Oracle policy based management

Oracle Clusterware uses 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
• Default Server Pools
• Overview of Server Categorization
• Overview of Cluster Configuration Policies and the Policy Set
• Server Weight-Based Node Eviction
• Load-Aware Resource Placement
• Server Configuration and Server State Attributes
• Server Category Attributes
• An Example Policy Set Configuration

Starting with Oracle Grid Infrastructure 21c, policy-managed databases are deprecated.

You can continue to use existing server pools, and create new pools and policies. Resources using existing server pools can continue to use them transparently.

The use of CRS configuration policies and the CRS policy set can be desupported in a future release. In place of server pools and policy-managed databases, Oracle recommends that you use the new "Merged" management style.

Overview of Server Pools and Policy-Based Management

Resources managed by Oracle Clusterware 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 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 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
• Server Pools and Policy-Based Management
• How Server Pools Work
• Default Server Pools
• Server Pool Attributes
• How Oracle Clusterware Assigns New Servers Using Server Pools
• Managing Server Pools Using Default Attributes

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

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.

• 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.

Related Topics

• Oracle Clusterware Resource Reference
• Overview of Cluster Configuration Policies and the Policy Set

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.

  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

  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.

  • 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:

  user:user_name:rwx

  group:group_name:rwx

  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.

  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.

  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.

  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.

  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 0 .

  The maximum number of servers a server pool can contain, expressed as any nonnegative integer. 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.

  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.

  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.

  The name of a registered server category, used as part of server categorization. Oracle Clusterware standard clusters and Oracle Flex Clusters have a default category of hub . 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.

  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 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.

  Related Topics

  • crsctl add serverpool
  • crsctl status server
  • Server Category Attributes
  • Oracle Real Application Clusters Administration and Deployment Guide

  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