Policy based cluster management in oracle 12c

Policy Based Cluster Management In
Oracle 12c
ANJU GARG

About me
Sangam 16 Anju Garg 2
• Oracle Ace
• More than 14 years of experience in IT Industry
• Oracle Certified Specialist and Expert
• Independent Corporate Trainer (Oracle DBA), Author, Speaker
• Member - AIOUG, IOUG, UKOUG
• Oracle blog : http://oracleinaction.com/
• Email : anjugarg66@gmail.com

Agenda
• Resource management in a cluster
– Administrator Managed configuration
– Policy Managed configuration
• Server Assignment for Policy Based Cluster Management
– Illustration-I: New Server Assignment
– Illustration-II: Reallocations of servers
• Limitations of Policy Based Management In Oracle Clusterware 11g R2
• Policy based cluster management in Oracle clusterware 12c
– Server Categorization
• Illustration-III
– Extended Policy framework
• Illustration-IV
• Summary
• References
• Q & A

Resource Management In A Cluster
• Administrator Managed configuration
• Policy Managed configuration

Administrator Managed configuration
• Only management strategy available in releases earlier than 11g R2
• Administrator statically assigns clusterware resources to specific servers in
the cluster.
• Oracle Clusterware is responsible for placing the resources on the specified
servers
• Hard coupling between the resources and the servers eliminates resource
sharing .
• An inflexible, manual management configuration best suited for smaller
clusters or rather static systems
• Cannot scale very well in large clusters having more than 8 nodes.

Policy Managed configuration
• Introduced in Oracle Clusterware 11g release 2
• The cluster can be logically partitioned into groups of servers called server
pools.
• Administrator assigns clusterware resources to Server pools whose size can
change dynamically.
• Oracle Clusterware is responsible for placing the resources on the servers
belonging to the specified server pool(s).
• Flexible management eliminates the need for static definitions physically
assigning resources to particular nodes in the cluster.
• Best suited for larger clusters and scales very well in large clusters having
more than 8 nodes.

Policy Based Cluster Management
Server Pools
• Foundation of policy based cluster management
• Logical groups of servers hosting the resources managed by Oracle
Clusterware.
• The scalability of resources is controlled by the MIN_SIZE and MAX_SIZE
attributes of the server pool.
• Different IMPORTANCE can be assigned to server pools
• Critical workloads can be mapped to server pools of higher IMPORTANCE.
• Based on available compute resources in the cluster, Oracle Clusterware will
allocate servers to server pools in order of their IMPORTANCE
• Ensures that business critical workload get the compute resources necessary
to satisfy performance or availability service level agreements.
• Server pools can expand or shrink as requirements change.

Policy Based Cluster Management
Server Pool Types
• Built-in pools : Created automatically with the installation of the cluster
– Generic Server Pool:
• Internally managed server pool
• All attributes are read-only
• Hosts Admininstrator -managed resources.
– Free Server Pool: an internally managed pool
• Internally managed server pool
• IMPORTANCE attribute can be edited by the user
• Contains servers that are not assigned to any other server pools.
• User-created Server Pool
• Created by user
• MIN_SIZE, MAX_SIZE and IMPORTANCE attribute can be edited
by the user

Server Assignment for Policy Based Management
• New Server Assignment
• Reallocation of servers

New Server Assignment
• New servers are assigned to server pools in the following order:
– Generic server pool
– User-created server pool
• Fill all server pools in order of importance until they meet their
minimum (MIN_SIZE).
• Fill all server pools in order of importance until they meet their
maximum (MAX_SIZE).
– Free server pool

Reallocation of servers
• If server(s) leave the cluster, a server reallocation between pools may take
place.
• If there are servers in the Free Pool
– If a server pool falls below its MAX_SIZE value, a free server is moved
from the Free Pool to the affected server pool.
• Else (No free servers)
– Only if a server pool falls below its MIN_SIZE, a server reallocation will
take place as follows:
• Determine the server pool having least IMPORTANCE
• If the least IMPORTANT server pool exceeds its MIN_SIZE
– Move server to deficient pool
• Else (least IMPORTANT server pool <= MIN_SIZE)
– If IMPORTANCE of least IMPORTANT server pool < deficient
pool
» Move server to deficient pool even if it causes the donor
pool to fall below its MIN_SIZE
Sangam 16 Anju Garg
11

