Chapter 13. Configuring a high-availability cluster by using RHEL system roles With the ha_cluster system role, you can configure and manage a high-availability cluster that uses the Pacemaker high availability cluster resource manager. 13.1. Variables of the ha_cluster RHEL system role In an ha_cluster RHEL system role playbook, you define the variables for a high availability cluster according to the requirements of your cluster deployment. The variables you can set for an ha_cluster RHEL system role are as follows: ha_cluster_enable_repos A boolean flag that enables the repositories containing the packages that are needed by the ha_cluster RHEL system role. When this variable is set to true , the default value, you must have active subscription coverage for RHEL and the RHEL High Availability Add-On on the systems that you will use as your cluster members or the system role will fail. ha_cluster_enable_repos_resilient_storage (RHEL 9.4 and later) A boolean flag that enables the repositories containing resilient storage packages, such as dlm or gfs2 . For this option to take effect, ha_cluster_enable_repos must be set to true . The default value of this variable is false . ha_cluster_manage_firewall (RHEL 9.2 and later) A boolean flag that determines whether the ha_cluster RHEL system role manages the firewall. When ha_cluster_manage_firewall is set to true , the firewall high availability service and the fence-virt port are enabled. When ha_cluster_manage_firewall is set to false , the ha_cluster RHEL system role does not manage the firewall. If your system is running the firewalld service, you must set the parameter to true in your playbook. You can use the ha_cluster_manage_firewall parameter to add ports, but you cannot use the parameter to remove ports. To remove ports, use the firewall system role directly. As of RHEL 9.2, the firewall is no longer configured by default, because it is configured only when ha_cluster_manage_firewall is set to true . ha_cluster_manage_selinux (RHEL 9.2 and later) A boolean flag that determines whether the ha_cluster RHEL system role manages the ports belonging to the firewall high availability service using the selinux RHEL system role. When ha_cluster_manage_selinux is set to true , the ports belonging to the firewall high availability service are associated with the SELinux port type cluster_port_t . When ha_cluster_manage_selinux is set to false , the ha_cluster RHEL system role does not manage SELinux. If your system is running the selinux service, you must set this parameter to true in your playbook. Firewall configuration is a prerequisite for managing SELinux. If the firewall is not installed, the managing SELinux policy is skipped. You can use the ha_cluster_manage_selinux parameter to add policy, but you cannot use the parameter to remove policy. To remove policy, use the selinux RHEL system role directly. ha_cluster_cluster_present A boolean flag which, if set to true , determines that HA cluster will be configured on the hosts according to the variables passed to the role. Any cluster configuration not specified in the playbook and not supported by the role will be lost. If ha_cluster_cluster_present is set to false , all HA cluster configuration will be removed from the target hosts. The default value of this variable is true . The following example playbook removes all cluster configuration on node1 and node2 ha_cluster_start_on_boot A boolean flag that determines whether cluster services will be configured to start on boot. The default value of this variable is true . ha_cluster_install_cloud_agents (RHEL 9.5 and later) A boolean flag that determines whether resource and fence agents for cloud environments are installed. These agents are not installed by default. Alternately, you can specify the packages for cloud environments by using the ha_cluster_fence_agent_packages and ha_cluster_extra_packages variables. The default value of this variable is false . ha_cluster_fence_agent_packages List of fence agent packages to install. The default value of this variable is fence-agents-all , fence-virt . ha_cluster_extra_packages List of additional packages to be installed. The default value of this variable is no packages. This variable can be used to install additional packages not installed automatically by the role, for example custom resource agents. It is possible to specify fence agents as members of this list. However, ha_cluster_fence_agent_packages is the recommended role variable to use for specifying fence agents, so that its default value is overridden. ha_cluster_hacluster_password A string value that specifies the password of the hacluster user. The hacluster user has full access to a cluster. To protect sensitive data, vault encrypt the password, as described in Encrypting content with Ansible Vault . There is no default password value, and this variable must be specified. ha_cluster_hacluster_qdevice_password (RHEL 9.3 and later) A string value that specifies the password of the hacluster user for a quorum device. This parameter is needed only if the ha_cluster_quorum parameter is configured to use a quorum device of type net and the password of the hacluster user on the quorum device is different from the password of the hacluster user specified with the ha_cluster_hacluster_password parameter. The hacluster user has full access to a cluster. To protect sensitive data, vault encrypt the password, as described in Encrypting content with Ansible Vault . There is no default value for this password. ha_cluster_corosync_key_src The path to Corosync authkey file, which is the authentication and encryption key for Corosync communication. It is highly recommended that you have a unique authkey value for each cluster. The key should be 256 bytes of random data. If you specify a key for this variable, it is recommended that you vault encrypt the key, as described in Encrypting content with Ansible Vault . If no key is specified, a key already present on the nodes will be used. If nodes do not have the same key, a key from one node will be distributed to other nodes so that all nodes have the same key. If no node has a key, a new key will be generated and distributed to the nodes. If this variable is set, ha_cluster_regenerate_keys is ignored for this key. The default value of this variable is null. ha_cluster_pacemaker_key_src The path to the Pacemaker authkey file, which is the authentication and encryption key for Pacemaker communication. It is highly recommended that you have a unique authkey value for each cluster. The key should be 256 bytes of random data. If you specify a key for this variable, it is recommended that you vault encrypt the key, as described in Encrypting content with Ansible Vault . If no key is specified, a key already present on the nodes will be used. If nodes do not have the same key, a key from one node will be distributed to other nodes so that all nodes have the same key. If no node has a key, a new key will be generated and distributed to the nodes. If this variable is set, ha_cluster_regenerate_keys is ignored for this key. The default value of this variable is null. ha_cluster_fence_virt_key_src The path to the fence-virt or fence-xvm pre-shared key file, which is the location of the authentication key for the fence-virt or fence-xvm fence agent. If you specify a key for this variable, it is recommended that you vault encrypt the key, as described in Encrypting content with Ansible Vault . If no key is specified, a key already present on the nodes will be used. If nodes do not have the same key, a key from one node will be distributed to other nodes so that all nodes have the same key. If no node has a key, a new key will be generated and distributed to the nodes. If the ha_cluster RHEL system role generates a new key in this fashion, you should copy the key to your nodes' hypervisor to ensure that fencing works. If this variable is set, ha_cluster_regenerate_keys is ignored for this key. The default value of this variable is null. ha_cluster_pcsd_public_key_srcr , ha_cluster_pcsd_private_key_src The path to the pcsd TLS certificate and private key. If this is not specified, a certificate-key pair already present on the nodes will be used. If a certificate-key pair is not present, a random new one will be generated. If you specify a private key value for this variable, it is recommended that you vault encrypt the key, as described in Encrypting content with Ansible Vault . If these variables are set, ha_cluster_regenerate_keys is ignored for this certificate-key pair. The default value of these variables is null. ha_cluster_pcsd_certificates (RHEL 9.2 and later) Creates a pcsd private key and certificate using the certificate RHEL system role. If your system is not configured with a pcsd private key and certificate, you can create them in one of two ways: Set the ha_cluster_pcsd_certificates variable. When you set the ha_cluster_pcsd_certificates variable, the certificate RHEL system role is used internally and it creates the private key and certificate for pcsd as defined. Do not set the ha_cluster_pcsd_public_key_src , ha_cluster_pcsd_private_key_src , or the ha_cluster_pcsd_certificates variables. If you do not set any of these variables, the ha_cluster RHEL system role will create pcsd certificates by means of pcsd itself. The value of ha_cluster_pcsd_certificates is set to the value of the variable certificate_requests as specified in the certificate RHEL system role. For more information about the certificate RHEL system role, see Requesting certificates using RHEL system roles . The following operational considerations apply to the use of the ha_cluster_pcsd_certificate variable: Unless you are using IPA and joining the systems to an IPA domain, the certificate RHEL system role creates self-signed certificates. In this case, you must explicitly configure trust settings outside of the context of RHEL system roles. System roles do not support configuring trust settings. When you set the ha_cluster_pcsd_certificates variable, do not set the ha_cluster_pcsd_public_key_src and ha_cluster_pcsd_private_key_src variables. When you set the ha_cluster_pcsd_certificates variable, ha_cluster_regenerate_keys is ignored for this certificate - key pair. The default value of this variable is [] . For an example ha_cluster RHEL system role playbook that creates TLS certificates and key files in a high availability cluster, see Creating pcsd TLS certificates and key files for a high availability cluster . ha_cluster_regenerate_keys A boolean flag which, when set to true , determines that pre-shared keys and TLS certificates will be regenerated. For more information about when keys and certificates will be regenerated, see the descriptions of the ha_cluster_corosync_key_src , ha_cluster_pacemaker_key_src , ha_cluster_fence_virt_key_src , ha_cluster_pcsd_public_key_src , and ha_cluster_pcsd_private_key_src variables. The default value of this variable is false . ha_cluster_pcs_permission_list Configures permissions to manage a cluster using pcsd . The items you configure with this variable are as follows: type - user or group name - user or group name allow_list - Allowed actions for the specified user or group: read - View cluster status and settings write - Modify cluster settings except permissions and ACLs grant - Modify cluster permissions and ACLs full - Unrestricted access to a cluster including adding and removing nodes and access to keys and certificates The structure of the ha_cluster_pcs_permission_list variable and its default values are as follows: ha_cluster_cluster_name The name of the cluster. This is a string value with a default of my-cluster . ha_cluster_transport (RHEL 9.1 and later) Sets the cluster transport method. The items you configure with this variable are as follows: type (optional) - Transport type: knet , udp , or udpu . The udp and udpu transport types support only one link. Encryption is always disabled for udp and udpu . Defaults to knet if not specified. options (optional) - List of name-value dictionaries with transport options. links (optional) - List of list of name-value dictionaries. Each list of name-value dictionaries holds options for one Corosync link. It is recommended that you set the linknumber value for each link. Otherwise, the first list of dictionaries is assigned by default to the first link, the second one to the second link, and so on. compression (optional) - List of name-value dictionaries configuring transport compression. Supported only with the knet transport type. crypto (optional) - List of name-value dictionaries configuring transport encryption. By default, encryption is enabled. Supported only with the knet transport type. For a list of allowed options, see the pcs -h cluster setup help page or the setup description in the cluster section of the pcs (8) man page. For more detailed descriptions, see the corosync.conf (5) man page. The structure of the ha_cluster_transport variable is as follows: For an example ha_cluster RHEL system role playbook that configures a transport method, see Configuring Corosync values in a high availability cluster . ha_cluster_totem (RHEL 9.1 and later) Configures Corosync totem. For a list of allowed options, see the pcs -h cluster setup help page or the setup description in the cluster section of the pcs (8) man page. For a more detailed description, see the corosync.conf (5) man page. The structure of the ha_cluster_totem variable is as follows: For an example ha_cluster RHEL system role playbook that configures a Corosync totem, see Configuring Corosync values in a high availability cluster . ha_cluster_quorum (RHEL 9.1 and later) Configures cluster quorum. You can configure the following items for cluster quorum: options (optional) - List of name-value dictionaries configuring quorum. Allowed options are: auto_tie_breaker , last_man_standing , last_man_standing_window , and wait_for_all . For information about quorum options, see the votequorum (5) man page. device (optional) - (RHEL 9.2 and later) Configures the cluster to use a quorum device. By default, no quorum device is used. model (mandatory) - Specifies a quorum device model. Only net is supported model_options (optional) - List of name-value dictionaries configuring the specified quorum device model. For model net , you must specify host and algorithm options. Use the pcs-address option to set a custom pcsd address and port to connect to the qnetd host. If you do not specify this option, the role connects to the default pcsd port on the host . generic_options (optional) - List of name-value dictionaries setting quorum device options that are not model specific. heuristics_options (optional) - List of name-value dictionaries configuring quorum device heuristics. For information about quorum device options, see the corosync-qdevice (8) man page. The generic options are sync_timeout and timeout . For model net options see the quorum.device.net section. For heuristics options, see the quorum.device.heuristics section. To regenerate a quorum device TLS certificate, set the ha_cluster_regenerate_keys variable to true . The structure of the ha_cluster_quorum variable is as follows: For an example ha_cluster RHEL system role playbook that configures cluster quorum, see Configuring Corosync values in a high availability cluster . For an example ha_cluster RHEL system role playbook that configures a cluster using a quorum device, see Configuring a high availability cluster using a quorum device . ha_cluster_sbd_enabled (RHEL 9.1 and later) A boolean flag which determines whether the cluster can use the SBD node fencing mechanism. The default value of this variable is false . For example ha_cluster system role playbooks that enable SBD, see Configuring a high availability cluster with SBD node fencing by using the ha_cluster_node_options variable and Configuring a high availability cluster with SBD node fencing by using the ha_cluster variable . ha_cluster_sbd_options (RHEL 9.1 and later) List of name-value dictionaries specifying SBD options. For information about these options, see the Configuration via environment section of the sbd (8) man page. Supported options are: delay-start - defaults to false , documented as SBD_DELAY_START startmode - defaults to always , documented as SBD_START_MODE timeout-action - defaults to flush,reboot , documented as SBD_TIMEOUT_ACTION watchdog-timeout - defaults to 5 , documented as SBD_WATCHDOG_TIMEOUT Watchdog and SBD devices can be configured on a node to node basis in one of two variables: ha_cluster_node_options , which you define in a playbook file (RHEL 9.5 and later). For an example ha_cluster RHEL system role playbook that uses the ha_cluster_node_options variable to configure node by node SBD options, see Configuring a high availability cluster with SBD node fencing by using the ha_cluster_node_options variable . ha_cluster , which you define in an inventory file. For an example procedure that configures node to node SBD options in an inventory file, see Configuring a high availability cluster with SBD node fencing by using the ha_cluster variable . ha_cluster_cluster_properties List of sets of cluster properties for Pacemaker cluster-wide configuration. Only one set of cluster properties is supported. The structure of a set of cluster properties is as follows: By default, no properties are set. The following example playbook configures a cluster consisting of node1 and node2 and sets the stonith-enabled and no-quorum-policy cluster properties. ha_cluster_node_options (RHEL 9.4 and later) This variable defines settings which vary from one cluster node to another. It sets the options for the specified nodes, but does not specify which nodes form the cluster. You specify which nodes form the cluster with the hosts parameter in an inventory or a playbook. The items you configure with this variable are as follows: node_name (mandatory) - Name of the node for which to define Pacemaker node attributes. It must match a name defined for a node. pcs_address (optional) - (RHEL 9.5 and later) Address used by pcs to communicate with the node. You can specify a name, a FQDN or an IP address. You can specify a port as well. corosync_addresses (optional) - (RHEL 9.5 and later) List of addresses used by Corosync. All nodes must have the same number of addresses. The order of the addresses must be the same for all nodes, so that the addresses belonging to a particular link are specified in the same position for all nodes. sbd_watchdog_modules (optional) - (RHEL 9.5 and later) Watchdog kernel modules to be loaded, which create /dev/watchdog* devices. Defaults to an empty list if not set. sbd_watchdog_modules_blocklist (optional) - (RHEL 9.5 and later) Watchdog kernel modules to be unloaded and blocked. Defaults to an empty list if not set. sbd_watchdog (optional) - (RHEL 9.5 and later) Watchdog device to be used by SBD. Defaults to /dev/watchdog if not set. sbd_devices (optional) - (RHEL 9.5 and later) Devices to use for exchanging SBD messages and for monitoring. Defaults to an empty list if not set. Always refer to the devices using the long, stable device name ( /dev/disk/by-id/ ). attributes (optional) - List of sets of Pacemaker node attributes for the node. Currently, only one set is supported. The first set is used and the rest are ignored. utilization (optional) - (RHEL 9.5 and later) List of sets of the node's utilization. The field value must be an integer. Currently, only one set is supported. The first set is used and the rest are ignored. The structure of the ha_cluster_node_options variable is as follows: By default, no node options are defined. For an example ha_cluster RHEL system role playbook that includes node options configuration, see Configuring a high availability cluster with node attributes . ha_cluster_resource_primitives This variable defines pacemaker resources configured by the RHEL system role, including fencing resources. You can configure the following items for each resource: id (mandatory) - ID of a resource. agent (mandatory) - Name of a resource or fencing agent, for example ocf:pacemaker:Dummy or stonith:fence_xvm . It is mandatory to specify stonith: for STONITH agents. For resource agents, it is possible to use a short name, such as Dummy , instead of ocf:pacemaker:Dummy . However, if several agents with the same short name are installed, the role will fail as it will be unable to decide which agent should be used. Therefore, it is recommended that you use full names when specifying a resource agent. instance_attrs (optional) - List of sets of the resource's instance attributes. Currently, only one set is supported. The exact names and values of attributes, as well as whether they are mandatory or not, depend on the resource or fencing agent. meta_attrs (optional) - List of sets of the resource's meta attributes. Currently, only one set is supported. copy_operations_from_agent (optional) - (RHEL 9.3 and later) Resource agents usually define default settings for resource operations, such as interval and timeout , optimized for the specific agent. If this variable is set to true , then those settings are copied to the resource configuration. Otherwise, clusterwide defaults apply to the resource. If you also define resource operation defaults for the resource with the ha_cluster_resource_operation_defaults role variable, you can set this to false . The default value of this variable is true . operations (optional) - List of the resource's operations. action (mandatory) - Operation action as defined by pacemaker and the resource or fencing agent. attrs (mandatory) - Operation options, at least one option must be specified. (RHEL 9.5 and later) utilization (optional) - List of sets of the resource's utilization. The value field must be an integer. Only one set is supported, so the first set is used and the rest are ignored. The structure of the resource definition that you configure with the ha_cluster RHEL system role is as follows: By default, no resources are defined. For an example ha_cluster RHEL system role playbook that includes resource configuration, see Configuring a high availability cluster with fencing and resources . ha_cluster_resource_groups This variable defines pacemaker resource groups configured by the system role. You can configure the following items for each resource group: id (mandatory) - ID of a group. resources (mandatory) - List of the group's resources. Each resource is referenced by its ID and the resources must be defined in the ha_cluster_resource_primitives variable. At least one resource must be listed. meta_attrs (optional) - List of sets of the group's meta attributes. Currently, only one set is supported. The structure of the resource group definition that you configure with the ha_cluster RHEL system role is as follows: By default, no resource groups are defined. For an example ha_cluster RHEL system role playbook that includes resource group configuration, see Configuring a high availability cluster with fencing and resources . ha_cluster_resource_clones This variable defines pacemaker resource clones configured by the system role. You can configure the following items for a resource clone: resource_id (mandatory) - Resource to be cloned. The resource must be defined in the ha_cluster_resource_primitives variable or the ha_cluster_resource_groups variable. promotable (optional) - Indicates whether the resource clone to be created is a promotable clone, indicated as true or false . id (optional) - Custom ID of the clone. If no ID is specified, it will be generated. A warning will be displayed if this option is not supported by the cluster. meta_attrs (optional) - List of sets of the clone's meta attributes. Currently, only one set is supported. The structure of the resource clone definition that you configure with the ha_cluster RHEL system role is as follows: By default, no resource clones are defined. For an example ha_cluster RHEL system role playbook that includes resource clone configuration, see Configuring a high availability cluster with fencing and resources . ha_cluster_resource_defaults (RHEL 9.3 and later) This variable defines sets of resource defaults. You can define multiple sets of defaults and apply them to resources of specific agents using rules. The defaults you specify with the ha_cluster_resource_defaults variable do not apply to resources which override them with their own defined values. Only meta attributes can be specified as defaults. You can configure the following items for each defaults set: id (optional) - ID of the defaults set. If not specified, it is autogenerated. rule (optional) - Rule written using pcs syntax defining when and for which resources the set applies. For information on specifying a rule, see the resource defaults set create section of the pcs (8) man page. score (optional) - Weight of the defaults set. attrs (optional) - Meta attributes applied to resources as defaults. The structure of the ha_cluster_resource_defaults variable is as follows: For an example ha_cluster RHEL system role playbook that configures resource defaults, see Configuring a high availability cluster with resource and resource operation defaults . ha_cluster_resource_operation_defaults (RHEL 9.3 and later) This variable defines sets of resource operation defaults. You can define multiple sets of defaults and apply them to resources of specific agents and specific resource operations using rules. The defaults you specify with the ha_cluster_resource_operation_defaults variable do not apply to resource operations which override them with their own defined values. By default, the ha_cluster RHEL system role configures resources to define their own values for resource operations. For information about overriding these defaults with the ha_cluster_resource_operations_defaults variable, see the description of the copy_operations_from_agent item in ha_cluster_resource_primitives . Only meta attributes can be specified as defaults. The structure of the ha_cluster_resource_operations_defaults variable is the same as the structure for the ha_cluster_resource_defaults variable, with the exception of how you specify a rule. For information about specifying a rule to describe the resource operation to which a set applies, see the resource op defaults set create section of the pcs (8) man page. ha_cluster_stonith_levels (RHEL 9.4 and later) This variable defines STONITH levels, also known as fencing topology. Fencing levels configure a cluster to use multiple devices to fence nodes. You can define alternative devices in case one device fails and you can require multiple devices to all be executed successfully to consider a node successfully fenced. For more information on fencing levels, see Configuring fencing levels in Configuring and managing high availability clusters . You can configure the following items when defining fencing levels: level (mandatory) - Order in which to attempt the fencing level. Pacemaker attempts levels in ascending order until one succeeds. target (optional) - Name of a node this level applies to. You must specify one of the following three selections: target_pattern - POSIX extended regular expression matching the names of the nodes this level applies to. target_attribute - Name of a node attribute that is set for the node this level applies to. target_attribute and target_value - Name and value of a node attribute that is set for the node this level applies to. resouce_ids (mandatory) - List of fencing resources that must all be tried for this level. By default, no fencing levels are defined. The structure of the fencing levels definition that you configure with the ha_cluster RHEL system role is as follows: For an example ha_cluster RHEL system role playbook that configures fencing defaults, see Configuring a high availability cluster with fencing levels . ha_cluster_constraints_location This variable defines resource location constraints. Resource location constraints indicate which nodes a resource can run on. You can specify a resources specified by a resource ID or by a pattern, which can match more than one resource. You can specify a node by a node name or by a rule. You can configure the following items for a resource location constraint: resource (mandatory) - Specification of a resource the constraint applies to. node (mandatory) - Name of a node the resource should prefer or avoid. id (optional) - ID of the constraint. If not specified, it will be autogenerated. options (optional) - List of name-value dictionaries. score - Sets the weight of the constraint. A positive score value means the resource prefers running on the node. A negative score value means the resource should avoid running on the node. A score value of -INFINITY means the resource must avoid running on the node. If score is not specified, the score value defaults to INFINITY . By default no resource location constraints are defined. The structure of a resource location constraint specifying a resource ID and node name is as follows: The items that you configure for a resource location constraint that specifies a resource pattern are the same items that you configure for a resource location constraint that specifies a resource ID, with the exception of the resource specification itself. The item that you specify for the resource specification is as follows: pattern (mandatory) - POSIX extended regular expression resource IDs are matched against. The structure of a resource location constraint specifying a resource pattern and node name is as follows: You can configure the following items for a resource location constraint that specifies a resource ID and a rule: resource (mandatory) - Specification of a resource the constraint applies to. id (mandatory) - Resource ID. role (optional) - The resource role to which the constraint is limited: Started , Unpromoted , Promoted . rule (mandatory) - Constraint rule written using pcs syntax. For further information, see the constraint location section of the pcs (8) man page. Other items to specify have the same meaning as for a resource constraint that does not specify a rule. The structure of a resource location constraint that specifies a resource ID and a rule is as follows: The items that you configure for a resource location constraint that specifies a resource pattern and a rule are the same items that you configure for a resource location constraint that specifies a resource ID and a rule, with the exception of the resource specification itself. The item that you specify for the resource specification is as follows: pattern (mandatory) - POSIX extended regular expression resource IDs are matched against. The structure of a resource location constraint that specifies a resource pattern and a rule is as follows: For an example ha_cluster RHEL system role playbook that creates a cluster with resource constraints, see Configuring a high availability cluster with resource constraints . ha_cluster_constraints_colocation This variable defines resource colocation constraints. Resource colocation constraints indicate that the location of one resource depends on the location of another one. There are two types of colocation constraints: a simple colocation constraint for two resources, and a set colocation constraint for multiple resources. You can configure the following items for a simple resource colocation constraint: resource_follower (mandatory) - A resource that should be located relative to resource_leader . id (mandatory) - Resource ID. role (optional) - The resource role to which the constraint is limited: Started , Unpromoted , Promoted . resource_leader (mandatory) - The cluster will decide where to put this resource first and then decide where to put resource_follower . id (mandatory) - Resource ID. role (optional) - The resource role to which the constraint is limited: Started , Unpromoted , Promoted . id (optional) - ID of the constraint. If not specified, it will be autogenerated. options (optional) - List of name-value dictionaries. score - Sets the weight of the constraint. Positive score values indicate the resources should run on the same node. Negative score values indicate the resources should run on different nodes. A score value of +INFINITY indicates the resources must run on the same node. A score value of -INFINITY indicates the resources must run on different nodes. If score is not specified, the score value defaults to INFINITY . By default no resource colocation constraints are defined. The structure of a simple resource colocation constraint is as follows: You can configure the following items for a resource set colocation constraint: resource_sets (mandatory) - List of resource sets. resource_ids (mandatory) - List of resources in a set. options (optional) - List of name-value dictionaries fine-tuning how resources in the sets are treated by the constraint. id (optional) - Same values as for a simple colocation constraint. options (optional) - Same values as for a simple colocation constraint. The structure of a resource set colocation constraint is as follows: For an example ha_cluster RHEL system role playbook that creates a cluster with resource constraints, see Configuring a high availability cluster with resource constraints . ha_cluster_constraints_order This variable defines resource order constraints. Resource order constraints indicate the order in which certain resource actions should occur. There are two types of resource order constraints: a simple order constraint for two resources, and a set order constraint for multiple resources. You can configure the following items for a simple resource order constraint: resource_first (mandatory) - Resource that the resource_then resource depends on. id (mandatory) - Resource ID. action (optional) - The action that must complete before an action can be initiated for the resource_then resource. Allowed values: start , stop , promote , demote . resource_then (mandatory) - The dependent resource. id (mandatory) - Resource ID. action (optional) - The action that the resource can execute only after the action on the resource_first resource has completed. Allowed values: start , stop , promote , demote . id (optional) - ID of the constraint. If not specified, it will be autogenerated. options (optional) - List of name-value dictionaries. By default no resource order constraints are defined. The structure of a simple resource order constraint is as follows: You can configure the following items for a resource set order constraint: resource_sets (mandatory) - List of resource sets. resource_ids (mandatory) - List of resources in a set. options (optional) - List of name-value dictionaries fine-tuning how resources in the sets are treated by the constraint. id (optional) - Same values as for a simple order constraint. options (optional) - Same values as for a simple order constraint. The structure of a resource set order constraint is as follows: For an example ha_cluster RHEL system role playbook that creates a cluster with resource constraints, see Configuring a high availability cluster with resource constraints . ha_cluster_constraints_ticket This variable defines resource ticket constraints. Resource ticket constraints indicate the resources that depend on a certain ticket. There are two types of resource ticket constraints: a simple ticket constraint for one resource, and a ticket order constraint for multiple resources. You can configure the following items for a simple resource ticket constraint: resource (mandatory) - Specification of a resource the constraint applies to. id (mandatory) - Resource ID. role (optional) - The resource role to which the constraint is limited: Started , Unpromoted , Promoted . ticket (mandatory) - Name of a ticket the resource depends on. id (optional) - ID of the constraint. If not specified, it will be autogenerated. options (optional) - List of name-value dictionaries. loss-policy (optional) - Action to perform on the resource if the ticket is revoked. By default no resource ticket constraints are defined. The structure of a simple resource ticket constraint is as follows: You can configure the following items for a resource set ticket constraint: resource_sets (mandatory) - List of resource sets. resource_ids (mandatory) - List of resources in a set. options (optional) - List of name-value dictionaries fine-tuning how resources in the sets are treated by the constraint. ticket (mandatory) - Same value as for a simple ticket constraint. id (optional) - Same value as for a simple ticket constraint. options (optional) - Same values as for a simple ticket constraint. The structure of a resource set ticket constraint is as follows: For an example ha_cluster RHEL system role playbook that creates a cluster with resource constraints, see Configuring a high availability cluster with resource constraints . ha_cluster_acls (RHEL 9.5 and later) This variable defines ACL roles, users and groups. You can configure the following items for acl_roles : id (mandatory) - ID of an ACL role. description (optional) - Description of the ACL role. permissions (optional) - List of ACL role permissions. kind (mandatory) - The access being granted. Allowed values are read , write , and deny . xpath (optional) - An XPath specification selecting an XML element in the CIB to which the permission applies. It is mandatory to specify exactly one of the items: xpath or reference . reference (optional) - The ID of an XML element in the CIB to which the permission applies. It is mandatory to specify exactly one of the items: xpath or reference. The ID must exist. You can configure the following items for acl_users : id (mandatory) - ID of an ACL user. roles (optional) - List of ACL Role IDs assigned to the user. You can configure the following items for acl_group : id (mandatory) - ID of an ACL group. roles (optional) - List of ACL Role IDs assigned to the group. The structure of an ACL definition is as follows: To enable ACLS in the cluster, you must configure the enable-acl cluster property: For an example ha_cluster RHEL system role playbook that creates a cluster with ACL roles, users, and groups, see Configuring a high availability cluster that implements access control lists (ACLS) by using the RHEL system role . ha_cluster_alerts (RHEL 9.5 and later) This variable defines Pacemaker alerts. Note The ha_cluster role configures the cluster to call external programs to handle alerts. You must provide the programs and distribute them to cluster nodes. You can configure the following items for alerts : id (mandatory) - ID of an alert ipath (mandatory) - Path to the alert agent executable. description (optional) - Description of the alert. instance_attrs (optional) - List of sets of the alert's instance attributes.Only one set is supported. The first set is used and the rest are ignored. meta_attrs (optional) - List of sets of the alert's meta attributes. Only one set is supported. The first set is used and the rest are ignored. * recipients (optional) - List of alert's recipients. You can configure the following items for recipients : value (mandatory) - Value of a recipient. id (optional) - ID of the recipient. description (optional) - Description of the recipient. instance_attrs (optional) - List of sets of the recipient's instance attributes. Only one set is supported. The first set is used and the rest are ignored. meta_attrs (optional) - List of sets of the recipient's meta attributes. Only one set is supported. The first set is used and the rest are ignored. The structure of an alert definition is as follows: For an example ha_cluster RHEL system role playbook that configures a cluster with alerts, see Configuring alerts for a high availability cluster by using the ha_cluster RHEL system role . ha_cluster_qnetd (RHEL 9.2 and later) This variable configures a qnetd host which can then serve as an external quorum device for clusters. You can configure the following items for a qnetd host: present (optional) - If true , configure a qnetd instance on the host. If false , remove qnetd configuration from the host. The default value is false . If you set this true , you must set ha_cluster_cluster_present to false . start_on_boot (optional) - Configures whether the qnetd instance should start automatically on boot. The default value is true . regenerate_keys (optional) - Set this variable to true to regenerate the qnetd TLS certificate. If you regenerate the certificate, you must either re-run the role for each cluster to connect it to the qnetd host again or run pcs manually. You cannot run qnetd on a cluster node because fencing would disrupt qnetd operation. For an example ha_cluster RHEL system role playbook that configures a cluster using a quorum device, see Configuring a cluster using a quorum device . Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.2. Specifying an inventory for the ha_cluster RHEL system role When configuring an HA cluster using the ha_cluster RHEL system role playbook, you configure the names and addresses of the nodes for the cluster in an inventory. For each node in an inventory, you can optionally specify the following items: node_name - the name of a node in a cluster. pcs_address - an address used by pcs to communicate with the node. It can be a name, FQDN or an IP address and it can include a port number. corosync_addresses - list of addresses used by Corosync. All nodes which form a particular cluster must have the same number of addresses. The order of the addresses must be the same for all nodes, so that the addresses belonging to a particular link are specified in the same position for all nodes. The following example shows an inventory with targets node1 and node2 . node1 and node2 must be either fully qualified domain names or must otherwise be able to connect to the nodes as when, for example, the names are resolvable through the /etc/hosts file. As of RHEL 9.1, you can optionally configure watchdog and SBD devices for each node in an inventory. All SBD devices must be shared to and accessible from all nodes. Watchdog devices can be different for each node as well. For an example procedure that configures SBD node fencing in an inventory file, see Configuring a high availability cluster with SBD node fencing by using the ha_cluster variable . Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.3. Creating pcsd TLS certificates and key files for a high availability cluster (RHEL 9.2 and later) The connection between cluster nodes is secured using Transport Layer Security (TLS) encryption. By default, the pcsd daemon generates self-signed certificates. For many deployments, however, you may want to replace the default certificates with certificates issued by a certificate authority of your company and apply your company certificate policies for pcsd . You can use the ha_cluster RHEL system role to create TLS certificates and key files in a high availability cluster. When you run this playbook, the ha_cluster RHEL system role uses the certificate RHEL system role internally to manage TLS certificates. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create TLS certificates and key files in a high availability cluster ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_pcsd_certificates: - name: FILENAME common_name: "{{ ansible_hostname }}" ca: self-sign The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_pcsd_certificates: <certificate_properties> A variable that creates a self-signed pcsd certificate and private key files in /var/lib/pcsd . In this example, the pcsd certificate has the file name FILENAME.crt and the key file is named FILENAME.key . For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory Requesting certificates using RHEL system roles 13.4. Configuring a high availability cluster running no resources You can use the ha_cluster system role to configure a basic cluster in a simple, automatic way. Once you have created a basic cluster, you can use the pcs command-line interface to configure the other cluster components and behaviors on a resource-by-resource basis. The following example procedure configures a basic two-node cluster with no fencing configured using the minimum required parameters. Warning The ha_cluster system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster with minimum required parameters and no fencing ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.5. Configuring a high availability cluster with fencing and resources The specific components of a cluster configuration depend on your individual needs, which vary between sites. The following example procedure shows the formats for configuring different cluster components by using the ha_cluster RHEL system role. The configured cluster includes a fencing device, cluster resources, resource groups, and a cloned resource. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster with fencing and resources ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_resource_primitives: - id: xvm-fencing agent: 'stonith:fence_xvm' instance_attrs: - attrs: - name: pcmk_host_list value: node1 node2 - id: simple-resource agent: 'ocf:pacemaker:Dummy' - id: resource-with-options agent: 'ocf:pacemaker:Dummy' instance_attrs: - attrs: - name: fake value: fake-value - name: passwd value: passwd-value meta_attrs: - attrs: - name: target-role value: Started - name: is-managed value: 'true' operations: - action: start attrs: - name: timeout value: '30s' - action: monitor attrs: - name: timeout value: '5' - name: interval value: '1min' - id: dummy-1 agent: 'ocf:pacemaker:Dummy' - id: dummy-2 agent: 'ocf:pacemaker:Dummy' - id: dummy-3 agent: 'ocf:pacemaker:Dummy' - id: simple-clone agent: 'ocf:pacemaker:Dummy' - id: clone-with-options agent: 'ocf:pacemaker:Dummy' ha_cluster_resource_groups: - id: simple-group resource_ids: - dummy-1 - dummy-2 meta_attrs: - attrs: - name: target-role value: Started - name: is-managed value: 'true' - id: cloned-group resource_ids: - dummy-3 ha_cluster_resource_clones: - resource_id: simple-clone - resource_id: clone-with-options promotable: yes id: custom-clone-id meta_attrs: - attrs: - name: clone-max value: '2' - name: clone-node-max value: '1' - resource_id: cloned-group promotable: yes The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_resource_primitives: <cluster_resources> A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing ha_cluster_resource_groups: <resource_groups> A list of resource group definitions configured by the ha_cluster RHEL system role. ha_cluster_resource_clones: <resource_clones> A list of resource clone definitions configured by the ha_cluster RHEL system role. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory Configuring fencing in a Red Hat High Availability cluster 13.6. Configuring a high availability cluster with resource and resource operation defaults (RHEL 9.3 and later) In your cluster configuration, you can change the Pacemaker default values of a resource option for all resources. You can also change the default value for all resource operations in the cluster. For information about changing the default value of a resource option, see Changing the default value of a resource option . For information about global resource operation defaults, see Configuring global resource operation defaults . The following example procedure uses the ha_cluster RHEL system role to create a high availability cluster that defines resource and resource operation defaults. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster with fencing and resource operation defaults ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true # 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 # does not interfere with business activities. ha_cluster_resource_defaults: meta_attrs: - id: core-hours rule: date-spec hours=9-16 weekdays=1-5 score: 2 attrs: - name: resource-stickiness value: INFINITY - id: after-hours score: 1 attrs: - name: resource-stickiness value: 0 # Default the timeout on all 10-second-interval # monitor actions on IPaddr2 resources to 8 seconds. ha_cluster_resource_operation_defaults: meta_attrs: - rule: resource ::IPaddr2 and op monitor interval=10s score: INFINITY attrs: - name: timeout value: 8s The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_resource_defaults: <resource_defaults> A variable that defines sets of resource defaults. ha_cluster_resource_operation_defaults: <resource_operation_defaults> A variable that defines sets of resource operation defaults. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.7. Configuring a high availability cluster with fencing levels (RHEL 9.4 and later) When you configure multiple fencing devices for a node, you need to define fencing levels for those devices to determine the order that Pacemaker will use the devices to attempt to fence a node. For information about fencing levels, see Configuring fencing levels . The following example procedure uses the ha_cluster RHEL system role to create a high availability cluster that defines fencing levels. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> fence1_password: <fence1_password> fence2_password: <fence2_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml . This example playbook file configures a cluster running the firewalld and selinux services. --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster that defines fencing levels ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_resource_primitives: - id: apc1 agent: 'stonith:fence_apc_snmp' instance_attrs: - attrs: - name: ip value: apc1.example.com - name: username value: user - name: password value: "{{ fence1_password }}" - name: pcmk_host_map value: node1:1;node2:2 - id: apc2 agent: 'stonith:fence_apc_snmp' instance_attrs: - attrs: - name: ip value: apc2.example.com - name: username value: user - name: password value: "{{ fence2_password }}" - name: pcmk_host_map value: node1:1;node2:2 # Nodes have redundant power supplies, apc1 and apc2. Cluster must # ensure that when attempting to reboot a node, both power # supplies # are turned off before either power supply is turned # back on. ha_cluster_stonith_levels: - level: 1 target: node1 resource_ids: - apc1 - apc2 - level: 1 target: node2 resource_ids: - apc1 - apc2 The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_resource_primitives: <cluster_resources> A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing ha_cluster_stonith_levels: <stonith_levels> A variable that defines STONITH levels, also known as fencing topology, which configure a cluster to use multiple devices to fence nodes. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.8. Configuring a high availability cluster with resource constraints When configuring a cluster, you can specify the behavior of the cluster resources to be in line with your application requirements. You can control the behavior of cluster resources by configuring resource constraints. You can define the following categories of resource constraints: Location constraints, which determine which nodes a resource can run on. For information about location constraints, see Determining which nodes a resource can run on . Ordering constraints, which determine the order in which the resources are run. For information about ordering constraints, see Determing the order in which cluster resources are run . Colocation constraints, which specify that the location of one resource depends on the location of another resource. For information about colocation constraints, see Colocating cluster resources . Ticket constraints, which indicate the resources that depend on a particular Booth ticket. For information about Booth ticket constraints, see Multi-site Pacemaker clusters . The following example procedure uses the ha_cluster RHEL system role to create a high availability cluster that includes resource location constraints, resource colocation constraints, resource order constraints, and resource ticket constraints. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster with resource constraints ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true # In order to use constraints, we need resources # the constraints will apply to. ha_cluster_resource_primitives: - id: xvm-fencing agent: 'stonith:fence_xvm' instance_attrs: - attrs: - name: pcmk_host_list value: node1 node2 - id: dummy-1 agent: 'ocf:pacemaker:Dummy' - id: dummy-2 agent: 'ocf:pacemaker:Dummy' - id: dummy-3 agent: 'ocf:pacemaker:Dummy' - id: dummy-4 agent: 'ocf:pacemaker:Dummy' - id: dummy-5 agent: 'ocf:pacemaker:Dummy' - id: dummy-6 agent: 'ocf:pacemaker:Dummy' # location constraints ha_cluster_constraints_location: # resource ID and node name - resource: id: dummy-1 node: node1 options: - name: score value: 20 # resource pattern and node name - resource: pattern: dummy-\d+ node: node1 options: - name: score value: 10 # resource ID and rule - resource: id: dummy-2 rule: '#uname eq node2 and date in_range 2022-01-01 to 2022-02-28' # resource pattern and rule - resource: pattern: dummy-\d+ rule: node-type eq weekend and date-spec weekdays=6-7 # colocation constraints ha_cluster_constraints_colocation: # simple constraint - resource_leader: id: dummy-3 resource_follower: id: dummy-4 options: - name: score value: -5 # set constraint - resource_sets: - resource_ids: - dummy-1 - dummy-2 - resource_ids: - dummy-5 - dummy-6 options: - name: sequential value: "false" options: - name: score value: 20 # order constraints ha_cluster_constraints_order: # simple constraint - resource_first: id: dummy-1 resource_then: id: dummy-6 options: - name: symmetrical value: "false" # set constraint - resource_sets: - resource_ids: - dummy-1 - dummy-2 options: - name: require-all value: "false" - name: sequential value: "false" - resource_ids: - dummy-3 - resource_ids: - dummy-4 - dummy-5 options: - name: sequential value: "false" # ticket constraints ha_cluster_constraints_ticket: # simple constraint - resource: id: dummy-1 ticket: ticket1 options: - name: loss-policy value: stop # set constraint - resource_sets: - resource_ids: - dummy-3 - dummy-4 - dummy-5 ticket: ticket2 options: - name: loss-policy value: fence The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_resource_primitives: <cluster_resources> A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing ha_cluster_constraints_location: <location_constraints> A variable that defines resource location constraints. ha_cluster_constraints_colocation: <colocation_constraints> A variable that defines resource colocation constraints. ha_cluster_constraints_order: <order_constraints> A variable that defines resource order constraints. ha_cluster_constraints_ticket: <ticket_constraints> A variable that defines Booth ticket constraints. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.9. Configuring Corosync values in a high availability cluster (RHEL 9.1 and later) The corosync.conf file provides the cluster parameters used by Corosync, the cluster membership and messaging layer that Pacemaker is built on. For your system configuration, you can change some of the default parameters in the corosync.conf file. In general, you should not edit the corosync.conf file directly. You can, however, configure Corosync values by using the ha_cluster RHEL system role. The following example procedure uses the ha_cluster RHEL system role to create a high availability cluster that configures Corosync values. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster that configures Corosync values ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_transport: type: knet options: - name: ip_version value: ipv4-6 - name: link_mode value: active links: - - name: linknumber value: 1 - name: link_priority value: 5 - - name: linknumber value: 0 - name: link_priority value: 10 compression: - name: level value: 5 - name: model value: zlib crypto: - name: cipher value: none - name: hash value: none ha_cluster_totem: options: - name: block_unlisted_ips value: 'yes' - name: send_join value: 0 ha_cluster_quorum: options: - name: auto_tie_breaker value: 1 - name: wait_for_all value: 1 The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_transport: <transport_method> A variable that sets the cluster transport method. ha_cluster_totem: <totem_options> A variable that configures Corosync totem options. ha_cluster_quorum: <quorum_options> A variable that configures cluster quorum options. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.10. Configuring a high availability cluster that implements access control lists (ACLs) by using the ha_cluster RHEL system role (RHEL 9.5 and later) The pcs administration account for a cluster is hacluster . Using access control lists (ACLs), you can grant permission for specific local users other than user hacluster to manage a Pacemaker cluster. A common use case for this feature is to restrict unauthorized users from accessing business-sensitive information. By default, ACLs are not enabled. Consequently, any member of the group haclient on all nodes has full local read and write access to the cluster configuratioan. Users who are not members of haclient have no access. When ACLs are enabled, however, even users who are members of the haclient group have access only to what has been granted to that user by the ACLs. The root and hacluster user accounts always have full access to the cluster configuration, even when ACLs are enabled. When you set permissions for local users with ACLs, you create a role which defines the permissions for that role. You then assign that role to a user. If you assign multiple roles to the same user, any deny permission takes precedence, then write, then read. The following example procedure uses the ha_cluster RHEL system role to create in an automated fashion a high availability cluster that implements ACLs to control access to the cluster configuration. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with ACLs assigned ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true # To use an ACL role permission reference, the reference must exist in CIB. ha_cluster_resource_primitives: - id: not-for-operator agent: 'ocf:pacemaker:Dummy' # ACLs must be enabled (using the enable-acl cluster property) in order to be effective. ha_cluster_cluster_properties: - attrs: - name: enable-acl value: 'true' ha_cluster_acls: acl_roles: - id: operator description: HA cluster operator permissions: - kind: write xpath: //crm_config//nvpair[@name='maintenance-mode'] - kind: deny reference: not-for-operator - id: administrator permissions: - kind: write xpath: /cib acl_users: - id: alice roles: - operator - administrator - id: bob roles: - administrator acl_groups: - id: admins roles: - administrator The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_resource_primitives: <cluster resources> A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing resources. ha_cluster_cluster_properties: <cluster properties> A list of sets of cluster properties for Pacemaker cluster-wide configuration. ha_cluster_acls: <dictionary> A dictionary of ACL role, user, and group values. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory Ansible vault 13.11. Configuring a high availability cluster with SBD node fencing by using the ha_cluster_node_options variable You must configure a Red Hat high availability cluster with at least one fencing device to ensure the cluster-provided services remain available when a node in the cluster encounters a problem. If your environment does not allow for a remotely accessible power switch to fence a cluster node, you can configure fencing by using a STONITH Block Device (SBD). This device provides a node fencing mechanism for Pacemaker-based clusters through the exchange of messages by means of shared block storage. SBD integrates with Pacemaker, a watchdog device and, optionally, shared storage to arrange for nodes to reliably self-terminate when fencing is required. You can use the ha_cluster RHEL system role to configure SBD fencing in an automated fashion. With ha_cluster , you can configure watchdog and SBD devices on a node-to-node basis by using one of two variables: ha_cluster_node_options : (RHEL 9.5 and later) This is a single variable you define in a playbook file. It is a list of dictionaries where each dictionary defines options for one node. ha_cluster : (RHEL 9.1 and later) A dictionary that defines options for one node only. You configure the ha_cluster variable in an inventory file. To set different values for each node, you define the variable separately for each node. If both the ha_cluster_node_options and ha_cluster variables contain SBD options, those in ha_cluster_node_options have precedence. This example procedure uses the ha_cluster_node_options variable in a playbook file to configure node addresses and SBD options on a per-node basis. For an example procedure that uses the ha_cluster variable in an inventory file, see Configuring a high availability cluster with SBD node fencing by using the ha_cluster variable . Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with SBD fencing ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: my_sbd_devices: # This variable is indirectly used by various variables of the ha_cluster RHEL system role. # Its purpose is to define SBD devices once so they do not need # to be repeated several times in the role variables. - /dev/disk/by-id/000001 - /dev/disk/by-id/000002 - /dev/disk/by-id/000003 ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_sbd_enabled: true ha_cluster_sbd_options: - name: delay-start value: 'no' - name: startmode value: always - name: timeout-action value: 'flush,reboot' - name: watchdog-timeout value: 30 ha_cluster_node_options: - node_name: node1 sbd_watchdog_modules: - iTCO_wdt sbd_watchdog_modules_blocklist: - ipmi_watchdog sbd_watchdog: /dev/watchdog1 sbd_devices: "{{ my_sbd_devices }}" - node_name: node2 sbd_watchdog_modules: - iTCO_wdt sbd_watchdog_modules_blocklist: - ipmi_watchdog sbd_watchdog: /dev/watchdog1 sbd_devices: "{{ my_sbd_devices }}" # Best practice for setting SBD timeouts: # watchdog-timeout * 2 = msgwait-timeout (set automatically) # msgwait-timeout * 1.2 = stonith-timeout ha_cluster_cluster_properties: - attrs: - name: stonith-timeout value: 72 ha_cluster_resource_primitives: - id: fence_sbd agent: 'stonith:fence_sbd' instance_attrs: - attrs: - name: devices value: "{{ my_sbd_devices | join(',') }}" - name: pcmk_delay_base value: 30 The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_sbd_enabled: true A variable that determines whether the cluster can use the SBD node fencing mechanism. ha_cluster_sbd_options: <sbd options> A list of name-value dictionaries specifying SBD options. For information about these options, see the Configuration via environment section of the sbd (8) man page on your system. ha_cluster_node_options: <node options> A variable that defines settings which vary from one cluster node to another. You can configure the following SBD and watchdog items: sbd_watchdog_modules - Modules to be loaded, which create /dev/watchdog* devices. sbd_watchdog_modules_blocklist - Watchdog kernel modules to be unloaded and blocked. sbd_watchdog - Watchdog device to be used by SBD. sbd_devices - Devices to use for exchanging SBD messages and for monitoring. Always refer to the devices using the long, stable device name ( /dev/disk/by-id/ ). ha_cluster_cluster_properties: <cluster properties> A list of sets of cluster properties for Pacemaker cluster-wide configuration. ha_cluster_resource_primitives: <cluster resources> A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing resources. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources Red Hat Knowledgebase article Exploring RHEL High Availability's Components - sbd and fence_sbd Red Hat Knowledgebase article Design Guidance for RHEL High Availability Clusters - sbd Considerations Red Hat Knowledgebase article Support Policies for RHEL High Availability Clusters - sbd and fence_sbd /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory Ansible vault 13.12. Configuring a high availability cluster with SBD node fencing by using the ha_cluster variable You must configure a Red Hat high availability cluster with at least one fencing device to ensure the cluster-provided services remain available when a node in the cluster encounters a problem. If your environment does not allow for a remotely accessible power switch to fence a cluster node, you can configure fencing by using a STONITH Block Device (SBD). This device provides a node fencing mechanism for Pacemaker-based clusters through the exchange of messages by means of shared block storage. SBD integrates with Pacemaker, a watchdog device and, optionally, shared storage to arrange for nodes to reliably self-terminate when fencing is required. You can use the ha_cluster RHEL system role to configure SBD fencing in an automated fashion. With ha_cluster , you can configure watchdog and SBD devices on a node-to-node basis by using one of two variables: ha_cluster_node_options : (RHEL 9.5 and later) This is a single variable you define in a playbook file. It is a list of dictionaries where each dictionary defines options for one node. ha_cluster : (RHEL 9.1 and later) A dictionary that defines options for one node only. You configure the ha_cluster variable in an inventory file. To set different values for each node, you define the variable separately for each node. If both the ha_cluster_node_options and ha_cluster variables contain SBD options, those in ha_cluster_node_options have precedence. If both the ha_cluster_node_options and ha_cluster variables contain SBD options, those in ha_cluster_node_options have precedence.` The following example procedure uses the ha_cluster system role to create a high availability cluster with SBD fencing. This example procedure uses the ha_cluster variable in an inventory file to configure node addresses and SBD options on a per-node basis. For an example procedure that uses the ha_cluster_node_options variable in a playbook file, see Configuring a high availability cluster with SBD node fencing by using the ha_cluster_nodes_options variable . Warning The ha_cluster system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. Procedure Create an inventory file for your cluster that configures watchdog and SBD devices for each node by using the ha_cluster variable, as in the following exampla;e The SBD and watchdog settings specified in the example inventory include the following: sbd_watchdog_modules Watchdog kernel modules to be loaded, which create /dev/watchdog* devices. sbd_watchdog_modules_blocklist Watchdog kernel modules to be unloaded and blocked. sbd_watchdog Watchdog device to be used by SBD. sbd_devices Devices to use for exchanging SBD messages and for monitoring. Always refer to the devices using the long, stable device name ( /dev/disk/by-id/ ). For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , as in the following example. Since you have specified the SBD and watchog variables in an inventory, you do not need to include them in the playbook. --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with sbd fencing devices configured in an inventory file ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_sbd_enabled: true ha_cluster_sbd_options: - name: delay-start value: 'no' - name: startmode value: always - name: timeout-action value: 'flush,reboot' - name: watchdog-timeout value: 30 # Best practice for setting SBD timeouts: # watchdog-timeout * 2 = msgwait-timeout (set automatically) # msgwait-timeout * 1.2 = stonith-timeout ha_cluster_cluster_properties: - attrs: - name: stonith-timeout value: 72 ha_cluster_resource_primitives: - id: fence_sbd agent: 'stonith:fence_sbd' instance_attrs: - attrs: # taken from host_vars # this only works if all nodes have the same sbd_devices - name: devices value: "{{ ha_cluster.sbd_devices | join(',') }}" - name: pcmk_delay_base value: 30 The settings specified in the example playbook include the following: ha_cluster_cluster_name: cluster_name The name of the cluster you are creating. ha_cluster_hacluster_password: password The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_sbd_enabled: true A variable that determines whether the cluster can use the SBD node fencing mechanism. ha_cluster_sbd_options: sbd options A list of name-value dictionaries specifying SBD options. For information about these options, see the Configuration via environment section of the sbd (8) man page on your system. ha_cluster_cluster_properties: cluster properties A list of sets of cluster properties for Pacemaker cluster-wide configuration. ha_cluster_resource_primitives: cluster resources A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing resources. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources Red Hat Knowledgebase article Exploring RHEL High Availability's Components - sbd and fence_sbd Red Hat Knowledgebase article Design Guidance for RHEL High Availability Clusters - sbd Considerations Red Hat Knowledgebase article Support Policies for RHEL High Availability Clusters - sbd and fence_sbd /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory Ansible vault 13.13. Configuring a placement strategy for a high availability cluster by using the RHEL ha_cluster RHEL system role (RHEL 9.5 and later) A Pacemaker cluster allocates resources according to a resource allocation score. By default, if the resource allocation scores on all the nodes are equal, Pacemaker allocates the resource to the node with the smallest number of allocated resources. If the resources in your cluster use significantly different proportions of a node's capacities, such as memory or I/O, the default behavior may not be the best strategy for balancing your system's workload. In this case, you can customize an allocation strategy by configuring utilization attributes and placement strategies for nodes and resources. For detailed information about configuring utilization attributes and placement strategies, see Configuring a node placement strategy . This example procedure uses the ha_cluster RHEL system role to create a high availability cluster in an automated fashion that configures utilization attributes to define a placement strategy. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with utilization attributes ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_cluster_properties: - attrs: - name: placement-strategy value: utilization ha_cluster_node_options: - node_name: node1 utilization: - attrs: - name: utilization1 value: 1 - name: utilization2 value: 2 - node_name: node2 utilization: - attrs: - name: utilization1 value: 3 - name: utilization2 value: 4 ha_cluster_resource_primitives: - id: resource1 agent: 'ocf:pacemaker:Dummy' utilization: - attrs: - name: utilization1 value: 2 - name: utilization2 value: 3 The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_cluster_properties: <cluster properties> List of sets of cluster properties for Pacemaker cluster-wide configuration. For utilization to have an effect, the placement-strategy property must be set and its value must be different from the value default . `ha_cluster_node_options: <node options> A variable that defines various settings which vary from cluster node to cluster node. ha_cluster_resource_primitives: <cluster resources> A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing resources. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory Ansible vault 13.14. Configuring alerts for a high availability cluster by using the ha_cluster RHEL system role (RHEL 9.5 and later) When a Pacemaker event occurs, such as a resource or a node failure or a configuration change, you may want to take some external action. For example, you may want to send an email message or log to a file or update a monitoring system. You can configure your system to take an external action by using alert agents. These are external programs that the cluster calls in the same manner as the cluster calls resource agents to handle resource configuration and operation. The cluster passes information about the event to the agent through environment variables. Note The ha_cluster RHEL system role configures the cluster to call external programs to handle alerts. However, you must provide these programs and distribute them to cluster nodes. For more detailed information about alert agents, see Triggering scripts for cluster events . This example procedure uses the ha_cluster RHEL system role to create a high availability cluster in an automated fashion that configures a Pacemaker alert. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with alerts ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_alerts: - id: alert1 path: /alert1/path description: Alert1 description instance_attrs: - attrs: - name: alert_attr1_name value: alert_attr1_value meta_attrs: - attrs: - name: alert_meta_attr1_name value: alert_meta_attr1_value recipients: - value: recipient_value id: recipient1 description: Recipient1 description instance_attrs: - attrs: - name: recipient_attr1_name value: recipient_attr1_value meta_attrs: - attrs: - name: recipient_meta_attr1_name value: recipient_meta_attr1_value The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_alerts: <alert definitions> A variable that defines Pacemaker alerts. id - ID of an alert. path - Path to the alert agent executable. description - Description of the alert. instance_attrs - List of sets of the alert's instance attributes. Currently, only one set is supported, so the first set is used and the rest are ignored. meta_attrs - List of sets of the alert's meta attributes. Currently, only one set is supported, so the first set is used and the rest are ignored. recipients - List of alert's recipients. value - Value of a recipient. id - ID of the recipient. description - Description of the recipient. instance_attrs -List of sets of the recipient's instance attributes. Currently, only one set is supported, so the first set is used and the rest are ignored. meta_attrs - List of sets of the recipient's meta attributes. Currently, only one set is supported, so the first set is used and the rest are ignored. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory Ansible vault 13.15. Configuring a high availability cluster using a quorum device (RHEL 9.2 and later) Your cluster can sustain more node failures than standard quorum rules permit when you configure a separate quorum device. The quorum device acts as a lightweight arbitration device for the cluster. A quorum device is recommended for clusters with an even number of nodes. With two-node clusters, the use of a quorum device can better determine which node survives in a split-brain situation. For information about quorum devices, see Configuring quorum devices . To configure a high availability cluster with a separate quorum device by using the ha_cluster RHEL system role, first set up the quorum device. After setting up the quorum device, you can use the device in any number of clusters. 13.15.1. Configuring a quorum device To configure a quorum device using the ha_cluster RHEL system role, follow the steps in this example procedure. Note that you cannot run a quorum device on a cluster node. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The system that you will use to run the quorum device has active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the quorum devices as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook-qdevice.yml , with the following content: --- - name: Configure a host with a quorum device hosts: nodeQ vars_files: - vault.yml tasks: - name: Create a quorum device for the cluster ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_present: false ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_qnetd: present: true The settings specified in the example playbook include the following: ha_cluster_cluster_present: false A variable that, if set to false , determines that all cluster configuration will be removed from the target host. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_qnetd: <quorum_device_options> A variable that configures a qnetd host. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.15.2. Configuring a cluster to use a quorum device To configure a cluster to use a quorum device, follow the steps in this example procedure. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . You have configured a quorum device. Procedure Create a playbook file, for example ~/playbook-cluster-qdevice.yml , with the following content: --- - name: Configure a cluster to use a quorum device hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster that uses a quorum device ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_quorum: device: model: net model_options: - name: host value: nodeQ - name: algorithm value: lms The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_quorum: <quorum_parameters> A variable that configures cluster quorum which you can use to specify that the cluster uses a quorum device. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory 13.16. Configuring a high availability cluster with node attributes (RHEL 9.4 and later) You can use Pacemaker rules to make your configuration more dynamic. For example, you can use a node attribute to assign machines to different processing groups based on time and then use that attribute when creating location constraints. Node attribute expressions are used to control a resource based on the attributes defined by a node or nodes. For information on node attributes, see Determining resource location with rules . The following example procedure uses the ha_cluster RHEL system role to create a high availability cluster that configures node attributes. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create a cluster that defines node attributes ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_node_options: - node_name: node1 attributes: - attrs: - name: attribute1 value: value1A - name: attribute2 value: value2A - node_name: node2 attributes: - attrs: - name: attribute1 value: value1B - name: attribute2 value: value2B ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_node_options: <node_settings> A variable that defines various settings that vary from one cluster node to another. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: Additional resources Pacemaker rules 13.17. Configuring an Apache HTTP server in a high availability cluster with the ha_cluster RHEL system role High availability clusters provide highly available services by eliminating single points of failure and by failing over services from one cluster node to another in case a node becomes inoperative. Red Hat provides a variety of documentation for planning, configuring, and maintaining a Red Hat high availability cluster. For a listing of articles that provide indexes to the various areas of Red Hat cluster documentation, see the Red Hat High Availability Add-On Documentation Guide . The following example use case configures an active/passive Apache HTTP server in a two-node Red Hat Enterprise Linux High Availability Add-On cluster by using the ha_cluster RHEL system role. In this use case, clients access the Apache HTTP server through a floating IP address. The web server runs on one of two nodes in the cluster. If the node on which the web server is running becomes inoperative, the web server starts up again on the second node of the cluster with minimal service interruption. This example uses an APC power switch with a host name of zapc.example.com . If the cluster does not use any other fence agents, you can optionally list only the fence agents your cluster requires when defining the ha_cluster_fence_agent_packages variable, as in this example. Warning The ha_cluster RHEL system role replaces any existing cluster configuration on the specified nodes. Any settings not specified in the playbook will be lost. Prerequisites You have prepared the control node and the managed nodes . You are logged in to the control node as a user who can run playbooks on the managed nodes. The account you use to connect to the managed nodes has sudo permissions on them. The systems that you will use as your cluster members have active subscription coverage for RHEL and the RHEL High Availability Add-On. The inventory file specifies the cluster nodes as described in Specifying an inventory for the ha_cluster RHEL system role . For general information about creating an inventory file, see Preparing a control node on RHEL 9 . You have configured an LVM logical volume with an XFS file system, as described in Configuring an LVM volume with an XFS file system in a Pacemaker cluster . You have configured an Apache HTTP server, as described in Configuring an Apache HTTP Server . Your system includes an APC power switch that will be used to fence the cluster nodes. Procedure Store your sensitive variables in an encrypted file: Create the vault: After the ansible-vault create command opens an editor, enter the sensitive data in the <key> : <value> format: cluster_password: <cluster_password> Save the changes, and close the editor. Ansible encrypts the data in the vault. Create a playbook file, for example ~/playbook.yml , with the following content: --- - name: Create a high availability cluster hosts: z1.example.com z2.example.com vars_files: - vault.yml tasks: - name: Configure active/passive Apache server in a high availability cluster ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_cluster_name: my_cluster ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_fence_agent_packages: - fence-agents-apc-snmp ha_cluster_resource_primitives: - id: myapc agent: stonith:fence_apc_snmp instance_attrs: - attrs: - name: ipaddr value: zapc.example.com - name: pcmk_host_map value: z1.example.com:1;z2.example.com:2 - name: login value: apc - name: passwd value: apc - id: my_lvm agent: ocf:heartbeat:LVM-activate instance_attrs: - attrs: - name: vgname value: my_vg - name: vg_access_mode value: system_id - id: my_fs agent: Filesystem instance_attrs: - attrs: - name: device value: /dev/my_vg/my_lv - name: directory value: /var/www - name: fstype value: xfs - id: VirtualIP agent: IPaddr2 instance_attrs: - attrs: - name: ip value: 198.51.100.3 - name: cidr_netmask value: 24 - id: Website agent: apache instance_attrs: - attrs: - name: configfile value: /etc/httpd/conf/httpd.conf - name: statusurl value: http://127.0.0.1/server-status ha_cluster_resource_groups: - id: apachegroup resource_ids: - my_lvm - my_fs - VirtualIP - Website The settings specified in the example playbook include the following: ha_cluster_cluster_name: <cluster_name> The name of the cluster you are creating. ha_cluster_hacluster_password: <password> The password of the hacluster user. The hacluster user has full access to a cluster. ha_cluster_manage_firewall: true A variable that determines whether the ha_cluster RHEL system role manages the firewall. ha_cluster_manage_selinux: true A variable that determines whether the ha_cluster RHEL system role manages the ports of the firewall high availability service using the selinux RHEL system role. ha_cluster_fence_agent_packages: <fence_agent_packages> A list of fence agent packages to install. ha_cluster_resource_primitives: <cluster_resources> A list of resource definitions for the Pacemaker resources configured by the ha_cluster RHEL system role, including fencing ha_cluster_resource_groups: <resource_groups> A list of resource group definitions configured by the ha_cluster RHEL system role. For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file on the control node. Validate the playbook syntax: Note that this command only validates the syntax and does not protect against a wrong but valid configuration. Run the playbook: When you use the apache resource agent to manage Apache, it does not use systemd . Because of this, you must edit the logrotate script supplied with Apache so that it does not use systemctl to reload Apache. Remove the following line in the /etc/logrotate.d/httpd file on each node in the cluster. # /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true Replace the line you removed with the following three lines, specifying /var/run/httpd- website .pid as the PID file path where website is the name of the Apache resource. In this example, the Apache resource name is Website . /usr/bin/test -f /var/run/httpd-Website.pid >/dev/null 2>/dev/null && /usr/bin/ps -q USD(/usr/bin/cat /var/run/httpd-Website.pid) >/dev/null 2>/dev/null && /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd-Website.pid" -k graceful > /dev/null 2>/dev/null || true Verification From one of the nodes in the cluster, check the status of the cluster. Note that all four resources are running on the same node, z1.example.com . If you find that the resources you configured are not running, you can run the pcs resource debug-start resource command to test the resource configuration. Once the cluster is up and running, you can point a browser to the IP address you defined as the IPaddr2 resource to view the sample display, consisting of the simple word "Hello". To test whether the resource group running on z1.example.com fails over to node z2.example.com , put node z1.example.com in standby mode, after which the node will no longer be able to host resources. After putting node z1 in standby mode, check the cluster status from one of the nodes in the cluster. Note that the resources should now all be running on z2 . The web site at the defined IP address should still display, without interruption. To remove z1 from standby mode, enter the following command. Note Removing a node from standby mode does not in itself cause the resources to fail back over to that node. This will depend on the resource-stickiness value for the resources. For information about the resource-stickiness meta attribute, see Configuring a resource to prefer its current node . Additional resources /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md file /usr/share/doc/rhel-system-roles/ha_cluster/ directory

