Note - Clusters with three or more nodes must use transport junctions. Direct connection between cluster nodes is supported only for two-node clusters.
You can configure additional private-network connections after installation by using the scsetup(1M) utility.
For more information about the cluster interconnect, see the Sun Cluster 3.1 10/03 Concepts Guide.
Public Networks
Add this planning information to the Public Networks Worksheet.
Public networks communicate outside the cluster. Consider the following points when you plan your public network configuration.
Public networks and the private network (cluster interconnect) must use separate adapters.
You must have at least one public network that is connected to all cluster nodes.
You can have as many additional public network connections as your hardware configuration allows.
The local-mac-address? variable must use the default value true for Ethernet adapters. Sun Cluster 3.1 software does not support a local-mac-address? value of false for Ethernet adapters. This requirement is a change from Sun Cluster 3.0, which did require a local-mac-address? value of false.
See IP Network Multipathing Groups for guidelines on planning public-network-adapter backup groups. For more information about public network interfaces, see the Sun Cluster 3.1 10/03 Concepts Guide.
Disk Device Groups
Add this planning information to the Disk Device Group Configurations Worksheet.
You must configure all volume-manager disk groups as Sun Cluster disk device groups. This configuration enables a secondary node to host multihost disks if the primary node fails. Consider the following points when you plan disk device groups.
Failover - You can configure multiported disks and properly configured volume-manager devices as failover devices. Proper configuration of a volume-manager device includes multiported disks and correct setup of the volume manager itself. This configuration ensures that multiple nodes can host the exported device. You cannot configure tape drives, CD-ROMs, or single-ported disks as failover devices.
Mirroring - You must mirror the disks to protect the data from disk failure. See Mirroring Guidelines for additional guidelines. See Installing and Configuring Solstice DiskSuite/Solaris Volume Manager Software or Installing and Configuring VxVM Software and your volume-manager documentation for instructions on mirroring.
For more information about disk device groups, see the Sun Cluster 3.1 10/03 Concepts Guide.
IP Network Multipathing Groups
Add this planning information to the Public Networks Worksheet.
Internet Protocol (IP) Network Multipathing groups, which replace Network Adapter Failover (NAFO) groups, provide public network adapter monitoring and failover, and are the foundation for a network-address resource. A multipathing group provides high availability when the multipathing group is configured with two or more adapters. If one adapter fails, all of the addresses on the failed adapter fail over to another adapter in the multipathing group. In this way, the multipathing-group adapters maintain public-network connectivity to the subnet to which the adapters in the multipathing group connect.
Consider the following points when you plan your multipathing groups.
Each public network adapter must belong to a multipathing group.
For multipathing groups that contain two or more adapters, you must configure a test IP address for each adapter in the group. If a multipathing group contains only one adapter, you do not need to configure a test IP address.
Test IP addresses for all adapters in the same multipathing group must belong to a single IP subnet.
Test IP addresses must not be used by normal applications because the test IP addresses are not highly available.
In the /etc/default/mpathd file, do no change the value of TRACK_INTERFACES_ONLY_WITH_GROUPS from yes to no.
The name of a multipathing group has no requirements or restrictions.
For more information about IP Network Multipathing, see "Deploying Network Multipathing" in IP Network Multipathing Administration Guide (Solaris 8) or"Administering Network Multipathing (Task)" in System Administration Guide: IP Services (Solaris 9).
Quorum Devices
Sun Cluster configurations use quorum devices to maintain data and resource integrity. If the cluster temporarily loses connection to a node, the quorum device prevents amnesia or split-brain problems when the cluster node attempts to rejoin the cluster. You assign quorum devices by using the scsetup(1M) utility.
Note - You do not need to configure quorum devices for a single-node cluster.
Consider the following points when you plan quorum devices.
Minimum - A two-node cluster must have at least one shared disk assigned as a quorum device. For other topologies, quorum devices are optional.
Odd-number rule - If more than one quorum device is configured in a two-node cluster, or in a pair of nodes directly connected to the quorum device, configure an odd number of quorum devices. This configuration ensures that the quorum devices have completely independent failure pathways.
Connection - You must connect a quorum device to at least two nodes.
For more information about quorum devices, see the Sun Cluster 3.1 10/03 Concepts Guide.
Planning the Global Devices and Cluster File Systems
This section provides the following guidelines for planning global devices and for planning cluster file systems:
For more information about global devices and about cluster files systems, see the Sun Cluster 3.1 10/03 Concepts Guide.
Guidelines for Highly Available Global Devices and Cluster File Systems
Sun Cluster software does not require any specific disk layout or file system size. Consider the following points when you plan your layout for global devices and for cluster file systems.
Mirroring - You must mirror all global devices for the global device to be considered highly available. You do not need to use software mirroring if the storage device provides hardware RAID as well as redundant paths to disks.
Disks - When you mirror, lay out file systems so that the file systems are mirrored across disk arrays.
Availability - You must physically connect a global device to more than one node in the cluster for the global device to be considered highly available. A global device with multiple physical connections can tolerate a single-node failure. A global device with only one physical connection is supported, but the global device becomes inaccessible from other nodes if the node with the connection is down.