7 Using the YaST cluster module #

When using multicast, the same bindnetaddr, mcastaddr, and mcastport is used for all cluster nodes. All nodes in the cluster know each other by using the same multicast address. For different clusters, use different multicast addresses.

1. If you are modifying an existing cluster, switch to the Communication Channels category.

   If you are following the initial setup wizard, you do not need to switch categories manually.

2. Set the Transport protocol to Multicast.

3. Define the Bind Network Address. Set the value to the subnet you will use for cluster multicast.

4. Define the Multicast Address.

5. Define the Port.

6. To automatically generate a unique ID for every cluster node, keep Auto Generate Node ID enabled.

7. Define a Cluster Name.

8. Enter the number of Expected Votes. This is important for Corosync to calculate quorum in case of a partitioned cluster. By default, each node has 1 vote. The number of Expected Votes must match the number of nodes in your cluster.

9. If you need to define a redundant communication channel in Corosync, continue to Procedure 7.3, “Defining a redundant communication channel”.

   Otherwise, confirm your changes with Next (setup wizard) or Finish (existing cluster).

1. If you are modifying an existing cluster, switch to the Communication Channels category.

   If you are following the initial setup wizard, you do not need to switch categories manually.

2. Set the Transport protocol to Unicast.

3. Define the Port.

4. For unicast communication, Corosync needs to know the IP addresses of all nodes in the cluster. For each node, select Add and enter the following details:

   • IP Address

   • Redundant IP Address (only required if you use a second communication channel in Corosync)

   • Node ID (only required if the option Auto Generate Node ID is disabled)

   To modify or remove any addresses of cluster members, use the Edit or Del buttons.

5. To automatically generate a unique ID for every cluster node keep Auto Generate Node ID enabled.

6. Define a Cluster Name.

7. Enter the number of Expected Votes. This is important for Corosync to calculate quorum in case of a partitioned cluster. By default, each node has 1 vote. The number of Expected Votes must match the number of nodes in your cluster.

8. If you need to define a redundant communication channel in Corosync, continue to Procedure 7.3, “Defining a redundant communication channel”.

   Otherwise, confirm your changes with Next (setup wizard) or Finish (existing cluster).

If network device bonding cannot be used for any reason, the second best choice is to define a redundant communication channel (a second ring) in Corosync. That way, two physically separate networks can be used for communication. If one network fails, the cluster nodes can still communicate via the other network.

The additional communication channel in Corosync forms a second token-passing ring. The first channel you configured is the primary ring and gets the ring number 0. The second ring (redundant channel) gets the ring number 1.

Important: Redundant rings and /etc/hosts

If multiple rings are configured in Corosync, each node can have multiple IP addresses. This needs to be reflected in the /etc/hosts file of all nodes.

1. Configure the first channel as described in Procedure 7.1, “Defining the first communication channel (multicast)” or Procedure 7.2, “Defining the first communication channel (unicast)”.

2. Activate Redundant Channel. The redundant channel must use the same protocol as the first communication channel you defined.

3. If you use multicast, enter the following parameters: the Bind Network Address to use, the Multicast Address and the Port for the redundant channel.

   If you use unicast, define the following parameters: the Bind Network Address to use, and the Port. Under Member Address, Edit each entry to add a Redundant IP for each node that will be part of the cluster.

4. To tell Corosync how and when to use the different channels, select the rrp_mode to use:

   • If only one communication channel is defined, rrp_mode is automatically disabled (value none).

   • If set to active, Corosync uses both interfaces actively. However, this mode is deprecated.

   • If set to passive, Corosync sends messages alternatively over the available networks.

   When RRP is used, SUSE Linux Enterprise High Availability monitors the status of the current rings and automatically re-enables redundant rings after faults.

   Alternatively, check the ring status manually with corosync-cfgtool. View the available options with -h.

5. Confirm your changes with Next (setup wizard) or Finish (existing cluster).

1. If you are modifying an existing cluster, switch to the Corosync QDevice category.

   If you are following the initial setup wizard, you do not need to switch categories manually.

2. Activate Enable Corosync QDevice.

3. In the QNetd server host field, enter the IP address or host name of the QNetd server.

4. Select the mode for TLS:

   • Use off if TLS is not required and should not be tried.

   • Use on to attempt to connect with TLS, but connect without TLS if it is not available.

   • Use required to make TLS mandatory. QDevice will exit with an error if TLS is not available.

5. Accept the default values for Algorithm and Tie breaker. If you need to change these values, you can do so with the command crm cluster init qdevice after you finish setting up the cluster.

6. Select the Heuristics Mode:

   • Use off to disable heuristics.

   • Use on to run heuristics on a regular basis, as set by the Heuristics Interval.

   • Use sync to only run heuristics during startup, when cluster membership changes, and on connection to QNetd.

7. If you set the Heuristics Mode to on or sync, add your heuristics commands to the Heuristics Executables list:

   1. Select Add. A new window opens.

   2. Enter an Execute Name for the command.

   3. Enter the command in the Execute Script field. This can be a single command or the path to a script, and can be written in any language such as Shell, Python, or Ruby.

   4. Select OK to close the window.

8. Confirm your changes with Next (setup wizard) or Finish (existing cluster).

1. If you are modifying an existing cluster, switch to the Security category.

   If you are following the initial setup wizard, you do not need to switch categories manually.

