The primary objective of LAN connectivity in a cluster is to provide uninterrupted heartbeat communications. Use the guidelines in this section to design the LAN connectivity for each of the peer clusters in the business continuity cluster.
Use a dedicated VLAN (virtual local area network) for each cluster.
The cluster protocol is non-routable, so you cannot direct communications to specific IP addresses. Using a VLAN for the cluster nodes provides a protected environment for the heartbeat process and ensures that heartbeat packets are exchanged only between the nodes of a given cluster.
When using a VLAN, no foreign host can interfere with the heartbeat. For example, it avoids broadcast storms that slow traffic and result in false split-brain failures.
Use channel bonding for adapters for LAN fault tolerance. Channel bonding combines Ethernet interfaces on a host computer for redundancy or increased throughput. It helps increase the availability of an individual cluster node, which helps avoid or reduce the occurrences of failover caused by slow LAN traffic. For information, see /usr/src/linux/Documentation/bonding.txt.
When configuring Spanning Tree Protocol (STP), ensure that Portfast is enabled, or consider Rapid Spanning Tree. The default settings for STP inhibit the heartbeat for over 30 seconds whenever there is a change in link status. Test your STP configuration with Novell Cluster Services running to ensure that a node is not cast out of the cluster when a broken link is restored.
Consider connecting cluster nodes to access switches for fault tolerance.
Use the guidelines in this section to plan your IP address assignment so that it is consistently applied across all peer clusters.
You need a unique static IP address for each of the following components of each peer cluster:
Cluster (master IP address)
Cluster nodes
Cluster resources that are not BCC-enabled, such as file system resources and service resources that support site-based services like DHCP, DNS, and SLP.
Cluster resources that are BCC-enabled, such as file system resources and application resources.
You can dedicate IP address ranges for BCC-enabled cluster resources. Your IP address plan should provide an IP address range with sufficient addresses for each cluster. With careful planning, the IP address and the name of the virtual server for the cluster resource never need to change.
When a cluster resource is BCC-migrated to a peer cluster, the IP address of the inbound cluster resource is transformed to use an IP address in the same subnet of the target peer cluster. You define the transformation rules to accomplish this by using the Identity Manager driver’s search-and-replace functionality. The transformation rules are easier to define and remember when you use strict IP address assignment, such as using the third octet to identify the subnet of the peer cluster. For information about setting up the transformation rules, see Section 7.3, Adding Search-and-Replace Values to the Resource Replacement Script.
Dynamic DNS (Domain Name Service) is an alternate technique for transforming IP addresses. For information, see Section E.0, Using Dynamic DNS with BCC.
Unrelated to BCC, if you change the IP address of a BCC-enabled cluster resource, modify the address according to the instructions in Changing the IP Address of a Cluster Resource in the Overview of OES Cluster Services . Before you bring the resource online, modify the transformation rules as needed to ensure that the resource can still be failed over to a peer cluster.
IMPORTANT:If you change the IP address of a BCC-enabled cluster resource, you might also need to update the transformation rules for the resource.
The master IP addresses are stored in the NCS:BCC Peers attribute. Ensure that SLP is properly configured for name resolution.