To ditch HBA on iSCSI SANs or not to ditch -- that is the question

Do you really need an iSCSI host bus adapter (HBA)? Strictly speaking, the answer is no. You can build a fully functional iSCSI SAN using standard Ethernet network interface cards (NICs) as the initiators. But whether it's a good idea to forgo an HBA is another question.

It used to be that any iSCSI SAN needed an HBA because the performance penalty outweighed the cost, even though the cost of an HBA was substantially more than an Ethernet NIC.

Even today, an iSCSI HBA runs $500 to $750. A high-quality gigabit Ethernet NIC costs perhaps 1/10 as much. However, the differences in server power, economics, and use of iSCSI SANs now make the issue of using HBAs less clear-cut.

The two issues with iSCSI SANs that do not use HBAs are performance and booting.

One big difference between an iSCSI HBA and a conventional NIC is that the HBA includes a TCP Offload Engine (TOE), an auxiliary processor that takes care of wrapping and unwrapping SCSI information in Ethernet frames. Since handling iSCSI housekeeping can easily eat 20 percent or more of the CPU cycles of the iSCSI server, the server in an iSCSI SAN that does not use an HBA may take a large performance hit.

However, the trend toward increasingly powerful servers at ever-more-affordable prices means that more servers are likely to have the CPU cycles to spare. This is especially true in environments that do not virtualize their servers.

As for the boot issue, an HBA initiator lets the system

Requires Free Membership to View

boot from the SAN. Since the system can't handle iSCSI packets until it is up and running, an iSCSI SAN without an HBA must boot from a directly attached hard drive or other device.

However, there are now ways to boot from an iSCSI SAN without HBAs. For example, NetBoot software from emBoot Inc. enables booting by storing a copy of the system's boot volume in the iSCSI array and using a Windows boot initiator on the system driver to load the boot files from the SAN at startup.

There is one last factor to consider. Originally, most iSCSI SANs were alternatives to, or replacements for, Fibre Channel SANs. They were not expected to offer the same performance as FC SANs -- early iSCSI SANs didn't have the same throughput as FC SANs and even today a high-performance SAN is more than likely an FC SAN.

However, the low cost of iSCSI SANs is increasingly encouraging enterprises to use them in areas that do not require the performance of an enterprise SAN, such as snapshotting or for departmental computing.

Bottom line: In some cases it is worth considering an iSCSI SAN without an HBA. But it will take analysis, and probably some testing with performance tuning tools such as iostat, to see if you can get by without HBAs in a particular application.

About the author: Rick Cook specializes in writing about issues related to storage and storage management.

More information from SearchWinSystems.com

This was first published in May 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.