2. Activate Enable Security Auth.

3. For a newly created cluster, select Generate Auth Key File. An authentication key is created and written to /etc/corosync/authkey.

   If you want the current machine to join an existing cluster, do not generate a new key file. Instead, copy the /etc/corosync/authkey from one of the nodes to the current machine (either manually or with Csync2).

4. Confirm your changes with Next (setup wizard) or Finish (existing cluster). YaST writes the configuration to /etc/corosync/corosync.conf.

1. If you are modifying an existing cluster, switch to the Configure Csync2 category.

   If you are following the initial setup wizard, you do not need to switch categories manually.

2. To specify the synchronization group, select Add in the Sync Host group and enter the local host names of all nodes in your cluster. For each node, you must use exactly the strings that are returned by the hostname command.

   

   Tip: Host name resolution

   If host name resolution does not work properly in your network, you can also specify a combination of host name and IP address for each cluster node. To do so, use the string HOSTNAME@IP such as alice@192.168.2.100, for example. Csync2 then uses the IP addresses when connecting.

3. Select Generate Pre-Shared-Keys to create a key file for the synchronization group. The key file is written to /etc/csync2/key_hagroup.

4. To populate the Sync File list with the files that usually need to be synchronized among all nodes, select Add Suggested Files.

5. To Edit, Add or Remove files from the list of files to be synchronized, use the respective buttons. You must enter the absolute path for each file.

6. Activate Csync2 by selecting Turn Csync2 ON. This enables Csync2 to start automatically at boot time.

7. Confirm your changes with Next (setup wizard) or Finish (existing cluster). YaST writes the Csync2 configuration to /etc/csync2/csync2.cfg.

Use the YaST cluster module to configure the user space conntrackd (see Figure 7.6, “YaST Cluster—conntrackd”). It needs a dedicated network interface that is not used for other communication channels. The daemon can be started via a resource agent afterward.

1. If you are modifying an existing cluster, switch to the Configure conntrackd category.

   If you are following the initial setup wizard, you do not need to switch categories manually.

2. Select a Dedicated Interface for synchronizing the connection status. The IPv4 address of the selected interface is automatically detected and shown in YaST. It must already be configured and it must support multicast.

3. Define the Multicast Address to be used for synchronizing the connection status.

4. In Group Number, define a numeric ID for the group to synchronize the connection status to.

5. Select Generate /etc/conntrackd/conntrackd.conf to create the configuration file for conntrackd.

6. If you modified any options for an existing cluster, confirm your changes and close the cluster module.

7. Confirm your changes with Next (setup wizard) or Finish (existing cluster).

1. If you are modifying an existing cluster, switch to the Service category. You can use the options in this section to start and stop cluster services on this node.

   If you are following the initial setup wizard, you do not need to switch categories manually. You will start the cluster services later, so you can skip straight to Step 5.

2. To start the cluster services each time this cluster node is booted, select Enable cluster. If you select Disable cluster, you must start the cluster services manually each time this node is booted.

3. To start or stop the cluster services immediately, select Start Now or Stop Now.

4. To start or stop QDevice immediately, select Start Now or Stop Now.

5. To open the ports in the firewall that are needed for cluster communication, activate Open Port in Firewall.

6. Confirm your changes with Next (setup wizard) or Finish (existing cluster).

   If you are following the initial setup wizard, this completes the initial configuration and exits YaST. Continue to Section 7.9, “Transferring the configuration to all nodes”.

1. Make sure passwordless SSH is configured between the nodes. This is required for cluster communication.

2. Copy the file /etc/csync2/csync2.cfg manually to all nodes in the cluster.

3. Copy the file /etc/csync2/key_hagroup manually to all nodes in the cluster. It is needed for authentication by Csync2. However, do not regenerate the file on the other nodes—it needs to be the same file on all nodes.

4. Run the following command on all nodes to enable and start the service now:

   # systemctl enable --now csync2.socket

1. To synchronize all files once, run the following command on the machine that you want to copy the configuration from:

   # csync2 -xv

   This synchronizes all the files once by pushing them to the other nodes. If all files are synchronized successfully, Csync2 finishes with no errors.

   If one or several files that are to be synchronized have been modified on other nodes (not only on the current one), Csync2 reports a conflict with an output similar to the one below:

   While syncing file /etc/corosync/corosync.conf:
   ERROR from peer hex-14: File is also marked dirty here!
   Finished with 1 errors.

2. If you are sure that the file version on the current node is the “best” one, you can resolve the conflict by forcing this file and resynchronizing:

   # csync2 -f /etc/corosync/corosync.conf
   # csync2 -xv

1. Log in to an existing node.

2. Start the cluster services on all cluster nodes:

   # crm cluster start --all

   This command requires passwordless SSH access between the nodes. You can also start individual nodes with crm cluster start.

3. Check the cluster status with the crm status command. If all nodes are online, the output should be similar to the following:

   # crm status
   Cluster Summary:
     * Stack: corosync
     * Current DC: alice (version ...) - partition with quorum
     * Last updated: ...
     * Last change:  ... by hacluster via crmd on bob
     * 2 nodes configured
     * 1 resource instance configured
   
   Node List:
     * Online: [ alice bob ]
   ...

   This output indicates that the cluster resource manager is started and is ready to manage resources.