Procedure 3.6. Defining the First Communication Channel¶

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

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

   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. 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. If needed, define a second communication channel as described below. Or click Next and proceed with Procedure 3.8, “Enabling Secure Authentication”.

Procedure 3.7. Defining a Redundant Communication Channel¶

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.

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

Procedure 3.8. Enabling Secure Authentication¶

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.

Procedure 3.9. Configuring Csync2 with YaST¶

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 host names of all nodes in your cluster. For each node, you must use exactly the strings that are returned by the hostname command.

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 path name for each file.

6. Activate Csync2 by clicking Turn Csync2 ON. This will execute chkconfig csync2 to start Csync2 automatically at boot time.

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.10, “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”.

Procedure 3.10. Synchronizing the Configuration Files with Csync2¶

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.

Procedure 3.11. Configuring the conntrackd with YaST¶

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

Procedure 3.12. Enabling the Cluster Services¶

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

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

   No-Start-on-Boot Parameter for OpenAIS

   While generally disabling the cluster service (including other start/stop scripts) at boot time might break the cluster configuration sometimes, enabling it unconditionally at boot time may also lead to unwanted effect with regards to fencing. To fine-tune this, insert the START_ON_BOOT parameter to /etc/sysconfig/openais. Setting START_ON_BOOT=No will prevent the OpenAIS service from starting at boot time (allowing you to start it manually whenever you want to start it). The default is START_ON_BOOT=Yes.

3. If you want to use the Pacemaker GUI for configuring, managing and monitoring cluster resources, activate Enable mgmtd. This daemon is needed for the GUI.

4. To start or stop OpenAIS immediately, click the respective button.

5. To open the ports in the firewall that are needed for cluster communication on the current machine, activate Open Port in Firewall. The configuration is written to /etc/sysconfig/SuSEfirewall2.d/services/cluster.

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

Procedure 3.13. Starting OpenAIS/Corosync and Checking the Status

1. Log in to an existing node.

2. Check if the service is already running:

   root # rcopenais status

   If not, start OpenAIS/Corosync now:

   root # rcopenais start

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.