不看死不瞑目的文档 ：Solaris container - Introduction

Introduction

Today, businesses often design their systems with extra capacity to handle occasional peak loads to maximize revenue during periods of high demand. This extra system capacity remains unused during periods of normal demand. By allowing other applications to borrow this unused capacity a more cost-effective solution can be realized. During periods of high demand resources can be dynamically reallocated to important applications. Sharing resources in this way leads to higher resource utilization reduces capital and system management costs by reducing the total number of systems required. For the consolidation of applications onto fewer systems to be effective, applications must be able to be managed independently. This requires the ability to control resource utilization, isolate faults, and manage security between multiple applications on the same server. In other words, it requires

the establishment of virtual server boundaries within the server.

One of the first steps in this direction was the introduction of Dynamic System Domains on large Sun servers. With Dynamic System Domains, a server can be divided into several domains, each running its own copy of the Solaris OS. The domains provide hardware isolation between the applications so that faults in one domain do not propagate to applications in other domains. Domain boundaries can be dynamically partitioned to adapt to changing resource requirements. Resources can be moved from one domain to another without requiring a restart of the system. This adds flexibility to the data center while maintaining security and isolation from faults in other domains.

Starting with Solaris Resource Manager 1.x in the Solaris 2.6 OS, Sun has gradually enhanced the ability to control resource utilization and separate applications running in a single instance of the Solaris OS. Several technologies have been added to the Solaris OS over the years, providing additional capabilities and finer control over resource utilization. Examples of such technologies include the Solaris 9 Resource Manager and Resource Pools in the Solaris 9 OS. These technologies allow users to create a Solaris Container, an application or service that has one or more resource boundaries associated with it. These resource boundaries can limit CPU or memory consumption, network bandwidth, or even be a processor set. As a result, Solaris Containers are a prime enabler for server consolidation. With the introduction of Solaris Zones in the Solaris 10 OS, Sun is taking Solaris Containers a step further by allowing servers to be partitioned in sub-CPU granularity. A Solaris Zone is a complete execution environment for a set of software services — a separate, virtual Solaris Workload Resource Management environment within a Solaris instance. A Zone provides a virtual mapping from software services to platform resources, and allows application components to be isolated from each other even though they share a single Solaris OS instance. It establishes boundaries for resource consumption and provides isolation from other Zones on the same system. The boundaries can be changed dynamically to adapt to changing processing requirements of the applications running in the Zone.

Solaris Containers can be built using one or more the following technologies. These technologies can be combined to create Containers tailored for a specific server consolidation project.

1.        Solaris Resource Manager, for workload resource management

2.        Resource Pools, for partitioning

3.        Zones, for isolation, security and virtualization

It is important to note that a Solaris Container is not equivalent to a Solaris Zone. Zones technology can be used to create a Container with certain characteristics, such as the isolation provided by the virtual Solaris environment. But it is also possible to create another Solaris Container using Resource Pools technology if the required characteristics of that Container can be met with the features Resource Pools provide. So while a Zone is a

Container, a Container is not necessarily a Zone.

Workload Resource Management

One of the inhibitors for consolidating multiple applications onto a single server is the lack of control over the resources utilized by applications. Consider the example of a company that wants to consolidate two database servers onto one system to decrease the number of systems to manage, as well as the number of software licenses required.

The first database is used by an on-line sales application while the second database is used by a marketing application. Because the sales application supports the core business of the company, it should be guaranteed a certain minimum amount of CPU when needed. The marketing application is a supporting application, and the CPU requirements of the database server are much less stringent. Without a mechanism to enforce these requirements, these two applications cannot be consolidated successfully onto one system. With Solaris Containers, these business requirements can be implemented by establishing the appropriate CPU resource boundaries using the Fair Share Scheduler (Figure 2-1).

FIGURE 2-1 Solaris Containers provide an environment that fosters the safe consolidation of applications onto a single server

The Fair Share Scheduler controls the allocation of available CPU resources among workloads based on their relative importance. See Chapter 3 for more information on workload management and Chapter 4 for a hands-on example of workload management.

FIGURE 2-2 The Fair Share Scheduler ensures applications get the resources they need

Partitioning

In some cases a more strict separation of resource consumption may be required. For example, some applications may require a dedicated number of CPUs regardless of the processing requirements of other workloads. Furthermore, it may be desirable to restrict some applications to a maximum number of CPU resources as defined in a service level agreement. Dynamic Resource Pools can be used to provide this kind of partitioning.

In the example of the sales and the marketing database, two Resource Pools can be created: one with a large number of CPUs, and another with a small number of CPUs (Figure 2-3). The sales database would be assigned to the large pool and the marketing database to the small pool. The Solaris 10 OS adds the capability to dynamically adjust these resource allocations in response to application load changes in order to meet system performance goals set by administrators. See Chapter 5 for more information on dynamic resource pools, and Chapter 6 for an example of dynamic resource pools.

FIGURE 2-3 Resource pools can be used to partition resources

Isolation

Another inhibitor for consolidating applications is the lack of logical isolation between applications. This is of prime importance when the applications belong to different business units. Consider the example of an internal IT department acting as a service provider for a large corporation consolidating two workloads onto a single system. The IT department currently uses two systems, each dedicated to a single workload, since the workloads are from two different business units and each procured a system. Assuming the systems are currently under utilized, the organization wants to consolidate the applications onto a single system to achieve a more cost-effective solution.

However, both businesses object to sharing a system with another customer, as they are concerned about possible namespace conflicts, security issues, and administration conflicts. Solaris Containers make it possible to consolidate these workloads on one system by virtue of the namespace isolation, security and virtualization features of Solaris Zones By creating a Zone for each business unit, the IT department can effectively create two separate systems on one physical system. To each business unit it appears as if they have a dedicated machine. See Chapter 7 for more information on Solaris Zones and Chapter 8 for a practical example of using Zones.

FIGURE 2-4 Zones effectively create separate systems on one physical system

Solaris Container Evolution

With the release of the Solaris 10 OS the Solaris Container reaches the full functionality discussed above. However, much of the functionality discussed in this document can be used in earlier Solaris OS releases. Some Solaris Containers features, such as the Fair Share Scheduler, have been available since the release of the Solaris 9 OS. Prior to that release, a fair share scheduler was available in the form of the Solaris Resource Manager 1.x unbundled software for Solaris 2.6 OS and later releases. This means that much of the functionality discussed in this document can be equally used on these earlier platforms. Appendix A contains a list of Container features and indicates the Solaris OS version in which they were first released.

Document Approach

To see how Solaris Containers can be used for consolidating applications this paper presents several technologies that help organizations implement Solaris Containers:

Workload management

Resource pools

Solaris Zones

Each of these topics is discussed in two parts: a chapter that focuses on the concepts of the feature, followed by a chapter where the feature is used in a hands-on fashion using a simplified real world example. Readers that are interested solely in the concepts can skip the example chapters. By following the steps in the example chapters readers can recreate the examples on their own systems to experiment with a particular Solaris Containers feature. All examples can run on a uniprocessor system, with the exception of the processor sets portion of the resource pools example. This requires a multiprocessor system.