In these scenarios, assume the following configurations.
All applications are configured under a common project.
Each resource has only one application.
The applications are the only active processes on the nodes.
The projects databases are configured the same on each node of the cluster.
Two-Node Cluster With Two Applications
You can configure two applications on a two-node cluster to ensure that each physical host (phys-schost-1, phys-schost-2) acts as the default master for one application. Each physical host acts as the secondary node for the other physical host. All projects associated with Application 1 and Application 2 must be represented in the projects database files on both nodes. When the cluster is running normally, each application is running on its default master, where it is allocated all CPU time by the management facility.
After a failover or switchover occurs, both applications run on a single node where they are allocated shares as specified in the configuration file. For example, this entry in the /etc/project file specifies that Application 1 is allocated 4 shares and Application 2 is allocated 1 share.
Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none) Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none) |
The following diagram illustrates the normal and failover operations of this configuration. The number of shares that are assigned does not change. However, the percentage of CPU time available to each application can change, depending on the number of shares assigned to each process demanding CPU time.
Two-Node Cluster With Three Applications
On a two-node cluster with three applications, you can configure one physical host (phys-schost-1) as the default master of one application and the second physical host (phys-schost-2) as the default master for the remaining two applications. Assume the following example projects database file on every node. The projects database file does not change when a failover or switchover occurs.
Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none) Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none) |
When the cluster is running normally, Application 1 is allocated 5 shares on its default master, phys-schost-1. This number is equivalent to 100 percent of CPU time because it is the only application that demands CPU time on that node. Applications 2 and 3 are allocated 3 and 2 shares, respectively, on their default master, phys-schost-2. Application 2 would receive 60 percent of CPU time and Application 3 would receive 40 percent of CPU time during normal operation.
If a failover or switchover occurs and Application 1 is switched over to phys-schost-2, the shares for all three applications remain the same. However, the percentages of CPU resources are reallocated according to the projects database file.
Application 1, with 5 shares, receives 50 percent of CPU.
Application 2, with 3 shares, receives 30 percent of CPU.
Application 3, with 2 shares, receives 20 percent of CPU.
The following diagram illustrates the normal operations and failover operations of this configuration.
Failover of Resource Group Only
In a configuration in which multiple resource groups have the same default master, a resource group (and its associated applications) can fail over or be switched over to a secondary node. Meanwhile, the default master is running in the cluster.
Note - During failover, the application that fails over is allocated resources as specified in the configuration file on the secondary node. In this example, the projects database files on the primary and secondary nodes have the same configurations.
For example, this sample configuration file specifies that Application 1 is allocated 1 share, Application 2 is allocated 2 shares, and Application 3 is allocated 2 shares.
Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none) Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none) Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none) |
The following diagram illustrates the normal and failover operations of this configuration, where RG-2, containing Application 2, fails over to phys-schost-2. Note that the number of shares assigned does not change. However, the percentage of CPU time available to each application can change, depending on the number of shares assigned to each application demanding CPU time.
Public Network Adapters and IP Network Multipathing
Clients make data requests to the cluster through the public network. Each cluster node is connected to at least one public network through a pair of public network adapters.
Solaris Internet Protocol (IP) Network Multipathing software on Sun Cluster provides the basic mechanism for monitoring public network adapters and failing over IP addresses from one adapter to another when a fault is detected. Each cluster node has its own IP Network Multipathing configuration, which can be different from that on other cluster nodes.
Public network adapters are organized into IP multipathing groups (multipathing groups). Each multipathing group has one or more public network adapters. Each adapter in a multipathing group can be active, or you can configure standby interfaces that are inactive unless there is a failover. The in.mpathd multipathing daemon uses a test IP address to detect failures and repairs. If a fault is detected on one of the adapters by the multipathing daemon, a failover occurs. All network access fails over from the faulted adapter to another functional adapter in the multipathing group, thereby maintaining public network connectivity for the node. If a standby interface was configured, the daemon chooses the standby interface. Otherwise, in.mpathd chooses the interface with the least number of IP addresses. Because the failover happens at the adapter interface level, higher-level connections such as TCP are not affected, except for a brief transient delay during the failover. When the failover of IP addresses completes successfully, gratuitous ARP broadcasts are sent. The connectivity to remote clients is therefore maintained.
Note - Because of the congestion recovery characteristics of TCP, TCP endpoints can suffer further delay after a successful failover as some segments could be lost during the failover, activating the congestion control mechanism in TCP.
Multipathing groups provide the building blocks for logical hostname and shared address resources. You can also create multipathing groups independently of logical hostname and shared address resources to monitor public network connectivity of cluster nodes. The same multipathing group on a node can host any number of logical hostname or shared address resources. For more information on logical hostname and shared address resources, see the Sun Cluster 3.1 Data Services Installation and Configuration Guide.
Note - The design of the IP Network Multipathing mechanism is meant to detect and mask adapter failures. The design is not intended to recover from an administrator using ifconfig(1M) to remove one of the logical (or shared) IP addresses. The Sun Cluster software views the logical and shared IP addresses as resources managed by the RGM. The correct way for an administrator to add or remove an IP address is to use scrgadm(1M) to modify the resource group containing the resource.
For more information about the Solaris implementation of IP Network Multipathing, see the appropriate documentation for the Solaris operating environment installed on your cluster.
Operating Environment Release | For Instructions, Go To... |
|---|---|
Solaris 8 operating environment | IP Network Multipathing Administration Guide |
Solaris 9 operating environment | "IP Network Multipathing Topics" in System Administration Guide: IP Services |
Dynamic Reconfiguration Support
Sun Cluster 3.1 support for the dynamic reconfiguration (DR) software feature is being developed in incremental phases. This section describes concepts and considerations for Sun Cluster 3.1 support of the DR feature.
Note that all of the requirements, procedures, and restrictions that are documented for the Solaris DR feature also apply to Sun Cluster DR support (except for the operating environment quiescence operation). Therefore, review the documentation for the Solaris DR feature before using the DR feature with Sun 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 8 on Sun Hardware or Solaris 9 on Sun Hardware collections) are both available for download from http://docs.sun.com.
Dynamic Reconfiguration General Description
The DR feature allows 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 of 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 containing active components would result in system errors. Before removing a board, the DR subsystem queries other subsystems, such as Sun 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 since the DR subsystem rejects operations on boards containing active components.
The DR add-board operation is always safe also. 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 in order 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 will report "Unknown error." System administrators should ignore the "Unknown error" reported by the upper level.
The following sections describe DR considerations for the different device types.
DR Clustering Considerations for CPU Devices
Sun Cluster software will not reject a DR remove-board operation due to the presence of CPU devices.
When a DR add-board operation succeeds, CPU devices on the added board are automatically incorporated in system operation.
DR Clustering Considerations for Memory
For the purposes of DR, there are two types of memory to consider. These two types differ only in usage. The actual hardware is the same for both types.
The memory used by the operating system is called the kernel memory cage. Sun Cluster software does not support remove-board operations on a board that contains the kernel memory cage and will reject any such operation. When a DR remove-board operation pertains to memory other than the kernel memory cage, Sun Cluster will 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.