Policy Based Management: Considerations
• A server can be part of only one server pool at any point in time
• A server pool can have one or more servers.
• A particular resource can run on more than one server pool(s)
• Multiple resources / databases can run on one particular server pool
• A particular service is bound to one database
• One Database Service can be assigned to only one server pool.
• Database services come as “singletons” or “uniform”. They either run on
one server or on all servers in a specific server pool
Sangam 16 Anju Garg
12

Illustration-I
New Server Assignment

Environment
• Consider a cluster having 9 servers.
• Three server pools - FrontOffice Pool, BackOffice pool and Line of Business
(LOB) pool have been defined as shown.
• Currently , all the server pools are empty.

Illustration-I : New Server Assignment
• Since FrontOffice Pool has highest IMPORTANCE (=4), and it is below its
MIN_SIZE (=2) , first two servers are assigned to it so that it meets its
MIN_SIZE (=2)

• BackOffice pool which is next in IMPORTANCE (=3) is allocated next
server so that it meets its MIN_SIZE (=1).

• Front office pool is allocated next server so that it meets its MAX_SIZE
(=3).

Example : New Server Assignment
• Nest two servers are assigned to BackOffice pool so that it meets its
MAX_SIZE (=3).

• LOB pool which is next in IMPORTANCE(=2) is allocated two servers so
that it meets its MAX_SIZE (=2).

• One left over server goes to Free Pool

Illustration-I
Summary
• As servers join the cluster, they are assigned to server pools in the
following order:
– Generic server pool
– User-created server pool
 Fill all server pools in order of importance until they meet their
minimum (MIN_SIZE).
 Fill all server pools in order of importance until they meet their
maximum (MAX_SIZE).
– Free server pool

Illustration-II
Reallocation Of Servers

Illustration-II : Reallocation Of Servers
• One server leaves FrontOffice Pool so that the pool falls below its
MAX_SIZE value (=3).

• Since a server is available in Free Pool, that server is moved to FrontOffice
Pool

• FrontOffice Pool meets its MAX_SIZE (=3)

• What will happen if front office pool loses another server?

• NOTHING - Since no free servers are available and FrontOffice pool still
has 2 servers (=MIN_SIZE).

• What will happen if FrontOffice pool loses another server?

• If FrontOffice pool loses another server, it is left with only one server and
falls below its MIN_SIZE limit of 2 servers.
• A server should be sourced from one of the other pools.
• Which pool will become the donor in this case?

• Of the BackOffice and LOB pools, LOB pool has the lowest IMPORTANCE
and has more than its minimum number of servers (=0).
• Hence, a server is moved from LOB pool to FrontOffice pool

• FrontOffice pool has 2 servers now (=MIN_SIZE).

• What happens if any of FrontOffice or BackOffice Pools fall below their
MIN_SIZE?

• If any of FrontOffice or BackOffice Pools fall below their MIN_SIZE, they
will get the only remaining server in the LOB pool since LOB pool has
– Lowest IMPORTANCE
– More than its minimum number of servers (=0).

• What happens if LOB pool is empty,
– If FrontOffice pool falls below MIN_SIZE
• It can grab server(s) from BackOffice pool so as to meet its
MIN_SIZE even if it requires emptying the BackOffice pool.
– If BackOffice pool falls below MIN_SIZE
• It can get at most one server to meet its MIN_SIZE (=1) from
FrontOffice pool only if FrontOffice pool exceeds its MIN_SIZE

Illustration-II
Summary
If servers leave the cluster for any reason, a server reallocation may take
place as follows:
• If there are servers in the Free Pool and another server pool falls below its
MAX_SIZE value, a free server is moved from the Free Pool to the
affected server pool.
• If there are no free servers, then server reallocation takes place only if a
server pool falls below its MIN_SIZE value.
– If there are server pools exceeding their MIN_SIZE
 The least IMPORTANT server pool will be the donor pool
– Else (All server pools at or below MIN_SIZE)
 If there are Server pools less IMPORTANT than the deficient
pool
o The least IMPORTANT server pool will be the donor pool
even if it causes it to shrink below its MIN_SIZE.

Policy Based Management: Benefits
• Fast resource failover: When the number of nodes in the cluster changes,
servers are reallocated online based on defined policy to satisfy workload
capacity requirements.
• Dynamic capacity assignment : Server Pools can expand or shrink as
requirements change.
• Guaranteed allocation of resources : Critical work will be allocated
required resources preferentially as defined by the policy.
• Isolation of resources: Since server pools do not share resources,
dedicated servers can be provided in a cluster for applications and
databases
• Useful for future planning: Once resource requirements has been defined
for expected workload, additional capacity, whenever available will be
used instantaneously.

