3 Policy-Based Cluster and Capacity Management

This chapter provides an overview of Oracle Clusterware policy-based management of servers and resources used by Oracle databases or applications.

This chapter includes the following topics:

Overview of Server Pools and Policy-Based Management

Oracle Clusterware 11g release 2 (11.2) introduced server pools, where resources that Oracle Clusterware manages are contained in logical groups of servers called server pools. Resources are hosted on a shared infrastructure and are contained within server pools. Examples of resources that Oracle Clusterware manages are database instances, database services, application VIPs, and application components.

In an Oracle Flex Cluster, with Hub Nodes and Leaf Nodes, you can use server pools to run particular types of workloads on cluster member nodes, while providing simplified administration options. You can use a cluster configuration policy set to provide dynamic management of cluster policies across the cluster.

See Also :

Chapter 4, "Oracle Flex Clusters" for details about Oracle Flex Cluster configuration

You can continue to manage resources in an Oracle Clusterware standard Cluster by using the Oracle Clusterware 11g release 2 (11.2) server pool model, or you can manually manage resources by using the traditional fixed, non-server pool method.

This section includes the following topics:

Server Pools and Server Categorization

Administrators can deploy and manage servers dynamically using server pools by identifying servers distinguished by particular attributes, a process called server categorization. In this way, you can create clusters made up of heterogeneous nodes.

See Also:

"Overview of Server Categorization" for details about server categorization

Server Pools and Policy-Based Management

With policy-based management, administrators specify the server pool (excluding the Generic and Free pools) in which the servers run. For example, a database administrator uses SRVCTL to create a server pool for servers hosting a database or database service. A clusterware administrator uses CRSCTL to create server pools for non-database use, such as creating a server pool for servers hosting an application.

Policy-based management:

  • Enables online server reallocation based on a defined policy to satisfy workload capacity requirements

  • Guarantees the allocation of required resources for critical work as defined by the policy

  • Ensures isolation where necessary, so that you can provide dedicated servers in a cluster for applications and databases

  • Enables policies to be configured to change pools in accordance with business needs or application demand, so that pools provide the required capacity at the right time

Server pools provide resource isolation to prevent applications running in one server pool from accessing resources running in another server pool. Oracle Clusterware provides fine-grained role separation between server pools. This capability maintains required management role separation between these groups in organizations that have clustered environments managed by separate groups.

See Also:

Appendix B, "Oracle Clusterware Resource Reference" for more information about resource attributes

Oracle Clusterware efficiently allocates servers in the cluster. Server pool attributes, defined when the server pool is created, dictate placement and prioritization of servers based on the IMPORTANCE server pool attribute.

See Also:

"Overview of Cluster Configuration Policies and the Policy Set" for details about managing server pools to respond to business or application demand

How Server Pools Work

Server pools divide the cluster into logical groups of servers hosting both singleton and uniform applications. The application can be a database service or a non-database application. An application is uniform when the application workload is distributed over all servers in the server pool. An application is singleton when it runs on a single server within the server pool. Oracle Clusterware role-separated management determines access to and use of a server pool.

You manage server pools that contain Oracle RAC databases with the Server Control (SRVCTL) utility. Use the Oracle Clusterware Control (CRSCTL) utility to manage all other server pools. Only cluster administrators have permission to create top-level server pools.

Database administrators use the Server Control (SRVCTL) utility to create and manage server pools that will contain Oracle RAC databases. Cluster administrators use the Oracle Clusterware Control (CRSCTL) utility to create and manage all other server pools, such as server pools for non-database applications. Only cluster administrators have permission to create top-level server pools.

Top-level server pools:

  • Logically divide the cluster

  • Are always exclusive, meaning that one server can only reside in one particular server pool at a certain point in time

Default Server Pools

When Oracle Clusterware is installed, two internal server pools are created automatically: Generic and Free. All servers in a new installation are assigned to the Free server pool, initially. Servers move from Free to newly defined server pools automatically.

The Free Server Pool

The Free server pool contains servers that are not assigned to any other server pools. The attributes of the Free server pool are restricted, as follows:

  • SERVER_NAMES, MIN_SIZE, and MAX_SIZE cannot be edited by the user

  • IMPORTANCE and ACL can be edited by the user

The Generic Server Pool

The Generic server pool stores any server that is not in a top-level server pool and is not policy managed. Servers that host non-policy-managed applications, such as administrator-managed databases, are statically assigned to the Generic server pool.

