N1 Grid Container Model

An N1 Grid Container is an abstraction layer that helps organize and manage the collection of physical system resources. The container enables the creation of a blueprint that details the resource requirements for an application. The resource requirements of the application are the focus of the N1 Grid Container model. This model focuses on the service or workload. The service is delivered by an application, which is a workload to the system. A workload is a set of associated processes, such as an executing application.

An earlier form of workload-based management was implemented in the Solaris Resource Manager 1.3 release. In that release, the workload was associated with the lnode. Container Manager software builds upon this earlier effort. The current container model provides a tool to help you organize and manage the ongoing delivery of resources for services. Common examples of services could be monthly payroll, customer order look-up, and web service delivery.

You need to be able to describe the environment that an application will be limited to when undergoing a server consolidation. Establishing this description enables you to move from having one application running per server to having many applications running on a single server. The container provides this description, as well as being its instantiation. A simple container could, for example, only describe system resources such as CPU, physical memory, and bandwidth. A more complex container could, for example, also control security, namespace isolation, and application faults.

The following illustration of an N1 Grid Container shows the relationship between services and resources.

Figure 1–1 Example of a N1 Grid Container

The box represents the container. Three kinds of resources are shown along the x, y, and z axes of the box that surrounds the service. In this model, CPU, Memory, and Bandwidth are fundamental resources. The service is bound by the box to represent how this service is contained by the container. For this release, Container Manager controls only CPU and physical memory resources.

Because Container Manager focuses upon the workload, the amount of resources used by an individual host is not monitored. The software instead monitors the amount of resources that is used by the service. In this model, a single instance of a service represents at least one process running on an individual host. The data is retained for possible system health monitoring and accounting purposes.

Figure 1–2 Example of Containers on a Host

More than one container can be active on an individual host at the same time. If multiple containers exist on a single host, you can set the boundaries of the containers so that the host can expand and contract them. In this case, resources that other containers are not currently using are available to a container that can use them. Ultimately, the number of containers that can be active on an individual host is determined by the amount of CPU and memory resources available, and how much of these resources each container reserves. The system must be able to meet the combined resource requirements of all the active containers, which are sized according to the needs of the applications.

For more information about managing containers with Container Manager, see Chapter 3, Managing Containers.