Saturday 2 June 2012

ISCSI - technical details

ISCSI:
The iSCSI protocol is a storage area network (SAN) protocol which allows iSCSI initiators to use storage devices on the (remote) iSCSI target using normal ethernet cabling. To the iSCSI initiator, the remote storage looks like a normal, locally-attached hard drive.


1. What is iSCSI?

It is 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 connection (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 enviroment). The iSCSI protocol 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.


Initiator:

The initiator 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 available:

    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 adress 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 adress.
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 adresses for the 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 versions (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 HP11i 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 initator, which the daemon reds 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 chosen Netapp FAS filer for the testing, but you can test it with a free software. There 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 contains one Debian Linux host and one Netapp filer. The Debain host is the initiator, and the Netapp filer is the target.

The setup process is the following briefly:

    We should set up the tcp/ip connection between Debian and Netapp filer. The initiator and target must ping each other. We assume that the open-iscsi package is already installed on Debian.
    The Debian host must discover the Netapp targets. It is called a "discovery" process. Then the target sends the target lists.
    The target must enable to the initator 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.
    When the initator gets the target lists, it must "login" to the target.
    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.

No comments:

Post a Comment