The Generic server pool's attributes are restricted, as follows:

  • No one can modify configuration attributes of the Generic server pool (all attributes are read-only)

  • You can only create administrator-managed databases in the Generic Pool, if the server you want to create the database on is one of the following:

    • Online and exists in the Generic server pool

    • Online and exists in the Free server pool, in which case Oracle Clusterware moves the server into the Generic server pool

    • Online and exists in any other server pool and the user is either a cluster administrator or is allowed to use the server pool's servers, in which case, the server is moved into the Generic server pool

    • Offline and the user is a cluster administrator

Server Pool Attributes

You can use SRVCTL or CRSCTL to create server pools for databases and other applications, respectively. If you use SRVCTL to create a server pool, then you can only use a subset of the server pool attributes described in this section. If you use CRSCTL to create server pools, then you can use the entire set of server pool attributes.

Server pool attributes are the attributes that you define to create and manage server pools.

The decision about which utility to use is based upon the type of resource being hosted in the server pool. You must use SRVCTL to create server pools that host Oracle databases. You must use CRSCTL to create server pools that host non-database resources such as middle tiers and applications.

When you use SRVCTL to create a server pool, the server pool attributes available to you are:


-category
-importance
-min
-max
-serverpool
-servers

SRVCTL prepends "ora." to the name of the server pool.

See Also:

Oracle Real Application Clusters Administration and Deployment Guide for more information

When you use CRSCTL to create a server pool, all attributes listed and described in Table 3-1 are available to you.

See Also:

"crsctl add serverpool" for more information

Table 3-1 Server Pool Attributes

Attribute Values and Format Description 
ACL

String in the following format:

owner:user:rwx,pgrp:group:rwx,other::r—

Defines the owner of the server pool and which privileges are granted to various operating system users and groups. The server pool owner defines the operating system user of the owner, and which privileges that user is granted.

The value of this optional attribute is populated at the time a server pool is created based on the ACL of the user creating the server pool, unless explicitly overridden. The value can subsequently be changed, if such a change is allowed based on the existing privileges of the server pool.

In the string:

  • owner: The operating system user of the server pool owner, followed by the privileges of the owner

  • pgrp: The operating system group that is the primary group of the owner of the server pool, followed by the privileges of members of the primary group

  • other: Followed by privileges of others

  • r: Read only

  • w: Modify attributes of the pool or delete it

  • x: Assign resources to this pool

By default, the identity of the client that creates the server pool is the owner. Also by default, root, and the user specified in owner have full privileges. You can grant required operating system users and operating system groups their privileges by adding the following lines to the ACL attribute:

The operating system user that creates the server pool is the owner of the server pool, and the ACL attribute for the server pool reflects the UNIX-like read, write, and execute ACL definitions for the user, primary group, group, and other.

 
ACTIVE_SERVERS

A string of server names in the following format:

server_name1 server_name2 ...

Oracle Clusterware automatically manages this attribute, which contains the space-delimited list of servers that are currently assigned to a server pool.

 
EXCLUSIVE_POOLS

String

This optional attribute indicates if servers assigned to this server pool are shared with other server pools. A server pool can explicitly state that it is mutually exclusive of any other server pool that has the same value for this attribute. Two or more server pools are mutually exclusive when the sets of servers assigned to them do not have a single server in common. For example, server pools A and B must be mutually exclusive if they both have the value of this attribute set to the same string, such as pools_A_B.

Top-level server pools are mutually exclusive, by default.

 
IMPORTANCE

Any integer from 0 to 1000

Relative importance of the server pool, with 0 denoting the lowest level of importance and 1000, the highest. This optional attribute is used to determine how to reconfigure the server pools when a node joins or leaves the cluster. The default value is 0.

 
MIN_SIZE

Any nonnegative integer

The minimum size of a server pool. If the number of servers contained in a server pool is below the number you specify in this attribute, then Oracle Clusterware automatically moves servers from other pools into this one until that number is met.

Note: The value of this optional attribute does not set a hard limit. It governs the priority for server assignment whenever the cluster is reconfigured. The default value is 0.

 
MAX_SIZE

Any nonnegative integer or -1 (no limit)

The maximum number of servers a server pool can contain. This attribute is optional and is set to -1 (no limit), by default.

Note: A value of -1 for this attribute spans the entire cluster.

 
NAME

String

The name of the server pool, which you must specify when you create the server pool. Server pool names must be unique within the domain of names of user-created entities, such as resources, types, and servers. A server pool name has a 254 character limit and can contain any platform-supported characters except the exclamation point (!), the tilde (~), and spaces. A server pool name cannot begin with a period nor with ora.

