Solaris Resource Manager provides the ability to administer the consumption of various important resources in the system, such as processor time, virtual memory, process count, login control, and connect-time. The Solaris Resource Manager administrative model adds flexibility by permitting the delegation of administrative rights within a hierarchy, relieving the data center staff from the need to be involved in intra-group administrative transactions. In addition, Solaris Resource Manager provides mechanisms for collecting resource usage data that can be applied to capacity planning or chargeback purposes.
One of the fundamental jobs of the operating system is to arbitrate which processes get access to the system's resources. The default Solaris timeshare (TS) scheduler tries to give every process relatively equal access to the system's resources. Limitations on access are applied to processes without physical memory resources, which are not permitted to run, and processes with pending I/O requests, which are blocked.
This scheme is the basis for most modern operating systems; it works well as long as "equal access for all" is a suitable policy for the organization. However, more sophisticated mechanisms are needed to implement different policies. For example, a manufacturing department might own a large system that is usually used lightly because of fluctuating seasonal demand. At the same time, the engineering department almost always needs more computational cycles. Although it is wasteful to underuse a large machine's resources, sharing the manufacturing system with engineering has traditionally been problematic. With simple scheduling policies, there is no way to express to the operating system that the manufacturing department's users are more important than the engineering users on the same system. If manufacturing has a critical job running that consumes 75 percent of the system's resources, the job will make suitable progress if all other jobs request 25 percent of the system or less. However, if an engineering job arrives that demands 50 percent of the system, that critical manufacturing job will likely not get what it needs to maintain adequate headway because the system will try to accommodate both jobs on an equal basis.
Now assume that the administrator determines that manufacturing's normal processing requirements can be met with 80 percent of the machine's capabilities. Using Solaris Resource Manager, the system administrator can specify that the manufacturing department's users can have up to 85 percent of the system's processing capability if they request it, and the scheduler will apportion the remainder to any other user. A more extreme but equally valid configuration might specify that manufacturing users can have up to 100 percent of the system if necessary, effectively preventing any other group's processes from running in the event that manufacturing really needs the entire system.
Solaris Resource Manager has a CPU scheduling class that replaces the standard timesharing scheduler. Called the SHR scheduler, this module implements what is called a fair share scheduler. The term is something of a misnomer, because it is the system administrator who specifies what "fair" means. In the example above, "fair" meant that manufacturing could get 100 percent of the system. The SHR scheduler is responsible for allocating resources according to the plan laid out in the administrative profile.
Solaris Resource Manager maintains a database of resource usage and associated limits.
The SHR scheduler takes into account the administrative specification for resource guarantees. It is capable of managing resources that are renewable (such as CPU time) or fixed (such as number of processes).
Other Solaris Resource Manager modules implement restrictions on the consumption of various resources. For example, connect-time and user logins are managed by a Pluggable Authentication Module (PAM). The PAM module consults the Solaris Resource Manager database each time a user attempts to log in. Once the system authenticates the user (generally through password matching), the user's connect-time and number of current logins are checked against the limits. The login is rejected if either limit is exceeded.