What is it Good For?
vMotion is limited to hosts
of a particular CPU architecture. This is the familiar Intel vs. AMD boundary
that needs to be identified on a cluster by cluster basis. Within those
CPU-bound clusters, however, a VM can have problems if vMotioned to a host with
a differing set of CPU instructions. From the VM’s point of view, the CPU’s
instruction sets have effectively changed instantly, either gaining or losing
certain instruction sets based on the underlying hardware. This could have
disastrous effects on the VM and it’s workload.
EVC is designed to allow a
boundary, or level, to be set at the cluster level. This level is effectively a
definition of CPU instruction sets that will be “allowed” within the cluster.
Hosts with CPUs that can meet this level, by having all of these instruction
sets available, can be added to the cluster. Hosts with CPUs that cannot meet
this level cannot be added to the cluster. This provides a level of consistency
for the VM’s so that we avoid the risk of impacting their workloads. This
provides the best of both worlds. There are still some higher level
constraints, such as Intel vs. AMD, however we end up with much more
flexibility in our cluster hardware design.
Best Practice:
A CPU baseline should be
established when any new cluster is created by choosing the proper CPUs and
enabling EVC. Remember that EVC means that you can’t move backwards through CPU
generations but that you can always move forwards (often without impacting running
VMs). The performance impact of EVC in and of itself is practically
non-existent. The longer you go without
enabling EVC on a cluster the harder it will be to take a full cluster outage
to enable EVC.
So always turn on EVC on your new empty clusters and plan
an EVC Enable Party for your existing clusters sooner, rather than later.
No comments:
Post a Comment