Note: When you create server pools using SRVCTL, the utility prepends "ora." to the name of the server pool.

 
PARENT_POOLS

A string of space-delimited server pool names in the following format:

sp1 sp2 ...

Use of this attribute makes it possible to create nested server pools. Server pools listed in this attribute are referred to as parent server pools. A server pool included in a parent server pool is referred to as a child server pool.

Note: If you use SRVCTL to create the server pool, then you cannot specify this attribute.

 
SERVER_CATEGORY

String

The name of a registered server category, used as part of server categorization. Oracle Clusterware standard Clusters and Oracle Flex Clusters have default categories of hub and leaf. When you create a server pool, if you set a value for SERVER_CATEGORY, then you cannot set a value for SERVER_NAMES. Only one of these parameters may have a non-empty value.

Use the SERVER_CATEGORY attribute to classify servers assigned to a server pool based on server attributes. You can organize servers and server pools in a cluster to match specific workload to servers and server pools, based on server attributes that you define.

See Also: "crsctl status server" for a list of server attributes

 
SERVER_NAMES

A string of space-delimited server names in the following format:

server1 server2 ...

A list of candidate node names that may be associated with a server pool. If you do not provide a set of server names for this optional attribute, then Oracle Clusterware is configured so that any server may be assigned to any server pool, to the extent allowed by values of other attributes, such as PARENT_POOLS.

The server names identified as candidate node names are not validated to confirm that they are currently active cluster members. Use this attribute to define servers as candidates that have not yet been added to the cluster.

If you set a value for SERVER_NAMES, then you cannot set a value for SERVER_CATEGORY; Only one of these attributes may have a non-empty value.

Note: If you set the SERVER_CATEGORY attribute and you need to specify individual servers, then you can list servers by name using the EXPRESSION server category attribute.

How Oracle Clusterware Assigns New Servers Using Server Pools

Oracle Clusterware assigns new servers to server pools in the following order:

  1. Generic server pool

  2. User-created server pool

  3. Free server pool

Oracle Clusterware continues to assign servers to server pools until the following conditions are met:

  1. Until all server pools are filled in order of importance to their minimum (MIN_SIZE).

  2. Until all server pools are filled in order of importance to their maximum (MAX_SIZE).

  3. By default, any servers not placed in a server pool go into the Free server pool.

    You can modify the IMPORTANCE attribute for the Free server pool. If the value of the IMPORTANCE attribute of the Free server pool is greater than one or more of the other server pools, then the Free server pool will receive any remaining servers once the value of their MIN_SIZE attribute is met.

When a server joins a cluster, several things occur.

Consider the server pools configured in Table 3-2:

Table 3-2 Sample Server Pool Attributes Configuration

NAME IMPORTANCE MIN_SIZE MAX_SIZE PARENT_POOLS EXCLUSIVE_POOLS 
sp1

1

1

10

 

 

 
sp2

3

1

6

 

 

 
sp3

2

1

2

 

 

 
sp2_1

2

1

5

sp2

S123

sp2_2

1

1

5

sp2

S123

For example, assume that there are no servers in a cluster; all server pools are empty.

When a server, named server1, joins the cluster:

  1. Server-to-pool assignment commences.

  2. Oracle Clusterware only processes top-level server pools (those that have no parent server pools), first. In this example, the top-level server pools are sp1, sp2, and sp3.

  3. Oracle Clusterware lists the server pools in order of IMPORTANCE, as follows: sp2, sp3, sp1.

  4. Oracle Clusterware assigns server1 to sp2 because sp2 has the highest IMPORTANCE value and its MIN_SIZE value has not yet been met.

  5. Oracle Clusterware processes the remaining two server pools, sp2_1 and sp2_2. The sizes of both server pools are below the value of the MIN_SIZE attribute (both server pools are empty and have MIN_SIZE values of 1).

  6. Oracle Clusterware lists the two remaining pools in order of IMPORTANCE, as follows: sp2_1, sp2_2.

  7. Oracle Clusterware assigns server1 to sp2_1 but cannot assign server1 to sp2_2 because sp2_1 is configured to be exclusive with sp2_2.

After processing, the cluster configuration appears, as follows

Table 3-3 Post Processing Server Pool Configuration

Server Pool Name Assigned Servers 
sp1

 

 
sp2

server1

sp3

 

 
sp2_1

server1

sp2_2

 

Servers Moving from Server Pool to Server Pool

