Introduction to Solaris Resource Manager

Organizational Goals It Addresses

IT organizations are often required to control costs and guarantee service levels for enterprise applications. Resource management can make it possible to lower overall total cost of ownership, have more accurate control over who uses the system and how they use it, and sometimes serve both goals.

By using Solaris Resource Manager software to categorize and prioritize usage, administrators can effectively utilize reserve capacity during off-peak periods, often eliminating the need for additional processing power.

By segregating workloads within the system, Solaris Resource Manager enables the system administrator to run and manage dissimilar applications on a single system, rather than dedicating an entire system-complete with peak capacity-to each application. Traditionally, the most common approach to ensuring predictable service and response time is to host one function per system. This method works, but the proliferation of systems in the data center is expensive and difficult to manage.

Solaris Resource Manager allows consolidation of several applications on a single UNIX® server, thus fully utilizing all available resources. At the same time, all users can receive resources commensurate with their service levels and the relative importance of their work.

Key Solaris Resource Manager Features

The following table identifies and briefly describes key system resource control features discussed in this manual.

When to Use Solaris Resource Manager

Solaris Resource Manager can provide effective resource control in a variety of situations including server consolidation, Internet Service Provider (ISP) web hosting, batch processing, administering sites with large or varied user populations, and establishing policies to ensure that critical applications get the response time they require.

Server Consolidation

Solaris Resource Manager is ideal for environments that are consolidating multiple applications on a single server. The cost and complexity of managing numerous machines encourages system managers to consolidate applications on larger, more scalable systems. With Solaris Resource Manager, it's easy to achieve these economies of scale.

As an example, a single Sun server could provide application, file, and print services for heterogeneous clients, messaging/mail service, web service, and mission-critical database applications. Since Sun Enterprise^TM servers scale from 1 to 64 processors, one server could be configured for several departments to share or for an entire enterprise to use. In other server consolidation efforts, the development, prototype, and production environments are combined on a single large machine such as the Sun Enterprise 10000 or Sun Enterprise 6500, rather than being hosted on three separate servers. Still other consolidation projects combine database and application servers within a single machine, or multiple data marts. Regardless of the application type or configuration, Solaris Resource Manager helps ensure that the system's resources are allocated among all users, applications, and groups according to the defined policy. Critical applications are protected because they are guaranteed the share of the available system resources they need.

Web Hosting

In the past, ISPs have had to assign dedicated machines to each client, at significant cost and complexity. With Solaris Resource Manager, an ISP can confidently host many (perhaps thousands) of web servers on a single machine. Solaris Resource Manager allows administrators to control the resource consumption associated with each web site, protecting each from the potential excesses of the others. It also prevents a faulty common gateway interface (CGI) script from exhausting CPU resources, or a user application from leaking all available virtual memory.

Batch Processing

Solaris Resource Manager can be used to prevent batch workloads from impacting ongoing business activities as well as other batch jobs running concurrently.

Large or Varied User Population

Solaris Resource Manager can help manage resources in any system that has a large and diverse user base, such as an educational institution. (In fact, Solaris Resource Manager has its roots in an early CPU resource scheduler developed at the Universities of Sydney and New South Wales.) Where there is a mix of workloads, the Solaris Resource Manager software can be configured to favor certain users. For example, in large brokerage firms, traders intermittently require fast access to execute a query or perform a calculation. Other system users, however, have more consistent workloads. If the traders are granted a proportionately larger amount of processing power, Solaris Resource Manager ensures that they will have the responsiveness they need.

Main Capabilities

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.

Processing Resources

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.

Allocating Resources

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.

Restricting Resources

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.

Relationship to Other Solaris Resource Control Features

The Solaris operating environment includes several other features that provide control over certain kinds of resources. Some features, such as real-time scheduling, nice(1), quotas, and processor sets, are part of the basic Solaris system.

Solaris Bandwidth Manager is a co-packaged software package, dynamic system domains are features of the Sun Enterprise 10000 system platform, and dynamic reconfiguration is a feature of the Sun Enterprise system platform.

All of these components offer types of resource management, but each differs from Solaris Resource Manager capabilities in some way.

• Real-time Scheduling

  The standard Solaris operating system uses the TS scheduling class for most conventional work, but it also offers real-time (RT) scheduling to users with sufficient privilege. The RT scheduling class implements a very different (and intentionally very weighted) scheduling policy to ensure that specific workloads or processes get immediate access to the processor.

  Solaris Resource Manager can coexist on the same system as the RT scheduling class, but it will have no control over any process running in the RT class. The Solaris Resource Manager fair share scheduler is able to manage the CPU time resources of only those processes that are not running in the RT scheduling class. For example, on a four-processor system, a single-threaded process can consume one entire processor; in fact, this is precisely what happens if the requesting process is CPU-bound. If this system also runs Solaris Resource Manager, regular user processes will be competing for the three CPUs not already being used by the real-time process. (Note that the real-time process might not use the CPU continually. When it is idle, Solaris Resource Manager will utilize all four processors.)

