Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster Concepts Guide Oracle Solaris Cluster |
2. Key Concepts for Hardware Service Providers
3. Key Concepts for System Administrators and Application Developers
Cluster Configuration Repository (CCR)
Device IDs and DID Pseudo Driver
Local and Global Namespaces Example
Using the cldevice Command to Monitor and Administer Disk Paths
Using Oracle Solaris Cluster Manager to Monitor Disk Paths
Using the clnode set Command to Manage Disk Path Failure
Adhering to Quorum Device Requirements
Adhering to Quorum Device Best Practices
Recommended Quorum Configurations
Quorum in Two-Host Configurations
Quorum in Greater Than Two-Host Configurations
Atypical Quorum Configurations
Characteristics of Scalable Services
Data Service API and Data Service Development Library API
Using the Cluster Interconnect for Data Service Traffic
Resources, Resource Groups, and Resource Types
Resource and Resource Group States and Settings
Resource and Resource Group Properties
Support for Oracle Solaris Zones
Support for Global-Cluster Non-Voting Nodes (Solaris Zones) Directly Through the RGM
Criteria for Using Support for Solaris Zones Directly Through the RGM
Requirements for Using Support for Solaris Zones Directly Through the RGM
Additional Information About Support for Solaris Zones Directly Through the RGM
Criteria for Using Oracle Solaris Cluster HA for Solaris Zones
Requirements for Using Oracle Solaris Cluster HA for Solaris Zones
Additional Information About Oracle Solaris Cluster HA for Solaris Zones
Data Service Project Configuration
Determining Requirements for Project Configuration
Setting Per-Process Virtual Memory Limits
Two-Host Cluster With Two Applications
Two-Host Cluster With Three Applications
Failover of Resource Group Only
Public Network Adapters and IP Network Multipathing
SPARC: Dynamic Reconfiguration Support
SPARC: Dynamic Reconfiguration General Description
SPARC: DR Clustering Considerations for CPU Devices
SPARC: DR Clustering Considerations for Memory
SPARC: DR Clustering Considerations for Disk and Tape Drives
SPARC: DR Clustering Considerations for Quorum Devices
SPARC: DR Clustering Considerations for Cluster Interconnect Interfaces
SPARC: DR Clustering Considerations for Public Network Interfaces
Oracle Solaris Cluster 3.3 support for the dynamic reconfiguration (DR) software feature is being developed in incremental phases. This section describes concepts and considerations for Oracle Solaris Cluster 3.3 support of the DR feature.
All 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 environment quiescence operation). Therefore, review the documentation for the Oracle Solaris DR feature before by 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.
The Sun Enterprise 10000 Dynamic Reconfiguration User Guide and the Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual (from the Solaris 10 on Sun Hardware collection) are both available for download from http://www.oracle.com/technetwork/indexes/documentation/index.html.
The DR feature enables operations, such as the removal of system hardware, in running systems. The DR processes are designed to ensure continuous system operation with no need to halt the system or interrupt cluster availability.
DR operates at the board level. Therefore, a DR operation affects all the components on a board. Each board can contain multiple components, including CPUs, memory, and peripheral interfaces for disk drives, tape drives, and network connections.
Removing a board that contains active components would result in system errors. Before removing a board, the DR subsystem queries other subsystems, such as Oracle Solaris Cluster, to determine whether the components on the board are being used. If the DR subsystem finds that a board is in use, the DR remove-board operation is not done. Therefore, it is always safe to issue a DR remove-board operation because the DR subsystem rejects operations on boards that contain active components.
The DR add-board operation is also always safe. CPUs and memory on a newly added board are automatically brought into service by the system. However, the system administrator must manually configure the cluster to actively use components that are on the newly added board.
Note - The DR subsystem has several levels. If a lower level reports an error, the upper level also reports an error. However, when the lower level reports the specific error, the upper level reports Unknown error. You can safely ignore this error.
The following sections describe DR considerations for the different device types.
Oracle Solaris Cluster software does not reject a DR remove-board operation because of the presence of CPU devices.
When a DR add-board operation succeeds, CPU devices on the added board are automatically incorporated in system operation.
For the purposes of DR, consider two types of memory:
Kernel memory cage
Non-kernel memory cage
These two types differ only in usage. The actual hardware is the same for both types. Kernel memory cage is the memory that is used by the Oracle Solaris Operating System. Oracle Solaris Cluster software does not support remove-board operations on a board that contains the kernel memory cage and rejects any such operation. When a DR remove-board operation pertains to memory other than the kernel memory cage, Oracle Solaris Cluster software does not reject the operation. When a DR add-board operation that pertains to memory succeeds, memory on the added board is automatically incorporated in system operation.
Oracle Solaris Cluster rejects dynamic reconfiguration (DR) remove-board operations on active drives on the primary host. You can perform DR remove-board operations on inactive drives on the primary host and on any drives in the secondary host. After the DR operation, cluster data access continues as before.
Note - Oracle Solaris Cluster rejects DR operations that impact the availability of quorum devices. For considerations about quorum devices and the procedure for performing DR operations on them, see SPARC: DR Clustering Considerations for Quorum Devices.
See Dynamic Reconfiguration With Quorum Devices in Oracle Solaris Cluster System Administration Guide for detailed instructions about how to perform these actions.
If the DR remove-board operation pertains to a board that contains an interface to a device configured for quorum, Oracle Solaris Cluster software rejects the operation. Oracle Solaris Cluster software also identifies the quorum device that would be affected by the operation. You must disable the device as a quorum device before you can perform a DR remove-board operation.
See Chapter 6, Administering Quorum, in Oracle Solaris Cluster System Administration Guide for detailed instructions about how administer quorum.
If the DR remove-board operation pertains to a board containing an active cluster interconnect interface, Oracle Solaris Cluster software rejects the operation. Oracle Solaris Cluster software also identifies the interface that would be affected by the operation. You must use an Oracle Solaris Cluster administrative tool to disable and remove the active interface before the DR operation can succeed.
Caution - Oracle Solaris Cluster software requires each cluster node to have at least one functioning path to every other cluster node. Do not disable a private interconnect interface that supports the last path to any Oracle Solaris host in the cluster. |
See Administering the Cluster Interconnects in Oracle Solaris Cluster System Administration Guide for detailed instructions about how to perform these actions.
If the DR remove-board operation pertains to a board that contains an active public network interface, Oracle Solaris Cluster software rejects the operation. Oracle Solaris Cluster software also identifies the interface that would be affected by the operation. Before you remove a board with an active network interface present, switch over all traffic on that interface to another functional interface in the multipathing group by using the if_mpadm command.
Caution - 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. |
See Administering the Public Network in Oracle Solaris Cluster System Administration Guide for detailed instructions about how to perform a DR remove operation on a public network interface.