Solaris Containers

Solaris Containers or Solaris Zones Are the implementation of operating system virtualization for x86 and SPARC systems, which was introduced by Sun Microsystems as part of Solaris 10 in 2005. The designations container and zone are usually used interchangeably; strictly speaking, means only one zone with resource management (ie, limitation and distributed allocation of CPU, memory, and network) container.

Zones act within an operating system instance as completely isolated virtual servers. Be consolidated by groups of application service on a system and individually placed in insulated containers, system administrators can reduce the overall cost of a system and at the same time provide the protection mechanisms available for the otherwise separate machines would be required.

Terminology

There is always at least one zone, the so-called global zone. The other zones are managed by this hot and non-global zones. The term local zone has indeed naturalized, the manufacturer recommends but from their use.

The Global zone contains all processes of the system, even those that run in a non-global zone. The word zone is ( for example, in this article) often for non-global zone.

Description

Each zone is assigned its own hostname, virtual network cards, and memory. There is no requirement which hardware is assigned to the zone, except that required for storing the zone configuration of disk space. In particular, no dedicated CPUs, storage areas, physical network cards or host bus adapter must be assigned a zone, although this is quite possible.

Each zone is surrounded by a safety limit that prevents a process a zone with those of other interacting or watching it. Each zone can be configured with its own list of user accounts. Conflicts of numeric user IDs are resolved automatically by the system; for example, may each have defined a user with the ID 10000 two zones of a system; both would get an own global identifier in the overall system.

A zone can be assigned to a resource pool ( a number of processors and a priority class ), or their resource shares over the fair-share scheduling obtained. A zone may reside in each one of the following states:

  • Configured ( configured): The configuration is completed and saved
  • Incomplete ( incomplete): intermediate state during the installation or uninstallation
  • Installed ( Installed ): The packages are fully installed
  • Ready ( finished): The virtual platform is created
  • Running ( active): The zone is successfully up and running now
  • Shutting down ( the shutdown ): Between State: The zone is going down; the state ends in the down state.
  • Down ( off): intermediate state: The zone was completely shut down; the state eventually turns into Installed.

Some programs can not be run by non-global zones. Since a zone does not have a custom kernel ( in contrast to a virtual machine), applications that need to manipulate the system kernel or directly access the memory area of ​​the system kernel, do not run within a container.

Resource requirements

The additional load on the CPU and memory that emanates from the zones is very low. It may 8191 non-global zones are created within a single operating system instance. Sparse Zones, where the largest part of the file system contents with the global zone is shared can get by with only 50 megabytes of disk space. Whole Root Zones, where each zone has its own set of operating system files, can take between a few hundred megabytes to several gigabytes, depending on the software installed.

Even with whole root zones, the disk space required will be negligible if the file system of the zone is a ZFS Clone of the memory image of the global zone, since only those blocks that are different from the snapshot image, must be saved on the disk. This method also allows the creation of new zones in a few seconds.

Branded Zones

Although all zones use the kernel together, allow the Branded Zones (or BrandZ ) the system of zones that have a different operating system from the global zone. The supported types ( Brands) fall into two categories (as of October 2009):

  • Brands that do not require translation of operating system calls: native, the default for Solaris 10
  • Ipkg, the default setting for OpenSolaris
  • Cluster, which is used for Solaris Cluster
  • Labeled for zones on a Solaris Trusted Extensions environment
  • Solaris8 provides a Solaris 8 environment on a Solaris 10 system available (Only for SPARC systems only)
  • Solaris9 provides a Solaris 9 environment on a Solaris 10 system available (Only for SPARC systems only)
  • Lx provides an environment with Red Hat Enterprise Linux 3 on a Solaris 10 system is available ( only for x86 systems )
  • S10brand provides a Solaris 10 environment on OpenSolaris or Oracle Solaris 11 is available.

The brand of a zone is fixed at the time of their investment.

Restriction for NFS

The default NFS server from Solaris is implemented in the kernel and therefore can not be used for exports to non-global zones. NFS server by third parties that are not implemented in the Solaris kernel, but can possibly work.

Computer memory User identifier Pool (computer science) Fair-Share-Scheduling Network File System
201222
de