If the number of servers in a server pool falls below the value of the MIN_SIZE attribute for the server pool (such as when a server fails), based on values you set for the MIN_SIZE and IMPORTANCE attributes for all server pools, Oracle Clusterware can move servers from other server pools into the server pool whose number of servers has fallen below the value for MIN_SIZE. Oracle Clusterware selects servers from other server pools to move into the deficient server pool that meet the following criteria:

  • For server pools that have a lower IMPORTANCE value than the deficient server pool, Oracle Clusterware can take servers from those server pools even if it means that the number of servers falls below the value for the MIN_SIZE attribute.

  • For server pools with equal or greater IMPORTANCE, Oracle Clusterware only takes servers from those server pools if the number of servers in a server pool is greater than the value of its MIN_SIZE attribute.

Managing Server Pools Using Default Attributes

By default, each server pool is configured with the following attribute options for managing server pools:

  • MIN_SIZE: The minimum number of servers the server pool should contain.

    If the number of servers in a server pool is below the value of this attribute, then Oracle Clusterware automatically moves servers from elsewhere into the server pool until the number of servers reaches the attribute value.

  • MAX_SIZE: The maximum number of servers the server pool should contain.

  • IMPORTANCE: A number from 0 to 1000 (0 being least important) that ranks a server pool among all other server pools in a cluster.

In addition, you can assign additional attributes to provide more granular management of server pools, as part of a cluster configuration policy. Attributes such as EXCLUSIVE_POOLS and SERVER_CATEGORY can assist you to create policies for your server pools that enhance performance and build tuning design management into your server pool.

Overview of Server Categorization

Oracle Clusterware 11g release 2 (11.2) introduced server pools as a means for specifying resource placement and administering server allocation and access. Originally, server pools were restricted to a set of basic attributes characterizing servers as belonging to a given pool, with no way to distinguish between types of servers; all servers were considered to be equal in relation to their processors, physical memory, and other characteristics.

Server categorization enables you to organize servers into particular categories by using attributes such as processor types, memory, and other distinguishing system features. You can configure server pools to restrict eligible members of the pool to a category of servers, which share a particular set of attributes.

Note:

If you create policies with Oracle Database Quality of Service Management (Oracle Database QoS Management), then you categorize servers by setting server pool directive overrides, and CRSCTL commands using the policy and policyset nouns are disabled. Also if you switch from using Oracle Clusterware policies to using Oracle Database QoS Management policies, then the Oracle Clusterware policies are replaced, because the two policy types cannot coexist. Oracle recommends that you create a backup using crsctl status policyset -file file_name before you switch policies.

See Also:

Overview of Cluster Configuration Policies and the Policy Set

A cluster configuration policy is a document that contains exactly one definition for each server pool managed by the cluster configuration policy set. A cluster configuration policy set is a document that defines the names of all server pools configured for the cluster and definitions for all policies.

Note:

Oracle Clusterware 11g release 2 (11.2) supports only a single server pool configuration. You must manually make any changes to the server pool configuration when you want the change to take effect.

In Oracle Clusterware 12c, you use the policies defined in the cluster configuration policy set for server pool specification and management, and Oracle Clusterware manages the server pools according to the policies in the policy set. With a cluster configuration policy set, for example, you can allocate more servers to OLTP workload during weekly business hours to respond to email demand, and on the weekends and evenings, allocate more servers to batch workloads, and perform transitions of server pool configuration or server allocation, atomically.

At any point in time, only one policy is in effect for the cluster. But you can create several different policies, so that you can configure pools of servers with parameters to reflect differences in requirements for the cluster based on business needs or demand, or based on calendar dates or times of the day.

See Also:

"An Example Policy Set Configuration" for a more detailed example of policy set configuration

Server Configuration and Server State Attributes

Oracle Clusterware assigns each server a set of attributes as soon as you add a server to a cluster. Some of these attributes describe the physical characteristics of the server, while others describe the state conditions of the server. Also, there are other server attributes which you can modify that help further categorize servers. If you remove the server from the cluster, then Oracle Clusterware deletes the server object.

You use server configuration attributes to categorize servers, as part of a server categorization management policy.

Table 3-4 lists and describes server configuration attributes.

Table 3-4 Server Configuration Attributes

Attribute Description 
ACTIVE_CSS_ROLE

Role being performed by the server. A server can have one of the following roles:

  • hub: Designated role for a server in an Oracle Flex Cluster or the designated role for any node in an Oracle Clusterware standard Cluster.

  • leaf: The server is a Leaf Node in an Oracle Flex Cluster.

