what the hell is a LUN

Well, playing around with iSCSI i stumbled with LUN ... and according to wikipedia, LUN stands for Logical Unit Number, and its apparently related to scsi and/or raid, and apparently they are logical portions of disks, still what does that mean ?

Well, after looking around a bit, and finding a lot of talking about LUN and LUN explained ... etc, it turns out that from the iscsi-initiator host OS (client) point of view, a LUN is simply a disk ... every LUN regardless of being the only one in a given iscsi-target or whether there are multiple LUNs in an iscsi-target, its a disk, and if things are configured correctly, every LUN will give you a disk device like /dev/sdx or something similar .

So why have multiple targets each with one LUN or have multiple LUNs in one iscsi-target? again, as far as i understood from this very helpful post, from the client (initiator) perspective, its the same thing ... all are disks. just accessed with seperate iscsi-initiator procedure or with a single one, from server (target) perspective, distributing LUNs is just a managerial issue, and seperating LUNs into multiple targets helps the administrator to make policies about who is allowed to access which LUNs by distributing them among targets, and possibly setting authentication.

So ... what does all the talking about using LVM and software raid and other stuff all about ? well, after understanding that the LUN is somehow simply a disk to the client, you can do with it whatever you do with a disk! or multiple disks :) ... so you can format the LUN (now its a disk, like /dev/sdf) or you can use LVM to create Logical volume from multiple disks, which might be iscsi LUN or just old good regular disks :), or setup software raid , again, all this can be done on regular disks, scsi or sata or ata ... and now on LUNs too, you basically stop talking about LUN after iscsi-initiator is done with logging to the target and getting the LUN, afterwards, you treat it as a disk.

Now possibly you have RAID and LVM ...etc on the server side ... whats the story there ? and whats the strory with the word "carved" that is used in a couple of places online when talking about LUNs? ... the idea if fairly simple, when you have LUN on the target, you define where the real storage is going to happen, so on the target you define Path to where the actual storage will happen so you say for example Path=/iscsi-exports/2GBDISK1.iso or Path=/dev/sdc or Path=/dev/sda5 ...etc. as you can see you can put any file that you usually use for read and/or write to, and as you might already know, even regular files can be treated as disk volumes and you can mount them using a loop device. so these partions, disks, regular files or even iscsi LUN from a diffrent iscsi-target (which would appear as devices) can be used for a LUN, now these files, partions, disks ..etc, can reside on a hardware raid, or be part of an LVM, or software raid or anything else you can think of you can store data on, and might as well be a regular disk partion or a whole disk that is used as a LUN :).

Note:please feel free to correct me if there is something wrong or unclear in this post

Oracle RAC on ISCSI ... the small details ... round two

Now im starting over with installing oracle 11g RAC on iSCSI, the first round (actually that was probably the 5th round, but first round i write about) failed due lack of A)storage on iscsi target B)too little memory on one of the nodes.

So now i have a new iSCSI target setup on debian etch from backports, and im setting up a new powerful node to serve as a node in the Oracle RAC.

So i installed Enterprise Linux fine and i am following the same steps described in the "round one" post.

While trying to configure the iSCSI target, a question poped into my mind, what diffrence would it be if i configure a single target with multiple LUN or if i configure multiple targets each with single LUN, i have no idea what diffrence it makes.

So after a while of digging arond, i realized that the script provided from oracle howto will only work properly if you have one LUN in each target, but i had multiple LUNs in my iscsi-targets to have more space ... so i had to modify the script that returns the names of devices for persistant naming, here is the diff:

--- iscsidev.sh.bak 2008-05-10 19:44:49.000000000 +0300
+++ iscsidev.sh 2008-05-10 19:44:25.000000000 +0300
@@ -4,6 +4,7 @@
 
 BUS=${1}
 HOST=${BUS%%:*}
