February 22, 2019

Opening Solaris - page 4

The Solaris 10 Pitch

  • September 15, 2005
  • By Martin C. Brown

One of the most intriguing aspects of the Solaris 10 operating system is the functionality included in the system. The three main items, Solaris Containers, the Service Service Manager, and DTrace have spawned their own communities and discussions and for some these features along are enough to encourage them to switch to the Solaris operating system.

As computer power keeps increasing, the need for such power on an individual machine basis is beginning to decrease. Five or ten years ago it would be common to find an SME (Small to medium Enterprise) supporting a number of different servers, each one dedicated to its own task. Today, if the organization is operating in the same way it's likely the power of some of the machines is being underused. It's no wonder then that virtualization software such as VMware or Microsoft's Virtual Server/VirtualPC has become a popular way of sharing the power of a single machine through multiple virtual servers.

These solutions are fine, but they involve emulating a complete machine with its own operating system and often this means increased licensing costs in addition to the technical overhead of emulating a hardware environment for the sake of running software within a dedicated environment.

The Solaris Containers concept enables you to configure a container which will act as a completely separate instance of the Solaris operating system, but with a much lower overhead and a more configurable virtual environment. Unlike VMware or Virtual Server, we do not need a separate OS instance, but each container gives the impression of being a completely separate OS instance. Because a container is a separate instance we gain resource, fault and security isolation. A container is isolated both from the host operating system, and other containers.

For example, you can create a container which completely recreates the host environment. Or one that shares all the files from the host environment and just provides a separate execution environment. For secure environments, you can provide read-only partitions for critical filesystems; although technically shared with the host, from within the container the filesystems are completely protected.

A container could, for example, be configured to run the Apache web server. By carefully configuring the container parameters we could create read-only filesystems for all the files, applications, libraries and other components. Because the web application container would be read only it would be completely protected from hack attacks because, as far as the container's kernel is concerned all the filesystems are read-only. But, because we are sharing those filesystems from the host, updates and improvements could still be made to the web application by altering the files on the host, not the container.

Even further control of individual containers is provided by allowing you to specify the number of CPUs you would like to dedicate to individual containers. You can share one, or two, or all of your CPUs with individual containers, or provide a dedicated CPU for each container.

The only limitation of zones compared to VMware or VirtualPC is that the zones are also running Solaris--it's not possible to run an alternative OS within a zone. The benefits are the security, resource, and fault isolation and the significantly lower overheads; because each instance is not running the operating system there is no duplication of kernel or system interfaces, hardware drivers, or the virtual hardware environment that both VMware and Microsoft Virtual Server imply.

Most Popular LinuxPlanet Stories