开发进行时...

Nowadays, the iSCSI technology is quite popular in the storage world. This article shows an iSCSI demo environment which consists of one Debian Linux host and one Netapp Filer. We try to show the most important features of this protocol.

1. What is iSCSI?
It's a network storage protocol above TCP/IP. This protocol encapsulates SCSI data into TCP packets. iSCSI allows us to connect a host to a storage array via a simple Ethernet connecton(tape drive). This solution is cheaper than the Fibre Channel SAN (Fibre channel HBAs and switches are expensive). From the host view the user sees the storage array LUNs like a local disks. iSCSI devices should not be confused with the NAS devices( for example NFS). The most important difference is that NFS volumes can be accessed by multiple hosts, but one iSCSI volume can by accessed by one host. It is similar to SCSIi protocol: usually only one host has access to one SCSI disk ( the difference is the cluster environment). The iSCSI protocal is defined in the RFC3720 document by the IETF (Internet Engineering Task Force).

Some critics said that iSCSI has a worse performance comparing to Fibre Channel and causes high CPU load at the host machines. I think if we use Gigabit ethernet, the speed can be enough. To overcome the high CPU load, some vendors developed the iSCSI TOE-s(TCP Offload Engine). It means that the card has a built in network chip, which creates and computes the tcp frames. The Linux kernel doesn't support directly this and the card vendors write their own drivers for the OS.
The most important iscsi terms:

Initiator:

The initirator is the name of the iSCSI client. The iSCSI client has a block level access to the iSCSI devices, which can be a disk, tape drive, DVD/CD writer. One client can use multiple iSCSI devices.

Target:

The target is the name of the iSCSI server. The iSCSI server offers its devices (disks, tape, dvd/cd... etc.) to the clients. One device can by accessed by one client.

Discovery:

Discovery is the process which shows the targets for the initiator.

Discovery method:

Describes the way in which the iSCSI targets can be found. The methods are currently avaiable:
Internet Storage Name Service(iSNS) - Potential targets are discovered by interacting with one or more iSNS servers.
SendTargets - Potential targets are discovered by using a discovery-address.
SLP - Discover targets via Service Location protocol (RFC 4018)
static - Static target address is specified.

iSCSI naming:

The RFC document also covers the iSCSI names. The iSCSI name consists of two parts: type string and unique name string.
The type string can be the following:
iqn. : iscsi qualifiled name
eui. : eui-64 bit identifier
Most of the implementations use the iqn format. Let's see our initiator name: iqn.1993-08.org.debian:01.35ef13adb6d
iqn: we use iSCSI qualified name address.
1993-08: the year of the month on which the naming authority acquired the domain name which is used in the iSCSI name.
org.debian: reversed dns name which defines the organizational naming authority.
01.35ef13adb6d: this string is defined by the naming authority.

Our target name is similar (iqn.1992-08.com.netapp:sn.84211978). The difference is that contains the serial number of Netapp filer. Both names are user editable (initiator, target). We need also two ip addresses for the target and for the initator, too.
the following figure shows our demo environment. It consists of one Debian host which is the iSCSI initiator, and accesses the iSCSI disk via /dev/sdb device. The Netapp filer is our iSCSI target device, which offers /vol/iscsivol/tesztlun0 disk or lun for the Debian Linux host. The iSCSI session consists of login phase, then the data exchange phase.

2. iSCSI support on other Unix platforms

The Cisco iSCSI Driver is one of the earliest software iSCSI initiator implementations. This driver supports all of the major commercial Unix systems and their version (HPUX: 10.20, 11, 11i, AIX: 4.3.3, 5.1, 5.2, Solaris: 2.6, 7,8,9). The earliest release can be dated back to 2001. Currently each Unix vendor implements its own driver, and we investigate these drivers.

