One of the more popular communications protocols in use today is iSCSI--or internet SCSI, as it is sometimes called. iSCSI traces its roots to the local SCSI storage bus, which allows a PC to communicate with SCSI-based devices using the SCSI protocol. Most SCSI devices are storage-related, but, over the years, there have been plenty of non-storage devices (such as scanners) that have leveraged the SCSI storage bus. Here's what you need to know about iSCSI and iSCSI use cases.
The iSCSI protocol is designed to allow SCSI communications to occur over an Ethernet network. It accomplishes this by encapsulating native SCSI commands into Ethernet packets, which can then be transmitted over a standard Ethernet network. This allows a host to communicate with SCSI devices, even though those devices are not connected to the host’s SCSI bus.
iSCSI has a number of different use cases. Some organizations build storage area networks that utilize iSCSI. SANs commonly use Fibre Channel connectivity, but iSCSI is usually much less expensive and easier to deploy than Fibre Channel.
iSCSI is also commonly used in failover clustering. Failover clusters commonly make use of a centralized storage device, known as a cluster shared volume. Because each cluster node must have access to the cluster shared volume, using direct attached storage isn’t usually an option. iSCSI provides a simple and efficient way for all of the cluster nodes to attach to the cluster’s shared storage.
One more use case is disaster recovery. Some organizations replicate their storage either to the cloud or to a remote data center. In the event of a disaster, hosts can use iSCSI to attach to the remote storage and use it as though it were directly attached to the host.
iSCSI is based on the use of two main components. The first is the iSCSI initiator. As previously mentioned, iSCSI is designed to essentially mimic a local SCSI storage bus. When a physical SCSI device is directly attached to a host, the device’s data cable attaches to the host through a SCSI bus adapter. Since iSCSI doesn’t make use of physical device connectivity (except through an Ethernet link), it uses software to emulate the SCSI bus adapter. This is where the iSCSI initiator comes into play. It is the initiator that enables SCSI commands to be sent to the remote SCSI device.
In case you are wondering, there is an iSCSI initiator that is built directly into the Windows operating system. You can see the Windows iSCSI initiator in Figure 1. You can access the iSCSI initiator in Windows Server 2016 by opening the Control Panel and then clicking on Administrative Tools, followed by the iSCSI Initiator option. The Microsoft iSCSI Initiator Service has to be running to launch the initiator; Windows will offer to start the required service for you the first time you attempt to configure the initiator .
Figure 1: This is what the Windows Server iSCSI initiator looks like.
The other main iSCSI component is the iSCSI target. On the most generic level, a target is simply a remote device that can accept an iSCSI connection. Targets usually define one or more logical units, or LUNs. To put this into prospective, imagine a JBOD disk array that supports iSCSI connectivity. The array itself would act as the target, with each of the individual disks acting as LUNs within the target. Of course, that is only one example of a LUN architecture. iSCSI targets can be configured in a variety of different ways.
Each iSCSI initiator is assigned a unique initiator name (which is sometimes referred to as an IQN). You can see an example of an initiator’s IQN in Figure 2. iSCSI targets are typically configured with a list of initiator names that are allowed to establish connectivity with the target. This prevents rogue initiators from accessing the target. Targets also typically support the use of other security features such as CHAP based authentication and IPSec encryption.
Figure 2: The Configuration tab displays this initiator’s IQN.
When an iSCSI initiator is configured to connect to a target, the initiator is usually provisioned with the target’s IP address, as well as any required authentication credentials. Once the initiator establishes connectivity to the target, the administrator can specify the individual LUNs that need to be mounted. Of course, the actual steps involved in configuring an initiator and establishing connectivity vary depending on the type of initiator (Microsoft, Linux, third party, etc.) that is being used.
If you are thinking about using iSCSI in your own environment, then it is strongly recommended that you use a dedicated Ethernet segment for carrying iSCSI traffic. Storage performance can suffer greatly if the iSCSI packets have to compete with other traffic that is flowing across the Ethernet network.