Note: You cannot configure this attribute.

 
CONFIGURED_CSS_ROLE

Configured role for the server. A server can be either of the following:

hub: Designated role for a server in an Oracle Flex Cluster or the designated role for any node in an Oracle Clusterware standard Cluster.

leaf: The server is a Leaf Node in an Oracle Flex Cluster.

Note: You cannot configure this attribute.

 
CPU_CLOCK_RATE

CPU clock rate in megahertz (MHz)

 
CPU_COUNT

Number of processors

 

CPU_EQUIVALENCY

The relative value (expressed as a positive integer greater than or equal to 1) that Oracle Clusterware uses to describe that the CPU power provided by a server may deviate (positively or negatively) from its physical representation using a baseline of 1000, for example. A value lower than 1000 describes that, despite a certain value for the CPU_COUNT and CPU_CLOCK_RATE parameters, the equivalent power provided by this server is respectively lower.

Use the following commands to view or modify, respectively, this attribute on the local server:

crsctl get cpu equivalency
crsctl set cpu equivalency

CPU_HYPERTHREADING

Status of hyperthreading for the CPU. A value of 0 signifies that hyperthreading is not in use. A value of 1 signifies that hyperthreading is in use.

 
MEMORY_SIZE

Memory size in megabytes (MB)

 
NAME

The name of the server.

 
RESOURCE_USE_ENABLED

A server pool resource management parameter. If the value for this attribute is 1, which is the default, then the server can be used for resource placement. If the value is 0, then Oracle Clusterware disallows starting server pool resources on the server. The server remains in the Free pool.

You can review the setting and control this attribute for each cluster member node by using the crsctl get resource use and crsctl set resource use commands.

 
SERVER_LABEL

An arbitrary value that you can use to label the server. You can use this attribute when setting up server categories. For example, you can specify a location (such as building_A or building_B), which makes it possible to put servers into pools where location is a requirement, by creating an appropriate server category and using it for the server pool.

Use the following commands to view or modify, respectively, this attribute on the local server:

crsctl get server label
crsctl set server label

Table 3-5 lists and describes read-only server state and configuration attributes:

Table 3-5 Server State Attributes

Attribute Description 
ACTIVE_POOLS

A space-delimited list of the names of the server pools to which a server belongs. Oracle Clusterware manages this list automatically.

 
STATE

A server can be in one of the following states:

  • ONLINE: The server is a member of the cluster and is available for resource placement.

  • OFFLINE: The server is not currently a member of the cluster. Subsequently, it is not available for resource placement.

  • JOINING: When a server joins a cluster, Oracle Clusterware processes the server to ensure that it is valid for resource placement. Oracle Clusterware also checks the state of resources configured to run on the server. Once the validity of the server and the state of the resources are determined, the server transitions out of this state.

  • LEAVING: When a planned shutdown for a server begins, the state of the server transitions to LEAVING, making it unavailable for resource placement.

  • VISIBLE: Servers that have Oracle Clusterware running, but not the Cluster Ready Services daemon (CRSD), are put into the VISIBLE state. This usually indicates an intermittent issue or failure and Oracle Clusterware trying to recover (restart) the daemon. Oracle Clusterware cannot manage resources on servers while the servers are in this state.

  • RECONFIGURING: When servers move between server pools due to server pool reconfiguration, a server is placed into this state if resources that ran on it in the current server pool must be stopped and relocated. This happens because resources running on the server may not be configured to run in the server pool to which the server is moving. As soon as the resources are successfully relocated, the server is put back into the ONLINE state.

Use the crsctl status server command to obtain server information.

 
STATE_DETAILS

This is a read-only attribute that Oracle Clusterware manages. The attribute provides additional details about the state of a server. Possible additional details about a server state are:

Server state: ONLINE:

  • AUTOSTARTING RESOURCES

    Indicates that the resource autostart procedure (performed when a server reboots or the Oracle Clusterware stack is restarted) is in progress for the server.

  • AUTOSTART QUEUED

    The server is waiting for the resource autostart to commence. Once that happens, the attribute value changes to AUTOSTARTING RESOURCES.

Server state: RECONFIGURING:

  • STOPPING RESOURCES

    Resources that are restricted from running in a new server pool are stopping.

  • STARTING RESOURCES

    Resources that can run in a new server pool are starting.

  • RECONFIG FAILED

    One or more resources did not stop and thus the server cannot transition into the ONLINE state. At this point, manual intervention is required. You must stop or unregister resources that did not stop. After that, the server automatically transitions into the ONLINE state.

