]> git.proxmox.com Git - pve-docs.git/blobdiff - ha-manager.adoc
buildsys: not our job to handle editor files
[pve-docs.git] / ha-manager.adoc
index b8852f6550f5f602e2b08303359bd10757cfbf62..db67e59fbe34d491494867ed9a6e71857daae894 100644 (file)
@@ -142,6 +142,93 @@ service from other services, like it was done with `rgmanager`. In
 general, a HA managed resource should not depend on other resources.
 
 
+Management Tasks
+----------------
+
+This section provides a short overview of common management tasks. The
+first step is to enable HA for a resource. This is done by adding the
+resource to the HA resource configuration. You can do this using the
+GUI, or simply use the command line tool, for example:
+
+----
+# ha-manager add vm:100
+----
+
+The HA stack now tries to start the resources and keeps it
+running. Please note that you can configure the ``requested''
+resources state. For example you may want that the HA stack stops the
+resource:
+
+----
+# ha-manager set vm:100 --state stopped
+----
+
+and start it again later:
+
+----
+# ha-manager set vm:100 --state started
+----
+
+You can also use the normal VM and container management commands. They
+automatically forward the commands to the HA stack, so
+
+----
+# qm start 100
+----
+
+simply sets the requested state to `started`. Same applied to `qm
+stop`, which sets the requested state to `stopped`.
+
+NOTE: The HA stack works fully asynchronous and needs to communicate
+with other cluster members. So it takes some seconds until you see
+the result of such actions.
+
+To view the current HA resource configuration use:
+
+----
+# ha-manager config
+vm:100
+       state stopped
+----
+
+And you can view the actual HA manager and resource state with:
+
+----
+# ha-manager status
+quorum OK
+master node1 (active, Wed Nov 23 11:07:23 2016)
+lrm elsa (active, Wed Nov 23 11:07:19 2016)
+service vm:100 (node1, started)
+----
+
+You can also initiate resource migration to other nodes:
+
+----
+# ha-manager migrate vm:100 node2
+----
+
+This uses online migration and tries to keep the VM running. Online
+migration needs to transfer all used memory over the network, so it is
+sometimes faster to stop VM, then restart it on the new node. This can be
+done using the `relocate` command:
+
+----
+# ha-manager relocate vm:100 node2
+----
+
+Finally, you can remove the resource from the HA configuration using
+the following command:
+
+----
+# ha-manager remove vm:100
+----
+
+NOTE: This does not start or stop the resource.
+
+But all HA related task can be done on the GUI, so there is no need to
+use the command line at all.
+
+
 How It Works
 ------------
 
@@ -167,7 +254,7 @@ handles node fencing.
 [NOTE]
 Locks are provided by our distributed configuration file system (pmxcfs).
 They are used to guarantee that each LRM is active once and working. As a
-LRM only executes actions when it holds its lock we can mark a failed node
+LRM only executes actions when it holds its lock, we can mark a failed node
 as fenced if we can acquire its lock. This lets us then recover any failed
 HA services securely without any interference from the now unknown failed node.
 This all gets supervised by the CRM which holds currently the manager master
@@ -177,8 +264,6 @@ 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:
@@ -205,6 +290,10 @@ request_stop::
 Service should be stopped. The CRM waits for confirmation from the
 LRM.
 
+stopping::
+
+Pending stop request. But the CRM did not get the request so far.
+
 started::
 
 Service is active an LRM should start it ASAP if not already running.
@@ -212,6 +301,11 @@ 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]).
 
+starting::
+
+Pending start request. But the CRM has not got any confirmation from the
+LRM that the service is running.
+
 fence::
 
 Wait for node fencing (service node is not inside quorate cluster
@@ -234,6 +328,14 @@ error::
 Service is disabled because of LRM errors. Needs manual intervention
 (see xref:ha_manager_error_recovery[Error Recovery]).
 
+queued::
+
+Service is newly added, and the CRM has not seen it so far.
+
+disabled::
+
+Service is stopped and marked as `disabled`
+
 
 Local Resource Manager
 ~~~~~~~~~~~~~~~~~~~~~~
@@ -354,7 +456,8 @@ the same HA configuration.
 Resources
 ~~~~~~~~~
 
-[thumbnail="gui-ha-manager-resources-view.png"]
+[thumbnail="gui-ha-manager-status.png"]
+
 
 The resource configuration file `/etc/pve/ha/resources.cfg` stores
 the list of resources managed by `ha-manager`. A resource configuration
@@ -420,7 +523,7 @@ include::ha-groups-opts.adoc[]
 
 [thumbnail="gui-ha-manager-add-group.png"]
 
-A commom requirement is that a resource should run on a specific
+A common 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:
 
@@ -465,7 +568,7 @@ group: mygroup2
 
 
 The `nofailback` options is mostly useful to avoid unwanted resource
-movements during administartion tasks. For example, if you need to
+movements during administration 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.
@@ -614,9 +717,11 @@ Error Recovery
 If after all tries the service state could not be recovered it gets
 placed in an error state. In this state the service won't get touched
 by the HA stack anymore. The only way out is disabling a service:
+
 ----
 # ha-manager set vm:100 --state disabled
 ----
+
 This can also be done in the web interface.
 
 To recover from the error state you should do the following:
@@ -703,46 +808,6 @@ NOTE: Please do not 'kill' services like `pve-ha-crm`, `pve-ha-lrm` or
 in a node reboot.
 
 
-[[ha_manager_service_operations]]
-Service Operations
-------------------
-
-This are how the basic user-initiated service operations (via
-`ha-manager`) work.
-
-set state::
-
-Request the service state.
-See xref:ha_manager_resource_config[Resource Configuration] for possible
-request states.
-+
-----
-# ha-manager set SID -state REQUEST_STATE
-----
-
-disable::
-
-The service will be placed in the stopped state, even if it was in the error
-state. The service will not be recovered on a node failure and will stay
-stopped while it is in this state.
-
-migrate/relocate::
-
-The service will be relocated (live) to another node.
-
-remove::
-
-The service will be removed from the HA managed resource list. Its
-current state will not be touched.
-
-start/stop::
-
-`start` and `stop` commands can be issued to the resource specific tools
-(like `qm` or `pct`), they will forward the request to the
-`ha-manager` which then will execute the action and set the resulting
-service state (enabled, disabled).
-
-
 ifdef::manvolnum[]
 include::pve-copyright.adoc[]
 endif::manvolnum[]