Information Technology Reference
In-Depth Information
have 2 or even 4 vCPUs. Because vSphere doesn't know in advance which host will fail and
which VMs will be affected by that failure (naturally), vSphere HA needed a way to establish
a “least common denominator” to express the overall capacity of the cluster. Once that overall
capacity of the cluster can be expressed, vSphere HA can set aside the appropriate amount of
resources to protect against the coni gured number of host failures.
Here's how slots and slot sizes work. First, vSphere HA examines all the VMs in the cluster
to determine the largest values for reserved memory and reserved CPU. For example, if one of
the VMs in the cluster has a 2 GB memory reservation but all others do not have a memory res-
ervation, vSphere HA will use 2 GB as the value for calculating slots based on memory. In the
same fashion, if one VM has a reservation for 2 GHz of CPU capacity but all the other VMs don't
have any reservation value, it will use 2 GHz as the value. Basically, vSphere HA constructs the
least common denominator as a VM with the largest memory reservation and the largest CPU
reservation.
What If There Are No Reservations?
vSphere HA uses reservations, described in Chapter 11, to calculate the slot size. If no VMs have
reservations for CPU or memory, vSphere will use the default value of 32 MHz for CPU to calculate
slot size. For memory, vSphere HA will use the largest memory overhead value when calculating
the slot size. h ese settings can be seen, grayed out, in Figure 7.18.
Once it has constructed the least common denominator, vSphere HA then calculates the
total number of slots that each ESXi host in the cluster could support. Then it determines how
many slots the cluster could support if the host with the largest number of slots were to fail (a
worst-case scenario). vSphere HA performs these calculations and comparisons for both CPU
and memory and then uses the most restrictive result. If vSphere HA calculated 50 slots for
memory and 100 slots for CPU, then 50 is the number vSphere HA uses. VMs are then assigned
to the slots to determine how many slots are used and how many slots are free, and Admission
Control uses this to determine whether additional VMs can be powered on (enough slots
remain) or cannot be powered on (not enough slots are available).
The slot-size calculation algorithm just described can result in unexpected settings when
you have an unbalanced cluster. An
unbalanced
cluster
is a cluster with dramatically different
ESXi hosts, such as a host with 12 GB of RAM along with an ESXi host with 96 GB of RAM in
the same cluster. You might also have an unbalanced cluster if you have dramatically different
resource reservations assigned to VMs in the cluster (for example, one VM with an 8 GB mem-
ory reservation while all the other VMs use much less than that). While you can i ne-tune the
behavior of the vSphere HA slot-calculation mechanism using advanced settings, it's generally
not recommended. For these situations, you have a couple of options:
You could place similarly sized VMs (or similarly sized hosts) in their own cluster.
◆
You could use percentage-based availability constraints (via the Percentage Of Cluster
Resources Reserved As Failover Spare Capacity setting) instead of host failures or
failover hosts.
◆
Using reservations on resource pools might be another way to help alleviate the impact to
slot size calculations, if the reservations are necessary. Refer to Chapter 11 for more details on
both reservations and resource pools.
The next major area of coni guration for vSphere HA is VM options.
