Understanding iSCSI Infrastructure Deployment


Lighted Ways Tech
Shop Your Best Moments here. The easiest way to find your things!- CHECK EVERYTHING ON AMAZON
Network topology of iSCSI infrastructure
Figure 1: Network topology of iSCSI infrastructure | Source: http://opensourceforu.com


In any iSCSI software and hardware deployment, one must thoroughly understand the nature of its deployment, notably first, is how it affects its present infrastructure within the organization and its COSTS. Needs or requirements should be first established before comparative assessment of the nature of its application is considered, because for all you know software iSCSI (Internet Small Computer System Interface) initiators or hardware iSCSI initiators were just too much complicated.


The iSCSI protocol has obtained following as a method of presenting block storage devices over a network taking into account design considerations and deployment options, generally, trade-offs and factors to consider when deploying iSCSI storage. Basically, iSCSI is a network protocol utilizing TCP to transfer SCSI commands to enable the use of the already established TCP/IP (Transmission Control Protocol (TCP) and the Internet Protocol) networks as a SAN (Storage Area Network). iSCSI presents SCSI targets and devices to iSCSI initiators with SCSI over Fibre Channel (FC), unlike NAS (Network-attached Storage) that introduces devices at the file level, iSCSI create block devices through the network much like any other block storage devices.
A business organization with a centralized storage system, iSCSI gives customers several benefits relatively cheap based on familiar SCSI and TCP/IP standards compared to FC and Fibre Channel over Ethernet (FCoE) SAN deployments because iSCSI infrastructure needs less, low-cost hardware in the system. While at best FC SANs are more established and fully developed technology in the world of storage, iSCSI has become much more suited and accepted in recent years.
A major distinction between iSCSI and FC is due in part to I/O congestion mainly to overloading and oversubscriptions. In an instance that an iSCSI path overloads, the TCP/IP protocol will instantly drop packets that requires resending while FC has a built-in pause means when congestion occurs. When oversubscriptions (heavy traffic) occurs, a bad condition swiftly grows and performance will further deteriorate as drop packets must be resent.
Another thing to take into consideration is network bandwidth. Network bandwidth dependent on the Ethernet standards used 1 GB or 10 GB, but there are also other mechanisms that deliver greater network bandwidth such as port aggregation and bonding links. So, when implementing the iSCSI software initiators using a networking interface cards as an option instead of a dedicated ISCSI adapters, then it is best to use gigabit Ethernet interfaces, but bear in mind that these interfaces have tendencies to consume so much amount of CPU resources. One way of overcoming this problem is to use a TOE (TCP/IP offload engine) features. These features were just a simple process that shifts TOEs to TCP packets’ specialized processors from the CPU server on the network adapters or storage devices. Moreover, a lot of enterprise-level networking chipsets nowadays offer TCP offload or checksum offload which immensely boosts CPU overhead.

ISCSI Architecture
Type of iSCSI initiators
Figure 2: Type of iSCSI initiators | Source: https://vinfrastructure.it/
In recent years, iSCSI, to a wide extent has been considered a technology that fails to work well on wide-ranging applications over most wide-area sharing networks. It is just considered as a local area network technology yet it is changing rapidly as time goes on. Earlier in its inception, for synchronous replication writes (high availability) or remote data writes, iSCSI may not be a good fit in view of the fact that latency foundation may bring considerable delays to data transfers that might impact performance, while asynchronous replication which is not contingent on latency sensitivity makes iSCSI a perfect solution.

In a perfect scenario, iSCSI initiators must, at all times manage multiple, parallel communication links to multiple targets. Accordingly, iSCSI targets must, at all times manage multiple, parallel communication links to multiple initiators. A number of identifiers do exist in iSCSI to make this happen such as iSCSI Name, Target session identifier (TSID), iSCSI session identifiers (ISID) iSCSI connection identifier (CID) and iSCSI portals. iSCSI nodes consist of unique names that do not change whenever Ethernet adapters changes or IP addresses changes. Typically, a storage network composed of two kinds of equipment; initiators and targets. Initiators, typically a host, are data customers and targets, for example, disk arrays or tape libraries data providers. In this condition, iSCSI initiators fall under three well-defined classifications, software initiators, hardware initiators and hardware-assisted initiators.

Software initiators
Except in levels 1 and 2, the entire iSCSI protocol is implemented in software, thus it requires more CPU resources on the host.

Hardware initiators
Also called iSCSI HBA, the entire iSCSI protocol is implemented in hardware utilizing hardware resources on the adapter.

Hardware-assisted initiators
Part of iSCSI is implemented in hardware where in some cases uses host resources, such as the case of TCP Offload Engine (TOE) NIC.

iSCSI Sessions and Connectivity
An example of multiple connections to the target
Figure 3: An example of multiple connections to the target | Source: https://www.vmware.com/

iSCSI initiators and targets use TCP to make connection called sessions, identified by iSCSI session IDs (ISIDs). These IDs are not unavailable to the hardware and it can persevere through hardware swaps. 
At the same time, an iSCSI session might also hold multiple logical links. From a host's perspective, iSCSI sessions might also be viewed as in terms of paths linking the initiator and target. Possessing multiple links per session allows aggregation of bandwidth and can provide load balancing.

Initially performance will be the important factor in deciding which option to pursue but of course, it depends entirely on influencing factors and client’s needs. It is very important to understand that a throughput performance does not vary very much. However, a more important issue as iSCSI deployments grow will be the opportunity to reduce management costs as well as minimize resources required to scale IT infrastructure using iSCSI HBAs, to enable high levels of security, monitoring, fault isolation, and most of all performance management capabilities that will ultimately translate to remarkable IT personnel saving costs.


iSCSI is at present an exceptionally popular storage protocol found in vSphere infrastructures. It is a complement to, not a replacement for, VMware product documentation. Certainly it depends on several factors and also by customer’s needs. But could also be important to understand that throughput performance do not differ too much between the different types (naturally a software solution mean more host resources), it be contingent more on the NIC speed (and also on the number of NICs) and the Jumbo Frames (this is not actually correct for all storage, but generally yes).

And, if ever you find this article interesting, you can also read our 7 Best Steps in Preventing Ransomware Attacks.

Previous Post Next Post