Policy Based Management In Oracle Clusterware 11g R2
Limitations
• All servers were assumed to be homogeneous with regard to their CPU
count, physical memory and other characteristics.
– Placement of servers in server pools could not be governed by server
attributes.
– Sub-optimal performance of applications executing on inadequate
servers
– Administrator needed to manually map workload to servers having
appropriate attributes
 A burden to the administrator
 Error prone
• Does not consider the fact that server requirements of applications may
be different at different times of the day, week, or month.
– Though server pool properties can be changed to meet such
requirements, it is very cumbersome to do by issuing one command at
a time.

Policy Based Cluster Management In 12c
With Oracle clusterware 12c, policy based cluster management is enhanced in
three important ways.
• Server Categorization
• Extended Policy framework
• Unification of policy based cluster management with QOS
Management

Overview
• Enables supporting clusters with heterogeneous servers.
• Servers can be differentiated based on their attributes which can further
govern placement of servers in the server pools.
• Workflow:
– Every server has a set of server configuration attributes associated
with it
– Servers are further organized into particular categories based on
 Role of the node (Hub / Leaf),
 Server attributes and
 Various conditions
– Server categories are associated with server pools so that now server
pools are defined based on server attributes rather than the names of
the servers
• Provides an efficient, automated mechanism to allocate compute
resources to server pools based on pre-defined server attributes.

Server Attributes
• Various server configuration attributes associated with each server are:
• As Oracle Clusterware stack is started on a server, these attributes are
automatically discovered and stored persistently for each server until
stack is restarted on the server
• Enable Oracle Grid Infrastructure 12c to understand heterogeneous
servers in the cluster

Server Categories
• A new clusterware object
• Enables you to organize servers into particular categories.
• Two internal categories are created by default
- ora.hub.category : Categorizes Hub Nodes
- ora.leaf.category : Categorizes Leaf Nodes
• New user defined server categories can be created
• Various attributes of server category are:
• A server can belong to multiple categories at the same time.

Apply Server Categories To Server Pools
• Associate Server Pools with Server Categories so that Server pools are
defined based on server attributes such as number of CPUs, CPU speed,
Memory etc. rather than the names of the servers.
• Applications can be assigned to the server pools so that they will run on
the servers belonging to a server category.
• If a server pool loses a server, free servers of the associated category, if
available, will be moved to the server pool.
• If free servers of desired category are not available, servers will be moved
from another server pool of lesser IMPORTANCE in order to satisfy the
requirements of business critical workloads.
• Provides an automated and efficient way to manage environments with
varying workload requirements and with servers of varying capacities .

Illustration-III
Server categorization

Sangam 16 Anju Garg
45
Illustration-III
Server Attributes
• Consider a Flex cluster having 3 hub nodes and 2 leaf nodes.
• View server attributes
– Servers host01, host02 and host03 are Hub Nodes and physical
memory associated with them is greater than 2000 MB
– Servers host04 and host05 are Leaf Nodes and physical memory
associated with them is less than 2000 MB

Illustration-III
Default Server Categories
• View default categories

Illustration-III
Default Server Categories
• List servers in the two default categories

Illustration-III
User Defined Server Categories
Create new categories
• Small : Leaf Node and Memory < 2000
• Big : Hub Node and Memory >= 2000

Illustration-III
• View user defined new categories

Illustration-III
• List servers in user defined categories

Illustration-III
Server Categories
• List categories for servers

Illustration-III
• Create server pools and associate them with big / small categories as
follows:
Server pool Category
Bigpool Big
Smallpool Small
Testpool Small
Backuppool Big

Illustration-III
• View server pools and associated categories:

Illustration-III
Summary
• Server categorization enables organization of servers into particular
categories by using various server attributes.
• A Server pool can be associated with a category so that servers belonging
to the category are eligible to be members of the pool .
• Server pools are defined based on server attributes rather than the
names of the servers
• Provides an efficient, automated mechanism to manage clusters made up
of heterogeneous nodes.

Need for Extended Policy Framework
• In Oracle clusterware earlier than 12c, the server pools could be
configured such that each of the applications is assigned to run in its own
server pool.
• This configuration, however, does not consider the fact that server time
requirement of some applications might be different at different times of
the day, week, or month.
• Server time requirement can vary due to
– An anticipated / unanticipated increase in demand for one or more
applications in the cluster.
– Planned maintenance operation (a server needs to be taken down for
maintenance)
– End-of-month or end-of-year changes in demand
• Though server pool properties can be changed to meet such
requirements, it is very cumbersome to do by issuing one command at a
time.

