Procedure 3.4. 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 its IP address. To modify or remove any addresses of cluster members, use the Edit or Del buttons.

      Figure 3.3. YaST Cluster—Unicast Configuration
      
      

4. Activate Auto Generate Node ID to automatically generate a unique ID for every cluster node.

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.6, “Enabling Secure Authentication”.

Procedure 3.5. 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.6. 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, proceed with Section 3.5.4, “Configuring Services”.

Procedure 3.7. Enabling OpenAIS and mgmtd¶

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.

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

   Figure 3.5. YaST Cluster—Services
   
   

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

1. Configuring Csync2 with YaST.

2. Synchronizing the Configuration Files with Csync2.

Procedure 3.8. 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 hostnames 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.6. 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 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.9, “Synchronizing the Configuration Files with Csync2”.

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

Procedure 3.9. 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:

   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:

   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.10. 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. Confirm your changes and close the cluster module. 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”.

Procedure 3.11. Starting OpenAIS/Corosync and Checking the Status

1. Log in to an existing node.

2. Check if the service is already running:

   rcopenais status

   If not, start OpenAIS/Corosync now:

   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 following command:

   crm_mon

   If all nodes are online, the output should be similar to the following:

   ============
   Last updated: Thu Nov 10 13:37:48 2011
   Last change: Wed Nov  9 17:40:06 2011 by hacluster via cibadmin on auckland
   Stack: openais
   Current DC: auckland - partition with quorum
   Version: 1.1.6-2d8fad5daab7e592069215f144cc765def450309
   2 Nodes configured, 2 expected votes
   8 Resources configured.
   ============
   
   Online: [ e231 e229 ]

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