-[[chapter-ha-manager]]
+[[chapter_ha_manager]]
ifdef::manvolnum[]
ha-manager(1)
=============
-include::attributes.txt[]
:pve-toplevel:
NAME
ifndef::manvolnum[]
High Availability
=================
-include::attributes.txt[]
-endif::manvolnum[]
-ifdef::wiki[]
:pve-toplevel:
-endif::wiki[]
+endif::manvolnum[]
Our modern society depends heavily on information provided by
computers over the network. Mobile devices amplified that dependency,
software:
* Use reliable ``server'' components
-
++
NOTE: Computer components with same functionality can have varying
reliability numbers, depending on the component quality. Most vendors
sell components with higher reliability as ``server'' components -
times of about 2 minutes, so you can get no more than 99.999%
availability.
+
Requirements
------------
+You must meet the following requirements before you start with HA:
+
* at least three cluster nodes (to get reliable quorum)
* shared storage for VMs and containers
* hardware redundancy (everywhere)
+* use reliable “server” components
+
* hardware watchdog - if not available we fall back to the
linux kernel software watchdog (`softdog`)
* optional hardware fencing devices
+[[ha_manager_resources]]
Resources
---------
How It Works
------------
-This section provides an in detail description of the {PVE} HA-manager
-internals. It describes how the CRM and the LRM work together.
-
-To provide High Availability two daemons run on each node:
+This section provides a detailed description of the {PVE} HA manager
+internals. It describes all involved daemons and how they work
+together. To provide HA, two daemons run on each node:
`pve-ha-lrm`::
-The local resource manager (LRM), it controls the services running on
-the local node.
-It reads the requested states for its services from the current manager
-status file and executes the respective commands.
+The local resource manager (LRM), which controls the services running on
+the local node. It reads the requested states for its services from
+the current manager status file and executes the respective commands.
`pve-ha-crm`::
-The cluster resource manager (CRM), it controls the cluster wide
-actions of the services, processes the LRM results and includes the state
-machine which controls the state of each service.
+The cluster resource manager (CRM), which makes the cluster wide
+decisions. It sends commands to the LRM, processes the results,
+and moves resources to other nodes if something fails. The CRM also
+handles node fencing.
+
.Locks in the LRM & CRM
[NOTE]
This all gets supervised by the CRM which holds currently the manager master
lock.
+
+Service States
+~~~~~~~~~~~~~~
+
+[thumbnail="gui-ha-manager-status.png"]
+
+The CRM use a service state enumeration to record the current service
+state. We display this state on the GUI and you can query it using
+the `ha-manager` command line tool:
+
+----
+# ha-manager status
+quorum OK
+master elsa (active, Mon Nov 21 07:23:29 2016)
+lrm elsa (active, Mon Nov 21 07:23:22 2016)
+service ct:100 (elsa, stopped)
+service ct:102 (elsa, started)
+service vm:501 (elsa, started)
+----
+
+Here is the list of possible states:
+
+stopped::
+
+Service is stopped (confirmed by LRM). If the LRM detects a stopped
+service is still running, it will stop it again.
+
+request_stop::
+
+Service should be stopped. The CRM waits for confirmation from the
+LRM.
+
+started::
+
+Service is active an LRM should start it ASAP if not already running.
+If the Service fails and is detected to be not running the LRM
+restarts it
+(see xref:ha_manager_start_failure_policy[Start Failure Policy]).
+
+fence::
+
+Wait for node fencing (service node is not inside quorate cluster
+partition). As soon as node gets fenced successfully the service will
+be recovered to another node, if possible
+(see xref:ha_manager_fencing[Fencing]).
+
+freeze::
+
+Do not touch the service state. We use this state while we reboot a
+node, or when we restart the LRM daemon
+(see xref:ha_manager_package_updates[Package Updates]).
+
+migrate::
+
+Migrate service (live) to other node.
+
+error::
+
+Service is disabled because of LRM errors. Needs manual intervention
+(see xref:ha_manager_error_recovery[Error Recovery]).
+
+
Local Resource Manager
~~~~~~~~~~~~~~~~~~~~~~
quorum the node cannot reset the watchdog. This will trigger a reboot
after the watchdog then times out, this happens after 60 seconds.
+
Configuration
-------------
-The HA stack is well integrated in the Proxmox VE API2. So, for
-example, HA can be configured via `ha-manager` or the PVE web
-interface, which both provide an easy to use tool.
+The HA stack is well integrated into the {pve} API. So, for example,
+HA can be configured via the `ha-manager` command line interface, or
+the {pve} web interface - both interfaces provide an easy way to
+manage HA. Automation tools can use the API directly.
-The resource configuration file can be located at
-`/etc/pve/ha/resources.cfg` and the group configuration file at
-`/etc/pve/ha/groups.cfg`. Use the provided tools to make changes,
-there shouldn't be any need to edit them manually.
+All HA configuration files are within `/etc/pve/ha/`, so they get
+automatically distributed to the cluster nodes, and all nodes share
+the same HA configuration.
-Node Power Status
------------------
-If a node needs maintenance you should migrate and or relocate all
-services which are required to run always on another node first.
-After that you can stop the LRM and CRM services. But note that the
-watchdog triggers if you stop it with active services.
+Resources
+~~~~~~~~~
-Package Updates
----------------
+[thumbnail="gui-ha-manager-resources-view.png"]
-When updating the ha-manager you should do one node after the other, never
-all at once for various reasons. First, while we test our software
-thoughtfully, a bug affecting your specific setup cannot totally be ruled out.
-Upgrading one node after the other and checking the functionality of each node
-after finishing the update helps to recover from an eventual problems, while
-updating all could render you in a broken cluster state and is generally not
-good practice.
+The resource configuration file `/etc/pve/ha/resources.cfg` stores
+the list of resources managed by `ha-manager`. A resource configuration
+inside that list look like this:
-Also, the {pve} HA stack uses a request acknowledge protocol to perform
-actions between the cluster and the local resource manager. For restarting,
-the LRM makes a request to the CRM to freeze all its services. This prevents
-that they get touched by the Cluster during the short time the LRM is restarting.
-After that the LRM may safely close the watchdog during a restart.
-Such a restart happens on a update and as already stated a active master
-CRM is needed to acknowledge the requests from the LRM, if this is not the case
-the update process can be too long which, in the worst case, may result in
-a watchdog reset.
+----
+<type>: <name>
+ <property> <value>
+ ...
+----
+It starts with a resource type followed by a resource specific name,
+separated with colon. Together this forms the HA resource ID, which is
+used by all `ha-manager` commands to uniquely identify a resource
+(example: `vm:100` or `ct:101`). The next lines contain additional
+properties:
+
+include::ha-resources-opts.adoc[]
+
+Here is a real world example with one VM and one container. As you see,
+the syntax of those files is really simple, so it is even posiible to
+read or edit those files using your favorite editor:
+
+.Configuration Example (`/etc/pve/ha/resources.cfg`)
+----
+vm: 501
+ state started
+ max_relocate 2
+
+ct: 102
+ # Note: use default settings for everything
+----
+
+[thumbnail="gui-ha-manager-add-resource.png"]
+
+Above config was generated using the `ha-manager` command line tool:
+
+----
+# ha-manager add vm:501 --state started --max_relocate 2
+# ha-manager add ct:102
+----
+
+
+[[ha_manager_groups]]
+Groups
+~~~~~~
+
+[thumbnail="gui-ha-manager-groups-view.png"]
+
+The HA group configuration file `/etc/pve/ha/groups.cfg` is used to
+define groups of cluster nodes. A resource can be restricted to run
+only on the members of such group. A group configuration look like
+this:
+
+----
+group: <group>
+ nodes <node_list>
+ <property> <value>
+ ...
+----
+
+include::ha-groups-opts.adoc[]
+
+[thumbnail="gui-ha-manager-add-group.png"]
+
+A commom requirement is that a resource should run on a specific
+node. Usually the resource is able to run on other nodes, so you can define
+an unrestricted group with a single member:
+
+----
+# ha-manager groupadd prefer_node1 --nodes node1
+----
+
+For bigger clusters, it makes sense to define a more detailed failover
+behavior. For example, you may want to run a set of services on
+`node1` if possible. If `node1` is not available, you want to run them
+equally splitted on `node2` and `node3`. If those nodes also fail the
+services should run on `node4`. To achieve this you could set the node
+list to:
+
+----
+# ha-manager groupadd mygroup1 -nodes "node1:2,node2:1,node3:1,node4"
+----
+Another use case is if a resource uses other resources only available
+on specific nodes, lets say `node1` and `node2`. We need to make sure
+that HA manager does not use other nodes, so we need to create a
+restricted group with said nodes:
+
+----
+# ha-manager groupadd mygroup2 -nodes "node1,node2" -restricted
+----
+
+Above commands created the following group configuration fils:
+
+.Configuration Example (`/etc/pve/ha/groups.cfg`)
+----
+group: prefer_node1
+ nodes node1
+
+group: mygroup1
+ nodes node2:1,node4,node1:2,node3:1
+
+group: mygroup2
+ nodes node2,node1
+ restricted 1
+----
+
+
+The `nofailback` options is mostly useful to avoid unwanted resource
+movements during administartion tasks. For example, if you need to
+migrate a service to a node which hasn't the highest priority in the
+group, you need to tell the HA manager to not move this service
+instantly back by setting the `nofailback` option.
+
+Another scenario is when a service was fenced and it got recovered to
+another node. The admin tries to repair the fenced node and brings it
+up online again to investigate the failure cause and check if it runs
+stable again. Setting the `nofailback` flag prevents that the
+recovered services move straight back to the fenced node.
+
+
+[[ha_manager_fencing]]
Fencing
-------
-What is Fencing
-~~~~~~~~~~~~~~~
+On node failures, fencing ensures that the erroneous node is
+guaranteed to be offline. This is required to make sure that no
+resource runs twice when it gets recovered on another node. This is a
+really important task, because without, it would not be possible to
+recover a resource on another node.
+
+If a node would not get fenced, it would be in an unknown state where
+it may have still access to shared resources. This is really
+dangerous! Imagine that every network but the storage one broke. Now,
+while not reachable from the public network, the VM still runs and
+writes to the shared storage.
-Fencing secures that on a node failure the dangerous node gets will be rendered
-unable to do any damage and that no resource runs twice when it gets recovered
-from the failed node. This is a really important task and one of the base
-principles to make a system Highly Available.
+If we then simply start up this VM on another node, we would get a
+dangerous race conditions because we write from both nodes. Such
+condition can destroy all VM data and the whole VM could be rendered
+unusable. The recovery could also fail if the storage protects from
+multiple mounts.
-If a node would not get fenced it would be in an unknown state where it may
-have still access to shared resources, this is really dangerous!
-Imagine that every network but the storage one broke, now while not
-reachable from the public network the VM still runs and writes on the shared
-storage. If we would not fence the node and just start up this VM on another
-Node we would get dangerous race conditions, atomicity violations the whole VM
-could be rendered unusable. The recovery could also simply fail if the storage
-protects from multiple mounts and thus defeat the purpose of HA.
How {pve} Fences
-~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~
-There are different methods to fence a node, for example fence devices which
-cut off the power from the node or disable their communication completely.
+There are different methods to fence a node, for example, fence
+devices which cut off the power from the node or disable their
+communication completely. Those are often quite expensive and bring
+additional critical components into a system, because if they fail you
+cannot recover any service.
-Those are often quite expensive and bring additional critical components in
-a system, because if they fail you cannot recover any service.
+We thus wanted to integrate a simpler fencing method, which does not
+require additional external hardware. This can be done using
+watchdog timers.
-We thus wanted to integrate a simpler method in the HA Manager first, namely
-self fencing with watchdogs.
+.Possible Fencing Methods
+- external power switches
+- isolate nodes by disabling complete network traffic on the switch
+- self fencing using watchdog timers
-Watchdogs are widely used in critical and dependable systems since the
-beginning of micro controllers, they are often independent and simple
-integrated circuit which programs can use to watch them. After opening they need to
-report periodically. If, for whatever reason, a program becomes unable to do
-so the watchdogs triggers a reset of the whole server.
+Watchdog timers are widely used in critical and dependable systems
+since the beginning of micro controllers. They are often independent
+and simple integrated circuits which are used to detect and recover
+from computer malfunctions.
+
+During normal operation, `ha-manager` regularly resets the watchdog
+timer to prevent it from elapsing. If, due to a hardware fault or
+program error, the computer fails to reset the watchdog, the timer
+will elapse and triggers a reset of the whole server (reboot).
+
+Recent server motherboards often include such hardware watchdogs, but
+these need to be configured. If no watchdog is available or
+configured, we fall back to the Linux Kernel 'softdog'. While still
+reliable, it is not independent of the servers hardware, and thus has
+a lower reliability than a hardware watchdog.
-Server motherboards often already include such hardware watchdogs, these need
-to be configured. If no watchdog is available or configured we fall back to the
-Linux Kernel softdog while still reliable it is not independent of the servers
-Hardware and thus has a lower reliability then a hardware watchdog.
Configure Hardware Watchdog
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-By default all watchdog modules are blocked for security reasons as they are
-like a loaded gun if not correctly initialized.
-If you have a hardware watchdog available remove its kernel module from the
-blacklist, load it with insmod and restart the `watchdog-mux` service or reboot
-the node.
+
+By default, all hardware watchdog modules are blocked for security
+reasons. They are like a loaded gun if not correctly initialized. To
+enable a hardware watchdog, you need to specify the module to load in
+'/etc/default/pve-ha-manager', for example:
+
+----
+# select watchdog module (default is softdog)
+WATCHDOG_MODULE=iTCO_wdt
+----
+
+This configuration is read by the 'watchdog-mux' service, which load
+the specified module at startup.
+
Recover Fenced Services
~~~~~~~~~~~~~~~~~~~~~~~
-After a node failed and its fencing was successful we start to recover services
-to other available nodes and restart them there so that they can provide service
-again.
-
-The selection of the node on which the services gets recovered is influenced
-by the users group settings, the currently active nodes and their respective
-active service count.
-First we build a set out of the intersection between user selected nodes and
-available nodes. Then the subset with the highest priority of those nodes
-gets chosen as possible nodes for recovery. We select the node with the
-currently lowest active service count as a new node for the service.
-That minimizes the possibility of an overload, which else could cause an
-unresponsive node and as a result a chain reaction of node failures in the
-cluster.
+After a node failed and its fencing was successful, the CRM tries to
+move services from the failed node to nodes which are still online.
-Groups
-------
+The selection of nodes, on which those services gets recovered, is
+influenced by the resource `group` settings, the list of currently active
+nodes, and their respective active service count.
-A group is a collection of cluster nodes which a service may be bound to.
+The CRM first builds a set out of the intersection between user selected
+nodes (from `group` setting) and available nodes. It then choose the
+subset of nodes with the highest priority, and finally select the node
+with the lowest active service count. This minimizes the possibility
+of an overloaded node.
-Group Settings
-~~~~~~~~~~~~~~
-
-nodes::
-
-List of group node members where a priority can be given to each node.
-A service bound to this group will run on the nodes with the highest priority
-available. If more nodes are in the highest priority class the services will
-get distributed to those node if not already there. The priorities have a
-relative meaning only.
- Example;;
- You want to run all services from a group on `node1` if possible. If this node
- is not available, you want them to run equally splitted on `node2` and `node3`, and
- if those fail it should use `node4`.
- To achieve this you could set the node list to:
-[source,bash]
- ha-manager groupset mygroup -nodes "node1:2,node2:1,node3:1,node4"
-
-restricted::
-
-Resources bound to this group may only run on nodes defined by the
-group. If no group node member is available the resource will be
-placed in the stopped state.
- Example;;
- Lets say a service uses resources only available on `node1` and `node2`,
- so we need to make sure that HA manager does not use other nodes.
- We need to create a 'restricted' group with said nodes:
-[source,bash]
- ha-manager groupset mygroup -nodes "node1,node2" -restricted
-
-nofailback::
-
-The resource won't automatically fail back when a more preferred node
-(re)joins the cluster.
- Examples;;
- * You need to migrate a service to a node which hasn't the highest priority
- in the group at the moment, to tell the HA manager to not move this service
- instantly back set the 'nofailback' option and the service will stay on
- the current node.
-
- * A service was fenced and it got recovered to another node. The admin
- repaired the node and brought it up online again but does not want that the
- recovered services move straight back to the repaired node as he wants to
- first investigate the failure cause and check if it runs stable. He can use
- the 'nofailback' option to achieve this.
+CAUTION: On node failure, the CRM distributes services to the
+remaining nodes. This increase the service count on those nodes, and
+can lead to high load, especially on small clusters. Please design
+your cluster so that it can handle such worst case scenarios.
+[[ha_manager_start_failure_policy]]
Start Failure Policy
---------------------
re-enabled without fixing the error only the restart policy gets
repeated.
+
+[[ha_manager_error_recovery]]
Error Recovery
--------------
* *after* you fixed all errors you may enable the service again
+Node Maintenance
+----------------
+
+It is sometimes possible to shutdown or reboot a node to do
+maintenance tasks. Either to replace hardware, or simply to install a
+new kernel image.
+
+
+Shutdown
+~~~~~~~~
+
+A shutdown ('poweroff') is usually done if the node is planned to stay
+down for some time. The LRM stops all managed services in that
+case. This means that other nodes will take over those service
+afterwards.
+
+NOTE: Recent hardware has large amounts of RAM. So we stop all
+resources, then restart them to avoid online migration of all that
+RAM. If you want to use online migration, you need to invoke that
+manually before you shutdown the node.
+
+
+Reboot
+~~~~~~
+
+Node reboots are initiated with the 'reboot' command. This is usually
+done after installing a new kernel. Please note that this is different
+from ``shutdown'', because the node immediately starts again.
+
+The LRM tells the CRM that it wants to restart, and waits until the
+CRM puts all resources into the `freeze` state. This prevents that
+those resources are moved to other nodes. Instead, the CRM start the
+resources after the reboot on the same node.
+
+
+Manual Resource Movement
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Last but not least, you can also move resources manually to other
+nodes before you shutdown or restart a node. The advantage is that you
+have full control, and you can decide if you want to use online
+migration or not.
+
+NOTE: Please do not 'kill' services like `pve-ha-crm`, `pve-ha-lrm` or
+`watchdog-mux`. They manage and use the watchdog, so this can result
+in a node reboot.
+
+
+[[ha_manager_package_updates]]
+Package Updates
+---------------
+
+When updating the ha-manager you should do one node after the other, never
+all at once for various reasons. First, while we test our software
+thoughtfully, a bug affecting your specific setup cannot totally be ruled out.
+Upgrading one node after the other and checking the functionality of each node
+after finishing the update helps to recover from an eventual problems, while
+updating all could render you in a broken cluster state and is generally not
+good practice.
+
+Also, the {pve} HA stack uses a request acknowledge protocol to perform
+actions between the cluster and the local resource manager. For restarting,
+the LRM makes a request to the CRM to freeze all its services. This prevents
+that they get touched by the Cluster during the short time the LRM is restarting.
+After that the LRM may safely close the watchdog during a restart.
+Such a restart happens on a update and as already stated a active master
+CRM is needed to acknowledge the requests from the LRM, if this is not the case
+the update process can be too long which, in the worst case, may result in
+a watchdog reset.
+
+
+[[ha_manager_service_operations]]
Service Operations
------------------
service state (enabled, disabled).
-Service States
---------------
-
-stopped::
-
-Service is stopped (confirmed by LRM), if detected running it will get stopped
-again.
-
-request_stop::
-
-Service should be stopped. Waiting for confirmation from LRM.
-
-started::
-
-Service is active an LRM should start it ASAP if not already running.
-If the Service fails and is detected to be not running the LRM restarts it.
-
-fence::
-
-Wait for node fencing (service node is not inside quorate cluster
-partition).
-As soon as node gets fenced successfully the service will be recovered to
-another node, if possible.
-
-freeze::
-
-Do not touch the service state. We use this state while we reboot a
-node, or when we restart the LRM daemon.
-
-migrate::
-
-Migrate service (live) to other node.
-
-error::
-
-Service disabled because of LRM errors. Needs manual intervention.
-
-
ifdef::manvolnum[]
include::pve-copyright.adoc[]
endif::manvolnum[]
projects / pve-docs.git / blobdiff