6.7
Table Of Contents
- vSphere Availability
- Contents
- About vSphere Availability
- Business Continuity and Minimizing Downtime
- Creating and Using vSphere HA Clusters
- Providing Fault Tolerance for Virtual Machines
- How Fault Tolerance Works
- Fault Tolerance Use Cases
- Fault Tolerance Requirements, Limits, and Licensing
- Fault Tolerance Interoperability
- Preparing Your Cluster and Hosts for Fault Tolerance
- Using Fault Tolerance
- Best Practices for Fault Tolerance
- Legacy Fault Tolerance
- Troubleshooting Fault Tolerant Virtual Machines
- Hardware Virtualization Not Enabled
- Compatible Hosts Not Available for Secondary VM
- Secondary VM on Overcommitted Host Degrades Performance of Primary VM
- Increased Network Latency Observed in FT Virtual Machines
- Some Hosts Are Overloaded with FT Virtual Machines
- Losing Access to FT Metadata Datastore
- Turning On vSphere FT for Powered-On VM Fails
- FT Virtual Machines not Placed or Evacuated by vSphere DRS
- Fault Tolerant Virtual Machine Failovers
- vCenter High Availability
- Plan the vCenter HA Deployment
- Configure the Network
- Configure vCenter HA With the Basic Option
- Configure vCenter HA With the Advanced Option
- Manage the vCenter HA Configuration
- Set Up SNMP Traps
- Set Up Your Environment to Use Custom Certificates
- Manage vCenter HA SSH Keys
- Initiate a vCenter HA Failover
- Edit the vCenter HA Cluster Configuration
- Perform Backup and Restore Operations
- Remove a vCenter HA Configuration
- Reboot All vCenter HA Nodes
- Change the Appliance Environment
- Collecting Support Bundles for a vCenter HA Node
- Troubleshoot Your vCenter HA Environment
- Patching a vCenter High Availability Environment
- Using Microsoft Clustering Service for vCenter Server on Windows High Availability
The first way you can implement network redundancy is at the NIC level with NIC teaming. Using a team
of two NICs connected to separate physical switches improves the reliability of a management network.
Because servers connected through two NICs (and through separate switches) have two independent
paths for sending and receiving heartbeats, the cluster is more resilient. To configure a NIC team for the
management network, configure the vNICs in vSwitch configuration for Active or Standby configuration.
The recommended parameter settings for the vNICs are:
n
Default load balancing = route based on originating port ID
n
Failback = No
After you have added a NIC to a host in your vSphere HA cluster, you must reconfigure vSphere HA on
that host.
In most implementations, NIC teaming provides sufficient heartbeat redundancy, but as an alternative you
can create a second management network connection attached to a separate virtual switch. Redundant
management networking allows the reliable detection of failures and prevents isolation or partition
conditions from occurring, because heartbeats can be sent over multiple networks. The original
management network connection is used for network and management purposes. When the second
management network connection is created, vSphere HA sends heartbeats over both management
network connections. If one path fails, vSphere HA still sends and receives heartbeats over the other
path.
Note Configure the fewest possible number of hardware segments between the servers in a cluster. The
goal being to limit single points of failure. Also, routes with too many hops can cause networking packet
delays for heartbeats, and increase the possible points of failure.
Using IPv6 Network Configurations
Only one IPv6 address can be assigned to a given network interface used by your vSphere HA cluster.
Assigning multiple IP addresses increases the number of heartbeat messages sent by the cluster's
master host with no corresponding benefit.
Best Practices for Interoperability
Observe the following best practices for allowing interoperability between vSphere HA and other features.
vSphere HA and Storage vMotion Interoperability in a Mixed Cluster
In clusters where ESXi 5.x hosts and ESX/ESXi 4.1 or earlier hosts are present and where Storage
vMotion is used extensively or Storage DRS is enabled, do not deploy vSphere HA. vSphere HA might
respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the
one on which the virtual machine was running before the failure. A problem can occur if, at the time of
failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.x host, and vSphere
HA restarts the virtual machine on a host with a version earlier than ESXi 5.0. While the virtual machine
might power-on, any subsequent attempts at snapshot operations might corrupt the vdisk state and leave
the virtual machine unusable.
vSphere Availability
VMware, Inc. 46