diff --git a/doc/sphinx/Pacemaker_Explained/alerts.rst b/doc/sphinx/Pacemaker_Explained/alerts.rst index 1d0218752e..cba271c8f7 100644 --- a/doc/sphinx/Pacemaker_Explained/alerts.rst +++ b/doc/sphinx/Pacemaker_Explained/alerts.rst @@ -1,257 +1,259 @@ +.. _alerts: + .. index:: single: alert single: resource; alert single: node; alert single: fencing; alert pair: XML element; alert pair: XML element; alerts Alerts ------ *Alerts* may be configured to take some external action when a cluster event occurs (node failure, resource starting or stopping, etc.). .. index:: pair: alert; agent Alert Agents ############ As with resource agents, the cluster calls an external program (an *alert agent*) to handle alerts. The cluster passes information about the event to the agent via environment variables. Agents can do anything desired with this information (send an e-mail, log to a file, update a monitoring system, etc.). .. topic:: Simple alert configuration .. code-block:: xml In the example above, the cluster will call ``my-script.sh`` for each event. Multiple alert agents may be configured; the cluster will call all of them for each event. Alert agents will be called only on cluster nodes. They will be called for events involving Pacemaker Remote nodes, but they will never be called *on* those nodes. For more information about sample alert agents provided by Pacemaker and about developing custom alert agents, see the *Pacemaker Administration* document. .. index:: single: alert; recipient pair: XML element; recipient Alert Recipients ################ Usually, alerts are directed towards a recipient. Thus, each alert may be additionally configured with one or more recipients. The cluster will call the agent separately for each recipient. .. topic:: Alert configuration with recipient .. code-block:: xml In the above example, the cluster will call ``my-script.sh`` for each event, passing the recipient ``some-address`` as an environment variable. The recipient may be anything the alert agent can recognize -- an IP address, an e-mail address, a file name, whatever the particular agent supports. .. index:: single: alert; meta-attributes single: meta-attribute; alert meta-attributes Alert Meta-Attributes ##################### As with resources, meta-attributes can be configured for alerts to change whether and how Pacemaker calls them. .. table:: **Meta-Attributes of an Alert** :class: longtable :widths: 1 1 3 +------------------+---------------+-----------------------------------------------------+ | Meta-Attribute | Default | Description | +==================+===============+=====================================================+ | enabled | true | .. index:: | | | | single: alert; meta-attribute, enabled | | | | single: meta-attribute; enabled (alert) | | | | single: enabled; alert meta-attribute | | | | | | | | If false for an alert, the alert will not be used. | | | | If true for an alert and false for a particular | | | | recipient of that alert, that recipient will not be | | | | used. *(since 2.1.6)* | +------------------+---------------+-----------------------------------------------------+ | timestamp-format | %H:%M:%S.%06N | .. index:: | | | | single: alert; meta-attribute, timestamp-format | | | | single: meta-attribute; timestamp-format (alert) | | | | single: timestamp-format; alert meta-attribute | | | | | | | | Format the cluster will use when sending the | | | | event's timestamp to the agent. This is a string as | | | | used with the ``date(1)`` command. | +------------------+---------------+-----------------------------------------------------+ | timeout | 30s | .. index:: | | | | single: alert; meta-attribute, timeout | | | | single: meta-attribute; timeout (alert) | | | | single: timeout; alert meta-attribute | | | | | | | | If the alert agent does not complete within this | | | | amount of time, it will be terminated. | +------------------+---------------+-----------------------------------------------------+ Meta-attributes can be configured per alert and/or per recipient. .. topic:: Alert configuration with meta-attributes .. code-block:: xml In the above example, the ``my-script.sh`` will get called twice for each event, with each call using a 15-second timeout. One call will be passed the recipient ``someuser@example.com`` and a timestamp in the format ``%D %H:%M``, while the other call will be passed the recipient ``otheruser@example.com`` and a timestamp in the format ``%c``. .. index:: single: alert; instance attributes single: instance attribute; alert instance attributes Alert Instance Attributes ######################### As with resource agents, agent-specific configuration values may be configured as instance attributes. These will be passed to the agent as additional environment variables. The number, names and allowed values of these instance attributes are completely up to the particular agent. .. topic:: Alert configuration with instance attributes .. code-block:: xml .. index:: single: alert; filters pair: XML element; select pair: XML element; select_nodes pair: XML element; select_fencing pair: XML element; select_resources pair: XML element; select_attributes pair: XML element; attribute Alert Filters ############# By default, an alert agent will be called for node events, fencing events, and resource events. An agent may choose to ignore certain types of events, but there is still the overhead of calling it for those events. To eliminate that overhead, you may select which types of events the agent should receive. .. topic:: Alert configuration to receive only node events and fencing events .. code-block:: xml The possible options within `` Node attribute alerts are currently considered experimental. Alerts may be limited to attributes set via ``attrd_updater``, and agents may be called multiple times with the same attribute value. diff --git a/doc/sphinx/Pacemaker_Explained/constraints.rst b/doc/sphinx/Pacemaker_Explained/constraints.rst index 12a5ef93a9..cff65c5b04 100644 --- a/doc/sphinx/Pacemaker_Explained/constraints.rst +++ b/doc/sphinx/Pacemaker_Explained/constraints.rst @@ -1,1110 +1,1114 @@ .. index:: single: constraint single: resource; constraint .. _constraints: Resource Constraints -------------------- .. _location-constraint: .. index:: single: location constraint single: constraint; location Deciding Which Nodes a Resource Can Run On ########################################## *Location constraints* tell the cluster which nodes a resource can run on. There are two alternative strategies. One way is to say that, by default, resources can run anywhere, and then the location constraints specify nodes that are not allowed (an *opt-out* cluster). The other way is to start with nothing able to run anywhere, and use location constraints to selectively enable allowed nodes (an *opt-in* cluster). Whether you should choose opt-in or opt-out depends on your personal preference and the make-up of your cluster. If most of your resources can run on most of the nodes, then an opt-out arrangement is likely to result in a simpler configuration. On the other-hand, if most resources can only run on a small subset of nodes, an opt-in configuration might be simpler. .. index:: pair: XML element; rsc_location single: constraint; rsc_location Location Properties ___________________ .. list-table:: **Attributes of a rsc_location Element** :class: longtable :widths: 1 1 1 4 :header-rows: 1 * - Name - Type - Default - Description * - .. rsc_location_id: .. index:: single: rsc_location; attribute, id single: attribute; id (rsc_location) single: id; rsc_location attribute id - :ref:`id ` - - A unique name for the constraint (required) * - .. rsc_location_rsc: .. index:: single: rsc_location; attribute, rsc single: attribute; rsc (rsc_location) single: rsc; rsc_location attribute rsc - :ref:`id ` - - The name of the resource to which this constraint applies. A location constraint must either have a ``rsc``, have a ``rsc-pattern``, or contain at least one resource set. * - .. rsc_pattern: .. index:: single: rsc_location; attribute, rsc-pattern single: attribute; rsc-pattern (rsc_location) single: rsc-pattern; rsc_location attribute rsc-pattern - :ref:`text ` - - A pattern matching the names of resources to which this constraint applies. The syntax is the same as `POSIX `_ extended regular expressions, with the addition of an initial ``!`` indicating that resources *not* matching the pattern are selected. If - the regular expression contains submatches, and the constraint is - governed by a :ref:`rule `, the submatches can be referenced as - ``%1`` through ``%9`` in the rule's ``score-attribute`` or a rule - expression's ``attribute`` (see :ref:`s-rsc-pattern-rules`). A location - constraint must either have a ``rsc``, have a ``rsc-pattern``, or - contain at least one resource set. + the regular expression contains submatches, and the constraint contains + a :ref:`rule `, the submatches can be referenced as ``%1`` + through ``%9`` in the rule's ``score-attribute`` or a rule expression's + ``attribute`` (see :ref:`s-rsc-pattern-rules`). A location constraint + must either have a ``rsc``, have a ``rsc-pattern``, or contain at least + one resource set. * - .. rsc_location_node: .. index:: single: rsc_location; attribute, node single: attribute; node (rsc_location) single: node; rsc_location attribute node - :ref:`text ` - - The name of the node to which this constraint applies. A location constraint must either have a ``node`` and ``score``, or contain at least one rule. * - .. rsc_location_score: .. index:: single: rsc_location; attribute, score single: attribute; score (rsc_location) single: score; rsc_location attribute score - :ref:`score ` - - Positive values indicate a preference for running the affected resource(s) on ``node`` -- the higher the value, the stronger the preference. Negative values indicate the resource(s) should avoid this node (a value of **-INFINITY** changes "should" to "must"). A location constraint must either have a ``node`` and ``score``, or contain at least one rule. * - .. rsc_location_role: .. index:: single: rsc_location; attribute, role single: attribute; role (rsc_location) single: role; rsc_location attribute role - :ref:`enumeration ` - ``Started`` - - The constraint applies only to resource instances in this role; - significant only for :ref:`promotable clones `. - Allowed values: + - This is significant only for + :ref:`promotable clones `, is allowed only if + ``rsc`` or ``rsc-pattern`` is set, and is ignored if the constraint + contains a rule. Allowed values: - * ``Started`` or ``Unpromoted``: any active role (a promoted instance - must start in the unpromoted role before being promoted, and must be - demoted to the unpromoted role before being stopped, so any location - constraint for unpromoted instances also affects promoted instances) - * ``Promoted``: the promoted role + * ``Started`` or ``Unpromoted``: The constraint affects the location of + all instances of the resource. (A promoted instance must start in the + unpromoted role before being promoted, so any location requirement for + unpromoted instances also affects promoted instances.) + * ``Promoted``: The constraint does not affect the location of + instances, but instead affects which of the instances will be + promoted. + * - .. resource_discovery: .. index:: single: rsc_location; attribute, resource-discovery single: attribute; resource-discovery (rsc_location) single: resource-discovery; rsc_location attribute resource-discovery - :ref:`enumeration ` - always - Whether Pacemaker should perform resource discovery (that is, check whether the resource is already running) for this resource on this node. This should normally be left as the default, so that rogue instances of a service can be stopped when they are running where they are not supposed to be. However, there are two situations where disabling resource discovery is a good idea: when a service is not installed on a node, discovery might return an error (properly written OCF agents will not, so this is usually only seen with other agent types); and when Pacemaker Remote is used to scale a cluster to hundreds of nodes, limiting resource discovery to allowed nodes can significantly boost performance. Allowed values: * ``always:`` Always perform resource discovery for the specified resource on this node. * ``never:`` Never perform resource discovery for the specified resource on this node. This option should generally be used with a -INFINITY score, although that is not strictly required. * ``exclusive:`` Perform resource discovery for the specified resource only on this node (and other nodes similarly marked as ``exclusive``). Multiple location constraints using ``exclusive`` discovery for the same resource across different nodes creates a subset of nodes resource-discovery is exclusive to. If a resource is marked for ``exclusive`` discovery on one or more nodes, that resource is only allowed to be placed within that subset of nodes. .. warning:: Setting ``resource-discovery`` to ``never`` or ``exclusive`` removes Pacemaker's ability to detect and stop unwanted instances of a service running where it's not supposed to be. It is up to the system administrator (you!) to make sure that the service can *never* be active on nodes without ``resource-discovery`` (such as by leaving the relevant software uninstalled). .. index:: single: Asymmetrical Clusters single: Opt-In Clusters Asymmetrical "Opt-In" Clusters ______________________________ To create an opt-in cluster, start by preventing resources from running anywhere by default: .. code-block:: none # crm_attribute --name symmetric-cluster --update false Then start enabling nodes. The following fragment says that the web server prefers **sles-1**, the database prefers **sles-2** and both can fail over to **sles-3** if their most preferred node fails. .. topic:: Opt-in location constraints for two resources .. code-block:: xml .. index:: single: Symmetrical Clusters single: Opt-Out Clusters Symmetrical "Opt-Out" Clusters ______________________________ To create an opt-out cluster, start by allowing resources to run anywhere by default: .. code-block:: none # crm_attribute --name symmetric-cluster --update true Then start disabling nodes. The following fragment is the equivalent of the above opt-in configuration. .. topic:: Opt-out location constraints for two resources .. code-block:: xml .. _node-score-equal: What if Two Nodes Have the Same Score _____________________________________ If two nodes have the same score, then the cluster will choose one. This choice may seem random and may not be what was intended, however the cluster was not given enough information to know any better. .. topic:: Constraints where a resource prefers two nodes equally .. code-block:: xml In the example above, assuming no other constraints and an inactive cluster, **Webserver** would probably be placed on **sles-1** and **Database** on **sles-2**. It would likely have placed **Webserver** based on the node's uname and **Database** based on the desire to spread the resource load evenly across the cluster. However other factors can also be involved in more complex configurations. .. _s-rsc-pattern: Specifying locations using pattern matching ___________________________________________ A location constraint can affect all resources whose IDs match a given pattern. The following example bans resources named **ip-httpd**, **ip-asterisk**, **ip-gateway**, etc., from **node1**. .. topic:: Location constraint banning all resources matching a pattern from one node .. code-block:: xml .. index:: single: constraint; ordering single: resource; start order .. _s-resource-ordering: Specifying the Order in which Resources Should Start/Stop ######################################################### *Ordering constraints* tell the cluster the order in which certain resource actions should occur. .. important:: Ordering constraints affect *only* the ordering of resource actions; they do *not* require that the resources be placed on the same node. If you want resources to be started on the same node *and* in a specific order, you need both an ordering constraint *and* a colocation constraint (see :ref:`s-resource-colocation`), or alternatively, a group (see :ref:`group-resources`). .. index:: pair: XML element; rsc_order pair: constraint; rsc_order Ordering Properties ___________________ .. table:: **Attributes of a rsc_order Element** :class: longtable :widths: 1 2 4 +--------------+----------------------------+-------------------------------------------------------------------+ | Field | Default | Description | +==============+============================+===================================================================+ | id | | .. index:: | | | | single: rsc_order; attribute, id | | | | single: attribute; id (rsc_order) | | | | single: id; rsc_order attribute | | | | | | | | A unique name for the constraint | +--------------+----------------------------+-------------------------------------------------------------------+ | first | | .. index:: | | | | single: rsc_order; attribute, first | | | | single: attribute; first (rsc_order) | | | | single: first; rsc_order attribute | | | | | | | | Name of the resource that the ``then`` resource | | | | depends on | +--------------+----------------------------+-------------------------------------------------------------------+ | then | | .. index:: | | | | single: rsc_order; attribute, then | | | | single: attribute; then (rsc_order) | | | | single: then; rsc_order attribute | | | | | | | | Name of the dependent resource | +--------------+----------------------------+-------------------------------------------------------------------+ | first-action | start | .. index:: | | | | single: rsc_order; attribute, first-action | | | | single: attribute; first-action (rsc_order) | | | | single: first-action; rsc_order attribute | | | | | | | | The action that the ``first`` resource must complete | | | | before ``then-action`` can be initiated for the ``then`` | | | | resource. Allowed values: ``start``, ``stop``, | | | | ``promote``, ``demote``. | +--------------+----------------------------+-------------------------------------------------------------------+ | then-action | value of ``first-action`` | .. index:: | | | | single: rsc_order; attribute, then-action | | | | single: attribute; then-action (rsc_order) | | | | single: first-action; rsc_order attribute | | | | | | | | The action that the ``then`` resource can execute only | | | | after the ``first-action`` on the ``first`` resource has | | | | completed. Allowed values: ``start``, ``stop``, | | | | ``promote``, ``demote``. | +--------------+----------------------------+-------------------------------------------------------------------+ | kind | Mandatory | .. index:: | | | | single: rsc_order; attribute, kind | | | | single: attribute; kind (rsc_order) | | | | single: kind; rsc_order attribute | | | | | | | | How to enforce the constraint. Allowed values: | | | | | | | | * ``Mandatory:`` ``then-action`` will never be initiated | | | | for the ``then`` resource unless and until ``first-action`` | | | | successfully completes for the ``first`` resource. | | | | | | | | * ``Optional:`` The constraint applies only if both specified | | | | resource actions are scheduled in the same transition | | | | (that is, in response to the same cluster state). This | | | | means that ``then-action`` is allowed on the ``then`` | | | | resource regardless of the state of the ``first`` resource, | | | | but if both actions happen to be scheduled at the same time, | | | | they will be ordered. | | | | | | | | * ``Serialize:`` Ensure that the specified actions are never | | | | performed concurrently for the specified resources. | | | | ``First-action`` and ``then-action`` can be executed in either | | | | order, but one must complete before the other can be initiated. | | | | An example use case is when resource start-up puts a high load | | | | on the host. | +--------------+----------------------------+-------------------------------------------------------------------+ | symmetrical | TRUE for ``Mandatory`` and | .. index:: | | | ``Optional`` kinds. FALSE | single: rsc_order; attribute, symmetrical | | | for ``Serialize`` kind. | single: attribute; symmetrical (rsc)order) | | | | single: symmetrical; rsc_order attribute | | | | | | | | If true, the reverse of the constraint applies for the | | | | opposite action (for example, if B starts after A starts, | | | | then B stops before A stops). ``Serialize`` orders cannot | | | | be symmetrical. | +--------------+----------------------------+-------------------------------------------------------------------+ ``Promote`` and ``demote`` apply to :ref:`promotable ` clone resources. Optional and mandatory ordering _______________________________ Here is an example of ordering constraints where **Database** *must* start before **Webserver**, and **IP** *should* start before **Webserver** if they both need to be started: .. topic:: Optional and mandatory ordering constraints .. code-block:: xml Because the above example lets ``symmetrical`` default to TRUE, **Webserver** must be stopped before **Database** can be stopped, and **Webserver** should be stopped before **IP** if they both need to be stopped. Symmetric and asymmetric ordering _________________________________ A mandatory symmetric ordering of "start A then start B" implies not only that the start actions must be ordered, but that B is not allowed to be active unless A is active. For example, if the ordering is added to the configuration when A is stopped (due to target-role, failure, etc.) and B is already active, then B will be stopped. By contrast, asymmetric ordering of "start A then start B" means the stops can occur in either order, which implies that B *can* remain active in the same situation. .. index:: single: colocation single: constraint; colocation single: resource; location relative to other resources .. _s-resource-colocation: Placing Resources Relative to other Resources ############################################# *Colocation constraints* tell the cluster that the location of one resource depends on the location of another one. Colocation has an important side-effect: it affects the order in which resources are assigned to a node. Think about it: You can't place A relative to B unless you know where B is [#]_. So when you are creating colocation constraints, it is important to consider whether you should colocate A with B, or B with A. .. important:: Colocation constraints affect *only* the placement of resources; they do *not* require that the resources be started in a particular order. If you want resources to be started on the same node *and* in a specific order, you need both an ordering constraint (see :ref:`s-resource-ordering`) *and* a colocation constraint, or alternatively, a group (see :ref:`group-resources`). .. index:: pair: XML element; rsc_colocation single: constraint; rsc_colocation Colocation Properties _____________________ .. table:: **Attributes of a rsc_colocation Constraint** :class: longtable :widths: 2 2 5 +----------------+----------------+--------------------------------------------------------+ | Field | Default | Description | +================+================+========================================================+ | id | | .. index:: | | | | single: rsc_colocation; attribute, id | | | | single: attribute; id (rsc_colocation) | | | | single: id; rsc_colocation attribute | | | | | | | | A unique name for the constraint (required). | +----------------+----------------+--------------------------------------------------------+ | rsc | | .. index:: | | | | single: rsc_colocation; attribute, rsc | | | | single: attribute; rsc (rsc_colocation) | | | | single: rsc; rsc_colocation attribute | | | | | | | | The name of a resource that should be located | | | | relative to ``with-rsc``. A colocation constraint must | | | | either contain at least one | | | | :ref:`resource set `, or specify both | | | | ``rsc`` and ``with-rsc``. | +----------------+----------------+--------------------------------------------------------+ | with-rsc | | .. index:: | | | | single: rsc_colocation; attribute, with-rsc | | | | single: attribute; with-rsc (rsc_colocation) | | | | single: with-rsc; rsc_colocation attribute | | | | | | | | The name of the resource used as the colocation | | | | target. The cluster will decide where to put this | | | | resource first and then decide where to put ``rsc``. | | | | A colocation constraint must either contain at least | | | | one :ref:`resource set `, or specify | | | | both ``rsc`` and ``with-rsc``. | +----------------+----------------+--------------------------------------------------------+ | node-attribute | #uname | .. index:: | | | | single: rsc_colocation; attribute, node-attribute | | | | single: attribute; node-attribute (rsc_colocation) | | | | single: node-attribute; rsc_colocation attribute | | | | | | | | If ``rsc`` and ``with-rsc`` are specified, this node | | | | attribute must be the same on the node running ``rsc`` | | | | and the node running ``with-rsc`` for the constraint | | | | to be satisfied. (For details, see | | | | :ref:`s-coloc-attribute`.) | +----------------+----------------+--------------------------------------------------------+ | score | 0 | .. index:: | | | | single: rsc_colocation; attribute, score | | | | single: attribute; score (rsc_colocation) | | | | single: score; rsc_colocation attribute | | | | | | | | Positive values indicate the resources should run on | | | | the same node. Negative values indicate the resources | | | | should run on different nodes. Values of | | | | +/- ``INFINITY`` change "should" to "must". | +----------------+----------------+--------------------------------------------------------+ | rsc-role | Started | .. index:: | | | | single: clone; ordering constraint, rsc-role | | | | single: ordering constraint; rsc-role (clone) | | | | single: rsc-role; clone ordering constraint | | | | | | | | If ``rsc`` and ``with-rsc`` are specified, and ``rsc`` | | | | is a :ref:`promotable clone `, | | | | the constraint applies only to ``rsc`` instances in | | | | this role. Allowed values: ``Started``, ``Stopped``, | | | | ``Promoted``, ``Unpromoted``. For details, see | | | | :ref:`promotable-clone-constraints`. | +----------------+----------------+--------------------------------------------------------+ | with-rsc-role | Started | .. index:: | | | | single: clone; ordering constraint, with-rsc-role | | | | single: ordering constraint; with-rsc-role (clone) | | | | single: with-rsc-role; clone ordering constraint | | | | | | | | If ``rsc`` and ``with-rsc`` are specified, and | | | | ``with-rsc`` is a | | | | :ref:`promotable clone `, the | | | | constraint applies only to ``with-rsc`` instances in | | | | this role. Allowed values: ``Started``, ``Stopped``, | | | | ``Promoted``, ``Unpromoted``. For details, see | | | | :ref:`promotable-clone-constraints`. | +----------------+----------------+--------------------------------------------------------+ | influence | value of | .. index:: | | | ``critical`` | single: rsc_colocation; attribute, influence | | | meta-attribute | single: attribute; influence (rsc_colocation) | | | for ``rsc`` | single: influence; rsc_colocation attribute | | | | | | | | Whether to consider the location preferences of | | | | ``rsc`` when ``with-rsc`` is already active. Allowed | | | | values: ``true``, ``false``. For details, see | | | | :ref:`s-coloc-influence`. *(since 2.1.0)* | +----------------+----------------+--------------------------------------------------------+ Mandatory Placement ___________________ Mandatory placement occurs when the constraint's score is **+INFINITY** or **-INFINITY**. In such cases, if the constraint can't be satisfied, then the **rsc** resource is not permitted to run. For ``score=INFINITY``, this includes cases where the ``with-rsc`` resource is not active. If you need resource **A** to always run on the same machine as resource **B**, you would add the following constraint: .. topic:: Mandatory colocation constraint for two resources .. code-block:: xml Remember, because **INFINITY** was used, if **B** can't run on any of the cluster nodes (for whatever reason) then **A** will not be allowed to run. Whether **A** is running or not has no effect on **B**. Alternatively, you may want the opposite -- that **A** *cannot* run on the same machine as **B**. In this case, use ``score="-INFINITY"``. .. topic:: Mandatory anti-colocation constraint for two resources .. code-block:: xml Again, by specifying **-INFINITY**, the constraint is binding. So if the only place left to run is where **B** already is, then **A** may not run anywhere. As with **INFINITY**, **B** can run even if **A** is stopped. However, in this case **A** also can run if **B** is stopped, because it still meets the constraint of **A** and **B** not running on the same node. Advisory Placement __________________ If mandatory placement is about "must" and "must not", then advisory placement is the "I'd prefer if" alternative. For colocation constraints with scores greater than **-INFINITY** and less than **INFINITY**, the cluster will try to accommodate your wishes, but may ignore them if other factors outweigh the colocation score. Those factors might include other constraints, resource stickiness, failure thresholds, whether other resources would be prevented from being active, etc. .. topic:: Advisory colocation constraint for two resources .. code-block:: xml .. _s-coloc-attribute: Colocation by Node Attribute ____________________________ The ``node-attribute`` property of a colocation constraints allows you to express the requirement, "these resources must be on similar nodes". As an example, imagine that you have two Storage Area Networks (SANs) that are not controlled by the cluster, and each node is connected to one or the other. You may have two resources **r1** and **r2** such that **r2** needs to use the same SAN as **r1**, but doesn't necessarily have to be on the same exact node. In such a case, you could define a :ref:`node attribute ` named **san**, with the value **san1** or **san2** on each node as appropriate. Then, you could colocate **r2** with **r1** using ``node-attribute`` set to **san**. .. _s-coloc-influence: Colocation Influence ____________________ By default, if A is colocated with B, the cluster will take into account A's preferences when deciding where to place B, to maximize the chance that both resources can run. For a detailed look at exactly how this occurs, see `Colocation Explained `_. However, if ``influence`` is set to ``false`` in the colocation constraint, this will happen only if B is inactive and needing to be started. If B is already active, A's preferences will have no effect on placing B. An example of what effect this would have and when it would be desirable would be a nonessential reporting tool colocated with a resource-intensive service that takes a long time to start. If the reporting tool fails enough times to reach its migration threshold, by default the cluster will want to move both resources to another node if possible. Setting ``influence`` to ``false`` on the colocation constraint would mean that the reporting tool would be stopped in this situation instead, to avoid forcing the service to move. The ``critical`` resource meta-attribute is a convenient way to specify the default for all colocation constraints and groups involving a particular resource. .. note:: If a noncritical resource is a member of a group, all later members of the group will be treated as noncritical, even if they are marked as (or left to default to) critical. .. _s-resource-sets: Resource Sets ############# .. index:: single: constraint; resource set single: resource; resource set *Resource sets* allow multiple resources to be affected by a single constraint. .. topic:: A set of 3 resources .. code-block:: xml Resource sets are valid inside ``rsc_location``, ``rsc_order`` (see :ref:`s-resource-sets-ordering`), ``rsc_colocation`` (see :ref:`s-resource-sets-colocation`), and ``rsc_ticket`` (see :ref:`ticket-constraints`) constraints. A resource set has a number of properties that can be set, though not all have an effect in all contexts. .. index:: pair: XML element; resource_set .. table:: **Attributes of a resource_set Element** :class: longtable :widths: 2 2 5 +-------------+------------------+--------------------------------------------------------+ | Field | Default | Description | +=============+==================+========================================================+ | id | | .. index:: | | | | single: resource_set; attribute, id | | | | single: attribute; id (resource_set) | | | | single: id; resource_set attribute | | | | | | | | A unique name for the set (required) | +-------------+------------------+--------------------------------------------------------+ | sequential | true | .. index:: | | | | single: resource_set; attribute, sequential | | | | single: attribute; sequential (resource_set) | | | | single: sequential; resource_set attribute | | | | | | | | Whether the members of the set must be acted on in | | | | order. Meaningful within ``rsc_order`` and | | | | ``rsc_colocation``. | +-------------+------------------+--------------------------------------------------------+ | require-all | true | .. index:: | | | | single: resource_set; attribute, require-all | | | | single: attribute; require-all (resource_set) | | | | single: require-all; resource_set attribute | | | | | | | | Whether all members of the set must be active before | | | | continuing. With the current implementation, the | | | | cluster may continue even if only one member of the | | | | set is started, but if more than one member of the set | | | | is starting at the same time, the cluster will still | | | | wait until all of those have started before continuing | | | | (this may change in future versions). Meaningful | | | | within ``rsc_order``. | +-------------+------------------+--------------------------------------------------------+ | role | | .. index:: | | | | single: resource_set; attribute, role | | | | single: attribute; role (resource_set) | | | | single: role; resource_set attribute | | | | | | | | The constraint applies only to resource set members | | | | that are :ref:`s-resource-promotable` in this | | | | role. Meaningful within ``rsc_location``, | | | | ``rsc_colocation`` and ``rsc_ticket``. | | | | Allowed values: ``Started``, ``Promoted``, | | | | ``Unpromoted``. For details, see | | | | :ref:`promotable-clone-constraints`. | +-------------+------------------+--------------------------------------------------------+ | action | value of | .. index:: | | | ``first-action`` | single: resource_set; attribute, action | | | in the enclosing | single: attribute; action (resource_set) | | | ordering | single: action; resource_set attribute | | | constraint | | | | | The action that applies to *all members* of the set. | | | | Meaningful within ``rsc_order``. Allowed values: | | | | ``start``, ``stop``, ``promote``, ``demote``. | +-------------+------------------+--------------------------------------------------------+ | score | | .. index:: | | | | single: resource_set; attribute, score | | | | single: attribute; score (resource_set) | | | | single: score; resource_set attribute | | | | | | | | *Advanced use only.* Use a specific score for this | | | | set within the constraint. | +-------------+------------------+--------------------------------------------------------+ .. _s-resource-sets-ordering: Ordering Sets of Resources ########################## A common situation is for an administrator to create a chain of ordered resources, such as: .. topic:: A chain of ordered resources .. code-block:: xml .. topic:: Visual representation of the four resources' start order for the above constraints .. image:: images/resource-set.png :alt: Ordered set Ordered Set ___________ To simplify this situation, :ref:`s-resource-sets` can be used within ordering constraints: .. topic:: A chain of ordered resources expressed as a set .. code-block:: xml While the set-based format is not less verbose, it is significantly easier to get right and maintain. .. important:: If you use a higher-level tool, pay attention to how it exposes this functionality. Depending on the tool, creating a set **A B** may be equivalent to **A then B**, or **B then A**. Ordering Multiple Sets ______________________ The syntax can be expanded to allow sets of resources to be ordered relative to each other, where the members of each individual set may be ordered or unordered (controlled by the ``sequential`` property). In the example below, **A** and **B** can both start in parallel, as can **C** and **D**, however **C** and **D** can only start once *both* **A** *and* **B** are active. .. topic:: Ordered sets of unordered resources .. code-block:: xml .. topic:: Visual representation of the start order for two ordered sets of unordered resources .. image:: images/two-sets.png :alt: Two ordered sets Of course either set -- or both sets -- of resources can also be internally ordered (by setting ``sequential="true"``) and there is no limit to the number of sets that can be specified. .. topic:: Advanced use of set ordering - Three ordered sets, two of which are internally unordered .. code-block:: xml .. topic:: Visual representation of the start order for the three sets defined above .. image:: images/three-sets.png :alt: Three ordered sets .. important:: An ordered set with ``sequential=false`` makes sense only if there is another set in the constraint. Otherwise, the constraint has no effect. Resource Set OR Logic _____________________ The unordered set logic discussed so far has all been "AND" logic. To illustrate this take the 3 resource set figure in the previous section. Those sets can be expressed, **(A and B) then (C) then (D) then (E and F)**. Say for example we want to change the first set, **(A and B)**, to use "OR" logic so the sets look like this: **(A or B) then (C) then (D) then (E and F)**. This functionality can be achieved through the use of the ``require-all`` option. This option defaults to TRUE which is why the "AND" logic is used by default. Setting ``require-all=false`` means only one resource in the set needs to be started before continuing on to the next set. .. topic:: Resource Set "OR" logic: Three ordered sets, where the first set is internally unordered with "OR" logic .. code-block:: xml .. important:: An ordered set with ``require-all=false`` makes sense only in conjunction with ``sequential=false``. Think of it like this: ``sequential=false`` modifies the set to be an unordered set using "AND" logic by default, and adding ``require-all=false`` flips the unordered set's "AND" logic to "OR" logic. .. _s-resource-sets-colocation: Colocating Sets of Resources ############################ Another common situation is for an administrator to create a set of colocated resources. The simplest way to do this is to define a resource group (see :ref:`group-resources`), but that cannot always accurately express the desired relationships. For example, maybe the resources do not need to be ordered. Another way would be to define each relationship as an individual constraint, but that causes a difficult-to-follow constraint explosion as the number of resources and combinations grow. .. topic:: Colocation chain as individual constraints, where A is placed first, then B, then C, then D .. code-block:: xml To express complicated relationships with a simplified syntax [#]_, :ref:`resource sets ` can be used within colocation constraints. .. topic:: Equivalent colocation chain expressed using **resource_set** .. code-block:: xml .. note:: Within a ``resource_set``, the resources are listed in the order they are *placed*, which is the reverse of the order in which they are *colocated*. In the above example, resource **A** is placed before resource **B**, which is the same as saying resource **B** is colocated with resource **A**. As with individual constraints, a resource that can't be active prevents any resource that must be colocated with it from being active. In both of the two previous examples, if **B** is unable to run, then both **C** and by inference **D** must remain stopped. .. important:: If you use a higher-level tool, pay attention to how it exposes this functionality. Depending on the tool, creating a set **A B** may be equivalent to **A with B**, or **B with A**. Resource sets can also be used to tell the cluster that entire *sets* of resources must be colocated relative to each other, while the individual members within any one set may or may not be colocated relative to each other (determined by the set's ``sequential`` property). In the following example, resources **B**, **C**, and **D** will each be colocated with **A** (which will be placed first). **A** must be able to run in order for any of the resources to run, but any of **B**, **C**, or **D** may be stopped without affecting any of the others. .. topic:: Using colocated sets to specify a shared dependency .. code-block:: xml .. note:: Pay close attention to the order in which resources and sets are listed. While the members of any one sequential set are placed first to last (i.e., the colocation dependency is last with first), multiple sets are placed last to first (i.e. the colocation dependency is first with last). .. important:: A colocated set with ``sequential="false"`` makes sense only if there is another set in the constraint. Otherwise, the constraint has no effect. There is no inherent limit to the number and size of the sets used. The only thing that matters is that in order for any member of one set in the constraint to be active, all members of sets listed after it must also be active (and naturally on the same node); and if a set has ``sequential="true"``, then in order for one member of that set to be active, all members listed before it must also be active. If desired, you can restrict the dependency to instances of promotable clone resources that are in a specific role, using the set's ``role`` property. .. topic:: Colocation in which the members of the middle set have no interdependencies, and the last set listed applies only to promoted instances .. code-block:: xml .. topic:: Visual representation of the above example (resources are placed from left to right) .. image:: ../shared/images/pcmk-colocated-sets.png :alt: Colocation chain .. note:: Unlike ordered sets, colocated sets do not use the ``require-all`` option. External Resource Dependencies ############################## Sometimes, a resource will depend on services that are not managed by the cluster. An example might be a resource that requires a file system that is not managed by the cluster but mounted by systemd at boot time. To accommodate this, the pacemaker systemd service depends on a normally empty target called ``resource-agents-deps.target``. The system administrator may create a unit drop-in for that target specifying the dependencies, to ensure that the services are started before Pacemaker starts and stopped after Pacemaker stops. Typically, this is accomplished by placing a unit file in the ``/etc/systemd/system/resource-agents-deps.target.d`` directory, with directives such as ``Requires`` and ``After`` specifying the dependencies as needed. .. [#] While the human brain is sophisticated enough to read the constraint in any order and choose the correct one depending on the situation, the cluster is not quite so smart. Yet. .. [#] which is not the same as saying easy to follow diff --git a/doc/sphinx/Pacemaker_Explained/local-options.rst b/doc/sphinx/Pacemaker_Explained/local-options.rst index 7794873b52..915a65b9ec 100644 --- a/doc/sphinx/Pacemaker_Explained/local-options.rst +++ b/doc/sphinx/Pacemaker_Explained/local-options.rst @@ -1,741 +1,750 @@ Host-Local Configuration ------------------------ .. index:: pair: XML element; configuration .. note:: Directory and file paths below may differ on your system depending on your Pacemaker build settings. Check your Pacemaker configuration file to find the correct paths. Configuration Value Types ######################### Throughout this document, configuration values will be designated as having one of the following types: .. list-table:: **Configuration Value Types** :class: longtable :widths: 1 3 :header-rows: 1 * - Type - Description * - .. _boolean: .. index:: pair: type; boolean boolean - Case-insensitive text value where ``1``, ``yes``, ``y``, ``on``, and ``true`` evaluate as true and ``0``, ``no``, ``n``, ``off``, ``false``, and unset evaluate as false * - .. _date_time: .. index:: pair: type; date/time date/time - Textual timestamp like ``Sat Dec 21 11:47:45 2013`` * - .. _duration: .. index:: pair: type; duration duration - A time duration, specified either like a :ref:`timeout ` or an `ISO 8601 duration `_. A duration may be up to approximately 49 days but is intended for much smaller time periods. * - .. _enumeration: .. index:: pair: type; enumeration enumeration - Text that must be one of a set of defined values (which will be listed in the description) * - .. _epoch_time: .. index:: pair: type; epoch_time epoch_time - Time as the integer number of seconds since the Unix epoch, ``1970-01-01 00:00:00 +0000 (UTC)``. * - .. _id: .. index:: pair: type; id id - A text string starting with a letter or underbar, followed by any combination of letters, numbers, dashes, dots, and/or underbars; when used for a property named ``id``, the string must be unique across all ``id`` properties in the CIB * - .. _integer: .. index:: pair: type; integer integer - 32-bit signed integer value (-2,147,483,648 to 2,147,483,647) * - .. _iso8601: .. index:: pair: type; iso8601 ISO 8601 - An `ISO 8601 `_ date/time. * - .. _nonnegative_integer: .. index:: pair: type; nonnegative integer nonnegative integer - 32-bit nonnegative integer value (0 to 2,147,483,647) * - .. _percentage: .. index:: pair: type; percentage percentage - Floating-point number followed by an optional percent sign ('%') * - .. _port: .. index:: pair: type; port port - Integer TCP port number (0 to 65535) + * - .. _range: + + .. index:: + pair: type; range + + range + - A range may be a single nonnegative integer or a dash-separated range of + nonnegative integers. Either the first or last value may be omitted to + leave the range open-ended. Examples: ``0``, ``3-``, ``-5``, ``4-6``. * - .. _score: .. index:: pair: type; score score - A Pacemaker score can be an integer between -1,000,000 and 1,000,000, or a string alias: ``INFINITY`` or ``+INFINITY`` is equivalent to 1,000,000, ``-INFINITY`` is equivalent to -1,000,000, and ``red``, ``yellow``, and ``green`` are equivalent to integers as described in :ref:`node-health`. * - .. _text: .. index:: pair: type; text text - A text string * - .. _timeout: .. index:: pair: type; timeout timeout - A time duration, specified as a bare number (in which case it is considered to be in seconds) or a number with a unit (``ms`` or ``msec`` for milliseconds, ``us`` or ``usec`` for microseconds, ``s`` or ``sec`` for seconds, ``m`` or ``min`` for minutes, ``h`` or ``hr`` for hours) optionally with whitespace before and/or after the number. * - .. _version: .. index:: pair: type; version version - Version number (any combination of alphanumeric characters, dots, and dashes, starting with a number). Scores ______ Scores are integral to how Pacemaker works. Practically everything from moving a resource to deciding which resource to stop in a degraded cluster is achieved by manipulating scores in some way. Scores are calculated per resource and node. Any node with a negative score for a resource can't run that resource. The cluster places a resource on the node with the highest score for it. Score addition and subtraction follow these rules: * Any value (including ``INFINITY``) - ``INFINITY`` = ``-INFINITY`` * ``INFINITY`` + any value other than ``-INFINITY`` = ``INFINITY`` .. note:: What if you want to use a score higher than 1,000,000? Typically this possibility arises when someone wants to base the score on some external metric that might go above 1,000,000. The short answer is you can't. The long answer is it is sometimes possible work around this limitation creatively. You may be able to set the score to some computed value based on the external metric rather than use the metric directly. For nodes, you can store the metric as a node attribute, and query the attribute when computing the score (possibly as part of a custom resource agent). Local Options ############# Pacemaker supports several host-local configuration options. These options can be configured on each node in the main Pacemaker configuration file (|PCMK_CONFIG_FILE|) in the format ``=""``. They work by setting environment variables when Pacemaker daemons start up. .. list-table:: **Local Options** :class: longtable :widths: 2 2 2 5 :header-rows: 1 * - Name - Type - Default - Description * - .. _cib_pam_service: .. index:: pair: node option; CIB_pam_service CIB_pam_service - :ref:`text ` - login - PAM service to use for remote CIB client authentication (passed to ``pam_start``). * - .. _pcmk_logfacility: .. index:: pair: node option; PCMK_logfacility PCMK_logfacility - :ref:`enumeration ` - daemon - Enable logging via the system log or journal, using the specified log facility. Messages sent here are of value to all Pacemaker administrators. This can be disabled using ``none``, but that is not recommended. Allowed values: * ``none`` * ``daemon`` * ``user`` * ``local0`` * ``local1`` * ``local2`` * ``local3`` * ``local4`` * ``local5`` * ``local6`` * ``local7`` * - .. _pcmk_logpriority: .. index:: pair: node option; PCMK_logpriority PCMK_logpriority - :ref:`enumeration ` - notice - Unless system logging is disabled using ``PCMK_logfacility=none``, messages of the specified log severity and higher will be sent to the system log. The default is appropriate for most installations. Allowed values: * ``emerg`` * ``alert`` * ``crit`` * ``error`` * ``warning`` * ``notice`` * ``info`` * ``debug`` * - .. _pcmk_logfile: .. index:: pair: node option; PCMK_logfile PCMK_logfile - :ref:`text ` - |PCMK_LOG_FILE| - Unless set to ``none``, more detailed log messages will be sent to the specified file (in addition to the system log, if enabled). These messages may have extended information, and will include messages of info severity. This log is of more use to developers and advanced system administrators, and when reporting problems. Note: The default is |PCMK_CONTAINER_LOG_FILE| (inside the container) for bundled container nodes; this would typically be mapped to a different path on the host running the container. * - .. _pcmk_logfile_mode: .. index:: pair: node option; PCMK_logfile_mode PCMK_logfile_mode - :ref:`text ` - 0660 - Pacemaker will set the permissions on the detail log to this value (see ``chmod(1)``). * - .. _pcmk_debug: .. index:: pair: node option; PCMK_debug PCMK_debug - :ref:`enumeration ` - no - Whether to send debug severity messages to the detail log. This may be set for all subsystems (``yes`` or ``no``) or for specific (comma- separated) subsystems. Allowed subsystems are: * ``pacemakerd`` * ``pacemaker-attrd`` * ``pacemaker-based`` * ``pacemaker-controld`` * ``pacemaker-execd`` * ``pacemaker-fenced`` * ``pacemaker-schedulerd`` Example: ``PCMK_debug="pacemakerd,pacemaker-execd"`` * - .. _pcmk_stderr: .. index:: pair: node option; PCMK_stderr PCMK_stderr - :ref:`boolean ` - no - *Advanced Use Only:* Whether to send daemon log messages to stderr. This would be useful only during troubleshooting, when starting Pacemaker manually on the command line. Setting this option in the configuration file is pointless, since the file is not read when starting Pacemaker manually. However, it can be set directly as an environment variable on the command line. * - .. _pcmk_trace_functions: .. index:: pair: node option; PCMK_trace_functions PCMK_trace_functions - :ref:`text ` - - *Advanced Use Only:* Send debug and trace severity messages from these (comma-separated) source code functions to the detail log. Example: ``PCMK_trace_functions="func1,func2"`` * - .. _pcmk_trace_files: .. index:: pair: node option; PCMK_trace_files PCMK_trace_files - :ref:`text ` - - *Advanced Use Only:* Send debug and trace severity messages from all functions in these (comma-separated) source file names to the detail log. Example: ``PCMK_trace_files="file1.c,file2.c"`` * - .. _pcmk_trace_formats: .. index:: pair: node option; PCMK_trace_formats PCMK_trace_formats - :ref:`text ` - - *Advanced Use Only:* Send trace severity messages that are generated by these (comma-separated) format strings in the source code to the detail log. Example: ``PCMK_trace_formats="Error: %s (%d)"`` * - .. _pcmk_trace_tags: .. index:: pair: node option; PCMK_trace_tags PCMK_trace_tags - :ref:`text ` - - *Advanced Use Only:* Send debug and trace severity messages related to these (comma-separated) resource IDs to the detail log. Example: ``PCMK_trace_tags="client-ip,dbfs"`` * - .. _pcmk_blackbox: .. index:: pair: node option; PCMK_blackbox PCMK_blackbox - :ref:`enumeration ` - no - *Advanced Use Only:* Enable blackbox logging globally (``yes`` or ``no``) or by subsystem. A blackbox contains a rolling buffer of all logs (of all severities). Blackboxes are stored under |CRM_BLACKBOX_DIR| by default, by default, and their contents can be viewed using the ``qb-blackbox(8)`` command. The blackbox recorder can be enabled at start using this variable, or at runtime by sending a Pacemaker subsystem daemon process a ``SIGUSR1`` or ``SIGTRAP`` signal, and disabled by sending ``SIGUSR2`` (see ``kill(1)``). The blackbox will be written after a crash, assertion failure, or ``SIGTRAP`` signal. See :ref:`PCMK_debug ` for allowed subsystems. Example: ``PCMK_blackbox="pacemakerd,pacemaker-execd"`` * - .. _pcmk_trace_blackbox: .. index:: pair: node option; PCMK_trace_blackbox PCMK_trace_blackbox - :ref:`enumeration ` - - *Advanced Use Only:* Write a blackbox whenever the message at the specified function and line is logged. Multiple entries may be comma- separated. Example: ``PCMK_trace_blackbox="remote.c:144,remote.c:149"`` * - .. _pcmk_node_start_state: .. index:: pair: node option; PCMK_node_start_state PCMK_node_start_state - :ref:`enumeration ` - default - By default, the local host will join the cluster in an online or standby state when Pacemaker first starts depending on whether it was previously put into standby mode. If this variable is set to ``standby`` or ``online``, it will force the local host to join in the specified state. * - .. _pcmk_node_action_limit: .. index:: pair: node option; PCMK_node_action_limit PCMK_node_action_limit - :ref:`nonnegative integer ` - - Specify the maximum number of jobs that can be scheduled on this node. If set, this overrides the :ref:`node-action-limit ` cluster option on this node. * - .. _pcmk_shutdown_delay: .. index:: pair: node option; PCMK_shutdown_delay PCMK_shutdown_delay - :ref:`timeout ` - - Specify a delay before shutting down ``pacemakerd`` after shutting down all other Pacemaker daemons. * - .. _pcmk_fail_fast: .. index:: pair: node option; PCMK_fail_fast PCMK_fail_fast - :ref:`boolean ` - no - By default, if a Pacemaker subsystem crashes, the main ``pacemakerd`` process will attempt to restart it. If this variable is set to ``yes``, ``pacemakerd`` will panic the local host instead. * - .. _pcmk_panic_action: .. index:: pair: node option; PCMK_panic_action PCMK_panic_action - :ref:`enumeration ` - reboot - Pacemaker will panic the local host under certain conditions. By default, this means rebooting the host. This variable can change that behavior: if ``crash``, trigger a kernel crash (useful if you want a kernel dump to investigate); if ``sync-reboot`` or ``sync-crash``, synchronize filesystems before rebooting the host or triggering a kernel crash. The sync values are more likely to preserve log messages, but with the risk that the host may be left active if the synchronization hangs. * - .. _pcmk_authkey_location: .. index:: pair: node option; PCMK_authkey_location PCMK_authkey_location - :ref:`text ` - |PCMK_AUTHKEY_FILE| - Use the contents of this file as the authorization key to use with Pacemaker Remote connections. This file must be readable by Pacemaker daemons (that is, it must allow read permissions to either the |CRM_DAEMON_USER| user or the |CRM_DAEMON_GROUP| group), and its contents must be identical on all nodes. * - .. _pcmk_remote_address: .. index:: pair: node option; PCMK_remote_address PCMK_remote_address - :ref:`text ` - - By default, if the Pacemaker Remote service is run on the local node, it will listen for connections on all IP addresses. This may be set to one address to listen on instead, as a resolvable hostname or as a numeric IPv4 or IPv6 address. When resolving names or listening on all addresses, IPv6 will be preferred if available. When listening on an IPv6 address, IPv4 clients will be supported via IPv4-mapped IPv6 addresses. Example: ``PCMK_remote_address="192.0.2.1"`` * - .. _pcmk_remote_port: .. index:: pair: node option; PCMK_remote_port PCMK_remote_port - :ref:`port ` - 3121 - Use this TCP port number for Pacemaker Remote node connections. This value must be the same on all nodes. * - .. _pcmk_remote_pid1: .. index:: pair: node option; PCMK_remote_pid1 PCMK_remote_pid1 - :ref:`enumeration ` - default - *Advanced Use Only:* When a bundle resource's ``run-command`` option is left to default, Pacemaker Remote runs as PID 1 in the bundle's containers. When it does so, it loads environment variables from the container's |PCMK_INIT_ENV_FILE| and performs the PID 1 responsibility of reaping dead subprocesses. This option controls whether those actions are performed when Pacemaker Remote is not running as PID 1. It is intended primarily for developer testing but can be useful when ``run-command`` is set to a separate, custom PID 1 process that launches Pacemaker Remote. * ``full``: Pacemaker Remote loads environment variables from |PCMK_INIT_ENV_FILE| and reaps dead subprocesses. * ``vars``: Pacemaker Remote loads environment variables from |PCMK_INIT_ENV_FILE| but does not reap dead subprocesses. * ``default``: Pacemaker Remote performs neither action. If Pacemaker Remote is running as PID 1, this option is ignored, and the behavior is the same as for ``full``. * - .. _pcmk_tls_priorities: .. index:: pair: node option; PCMK_tls_priorities PCMK_tls_priorities - :ref:`text ` - |PCMK_GNUTLS_PRIORITIES| - *Advanced Use Only:* These GnuTLS cipher priorities will be used for TLS connections (whether for Pacemaker Remote connections or remote CIB access, when enabled). See: https://gnutls.org/manual/html_node/Priority-Strings.html Pacemaker will append ``":+ANON-DH"`` for remote CIB access and ``":+DHE-PSK:+PSK"`` for Pacemaker Remote connections, as they are required for the respective functionality. Example: ``PCMK_tls_priorities="SECURE128:+SECURE192"`` * - .. _pcmk_dh_min_bits: .. index:: pair: node option; PCMK_dh_min_bits PCMK_dh_min_bits - :ref:`nonnegative integer ` - 0 (no minimum) - *Advanced Use Only:* Set a lower bound on the bit length of the prime number generated for Diffie-Hellman parameters needed by TLS connections. The default is no minimum. The server (Pacemaker Remote daemon, or CIB manager configured to accept remote clients) will use this value to provide a floor for the value recommended by the GnuTLS library. The library will only accept a limited number of specific values, which vary by library version, so setting these is recommended only when required for compatibility with specific client versions. Clients (connecting cluster nodes or remote CIB commands) will require that the server use a prime of at least this size. This is recommended only when the value must be lowered in order for the client's GnuTLS library to accept a connection to an older server. * - .. _pcmk_dh_max_bits: .. index:: pair: node option; PCMK_dh_max_bits PCMK_dh_max_bits - :ref:`nonnegative integer ` - 0 (no maximum) - *Advanced Use Only:* Set an upper bound on the bit length of the prime number generated for Diffie-Hellman parameters needed by TLS connections. The default is no maximum. The server (Pacemaker Remote daemon, or CIB manager configured to accept remote clients) will use this value to provide a ceiling for the value recommended by the GnuTLS library. The library will only accept a limited number of specific values, which vary by library version, so setting these is recommended only when required for compatibility with specific client versions. Clients do not use ``PCMK_dh_max_bits``. * - .. _pcmk_ipc_type: .. index:: pair: node option; PCMK_ipc_type PCMK_ipc_type - :ref:`enumeration ` - shared-mem - *Advanced Use Only:* Force use of a particular IPC method. Allowed values: * ``shared-mem`` * ``socket`` * ``posix`` * ``sysv`` * - .. _pcmk_ipc_buffer: .. index:: pair: node option; PCMK_ipc_buffer PCMK_ipc_buffer - :ref:`nonnegative integer ` - 131072 - *Advanced Use Only:* Specify an IPC buffer size in bytes. This can be useful when connecting to large clusters that result in messages exceeding the default size (which will also result in log messages referencing this variable). * - .. _pcmk_cluster_type: .. index:: pair: node option; PCMK_cluster_type PCMK_cluster_type - :ref:`enumeration ` - corosync - *Advanced Use Only:* Specify the cluster layer to be used. If unset, Pacemaker will detect and use a supported cluster layer, if available. Currently, ``"corosync"`` is the only supported cluster layer. If multiple layers are supported in the future, this will allow overriding Pacemaker's automatic detection to select a specific one. * - .. _pcmk_schema_directory: .. index:: pair: node option; PCMK_schema_directory PCMK_schema_directory - :ref:`text ` - |CRM_SCHEMA_DIRECTORY| - *Advanced Use Only:* Specify an alternate location for RNG schemas and XSL transforms. * - .. _pcmk_remote_schema_directory: .. index:: pair: node option; PCMK_remote_schema_directory PCMK_remote_schema_directory - :ref:`text ` - |PCMK__REMOTE_SCHEMA_DIR| - *Advanced Use Only:* Specify an alternate location on Pacemaker Remote nodes for storing newer RNG schemas and XSL transforms fetched from the cluster. * - .. _pcmk_valgrind_enabled: .. index:: pair: node option; PCMK_valgrind_enabled PCMK_valgrind_enabled - :ref:`enumeration ` - no - *Advanced Use Only:* Whether subsystem daemons should be run under ``valgrind``. Allowed values are the same as for ``PCMK_debug``. * - .. _pcmk_callgrind_enabled: .. index:: pair: node option; PCMK_callgrind_enabled PCMK_callgrind_enabled - :ref:`enumeration ` - no - *Advanced Use Only:* Whether subsystem daemons should be run under ``valgrind`` with the ``callgrind`` tool enabled. Allowed values are the same as for ``PCMK_debug``. * - .. _sbd_sync_resource_startup: .. index:: pair:: node option; SBD_SYNC_RESOURCE_STARTUP SBD_SYNC_RESOURCE_STARTUP - :ref:`boolean ` - - If true, ``pacemakerd`` waits for a ping from ``sbd`` during startup before starting other Pacemaker daemons, and during shutdown after stopping other Pacemaker daemons but before exiting. Default value is set based on the ``--with-sbd-sync-default`` configure script option. * - .. _sbd_watchdog_timeout: .. index:: pair:: node option; SBD_WATCHDOG_TIMEOUT SBD_WATCHDOG_TIMEOUT - :ref:`duration ` - - If the ``stonith-watchdog-timeout`` cluster property is set to a negative or invalid value, use double this value as the default if positive, or use 0 as the default otherwise. This value must be greater than the value of ``stonith-watchdog-timeout`` if both are set. * - .. _valgrind_opts: .. index:: pair: node option; VALGRIND_OPTS VALGRIND_OPTS - :ref:`text ` - - *Advanced Use Only:* Pass these options to valgrind, when enabled (see ``valgrind(1)``). ``"--vgdb=no"`` should usually be specified because ``pacemaker-execd`` can lower privileges when executing commands, which would otherwise leave a bunch of unremovable files in ``/tmp``. diff --git a/doc/sphinx/Pacemaker_Explained/reusing-configuration.rst b/doc/sphinx/Pacemaker_Explained/reusing-configuration.rst index 06c00f0a99..39f736fcfd 100644 --- a/doc/sphinx/Pacemaker_Explained/reusing-configuration.rst +++ b/doc/sphinx/Pacemaker_Explained/reusing-configuration.rst @@ -1,420 +1,426 @@ Reusing Parts of the Configuration ---------------------------------- Pacemaker provides multiple ways to simplify the configuration XML by reusing parts of it in multiple places. Besides simplifying the XML, this also allows you to manipulate multiple configuration elements with a single reference. Reusing Resource Definitions ############################ If you want to create lots of resources with similar configurations, defining a *resource template* simplifies the task. Once defined, it can be referenced in primitives or in certain types of constraints. Configuring Resources with Templates ____________________________________ The primitives referencing the template will inherit all meta-attributes, instance attributes, utilization attributes and operations defined in the template. And you can define specific attributes and operations for any of the primitives. If any of these are defined in both the template and the primitive, the values defined in the primitive will take precedence over the ones defined in the template. Hence, resource templates help to reduce the amount of configuration work. If any changes are needed, they can be done to the template definition and will take effect globally in all resource definitions referencing that template. Resource templates have a syntax similar to that of primitives. .. topic:: Resource template for a migratable Xen virtual machine .. code-block:: xml Once you define a resource template, you can use it in primitives by specifying the ``template`` property. .. topic:: Xen primitive resource using a resource template .. code-block:: xml In the example above, the new primitive ``vm1`` will inherit everything from ``vm-template``. For example, the equivalent of the above two examples would be: .. topic:: Equivalent Xen primitive resource not using a resource template .. code-block:: xml If you want to overwrite some attributes or operations, add them to the particular primitive's definition. .. topic:: Xen resource overriding template values .. code-block:: xml In the example above, the new primitive ``vm2`` has special attribute values. Its ``monitor`` operation has a longer ``timeout`` and ``interval``, and the primitive has an additional ``stop`` operation. To see the resulting definition of a resource, run: .. code-block:: none # crm_resource --query-xml --resource vm2 To see the raw definition of a resource in the CIB, run: .. code-block:: none # crm_resource --query-xml-raw --resource vm2 Using Templates in Constraints ______________________________ A resource template can be referenced in the following types of constraints: - ``order`` constraints (see :ref:`s-resource-ordering`) - ``colocation`` constraints (see :ref:`s-resource-colocation`) - ``rsc_ticket`` constraints (for multi-site clusters as described in :ref:`ticket-constraints`) Resource templates referenced in constraints stand for all primitives which are derived from that template. This means, the constraint applies to all primitive resources referencing the resource template. Referencing resource templates in constraints is an alternative to resource sets and can simplify the cluster configuration considerably. For example, given the example templates earlier in this chapter: .. code-block:: xml would colocate all VMs with ``base-rsc`` and is the equivalent of the following constraint configuration: .. code-block:: xml .. note:: In a colocation constraint, only one template may be referenced from either ``rsc`` or ``with-rsc``; the other reference must be a regular resource. Using Templates in Resource Sets ________________________________ Resource templates can also be referenced in resource sets. For example, given the example templates earlier in this section, then: .. code-block:: xml is the equivalent of the following constraint using a sequential resource set: .. code-block:: xml Or, if the resources referencing the template can run in parallel, then: .. code-block:: xml is the equivalent of the following constraint configuration: .. code-block:: xml .. _s-reusing-config-elements: Reusing Rules, Options and Sets of Operations ############################################# Sometimes a number of constraints need to use the same set of rules, and resources need to set the same options and parameters. To simplify this situation, you can refer to an existing object using an ``id-ref`` instead of an ``id``. So if for one resource you have .. code-block:: xml Then instead of duplicating the rule for all your other resources, you can instead specify: .. topic:: **Referencing rules from other constraints** .. code-block:: xml .. important:: The cluster will insist that the ``rule`` exists somewhere. Attempting - to add a reference to a non-existing rule will cause a validation - failure, as will attempting to remove a ``rule`` that is referenced + to add a reference to a nonexistent ``id`` will cause a validation failure, + as will attempting to remove a ``rule`` with an ``id`` that is referenced elsewhere. + Some rule syntax is allowed only in + :ref:`certain contexts `. Validation cannot ensure that the + referenced rule is allowed in the context of the rule containing ``id-ref``, + so such errors will be caught (and logged) only after the new configuration + is accepted. It is the administrator's reponsibility to check for these. + The same principle applies for ``meta_attributes`` and ``instance_attributes`` as illustrated in the example below: .. topic:: Referencing attributes, options, and operations from other resources .. code-block:: xml - + ``id-ref`` can similarly be used with ``resource_set`` (in any constraint type), ``nvpair``, and ``operations``. Tagging Configuration Elements ############################## Pacemaker allows you to *tag* any configuration element that has an XML ID. The main purpose of tagging is to support higher-level user interface tools; Pacemaker itself only uses tags within constraints. Therefore, what you can do with tags mostly depends on the tools you use. Configuring Tags ________________ A tag is simply a named list of XML IDs. .. topic:: Tag referencing three resources .. code-block:: xml What you can do with this new tag depends on what your higher-level tools support. For example, a tool might allow you to enable or disable all of the tagged resources at once, or show the status of just the tagged resources. A single configuration element can be listed in any number of tags. .. important:: If listing nodes in a tag, you must list the node's ``id``, not name. Using Tags in Constraints and Resource Sets ___________________________________________ Pacemaker itself only uses tags in constraints. If you supply a tag name instead of a resource name in any constraint, the constraint will apply to all resources listed in that tag. .. topic:: Constraint using a tag .. code-block:: xml In the example above, assuming the ``all-vms`` tag is defined as in the previous example, the constraint will behave the same as: .. topic:: Equivalent constraints without tags .. code-block:: xml A tag may be used directly in the constraint, or indirectly by being listed in a :ref:`resource set ` used in the constraint. When used in a resource set, an expanded tag will honor the set's ``sequential`` property. Filtering With Tags ___________________ The ``crm_mon`` tool can be used to display lots of information about the state of the cluster. On large or complicated clusters, this can include a lot of information, which makes it difficult to find the one thing you are interested in. The ``--resource=`` and ``--node=`` command line options can be used to filter results. In their most basic usage, these options take a single resource or node name. However, they can also be supplied with a tag name to display several objects at once. For instance, given the following CIB section: .. code-block:: xml The following would be output for ``crm_mon --resource=inactive-rscs -r``: .. code-block:: none Cluster Summary: * Stack: corosync * Current DC: cluster02 (version 2.0.4-1.e97f9675f.git.el7-e97f9675f) - partition with quorum * Last updated: Tue Oct 20 16:09:01 2020 * Last change: Tue May 5 12:04:36 2020 by hacluster via crmd on cluster01 * 5 nodes configured * 27 resource instances configured (4 DISABLED) Node List: * Online: [ cluster01 cluster02 ] Full List of Resources: * Clone Set: inactive-clone [inactive-dhcpd] (disabled): * Stopped (disabled): [ cluster01 cluster02 ] * Resource Group: inactive-group (disabled): * inactive-dummy-1 (ocf::pacemaker:Dummy): Stopped (disabled) * inactive-dummy-2 (ocf::pacemaker:Dummy): Stopped (disabled) diff --git a/doc/sphinx/Pacemaker_Explained/rules.rst b/doc/sphinx/Pacemaker_Explained/rules.rst index 484b085e4a..13134daafa 100644 --- a/doc/sphinx/Pacemaker_Explained/rules.rst +++ b/doc/sphinx/Pacemaker_Explained/rules.rst @@ -1,1029 +1,1218 @@ .. index:: single: rule .. _rules: Rules ----- -Rules can be used to make your configuration more dynamic, allowing values to -change depending on the time or the value of a node attribute. Examples of -things rules are useful for: +Rules make a configuration more dynamic, allowing values to depend on +conditions such as time of day or the value of a node attribute. For example, +rules can: * Set a higher value for :ref:`resource-stickiness ` - during working hours, to minimize downtime, and a lower value on weekends, to + during working hours to minimize downtime, and a lower value on weekends to allow resources to move to their most preferred locations when people aren't - around to notice. + around * Automatically place the cluster into maintenance mode during a scheduled - maintenance window. + maintenance window -* Assign certain nodes and resources to a particular department via custom - node attributes and meta-attributes, and add a single location constraint - that restricts the department's resources to run only on those nodes. - -Each constraint type or property set that supports rules may contain one or more -``rule`` elements specifying conditions under which the constraint or properties -take effect. Examples later in this chapter will make this clearer. +* Restrict a particular department's resources to run on certain nodes, as + determined by custom resource meta-attributes and node attributes .. index:: - pair: XML element; rule - -Rule Properties -############### - -.. table:: **Attributes of a rule Element** - :widths: 1 1 3 - - +-----------------+-------------+-------------------------------------------+ - | Attribute | Default | Description | - +=================+=============+===========================================+ - | id | | .. index:: | - | | | pair: rule; id | - | | | | - | | | A unique name for this element (required) | - +-----------------+-------------+-------------------------------------------+ - | role | ``Started`` | .. index:: | - | | | pair: rule; role | - | | | | - | | | The rule is in effect only when the | - | | | resource is in the specified role. | - | | | Allowed values are ``Started``, | - | | | ``Unpromoted``, and ``Promoted``. A rule | - | | | with a ``role`` of ``Promoted`` cannot | - | | | determine the initial location of a clone | - | | | instance and will only affect which of | - | | | the active instances will be promoted. | - +-----------------+-------------+-------------------------------------------+ - | score | | .. index:: | - | | | pair: rule; score | - | | | | - | | | If this rule is used in a location | - | | | constraint and evaluates to true, apply | - | | | this score to the constraint. Only one of | - | | | ``score`` and ``score-attribute`` may be | - | | | used. | - +-----------------+-------------+-------------------------------------------+ - | score-attribute | | .. index:: | - | | | pair: rule; score-attribute | - | | | | - | | | If this rule is used in a location | - | | | constraint and evaluates to true, use the | - | | | value of this node attribute as the score | - | | | to apply to the constraint. Only one of | - | | | ``score`` and ``score-attribute`` may be | - | | | used. | - +-----------------+-------------+-------------------------------------------+ - | boolean-op | ``and`` | .. index:: | - | | | pair: rule; boolean-op | - | | | | - | | | If this rule contains more than one | - | | | condition, a value of ``and`` specifies | - | | | that the rule evaluates to true only if | - | | | all conditions are true, and a value of | - | | | ``or`` specifies that the rule evaluates | - | | | to true if any condition is true. | - +-----------------+-------------+-------------------------------------------+ - -A ``rule`` element must contain one or more conditions. A condition may be an -``expression`` element, a ``date_expression`` element, or another ``rule`` element. + pair: rule; XML element + pair: rule; options +Rule Options +############ -.. index:: - single: rule; node attribute expression - single: node attribute; rule expression - pair: XML element; expression +Each context that supports rules may contain a single ``rule`` element. -.. _node_attribute_expressions: +.. list-table:: **Attributes of a rule Element** + :class: longtable + :widths: 2 2 2 5 + :header-rows: 1 + + * - Name + - Type + - Default + - Description + + * - .. _rule_id: + + .. index:: + pair: rule; id + + id + - :ref:`id ` + - + - A unique name for this element (required) + * - .. _boolean_op: + + .. index:: + pair: rule; boolean-op + + boolean-op + - :ref:`enumeration ` + - ``and`` + - How to combine conditions if this rule contains more than one. Allowed + values: + + * ``and``: the rule is satisfied only if all conditions are satisfied + * ``or``: the rule is satisfied if any condition is satisfied -Node Attribute Expressions -########################## +.. _rule_conditions: -Expressions are rule conditions based on the values of node attributes. +.. index:: + single: rule; conditions + single: rule; contexts -.. table:: **Attributes of an expression Element** - :class: longtable - :widths: 1 2 3 - - +--------------+---------------------------------+-------------------------------------------+ - | Attribute | Default | Description | - +==============+=================================+===========================================+ - | id | | .. index:: | - | | | pair: expression; id | - | | | | - | | | A unique name for this element (required) | - +--------------+---------------------------------+-------------------------------------------+ - | attribute | | .. index:: | - | | | pair: expression; attribute | - | | | | - | | | The node attribute to test (required) | - +--------------+---------------------------------+-------------------------------------------+ - | type | The default type for | .. index:: | - | | ``lt``, ``gt``, ``lte``, and | pair: expression; type | - | | ``gte`` operations is ``number``| | - | | if either value contains a | How the node attributes should be | - | | decimal point character, or | compared. Allowed values are ``string``, | - | | ``integer`` otherwise. The | ``integer`` *(since 2.0.5)*, ``number``, | - | | default type for all other | and ``version``. ``integer`` truncates | - | | operations is ``string``. If a | floating-point values if necessary before | - | | numeric parse fails for either | performing a 64-bit integer comparison. | - | | value, then the values are | ``number`` performs a double-precision | - | | compared as type ``string``. | floating-point comparison | - | | | *(32-bit integer before 2.0.5)*. | - +--------------+---------------------------------+-------------------------------------------+ - | operation | | .. index:: | - | | | pair: expression; operation | - | | | | - | | | The comparison to perform (required). | - | | | Allowed values: | - | | | | - | | | * ``lt:`` True if the node attribute value| - | | | is less than the comparison value | - | | | * ``gt:`` True if the node attribute value| - | | | is greater than the comparison value | - | | | * ``lte:`` True if the node attribute | - | | | value is less than or equal to the | - | | | comparison value | - | | | * ``gte:`` True if the node attribute | - | | | value is greater than or equal to the | - | | | comparison value | - | | | * ``eq:`` True if the node attribute value| - | | | is equal to the comparison value | - | | | * ``ne:`` True if the node attribute value| - | | | is not equal to the comparison value | - | | | * ``defined:`` True if the node has the | - | | | named attribute | - | | | * ``not_defined:`` True if the node does | - | | | not have the named attribute | - +--------------+---------------------------------+-------------------------------------------+ - | value | | .. index:: | - | | | pair: expression; value | - | | | | - | | | User-supplied value for comparison | - | | | (required for operations other than | - | | | ``defined`` and ``not_defined``) | - +--------------+---------------------------------+-------------------------------------------+ - | value-source | ``literal`` | .. index:: | - | | | pair: expression; value-source | - | | | | - | | | How the ``value`` is derived. Allowed | - | | | values: | - | | | | - | | | * ``literal``: ``value`` is a literal | - | | | string to compare against | - | | | * ``param``: ``value`` is the name of a | - | | | resource parameter to compare against | - | | | (only valid in location constraints) | - | | | * ``meta``: ``value`` is the name of a | - | | | resource meta-attribute to compare | - | | | against (only valid in location | - | | | constraints) | - +--------------+---------------------------------+-------------------------------------------+ +Rule Conditions and Contexts +############################ -.. _node-attribute-expressions-special: +A ``rule`` element must contain one or more conditions. A condition is any of +the following, which will be described in more detail later: -In addition to custom node attributes defined by the administrator, the cluster -defines special, built-in node attributes for each node that can also be used -in rule expressions. +* a :ref:`date/time expression ` +* a :ref:`node attribute expression ` +* a :ref:`resource type expression ` +* an :ref:`operation type expression ` +* another ``rule`` (allowing for complex combinations of conditions) -.. table:: **Built-in Node Attributes** - :widths: 1 4 +Each type of condition is allowed only in certain contexts. Although any given +context may contain only one ``rule`` element, that element may contain any +number of conditions, including other ``rule`` elements. + +Rules may be used in the following contexts, which also will be described in +more detail later: + +* a :ref:`location constraint ` +* a :ref:`cluster_property_set ` element (within the + ``crm_config`` element) +* an :ref:`instance_attributes ` element (within an ``alert``, + ``bundle``, ``clone``, ``group``, ``node``, ``op``, ``primitive``, + ``recipient``, or ``template`` element) +* a :ref:`meta_attributes ` element (within an ``alert``, + ``bundle``, ``clone``, ``group``, ``op``, ``op_defaults``, ``primitive``, + ``recipient``, ``rsc_defaults``, or ``template`` element) +* a :ref:`utilization ` element (within a ``node``, ``primitive``, + or ``template`` element) - +---------------+-----------------------------------------------------------+ - | Name | Value | - +===============+===========================================================+ - | #uname | :ref:`Node name ` | - +---------------+-----------------------------------------------------------+ - | #id | Node ID | - +---------------+-----------------------------------------------------------+ - | #kind | Node type. Possible values are ``cluster``, ``remote``, | - | | and ``container``. Kind is ``remote`` for Pacemaker Remote| - | | nodes created with the ``ocf:pacemaker:remote`` resource, | - | | and ``container`` for Pacemaker Remote guest nodes and | - | | bundle nodes | - +---------------+-----------------------------------------------------------+ - | #is_dc | ``true`` if this node is the cluster's Designated | - | | Controller (DC), ``false`` otherwise | - +---------------+-----------------------------------------------------------+ - | #cluster-name | The value of the ``cluster-name`` cluster property, if set| - +---------------+-----------------------------------------------------------+ - | #site-name | The value of the ``site-name`` node attribute, if set, | - | | otherwise identical to ``#cluster-name`` | - +---------------+-----------------------------------------------------------+ - -.. Add_to_above_table_if_released: - - +---------------+-----------------------------------------------------------+ - | #ra-version | The installed version of the resource agent on the node, | - | | as defined by the ``version`` attribute of the | - | | ``resource-agent`` tag in the agent's metadata. Valid only| - | | within rules controlling resource options. This can be | - | | useful during rolling upgrades of a backward-incompatible | - | | resource agent. *(since x.x.x)* | +.. _date_expression: .. index:: single: rule; date/time expression pair: XML element; date_expression Date/Time Expressions ##################### -Date/time expressions are rule conditions based on the current date and time. -A ``date_expression`` element may optionally contain a ``date_spec`` or -``duration`` element depending on the ``operation`` as described below. +The ``date_expression`` element configures a rule condition based on the +current date and time. It is allowed in rules in any context. + +It may contain a ``date_spec`` or ``duration`` element depending on the +``operation`` as described below. .. list-table:: **Attributes of a date_expression Element** :class: longtable :widths: 1 1 1 4 :header-rows: 1 * - Name - Type - Default - Description * - .. _date_expression_id: .. index:: - pair: id; date_expression + pair: date_expression; id id - :ref:`id ` - - A unique name for this element (required) * - .. _date_expression_start: .. index:: - pair: start; date_expression + pair: date_expression; start start - :ref:`ISO 8601 ` - - The beginning of the desired time range. Meaningful with an ``operation`` of ``in_range`` or ``gt``. * - .. _date_expression_end: .. index:: - pair: end; date_expression + pair: date_expression; end end - :ref:`ISO 8601 ` - - The end of the desired time range. Meaningful with an ``operation`` of ``in_range`` or ``lt``. * - .. _date_expression_operation: .. index:: - pair: operation; date_expression + pair: date_expression; operation operation - :ref:`enumeration ` - ``in_range`` - Specifies how to compare the current date/time against a desired time range. Allowed values: - * ``gt:`` The expression passes if the current date/time is after + * ``gt:`` The expression is satisfied if the current date/time is after ``start`` (which is required) - * ``lt:`` The expression passes if the current date/time is before + * ``lt:`` The expression is satisfied if the current date/time is before ``end`` (which is required) - * ``in_range:`` The expression passes if the current date/time is + * ``in_range:`` The expression is satisfied if the current date/time is greater than or equal to ``start`` (if specified) and less than or equal to either ``end`` (if specified) or ``start`` plus the value of the :ref:`duration ` element (if one is contained in the ``date_expression``). At least one of ``start`` or ``end`` must be specified. If both ``end`` and ``duration`` are specified, ``duration`` is ignored. - * ``date_spec:`` The expression passes if the current date/time matches - the specification given in the contained + * ``date_spec:`` The expression is satisfied if the current date/time + matches the specification given in the contained :ref:`date_spec ` element (which is required) .. _date_spec: .. index:: single: date specification pair: XML element; date_spec Date Specifications ___________________ -A ``date_spec`` element is used to create a cron-like expression relating -to time. Each field can contain a single number or range. Any field not -supplied is ignored. - -.. table:: **Attributes of a date_spec Element** - :widths: 1 3 - - +---------------+-----------------------------------------------------------+ - | Attribute | Description | - +===============+===========================================================+ - | id | .. index:: | - | | pair: id; date_spec | - | | | - | | A unique name for this element (required) | - +---------------+-----------------------------------------------------------+ - | seconds | .. index:: | - | | pair: seconds; date_spec | - | | | - | | Allowed values: 0-59 | - +---------------+-----------------------------------------------------------+ - | minutes | .. index:: | - | | pair: minutes; date_spec | - | | | - | | Allowed values: 0-59 | - +---------------+-----------------------------------------------------------+ - | hours | .. index:: | - | | pair: hours; date_spec | - | | | - | | Allowed values: 0-23 (where 0 is midnight and 23 is | - | | 11 p.m.) | - +---------------+-----------------------------------------------------------+ - | monthdays | .. index:: | - | | pair: monthdays; date_spec | - | | | - | | Allowed values: 1-31 (depending on month and year) | - +---------------+-----------------------------------------------------------+ - | weekdays | .. index:: | - | | pair: weekdays; date_spec | - | | | - | | Allowed values: 1-7 (where 1 is Monday and 7 is Sunday) | - +---------------+-----------------------------------------------------------+ - | yeardays | .. index:: | - | | pair: yeardays; date_spec | - | | | - | | Allowed values: 1-366 (depending on the year) | - +---------------+-----------------------------------------------------------+ - | months | .. index:: | - | | pair: months; date_spec | - | | | - | | Allowed values: 1-12 | - +---------------+-----------------------------------------------------------+ - | weeks | .. index:: | - | | pair: weeks; date_spec | - | | | - | | Allowed values: 1-53 (depending on weekyear) | - +---------------+-----------------------------------------------------------+ - | years | .. index:: | - | | pair: years; date_spec | - | | | - | | Year according to the Gregorian calendar | - +---------------+-----------------------------------------------------------+ - | weekyears | .. index:: | - | | pair: weekyears; date_spec | - | | | - | | Year in which the week started; for example, 1 January | - | | 2005 can be specified in ISO 8601 as "2005-001 Ordinal", | - | | "2005-01-01 Gregorian" or "2004-W53-6 Weekly" and thus | - | | would match ``years="2005"`` or ``weekyears="2004"`` | - +---------------+-----------------------------------------------------------+ - | moon | .. index:: | - | | pair: moon; date_spec | - | | | - | | Allowed values are 0-7 (where 0 is the new moon and 4 is | - | | full moon). *(deprecated since 2.1.6)* | - +---------------+-----------------------------------------------------------+ - -For example, ``monthdays="1"`` matches the first day of every month, and -``hours="09-17"`` matches the hours between 9 a.m. and 5 p.m. (inclusive). - -At this time, multiple ranges (e.g. ``weekdays="1,2"`` or ``weekdays="1-2,5-6"``) -are not supported. +A ``date_spec`` element is used within a ``date_expression`` to specify a +combination of dates and times that satisfy the expression. + +.. list-table:: **Attributes of a date_spec Element** + :class: longtable + :widths: 1 1 1 4 + :header-rows: 1 + + * - Name + - Type + - Default + - Description + * - .. _date_spec_id: + + .. index:: + pair: date_spec; id + + id + - :ref:`id ` + - + - A unique name for this element (required) + * - .. _date_spec_seconds: + + .. index:: + pair: date_spec; seconds + + seconds + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current time's + second is within this range. Allowed integers: 0 to 59. + * - .. _date_spec_minutes: + + .. index:: + pair: date_spec; minutes + + minutes + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current time's + minute is within this range. Allowed integers: 0 to 59. + * - .. _date_spec_hours: + + .. index:: + pair: date_spec; hours + + hours + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current time's + hour is within this range. Allowed integers: 0 to 23 where 0 is midnight + and 23 is 11 p.m. + * - .. _date_spec_monthdays: + + .. index:: + pair: date_spec; monthdays + + monthdays + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current date's + day of the month is in this range. Allowed integers: 1 to 31. + * - .. _date_spec_weekdays: + + .. index:: + pair: date_spec; weekdays + + weekdays + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current date's + ordinal day of the week is in this range. Allowed integers: 1-7 (where 1 + is Monday and 7 is Sunday). + * - .. _date_spec_yeardays: + + .. index:: + pair: date_spec; yeardays + + yeardays + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current date's + ordinal day of the year is in this range. Allowed integers: 1-366. + * - .. _date_spec_months: + + .. index:: + pair: date_spec; months + + months + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current date's + month is in this range. Allowed integers: 1-12 where 1 is January and 12 + is December. + * - .. _date_spec_weeks: + + .. index:: + pair: date_spec; weeks + + weeks + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current date's + ordinal week of the year is in this range. Allowed integers: 1-53. + * - .. _date_spec_years: + + .. index:: + pair: date_spec; years + + years + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current date's + year according to the Gregorian calendar is in this range. + * - .. _date_spec_weekyears: + + .. index:: + pair: date_spec; weekyears + + weekyears + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current date's + year in which the week started (according to the ISO 8601 standard) is + in this range. + * - .. _date_spec_moon: + + .. index:: + pair: date_spec; moon + + moon + - :ref:`range ` + - + - If this is set, the expression is satisfied only if the current date's + phase of the moon is in this range. Allowed values are 0 to 7 where 0 is + the new moon and 4 is the full moon. *(deprecated since 2.1.6)* .. note:: Pacemaker can calculate when evaluation of a ``date_expression`` with an ``operation`` of ``gt``, ``lt``, or ``in_range`` will next change, and schedule a cluster re-check for that time. However, it does not do this for ``date_spec``. Instead, it evaluates the ``date_spec`` whenever a cluster re-check naturally happens via a cluster event or the ``cluster-recheck-interval`` cluster option. For example, if you have a ``date_spec`` enabling a resource from 9 a.m. to 5 p.m., and ``cluster-recheck-interval`` has been set to 5 minutes, then sometime between 9 a.m. and 9:05 a.m. the cluster would notice that it needs to start the resource, and sometime between 5 p.m. and 5:05 p.m. it would realize that it needs to stop the resource. The timing of the actual start and stop actions will further depend on factors such as any other actions the cluster may need to perform first, and the load of the machine. .. _duration_element: .. index:: single: duration pair: XML element; duration Durations _________ -A ``duration`` is used to calculate a value for ``end`` when one is not -supplied to ``in_range`` operations. It contains one or more attributes each -containing a single number. Any attribute not supplied is ignored. - -.. table:: **Attributes of a duration Element** - :widths: 1 3 - - +---------------+-----------------------------------------------------------+ - | Attribute | Description | - +===============+===========================================================+ - | id | .. index:: | - | | pair: id; duration | - | | | - | | A unique name for this element (required) | - +---------------+-----------------------------------------------------------+ - | seconds | .. index:: | - | | pair: seconds; duration | - | | | - | | This many seconds will be added to the total duration | - +---------------+-----------------------------------------------------------+ - | minutes | .. index:: | - | | pair: minutes; duration | - | | | - | | This many minutes will be added to the total duration | - +---------------+-----------------------------------------------------------+ - | hours | .. index:: | - | | pair: hours; duration | - | | | - | | This many hours will be added to the total duration | - +---------------+-----------------------------------------------------------+ - | days | .. index:: | - | | pair: days; duration | - | | | - | | This many days will be added to the total duration | - +---------------+-----------------------------------------------------------+ - | weeks | .. index:: | - | | pair: weeks; duration | - | | | - | | This many weeks will be added to the total duration | - +---------------+-----------------------------------------------------------+ - | months | .. index:: | - | | pair: months; duration | - | | | - | | This many months will be added to the total duration | - +---------------+-----------------------------------------------------------+ - | years | .. index:: | - | | pair: years; duration | - | | | - | | This many years will be added to the total duration | - +---------------+-----------------------------------------------------------+ - - -Example Time-Based Expressions -______________________________ - -A small sample of how time-based expressions can be used: - -.. topic:: True if now is any time in the year 2005 +A ``duration`` element is used within a ``date_expression`` to calculate an +ending value for ``in_range`` operations when ``end`` is not supplied. + +.. list-table:: **Attributes of a duration Element** + :class: longtable + :widths: 1 1 1 4 + :header-rows: 1 + + * - Name + - Type + - Default + - Description + * - .. _duration_id: + + .. index:: + pair: duration; id + + id + - :ref:`id ` + - + - A unique name for this element (required) + * - .. _duration_seconds: + + .. index:: + pair: duration; seconds + + seconds + - :ref:`integer ` + - 0 + - Number of seconds to add to the total duration + * - .. _duration_minutes: + + .. index:: + pair: duration; minutes + + minutes + - :ref:`integer ` + - 0 + - Number of minutes to add to the total duration + * - .. _duration_hours: + + .. index:: + pair: duration; hours + + hours + - :ref:`integer ` + - 0 + - Number of hours to add to the total duration + * - .. _duration_days: + + .. index:: + pair: duration; days + + days + - :ref:`integer ` + - 0 + - Number of days to add to the total duration + * - .. _duration_weeks: + + .. index:: + pair: duration; weeks + + weeks + - :ref:`integer ` + - 0 + - Number of weeks to add to the total duration + * - .. _duration_months: + + .. index:: + pair: duration; months + + months + - :ref:`integer ` + - 0 + - Number of months to add to the total duration + * - .. _duration_years: + + .. index:: + pair: duration; years + + years + - :ref:`integer ` + - 0 + - Number of years to add to the total duration + + +Example Date/Time Expressions +_____________________________ + + +.. topic:: Satisfied if the current year is 2005 .. code-block:: xml or equivalently: .. code-block:: xml .. topic:: 9 a.m. to 5 p.m. Monday through Friday .. code-block:: xml Note that the ``16`` matches all the way through ``16:59:59``, because the numeric value of the hour still matches. -.. topic:: 9 a.m. to 6 p.m. Monday through Friday or anytime Saturday +.. topic:: 9 a.m. to 6 p.m. Monday through Friday, or anytime Saturday .. code-block:: xml .. topic:: 9 a.m. to 5 p.m. or 9 p.m. to 12 a.m. Monday through Friday .. code-block:: xml .. topic:: Mondays in March 2005 .. code-block:: xml .. note:: Because no time is specified with the above dates, 00:00:00 is implied. This means that the range includes all of 2005-03-01 but only the first second of 2005-04-01. You may wish to write ``end`` as ``"2005-03-31T23:59:59"`` to avoid confusion. +.. index:: + single: rule; node attribute expression + single: node attribute; rule expression + pair: XML element; expression + +.. _node_attribute_expressions: + +Node Attribute Expressions +########################## + +The ``expression`` element configures a rule condition based on the value of a +node attribute. It is allowed in rules in location constraints and in +``instance_attributes`` elements within ``bundle``, ``clone``, ``group``, +``op``, ``primitive``, and ``template`` elements. + +.. list-table:: **Attributes of an expression Element** + :class: longtable + :widths: 1 1 3 5 + :header-rows: 1 + + * - Name + - Type + - Default + - Description + + * - .. _expression_id: + + .. index:: + pair: expression; id + + id + - :ref:`id ` + - + - A unique name for this element (required) + * - .. _expression_attribute: + + .. index:: + pair: expression; attribute + + attribute + - :ref:`text ` + - + - Name of the node attribute to test (required) + * - .. _expression_operation: + + .. index:: + pair: expression; operation + + operation + - :ref:`enumeration ` + - + - The comparison to perform (required). Allowed values: + + * ``defined:`` The expression is satisfied if the node has the named + attribute + * ``not_defined:`` The expression is satisfied if the node does not have + the named attribute + * ``lt:`` The expression is satisfied if the node attribute value is + less than the reference value + * ``gt:`` The expression is satisfied if the node attribute value is + greater than the reference value + * ``lte:`` The expression is satisfied if the node attribute value is + less than or equal to the reference value + * ``gte:`` The expression is satisfied if the node attribute value is + greater than or equal to the reference value + * ``eq:`` The expression is satisfied if the node attribute value is + equal to the reference value + * ``ne:`` The expression is satisfied if the node attribute value is not + equal to the reference value + * - .. _expression_type: + + .. index:: + pair: expression; type + + type + - :ref:`enumeration ` + - The default type for ``lt``, ``gt``, ``lte``, and ``gte`` operations is + ``number`` if either value contains a decimal point character, or + ``integer`` otherwise. The default type for all other operations is + ``string``. If a numeric parse fails for either value, then the values + are compared as type ``string``. + - How to interpret values. Allowed values are ``string``, ``integer`` + *(since 2.0.5)*, ``number``, and ``version``. ``integer`` truncates + floating-point values if necessary before performing a 64-bit integer + comparison. ``number`` performs a double-precision floating-point + comparison *(32-bit integer before 2.0.5)*. + * - .. _expression_value: + + .. index:: + pair: expression; value + + value + - :ref:`text ` + - + - Reference value to compare node attribute against (used only with, and + required for, operations other than ``defined`` and ``not_defined``) + * - .. _expression_value_source: + + .. index:: + pair: expression; value-source + + value-source + - :ref:`enumeration ` + - ``literal`` + - How the reference value is obtained. Allowed values: + + * ``literal``: ``value`` contains the literal reference value to compare + * ``param``: ``value`` contains the name of a resource parameter to + compare (valid only in the context of a location constraint) + * ``meta``: ``value`` is the name of a resource meta-attribute to + compare (valid only in the context of a location constraint) + +.. _node-attribute-expressions-special: + +In addition to custom node attributes defined by the administrator, the cluster +defines special, built-in node attributes for each node that can also be used +in rule expressions. + +.. list-table:: **Built-in Node Attributes** + :class: longtable + :widths: 1 4 + :header-rows: 1 + + * - Name + - Description + * - #uname + - :ref:`Node name ` + * - #id + - Node ID + * - #kind + - Node type (``cluster`` for cluster nodes, ``remote`` for Pacemaker + Remote nodes created with the ``ocf:pacemaker:remote`` resource, and + ``container`` for Pacemaker Remote guest nodes and bundle nodes) + * - #is_dc + - ``true`` if this node is the cluster's Designated Controller (DC), + ``false`` otherwise + * - #cluster-name + - The value of the ``cluster-name`` cluster property, if set + * - #site-name + - The value of the ``site-name`` node attribute, if set, otherwise + identical to ``#cluster-name`` + + +.. _rsc_expression: + .. index:: single: rule; resource expression single: resource; rule expression pair: XML element; rsc_expression -Resource Expressions -#################### - -An ``rsc_expression`` *(since 2.0.5)* is a rule condition based on a resource -agent's properties. This rule is only valid within an ``rsc_defaults`` or -``op_defaults`` context. None of the matching attributes of ``class``, -``provider``, and ``type`` are required. If one is omitted, all values of that -attribute will match. For instance, omitting ``type`` means every type will -match. - -.. table:: **Attributes of a rsc_expression Element** - :widths: 1 3 - - +---------------+-----------------------------------------------------------+ - | Attribute | Description | - +===============+===========================================================+ - | id | .. index:: | - | | pair: id; rsc_expression | - | | | - | | A unique name for this element (required) | - +---------------+-----------------------------------------------------------+ - | class | .. index:: | - | | pair: class; rsc_expression | - | | | - | | The standard name to be matched against resource agents | - +---------------+-----------------------------------------------------------+ - | provider | .. index:: | - | | pair: provider; rsc_expression | - | | | - | | If given, the vendor to be matched against resource | - | | agents (only relevant when ``class`` is ``ocf``) | - +---------------+-----------------------------------------------------------+ - | type | .. index:: | - | | pair: type; rsc_expression | - | | | - | | The name of the resource agent to be matched | - +---------------+-----------------------------------------------------------+ - -Example Resource-Based Expressions -__________________________________ +Resource Type Expressions +######################### + +The ``rsc_expression`` element *(since 2.0.5)* configures a rule condition +based on the agent used for a resource. It is allowed in rules in a +``meta_attributes`` element within a ``rsc_defaults`` or ``op_defaults`` +element. + +.. list-table:: **Attributes of a rsc_expression Element** + :class: longtable + :widths: 1 1 1 4 + :header-rows: 1 + + * - Name + - Type + - Default + - Description + * - .. _rsc_expression_id: + + .. index:: + pair: rsc_expression; id + + id + - :ref:`id ` + - + - A unique name for this element (required) + * - .. _rsc_expression_class: + + .. index:: + pair: rsc_expression; class -A small sample of how resource-based expressions can be used: + class + - :ref:`text ` + - + - If this is set, the expression is satisfied only if the resource's agent + standard matches this value + * - .. _rsc_expression_provider: -.. topic:: True for all ``ocf:heartbeat:IPaddr2`` resources + .. index:: + pair: rsc_expression; provider + + provider + - :ref:`text ` + - + - If this is set, the expression is satisfied only if the resource's agent + provider matches this value + * - .. _rsc_expression_type: + + .. index:: + pair: rsc_expression; type + + type + - :ref:`text ` + - + - If this is set, the expression is satisfied only if the resource's agent + type matches this value + + +Example Resource Type Expressions +_________________________________ + +.. topic:: Satisfied for ``ocf:heartbeat:IPaddr2`` resources .. code-block:: xml -.. topic:: Provider doesn't apply to non-OCF resources +.. topic:: Satisfied for ``stonith:fence_xvm`` resources .. code-block:: xml +.. _op_expression: + .. index:: single: rule; operation expression single: operation; rule expression pair: XML element; op_expression -Operation Expressions -##################### +Operation Type Expressions +########################## +The ``op_expression`` element *(since 2.0.5)* configures a rule condition based +on a resource operation name and interval. It is allowed in rules in a +``meta_attributes`` element within an ``op_defaults`` element. -An ``op_expression`` *(since 2.0.5)* is a rule condition based on an action of -some resource agent. This rule is only valid within an ``op_defaults`` context. - -.. table:: **Attributes of an op_expression Element** - :widths: 1 3 - - +---------------+-----------------------------------------------------------+ - | Attribute | Description | - +===============+===========================================================+ - | id | .. index:: | - | | pair: id; op_expression | - | | | - | | A unique name for this element (required) | - +---------------+-----------------------------------------------------------+ - | name | .. index:: | - | | pair: name; op_expression | - | | | - | | The action name to match against. This can be any action | - | | supported by the resource agent; common values include | - | | ``monitor``, ``start``, and ``stop`` (required). | - +---------------+-----------------------------------------------------------+ - | interval | .. index:: | - | | pair: interval; op_expression | - | | | - | | The interval of the action to match against. If not given,| - | | only the name attribute will be used to match. | - +---------------+-----------------------------------------------------------+ - -Example Operation-Based Expressions -___________________________________ - -A small sample of how operation-based expressions can be used: - -.. topic:: True for all monitor actions +.. list-table:: **Attributes of an op_expression Element** + :class: longtable + :widths: 1 1 1 4 + :header-rows: 1 + + * - Name + - Type + - Default + - Description + * - .. _op_expression_id: + + .. index:: + pair: op_expression; id + + id + - :ref:`id ` + - + - A unique name for this element (required) + * - .. _op_expression_name: + + .. index:: + pair: op_expression; name + + name + - :ref:`text ` + - + - The expression is satisfied only if the operation's name matches this + value (required) + * - .. _op_expression_interval: + + .. index:: + pair: op_expression; interval + + interval + - :ref:`duration ` + - + - If this is set, the expression is satisfied only if the operation's + interval matches this value + + +Example Operation Type Expressions +__________________________________ + +.. topic:: Expression is satisfied for all monitor actions .. code-block:: xml -.. topic:: True for all monitor actions with a 10 second interval +.. topic:: Expression is satisfied for all monitor actions with a 10-second interval .. code-block:: xml +.. _location_rule: + .. index:: pair: location constraint; rule Using Rules to Determine Resource Location ########################################## -A location constraint may contain one or more top-level rules. The cluster will -act as if there is a separate location constraint for each rule that evaluates -as true. +If a :ref:`location constraint ` contains a rule, the +cluster will apply the constraint to all nodes where the rule is satisfied. +This acts as if identical location constraints without rules were defined for +each of the nodes. + +In the context of a location constraint, ``rule`` elements may take additional +attributes. These have an effect only when set for the constraint's top-level +``rule``; they are ignored if set on a subrule. + +.. list-table:: **Extra Attributes of a rule Element in a Location Constraint** + :class: longtable + :widths: 2 2 1 5 + :header-rows: 1 + + * - Name + - Type + - Default + - Description + + * - .. _rule_role: + + .. index:: + pair: rule; role + + role + - :ref:`enumeration ` + - ``Started`` + - If this is set in the constraint's top-level rule, the constraint acts + as if ``role`` were set to this in the ``rsc_location`` element. + + * - .. _rule_score: + + .. index:: + pair: rule; score + + score + - :ref:`score ` + - + - If this is set in the constraint's top-level rule, the constraint acts + as if ``score`` were set to this in the ``rsc_location`` element. + Only one of ``score`` and ``score-attribute`` may be set. + + * - .. _rule_score_attribute: + + .. index:: + pair: rule; score-attribute + + score-attribute + - :ref:`text ` + - + - If this is set in the constraint's top-level rule, the constraint acts + as if ``score`` were set to the value of this node attribute on each + node where the rule is satisfied. Only one of ``score`` and + ``score-attribute`` may be set. Consider the following simple location constraint: .. topic:: Prevent resource ``webserver`` from running on node ``node3`` .. code-block:: xml -The same constraint can be more verbosely written using a rule: +The same constraint can be written more verbosely using a rule: .. topic:: Prevent resource ``webserver`` from running on node ``node3`` using a rule .. code-block:: xml The advantage of using the expanded form is that one could add more expressions -(for example, limiting the constraint to certain days of the week), or activate -the constraint by some node attribute other than node name. +(for example, limiting the constraint to certain days of the week). Location Rules Based on Other Node Properties _____________________________________________ -The expanded form allows us to match on node properties other than its name. -If we rated each machine's CPU power such that the cluster had the following -nodes section: +The expanded form allows us to match node attributes other than its name. As an +example, consider this configuration of custom node attributes specifying each +node's CPU capacity: .. topic:: Sample node section with node attributes .. code-block:: xml -then we could prevent resources from running on underpowered machines with this -rule: +We can use a rule to prevent a resource from running on underpowered machines: .. topic:: Rule using a node attribute (to be used inside a location constraint) .. code-block:: xml Using ``score-attribute`` Instead of ``score`` ______________________________________________ When using ``score-attribute`` instead of ``score``, each node matched by the -rule has its score adjusted differently, according to its value for the named -node attribute. Thus, in the previous example, if a rule inside a location -constraint for a resource used ``score-attribute="cpu_mips"``, ``c001n01`` -would have its preference to run the resource increased by ``1234`` whereas -``c001n02`` would have its preference increased by ``5678``. +rule has its score adjusted according to its value for the named node +attribute. + +In the previous example, if the location constraint rule used +``score-attribute="cpu_mips"`` instead of ``score="-INFINITY"``, node +``c001n01`` would have its preference to run the resource increased by 1234 +whereas node ``c001n02`` would have its preference increased by 5678. .. _s-rsc-pattern-rules: Specifying location scores using pattern submatches ___________________________________________________ -Location constraints may use ``rsc-pattern`` to apply the constraint to all -resources whose IDs match the given pattern (see :ref:`s-rsc-pattern`). The -pattern may contain up to 9 submatches in parentheses, whose values may be used -as ``%1`` through ``%9`` in a rule's ``score-attribute`` or a rule expression's -``attribute``. +Location constraints may use :ref:`rsc-pattern ` to apply the +constraint to all resources whose IDs match the given pattern. The pattern may +contain up to 9 submatches in parentheses, whose values may be used as ``%1`` +through ``%9`` in a ``rule`` element's ``score-attribute`` or an ``expression`` +element's ``attribute``. -As an example, the following configuration (only relevant parts are shown) -gives the resources **server-httpd** and **ip-httpd** a preference of 100 on -**node1** and 50 on **node2**, and **ip-gateway** a preference of -100 on -**node1** and 200 on **node2**. +For example, the following configuration excerpt gives the resources +**server-httpd** and **ip-httpd** a preference of 100 on node1 and 50 on node2, +and **ip-gateway** a preference of -100 on node1 and 200 on node2. .. topic:: Location constraint using submatches .. code-block:: xml +.. _option_rule: + .. index:: pair: cluster option; rule pair: instance attribute; rule pair: meta-attribute; rule pair: resource defaults; rule pair: operation defaults; rule pair: node attribute; rule Using Rules to Define Options ############################# Rules may be used to control a variety of options: -* :ref:`Cluster options ` (``cluster_property_set`` elements) -* :ref:`Node attributes ` (``instance_attributes`` or +* :ref:`Cluster options ` (as ``cluster_property_set`` + elements) +* :ref:`Node attributes ` (as ``instance_attributes`` or ``utilization`` elements inside a ``node`` element) -* :ref:`Resource options ` (``utilization``, +* :ref:`Resource options ` (as ``utilization``, ``meta_attributes``, or ``instance_attributes`` elements inside a resource definition element or ``op`` , ``rsc_defaults``, ``op_defaults``, or ``template`` element) -* :ref:`Operation properties ` (``meta_attributes`` +* :ref:`Operation options ` (as ``meta_attributes`` elements inside an ``op`` or ``op_defaults`` element) +* :ref:`Alert options ` (as ``instance_attributes`` or + ``meta_attributes`` elements inside an ``alert`` or ``recipient`` element) -.. note:: - - Attribute-based expressions for meta-attributes can only be used within - ``operations`` and ``op_defaults``. They will not work with resource - configuration or ``rsc_defaults``. Additionally, attribute-based - expressions cannot be used with cluster options. Using Rules to Control Resource Options _______________________________________ Often some cluster nodes will be different from their peers. Sometimes, -these differences -- e.g. the location of a binary or the names of network -interfaces -- require resources to be configured differently depending +these differences (for example, the location of a binary, or the names of +network interfaces) require resources to be configured differently depending on the machine they're hosted on. -By defining multiple ``instance_attributes`` objects for the resource and +By defining multiple ``instance_attributes`` elements for the resource and adding a rule to each, we can easily handle these special cases. In the example below, ``mySpecialRsc`` will use eth1 and port 9999 when run on -``node1``, eth2 and port 8888 on ``node2`` and default to eth0 and port 9999 -for all other nodes. +node1, eth2 and port 8888 on node2 and default to eth0 and port 9999 for all +other nodes. .. topic:: Defining different resource options based on the node name .. code-block:: xml -The order in which ``instance_attributes`` objects are evaluated is determined -by their score (highest to lowest). If not supplied, the score defaults to -zero. Objects with an equal score are processed in their listed order. If the -``instance_attributes`` object has no rule, or a ``rule`` that evaluates to -``true``, then for any parameter the resource does not yet have a value for, -the resource will use the parameter values defined by the ``instance_attributes``. +Multiple ``instance_attributes`` elements are evaluated from highest score to +lowest. If not supplied, the score defaults to zero. Objects with equal scores +are processed in their listed order. If an ``instance_attributes`` object has +no rule or a satisfied ``rule``, then for any parameter the resource does not +yet have a value for, the resource will use the value defined by the +``instance_attributes``. For example, given the configuration above, if the resource is placed on ``node1``: * ``special-node1`` has the highest score (3) and so is evaluated first; its - rule evaluates to ``true``, so ``interface`` is set to ``eth1``. -* ``special-node2`` is evaluated next with score 2, but its rule evaluates to - ``false``, so it is ignored. + rule is satisfied, so ``interface`` is set to ``eth1``. +* ``special-node2`` is evaluated next with score 2, but its rule is not + satisfied, so it is ignored. * ``defaults`` is evaluated last with score 1, and has no rule, so its values are examined; ``interface`` is already defined, so the value here is not used, but ``port`` is not yet defined, so ``port`` is set to ``9999``. Using Rules to Control Resource Defaults ________________________________________ -Rules can be used for resource and operation defaults. The following example -illustrates how to set a different ``resource-stickiness`` value during and -outside work hours. This allows resources to automatically move back to their -most preferred hosts, but at a time that (in theory) does not interfere with -business activities. +Rules can be used for resource and operation defaults. + +The following example illustrates how to set a different +``resource-stickiness`` value during and outside work hours. This allows +resources to automatically move back to their most preferred hosts, but at a +time that (in theory) does not interfere with business activities. .. topic:: Change ``resource-stickiness`` during working hours .. code-block:: xml -Rules may be used similarly in ``instance_attributes`` or ``utilization`` -blocks. - -Any single block may directly contain only a single rule, but that rule may -itself contain any number of rules. - -``rsc_expression`` and ``op_expression`` blocks may additionally be used to -set defaults on either a single resource or across an entire class of resources -with a single rule. ``rsc_expression`` may be used to select resource agents -within both ``rsc_defaults`` and ``op_defaults``, while ``op_expression`` may -only be used within ``op_defaults``. If multiple rules succeed for a given -resource agent, the last one specified will be the one that takes effect. As -with any other rule, boolean operations may be used to make more complicated -expressions. +``rsc_expression`` is valid within both ``rsc_defaults`` and ``op_defaults``; +``op_expression`` is valid only within ``op_defaults``. .. topic:: Default all IPaddr2 resources to stopped .. code-block:: xml .. topic:: Default all monitor action timeouts to 7 seconds .. code-block:: xml .. topic:: Default the timeout on all 10-second-interval monitor actions on ``IPaddr2`` resources to 8 seconds .. code-block:: xml .. index:: pair: rule; cluster option Using Rules to Control Cluster Options ______________________________________ Controlling cluster options is achieved in much the same manner as specifying different resource options on different nodes. The following example illustrates how to set ``maintenance_mode`` during a scheduled maintenance window. This will keep the cluster running but not monitor, start, or stop resources during this time. .. topic:: Schedule a maintenance window for 9 to 11 p.m. CDT Sept. 20, 2019 .. code-block:: xml .. important:: The ``cluster_property_set`` with an ``id`` set to "cib-bootstrap-options" will *always* have the highest priority, regardless of any scores. Therefore, rules in another ``cluster_property_set`` can never take effect for any properties listed in the bootstrap set.