4 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. Start the YaST cluster module and switch to the Communication Channels category.

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. Confirm your changes.

10. If needed, define a redundant communication channel in Corosync as described in Procedure 4.3, “Defining a redundant communication channel”.

1. Start the YaST cluster module and switch to the Communication Channels category.

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, click 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. Confirm your changes.

9. If needed, define a redundant communication channel in Corosync as described in Procedure 4.3, “Defining a redundant communication channel”.

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. Start the YaST cluster module and switch to the Communication Channels category.

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. Enter the IP addresses of all nodes 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.

1. Start the YaST cluster module and switch to the Security category.

2. Activate Enable Security Auth.

3. For a newly created cluster, click 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. YaST writes the configuration to /etc/corosync/corosync.conf.

Use the YaST cluster module to configure the user space conntrackd (see Figure 4.4, “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. Start the YaST cluster module and switch to the Configure conntrackd category.

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

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

4. Click Generate /etc/conntrackd/conntrackd.conf to create the configuration file for conntrackd.

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

6. For further cluster configuration, click Next and proceed with Section 4.6, “Configuring services”.

7. 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.

1. In the YaST cluster module, switch to the Service category.

2. To start the cluster services each time this cluster node is booted, select the respective option in the Booting group. If you select Off in the Booting group, you must start the cluster services manually each time this node is booted. To start the cluster services manually, use the command:

   # crm cluster start

3. To start or stop the cluster services immediately, click the respective button.

4. To open the ports in the firewall that are needed for cluster communication on the current machine, activate Open Port in Firewall.

5. Confirm your changes. Note that the configuration only applies to the current machine, not to all cluster nodes.

1. Configuring Csync2 with YaST.

2. Synchronizing the configuration files with Csync2.

1. Log in to an existing node.

2. Start the cluster services on all cluster nodes:

   # crm cluster start --all

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.