Resource Management

Generally, a resource represents a process-bindable OS entity. More often, a resource refers to the objects constructed by a kernel subsystem that offers some form of partitioning. A resource can also considered an aspect of the computing system that can be manipulated with the intention of affecting application behavior. Examples of resources include physical memory, CPUs, or network bandwidth.

Container Manager works with resource management utilities in the Solaris 8, Solaris 9, and Solaris 10 releases. In the Solaris 8 release, resource management is provided by Solaris Resource Manager 1.3. Every service is represented by an lnode. The lnode is used to record resource allocation policies and accrued resource usage data. lnodes correspond to UNIX user IDs (UIDs). The UID can represent individual users and applications by default. For more information about lnodes and resource management, see Limit Node Overview in Solaris Resource Manager 1.3 System Administration Guide

In the Solaris 9 and Solaris 10 releases, resource management is provided by the Resource Manager. In this release, the project is similar to the lnode. A project provides a network-wide administrative identifier for related work. All the processes that run in a container have the same project identifier, also known as the project ID. The Solaris kernel tracks resource usage through the project ID. Historical data can be gathered by using extended accounting, which uses the same tracking method. In Container Manager, the project represents the container.

Figure 1–3 Example of Projects on a Host

Information about the processes that run in a container is obtained from the Container Manager GUI. The gathering of data is transparent to you as you create and manage containers by using the software.

Different methods can be used to create container boundaries. One method is to partition the system by using resource pools. Another method is to establish limits on the project through resource controls.

Resource Pools

A resource pool, or pool, is a Solaris 9 and Solaris 10 software configuration mechanism that is used to partition the resources of a host. A resource set is a process-bindable resource. Memory sets and processor sets are examples of resource sets. Only processor sets are currently available in the Solaris 9 and Solaris 10 release. A pool binds the various resource sets that are available on a host.

A resource pool can hold one or more projects. In the case of one project, the resources that are linked to the pool are dedicated to that project. In the case of multiple projects, the resources that are linked to the pool are shared with the projects.

On the Solaris 10 Operating System, the product has a feature called dynamic resource pools. The dynamic resource pools help you obtain better performance by enabling you to adjust each pool's resource allocations in response to system events and load changes. This feature is described in Dynamic Resource Pools.

When running on the Solaris 8 Operating System, a host can have only one resource pool. This pool is called pool_default. Because resource pools do not exist in this OS version, the pool_default is created artificially. All of the CPUs on a host that run the Solaris 8 release are considered to be in a single pool by convention.

For more information about managing resource pools with Container Manager, see Chapter 5, Managing Resource Pools.

Resource Controls

In the case when more than one project is bound to a single pool, you can set guarantees, or limits, on a single project. These limits are called resource controls. An example of a control is the setting of a minimum CPU limit, as in the case of using the fair share scheduler (FSS). Another example is the setting of a physical memory cap, as in the case of using the rcapd daemon. When setting a minimum CPU guarantee, the idle CPU cycles in one project can be used by the applications in the other projects.