• nice(1) Command

  The nice command permits a user to manipulate program execution priority. Unless superuser privilege is invoked, this command only permits the user to lower the priority. This can be a useful feature (for example, when a user starts a low-priority batch job from an interactive login session), but it relies on the cooperation of the user. Solaris Resource Manager enforces administrative policies, even without the cooperation of the user.

• Quotas

  Solaris file systems have quota mechanisms that enable the administrator to restrict the disk consumption of individual users. This functionality is independent of Solaris Resource Manager.

• Processor Sets

  Processor sets were introduced in Solaris 2.6. This feature permits the administrator to divide multiprocessor systems into logical groups and permits users to launch processes into those groups. The advantage is that workloads running in one processor set are protected from CPU activity taking place in any other processor set. In some ways, this is similar to what Solaris Resource Manager does, but the two features operate on a completely different basis. Processor sets control only CPU activity. The control is at a relatively broad hardware level, because processors can belong to only one processor set at a time. Especially in the case of relatively small systems, the granularity may be quite high: on a 4-processor system, the minimum resource that can be assigned is 25 percent of the system.

  Solaris Resource Manager has much finer-grained control; each user is allocated a share of the system. The shares can be distributed arbitrarily on a fine granularity, and the scheduler will allocate resources accordingly. For example, if 50 shares are granted and one user has 40 of them, that user will get 40 / 50 = 80 percent of the resource. Similarly, if 67 total shares are granted, a user with 57 shares will get 85 percent of the resource. In addition, Solaris Resource Manager can control resources other than CPU. See The Role and Effect of Processor Sets for more information on the interaction of Solaris Resource Manager and processor sets.

• Dynamic System Domains

  The Sun Enterprise 10000 has a feature called dynamic system domains, which permit the administrator to logically divide a single system rack into one or more independent systems, much like the partitioning features available on mainframes. Each system runs its own copy of Solaris. For example, a machine with 32 CPUs on 8 system boards might be operated as 1 system with 16 CPUs, and 2 other systems with 8 CPUs each. In this configuration, three copies of Solaris would be running. Dynamic system domains also provide tools that manage the transfer of resources into and out of each copy of Solaris, thus creating a relatively broad facility for managing physical resources. (The minimum unit of inter-domain allocation is an entire system board.)

  Solaris Resource Manager is similar to dynamic system domains in that it also provides the administrator with mechanisms to allocate resources, but it does so in very different ways. Solaris Resource Manager runs within a single instance of Solaris, and provides a finer degree of administrative control over the resources in that system. Solaris Resource Manager can be used to segment resources among many users and applications in each instance of Solaris within a Sun Enterprise 10000 system and used in conjunction with dynamic system domains.

• Dynamic Reconfiguration

  The dynamic reconfiguration feature of Sun Enterprise servers enables users to dynamically add and delete system boards, which contain hardware resources such as processors, memory, and I/O devices. The effect of a dynamic reconfiguration operation on memory has no impact on Solaris Resource Manager memory-limit checking.

• Solaris Bandwidth Manager

  Solaris Bandwidth Manager is an unbundled package that works with the Solaris kernel to enforce limits on the consumption of network bandwidth. Solaris Bandwidth Manager is a form of resource management software that applies to a different class of resources. Solaris Resource Manager and Solaris Bandwidth Manager have different and separate management domains: Solaris Resource Manager operates on a per-user or per-application basis, while Solaris Bandwidth Manager manages on a per-port, per-service, or per-protocol basis.

Differences Between Solaris Resource Manager and Similar Products

The Solaris Resource Manager product is related to many other software components that might be present in the system, but it does not replace any of them.

• Solaris Resource Manager and Solaris Bandwidth Manager manage different types of resources.

• Solaris Resource Manager is not a system monitor in the sense that Sun Management Center is.

• Solaris Resource Manager is not really a capacity planning tool. While it helps the administrator manage capacity, and its accounting functions construct usage records that the administrative staff might use to do trend analysis, it does not do capacity planning in the traditional sense of the term.

• Solaris Resource Manager is not a job scheduler; it controls how a process runs on its host system, rather than when or where it runs.

• Because Solaris Resource Manager operates only on a single system, it is not a mechanism for implementing load balancing across cluster members. Solaris Resource Manager can be used effectively to manage workloads individually on each member of a cluster, however. For example, arrangements might be made to prioritize a workload from a failed member of a high availability cluster over a background workload running on standby member.