The Basics
Before we actually build anything, you need to understand a couple things. Lets look at how iSCSI addresses are formed and how iSCSI is used, some general terms, and overall methodology.
It's important to understand that iSCSI, unlike NAS, makes block devices available via the network. Effectively, you can mount block devices (disks) across an IP network to your local system and then use them like any other block device. Generally when you first use an iSCSI device your going to need to partition it, label it, and create a filesystem on it. Unlike NAS your kernel will be able to read and write to your new iSCSI device just as if it were a local hard disk and therefore you can use any filesystem you like (EXT2/3, JFS, XFS, ReiserFS, etc). Also, because it is being handled as a block device only one (1) system can use the iSCSI device at a time! (This changes if you use a global filesystem, or read-only filesystem.) So just like Fibre Channel your not making 4 machines access 1 filesystem, but instead your allocating 4 chunks of disk on one large device and making it avalible via an iSCSI target so that 4 initiators can access it.
All devices in an iSCSI enviroment will have addresses. Think of addresses in iSCSI as being the iSCSI equivelent to a Fibre Channel WWN. Every address must be unique. Initiators will have addresses, and targets will have addresses. When you define a target you can specify the address yourself. When you use an initiator the address is typically defined for you. For instance, on my test setup used for this tutorial I have the following addresses:
On Nexus, Linux System:iqn.1987-05.com.cisco:01.54197b8f9a8 -> Linux Initiator Addressiqn.1997-06.com.homestead:storage.disk1.nexus -> iSCSI Target Disk on Nexusiqn.1997-06.com.homestead:storage.disk2.drew -> iSCSI Target Disk for Drewiqn.1997-06.com.homestead:storage.raid.stripe0 -> iSCSI Target RAID On Blade, Solaris System:iqn.1987-05.com.cisco:01.f554845210af -> Solaris Initiator AddressiSCSI uses the following form for addresses, as found documented in IETF iSCSI Protocol Draft 20.
iSCSI Address Form: The following are examples of iSCSI qualified names that might be generated by "EXAMPLE Storage Arrays, Inc." Naming String defined by Type Date Auth "example.com" naming authority +--++-----+ +---------+ +--------------------------------+ | || | | | | | iqn.2001-04.com.example:storage:diskarrays-sn-a8675309 iqn.2001-04.com.example iqn.2001-04.com.example:storage.tape1.sys1.xyz iqn.2001-04.com.example:storage.disk2.sys1.xyzIn the above examples, you can see the form. There are two different address types, iqn (iSCSI Qualified Name) and eui (IEEE EUI-64 format). The date field is the date of the first full month that your naming authorities domain name was registered. The Naming Auth is the naming authority (domain name) for this target, reversed. Following the naming authority is a colon, after which you can put anything you want to help you better organize your resourced. In the example above (#2) this field is left off completely which is legal. In examples 1 and 3 above you can see different naming conventions being used to clarify the target resources type. But in both cases the date and naming authority are the same. Cuddletech was registered on Jan 30th, 1999, so if I shared a 20G target I might use the target address: "iqn.1999-02.com.cuddletech:public.dump.20g-Seagate.jfs". So far I have not seen an implementation that actually used the naming authority for resolution, so it doesn't really matter what the naming authority is. Most Cisco targets and initiators will get the naming authority of cisco.com, and thats not a problem. You'll almost always be asked for the IP address of the iSCSI target, so feel free to name your targets anything you want so long as it follows the convension above.
Some other terms you may want to know include "portals" and "discovery". An iSCSI portal is a targets IP and TCP port number pair. Typically, if the port number is not specified it is defaulted to 3260. Discovery, or auto-discovery, is the proccess of an initiator asking a target portal for a list of it's targets and thus making those available to the initator for use. Most of the time using discovery on a target portal is the best way to get connected, and you'll see this done when we setup an initiator later. You can, however, alternately specify specifically the portal and target you wish to use. You can also use iSNS (the Internet Storage Name Service) for discovery instead of contacting a specific portal. iSNS is effectively like DNS for network storage devices. Finally, one kool thing you can do, especially if your using iSCSI as a method to extend your FC-SAN, is to allow multi-pathing for fault-tolerance. In such as case, a storage device would be avalible as a target on 2 or more target portals (or specified as such in your iSNS directory) and if one server died, you could continue to access the device thru the other portals. But doing such is beyond the scope of this tutorial.
