8.6. Configuring Redundant Ring Protocol
As of Red Hat Enterprise Linux 6.4, the Red Hat High Availability Add-On supports the configuration of redundant ring protocol.
When configuring a system to use redundant ring protocol, you must take the following considerations into account:
- Do not specify more than two rings.
- Each ring must use the same protocol; do not mix IPv4 and IPv6.
- If necessary, you can manually specify a multicast address for the second ring. If you specify a multicast address for the second ring, either the alternate multicast address or the alternate port must be different from the multicast address for the first ring. If you do not specify an alternate multicast address, the system will automatically use a different multicast address for the second ring.If you specify an alternate port, the port numbers of the first ring and the second ring must differ by at least two, since the system itself uses port and port-1 to perform operations.
- Do not use two different interfaces on the same subnet.
- In general, it is a good practice to configure redundant ring protocol on two different NICs and two different switches, in case one NIC or one switch fails.
- Do not use the
ifdowncommand or theservice network stopcommand to simulate network failure. This destroys the whole cluster and requires that you restart all of the nodes in the cluster to recover. - Do not use
NetworkManager, since it will execute theifdowncommand if the cable is unplugged. - When one node of a NIC fails, the entire ring is marked as failed.
- No manual intervention is required to recover a failed ring. To recover, you only need to fix the original reason for the failure, such as a failed NIC or switch.
To specify a second network interface to use for redundant ring protocol, you add an
altname component to the clusternode section of the cluster.conf configuration file. When specifying altname, you must specify a name attribute to indicate a second host name or IP address for the node.
The following example specifies
clusternet-node1-eth2 as the alternate name for cluster node clusternet-node1-eth1.
<cluster name="mycluster" config_version="3" >
<logging debug="on"/>
<clusternodes>
<clusternode name="clusternet-node1-eth1" votes="1" nodeid="1">
<fence>
<method name="single">
<device name="xvm" domain="clusternet-node1"/>
</method>
</fence>
<altname name="clusternet-node1-eth2"/>
</clusternode>
The
altname section within the clusternode block is not position dependent. It can come before or after the fence section. Do not specify more than one altname component for a cluster node or the system will fail to start.
Optionally, you can manually specify a multicast address, a port, and a TTL for the second ring by including an
altmulticast component in the cman section of the cluster.conf configuration file. The altmulticast component accepts an addr, a port, and a ttl parameter.
The following example shows the
cman section of a cluster configuration file that sets a multicast address, port, and TTL for the second ring.
<cman> <multicast addr="239.192.99.73" port="666" ttl="2"/> <altmulticast addr="239.192.99.88" port="888" ttl="3"/> </cman>
