Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster Concepts Guide Oracle Solaris Cluster 4.1 |
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
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 Zones on Cluster Nodes Through Oracle Solaris Cluster HA for 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
System resources include aspects of CPU usage, memory usage, swap usage, and disk and network throughput. Oracle Solaris Cluster enables you to monitor how much of a specific system resource is being used by an object type. An object type includes a host, node, zone, disk, network interface, or resource group. Oracle Solaris Cluster also enables you to control the CPU that is available to a resource group.
Monitoring and controlling system resource usage can be part of your resource management policy. The cost and complexity of managing numerous machines encourages the consolidation of several applications on larger hosts. Instead of running each workload on separate systems, with full access to each system's resources, you use resource management to segregate workloads within the system.
Resource management ensures that your applications have the required response times. Resource management can also increase resource use. By categorizing and prioritizing usage, you can effectively use reserve capacity during off-peak periods, often eliminating the need for additional processing power. You can also ensure that resources are not wasted because of load variability.
To use the data that Oracle Solaris Cluster collects about system resource usage, you must do the following:
Analyze the data to determine what it means for your system.
Make a decision about the action that is required to optimize your usage of hardware and software resources.
Take action to implement your decision.
By default, system resource monitoring and control are not configured when you install Oracle Solaris Cluster. For information about configuring these services, see Chapter 10, Configuring Control of CPU Usage, in Oracle Solaris Cluster System Administration Guide.
By monitoring system resource usage, you can do the following:
Collect data that reflects how a service that is using specific system resources is performing.
Discover resource bottlenecks or overload and so preempt problems.
More efficiently manage workloads.
Data about system resource usage can help you determine the hardware resources that are underused and the applications that use many resources. Based on this data, you can assign applications to nodes that have the necessary resources and choose the node to which to failover. This consolidation can help you optimize the way that you use your hardware and software resources.
Monitoring all system resources at the same time might be costly in terms of CPU. Choose the system resources that you want to monitor by prioritizing the resources that are most critical for your system.
When you enable monitoring, you choose the telemetry attribute that you want to monitor. A telemetry attribute is an aspect of system resources. Examples of telemetry attributes include the amount of free CPU or the percentage of blocks that are used on a device. If you monitor a telemetry attribute on an object type, Oracle Solaris Cluster monitors this telemetry attribute on all objects of that type in the cluster. Oracle Solaris Cluster stores a history of the system resource data that is collected for seven days.
If you consider a particular data value to be critical for a system resource, you can set a threshold for this value. When setting a threshold, you also choose how critical this threshold is by assigning it a severity level. If the threshold is crossed, Oracle Solaris Cluster changes the severity level of the threshold to the severity level that you choose.
Each application and service that is running on a cluster has specific CPU needs. For example, the global-cluster node assigns CPU shares.
If you want to apply CPU shares, you must specify the Fair Share Scheduler (FFS) as the default scheduler in the cluster. A CPU share is the portion of the system's CPU resources that is allocated to a project. Shares define the relative importance of workloads in relation to other workloads. When you assign CPU shares to a project, your primary concern is not the number of shares the project has. Rather, you should know how many of those other projects will be competing with it for CPU resources.
The system resources that you choose to monitor determine the tables and graphs that you can view.
By viewing the output of system resource usage and CPU control, you can do the following:
Anticipate failures due to the exhaustion of system resources.
Detect unbalanced usage of system resources.
Validate server consolidation.
Obtain information that enables you to improve the performance of applications.
For more information, see the clresource(1CL), cltelemetryattribute(1CL), and rg_properties(5) man pages.