Disk management basics for iSCSI deployments

One SAN technology that is really starting to gain popularity is iSCSI, which allows clients to connect to remote storage devices by sending SCSI commands over an IP network. The question is, how does a client to use iSCSI to connect to a Storage Area Network?

As you know, storage area networks typically consist of large RAID arrays connected to each other by high-speed cabling. When iSCSI clients connect to a SAN, they are not connecting to the SAN as a whole. Instead, they connect to either an individual storage device or a storage pool that has been designated for use by the client.

Logical unit numbers

If you're familiar with traditional SCSI, then you know that each device on a SCSI bus is assigned a logical unit number (LUN). In that sense, a LUN corresponds to a physical storage device. When we talk about SANs, though, a LUN can still refer to a physical device, but it doesn't have to. It is also possible for a LUN to point to a storage pool, such as an individual volume on a large RAID array.

iSCSI itself does not impose restrictions on a LUN that is shared among multiple computers. However, sharing a LUN in this way can be a recipe for disaster.

In an iSCSI environment, a LUN is treated very similarly to how a physical storage device would be treated on a traditional SCSI bus. The difference is that the client must use an iSCSI Initiator to establish a connection to the LUN, which is also referred to as a target. The iSCSI Initiator treats the LUN the same way that a physical SCSI controller would treat an individual storage device in that it maintains direct control over the LUN. Clients are able to format the LUN and apply their own file system to it just as if the LUN were physically attached to the client computer.

In case you're wondering, iSCSI itself does not impose restrictions on a LUN that is shared among multiple computers. However, sharing a LUN in this way can be a recipe for disaster. If an individual LUN needs to be shared among multiple computers, then, typically, one individual server uses its iSCSI Initiator to establish connectivity to the LUN. From there, the administrator can use the server to share resources on the LUN in the same way that they would share folders on a locally attached storage device. Client computers that attach to the server that is using the LUN neither know nor care that the shared resources are not physically attached to the server.

Software initiators

As you might have heard, Windows Vista and Windows Server 2008 both contain a built in iSCSI Initiator, which is also classified as a software initiator.

Looking for more storage management advice? Check out our Windows storage tip section

Software initiators, like the one built into Windows, simply use software to make the client able to speak to the iSCSI protocol. Just as there are software-based iSCSI initiators, some of them are also hardware-based. A hardware-based initiator works by offloading the processing of the iSCSI in the TCP protocol to a specialized card. This often allows the initiator to perform better than a software-based one, because much of the overhead is taken care of outside of the operating system.

One of the most common types of hardware-based iSCSI initiators are host bus adapters, or HBAs. A host bus adapter appears to the client as a SCSI bus. However, this device differs from a traditional SCSI bus in that it includes a dedicated NIC and a TCP offload engine.

In case you aren't familiar with the concept of a TCP offload engine, it's basically an integrated component that takes care of assembling TCP packets before they are sent out and extracting data from TCP packets that have been received. TCP offload engines are not unique to iSCSI engines. In fact, some NICs include TCP offload engines. The benefit is that if TCP packets are assembled and disassembled at the hardware level, then there is less work for the system's CPU to perform, which results in better performance.