Architecting a vSphere Compute Platform : Planning Host Deployment : 6.5 vSphere Auto Deploy : 6.5.3 Stateful Compared with Stateless Compute
   
6.5.3 Stateful Compared with Stateless Compute
The concept of a stateless ESXi host was introduced with vSphere 5 along with vSphere Auto Deploy. A stateless host would not under normal operating conditions boot from a disk or other media. Stateless hosts take advantage of the ESXi small memory-resident footprint to boot the system image over the network on every startup or restart. In this context, the stateless host must leverage vSphere Auto Deploy as its deployment mechanism. However, this is the not only option to achieve stateless compute within the ESXi platform. For instance, the Cisco UCS Blade system, when employed with boot from SAN, takes a very different approach to stateless hosts.
Cisco UCS abstracts the logical server from the physical hardware. With this concept of “stateless computing,” each compute node’s hardware does not have a set configuration. MAC addresses, UUIDs, firmware, and BIOS settings for instance, are all configured within UCS manager and stored as part of a service profile, and then applied to the server hardware. This allows for consistent configuration and ease of repurposing of physical equipment. A new service profile can be applied to a physical blade server within a matter of minutes, and includes the following key elements:
LAN addressing (MAC addresses)
SAN addressing (WWPN and WWNN addresses)
Blade firmware versions
Boot order
Network VLANs
Physical port configuration (Ethernet vNICs and vHBAs)
Quality of service (QoS) policy
BIOS versions and parameters
The Cisco service profile concept allows for a significant amount of flexibility and control. You can disassociate the service profile from one server and then associate it with a different blade. The burned-in settings on the new blade, such as UUID and MAC address, are overwritten with the configuration in the service profile. As a result, the change to the server is transparent to your network and the boot image. You do not need to reconfigure any component or application on your network to begin using the new blade.
The concept of abstracting the hardware away from the system image remains the same in both vSphere Auto Deploy and Cisco UCS, but the mechanism of achieving “stateless compute” differs significantly in each architecture.
A stateful installation of the hypervisor boots from a copied installation of the system image on local disk or other stateful media. In a vSphere Auto Deploy architecture, a stateful installation is carried out the first time the server is booted and receives the image. That system image is then copied to the server’s local disk, removable media, or SAN LUN, and the host boots from that installation on all subsequent reboots, not the vSphere Auto Deploy infrastructure. This is typically achieved by modifying the server’s BIOS so that the first boot attempt was from local media and the second a PXE boot. The patching of stateful hosts must be carried out using conventional methods such as VMware vSphere Update Manager™ with the continued risk of configuration drift within the environment.