Server state: JOINING:

  • CHECKING RESOURCES

    Whenever a server reboots, the Oracle Clusterware stack restarts, or CRSD on a server restarts, the policy engine must determine the current state of the resources on the server. While that procedure is in progress, this value is returned.

Managing Memory Pressure for Database Servers

Enterprise database servers can use all available memory due to too many open sessions or runaway workloads. Running out of memory can result in failed transactions or, in extreme cases, a restart of the server and the loss of a valuable resource for your applications. Oracle Database QoS Management detects memory pressure on a server in real time and redirects new sessions to other servers to prevent using all available memory on the stressed server.

When Oracle Database QoS Management is enabled and managing an Oracle Clusterware server pool, Cluster Health Monitor sends a metrics stream that provides real-time information about memory resources for the cluster servers to Oracle Database QoS Management. This information includes the following:

  • Amount of available memory

  • Amount of memory currently in use

If Oracle Database QoS Management determines that a node is under memory stress, then the database services managed by Oracle Clusterware are stopped on that node, preventing new connections from being created. After the memory stress is relieved, the services on that node are restarted automatically, and the listener starts sending new connections to that server. Memory pressure can be relieved in several ways (for example, by closing existing sessions or by user intervention).

Rerouting new sessions to different servers protects the existing workloads on the memory-stressed server and enables the server to remain available. Managing the memory pressure for servers adds a new resource protection capability in managing service levels for applications hosted on Oracle RAC databases.

Server Category Attributes

You define servers into named categories, and assign attributes that define servers as members of that category. Some attributes that you can use to define members of a category describe the state conditions for the server, and others describe the physical characteristics of the server. You can also create your own characteristics to define servers as members of a particular category.

Note:

If you change the value of any of the server attributes listed in the EXPRESSION server category attribute, then you must restart the Oracle Clusterware technology stack on the affected servers before the new values take effect.

Table 3-6 lists and describes possible server category attributes.

Table 3-6 Server Category Attributes

Attribute Values and Format Description 
NAME

String

The name of the server category, which you must specify when you create the server category. Server category names must be unique within the domain of names of user-created entities, such as resources, types, and servers. A server pool name has a 254 character limit and can contain any platform-supported characters except the exclamation point (!) and the tilde (~). A server pool name cannot begin with a period nor with ora.

 
ACTIVE_CSS_ROLE

hub, leaf

Active role for the server, which can be either of the following:

hub: The server is a Hub Node in either an Oracle Flex Cluster or an Oracle Clusterware standard Cluster. This is the default value in either case.

leaf: The server is a Leaf Node in an Oracle Flex Cluster.

 

EXPRESSION

String in the following format:

(expression)

A set of server attribute names, values, and conditions that can be evaluated for each server to determine whether it belongs to the category. Table 3-4 lists and describes server attributes.

Acceptable comparison operators include:


=: equal
eqi: equal, case insensitive
>: greater than
<: less than
!=: not equal
co: contains
coi: contains, case insensitive
st: starts with
en: ends with
nc: does not contain
nci: does not contain, case insensitive

Acceptable boolean operators include:


AND
OR

Note: Spaces must surround the operators used in the EXPRESSION string.

For example:

EXPRESSION='((NAME = server1) OR (NAME = server2))'"

An Example Policy Set Configuration

Assume that you have a four-node cluster that is used by three different applications, app1, app2, and app3, and that you have created three server pools, pool1, pool2, and pool3. You configure the server pools such that each application is assigned to run in its own server pool, and that app1 wants to have two servers, and app2 and app3 each want one server. The server pool configurations are as follows:

$ crsctl status serverpool pool1 -p
NAME=pool1
IMPORTANCE=0
MIN_SIZE=2
MAX_SIZE=2
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:mjk:rwx,pgrp:g900:rwx,other::r--
SERVER_CATEGORY=

$ crsctl status serverpool pool2 -p
NAME=pool2
IMPORTANCE=0
MIN_SIZE=1
MAX_SIZE=1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:mjk:rwx,pgrp:g900:rwx,other::r--
SERVER_CATEGORY=

$ crsctl status serverpool pool3 -p
NAME=pool3
IMPORTANCE=0
MIN_SIZE=1
MAX_SIZE=1
SERVER_NAMES=
PARENT_POOLS=
EXCLUSIVE_POOLS=
ACL=owner:mjk:rwx,pgrp:g900:rwx,other::r--
SERVER_CATEGORY=

Notes:

