One of the ways enterprises today with large numbers of servers are reducing costs and enable greater storage consolidation is by deploying diskless servers that boot from the SAN (FC or IP). While this technique is not new, the introduction of the Bladeserver, which provides greater manageability, reduced HW costs, simpler cable management as well as providing power, cooling and real-estate savings, has further accelerate the adoption of SAN booting.
Booting from the SAN provides several advantages:
* Disaster Recovery – Boot images stored on disk arrays can be easily replicated to remote sites where standby servers of the same HW type can boot quickly, minimizing the negative effect a disaster can have to the business.
* Snapshots – Boot images in shapshots can be quickly reverted back to a point-in-time, saving time and money in rebuilding a server from scratch.
* Quick deployment of Servers – Master Boot images stored on disk arrays can be easily cloned using Netapp’s FlexClone capabilities providing rapid deployment of additional physical servers.
* Centralized Management – Because the Master image is located in the SAN, upgrades and patches are managed centrally and are installed only on the master boot image which can be then cloned and mapped to the various servers. No more multiple upgrades or patch installs.
* Greater Storage consolidation – Because the boot image resides in the SAN, there is no need to purchase internal drives.
* Greater Protection – Disk arrays provide greater data protection, availability and resiliency features than servers. For example, Netapp’s RAID-DP functionality provides additional protection in the event of a Dual drive failure. RAID-DP with SyncMirror, also protects against disk drive enclosure failure, Loop failure, cable failure, back-end HBA failure or any 4 concurrent drive failures
Having mentioned the advantages, it’s only fair that we also mention the disadvantages which even though are being outnumbered they still exist:
* Complexity – SAN Booting is a more complex process than booting from an internal drive. In certain cases, the troubleshooting process may be a bit more difficult especially if a coredump file can not be obtained.
* Variable Requirements – The requirements and support from array vendor to array vendor will vary and specific configurations may not even be supported. The requirements will also vary based on the type of OS that is being loaded. Always consult with the disk array vendor before you decide to boot from the fabric.
One of the most popular platforms that lends itself to booting from the SAN is VMware ESX server 3.0.0. One reason is that VMware does not support booting from internal IDE or SATA drives. The second reason is that more and more enterprises have started to deploy ESX 3.0.0 on diskless blade servers consolidating hundreds of physical servers into few blades in a single blade chassis with the deployment of VMware’s server virtualization capabilities.
Another point to consider is that every server needs a LUN zoned exclusively for its boot disk, and some vendors license their SAN by zones (like IBM’s DS4000).
Generally, since most VMWare ESX boot images are fairly consistent and can not be shared between servers, you don’t find them booting on SAN much. People prefer to have local disk when possible instead of more expensive (and complicated) SAN boot disk space.