Sun Cluster 3.1 10/03 Concepts Guide

Data Service Project Configuration

Data services may be configured to launch under a Solaris project name when brought online using the RGM. The configuration associates a resource or resource group managed by the RGM with a Solaris project ID. The mapping from your resource or resource group to a project ID gives you the ability to use sophisticated controls that are available in the Solaris environment to manage workloads and consumption within your cluster.

Note - You can perform this configuration only if you are running the current release of Sun Cluster software with Solaris 9.

Using the Solaris management functionality in a cluster environment enables you to ensure that your most important applications are given priority when sharing a node with other applications. Applications might share a node if you have consolidated services or because applications have failed over. Use of the management functionality described herein might improve availability of a critical application by preventing other low priority applications from over-consuming system supplies such as CPU time.

Note - The Solaris documentation of this feature describes CPU time, processes, tasks and similar components as 'resources'. Meanwhile, Sun Cluster documentation uses the term 'resources' to describe entities that are under the control of the RGM. The following section will use the term 'resource' to refer to Sun Cluster entities under the control of the RGM and use the term 'supplies' to refer to CPU time, processes, and tasks.

This section provides a conceptual description of configuring data services to launch processes in a specified Solaris 9 project(4). This section also describes several failover scenarios and suggestions for planning to use the management functionality provided by the Solaris environment. For detailed conceptual and procedural documentation of the management feature, refer to System Administration Guide: Resource Management and Network Services in the Solaris 9 System Administrator Collection.

When configuring resources and resource groups to use Solaris management functionality in a cluster, consider using the following high-level process:

Configure applications as part of the resource.
Configure resources as part of a resource group.
Enable resources in the resource group.
Make the resource group managed.
Create a Solaris project for your resource group.
Configure standard properties to associate the resource group name with the project you created in step 5.
Bring the resource group online.

To configure the standard Resource_project_name or RG_project_name properties to associate the Solaris project ID with the resource or resource group, use the -y option with the scrgadm(1M) command. Set the property values to the resource or resource group. See "Standard Properties" in Sun Cluster 3.1 Data Services Installation and Configuration Guide for property definitions. Refer to r_properties(5) and rg_properties(5) for property descriptions.

The specified project name must exist in the projects database (/etc/project) and the root user must be configured as a member of the named project. Refer to "Projects and Tasks" in System Administration Guide: Resource Management and Network Services in the Solaris 9 System Administrator Collection for conceptual information about the project name database. Refer to project(4) for a description of project file syntax.

When the RGM brings resources or resource groups online, it launches the related processes under the project name.

Note - Users can associate the resource or resource group with a project at any time. However, the new project name is not effective until the resource or resource group is taken offline and brought back online using the RGM.

Launching resources and resource groups under the project name enables you to configure the following features to manage system supplies across your cluster.

Extended Accounting - Provides a flexible way to record consumption on a task or process basis. Extended accounting enables you to examine historical usage and make assessments of capacity requirements for future workloads.
Controls - Provide a mechanism for constraint on system supplies. Processes, tasks, and projects can be prevented from consuming large amounts of specified system supplies.
Fair Share Scheduling (FSS) - Provides the ability to control the allocation of available CPU time among workloads, based on their importance. Workload importance is expressed by the number of shares of CPU time that you assign to each workload. Refer to dispadmin(1M) for a command line description of setting FSS as your default scheduler. See also priocntl(1), ps(1), and FSS(7) for more information.
Pools - Provide the ability to use partitions for interactive applications according to the application's requirements. Pools can be used to partition a server that supports a number of different software applications. The use of pools results in a more predictable response for each application.

Determining Requirements for Project Configuration

Before you configure data services to use the controls provided by Solaris in a Sun Cluster environment, you must decide how you want to control and track resources across switchovers or failovers. Consider identifying dependencies within your cluster before configuring a new project. For example, resources and resource groups depend on disk device groups. Use the nodelist, failback, maximum_primaries and desired_primaries resource group properties, configured with scrgadm(1M) to identify nodelist priorities for your resource group. Refer to "Relationship Between Resource Groups and Disk Device Groups" in Sun Cluster 3.1 Data Services Installation and Configuration Guide for a brief discussion of the node list dependencies between resource groups and disk device groups. For detailed property descriptions, refer to rg_properties(5).

Use the preferenced and failback properties configured with scrgadm(1M) and scsetup(1M) to determine disk device group nodelist priorities. For procedural information, see "How To Change Disk Device Properties" in " Administering Disk Device Groups" in Sun Cluster 3.1 System Administration Guide. Refer to The SunPlex System Hardware Components for conceptual information about node configuration and the behavior of failover and scalable data services.

If you configure all cluster nodes identically, usage limits are enforced identically on primary and secondary nodes. The configuration parameters of projects need not be identical for all applications in the configuration files on all nodes. All projects associated with the application must at least be accessible by the project database on all potential masters of that application. Suppose that Application 1 is mastered by phys-schost-1 but could potentially be switched over or failed over to phys-schost-2 or phys-schost-3. The project associated with Application 1 must be accessible on all three nodes (phys-schost-1, phys-schost-2, and phys-schost-3).

