This site may possibly earn a commission from affiliated
partners for qualifying purchases should you choose to buy through our links.
Introduction
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.
 |
| 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.
 |
| 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.
Conclusions
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.
This site may possibly earn a commission from affiliated
partners for qualifying purchases should you choose to buy through our links.