+LUN=${BUS##*:}
 
 [ -e /sys/class/iscsi_host ] || exit 1
 
@@ -16,5 +17,5 @@
    exit 1
 fi
 
-echo "${target_name##*.}"
+echo "${target_name##*.}LUN$LUN"

traffic control ... learning tc

Well, what do i want to do today, i want to try to distribute traffic in a fair way between clients on my network, so it seemed as a starting point i should start playing with tc.

So i started reading tc man page thoroughly, after a while of playing around with it i tried creating a qdisc using
tc qdisc add dev eth1 root pfifo
notice that anything less didnt work with me ! that went fine, now i want to view what i did, and the command tc qdisc show dev eth1 did it fine, now i tried to delete the qdisc i created using tc qdisc del dev eth1 root and it went well too.

Now i tried tc qdisc show dev eth1 and apparently there is a qdisc there!! i try to delete that but i get RTNETLINK answers: No such file or directory !!! later i realized this is probably a mandatory qdisk for every interface ... although found nothing about it in the man page, but a quick google search for "default qdisc" yielded this very informative link.

Now, what i understand so far that we have 3 elements working together, qdisc, class and rule ... and to put it in simple words, i think that qdisc ( a general framework for what we are talking about ) classifies packets into classes using some rules, and decides later according to the classification which packets should go out to the network interface.

As Expected, a year and a half later (sep 2009), i get back to reading on the topic, and i have no clue where i got the word rule! the word is "filter"!

this time i have used tc actually, i used iptables to "mark" certain packets, which then a tc "filter" captured them and sent them to a "class" that limits the bandwidth !!

Setting up iSCSI target on Debian etch

Todays adventure is setting up iSCSI target on debian !

First off, a normal installation of debian etch, using the defaults and nothing particularly special, afterwards, i search google for a debian package of iscsi target, and well, i find debian provides one for testing, one for unstable and one in backports :D yay, i quickly add the debian backports repository, and try to install it by doing apt-get install iscsitarget, and i get the following


Setting up iscsitarget (0.4.15+svn145-1~bpo40+1) ...
Starting iSCSI enterprise target service: FATAL: Module iscsi_trgt not found.
netlink fd: Connection refused
failed.


i looked this file using apt-file and googled around a little, but found nothing particularly helpful, but i noticed that there is a package called iscsitarget-source, which is not usual unless the source is needed to install a package, other wise source is usually provided seperately, so i apt-got it and there you have it in /usr/src/iscsitarget.tar.bz2, i extract the archive. now what, i see no doc or README in that archive, i look back at the packs installed, and notice that debian got module-assistant as a dependency for iscsitarget-source ... sure thing, thats the way to go, so i run module-assistant, try to select iscsitarget to build, and then fall back to the main menu and do "prepare" which gets a bunch of new packages and installs them.

Back to modules-assistant ... select ... iscsitarget ... ok ... build .... build fails!! :( i look at the errors, the first one i can see was:

CC [M] /usr/src/modules/iscsitarget/kernel/tio.o
In file included from /usr/src/modules/iscsitarget/kernel/tio.c:7:
/usr/src/modules/iscsitarget/kernel/iscsi.h:236: error: field ‘rx_hash’ has incomplete type

nothing before seems to be relevent to the error or triggering it, so i started asking around, and there you go , #debian-backports on oftc irc network guys tell me that it needs a newer kernel, and so does /usr/share/doc/iscsitarget-source/README.Debian which i didnt read before, so i need to install a newer kernel, which i still find in etch-backports. so i lookup which kernels are available and i do apt-get install linux-image-2.6.22-4-686 and linux-headers-2.6.22-4-686 and reboot.

now back to module-assistant, select, build, install,exit ... /etc/init.d/iscsitarget start ... all starts successfully :) now i can go ahead and play with the /etc/ietd.conf file (iscsi enterprise target daemon conf file).

Note:I wonder ... why would iSCSI target have anything in the kernel space ?