Solaris Resource Manager Basics : Understanding Resource Pools

What is a resource pool

– Resource pools provide a mechanism for partitioning a system into persistent processor sets with optional scheduling class assignments.
– The real power of resource pools is realized when projects are associated with pools. Remember that a project can be viewed as an aggregation of related tasks that collectively represent a workload.
– A pool can have one or more projects assigned to it. Priority of the projects within a pool can be determined using the FSS scheduler. – The FSS scheduler determines the relative priority of processes via CPU shares. Priority of projects within a pool can be assigned via CPU shares.

Administration

There are two basic ways to administer resource pools. The first is through the Command Line Interface (CLI). The CLI is comprised of three commands:

pooladm – Activates a configuration or deactivates the current configuration. Without options, it also prints the current configuration.
poolbind – Binds projects, tasks and processes to a pool.
poolcfg – Creates and modifies the pools configuration file. It can also display the current configuration.

The default configuration file for pools is /etc/pooladm.conf. There are basically three things listed in this file:

system – This is the machine-level entity which represents the entire system.
pset – This is a processor set.
pool – This is a named collection of resources (processor set and/or scheduling class assignment).

If this file exists at boot time, pooladm is invoked to activate the specified configuration. Alternatively, any valid configuration placed in an arbitrary file via the poolcfg command can be activated manually with the pooladm command.

There are two ways in which poolcfg creates a valid /etc/pooladm.conf file. The first is using the ‘discover‘ option. In this case, all components and resources (system, pool, pset) in the system are recorded. This is the simplest way to create an initial configuration file. Here is an example:

# poolcfg -c discover

The configuration can then be modified with the poolcfg file. The second way to create a valid configuration file is using subcommand arguments to poolcfg. Here is an example:

# poolcfg -c 'create system dev'

The basic flow of operations in defining a pool is to create a system, create processor sets, create pools, optionally assign scheduling classes to pools (one class per pool) and then associate a pool to a processor set. Here is an example using a command file with poolcfg:

# cat > poolcmds.txt
# create system dev
# create pset web (int pset.min = 1; int pset.max = 4)
# create pset db (int pset.min = 2; int pset.max = 4)
# create pool web
# create pool db
# modify pool web (string pool.scheduler="FSS")
# associate pool web (pset web)
# associate pool db (pset db)
# poolcfg -f poolcmds.txt

As mentioned in the overview, the real power of pools comes into play with projects. One or more projects can be assigned to a pool to guarantee certain resource levels to workloads. Projects can be bound to pools automatically through the project database or manually with the poolbind command. Here are examples of both:

Automatic – Here is the project database.

user.user01:1000::::project.pool=web,project.cpu-shares=(priveleged,1,deny)
user.user02:1001::::project.pool=web,project.cpu-shares=(priveleged,2,deny)
user.oracle:1002::::project.pool=db

By default, processes owned by user01 and user02 will run in the web pool and oracle processes will run in the db pool. user02 is guaranteed twice the CPU resources as user01.

Manual – Bind processes owned by jpb to the db pool.

# poolbind -i project -p db user.jpb

Conclusion

The resource pools framework provides a powerful mechanism for separating a system into independent partitions through the use of processor sets and scheduling classes. Combining pools with projects enables administrators to easily guarantee resource levels to workloads. Pools even work with Dynamic Reconfiguration (DR). If the DR operation requested keeps the current pools configuration valid, the DR operation succeeds. Alternatively, if the operation would invalidate the active configuration, it fails with a message to the log. You can force the DR operation (using the appropriate option) in this case to proceed which also cause the pool configuration to comply.