Speeding up with boot from SAN

While much is made of virtualization these days, there is another option for admins who need to support multiple operating systems on similar systems — boot from SAN. This involves connecting a server to high-capacity, redundant network storage via Fibre Channel or iSCSI and booting from that network rather than from internal disks.

Boot from SAN offers several advantages, the first being that the speed of the storage system is generally much higher than internal storage. It’s even higher than high-speed SCSI RAID internal storage, due to the offloaded RAID processing and the fact that storage systems typically have more spindles than most internal systems.

The biggest advantage to boot from SAN, however, is the administrative flexibility you gain. The admin can make one partition, install the OS to it, and clone that partition quickly and easily. You can then boot from the clone, install additional software, service packs, etc., and test with the new environment. If something goes wrong, you can revert to the original in a matter of less than a minute, rather than the longer period it would take to re-image the system or re-install the OS.

Setting up boot from SAN is a snap with most late-model servers. The first step is disabling any internal storage; if you have an internal RAID controller in the server, removing it may substantially reduce boot times. When using iSCSI, you have the option of booting from an internal dedicated iSCSI NIC with offload processing, which shows up as a boot device just like an internal disk when the BIOS is enabled. You can also boot from an iSCSI storage system without any additional hardware using emboot software or the embedded capability of some recent servers. With Fibre Channel, all recent host adapters support boot from SAN, requiring only that the feature be enabled in BIOS, and most high-end storage systems support it as well.

Once the server is set up, provisioning a volume is the same as for any other volume, although some storage vendors recommend using LUN masking on the Fibre Channel switch so that the server doesn’t see any other volumes. Once the volume is provisioned, the OS can be installed, and then cloned at will. Changing the boot volume is as simple as changing the mapping within the storage application.

For a practical example of this, I recently tested 10 e-mail archiving solutions, which needed to be installed on a Windows server. Because uninstalling software never seems to work completely (or at least you can’t count on it working completely), I would normally have had to dedicate 10 servers, or face re-installing or re-imaging Windows after each test run. I don’t run virtualization software because it adds an additional potential problem area during my testing, and some software doesn’t yet support being run in a virtual environment.

I set up one server, and configured it to boot from SAN, which was a Compellent Storage Center 3000. I then set up a 200GB volume, using thin provisioning, which meant that the actual space used was generally about 10GB with the server and archiving software installed. Once I installed Windows Server 2003, patched it with SP3, and installed all the necessary software updates, I cloned that image ten times — one image for each test. Changing from one image to another and rebooting took about two minutes, greatly facilitating the testing process. Plus, having each image available allowed me to go back and look at any previous test environment as questions came up during the review process.

In addition to the time savings, I found that disk performance in a boot from SAN environment was much better than using internal disk. In fact, it was so good that performance results in messages per hour archived were better than some of the vendors had expected.