Datasheet

Lowe c01.indd V3 - 08/11/2011 Page 14
14
|
CHAPTER 1 INTRODUCING VMWARE VSPHERE 5
vSphere HA Improvements in vSphere 5
vSphere HA has received a couple of notable improvements since vSphere 4.0. First, the scalabil-
ity of vSphere HA has been signifi cantly improved; you can now run up to 512 VMs per host (up
from 100 in earlier versions) and 3,000 VMs per cluster (up from 1,280 in earlier versions). Second,
vSphere HA now integrates more closely with vSphere DRS’s intelligent placement functionality,
giving vSphere HA greater ability to restart VMs in the event of a host failure. The third and perhaps
most signifi cant improvement is the complete rewrite of the underlying architecture for vSphere
HA; this entirely new architecture, known as Fault Domain Manager (FDM), eliminates many of
the constraints found in earlier versions of VMware vSphere.
By default, vSphere HA does not provide failover in the event of a guest OS failure, although
you can confi gure vSphere HA to monitor VMs and restart them automatically if they fail to
respond to an internal heartbeat. This feature is called VM Failure Monitoring, and it uses a
combination of internal heartbeats and I/O activity to attempt to detect if the guest OS inside a
VM has stopped functioning. If the guest OS has stopped functioning, the VM can be restarted
automatically.
With vSphere HA, it’s important to understand that there will be an interruption of service. If
a physical host fails, vSphere HA restarts the VM, and during that period of time while the VM
is restarting, the applications or services provided by that VM are unavailable. For users who
need even higher levels of availability than can be provided using vSphere HA, vSphere Fault
Tolerance (FT), which is described in the next section, can help.
VSPHERE FAULT TOLERANCE
For users who require even greater levels of high availability than vSphere HA can provide,
VMware vSphere has a feature known as vSphere Fault Tolerance (FT).
As I described in the previous section, vSphere HA protects against unplanned physical
server failure by providing a way to automatically restart VMs upon physical host failure. This
need to restart a VM in the event of a physical host failure means that some downtime—gener-
ally less than three minutes—is incurred. vSphere FT goes even further and eliminates any
downtime in the event of a physical host failure. Using vLockstep technology that is based on
VMware’s earlier “record and replay” functionality, vSphere FT maintains a mirrored secondary
VM on a separate physical host that is kept in lockstep with the primary VM. Everything that
occurs on the primary (protected) VM also occurs simultaneously on the secondary (mirrored)
VM, so that if the physical host on which the primary VM is running fails, the secondary VM
can immediately step in and take over without any loss of connectivity. vSphere FT will also
automatically re-create the secondary (mirrored) VM on another host if the physical host on
which the secondary VM is running fails, as illustrated in Figure 1.4. This ensures protection for
the primary VM at all times.
c01.indd 14c01.indd 14 9/13/2011 11:46:55 AM9/13/2011 11:46:55 AM