This chapter reviews the resource management framework and describes a hypothetical server consolidation project.
The following topics are covered in this chapter:
In this example, five applications are being consolidated onto a single system. The target applications have resource requirements that vary, different user populations, and different architectures. Currently, each application exists on a dedicated server that is designed to meet the requirements of the application. The applications and their characteristics are identified in the following table.
|
Application Description |
Characteristics |
|---|---|
|
Application server |
Exhibits negative scalability beyond 2 CPUs |
|
Database instance for application server |
Heavy transaction processing |
|
Application server in test and development environment |
GUI-based, with untested code execution |
|
Transaction processing server |
Primary concern is response time |
|
Standalone database instance |
Processes a large number of transactions and serves multiple time zones |
The following configuration is used to consolidate the applications onto a single system.
The application server has a two–CPU processor set.
The database instance for the application server and the standalone database instance are consolidated onto a single processor set of at least four CPUs. The standalone database instance is guaranteed 75 percent of that resource.
The test and development application server requires the IA scheduling class to ensure UI responsiveness. Memory limitations are imposed to lessen the effects of bad code builds.
The transaction processing server is assigned a dedicated processor set of at least two CPUs, to minimize response latency.
This configuration covers known applications that are executing and consuming processor cycles in each resource set. Thus, constraints can be established that allow the processor resource to be transferred to sets where the resource is required.
The wt-load objective is set to allow resource sets that are highly utilized to receive greater resource allocations than sets that have low utilization.
The locality objective is set to tight, which is used to maximize processor locality.
An additional constraint to prevent utilization from exceeding 80 percent of any resource set is also applied. This constraint ensures that applications get access to the resources they require. Moreover, for the transaction processor set, the objective of maintaining utilization below 80 percent is twice as important as any other objectives that are specified. This importance will be defined in the configuration.
Edit the /etc/project database file. Add entries to implement the required resource controls and to map users to resource pools, then view the file.
# cat /etc/project . . . user.app_server:2001:Production Application Server:::project.pool=appserver_pool user.app_db:2002:App Server DB:::project.pool=db_pool;project.cpu-shares=(privileged,1,deny) development:2003:Test and development::staff:project.pool=dev_pool; process.max-address-space=(privileged,536870912,deny)keep with previous line user.tp_engine:2004:Transaction Engine:::project.pool=tp_pool user.geo_db:2005:EDI DB:::project.pool=db_pool;project.cpu-shares=(privileged,3,deny) . . . |
The development team has to execute tasks in the development project because access for this project is based on a user's group ID (GID).
Create an input file named pool.host, which will be used to configure the required resource pools. View the file.
# cat pool.host create system host create pset dev_pset (uint pset.min = 0; uint pset.max = 2) create pset tp_pset (uint pset.min = 2; uint pset.max=8) create pset db_pset (uint pset.min = 4; uint pset.max = 6) create pset app_pset (uint pset.min = 1; uint pset.max = 2) create pool dev_pool (string pool.scheduler="IA") create pool appserver_pool (string pool.scheduler="TS") create pool db_pool (string pool.scheduler="FSS") create pool tp_pool (string pool.scheduler="TS") associate pool dev_pool (pset dev_pset) associate pool appserver_pool (pset app_pset) associate pool db_pool (pset db_pset) associate pool tp_pool (pset tp_pset) modify system tester (string system.poold.objectives="wt-load") modify pset dev_pset (string pset.poold.objectives="locality tight; utilization < 80") modify pset tp_pset (string pset.poold.objectives="locality tight; 2: utilization < 80") modify pset db_pset (string pset.poold.objectives="locality tight;utilization < 80") modify pset app_pset (string pset.poold.objectives="locality tight; utilization < 80") |
Update the configuration using the pool.host input file.
# poolcfg -f pool.host |
Make the configuration active.
# pooladm -c |
The framework is now functional on the system.
To view the framework configuration, which also contains default elements created by the system, type:
# pooladm
system host
string system.comment
int system.version 1
boolean system.bind-default true
int system.poold.pid 177916
string system.poold.objectives wt-load
pool dev_pool
int pool.sys_id 125
boolean pool.default false
boolean pool.active true
int pool.importance 1
string pool.comment
string pool.scheduler IA
pset dev_pset
pool appserver_pool
int pool.sys_id 124
boolean pool.default false
boolean pool.active true
int pool.importance 1
string pool.comment
string pool.scheduler TS
pset app_pset
pool db_pool
int pool.sys_id 123
boolean pool.default false
boolean pool.active true
int pool.importance 1
string pool.comment
string pool.scheduler FSS
pset db_pset
pool tp_pool
int pool.sys_id 122
boolean pool.default false
boolean pool.active true
int pool.importance 1
string pool.comment
string pool.scheduler TS
pset tp_pset
pool pool_default
int pool.sys_id 0
boolean pool.default true
boolean pool.active true
int pool.importance 1
string pool.comment
string pool.scheduler TS
pset pset_default
pset dev_pset
int pset.sys_id 4
string pset.units population
boolean pset.default false
uint pset.min 0
uint pset.max 2
string pset.comment
boolean pset.escapable false
uint pset.load 0
uint pset.size 0
string pset.poold.objectives locality tight; utilization < 80
pset tp_pset
int pset.sys_id 3
string pset.units population
boolean pset.default false
uint pset.min 2
uint pset.max 8
string pset.comment
boolean pset.escapable false
uint pset.load 0
uint pset.size 0
string pset.poold.objectives locality tight; 2: utilization < 80
cpu
int cpu.sys_id 1
string cpu.comment
string cpu.status on-line
cpu
int cpu.sys_id 2
string cpu.comment
string cpu.status on-line
pset db_pset
int pset.sys_id 2
string pset.units population
boolean pset.default false
uint pset.min 4
uint pset.max 6
string pset.comment
boolean pset.escapable false
uint pset.load 0
uint pset.size 0
string pset.poold.objectives locality tight; utilization < 80
cpu
int cpu.sys_id 3
string cpu.comment
string cpu.status on-line
cpu
int cpu.sys_id 4
string cpu.comment
string cpu.status on-line
cpu
int cpu.sys_id 5
string cpu.comment
string cpu.status on-line
cpu
int cpu.sys_id 6
string cpu.comment
string cpu.status on-line
pset app_pset
int pset.sys_id 1
string pset.units population
boolean pset.default false
uint pset.min 1
uint pset.max 2
string pset.comment
boolean pset.escapable false
uint pset.load 0
uint pset.size 0
string pset.poold.objectives locality tight; utilization < 80
cpu
int cpu.sys_id 7
string cpu.comment
string cpu.status on-line
pset pset_default
int pset.sys_id -1
string pset.units population
boolean pset.default true
uint pset.min 1
uint pset.max 4294967295
string pset.comment
boolean pset.escapable false
uint pset.load 0
uint pset.size 0
cpu
int cpu.sys_id 0
string cpu.comment
string cpu.status on-line
|
A graphic representation of the framework follows.

In the pool db_pool, the standalone database instance is guaranteed 75 percent of the CPU resource.