The crsctl status serverpool command shown in the preceding examples only functions if you created the server pools using CRSCTL.

This configuration, however, does not consider the fact that some applications need server time at different times of the day, week, or month. Email applications, for example, typically use more resources during business hours and use less resources at night and on weekends.

Further assume that app1 requires two servers during business hours, but only requires one server at night and does not require any servers on weekends. At the same time, app2 and app3 each require one server during business hours, while at night, app2 requires two servers and app3 requires one. On the weekend, app2 requires one server and app3 requires three. This scenario suggests three configurations that you must configure for the cluster:

  1. Day Time:


    app1 uses two servers
    app2 and app3 use one server, each

  2. Night Time:


    app1 uses one server
    app2 uses two servers
    app3 uses one server

  3. Weekend:


    app1 is not running (0 servers)
    app2 uses one server
    app3 uses three servers

Policy Set Creation

Given these assumptions, run the crsctl create policyset command to create a policy set with a single policy named Default, which reflects the configuration displayed by the crsctl status serverpool command. You can use the Default policy to create other policies to meet the needs assumed in this example. The crsctl create policyset command creates a text file similar to Example 3-1.

Example 3-1 Policy Set Text File

SERVER_POOL_NAMES=Free pool1 pool2 pool3
POLICY
  NAME=Default
  SERVERPOOL
    NAME=pool1
    IMPORTANCE=0
    MAX_SIZE=2
    MIN_SIZE=2
    SERVER_CATEGORY=
  SERVERPOOL
    NAME=pool2
    IMPORTANCE=0
    MAX_SIZE=1
    MIN_SIZE=1
    SERVER_CATEGORY=
  SERVERPOOL
    NAME=pool3
    IMPORTANCE=0
    MAX_SIZE=1
    MIN_SIZE=1
    SERVER_CATEGORY=

Policy Modification

To modify the preceding policy set to meet the needs assumed in this example, edit the text file to define policies for the three scenarios discussed previously, by changing the name of the policy from Default to DayTime. Then, copy the policy and paste it twice to form two subsequent policies, which you name NightTime and Weekend, as shown in Example 3-2.

Example 3-2 Modified Policy Set Text File

SERVER_POOL_NAMES=Free pool1 pool2 pool3
POLICY
  NAME=DayTime
  SERVERPOOL
    NAME=pool1
    IMPORTANCE=0
    MAX_SIZE=2
    MIN_SIZE=2
    SERVER_CATEGORY=
  SERVERPOOL
    NAME=pool2
    IMPORTANCE=0
    MAX_SIZE=1
    MIN_SIZE=1
    SERVER_CATEGORY=
  SERVERPOOL
    NAME=pool3
    IMPORTANCE=0
    MAX_SIZE=1
    MIN_SIZE=1
    SERVER_CATEGORY=
POLICY
  NAME=NightTime
  SERVERPOOL
    NAME=pool1
    IMPORTANCE=0
    MAX_SIZE=1
    MIN_SIZE=1
    SERVER_CATEGORY=
  SERVERPOOL
    NAME=pool2
    IMPORTANCE=0
    MAX_SIZE=2
    MIN_SIZE=2
    SERVER_CATEGORY=
  SERVERPOOL
    NAME=pool3
    IMPORTANCE=0
    MAX_SIZE=1
    MIN_SIZE=1
    SERVER_CATEGORY=
POLICY
  NAME=Weekend
  SERVERPOOL
    NAME=pool1
    IMPORTANCE=0
    MAX_SIZE=0
    MIN_SIZE=0
    SERVER_CATEGORY=
  SERVERPOOL
    NAME=pool2
    IMPORTANCE=0
    MAX_SIZE=1
    MIN_SIZE=1
    SERVER_CATEGORY=
  SERVERPOOL
    NAME=pool3
    IMPORTANCE=0
    MAX_SIZE=3
    MIN_SIZE=3
    SERVER_CATEGORY=

Notice that, in addition to changing the names of the individual policies, the MAX_SIZE and MIN_SIZE policy attributes for each of the server pools in each of the policies were also modified according to the needs of the applications.

The following command registers the policy set stored in a file with Oracle Clusterware:

$ crsctl modify policyset -file file_name

You can achieve the same results as shown in the previous examples by editing the Default policy set, as a whole, using the crsctl modify policyset command, and by using the crsctl modify serverpool command to change individual server pool attributes for a specific policy.

The following command modifies the Default policy set to manage the three server pools:

