Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

CloudStack HA Service provides high availability to virtual machines (VMs) managed by CloudStack.   It works with CloudStack orchestration to detect VM and hypervisor host failures and restart VMs to ensure the high availability of VMs.  CloudStack HA is designed to operate within one zone and is confined to host and VM failures only.  It does not offer availability over network, storage or complete zone failures.

...

CloudStack HA is designed to make sure HA does not corrupt the VMs.  Workloads Workloads requiring HA are not run on ethereal VMs and, therefore, the data on these VMs must not be corrupted by the HA process.  CloudStack HA prioritizes VM integrity over VM availability.  In In conditions where CloudStack HA cannot safely restart a VM, it asks the administrator to be the arbitrator of whether it is safe to restart a VM.

...

Currently, two types of host investigators have been implemented: network ping investigation and hypervisor specific investigation.  Network ping investigation sends a PingTestCommand to a neighboring hypervisor host which carries out a network ping and network arping on the IP address of the hypervisor host in question.   If the hypervisor host responds to the network ping or arping, the host is consider to be alive and no HA is performed.  If there is no response, the investigator returns that it cannot detect the status of the host.   Note that it cannot return that the host is down because network ping and arping responses may be blocked and does not accurately indicate that the host is down.

If the network ping investigation returns that it cannot detect the status of the host, CloudStack HA then relies on the hypervisor specific investigation.  For VmWareVMware, there is no such investigation as the hypervisor host handles its own HA.   For XenServer and KVM, CloudStack HA deploys a monitoring script that writes the current timestamp on to a heartbeat file on shared storage.  If the timestamp cannot be written, the hypervisor host self-fences by rebooting itself.  For these two hypervisors, CloudStack HA sends a CheckOnHostCommand to a neighboring hypervisor host that shares the same storage.   The neighbor then checks on the heartbeat file on shared storage and see if the heartbeat is no longer being written.  If the heartbeat is still being written, the host reports that the host in question is still alive.   If the heartbeat file’s timestamp is lagging behind, after an acceptable timeout value, the host reports that the host in question is down and HA is started on the VMs on that host.

...

global settingdescriptiondefault value

stop.retry.interval

The time in seconds between retries to stop or destroy a VM.

600
restart.retry.intervalThe time (in seconds) between retries to restart a VM.600

time.between.cleanup

The time in seconds to wait before the cleanup thread runs for the different HA-Worker-Threads. The cleanup thread finds all the work items that were successful and is now ready to be purged from the the database (table: op_ha_work).86400
time.between.failuresTime in seconds before try to cleanup all the VMs which are registered for the HA event that were successful and are now ready to be purged.3600

max.retries

The number of times to try a restart for the different Work-Types:

Migrating - VMs off of a host, Destroy - a VM,
Stop - a VM for storage pool migration purposes,
CheckStop - checks if a VM has been stopped, ForceStop - force a VM to stop even if the states don't allow it,
Destroy - a VM and HA - restart a VM.

5

time.to.sleep

Time in seconds to sleep if no work items are found.

60

ha.workers

The number of High-Availability worker threads to spin off to do the processing.

5

Manual Intervention

As part of the CloudStack HA design, CloudStack HA must not restart a VM if it cannot be sure that it can be done safely.  In those cases, the VM stays in a transitional state.  In those cases, the system administrator can manually intervene by checking to make sure the VM or the host the VM is shutdown, and then calling CloudStack to stop the VM with forced stop flag set to true.  When called in this manner, CloudStack attempts to stop the VM but will continue to release resources even if any of the operations to the hypervisor host cannot be completed.  After doing this, CloudStack HA will stop any attempt to restart the VM and it can be restarted by the administrator. 

...