This chapter reviews the resource management framework and describes a hypothetical server consolidation project.The following topics are covered in this chapter:Configuration to Be Consolidated Consolidation Configuration Creating the Configuration Viewing the Configuration 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 that has the resource pools and the dynamic resource pools facilities enabled.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.hostMake the configuration active.# pooladm -cThe framework is now functional on the system.Enable DRP.# svcadm enable pools/dynamic:default 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-lineA graphic representation of the framework follows.

Illustration shows the hypothetical server configuration.

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