$ crsctl modify policyset –attr "SERVER_POOL_NAMES=Free pool1 pool2 pool3"

The following commands add the three policies:

$ crsctl add policy DayTime
$ crsctl add policy NightTime
$ crsctl add policy Weekend

The following commands configure the three server pools according to the requirements of the policies:

$ crsctl modify serverpool pool1 -attr "MIN_SIZE=2,MAX_SIZE=2" -policy DayTime
$ crsctl modify serverpool pool1 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy NightTime
$ crsctl modify serverpool pool1 -attr "MIN_SIZE=0,MAX_SIZE=0" -policy Weekend

$ crsctl modify serverpool pool2 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy DayTime
$ crsctl modify serverpool pool2 -attr "MIN_SIZE=2,MAX_SIZE=2" -policy NightTime
$ crsctl modify serverpool pool2 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy Weekend

$ crsctl modify serverpool pool3 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy DayTime
$ crsctl modify serverpool pool3 -attr "MIN_SIZE=1,MAX_SIZE=1" -policy NightTime
$ crsctl modify serverpool pool3 -attr "MIN_SIZE=3,MAX_SIZE=3" -policy Weekend

There are now three distinct policies to manage the server pools to accommodate the requirements of the three applications.

Policy Activation

The policy set is now configured and controlling the three server pools with three different policies. You can activate policies when necessary, prompting Oracle Clusterware to reconfigure a server pool according to each policy's configuration.

The following command activates the DayTime policy:

$ crsctl modify policyset -attr "LAST_ACTIVATED_POLICY=DayTime"

The current status of the resources is as follows:

$ crsctl status resource -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
app1
      1        ONLINE  ONLINE       mjk_has3_2               STABLE
      2        ONLINE  ONLINE       mjk_has3_0               STABLE
app2
      1        ONLINE  ONLINE       mjk_has3_1               STABLE
app3
      1        ONLINE  ONLINE       mjk_has3_3               STABLE

The status of the server pools is as follows:

$ crsctl stat serverpool
NAME=Free
ACTIVE_SERVERS=

NAME=Generic
ACTIVE_SERVERS=

NAME=pool1
ACTIVE_SERVERS=mjk_has3_0 mjk_has3_2

NAME=pool2
ACTIVE_SERVERS=mjk_has3_1

NAME=pool3
ACTIVE_SERVERS=mjk_has3_3

The servers are allocated according to the DayTime policy and the applications run on their respective servers.

The following command activates the Weekend policy (remember, because the server pools have different sizes, as servers move between server pools, some applications will be stopped and others will be started):

$ crsctl modify policyset -attr "LAST_ACTIVATED_POLICY=Weekend"
CRS-2673: Attempting to stop 'app1' on 'mjk_has3_2'
CRS-2673: Attempting to stop 'app1' on 'mjk_has3_0'
CRS-2677: Stop of 'app1' on 'mjk_has3_0' succeeded
CRS-2672: Attempting to start 'app3' on 'mjk_has3_0'
CRS-2677: Stop of 'app1' on 'mjk_has3_2' succeeded
CRS-2672: Attempting to start 'app3' on 'mjk_has3_2'
CRS-2676: Start of 'app3' on 'mjk_has3_2' succeeded
CRS-2676: Start of 'app3' on 'mjk_has3_0' succeeded

The current status of the resources is as follows:

$ crsctl status resource -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details      
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
app1
      1        ONLINE  OFFLINE                               STABLE
      2        ONLINE  OFFLINE                               STABLE
app2
      1        ONLINE  ONLINE       mjk_has3_1               STABLE
app3
      1        ONLINE  ONLINE       mjk_has3_0               STABLE
      2        ONLINE  ONLINE       mjk_has3_2               STABLE
      3        ONLINE  ONLINE       mjk_has3_3               STABLE
--------------------------------------------------------------------------------

The status of the server pools is as follows:

$ crsctl status serverpool
NAME=Free
ACTIVE_SERVERS=

NAME=Generic
ACTIVE_SERVERS=

NAME=pool1
ACTIVE_SERVERS=

NAME=pool2
ACTIVE_SERVERS=mjk_has3_1

NAME=pool3
ACTIVE_SERVERS=mjk_has3_0 mjk_has3_2 mjk_has3_3

Using the crsctl modify policyset command, Oracle Clusterware changed server pool configuration, moved servers according to the requirements of the policy, and stopped and started the applications.

See Also:

Appendix E, "Oracle Clusterware Control (CRSCTL) Utility Reference" for complete details on using the CRSCTL commands shown in this example