Continuous data access: enterprise-level high availability using iSCSI

Computer Technology Review, July, 2004 by Zophar Sante

Storage Area Networks (SANs) can deliver data storage solutions that provide 99.999% data storage availability; but, originally, SANs were built on FC technology. However, for the majority of businesses, using FC to build a SAN is too expensive to deploy, too rigid in its components' geographical constraints and too complex to configure according to real-time network needs. Industry leaders realized that a new network architecture was needed and developed a way to route SCSI over TCP/IP. iSCSI paved the way for a new type of SAN, an IP-SAN, based on TCP/IP over Ethernet. With the right products, any business can now build a SAN that is simple, cost effective, highly scaleable and fast enough to exceed their performance requirements.

[FIGURE 1 OMITTED]

iSCSI Background

Before examining how iSCSI can enable high availability for an IP-SAN, let's review how an iSCSI storage target (volume) interfaces with the operating systems and file system on the host. This is especially important to understand since, with iSCSI, the host can conceivably be in Florida while the data and the storage targets are in California. An IP-SAN and iSCSI work under the file system at the block level. This allows iSCSI to support virtually any application, including databases, backup and restore applications and Exchange.

With traditional DAS or FC-SAN-attached disk drives or tape, a file system makes read and write requests via the server to the storage devices using a set of standard SCSI commands. The OS and file system have 100% control over these storage devices. iSCSI, like standard SCSI, is a block-based storage protocol layered underneath the file system. This means that an iSCSI volume appears as an additional disk drive when mounted by the OS. The iSCSI volume can be partitioned, named and formatted like a normal disk drive. The MS Windows screen in Figure 1 shows two new disk drives (Disk 2 and Disk 3) which are actually allocated to the server from an IP-SAN.

An iSCSI initiator driver is available for all popular operating systems. Standards for the iSCSI initiator are governed by the IETF (Internet Engineering Task Force). The iSCSI initiator driver responds to file system SCSI commands that are targeted to the disk drives the initiator represents. The iSCSI initiator driver encapsulates these SCSI commands and data into iSCSI packets that are, in turn, encapsulated into TCP/IP packets (see Figure 2). The TCP/IP packets are then routed very quickly over the Ethernet network, where they are delivered to an iSCSI storage target. The iSCSI storage target can be located on the same network within the building or halfway around the world. This iSCSI target has all the same attributes as a standard SCSI storage system. Once the iSCSI packet arrives at the iSCSI storage system representing the targets, the SCSI commands and data are decapsulated from the iSCSI/TCP/IP packet and are executed on the storage system. Once executed, the results are encapsulated back into iSCSI/TCP/IP and returned to the iSCSI initiator driver on the server where they are decapsulated and delivered to the SCSI layer and then the file system

Automatic Multi-Path Failover With the iSCSI Initiator

The iSCSI initiator comprises layers that are key to providing multiple data paths between servers and iSCSI storage targets, like those provided by the iSCSI intelligent storage switch. The two main layers within the iSCSI initiator are the session and connection layers.

[FIGURE 2 OMITTED]

The first layer is the "session" layer, an upper layer responsible for maintaining the communication to the SCSI layer within the server. It also ensures proper order of SCSI commands and data to and from the server file system to the iSCSI storage target. SCSI commands are numbered in sequence as they are sent from the server. The iSCSI storage target arranges the SCSI commands according to their order, ensuring that commands are not lost, taken out of order or duplicated.

Within every server there is usually only one iSCSI initiator but there can be more than one session established and running within a single initiator. For example, if there are two iSCSI storage targets being used by the server, then there would be one initiator with two sessions running. In Figure 3 there are two sessions running, which means that the server iSCSI initiator is using two unique iSCSI connected targets or disk drives/volumes.

The second layer is the "connection" layer. The connection layer is the TCP/IP connection between the server and the iSCSI storage target which, in our case, is the iSCSI intelligent storage switch. The session layer can maintain several connections. In common applications there is only a primary iSCSI TCP/IP connection; but for 99.999 applications there is a primary iSCSI TCP/IP connection and an alternate connection (Figure 3). All iSCSI traffic between the server and storage system travels over the primary connection. In most IP-SAN deployments, this is a Gb Ethernet link and is more than fast enough to handle average server traffic. With some application servers, a 10/100 Ethernet link (100Mb) is adequate since most servers don't generate more than 50Mbs of sustained storage traffic. A Gb Ethernet link (1000Mb) is recommended to handle I/O spikes if spikes result in I/O bursts greater than 50Mbs assuming a 50% overhead.