3 Policy-Based Cluster and Capacity Management
This chapter includes the following topics:
3.1 Overview of Server Pools and Policy-Based Management
Resources managed by Oracle Clusterware are contained in logical groups of servers called server pools. This was introduced in Oracle Clusterware 11g release 2 (11.2).
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 Cluster 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.
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:
3.1.1 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.
Related Topics
3.1.2 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.
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.
3.1.3 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
3.1.4 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.
3.1.4.2 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
-
3.1.5 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.
When you use CRSCTL to create a server pool, all attributes listed and described in the following table are available to you.
Table 3-1 Server Pool Attributes
Attribute | Description |
---|---|
ACL |
String in the following format:
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:
By default, the identity of the client that creates the server pool is the
The operating system user that creates the server pool is the owner of the server pool, and the |
ACTIVE_SERVERS |
A string of server names in the following format:
Oracle Clusterware automatically manages this attribute, which contains the space-delimited list of servers that are currently assigned to a server pool. |
EXCLUSIVE_POOLS |
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 Top-level server pools are mutually exclusive, by default. |
IMPORTANCE |
Relative importance of the server pool, expressed as an integer from 0 to 1000, 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 |
The minimum size of a server pool expressed as any nonnegative integer. 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 |
MAX_SIZE |
The maximum number of servers a server pool can contain, expressed as any nonnegative integer. This attribute is optional and is set to Note: A value of |
NAME |
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 |
Use of this attribute makes it possible to create nested server pools. Server pools, listed as a string of space-delimited server pool names, 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 |
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 Use the |
SERVER_NAMES |
A list of candidate node names, expressed as a string of space-delimited server 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 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 Note: If you set the |
3.1.6 How Oracle Clusterware Assigns New Servers Using Server Pools
Oracle Clusterware assigns new servers to server pools in the following order:
-
Generic server pool
-
User-created server pool
-
Free server pool
Oracle Clusterware continues to assign servers to server pools until the following conditions are met:
-
Until all server pools are filled in order of importance to their minimum (
MIN_SIZE
). -
Until all server pools are filled in order of importance to their maximum (
MAX_SIZE
). -
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 theIMPORTANCE
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 theirMIN_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:
-
Server-to-pool assignment commences.
-
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
, andsp3
. -
Oracle Clusterware lists the server pools in order of
IMPORTANCE
, as follows:sp2
,sp3
,sp1
. -
Oracle Clusterware assigns
server1
tosp2
becausesp2
has the highestIMPORTANCE
value and itsMIN_SIZE
value has not yet been met. -
Oracle Clusterware processes the remaining two server pools,
sp2_1
andsp2_2
. The sizes of both server pools are below the value of theMIN_SIZE
attribute (both server pools are empty and haveMIN_SIZE
values of1
). -
Oracle Clusterware lists the two remaining pools in order of
IMPORTANCE
, as follows:sp2_1
,sp2_2
. -
Oracle Clusterware assigns
server1
tosp2_1
but cannot assignserver1
tosp2_2
becausesp2_1
is configured to be exclusive withsp2_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 |
|
3.1.6.1 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 theMIN_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 itsMIN_SIZE
attribute.
3.1.7 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.
3.2 Overview of Server Categorization
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. 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 now provides a way to distinguish these servers.
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.
3.3 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.
Related Topics
3.4 Load-Aware Resource Placement
You can configure a database so that Oracle Clusterware is aware of the CPU requirements and limits for the given database.
Oracle Clusterware uses this information to place the database resource only on servers that have a sufficient number of CPUs, amount of memory, or both.
If you have configured resources with CPU or memory requirements in Oracle Clusterware, then Oracle Clusterware will only attempt to start those resources on the servers that have that meet those requirements. For database resources, specifically, you can configure the CPU or memory values into the CPU_COUNT
and MEMORY_TARGET
instance parameters, respectively.
Note:
Configuring the instance parameters requires the following:-
For CPU (Instance Caging), the Resource Manager must be enabled
-
For memory, Automatic Memory Management must be used for the database
When you add or modify a database instance, you can configure load-aware resource placement, as follows:
$ srvctl modify database -db db_unique_name -cpucount cpu_count -memorytarget memory_target
In the preceding example, cpu_count
refers to the number of workload CPUs and memory_target
refers to the target memory, in MB, used by the resource.
If the Resource Manager is enabled in the database, then Oracle Clusterware sets the CPU_COUNT parameter to the value of -cpucount
. Also, if Automatic Memory Management is enabled for the database, then Oracle Clusterware sets the MEMORY_TARGET database parameter to the value of -memorytarget
.
3.5 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.
The following table 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:
Note: You cannot configure this attribute. |
CONFIGURED_CSS_ROLE |
Configured role for the server. A server can be either of the following:
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 Use the following commands to view or modify, respectively, this attribute on the local server:
|
CPU_HYPERTHREADING |
Status of hyperthreading for the CPU. A value of |
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 |
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:
|
The following table 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:
Use the |
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:
Server state:
Server state:
|
3.5.1 Memory Pressure Management 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.
3.6 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.
The following table lists and describes possible server category attributes.
Table 3-6 Server Category Attributes
Attribute | Description |
---|---|
NAME |
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 |
Active role for the server, which can be either of the following:
|
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:
Acceptable boolean operators include:
Note: Spaces must surround the operators used in the For example: EXPRESSION='((NAME = server1) OR (NAME = server2))'" |
3.7 An Example Policy Set Configuration
In this example, 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=
Note:
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:
-
Day Time:
- app1 uses two servers
- app2 and app3 use one server, each
-
Night Time:
- app1 uses one server
- app2 uses two servers
- app3 uses one server
-
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.
Related Topics