Solaris:
Solaris 10 (from 1/06 release) supports iSCSI. The initiator driver can do the following:
Multiple sessions to one target support: this feature enables that one client can create more iSCSI sessions to one target as needed, and it increases the performance.
Multipathing: with the help of Solaris Mpxio or IPMP feature we can create redundant paths to the targets.
2 Tb disks and CHAP authentication are also supported. The Solaris driver can use the three discovery methods (SLP can't). iSCSI disks can be accessed by the format program.

HPUX:

HP supported the iSCSI from the HP 11i v1 os. This driver can discover the targets via SLP (Service Location Protocol ) which is also defined by IETF(RFC 4018). This means that the iSCSI initiator and targets register themselves at the SLP Directory agent. After the registration the iSCSIi initiator queries only the Directory agent. HPUX driver implements all of the discovery methods. The CHAP authentication is also implemented and the OS multipath tools (PVLinks) also supported. The HPUX driver provides transport statistics, too.

AIX:

From 5.2 AIX supports iSCSI. The driver implements the static target discovery only. We can use the iSCSI disks with AIX multi pathing called MPIO. The CHAP authentication is also supported.

None of the drivers allows us to boot from iSCSI. This can be a next step in the driver development.

3. iscsi Linux implementations
initiator implementations:
Cisco also released Linux driver but it is quite old.
The Intel iSCSI implementation contains both target and initiator drivers and a handy tool for generating workloads.
UNH-iSCSI is an initiator and target implementation of the University of New hampshire.
The Open-iSCSI project is the newest implementation. It can be used with 2.6.11 kernels and up. We will test this driver with the Debian host. It contains kernel modules and an iscsid daemon.
The iscsid can be started with the following command:
/etc/init.d/open-scsi start

The iSCSI operations can be controlled with the iscsiadm command. the command can discover the targets, login/logout to the target, and displays the session information.

The configuration files are under the /etc/iscsi directory:
iscsid.conf: Configuration file for the iscsi daemon. It is read at startup.
initiatorname.iscsi: The name of initiator, which the daemon reads at the startup.
nodes directory: The directory contains the nodes and their targets.
send_targets directory: The directory contains the discovered targets.

The installation process is quite simple. Issue:
apt-get install open-iscsi

This driver implements currently the Sendtargets discovery method.

Target implementations:

iSCSI enterprise target is the open source target implementation for Linux. It based on the Ardis iSCSI Linux implementation and requires the 2.6.14 kernel. Openfiler is a quite popular Linux NAS implementation, and offers a Linux based NAS software with a web based GUI.
Many other companies offer software-based commercial iSCSI target drivers(Amgeon, Mayastor, Chelsio).
The storage array manufacturers offer also a native support for iSCSI(EMC, Netapp, etc.)
we have chose Netapp FAS filer for the testing, but you can test it with a free software. These is a link at the bottom of the article which shows how can we do it with Openfiler.

4.Setting up the iSCSI Linux demo environment

Our demo environment contaions one Debian Linux host and one Netapp filer. The Debian host is the initiatior, and the Netapp filer is the target.
The setup process is the following briefly:
1. We should set up the tcp/ip connection between Debian and Netapp filer. The initiator and target musting ping each other. We assume that the open-iscsi package is already installed on Debian.
2. The Debian host must discover the Netapp targets. It is called a "discovery" process. Then the target sends the target lists.
3. The target must enable to the initiator to access the LUN. On the Netapp side, it means that we should create one initiator group, which is a logical binding between the hosts and the luns. The initiator group contains the lun and one Debian host which can access this lun.
4. When the initiator gets the target lists, it must "login" to the target.
5. When the "login" process completes successfully and Netapp filer allows the access, the initiator can use the iSCSI disk as the normal disk. It appears under /dev/sdx devices and you can format, mount it like the normal disk.

here are the Netapp filer from the Linux host:
debian:~# ping nasa

PING nasa (192.168.2.222) 56(84) bytes of data.

64 bytes from nasa (192.168.2.222): icmp_seq=1 ttl=255 time=0.716 ms
64 bytes from nasa (192.168.2.222): icmp_seq=2 ttl=255 time=0.620 ms

It's successful.
2. we discover the netapp filer iSCSI LUNs with the iscsiadm command. We have choosen the st(sendtargets) discovery method. Currently it is implemented with this driver:
debian:~# iscsiadm -m discovery -t st -p 192.168.2.222

192.168.2.222:3260 via sendtargets

Let's see the discovered targets:

debian:~# iscsiadm -m node

192.168.2.222:3260,1000 iqn.1992-08.com.netapp:sn.84211978

3. We have to prepare the Netapp side: in this example we will create one 4GB LUN(part of the RAID group), and assign it to the Debian host. We should check the free space:
nasa> df -k

Filesystem total used avail capacity Mounted on
/vol/vol0/ 8388608KB 476784KB 7911824KB 6% /vol/vol0/
/vol/vol0/.snapshot 2097152KB 10952KB 2086200KB 1% /vol/vol0/.snapshot
/vol/iscsiLunVol/ 31457280KB 20181396KB 11275884KB 64% /vol/iscsiLunVol/
/vol/iscsiLunVol/.snapshot 0KB 232KB 0KB ---% /vol/iscsiLunVol/.snapshotunVol/testlun1

The following command creates one 4GB Lun on the iscsiLunVol volume:

nasa> lun create -s 4g -t linux /vol/iscsiLunVol/testlun1

Check it:

nasa> lun show

/vol/iscsiLunVol/iscsitestlun 7.0g (7526131200) (r/w, online, mapped)
/vol/iscsiLunVol/iscsitestlun2 7.0g (7526131200) (r/w, online, mapped)
/vol/iscsiLunVol/testlun1 4g (4294967296) (r/w, online)

We should check if the Debian host is visible from netapp host:

nasa> iscsi initiator show

Initiators connected:
TSIH TPGroup Initiator
19 1000 debian (iqn.1993-08.org.debian:01.35ef13adb6d / 00:02:3d:00:00:00)

Ok, we see the Debain host. Let's create the initiator group, called Debian2.

nasa> igroup create -i -t linux Debian2 iqn.1993-08.org.debian:01.35ef13adb6d

nasa> igroup show

Debian2 (iSCSI) (ostype: linux):
iqn.1993-08.org.debian:01.35ef13adb6d (logged in on: e0a)

We should assign the newly created Lun to the Debian2 hosts.

nasa> lun map /vol/iscsiLunVol/testlun1 Debian2

lun map: auto-assigned Debian2=2

The check command:

nasa> lun show -v

/vol/iscsiLunVol/testlun1 4g (4294967296) (r/w, online, mapped)
Serial#: hpGBe4AZsnLV
Share: none
Space Reservation: enabled
Multiprotocol Type: linux
Maps: Debian2=2

4. Lets go back to our initator host. Now everything is prepared to access the 4GB lun. The following command makes the disk accessible from the Linux host.

debian:~# iscsiadm -m node -T iqn.1992-08.com.netapp:sn.84211978 -p

192.168.2.222:3260 --login

We should see the following entries in the messages file:

debian:~# tail /var/log/messages

Apr 13 00:31:34 debian kernel: scsi: unknown device type 31
Apr 13 00:31:34 debian kernel: Vendor: NETAPP Model: LUN Rev: 0.2
Apr 13 00:31:34 debian kernel: Type: Unknown ANSI SCSI revision: 04
Apr 13 00:31:34 debian kernel: Vendor: NETAPP Model: LUN Rev: 0.2
Apr 13 00:31:34 debian kernel: Type: Direct-Access ANSI SCSI revision: 04
Apr 13 00:31:34 debian kernel: SCSI device sdb: 8388608 512-byte hdwr sectors (4295 MB)
Apr 13 00:31:34 debian kernel: sdb: Write Protect is off
Apr 13 00:31:34 debian kernel: SCSI device sdb: drive cache: write through
Apr 13 00:31:34 debian kernel: sd 1:0:0:2: Attached scsi disk sdb

The disk appears as the sdb device (/dev/sdb).

5. We can use it as the normal disk. You can create one partion, and you can easily mount it.

debian:~# fdisk /dev/sdb

debian:~# mkfs /dev/sdb1 ; mount /dev/sdb1 /mnt

If you want to use sdb after the next reboot, you should change the following entry:

node.conn[0].startup = manual to automatic

in the /etc/iscsi/nodes/<iscsi target name>/<ip address> file. After you change it the iSCSI daemon will login to this target. Adding an automatic mount entry (/dev/sdb1 /mnt) in the /etc/fstab file doesn't work, because the open-iscsi daemon will start later than the mounting of filesystems. One simple script can solve this problem, which does the automatic mounting after the iSCSI daemon starts.

The open-iscsi initiator implementation tolerates network errors well. If you disconnect the Ethernet cable and connect it again, you must start the io process again, but the reconnection occurs automatically.

Another good solution is for the network failures, if you create multiple paths for the one LUN (For example: /dev/sdb, /dev/sdc), the initator logs in to two locations (two RAID controllers) and you make the two disks as a single logical disk using Linux multipath software (dmsetup).

I recommend another alternative for iSCSI target implementation: Openfiler (if you cant test on the Netapp box). It is a free Linux based NAS sofware, which can be managed with a web based GUI.

The iSCSI setup process is quite similar in the case of other Unix implementations.

5. Summary and results
iSCSI is a good solution for a cheap disaster recovery site.You shouldn't buy an expensive Fibre Channel card at the disaster recovery site, you can use the Ethernet and iSCSI. You can also use it for connecting hosts to disk arrays without Fibre Channel host adapters (if the arrays are iSCSI capable).

During the test I ran the Debian host in the Vmware player program, and my network connection was 100 Mbit/s. I cannot reach more than 15 MB/s read/write performance but it isn't relevant. With Gigabit Ethernet you can reach much better performance, the only drawback is that it increases the CPU load (CPU must build and compute TCP frames).