Architecting a vSphere Compute Platform : Planning Host Deployment : 6.5 vSphere Auto Deploy : 6.5.1 vSphere Auto Deploy Architecture
   
6.5.1 vSphere Auto Deploy Architecture
The vSphere Auto Deploy architecture can be broken down into the components illustrated in the following figure.
Figure 19. Auto Deploy Components
 
vSphere Auto Deploy components include:
• vSphere Auto Deploy server – This component serves images and host profiles to ESXi hosts. The vSphere Auto Deploy server is at the heart of the vSphere Auto Deploy infrastructure.
• Auto Deploy rules engine – This component tells the vSphere Auto Deploy server which image profile and which host profile to assign to a particular host. Administrators use the vSphere PowerCLI to define the rules that assign image profiles and host profiles to hosts. These rules are organized into the following categories:
o Active rule set – Ready to be deployed to physical hosts.
o Working rules set – Rule testing that takes place prior to deployment.
• Image profiles – Define the set of VIBs to boot ESXi hosts with:
o Default images – VMware and VMware partners make image profiles and VIBs available in public depots. Use the VMware vSphere ESXi Image Builder CLI to examine the depot, and the vSphere Auto Deploy rules engine to specify which image profile to assign to which host.
o Custom images – VMware customers can create a custom image profile based on the public image profiles and VIBs in the depot, and apply that image profile to the host.
• Host profiles – Maintained by the vCenter Server and defined by machine-specific configurations, such as networking or storage setup. Administrators create host profiles by using the host profile user interface with the vSphere Web Client. You can create a host profile for a reference host and apply that host profile to other hosts in your environment for a consistent configuration.
• Host customization – Referred to as an answer file in previous releases of vSphere Auto Deploy. Stores information that the user provides when a host profile is applied to the host. Host customization might contain an IP address or other unique information.
The use of vSphere Auto Deploy in the service provider data center must be considered carefully because a number of other design decisions regarding infrastructure and hardware are dependent on it. These design decisions might differ significantly if vSphere Auto Deploy is adopted. As part of this design review, consider the advantages and drawbacks described in the following table.
Table 12. Advantages and Drawbacks of vSphere Auto Deploy
Advantages
Drawbacks
Patch management – Provides ease of deployment and patch management of large scale environments:
• Ability to re-deploy new versions of ESXi to a large number of ESXi hosts. Increases refresh agility when managing many ESXi hosts.
• Uses stateless ESXi hosts, memory is resident, and there is no need to have dedicated hard disks/volumes to run ESXi hosts. (Although some sort of storage is required for stateless caching.)
Complexity – Additional complexity when deploying to small number of servers.
 
Eliminate configuration drift – By sharing a standard ESXi image profile across multiple hosts, all ESXi hosts are running the same ESXi version. In addition, each time a host is rebooted, it is like performing a fresh install of ESXi.
 
Management – Managed using vSphere PowerCLI, which might be less familiar to the customer (although a fling is available).
• Heavily dependent on knowledge of vCenter Server host profiles and PowerCLI.
• Heavily dependent on vCenter Server, which poses recoverability issues in the event of a site failure. (Use of vCenter Server heartbeat is supported.)
• If vCenter Server is virtualized, the vCenter Server cluster of ESXi hosts must be deployed using installable ESXi. This cluster must be installed, patched, and updated differently from the vSphere Auto Deploy hosts. VMware recommends that vSphere Auto Deploy is not used when provisioning ESXi hosts in the case where a management cluster will be used to host the vCenter Server. The management cluster running vCenter Server must be configured with stateful booting.
• VMware recommends installing vSphere Auto Deploy on a dedicated server. For each vCenter Server, a dedicated vSphere Auto Deploy server is required.
Reduced storage costs – Because vSphere Auto Deploy installs directly into the host's memory, there is no need to dedicate a boot disk for each server. This not only saves money when purchasing new hardware and storage, but when booting from SAN, it helps to simplify the storage architecture by eliminating the need to map dedicated LUNs to each ESXi host.
 
Additional Infrastructure – vSphere Auto Deploy introduces several additional “mission critical” applications to the infrastructure management stack, such as TFTP, DHCP, PXE and vSphere PowerCLI. Issues with blade or access switching infrastructure might cause problems in a disaster recovery scenario after powering off and powering on the host.
vSphere Auto Deploy might pose a single point of failure if the image profile is incorrectly configured and the PXE and DHCP architecture is unavailable. In this case, the servers would not be able to boot. (The vSphere Auto Deploy server can be protected with vCenter Server heartbeat.)
Two options available in vSphere Auto Deploy can be configured to mitigate against this risk:
• Stateless caching – Caches the image locally on the ESXi host, ready for an event where the PXE, DHCP, or vCenter Server architecture is not available.
• Stateful Install – Installs the ESXi image in a stateful manner on the local disks, removable media or SAN LUN that will act in the same way as if it were installed manually.
Both options negate some of the benefits of vSphere Auto Deploy by having to maintain local storage for cache/installation, but they reduce risk to the architecture.
vSphere Auto Deploy uses the PXE network boot feature of an ESXi host and is fully dependent on an operational DHCP and a TFTP server.
Additional DHCP scope options are required when configuring vSphere Auto Deploy:
• 066 Boot Server Host Name (address of the TFTP server)
• 067 Boot File Name (iPXE binary will be used to boot the ESXi hosts)
vSphere Auto Deploy uses a PXE boot infrastructure that supports only IPv4. You can use vSphere Auto Deploy in a mixed IPv4/IPv6 environment or an IPv4-only environment, but not in an IPv6-only environment.
Fast server provisioning – Deploying a new ESXi host is as simple as enabling PXE boot and powering on a new server. The vSphere Auto Deploy server identifies the new server, assigns an appropriate ESXi image profile and host profile, and places the server in the correct vCenter Server folder or cluster.
Consider the following design points:
• The vCenter Server that provisions vSphere Auto Deploy hosts must not be dependent on vSphere Auto Deploy.
• Keeping the management cluster separate from the vSphere Auto Deploy infrastructure facilitates role-based access control.
• It is easy to grow the environment if additional instances of vCenter Server and the vSphere Auto Deploy server are needed.
vSAN is not supported on a stateless host.
 
vSphere Auto Deploy stateful deployment – vSphere Auto Deploy can also be used to provision an ESXi host and set up a host profile that causes the host to store the ESXi image and configuration on the local disk, a remote disk (boot from SAN), or a USB drive. Subsequently, the ESXi host boots from this local image. vSphere Auto Deploy no longer provisions the host. This process is similar to performing a scripted installation. With a scripted installation, the script provisions a host and the host then boots from disk. In this case, vSphere Auto Deploy provisions a host and the host then boots from disk.