Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster System Administration Guide Oracle Solaris Cluster 4.1 |
1. Introduction to Administering Oracle Solaris Cluster
2. Oracle Solaris Cluster and RBAC
3. Shutting Down and Booting a Cluster
4. Data Replication Approaches
5. Administering Global Devices, Disk-Path Monitoring, and Cluster File Systems
7. Administering Cluster Interconnects and Public Networks
Administering the Cluster Interconnects
Dynamic Reconfiguration With Cluster Interconnects
How to Check the Status of the Cluster Interconnect
How to Add Cluster Transport Cables, Transport Adapters, or Transport Switches
How to Remove Cluster Transport Cables, Transport Adapters, and Transport Switches
How to Enable a Cluster Transport Cable
How to Disable a Cluster Transport Cable
How to Determine a Transport Adapter's Instance Number
How to Change the Private Network Address or Address Range of an Existing Cluster
10. Configuring Control of CPU Usage
Oracle Solaris Cluster software supports the Oracle Solaris software implementation of Internet Protocol network Multipathing (IPMP) for public networks. Basic IPMP administration is the same for both cluster and noncluster environments. Multipathing is automatically installed when you install the Oracle Solaris 11 OS, and you must enable it to use it. Multipathing administration is covered in the appropriate Oracle Solaris OS documentation. However, review the guidelines that follow before administering IPMP in an Oracle Solaris Cluster environment.
Before performing IPMP procedures on a cluster, consider the following guidelines.
Each public network adapter must belong to an IPMP group.
The local-mac-address? variable must have a value of true for Ethernet adapters.
You can use probe-based IPMP groups or link-based IPMP groups in a cluster. A probe-based IPMP group tests the target IP address and provides the most protection by recognizing more conditions that might compromise availability.
You must configure a test IP address for each adapter in the following kinds of multipathing groups:
All multiple-adapter multipathing groups require test IP addresses. Single-adapter multipathing groups do not require test IP addresses.
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 they are not highly available.
No restrictions are placed on multipathing group naming. However, when configuring a resource group, the netiflist naming convention is any multipathing name followed by either the nodeID number or the node name. For example, given a multipathing group named sc_ipmp0 , the netiflist naming could be either sc_ipmp0@1 or sc_ipmp0@phys-schost-1, where the adapter is on the node phys-schost-1, which has the nodeID of 1.
Do not unconfigure (unplumb) or bring down an adapter of an IP Network Multipathing group without first switching over the IP addresses from the adapter to be removed to an alternate adapter in the group, using the if_mpadm command. For more information, see the if_mpadm(1M) man page.
Avoid rewiring adapters to different subnets without first removing them from their respective multipathing groups.
Logical adapter operations can be done on an adapter even if monitoring is on for the multipathing group.
You must maintain at least one public network connection for each node in the cluster. The cluster is inaccessible without a public network connection.
To view the status of IP Network Multipathing groups on a cluster, use the command.clinterconnect status command
For more information about IP Network Multipathing, see the appropriate documentation in the Oracle Solaris OS system administration documentation set.
Table 7-3 Task Map: Administering the Public Network
|
For cluster software installation procedures, see the Oracle Solaris Cluster Software Installation Guide. For procedures about servicing public networking hardware components, see the Oracle Solaris Cluster 4.1 Hardware Administration Manual.
You must consider a few issues when completing dynamic reconfiguration (DR) operations on public network interfaces in a cluster.
All of the requirements, procedures, and restrictions that are documented for the Oracle Solaris DR feature also apply to Oracle Solaris Cluster DR support (except for the operating system quiescence operation). Therefore, review the documentation for the Oracle Solaris DR feature before using the DR feature with Oracle Solaris Cluster software. You should review in particular the issues that affect non-network IO devices during a DR detach operation.
DR remove-board operations can succeed only when public network interfaces are not active. Before removing an active public network interface, switch the IP addresses from the adapter to be removed to another adapter in the multipathing group, using the if_mpadm command. For more information, see the if_mpadm(1M) man page.
If you try to remove a public network interface card without having properly disabled it as an active network interface, Oracle Solaris Cluster rejects the operation and identifies the interface that would be affected by the operation.
Caution - For multipathing groups with two adapters, if the remaining network adapter fails while you are performing the DR remove operation on the disabled network adapter, availability is impacted. The remaining adapter has no place to fail over for the duration of the DR operation. |
Complete the following procedures in the order indicated when performing DR operations on public network interfaces.
Table 7-4 Task Map: Dynamic Reconfiguration With Public Network Interfaces
|