The following is an excerpt from my “What’s New in VMware vSphere 5.1 – Platform” white paper that introduces the new Auto Deploy Stateless Caching and Stateful Install modes. You can download the white paper from here.
vSphere 5.0 introduced VMware vSphere Auto Deploy, a new way to rapidly deploy new vSphere hosts. With Auto Deploy, the vSphere host PXE boots over the network and is connected to an Auto Deploy server, where the vSphere host software is provisioned directly into the host’s memory. After the software has been installed on the host, it is connected to the VMware® vCenter™ Server (vCenter) and configured using a host profile.
Auto Deploy significantly reduces the amount of time required to deploy new vSphere hosts. And because an Auto Deploy host runs directly from memory, there is no requirement for a dedicated boot disk. This not only provides cost savings, because there is no need to allocate boot storage for each host, but it also can simplify the SAN configuration, because there is no need to provision and zone LUNs each time a new host is deployed. In addition, because the host configuration comes from a host profile there is no need to create and maintain custom pre- and postinstall scripts.
Along with the rapid deployment, cost savings and simplified configuration, Auto Deploy provides the following benefits:
• Each host reboot is comparable to a fresh install. This eliminates configuration drift.
• With no configuration drift between vSphere hosts, less time will be spent troubleshooting and diagnosing configuration issues.
• Simplified patching and upgrading. Applying updates is as easy as creating a new image profile, updating the corresponding rule on the Auto Deploy server and rebooting the hosts. In the unlikely event you must remove an update, reverting back to the previous image profile is also easy: 1) Reupdate the rule to assign the original image profile and 2) do another reboot.
NOTE: Because an Auto Deploy host runs directly from memory, it often is referred to as being “stateless.” This is because the host state (i.e., configuration) that is normally stored on a boot disk comes from the vCenter Host Profile.
In vSphere 5.0 Auto Deploy supported only one operational mode, which was referred to as “stateless” (also known as “diskless”). vSphere 5.1 extends Auto Deploy with the addition of two new operational modes: “Stateless Caching” and “Stateful Installs”.
Stateless Caching Mode
The Auto Deploy stateless caching mode was implemented to help address availability concerns with the PXE boot infrastructure and Auto Deploy server. With stateless hosts, if the PXE boot failed, or if the Auto Deploy server was unavailable, the host would not be able to boot until the outage was corrected. However, with stateless caching, if a host cannot boot due to a problem with the PXE environment or Auto Deploy server, it is able to fall back to booting off a cached image saved to a dedicated boot device. After booting from the cached image, the administrator is able to use the host to help troubleshoot and identify why the PXE boot might have failed.
The stateless caching mode is very similar to the stateless mode, in that during normal operation the host PXE boots from the Auto Deploy server. However, the difference is that with stateless caching, an additional step is taken where the software image running in memory is cached (saved) to a dedicated boot device (local disk, SAN, USB). This cached image then acts as a backup from which the host can boot in the event there is a problem with the PXE boot or Auto Deploy infrastructure.
Unlike the stateless mode, stateless caching requires a dedicated boot device for each vSphere host. In addition, users must configure the host’s BIOS settings to first attempt to boot over the network and, if that fails, to fall back to booting from disk.
With stateless caching, if there is a localized outage that affects the PXE boot infrastructure (DHCP or TFTP server) or the Auto Deploy server but does not affect the vCenter Server instance, by using the cached image the host will be able to boot and the administrator able to manually reconnect to the vCenter Server.
Note: Stateless caching does not protect against a vCenter Server failure. Always protect a vCenter Server by running it in a vSphere cluster protected by VMware vSphere High Availability (VMware HA) or VMware vCenter server Heartbeat (vCenter Server Heartbeat).
Stateful Install Mode
Auto Deploy stateful install mode enables administrators to leverage the Auto Deploy infrastructure to provision new vSphere hosts. With stateful install, users perform a one-time PXE boot of a new host from the Auto Deploy server. Following the one-time PXE boot, all subsequent reboots will take place from the dedicated boot disk.
Setting up stateful installs is similar to configuring stateless caching. The difference is the BIOS boot order configured on the server. Where stateless caching is set to boot from the network first and fall back to the local disk only when the PXE boot fails, with stateful installs the host is configured to always try to boot from the local disk first and boot from the network only when no boot image can be found on the disk. With Auto Deploy stateful install mode, a new host will perform an initial one-time PXE boot using the Auto Deploy infrastructure to configure the host. After the initial boot, all subsequent reboots take place using the boot device.
With stateful installs, the Auto Deploy infrastructure is being leveraged as a provisioning tool similarly to how scripted installations or kickstart might be used. The advantage to Auto Deploy stateful install is that users are able to rapidly deploy hosts without having the need to create and maintain custom scripts. The software to be installed is determined using the Auto Deploy rules engine, and the host is configured using the vCenter host profiles and therefore doesn’t rely on external scripts.
With stateful installs, users leverage the Auto Deploy infrastructure to provision new hosts but forgo most of the benefits of stateless or stateless caching because after the vSphere hosts have been deployed, they must be maintained, patched and updated individually.