Overview
• Extended Policy Framework in Oracle clusterware 12c provides the
infrastructure to handle the fluctuating requirements for server time
automatically by means of policies.
• Create policies corresponding to different business needs such that each
policy contains exactly one definition for each server pool defined in the
system.
• These policies collectively represent the cluster configuration policy set.
• Different policies need to be activated at different times in accordance
with business needs.
• When a policy is activated at a relevant time, configuration of server pools
is changed according to server pool definitions in the policy.
• Thus server time allocated to various applications changes automatically
in accordance with changing business needs
• Moreover these policies can even be changed dynamically.
• A centralized policy-based approach allows you to dynamically allocate
and reallocate resources to various applications in the cluster as the
demand changes.

Illustration-IV
Extended Policy Framework

Illustration-IV
Environment
• User defined server pools: Bigpool, Smallpool, Testpool and Backuppool
• Our requirement is as follows:
Night

Illustration-IV
Add Policies
• Add Day and Night Policies
• Set the SERVER_POOL_NAMES policy set attribute to define the scope
of the server pools that are controlled by the policy set.

Illustration-IV
Set Server Pool Attributes In Day Policy

Sangam 16 Anju Garg
62
Illustration-IV
Set Server Pool Attributes In Night Policy

Illustration-IV
View Policies
• View Day Policy

Illustration-IV
View Policies
• View Night Policy

Illustration-IV
Activate Day Policy
• Activate day policy

Illustration-IV
Verify Activation Of Day Policy
• Verify that as per the day policy,
• Smallpool has been assigned both the small nodes (host04,host05)
• Bigpool has been assigned three big nodes (host01,host02,host03)
• Testpool and Backuppool have not been assigned any servers

Illustration-IV
Activate Day Policy
• Activate night policy

Sangam 16 Anju Garg
68
Illustration-IV
Verify Activation Of Night Policy
• Verify that as per the night policy
– Backuppool has been assigned one big node (host01)
– Bigpool has been assigned two big nodes (host02,host03)
– Smallpool has been assigned one small node (host05)
– Testpool has been assigned one small node (host04)

Illustration-IV
Modify And Reactivate Night Policy
• Modify the configuration of night policy so that backuppool has 2 big
servers and bigpool has 1 big server.
• Reactivate the night policy

Illustration-IV
Verify Activation Of Modified Night Policy
• As per the modified night policy, one big server (host02) has been taken
away from bigpool and has been assigned to backuppool so that bigpool is
left with only one server and backuppool has 2 servers as desired.

Illustration-IV
Summary
• Extended policy framework enables policies to be configured to change
pools in accordance with business needs or application demand
• Different policies need to be activated at different times in accordance with
business needs.
• When a policy is activated, configuration of server pools is changed
according to server pool definitions in the policy, so that server time
allocated to various applications changes in accordance with changing
business needs
• These policies can be changed dynamically.

Conclusion
• Oracle Clusterware 11g release 2 (11.2) laid the foundation of policy based
cluster management by introducing server pools .
• Limitations of Policy based management in Oracle clusterware 11g R2 :
– As there was no way to distinguish between types of servers, placement
of servers in server pools could not be governed by server attributes.
– This configuration does not consider the fact that server requirements of
applications may be different at different times of the day, week, or
month.
• Enhancements to Policy based management in Oracle clusterware 12c:
– Server Categorization: Servers can be differentiated based on their
attributes which can further govern placement of servers in server pools.
– Extended Policy framework: Policies can be configured to change server
pool attributes in accordance with business needs or application
demand, so that pools provide the right service at the right time. The
administrators can maintain a library of policies and switch between
them as required.

References
• https://docs.oracle.com/database/121/CWADD/pbmgmt.htm#CWADD91116
• http://www.oracle.com/technetwork/database/options/clustering/learnmore/policy-managed-
deployments12c-twp-2338881.pdf

ANJU GARG
Email:anjugarg66@gmail.com
Blog:http://oracleinaction.com

Policy based cluster management in oracle 12c

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Policy based cluster management in oracle 12c

Ähnlich wie Policy based cluster management in oracle 12c (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Policy based cluster management in oracle 12c