For communication between the cluster nodes, use either multicast (UDP) or unicast (UDPU).

1. In the YaST cluster module, switch to the Communication Channels category.

2. To use multicast:

   1. Set the Transport protocol to Multicast.

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

   3. Define the Multicast Address.

   4. Define the Multicast Port.

      Wit the values entered above, you have now defined one communication channel for the cluster. In multicast mode, the same bindnetaddr, mcastaddr, and mcastport will be used for all cluster nodes. All nodes in the cluster will know each other by using the same multicast address. For different clusters, use different multicast addresses.

      

      Figure 3.2: YaST Cluster—Multicast Configuration #

3. To use unicast:

   1. Set the Transport protocol to Unicast.

   2. Define the Bind Network Address. Set the value to the subnet you will use for cluster unicast.

   3. Define the Multicast Port.

   4. For unicast communication, Corosync needs to know the IP addresses of all nodes in the cluster. For each node that will be part of the cluster, 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.

      

      Figure 3.3: YaST Cluster—Unicast Configuration #

4. The option Auto Generate Node ID is enabled by default. If you are using IPv4 addresses, node IDs are optional but they are required when using IPv6 addresses. To automatically generate a unique ID for every cluster node (which is less error-prone than specifying IDs manually for each node), keep this option enabled.

5. Define a Cluster Name.

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

7. If you modified any options for an existing cluster, confirm your changes and close the cluster module. YaST writes the configuration to /etc/corosync/corosync.conf.

8. If needed, define a second communication channel as described below. Or click Next and proceed with Procedure 3.7, “Enabling Secure Authentication”.

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. In case one network fails, the cluster nodes can still communicate via the other network.

Important: Redundant Rings and /etc/hosts

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

1. In the YaST cluster module, 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, define the Bind Network Address, the Multicast Address and the Multicast Port for the redundant channel.

   If you use unicast, define the Bind Network Address, the Multicast Port and enter the IP addresses of all nodes that will be part of the cluster.

   Now you have defined an additional communication channel in Corosync that will form a second token-passing ring. In /etc/corosync/corosync.conf, the primary ring (the first channel you have configured) gets the ringnumber 0, the second ring (redundant channel) the ringnumber 1.

4. To tell Corosync how and when to use the different channels, select the rrp_mode you want to use (active or passive). For more information about the modes, refer to Redundant Ring Protocol (RRP) or click Help. As soon as RRP is used, the Stream Control Transmission Protocol (SCTP) is used for communication between the nodes (instead of TCP). The High Availability Extension monitors the status of the current rings and automatically re-enables redundant rings after faults. Alternatively, you can also check the ring status manually with corosync-cfgtool. View the available options with -h.

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

5. If you modified any options for an existing cluster, confirm your changes and close the cluster module. YaST writes the configuration to /etc/corosync/corosync.conf.

6. For further cluster configuration, click Next and proceed with Section 3.5.3, “Defining Authentication Settings”.

1. In the YaST cluster module, 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.

   

   Figure 3.4: YaST Cluster—Security #

   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. If you modified any options for an existing cluster, confirm your changes and close the cluster module. YaST writes the configuration to /etc/corosync/corosync.conf.

5. For further cluster configuration, click Next and proceed with Section 3.5.4, “Transferring the Configuration to All Nodes”.

1. Configuring Csync2 with YaST.

2. Synchronizing the Configuration Files with Csync2.

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

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

   

   Tip: Hostname Resolution

   In case hostname resolution should not work properly in your network for some reason, you can also specify a combination of hostname 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 will then use the IP addresses when connecting.

3. Click Generate Pre-Shared-Keys to create a key file for the synchronization group. The key file is written to /etc/csync2/key_hagroup. After it has been created, it must be copied manually to all members of the cluster.

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

   

   Figure 3.5: YaST Cluster—Csync2 #

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

6. Activate Csync2 by clicking Turn Csync2 ON. This will execute the following command to start Csync2 automatically at boot time:

   root # systemctl enable csync2.socket

7. If you modified any options for an existing cluster, confirm your changes and close the cluster module. YaST then writes the Csync2 configuration to /etc/csync2/csync2.cfg. To start the synchronization process now, proceed with Procedure 3.9, “Synchronizing the Configuration Files with Csync2”.

8. For further cluster configuration, click Next and proceed with Section 3.5.5, “Synchronizing Connection Status Between Cluster Nodes”.

To successfully synchronize the files with Csync2, make sure that the following prerequisites are met:

1. On the node that you want to copy the configuration from, execute the following command:

   root # csync2 -xv

   This will synchronize all the files once by pushing them to the other nodes. If all files are synchronized successfully, Csync2 will finish 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 will report a conflict. You will get 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:

   root # csync2 -f /etc/corosync/corosync.conf
   csync2 -x

1. Configuring the conntrackd with YaST.

2. Configuring a resource for conntrackd (class: ocf, provider: heartbeat). If you use Hawk to add the resource, use the default values proposed by Hawk.

Use the YaST cluster module to configure the user-space 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. In the YaST cluster module, switch to the Configure conntrackd category.

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. Click 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. For further cluster configuration, click Next and proceed with Section 3.5.6, “Configuring Services”.

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

2. To start Pacemaker 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 Pacemaker manually each time this node is booted. To start Pacemaker manually, use the command:

   root # systemctl start pacemaker.service

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

4. If you modified any options for an existing cluster node, confirm your changes and close the cluster module. Note that the configuration only applies to the current machine, not to all cluster nodes.

   If you have done the initial cluster setup exclusively with the YaST cluster module, you have now completed the basic configuration steps. Proceed with Section 3.5.7, “Bringing the Cluster Online”.

   

   Figure 3.7: YaST Cluster—Services #

1. Log in to an existing node.

2. Check if the service is already running:

   root # systemctl status pacemaker.service

   If not, start Pacemaker now:

   root # systemctl start pacemaker.service

3. Repeat the steps above for each of the cluster nodes.

4. On one of the nodes, check the cluster status with the crm status command. If all nodes are online, the output should be similar to the following:

   root # crm status
         Last updated: Thu Jul  3 11:07:10 2014
         Last change: Thu Jul  3 10:58:43 2014
         Current DC: alice (175704363) - partition with quorum
         2 Nodes configured
         0 Resources configured
         
         Online: [ alice bob ]

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