Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Solaris Cluster Concepts Guide Oracle Solaris Cluster 4.0 |
2. Key Concepts for Hardware Service Providers
3. Key Concepts for System Administrators and Application Developers
Device IDs and DID Pseudo Driver
Cluster Configuration Repository (CCR)
Local and Global Namespaces Example
Using the cldevice Command to Monitor and Administer 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-Node Configurations
Quorum in Greater Than Two-Node Configurations
Characteristics of Scalable Services
Data Service API and Data Service Development Library API
Using the Cluster Interconnect for Data Service Traffic
Support for Oracle Solaris Zones
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-Node Cluster With Two Applications
Two-Node 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
Data services use several types of resources: applications such as Oracle iPlanet Web Server or Apache Web Server use network addresses (logical host names and shared addresses) on which the applications depend. Application and network resources form a basic unit that is managed by the Resource Group Manager (RGM).
For example, Oracle Solaris Cluster HA for Oracle is the resource type SUNW.oracle-server and Oracle Solaris Cluster HA for Apache is the resource type SUNW.apache.
A resource is an instance of a resource type that is defined cluster wide. Several resource types are defined.
Network resources are either SUNW.LogicalHostname or SUNW.SharedAddress resource types. These two resource types are preregistered by the Oracle Solaris Cluster software.
The HAStoragePlus resource type is used to synchronize the startup of resources and device groups on which the resources depend. This resource type ensures that before a data service starts, the paths to a cluster file system's mount points, global devices, and device group names are available. For more information, see Synchronizing the Startups Between Resource Groups and Device Groups in Oracle Solaris Cluster Data Services Planning and Administration Guide. The HAStoragePlus resource type also enables local file systems to be highly available. For more information about this feature, see HAStoragePlus Resource Type.
RGM-managed resources are placed into groups, called resource groups, so that they can be managed as a unit. A resource group is migrated as a unit if a failover or switchover is initiated on the resource group.
Note - When you bring a resource group that contains application resources online, the application is started. The data service start method waits until the application is running before exiting successfully. The determination of when the application is up and running is accomplished the same way the data service fault monitor determines that a data service is serving clients. Refer to the Oracle Solaris Cluster Data Services Planning and Administration Guide for more information about this process.
The RGM controls data services (applications) as resources, which are managed by resource type implementations. These implementations are either supplied by Oracle or created by a developer with a generic data service template, the Data Service Development Library API (DSDL API), or the Resource Management API (RMAPI). The cluster administrator creates and manages resources in containers called resource groups. The RGM stops and starts resource groups on selected nodes in response to cluster membership changes.
The RGM acts on resources and resource groups. RGM actions cause resources and resource groups to move between online and offline states. A complete description of the states and settings that can be applied to resources and resource groups is located in Resource and Resource Group States and Settings.
Refer to Data Service Project Configuration for information about how to launch Oracle Solaris projects under RGM control.
A system administrator applies static settings to resources and resource groups. You can change these settings only by administrative action. The RGM moves resource groups between dynamic “states.”
These settings and states are as follows:
Managed or unmanaged settings. These cluster-wide settings apply only to resource groups. The RGM manages resource groups. You can use the clresourcegroup command to request that the RGM manage or unmanage a resource group. These resource group settings do not change when you reconfigure a cluster.
When a resource group is first created, it is unmanaged. A resource group must be managed before any resources placed in the group can become active.
In some data services, for example, a scalable web server, work must be done prior to starting network resources and after they are stopped. This work is done by initialization (INIT) and finish (FINI) data service methods. The INIT methods only run if the resource group in which the resources are located is in the managed state.
When a resource group is moved from unmanaged to managed, any registered INIT methods for the group are run on the resources in the group.
When a resource group is moved from managed to unmanaged, any registered FINI methods are called to perform cleanup.
The most common use of the INIT and FINI methods are for network resources for scalable services. However, a data service developer can use these methods for any initialization or cleanup work that is not performed by the application.
Enabled or disabled settings. These settings apply to resources on one or more nodes. A system administrator can use the clresource command to enable or disable a resource on one or more nodes. These settings do not change when the cluster administrator reconfigures a cluster.
The normal setting for a resource is that it is enabled and actively running in the system.
If you want to make the resource unavailable on all cluster nodes, disable the resource on all cluster nodes. A disabled resource is not available for general use on the cluster nodes that you specify.
Online or offline states. These dynamic states apply to both resources and resource groups.
Online and offline states change as the cluster transitions through cluster reconfiguration steps during switchover or failover. You can also change the online or offline state of a resource or a resource group by using the clresource and clresourcegroup commands.
A failover resource or resource group can only be online on one node at any time. A scalable resource or resource group can be online on some nodes and offline on others. During a switchover or failover, resource groups and the resources within them are taken offline on one node and then brought online on another node.
If a resource group is offline, all of its resources are offline. If a resource group is online, all of its enabled resources are online.
You can temporarily suspend the automatic recovery actions of a resource group. You might need to suspend the automatic recovery of a resource group to investigate and fix a problem in the cluster. Or, you might need to perform maintenance on resource group services.
A suspended resource group is not automatically restarted or failed over until you explicitly issue the command that resumes automatic recovery. Whether online or offline, suspended data services remain in their current state. You can still manually switch the resource group to a different state on specified nodes. You can also still enable or disable individual resources in the resource group.
Resource groups can contain several resources, with dependencies between resources. These dependencies require that the resources be brought online and offline in a particular order. The methods that are used to bring resources online and offline might take different amounts of time for each resource. Because of resource dependencies and start and stop time differences, resources within a single resource group can have different online and offline states during a cluster reconfiguration.
You can configure property values for resources and resource groups for your Oracle Solaris Cluster data services. Standard properties are common to all data services. Extension properties are specific to each data service. Some standard and extension properties are configured with default settings so that you do not have to modify them. Others need to be set as part of the process of creating and configuring resources. The documentation for each data service specifies which resource properties can be set and how to set them.
The standard properties are used to configure resource and resource group properties that are usually independent of any particular data service. For the set of standard properties, see the following man pages: cluster(1CL), rt_properties(5), rg_properties(5), r_properties(5), and property_attributes(5).
The RGM extension properties provide information such as the location of application binaries and configuration files. You modify extension properties as you configure your data services. The set of extension properties is described in the individual guide for the data service.