In many cases, the answer is a simple one: the software iSCSI initiator that comes with the operating system, typically loaded as a device driver. Remember that one of the key drivers for iSCSI storage solutions is keeping the costs down. Nothing drives up costs faster than having to to buy dedicated hardware to make the solution work. Using a hardware initator also means that fewer servers will be attached to the iSCSI SAN, which means that the cost can't be amortized across as many systems and lengthens the ROI.
While software iSCSI initiators don't incur an added cost, there is a perception that their performance suffers in comparison with hardware iSCSI initiators. That's because the software initiator has to perform a translation from IP to SCSI and back any time storage data is received over the IP segment. This translation requires the CPU resources of the server that the initiator is run on. This was especially a concern in the early days of iSCSI. Processing power was nowhere near as robust as it is now, nor was the iSCSI initiator software. Over the past six years or so, that's changed.
Nowadays, most servers have plenty of excess processing power to perform the protocol translation. (In fact, server virtualization now exists because it's rare to find a single application that can consume all the processing power of a host.) And, jumbo-frame-capable products, which lower the load on the processor by adjusting the Ethernet frame size beyond its relatively small (from a storage perspective) default setting, are now much more commonplace than in the past. And configuring jumbo frames is much easier. In an iSCSI network, each frame that the server receives needs to be processed for IP-to-SCSI conversion. The more frames, the more time the server spends processing each frame and the busier the CPU is at that task as opposed to others. Making the frame size larger means that the server CPU will have fewer frames to process.
When do hardware initators make sense to recommend? There are two distinct scenarios. The first and most likely scenario is when your customer wants to boot the physical server from the iSCSI SAN array. Today, this can only be done with a hardware iSCSI initiator. There are valid reasons to recommend this. For example, if the server is being booted from a local hard disk, that local hard disk needs to be protected separately. If everything is booting from the SAN, all the protection and recovery can be focused on the SAN, leveraging its ability to do snapshots and replication to protect all data. Some customers will pay the extra expense for a hardware iSCSI initiator instead of having to manage extra data protection processes. The other use case may be encryption. If iSCSI cards have encryption embedded into them, they could address some of a customer's security concerns.
Most hardware iSCSI initators have processing capabilities on the card to offload the IP to SCSI conversion, which should help address CPU utilization issues as discussed above. In reality, however, we have not seen many situations where software initiators cause an undue amount of additional load. Reaching 75% or more of the potential bandwidth of your iSCSI connection is now realistic with software iSCSI initiators. Hardware-based initiators are generally unnecessary except in situations where booting from the SAN is desirable.
About the author
George Crump is president and founder of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. With 25 years of experience designing storage solutions for data centers across the United States, he has seen the birth of such technologies as RAID, NAS and SAN. Prior to founding Storage Switzerland, George was chief technology officer at one of the nation's largest storage integrators, where he was in charge of technology testing, integration and product selection. Find Storage Switzerland's disclosure statement here.
This was first published in March 2010