This section provides guidelines for planning and preparing the following components for Sun Cluster software installation and configuration:
For detailed information about Sun Cluster components, see the Sun Cluster Overview for Solaris OS and the Sun Cluster Concepts Guide for Solaris OS.
Ensure that you have available all necessary license certificates before you begin software installation. Sun Cluster software does not require a license certificate, but each node installed with Sun Cluster software must be covered under your Sun Cluster software license agreement.
For licensing requirements for volume-manager software and applications software, see the installation documentation for those products.
After installing each software product, you must also install any required patches.
For information about current required patches, see “Patches and Required Firmware Levels” in Sun Cluster Release Notes for Solaris OS or consult your Sun service provider.
For general guidelines and procedures for applying patches, see “Patching Sun Cluster Software and Firmware” in Sun Cluster System Administration Guide for Solaris OS.
You must set up a number of IP addresses for various Sun Cluster components, depending on your cluster configuration. Each node in the cluster configuration must have at least one public-network connection to the same set of public subnets.
The following table lists the components that need IP addresses assigned. Add these IP addresses to any naming services that are used. Also add these IP addresses to the local /etc/inet/hosts file on each cluster node after you install Solaris software.
For more information about IP addresses, see System Administration Guide, Volume 3 (Solaris 8) or System Administration Guide: IP Services (Solaris 9).
For more information about test IP addresses to support IP Network Multipathing, see IP Network Multipathing Administration Guide.
Component |
Number of IP Addresses Needed |
---|---|
1 per subnet |
|
|
|
Cluster nodes |
1 per node, per subnet |
1 per domain |
|
1 |
|
Logical addresses |
1 per logical host resource, per subnet |
You must have console access to all cluster nodes. If you install Cluster Control Panel software on your administrative console, you must provide the hostname of the console-access device that is used to communicate with the cluster nodes.
A terminal concentrator is used to communicate between the administrative console and the cluster node consoles.
A Sun Enterprise 10000 server uses a System Service Processor (SSP) instead of a terminal concentrator.
A Sun FireTM server uses a system controller instead of a terminal concentrator.
For more information about console access, see the Sun Cluster Concepts Guide for Solaris OS.
Each data-service resource group that uses a logical address must have a hostname specified for each public network from which the logical address can be accessed.
For more information, see the Sun Cluster Data Service Planning and Administration Guide for Solaris OS.
For additional information about data services and resources, also see the Sun Cluster Overview for Solaris OS and the Sun Cluster Concepts Guide for Solaris OS.
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.
Sun Cluster software supports IPv4 and IPv6 addresses on the public network, both for failover and scalable data services. However, Sun Cluster software does not support IPv6 communications over the private interconnects.
The local-mac-address? variable must use the default value true for Ethernet adapters. Sun Cluster 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.
During Sun Cluster installation, the scinstall utility automatically configures a single-adapter IP Network Multipathing group for each public-network adapter. To modify these backup groups after installation, follow the procedures in “Deploying Network Multipathing” in IP Network Multipathing Administration Guide (Solaris 8) or“Administering Network Multipathing (Task)” in System Administration Guide: IP Services (Solaris 9).
See IP Network Multipathing Groups for guidelines on planning public-network-adapter backup groups. For more information about public-network interfaces, see Sun Cluster Concepts Guide for Solaris OS.
Consider the following points when you plan the use of Network File System (NFS) in a Sun Cluster configuration.
No Sun Cluster node can be an NFS client of a Sun Cluster HA for NFS-exported file system being mastered on a node in the same cluster. Such cross-mounting of Sun Cluster HA for NFS is prohibited. Use the cluster file system to share files among cluster nodes.
Applications that run locally on the cluster must not lock files on a file system exported through NFS. Otherwise, local blocking (for example, flock(3UCB) or fcntl(2)) might interfere with the ability to restart the lock manager (lockd). During restart, a blocked local process might be granted a lock which might be intended to be reclaimed by a remote client. This would cause unpredictable behavior.
Sun Cluster software does not support Secure NFS or the use of Kerberos with NFS. In particular, Sun Cluster software does not support the secure and kerberos options to the share_nfs(1M) subsystem.
However, Sun Cluster software does support the use of secure ports for NFS. You enable secure ports for NFS by adding the entry set nfssrv:nfs_portmon=1 to the /etc/system file on cluster nodes.
Observe the following service restrictions for Sun Cluster configurations:
Do not configure cluster nodes as routers (gateways). If the system goes down, the clients cannot find an alternate router and cannot recover.
Do not configure cluster nodes as NIS or NIS+ servers. There is no data service available for NIS or NIS+. However, cluster nodes can be NIS or NIS+ clients.
Do not use a Sun Cluster configuration to provide a highly available boot or installation service on client systems.
Do not use a Sun Cluster configuration to provide an rarpd service.
If you install an RPC service on the cluster, the service must not use any of the following program numbers:
100141
100142
100248
These numbers are reserved for the Sun Cluster daemons rgmd_receptionist, fed, and pmfd, respectively.
If the RPC service that you install also uses one of these program numbers, you must change that RPC service to use a different program number.
Sun Cluster software does not support the running of high-priority process scheduling classes on cluster nodes. Do not run either of the following types of processes on cluster nodes:
Processes that run in the time-sharing scheduling class with a high priority
Processes that run in the real-time scheduling class
Sun Cluster software relies on kernel threads that do not run in the real-time scheduling class. Other time-sharing processes that run at higher-than-normal priority or real-time processes can prevent the Sun Cluster kernel threads from acquiring needed CPU cycles.
This section provides guidelines for the following Sun Cluster components that you configure:
Add this information to the appropriate configuration worksheet.
Table 1–4 Worksheets for Sun Cluster Configuration
Specify a name for the cluster during Sun Cluster configuration. The cluster name should be unique throughout the enterprise.
The node name is the name that you assign to a machine when you install the Solaris OS. During Sun Cluster configuration, you specify the names of all nodes that you are installing as a cluster. In single-node cluster installations, the default node name is the same as the cluster name.
You do not need to configure a private network for a single-node cluster.
Sun Cluster software uses the private network for internal communication between nodes. A Sun Cluster configuration requires at least two connections to the cluster interconnect on the private network. You specify the private-network address and netmask when you configure Sun Cluster software on the first node of the cluster. You can either accept the default private-network address (172.16.0.0) and netmask (255.255.0.0) or type different choices if the default network address is already in use elsewhere in the same enterprise.
After the installation utility (scinstall, SunPlex Installer, or JumpStart) has finished processing and the cluster is established, you cannot change the private-network address and netmask. You must uninstall and reinstall the cluster software to use a different private-network address or netmask.
If you specify a private-network address other than the default, the address must meet the following requirements:
The address must use zeroes for the last two octets of the address, as in the default address 172.16.0.0. Sun Cluster software requires the last 16 bits of the address space for its own use.
The address must be included in the block of addresses that RFC 1918 reserves for use in private networks. You can contact the InterNIC to obtain copies of RFCs or view RFCs online at http://www.rfcs.org.
You can use the same private network address in more than one cluster. Private IP network addresses are not accessible from outside the cluster.
Sun Cluster software does not support IPv6 addresses for the private interconnect.
Although the scinstall utility lets you specify an alternate netmask, best practice is to accept the default netmask, 255.255.0.0. There is no benefit if you specify a netmask that represents a larger network. And the scinstall utility does not accept a netmask that represents a smaller network.
See “Planning Your TCP/IP Network” in System Administration Guide, Volume 3 (Solaris 8) or “Planning Your TCP/IP Network (Task)” in System Administration Guide: IP Services (Solaris 9) for more information about private networks.
The private hostname is the name that is used for internode communication over the private-network interface. Private hostnames are automatically created during Sun Cluster configuration. These private hostnames follow the naming convention clusternodenodeid-priv, where nodeid is the numeral of the internal node ID. During Sun Cluster configuration, the node ID number is automatically assigned to each node when the node becomes a cluster member. After the cluster is configured, you can rename private hostnames by using the scsetup(1M) utility.
You do not need to configure a cluster interconnect for a single-node cluster. However, if you anticipate eventually adding nodes to a single-node cluster configuration, you might want to configure the cluster interconnect for future use.
The cluster interconnects provide the hardware pathways for private-network communication between cluster nodes. Each interconnect consists of a cable that is connected in one of the following ways:
Between two transport adapters
Between a transport adapter and a transport junction
Between two transport junctions
During Sun Cluster configuration, you specify the following information for two cluster interconnects:
Transport adapters – For the transport adapters, such as ports on network interfaces, specify the transport adapter names and transport type. If your configuration is a two-node cluster, you also specify whether your interconnect is direct connected (adapter to adapter) or uses a transport junction. If your two-node cluster is direct connected, you can still specify a transport junction for the interconnect.
If you specify a transport junction, you can more easily add another node to the cluster in the future.
Consider the following guidelines and restrictions:
SBus SCI adapters – The SBus Scalable Coherent Interface (SCI) is not supported as a cluster interconnect. However, the SCI–PCI interface is supported.
Logical network interfaces – Logical network interfaces are reserved for use by Sun Cluster software.
See the scconf_trans_adap_*(1M) family of man pages for information about a specific transport adapter.
Transport junctions – If you use transport junctions, such as a network switch, specify a transport junction name for each interconnect. You can use the default name switchN, where N is a number that is automatically assigned during configuration, or create another name. The exception is the Sun Firelink adapter, which requires the junction name sw-rsmN. The scinstall utility automatically uses this junction name after you specify a Sun Firelink adapter (wrsmN).
Also specify the junction port name or accept the default name. The default port name is the same as the internal node ID number of the node that hosts the adapter end of the cable. However, you cannot use the default port name for certain adapter types, such as SCI-PCI.
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 the cluster is established by using the scsetup(1M) utility.
For more information about the cluster interconnect, see “Cluster Interconnect” in Sun Cluster Overview for Solaris OS and Sun Cluster Concepts Guide for Solaris OS.
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, the value of TRACK_INTERFACES_ONLY_WITH_GROUPS must be yes.
The name of a multipathing group has no requirements or restrictions.
Most procedures, guidelines, and restrictions that are identified in the Solaris documentation for IP Network Multipathing are the same for both cluster and noncluster environments. Therefore, see the appropriate Solaris document for additional information about IP Network Multipathing:
For the Solaris 8 OS, see “Deploying Network Multipathing” in IP Network Multipathing Administration Guide.
For the Solaris 9 OS, see “Administering Network Multipathing (Task)” in System Administration Guide: IP Services.
Also see “IP Network Multipathing Groups” in Sun Cluster Overview for Solaris OS and Sun Cluster Concepts Guide for Solaris OS.
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 configure quorum devices by using the scsetup(1M) utility.
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 “Quorum and Quorum Devices” in Sun Cluster Concepts Guide for Solaris OS and “Quorum Devices” in Sun Cluster Overview for Solaris OS.