Note - Project database information can be a local /etc/project database file or may be stored in the NIS map or the LDAP directory service.

The Solaris environment allows for flexible configuration of usage parameters, and few restrictions are imposed by Sun Cluster. Configuration choices depend on the needs of the site. Consider the general guidelines in the following sections before configuring your systems.

Setting Per-Process Virtual Memory Limits

Set the process.max-address-space control to limit virtual memory on a per-process basis. Refer to rctladm(1M) for detailed information about setting the process.max-address-space value.

When using management controls with Sun Cluster, configure memory limits appropriately to prevent unnecessary failover of applications and a "ping-pong" effect of applications. In general:

Do not set memory limits too low.

When an application reaches its memory limit, it might fail over. This guideline is especially important for database applications, when reaching a virtual memory limit can have unexpected consequences.
Do not set memory limits identically on primary and secondary nodes.

Identical limits can cause a ping-pong effect when an application reaches its memory limit and fails over to a secondary node with an identical memory limit. Set the memory limit slightly higher on the secondary node. The difference in memory limits helps prevent the ping-pong scenario and gives the system administrator a period of time in which to adjust the parameters as necessary.
Do use the resource management memory limits for load-balancing.

For example, you can use memory limits to prevent an errant application from consuming excessive swap space.

Failover Scenarios

You can configure management parameters so that the allocation in the project configuration (/etc/project) works in normal cluster operation and in switchover or failover situations.

The following sections are example scenarios.

The first two sections, "Two-Node Cluster With Two Applications" and "Two-Node Cluster With Three Applications," show failover scenarios for entire nodes.
The section "Failover of Resource Group Only" illustrates failover operation for an application only.

In a cluster environment, an application is configured as part of a resource and a resource is configured as part of a resource group (RG). When a failure occurs, the resource group along with its associated applications, fails over to another node. In the following examples the resources are not shown explicitly. Assume that each resource has only one application.

Note - Failover occurs in the preferenced nodelist order that is set in the RGM.

The following examples have these constraints:

Application 1 (App-1) is configured in resource group RG-1.
Application 2 (App-2) is configured in resource group RG-2.
Application 3 (App-3) is configured in resource group RG-3.

Although the numbers of assigned shares remain the same, the percentage of CPU time allocated to each application changes after failover. This percentage depends on the number of applications that are running on the node and the number of shares that are assigned to each active application.


