This chapter describes server pool concepts in Oracle Real Application Clusters (Oracle RAC) environments. This chapter contains the following topics:
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. Resources are no longer defined as belonging to a specific instance or node. Instead, the priority of resource requirements is defined. You can use a cluster configuration policy set to provide dynamic management of cluster policies across the cluster.
The following sections provide additional concepts about server pools:
You can manage servers dynamically using server pools by identifying servers distinguished by particular attributes, a process called server categorization. In this way, you can manage clusters made up of heterogeneous nodes.
With policy-based management, database administrators specify the server pool (excluding Generic or Free) in which the database resource runs
Policy-based management:
Enables dynamic capacity assignment when needed to provide server capacity in accordance with the priorities you set with policies
Enables allocation of resources by importance, so that applications obtain the required minimum resources, whenever possible, and so that lower priority applications do not take resources from more important applications
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 right service at the right time
Applications and databases running in server pools do not share resources. Because server pools do not share resources, they isolate resources where necessary, but enable dynamic capacity assignments as required. Together with role-separated management, this capability addresses the needs of organizations that have standardized cluster environments, but allow multiple administrator groups to share the common cluster infrastructure.
Oracle Clusterware efficiently allocates different resources in the cluster. You need only to provide the minimum and maximum number of nodes on which a resource can run, combined with a level of importance for each resource that is running on these nodes.
See Also:
Oracle Clusterware Administration and Deployment Guide for more information about resource attributes
Oracle Clusterware Administration and Deployment Guide for details about managing server pools to respond to business or application demand
Server pools divide the cluster into groups of servers hosting singleton and uniform database services and applications. They distribute a uniform workload (a set of Oracle Clusterware resources) over several servers in the cluster. For example, you can restrict Oracle databases to run only in certain server pools. When you enable role-separated management, you can grant permission to operating system users to use server pools.
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.
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
When Oracle Clusterware is installed, two 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 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 stores any Oracle Database that is not policy managed. Additionally, the Generic server pool contains servers with names you specified in the SERVER_NAMES attribute of the server pools that list the Generic server pool as a parent 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)
When DBCA or SRVCTL specifies a server name in the HOSTING_MEMBERS resource attribute, Oracle Clusterware only allows it if the server is:
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
Oracle RAC databases support two different management styles and deployment models:
Policy-managed: Deployment is based on server pools, where database services run within a server pool as singleton or uniform across all of the servers in the server pool. Databases are deployed in one or more server pools and the size of the server pools determine the number of database instances in the deployment. Policy management allows clusters and databases to expand or shrink as requirements change.
A policy-managed database is defined by cardinality, which is the number of database instances you want running during normal operations. A policy-managed database runs in one or more database server pools that the cluster administrator creates in the cluster, and it can run on different servers at different times. A database instance starts on all servers that are in the server pools defined for the database.
Clients can connect to a policy-managed database using the same SCAN-based connect string no matter which servers they happen to be running on at the time.
Administrator-managed: Deployment is based on the Oracle RAC deployment types that existed before Oracle Database 11g release 2 (11.2) and requires that you statically configure each database instance to run on a specific node in the cluster, and that you configure database services to run on specific instances belonging to a certain database using the preferred and available designation.
When you review the database resource for an administrator-managed database, you see a server pool defined with the same name as the Oracle database. This server pool is part of a special Oracle-defined server pool called Generic. Oracle RAC manages the Generic server pool to support administrator-managed databases. When you add or remove an administrator-managed database using either SRVCTL or DBCA, Oracle RAC creates or removes the server pools that are members of the Generic server pool.
See Also:
Oracle Clusterware Administration and Deployment Guide for detailed information about server pools
Oracle Clusterware Administration and Deployment Guide for information about policy sets
You can create a server pool with DBCA while creating an Oracle RAC database, but Oracle recommends that you create server pools before you deploy database software and databases. Oracle also recommends that you:
Enable role separation before you create the first server pool in the cluster.
Create and manage server pools using configuration policies and a respective policy set.
You can implement role-separated management in one of two ways:
Vertical implementation (between layers) describes a role separation approach based on different operating system users and groups used for various layers in the technology stack. Permissions on server pools and resources are granted to different users (and groups) for each layer in the stack using access control lists. Oracle Automatic Storage Management (ASM) offers setting up role separation as part of the Oracle Grid Infrastructure installation based on a granular assignment of operating system groups for specific roles.
Horizontal implementation (within one layer) describes a role separation approach that restricts resource access within one layer using access permissions for resources that are granted using access control lists assigned to server pools and policy-managed databases or applications.
For example, consider an operating system user called grid, that installs Oracle Grid Infrastructure and creates two database server pools. The operating system users ouser1 and ouser2 must be able to operate within a server pool, but should not be able to modify those server pools and withdraw hardware resources from other server pools either accidentally or intentionally.
See Also:
Oracle Clusterware Administration and Deployment Guide for information about creating policy sets
Oracle Clusterware Administration and Deployment Guide for information about configuring role-separated management
Note the following about Oracle RAC One Node and server pools:
Oracle RAC One Node runs only in one server pool. This server pool is treated the same as any other server pool.
Online relocation of an Oracle RAC One Node database instance permits planned migrations of an Oracle RAC One Node database from one node to another node. Relocations must always be within a server pool.