Boot from SAN vSphere

Boot from SAN vSphere



Boot from SAN is the practice of booting a server from your SAN array instead of local disks. It�s a great feature for a server environment, as the most common failure point in any server is typically the hard drive(s). By shifting that risk to a SAN, which is already highly redundant, monitored, and cared for, the thought is that you better protect your server infrastructure. Additional benefits for converged blade infrastructure (such as Cisco UCS or HP BladeSystem) is the ability to make a blade stateless � the blade can be replaced while still retaining its host identity, as it simply reaches out to the SAN to boot up.

Having vSphere hosts that boot from SAN offers the unique opportunity to render any underlying blade hardware completely stateless. That is, a blade that is acquiring its personality from the blade infrastructure no longer has any unique identifiers or hosted information that keeps it tied down to the vSphere host personality. These identifiers are typically the Server�s ID (such as a UUID), any MAC addresses, and World Wide Names (WWN) of the HBAs.
By utilizing SAN storage for the boot partition, a blade can be powered down, swapped out for another blade, powered on, and then re-appear as the vSphere host in vCenter. There are a variety of reasons that this can be of benefit:
  1. The most commonly highlighted benefit is overcoming hardware failure. If a blade fails in such a way that it needs replacing, or even if just the disk drives fail, no re-work needs to be done to re-image the blade with the vSphere hypervisor. While installing vSphere is not a huge task in of itself, it still introduces several opportunities for human error during the configuration.
  2. An additional benefit is streamlining hardware refresh cycles. As blades hit an age where the business feels that it warrants replacement, the process is to simply swap out the blade, confirm the new hardware in the environment, and power on. This allows for a technician with lower levels of access to the environment to handle a refresh cycle, or even a �gold hands� type remote assistance if using a co-location.


Consolidation of the boot partitions to a SAN can increase efficiency in the current array utilization and reduce costs in the blades. Each blade no longer requires a pair of drives, be that Solid State Drives (SSDs), SD cards, or traditional spinning SATA or SAS drives. The hypervisor�s boot volumes are typically in a state of relative inactivity, making it easy to stack a higher number of boot LUNs on a small storage pool in the array, accounting only for boot storms and data protection (such as disk parity).
Overall, this reduces the disk footprint in the data center, which has an added bonus of potentially reducing cooling and power costs. And, because a large number of parts that commonly fail have been removed from the equation, the amount of support related incidents to identify failed drives, open warranty requests, and have technicians perform replacements are reduced.

Comments

Popular posts from this blog

Bodhi Linux 1 1 0 Ubuntu and Enlightenment based Promising Linux distribution

Book Review Practical Data Analysis by Hector Cuesta

Bodhi Linux 3 0 0 Release Candidate 1