3. Key Concepts - Administration and Application Development Cluster Administration and Application Development Resources, Resource Groups, and Resource Types


	Data Service Project Configuration Data services may be configured to launch under a Solaris project name when brought online using the RGM. The configuration associates a resource or resource group managed by the RGM with a Solaris project ID. The mapping from your resource or resource group to a project ID gives you the ability to use sophisticated controls that are available in the Solaris environment to manage workloads and consumption within your cluster. Note - You can perform this configuration only if you are running the current release of Sun Cluster software with Solaris 9. Using the Solaris management functionality in a cluster environment enables you to ensure that your most important applications are given priority when sharing a node with other applications. Applications might share a node if you have consolidated services or because applications have failed over. Use of the management functionality described herein might improve availability of a critical application by preventing other low priority applications from over-consuming system supplies such as CPU time. Note - The Solaris documentation of this feature describes CPU time, processes, tasks and similar components as 'resources'. Meanwhile, Sun Cluster documentation uses the term 'resources' to describe entities that are under the control of the RGM. The following section will use the term 'resource' to refer to Sun Cluster entities under the control of the RGM and use the term 'supplies' to refer to CPU time, processes, and tasks. This section provides a conceptual description of configuring data services to launch processes in a specified Solaris 9 `project`(4). This section also describes several failover scenarios and suggestions for planning to use the management functionality provided by the Solaris environment. For detailed conceptual and procedural documentation of the management feature, refer to System Administration Guide: Resource Management and Network Services in the Solaris 9 System Administrator Collection. When configuring resources and resource groups to use Solaris management functionality in a cluster, consider using the following high-level process: Configure applications as part of the resource. Configure resources as part of a resource group. Enable resources in the resource group. Make the resource group managed. Create a Solaris project for your resource group. Configure standard properties to associate the resource group name with the project you created in step 5. Bring the resource group online. To configure the standard `Resource_project_name` or `RG_project_name` properties to associate the Solaris project ID with the resource or resource group, use the `-y` option with the `scrgadm`(1M) command. Set the property values to the resource or resource group. See "Standard Properties" in Sun Cluster 3.1 Data Services Installation and Configuration Guide for property definitions. Refer to `r_properties`(5) and `rg_properties`(5) for property descriptions. The specified project name must exist in the projects database (`/etc/project`) and the root user must be configured as a member of the named project. Refer to "Projects and Tasks" in System Administration Guide: Resource Management and Network Services in the Solaris 9 System Administrator Collection for conceptual information about the project name database. Refer to `project`(4) for a description of project file syntax. When the RGM brings resources or resource groups online, it launches the related processes under the project name. Note - Users can associate the resource or resource group with a project at any time. However, the new project name is not effective until the resource or resource group is taken offline and brought back online using the RGM. Launching resources and resource groups under the project name enables you to configure the following features to manage system supplies across your cluster. Extended Accounting - Provides a flexible way to record consumption on a task or process basis. Extended accounting enables you to examine historical usage and make assessments of capacity requirements for future workloads. Controls - Provide a mechanism for constraint on system supplies. Processes, tasks, and projects can be prevented from consuming large amounts of specified system supplies. Fair Share Scheduling (FSS) - Provides the ability to control the allocation of available CPU time among workloads, based on their importance. Workload importance is expressed by the number of shares of CPU time that you assign to each workload. Refer to `dispadmin`(1M) for a command line description of setting FSS as your default scheduler. See also `priocntl`(1), `ps`(1), and `FSS`(7) for more information. Pools - Provide the ability to use partitions for interactive applications according to the application's requirements. Pools can be used to partition a server that supports a number of different software applications. The use of pools results in a more predictable response for each application. Determining Requirements for Project Configuration Before you configure data services to use the controls provided by Solaris in a Sun Cluster environment, you must decide how you want to control and track resources across switchovers or failovers. Consider identifying dependencies within your cluster before configuring a new project. For example, resources and resource groups depend on disk device groups. Use the `nodelist`, `failback`, `maximum_primaries` and `desired_primaries` resource group properties, configured with `scrgadm`(1M) to identify nodelist priorities for your resource group. Refer to "Relationship Between Resource Groups and Disk Device Groups" in Sun Cluster 3.1 Data Services Installation and Configuration Guide for a brief discussion of the node list dependencies between resource groups and disk device groups. For detailed property descriptions, refer to `rg_properties`(5). Use the `preferenced` and `failback` properties configured with `scrgadm`(1M) and `scsetup`(1M) to determine disk device group nodelist priorities. For procedural information, see "How To Change Disk Device Properties" in " Administering Disk Device Groups" in Sun Cluster 3.1 System Administration Guide. Refer to The SunPlex System Hardware Components for conceptual information about node configuration and the behavior of failover and scalable data services. If you configure all cluster nodes identically, usage limits are enforced identically on primary and secondary nodes. The configuration parameters of projects need not be identical for all applications in the configuration files on all nodes. All projects associated with the application must at least be accessible by the project database on all potential masters of that application. Suppose that Application 1 is mastered by phys-schost-1 but could potentially be switched over or failed over to phys-schost-2 or phys-schost-3. The project associated with Application 1 must be accessible on all three nodes (phys-schost-1, phys-schost-2, and phys-schost-3). Note - Project database information can be a local `/etc/project` database file or may be stored in the NIS map or the LDAP directory service. The Solaris environment allows for flexible configuration of usage parameters, and few restrictions are imposed by Sun Cluster. Configuration choices depend on the needs of the site. Consider the general guidelines in the following sections before configuring your systems. Setting Per-Process Virtual Memory Limits Set the `process.max-address-space` control to limit virtual memory on a per-process basis. Refer to `rctladm`(1M) for detailed information about setting the `process.max-address-space` value. When using management controls with Sun Cluster, configure memory limits appropriately to prevent unnecessary failover of applications and a "ping-pong" effect of applications. In general: Do not set memory limits too low. When an application reaches its memory limit, it might fail over. This guideline is especially important for database applications, when reaching a virtual memory limit can have unexpected consequences. Do not set memory limits identically on primary and secondary nodes. Identical limits can cause a ping-pong effect when an application reaches its memory limit and fails over to a secondary node with an identical memory limit. Set the memory limit slightly higher on the secondary node. The difference in memory limits helps prevent the ping-pong scenario and gives the system administrator a period of time in which to adjust the parameters as necessary. Do use the resource management memory limits for load-balancing. For example, you can use memory limits to prevent an errant application from consuming excessive swap space. Failover Scenarios You can configure management parameters so that the allocation in the project configuration (`/etc/project`) works in normal cluster operation and in switchover or failover situations. The following sections are example scenarios. The first two sections, "Two-Node Cluster With Two Applications" and "Two-Node Cluster With Three Applications," show failover scenarios for entire nodes. The section "Failover of Resource Group Only" illustrates failover operation for an application only. In a cluster environment, an application is configured as part of a resource and a resource is configured as part of a resource group (RG). When a failure occurs, the resource group along with its associated applications, fails over to another node. In the following examples the resources are not shown explicitly. Assume that each resource has only one application. Note - Failover occurs in the preferenced nodelist order that is set in the RGM. The following examples have these constraints: Application 1 (App-1) is configured in resource group RG-1. Application 2 (App-2) is configured in resource group RG-2. Application 3 (App-3) is configured in resource group RG-3. Although the numbers of assigned shares remain the same, the percentage of CPU time allocated to each application changes after failover. This percentage depends on the number of applications that are running on the node and the number of shares that are assigned to each active application.