Storage

Boot from SAN option's pros and cons

Scott Lowe lists nine things to keep in mind when using the boot from SAN option when architecting a data center infrastructure.

There are a number of decisions that the IT department must make when architecting a data center infrastructure; one of those decisions is whether to support local boot storage in a server or use a shared storage device. In this post, I discuss some of the potential pros and cons associated with the boot from SAN option.

Pros

  • Less expensive servers. With boot from SAN, you no longer need to buy servers with expensive storage controllers and hard disks. However, some of these savings are offset by the need to include a storage adapter that has boot capabilities, such as a Fibre Channel adapter or an iSCSI adapter.
  • Easier server maintenance. Without local storage, there is one less component to worry about in the server. The servers become nothing more than interchangeable compute nodes. If one of these compute nodes fails, it's much easier to replace the server -- simply connect the new server and attach it to the SAN-based boot volume. The new system may require new drivers for some components, but that's not a horrible problem to overcome. Quick and easy server replacement is a major advantage that shouldn't be overlooked.
  • More robust storage. In most enterprise environments that use SAN-based shared storage, the storage infrastructure is intentionally built to be rock solid since it holds, in many cases, everything. This means that the SAN probably has more disks, more capacity, faster storage processors, and other redundancies that might not be found on a local server. Further, if we start to get low on disk space on one of the connected servers, we just provision more.
  • Additional availability opportunities. Many SANs feature SAN-based replication capabilities, which means that the contents of the SAN can be automatically replicated to a secondary data center. Although individual servers can also be replicated, doing so requires additional software that may not be a standard operating method in an environment, thereby creating a process exception that can be difficult to support.
  • New upgrade options. When the time comes to move to a new operating system across the entire organization, you can more easily stage the upgrade by creating all of the OS images on the SAN and then connecting individual servers to new boot images.

Cons

  • Need for more advanced storage adapter. Boot from SAN requires some method by which a server can be connected to a storage device before the operating system has had an opportunity to load drivers. In a Fibre Channel environment, this is the job of the BIOS on the adapter. In addition, it's possible to procure iSCSI adapters that support booting from iSCSI-based SANs. In an environment that is already using shared storage, it's likely that the servers would already be provisioned with these storage adapters, so storage adapters may not be an additional cost that is borne to just boot from SAN.
  • Potential for boot storms. If there are many servers booting from shared storage, it's possible that all servers could attempt to boot at once. This situation can overload the storage since boot time is an intensive process from a storage perspective. As such, planning is key to make sure that all SAN-based services remain within performance parameters supported by the SAN.
  • Additional complexity. Local server-based storage is a known entity that people have been managing for decades. Although many use boot from SAN, it's not as common as local storage and requires new ways of thinking. Further, special care needs to be taken to make sure that the SAN boot environment operates as expected. The exact method can vary from SAN vendor to SAN vendor and from HBA to HBA.
  • All eggs in one basket. In a properly architected storage environment, this shouldn't be a problem, but in a SAN environment that isn't rock solid, a boot from SAN initiative could prove to be undesirable, as it would expose the organization to additional risk from the loss of that single piece of hardware. For example, if the SAN does not have redundant everything (including controllers, power supplies, and the like), the risk is too high.

Coming up next

At Westminster College, we use a Xiotech Emprise 5000 storage array with 4 Gbps Fibre Channel. The unit has a total of 40 disks and is rock solid. We've recently begun implementing boot from SAN with the Xiotech unit and our Dell blade servers, and it has been a great experience. Although there is some additional upfront configuration, we have much more flexibility. I'll describe the entire process in my next article.

About

Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...

2 comments
jianyan
jianyan

You don't need to use special adapter. You can use the open source ipxe as the boot loader.

b4real
b4real

Admitting that I'm almost exclusively virtual..... I like to use flash and boot from that; but all substantive work is done on the SAN. This keeps costs low on the server; but doesn't make local HBA do the booting; giving me "slightly" more flexibility on server model and HBA model. Further, it's easier for off-line testing that way.

Editor's Picks