The iSCSI's Internet Protocol System


This site may possibly earn a commission from affiliated partners for qualifying purchases should you choose to buy through our links.


A lot of debates, opinions, and discussions have been said about iSCSI which many in the software and hardware development servicing world would often confuse us. Which is which? What is iSCSI? How can it be of help to my IT systems in place in particular and my business in general? Let us start first by understanding iSCSI.

Understanding iSCSI

In the computing world, Internet Small Computer System Interface (iSCSI) is an Internet Protocol (IP) system that describes how information is collected together. This information,  for purposes of references and analysis, is then transferred between host systems (in particular, servers) and a standard storage networking device for linking data storage facilities, such as storage area networks (SANS) over long distances. It is a storage area network (SANs), a protocol allowing business organizations to integrate storage into data center storage arrays. To have a complete understanding of the systems, the Internet Engineering Task Force (IETF) standardized it in 2003 and merges the Transmission Control Protocol/Internet Protocol (TCP/IP) suite with the Small Computer System Interface (SCSI) storage protocol to establish a process of operation for block transfer of data over Ethernet network systems. To further clarify it, iSCSI is used and can be used to transmit or facilitate the transfer of data over the Internet, local area networks (LANs), or wide area networks (WANs). iSCSI can also permit location-independent data storage and retrieval.

This system of protocols will enable clients, (initiators) to send SCSI commands in a Command Descriptor Block (CDBs) to SCSI storage devices (targets) on remote servers. iSCSI allows transmission of data of SCSI storage commands within IP packets. At the same time allowing TCP to take flow control ensuring dependable and sound transmission with an application already running on host systems. The data is transferred in raw form block-by-block between SAN and the host system, making it appear to the host system as an illusion of locally direct-attached storage disks and not a network storage device. The host system can generate in itself disk storage called a virtual disk (generally called logical unit numbers or LUNs) or just a VHD file. Within the storage array, it ultimately generates volumes of these virtual disks (VDs), format this using NTFS file system, and apply these volumes as if they were locally installed hard drives in the host system. Unlike a network-attached storage device (NAS) that uses a file transfer protocol such as CIFS, NFS, or SMB in transferring data between a host system and the NAS device.

How iSCSI storage works
Fig. 1: How iSCSI storage works

The Purpose of iSCSI in A Networking Infrastructure

Primarily, iSCSI was developed as a replacement to the costly Fibre Channel SANS (FC SANs) system of implementing networked storage because it uses dedicated hardware like the FC host bus adapters (FC HBAs) and fiber optic cables. On the other hand, iSCSI will not require you to purchase any additional hardware because any existing network infrastructures such as switches, routers, network adapters, and so on will be instead utilized. The iSCSI architecture is implemented by utilizing a client/server architecture involving the iSCSI Initiator and iSCSI Target. The initiator is normally a server or some other computing entity requiring access to storage, whereas a target is normally a storage entity linked to an IP network.

iSCSI was pioneered by IBM and Cisco in 1998 and submitted as a standard draft in March of 2000.

Hardware or Software Initiators: Choosing the Right iSCSI Initiator Matters

An initiator works as an iSCSI client, typically serving the very same purpose to a computer as a SCSI bus adapter, except that apart from physically cabling SCSI devices, it is sending commands over an IP network. In deploying an iSCSI network, like in large iSCSI SAN in data centers, often the choice of iSCSI initiator is overly critical due to the significant effect on the selection of operating systems (OS), hardware, and the impact it may cause on your overall existing network infrastructure. 

The figure above conceptually describes iSCSI SAN with an initiator and a target
Fig. 2: The figure above conceptually describes iSCSI SAN with an initiator and a target

Software iSCSI Initiator

In most cases, a software iSCSI initiator is the cheapest option, the simplest to implement and manage. A software initiator utilizes code to implement iSCSI, typically taking place in a kernel- resident device driver using the existing network card (NIC) and a network stack to imitate SCSI devices in a computer by speaking the iSCSI protocol. An iSCSI initiator, without questions, will impact the server’s performance, especially when high-speed, multi-core CPUs are common in most servers, are not running at full CPU capacity. If it happens, then dedicating CPU resources to iSCSI protocol for a software iSCSI initiator may not be a problem.

It is true that the software iSCSI initiator does not incur any added cost. However, there is a common understanding that their performance dips in comparison with a hardware iSCSI initiator. It is because the software initiator will need to perform a transformation from an IP to SCSI and back, at any time when storage data is received over an IP section. This was a typical scenario in the early days of iSCSI. But at the moment most servers have so much processing power to perform that protocol transformation. Besides, there is now exists server virtualization since it is scarce to find a single application consuming all the processing power of a host. Software initiators are accessible mostly in popular operating systems and generally are the most common procedure in deploying iSCSI.

Hardware iSCSI Initiator

Using hardware iSCSI initiator means fewer servers will be linked to the iSCSI SAN, if all CPU resources are required to be allocated to your applications and if budget permits for iSCSI host bus adapters (HBAs) for hardware iSCSI initiators are available, then iSCSI HBAs can be used.

Does it make sense to propose hardware iSCSI initiators? The first and most likely scenario in recommending hardware initiators is when your client wants to boot the server from an iSCSI SAN array. At present, it can be done only using a hardware iSCSI initiator. Countless hardware initiators possess processing capabilities on the card to unload the converted IP to SCSI, which will ultimately help address all concerns on CPU utilization issues. If iSCSI cards contain encryptions embedded in them, they could answer most of the customer’s security concerns within the system. In some cases, customers will pay extra expenses for hardware iSCSI initiator instead of managing what extra data protection processes they have in place.

Whenever the server is booting from local hard disks, that local disks will need to be individually protected but, if each of them is booting from SAN then security protection and retrieval could be all directed entirely on the SAN. By doing so, it can be able to leverage snapshots and replication in protecting all data. In general, hardware-based initiators are unnecessary except in situations that booting the SAN is advisable.


So how do you choose which iSCSI initiator type to use in your network infrastructure - hardware or software? Oftentimes, it boils down to your budget, management, requirements, hardware, and performance needs. 


Post a Comment

Previous Post Next Post