Boot Directly from an iSCSI SAN

In my article about the advantages of using iSCSI SANs as part of your virtualization infrastructure, "Bringing iSCSI SAN and Virtualization Together," I mentioned that it's possible to boot from an iSCSI target, but I only had room to scratch the surface of what's required to do so. In this follow-up, I'll discuss some of the reasons to boot directly from an iSCSI SAN and tell you the hardware, software, and other requirements for booting Windows servers from an iSCSI target.

You're probably familiar with the data protection capabilities that SANs provide for traditional data volumes, including RAID, snapshots, replication, and Microsoft Multipath I/O (MPIO) support. Most SAN vendors also provide robust hardware platforms that include redundant, hot-swappable components to minimize the potential for downtime. You may be thinking you can get these capabilities in a server already, but these features all come with costs, and adding them to many servers would make your expenses skyrocket. In some environments, such as blade computing, booting from SAN LUNs makes for great economies of scale. You invest in making the storage pool highly available and save on server hardware.

SANs also give you a level of portability for bootable volumes that's difficult, if not impossible, to achieve using direct access storage. Consider the effort it would take to transfer a hardware RAID system from one server to another in the event of a server motherboard failure. You can get tremendous efficiency improvements by using a SAN's snapshot technology to replicate a bootable server image created with Sysprep to a number of LUNs that support multiple-server–boot from iSCSI implementations. Additionally, SANs can support shared-boot scenarios, where multiple systems use a single OS image, but that's a topic for another article.

Of course, you should always consider a balance between the pros and cons of different storage architectures, and you must evaluate and mitigate the risks that come with putting all your eggs in one basket. If you make the move to boot a number of critical servers from a storage pool, it's your duty to ensure that an appropriate level of redundancy is built into the design of that pool and its supporting network infrastructure.

As with Fibre Channel SANs, you can use dedicated iSCSI host bus adapters (HBAs) to boot from an iSCSI SAN. This option is viable but relatively expensive. Although they use more CPU power, two other options are available that deliver comparable power, performance, and simplicity of configuration at lower prices than HBAs. iSCSI boot-enabled NICs and software-based iSCSI boot solutions are both ready for prime time. I'll discuss configuring a hardware iSCSI boot in this article.

Before we dig in, there are a few requirements to discuss, none of which should pose a problem for any organization that deploys and maintains relatively up-to-date technology. For acceptable performance, you need to use Gigabit Ethernet for your iSCSI connections. Your servers should have a PCI Express slot to accommodate the iSCSI boot-capable NIC—some PCI Extended (PCI-X) NICs can be found, but PCI Express is a newer, arguably better standard and vendors won't be making new PCI-X cards. The system BIOS on your server must support booting from an iSCSI SAN. The final requirement for both scenarios is the Microsoft iSCSI Software Initiator 2.0.4 or later, iSCSI boot initiator version, available as a free download from Microsoft's site.