Commands:
- hosts: node1 node2 vars: ha_cluster_cluster_present: false roles: - rhel-system-roles.ha_cluster
ha_cluster_pcs_permission_list: - type: group name: hacluster allow_list: - grant - read - write
ha_cluster_transport: type: knet options: - name: option1_name value: option1_value - name: option2_name value: option2_value links: - - name: option1_name value: option1_value - name: option2_name value: option2_value - - name: option1_name value: option1_value - name: option2_name value: option2_value compression: - name: option1_name value: option1_value - name: option2_name value: option2_value crypto: - name: option1_name value: option1_value - name: option2_name value: option2_value
ha_cluster_totem: options: - name: option1_name value: option1_value - name: option2_name value: option2_value
ha_cluster_quorum: options: - name: option1_name value: option1_value - name: option2_name value: option2_value device: model: string model_options: - name: option1_name value: option1_value - name: option2_name value: option2_value generic_options: - name: option1_name value: option1_value - name: option2_name value: option2_value heuristics_options: - name: option1_name value: option1_value - name: option2_name value: option2_value
ha_cluster_cluster_properties: - attrs: - name: property1_name value: property1_value - name: property2_name value: property2_value
- hosts: node1 node2 vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: password ha_cluster_cluster_properties: - attrs: - name: stonith-enabled value: 'true' - name: no-quorum-policy value: stop roles: - rhel-system-roles.ha_cluster
ha_cluster_node_options: - node_name: node1 pcs_address: node1-address corosync_addresses: - 192.168.1.11 - 192.168.2.11 sbd_watchdog_modules: - module1 - module2 sbd_watchdog_modules_blocklist: - module3 sbd_watchdog: /dev/watchdog2 sbd_devices: - /dev/disk/by-id/000001 - /dev/disk/by-id/000002 - /dev/disk/by-id/000003 attributes: - attrs: - name: attribute1 value: value1_node1 - name: attribute2 value: value2_node1 utilization: - attrs: - name: utilization1 value: value1_node1 - name: utilization2 value: value2_node1 - node_name: node2 pcs_address: node2-address:2224 corosync_addresses: - 192.168.1.12 - 192.168.2.12 sbd_watchdog_modules: - module1 sbd_watchdog_modules_blocklist: - module3 sbd_watchdog: /dev/watchdog1 sbd_devices: - /dev/disk/by-id/000001 - /dev/disk/by-id/000002 - /dev/disk/by-id/000003 attributes: - attrs: - name: attribute1 value: value1_node2 - name: attribute2 value: value2_node2 utilization: - attrs: - name: utilization1 value: value1_node2 - name: utilization2 value: value2_node2
- id: resource-id agent: resource-agent instance_attrs: - attrs: - name: attribute1_name value: attribute1_value - name: attribute2_name value: attribute2_value meta_attrs: - attrs: - name: meta_attribute1_name value: meta_attribute1_value - name: meta_attribute2_name value: meta_attribute2_value copy_operations_from_agent: bool operations: - action: operation1-action attrs: - name: operation1_attribute1_name value: operation1_attribute1_value - name: operation1_attribute2_name value: operation1_attribute2_value - action: operation2-action attrs: - name: operation2_attribute1_name value: operation2_attribute1_value - name: operation2_attribute2_name value: operation2_attribute2_value
ha_cluster_resource_groups: - id: group-id resource_ids: - resource1-id - resource2-id meta_attrs: - attrs: - name: group_meta_attribute1_name value: group_meta_attribute1_value - name: group_meta_attribute2_name value: group_meta_attribute2_value
ha_cluster_resource_clones: - resource_id: resource-to-be-cloned promotable: true id: custom-clone-id meta_attrs: - attrs: - name: clone_meta_attribute1_name value: clone_meta_attribute1_value - name: clone_meta_attribute2_name value: clone_meta_attribute2_value
ha_cluster_resource_defaults: meta_attrs: - id: defaults-set-1-id rule: rule-string score: score-value attrs: - name: meta_attribute1_name value: meta_attribute1_value - name: meta_attribute2_name value: meta_attribute2_value - id: defaults-set-2-id rule: rule-string score: score-value attrs: - name: meta_attribute3_name value: meta_attribute3_value - name: meta_attribute4_name value: meta_attribute4_value
ha_cluster_stonith_levels: - level: 1..9 target: node_name target_pattern: node_name_regular_expression target_attribute: node_attribute_name target_value: node_attribute_value resource_ids: - fence_device_1 - fence_device_2 - level: 1..9 target: node_name target_pattern: node_name_regular_expression target_attribute: node_attribute_name target_value: node_attribute_value resource_ids: - fence_device_1 - fence_device_2
ha_cluster_constraints_location: - resource: id: resource-id node: node-name id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
ha_cluster_constraints_location: - resource: pattern: resource-pattern node: node-name id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
ha_cluster_constraints_location: - resource: id: resource-id role: resource-role rule: rule-string id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
ha_cluster_constraints_location: - resource: pattern: resource-pattern role: resource-role rule: rule-string id: constraint-id options: - name: score value: score-value - name: resource-discovery value: resource-discovery-value
ha_cluster_constraints_colocation: - resource_follower: id: resource-id1 role: resource-role1 resource_leader: id: resource-id2 role: resource-role2 id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
ha_cluster_constraints_colocation: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
ha_cluster_constraints_order: - resource_first: id: resource-id1 action: resource-action1 resource_then: id: resource-id2 action: resource-action2 id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
ha_cluster_constraints_order: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value id: constraint-id options: - name: score value: score-value - name: option-name value: option-value
ha_cluster_constraints_ticket: - resource: id: resource-id role: resource-role ticket: ticket-name id: constraint-id options: - name: loss-policy value: loss-policy-value - name: option-name value: option-value
ha_cluster_constraints_ticket: - resource_sets: - resource_ids: - resource-id1 - resource-id2 options: - name: option-name value: option-value ticket: ticket-name id: constraint-id options: - name: option-name value: option-value
ha_cluster_acls: acl_roles: - id: role-id-1 description: role description permissions: - kind: access-type xpath: XPath expression - kind: access-type reference: cib-element-id - id: role-id-2 permissions: - kind: access-type xpath: XPath expression acl_users: - id: user-name roles: - role-id-1 - role-id-2 acl_groups: - id: group-name roles: - role-id-2
ha_cluster_cluster_properties: - attrs: - name: enable-acl value: 'true'
ha_cluster_alerts: - id: alert1 path: /alert1/path description: Alert1 description instance_attrs: - attrs: - name: alert_attr1_name value: alert_attr1_value meta_attrs: - attrs: - name: alert_meta_attr1_name value: alert_meta_attr1_value recipients: - value: recipient_value id: recipient1 description: Recipient1 description instance_attrs: - attrs: - name: recipient_attr1_name value: recipient_attr1_value meta_attrs: - attrs: - name: recipient_meta_attr1_name value: recipient_meta_attr1_value
all: hosts: node1: ha_cluster: node_name: node-A pcs_address: node1-address corosync_addresses: - 192.168.1.11 - 192.168.2.11 node2: ha_cluster: node_name: node-B pcs_address: node2-address:2224 corosync_addresses: - 192.168.1.12 - 192.168.2.12
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create TLS certificates and key files in a high availability cluster ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_pcsd_certificates: - name: FILENAME common_name: "{{ ansible_hostname }}" ca: self-sign
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster with minimum required parameters and no fencing ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster with fencing and resources ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_resource_primitives: - id: xvm-fencing agent: 'stonith:fence_xvm' instance_attrs: - attrs: - name: pcmk_host_list value: node1 node2 - id: simple-resource agent: 'ocf:pacemaker:Dummy' - id: resource-with-options agent: 'ocf:pacemaker:Dummy' instance_attrs: - attrs: - name: fake value: fake-value - name: passwd value: passwd-value meta_attrs: - attrs: - name: target-role value: Started - name: is-managed value: 'true' operations: - action: start attrs: - name: timeout value: '30s' - action: monitor attrs: - name: timeout value: '5' - name: interval value: '1min' - id: dummy-1 agent: 'ocf:pacemaker:Dummy' - id: dummy-2 agent: 'ocf:pacemaker:Dummy' - id: dummy-3 agent: 'ocf:pacemaker:Dummy' - id: simple-clone agent: 'ocf:pacemaker:Dummy' - id: clone-with-options agent: 'ocf:pacemaker:Dummy' ha_cluster_resource_groups: - id: simple-group resource_ids: - dummy-1 - dummy-2 meta_attrs: - attrs: - name: target-role value: Started - name: is-managed value: 'true' - id: cloned-group resource_ids: - dummy-3 ha_cluster_resource_clones: - resource_id: simple-clone - resource_id: clone-with-options promotable: yes id: custom-clone-id meta_attrs: - attrs: - name: clone-max value: '2' - name: clone-node-max value: '1' - resource_id: cloned-group promotable: yes
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster with fencing and resource operation defaults ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true # 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 # does not interfere with business activities. ha_cluster_resource_defaults: meta_attrs: - id: core-hours rule: date-spec hours=9-16 weekdays=1-5 score: 2 attrs: - name: resource-stickiness value: INFINITY - id: after-hours score: 1 attrs: - name: resource-stickiness value: 0 # Default the timeout on all 10-second-interval # monitor actions on IPaddr2 resources to 8 seconds. ha_cluster_resource_operation_defaults: meta_attrs: - rule: resource ::IPaddr2 and op monitor interval=10s score: INFINITY attrs: - name: timeout value: 8s
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password> fence1_password: <fence1_password> fence2_password: <fence2_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster that defines fencing levels ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_resource_primitives: - id: apc1 agent: 'stonith:fence_apc_snmp' instance_attrs: - attrs: - name: ip value: apc1.example.com - name: username value: user - name: password value: "{{ fence1_password }}" - name: pcmk_host_map value: node1:1;node2:2 - id: apc2 agent: 'stonith:fence_apc_snmp' instance_attrs: - attrs: - name: ip value: apc2.example.com - name: username value: user - name: password value: "{{ fence2_password }}" - name: pcmk_host_map value: node1:1;node2:2 # Nodes have redundant power supplies, apc1 and apc2. Cluster must # ensure that when attempting to reboot a node, both power # supplies # are turned off before either power supply is turned # back on. ha_cluster_stonith_levels: - level: 1 target: node1 resource_ids: - apc1 - apc2 - level: 1 target: node2 resource_ids: - apc1 - apc2
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster with resource constraints ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true # In order to use constraints, we need resources # the constraints will apply to. ha_cluster_resource_primitives: - id: xvm-fencing agent: 'stonith:fence_xvm' instance_attrs: - attrs: - name: pcmk_host_list value: node1 node2 - id: dummy-1 agent: 'ocf:pacemaker:Dummy' - id: dummy-2 agent: 'ocf:pacemaker:Dummy' - id: dummy-3 agent: 'ocf:pacemaker:Dummy' - id: dummy-4 agent: 'ocf:pacemaker:Dummy' - id: dummy-5 agent: 'ocf:pacemaker:Dummy' - id: dummy-6 agent: 'ocf:pacemaker:Dummy' # location constraints ha_cluster_constraints_location: # resource ID and node name - resource: id: dummy-1 node: node1 options: - name: score value: 20 # resource pattern and node name - resource: pattern: dummy-\d+ node: node1 options: - name: score value: 10 # resource ID and rule - resource: id: dummy-2 rule: '#uname eq node2 and date in_range 2022-01-01 to 2022-02-28' # resource pattern and rule - resource: pattern: dummy-\d+ rule: node-type eq weekend and date-spec weekdays=6-7 # colocation constraints ha_cluster_constraints_colocation: # simple constraint - resource_leader: id: dummy-3 resource_follower: id: dummy-4 options: - name: score value: -5 # set constraint - resource_sets: - resource_ids: - dummy-1 - dummy-2 - resource_ids: - dummy-5 - dummy-6 options: - name: sequential value: "false" options: - name: score value: 20 # order constraints ha_cluster_constraints_order: # simple constraint - resource_first: id: dummy-1 resource_then: id: dummy-6 options: - name: symmetrical value: "false" # set constraint - resource_sets: - resource_ids: - dummy-1 - dummy-2 options: - name: require-all value: "false" - name: sequential value: "false" - resource_ids: - dummy-3 - resource_ids: - dummy-4 - dummy-5 options: - name: sequential value: "false" # ticket constraints ha_cluster_constraints_ticket: # simple constraint - resource: id: dummy-1 ticket: ticket1 options: - name: loss-policy value: stop # set constraint - resource_sets: - resource_ids: - dummy-3 - dummy-4 - dummy-5 ticket: ticket2 options: - name: loss-policy value: fence
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster that configures Corosync values ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_transport: type: knet options: - name: ip_version value: ipv4-6 - name: link_mode value: active links: - - name: linknumber value: 1 - name: link_priority value: 5 - - name: linknumber value: 0 - name: link_priority value: 10 compression: - name: level value: 5 - name: model value: zlib crypto: - name: cipher value: none - name: hash value: none ha_cluster_totem: options: - name: block_unlisted_ips value: 'yes' - name: send_join value: 0 ha_cluster_quorum: options: - name: auto_tie_breaker value: 1 - name: wait_for_all value: 1
ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with ACLs assigned ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true # To use an ACL role permission reference, the reference must exist in CIB. ha_cluster_resource_primitives: - id: not-for-operator agent: 'ocf:pacemaker:Dummy' # ACLs must be enabled (using the enable-acl cluster property) in order to be effective. ha_cluster_cluster_properties: - attrs: - name: enable-acl value: 'true' ha_cluster_acls: acl_roles: - id: operator description: HA cluster operator permissions: - kind: write xpath: //crm_config//nvpair[@name='maintenance-mode'] - kind: deny reference: not-for-operator - id: administrator permissions: - kind: write xpath: /cib acl_users: - id: alice roles: - operator - administrator - id: bob roles: - administrator acl_groups: - id: admins roles: - administrator
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with SBD fencing ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: my_sbd_devices: # This variable is indirectly used by various variables of the ha_cluster RHEL system role. # Its purpose is to define SBD devices once so they do not need # to be repeated several times in the role variables. - /dev/disk/by-id/000001 - /dev/disk/by-id/000002 - /dev/disk/by-id/000003 ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_sbd_enabled: true ha_cluster_sbd_options: - name: delay-start value: 'no' - name: startmode value: always - name: timeout-action value: 'flush,reboot' - name: watchdog-timeout value: 30 ha_cluster_node_options: - node_name: node1 sbd_watchdog_modules: - iTCO_wdt sbd_watchdog_modules_blocklist: - ipmi_watchdog sbd_watchdog: /dev/watchdog1 sbd_devices: "{{ my_sbd_devices }}" - node_name: node2 sbd_watchdog_modules: - iTCO_wdt sbd_watchdog_modules_blocklist: - ipmi_watchdog sbd_watchdog: /dev/watchdog1 sbd_devices: "{{ my_sbd_devices }}" # Best practice for setting SBD timeouts: # watchdog-timeout * 2 = msgwait-timeout (set automatically) # msgwait-timeout * 1.2 = stonith-timeout ha_cluster_cluster_properties: - attrs: - name: stonith-timeout value: 72 ha_cluster_resource_primitives: - id: fence_sbd agent: 'stonith:fence_sbd' instance_attrs: - attrs: - name: devices value: "{{ my_sbd_devices | join(',') }}" - name: pcmk_delay_base value: 30
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
all: hosts: node1: ha_cluster: sbd_watchdog_modules: - iTCO_wdt sbd_watchdog_modules_blocklist: - ipmi_watchdog sbd_watchdog: /dev/watchdog1 sbd_devices: - /dev/disk/by-id/000001 - /dev/disk/by-id/000001 - /dev/disk/by-id/000003 node2: ha_cluster: sbd_watchdog_modules: - iTCO_wdt sbd_watchdog_modules_blocklist: - ipmi_watchdog sbd_watchdog: /dev/watchdog1 sbd_devices: - /dev/disk/by-id/000001 - /dev/disk/by-id/000002 - /dev/disk/by-id/000003
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with sbd fencing devices configured in an inventory file ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_sbd_enabled: true ha_cluster_sbd_options: - name: delay-start value: 'no' - name: startmode value: always - name: timeout-action value: 'flush,reboot' - name: watchdog-timeout value: 30 # Best practice for setting SBD timeouts: # watchdog-timeout * 2 = msgwait-timeout (set automatically) # msgwait-timeout * 1.2 = stonith-timeout ha_cluster_cluster_properties: - attrs: - name: stonith-timeout value: 72 ha_cluster_resource_primitives: - id: fence_sbd agent: 'stonith:fence_sbd' instance_attrs: - attrs: # taken from host_vars # this only works if all nodes have the same sbd_devices - name: devices value: "{{ ha_cluster.sbd_devices | join(',') }}" - name: pcmk_delay_base value: 30
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with utilization attributes ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_cluster_properties: - attrs: - name: placement-strategy value: utilization ha_cluster_node_options: - node_name: node1 utilization: - attrs: - name: utilization1 value: 1 - name: utilization2 value: 2 - node_name: node2 utilization: - attrs: - name: utilization1 value: 3 - name: utilization2 value: 4 ha_cluster_resource_primitives: - id: resource1 agent: 'ocf:pacemaker:Dummy' utilization: - attrs: - name: utilization1 value: 2 - name: utilization2 value: 3
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Configure a cluster with alerts ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_alerts: - id: alert1 path: /alert1/path description: Alert1 description instance_attrs: - attrs: - name: alert_attr1_name value: alert_attr1_value meta_attrs: - attrs: - name: alert_meta_attr1_name value: alert_meta_attr1_value recipients: - value: recipient_value id: recipient1 description: Recipient1 description instance_attrs: - attrs: - name: recipient_attr1_name value: recipient_attr1_value meta_attrs: - attrs: - name: recipient_meta_attr1_name value: recipient_meta_attr1_value
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Configure a host with a quorum device hosts: nodeQ vars_files: - vault.yml tasks: - name: Create a quorum device for the cluster ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_present: false ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_qnetd: present: true
ansible-playbook --ask-vault-pass --syntax-check ~/playbook-qdevice.yml
ansible-playbook --ask-vault-pass ~/playbook-qdevice.yml
--- - name: Configure a cluster to use a quorum device hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create cluster that uses a quorum device ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_quorum: device: model: net model_options: - name: host value: nodeQ - name: algorithm value: lms
ansible-playbook --ask-vault-pass --syntax-check ~/playbook-cluster-qdevice.yml
ansible-playbook --ask-vault-pass ~/playbook-cluster-qdevice.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: node1 node2 vars_files: - vault.yml tasks: - name: Create a cluster that defines node attributes ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_cluster_name: my-new-cluster ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_node_options: - node_name: node1 attributes: - attrs: - name: attribute1 value: value1A - name: attribute2 value: value2A - node_name: node2 attributes: - attrs: - name: attribute1 value: value1B - name: attribute2 value: value2B
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
ansible-vault create vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>
cluster_password: <cluster_password>
--- - name: Create a high availability cluster hosts: z1.example.com z2.example.com vars_files: - vault.yml tasks: - name: Configure active/passive Apache server in a high availability cluster ansible.builtin.include_role: name: rhel-system-roles.ha_cluster vars: ha_cluster_hacluster_password: "{{ cluster_password }}" ha_cluster_cluster_name: my_cluster ha_cluster_manage_firewall: true ha_cluster_manage_selinux: true ha_cluster_fence_agent_packages: - fence-agents-apc-snmp ha_cluster_resource_primitives: - id: myapc agent: stonith:fence_apc_snmp instance_attrs: - attrs: - name: ipaddr value: zapc.example.com - name: pcmk_host_map value: z1.example.com:1;z2.example.com:2 - name: login value: apc - name: passwd value: apc - id: my_lvm agent: ocf:heartbeat:LVM-activate instance_attrs: - attrs: - name: vgname value: my_vg - name: vg_access_mode value: system_id - id: my_fs agent: Filesystem instance_attrs: - attrs: - name: device value: /dev/my_vg/my_lv - name: directory value: /var/www - name: fstype value: xfs - id: VirtualIP agent: IPaddr2 instance_attrs: - attrs: - name: ip value: 198.51.100.3 - name: cidr_netmask value: 24 - id: Website agent: apache instance_attrs: - attrs: - name: configfile value: /etc/httpd/conf/httpd.conf - name: statusurl value: http://127.0.0.1/server-status ha_cluster_resource_groups: - id: apachegroup resource_ids: - my_lvm - my_fs - VirtualIP - Website
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
ansible-playbook --ask-vault-pass ~/playbook.yml
/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
/usr/bin/test -f /var/run/httpd-Website.pid >/dev/null 2>/dev/null && /usr/bin/ps -q USD(/usr/bin/cat /var/run/httpd-Website.pid) >/dev/null 2>/dev/null && /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd-Website.pid" -k graceful > /dev/null 2>/dev/null || true
pcs status Cluster name: my_cluster Last updated: Wed Jul 31 16:38:51 2013 Last change: Wed Jul 31 16:42:14 2013 via crm_attribute on z1.example.com Stack: corosync Current DC: z2.example.com (2) - partition with quorum Version: 1.1.10-5.el7-9abe687 2 Nodes configured 6 Resources configured Online: [ z1.example.com z2.example.com ] Full list of resources: myapc (stonith:fence_apc_snmp): Started z1.example.com Resource Group: apachegroup my_lvm (ocf::heartbeat:LVM-activate): Started z1.example.com my_fs (ocf::heartbeat:Filesystem): Started z1.example.com VirtualIP (ocf::heartbeat:IPaddr2): Started z1.example.com Website (ocf::heartbeat:apache): Started z1.example.com
Hello
pcs node standby z1.example.com
pcs status Cluster name: my_cluster Last updated: Wed Jul 31 17:16:17 2013 Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com Stack: corosync Current DC: z2.example.com (2) - partition with quorum Version: 1.1.10-5.el7-9abe687 2 Nodes configured 6 Resources configured Node z1.example.com (1): standby Online: [ z2.example.com ] Full list of resources: myapc (stonith:fence_apc_snmp): Started z1.example.com Resource Group: apachegroup my_lvm (ocf::heartbeat:LVM-activate): Started z2.example.com my_fs (ocf::heartbeat:Filesystem): Started z2.example.com VirtualIP (ocf::heartbeat:IPaddr2): Started z2.example.com Website (ocf::heartbeat:apache): Started z2.example.com
pcs node unstandby z1.example.com