Host Groups in vSphere

Page last updated:

This topic documents the host groups feature in vSphere and describes how an operator can use host groups in Ops Manager to build flexible scalability and high availability into their BOSH deployments. It also describes the configuration of the Distributed Resource Scheduler (DRS) Host-Affinity Rule for host groups.

Overview

vSphere host groups and resource pools are both methods for segmenting and organizing resources within a vSphere cluster. A vSphere cluster is a collection of ESXi servers that run VMs. A resource pool is a collection of vSphere resources in the cluster, while a host group is a subset of ESXi servers within the cluster.

For BOSH deployments on vSphere infrastructure, you associate vSphere clusters with availability zones (AZs). You use Ops Manager to define these AZs for your BOSH Director deployments. In BOSH, AZs provide a mechanism for balancing apps and jobs across resources for resiliency and fault tolerance. Optionally, when defining an AZ, you can specify a resource pool or host group that is associated with the cluster. The association of vSphere resource pools or host groups with AZs allows BOSH to distribute deployments across predefined vSphere resources.

For more information about configuring AZs in BOSH Director, see Create Availability Zones in Configuring BOSH Director on vSphere.

When to Use Host Groups

This section describes the types of deployments that benefit most from using host groups. For multi-use vSphere clusters, it is generally better to use host groups instead of resource pools.

In some cases, configuring host groups does not provide an advantage. In deployments where the underlying clusters are dedicated to a single use, such as running only app containers, it is simpler to not use host groups and rather to use AZs to balance associated jobs and apps.

Stricter Resource Boundaries in Multi-Use Clusters

Host groups are most useful for deployments where the underlying clusters are used by multiple BOSH-managed deployments and you want greater control of cluster resource usage than is provided by resource pools. This greater control of resources is possible because you can use host groups to restrict BOSH VM deployments to a specific set of compute resources.

A resource pool allows both deployments to have access to the total compute capacity of the cluster, but also puts up a protective resource boundary contention between the deployments. The deployments can share the resources, but in the event that resource consumption greatly increases, a resource management engine enforces resource usage limits. In this situation, the engine might deny pool resources to one of the deployments. Depending on the nature of the deployments, denying resources to one of the deployments might not be ideal.

Vertical Scaling

Host groups also allow you to scale up or down the number of ESXi hosts used by your AZ. They also allow you to scale resources without forcing BOSH to redeploy its AZs.

For example, with host groups, you can begin by associating a single server from a cluster with an AZ. When one of the deployments requires more resources, instead of updating AZs or tuning resource pools, you can move additional servers from the existing cluster into the host group. This prevents disruption to the BOSH deployments.

For more information on using host groups in scaling platforms, see Growth Beyond Minimal Viable Platform in the Tanzu Architecture for Dell EMC VxRail (TA4V) documentation set.

DRS Host-Affinity Rules and Stretched Clusters

When configuring host groups, configure the host group’s Distributed Resource Scheduler (DRS) Host-Affinity Rule to SHOULD. This configuration allows VMs to start up in a new host group and AZ in the event that an AZ fails or in the event that you want to scale up the number of VM instances for a job.

To illustrate the reason behind this configuration, consider a deployment where the Host-Affinity Rule is set to MUST. The MUST rule requires that each VM is deployed to its associated host group. If you have a three-instance job, then BOSH deploys one instance to each host group and AZ. If you add a fourth instance and the rule is set to MUST, vSphere will not allow that fourth VM to turn on in order to achieve DRS separation.

In deployments that use stretched clusters, configuring the DRS Host-Affinity Rule to SHOULD is especially important for ensuring high availability in the event that an AZ fails.

You configure this rule when setting the host group for an AZ in BOSH Director. See Step 4: Create Availability Zones in Configuring BOSH Director on vSphere.

For more information about DRS Host-Affinity Rules, see VM-Host Affinity Rules in the VMware vSphere Product Documentation.