Configuring vSphere HA, Admission Control, Datastore Heart beating

Here i will let you know about Configuring vSphere HA

  1. Admission Control and Admission Control Policy.
  2. VM Options.
  3. VM Monitoring.
  4. Datastore Heart beating.

1. Admission Control:– In this admission control we have two settings.

i) Enable: Disallows the VMs to be Power ON that violates the availability constraints.

ii) Disable: Allow VM to be powered ON that violate the availability constraints.

  Over-commitment in a vSphere HA- Enabled cluster:-

When admission control setting is set to allow VMs to be powered ON even if they violate availability constraints, you could be in a situation where there is more physical RAM/Memory allocated to VMs than actually exists. This situation is called over-commitment which can lead to poor performance of VMs. Yes your VMs will start but after the host gets massed out, the whole system & all VMs will slow down dramatically. This will increase the amount of time that HA will take to recover the VMs. In normal situation HA will take up-to 20-30 Mints to recover could end up being an hour or even more.

If it is set to Enable:

HA will block the VMs to be Power ON if the cluster is already at the limit of the capacity it could support if one of the ESXi host in the cluster failed (one host out of four identical hosts is equal to 25% of the cluster capacity) as we have already set, the HA will prevent the VMs to be powered on that violate availability constraints because it has resources to protect and HA ensure you that it has sufficient resources preserved for protecting VMs in the event of failure.

In contrary if it is set to Disable:

HA will allow the VMs to be Powered ON even if it violate availability constraints & it continuous to powering IN the VMs until all the cluster resources are allocated. In this case in the event of failure of any ESXi host it may happen that some VMs would not be able to be Power ON because of insufficient resources to power ON all the VMs. HA allowed you to exceed the availability constraints of the cluster.

2. Admission Control Policy

Specify the type of policy that admission control should enforce.

○ Host failure the cluster tolerates: 1

○ Percentage of cluster resources reserved as failover spare capacity:  25% CPU

25% Memory

○ Specify failover Hosts: Hosts failover(Advanced option)

3. Configuring Virtual Machine Options:

When a cluster Host fails HA tries to restart VMs ON the remaining hosts in the cluster. There are cluster default settings & VM settings. Cluster settings can be overrides for a specific VM. We can set as high, low, medium & disabled for a specific VM to be restarted.

Virtual Machine Monitoring: VM monitoring restarts individual VMs if the VMware tools heartbeat are not received within a set of time. Application monitoring restarts the individual VMs if their VMware tools application heartbeat is not received within a set of time. You can set as VM monitoring only or VM & application monitoring.

4. Restart Priority and Order

In vSphere 5.0 new types of virtual machines have been introduced called as Agent virtual machines. These virtual machines typically offers a “Services” to other VMs. This is why these agent VMs have the highest priority to get powered ON as other regular VMs may dependent on them. Example: if agent VM a vSheild Endpoint VM which offers antivirus services to other VMs. Prioritization is done by each host and not globally. Each host that has been requested to initiate restart of VM will restart all the top priority VMs before attempting to restart any other VMs. If in case top priority VMs fails to restart it will retried after a delay. In the meantime, HA will continue powering ON the remaining VMs. Keep in mind that some VMs are dependent on agent VMs. You should document that which regular VM is dependent on which agent VM and also document the process to start-up these services in the right order if automatic restart of agent VM fails.

Besides Agent VM, HA prioritizes the other VM in the following way:

  1. Agent Virtual Machine.
  2. FT secondary VM
  3. VM configured with a restart priority of high.
  4. VM configured with a restart priority of Medium.
  5. VM configured with a restart priority of Low.

It is noted that HA will not place any VMs on the host if the required number of Agent VMs are not running on the host at the time placement is done.

HA Failure Scenario: Host, Guest OS, Application:

1) Host Failure Scenario: HA is able to determine whether the ESXi host is isolated from the network or has crashed. Isolation refers to an ESXi host that does not see N/W traffic coming from the host to the cluster or is separated from management network. If host is crashed then HA is responsible to restart the VMs that were running on the failed host on the remaining hosts that are running perfectly in the cluster.

In every cluster downtime depends on how long it takes whatever is running to restart when the virtual machine is failed over.

2) Guest operating system failure scenario: The HA agent in each individual host monitors VMware tools in each VM running on the host. When the VMs stop sending heartbeats, the guest OS is reset. The VM stays on the same host.

3) Application failure scenario: The agent on each host monitors the application heartbeat running in each VM. When the application fails, the VM on which the application as running is restarted on the same host. Application monitoring requires a third party application monitoring agent designed to work with VM application monitoring.