An Oracle blog about Openomics

  • sun
    February 3, 2011

Why Solaris Zones?

Guest Author

Our recent validation exercise of SAP NetWeaver Master Data Management on Oracle Solaris Containers reminded us how great a virtualization technology Solaris Zones are. Why am I saying this? Read on.

Starting with Solaris 10, Solaris Zones (a.k.a. Containers) are an operating system level virtualization technology that provides a complete, light-weight and secure run-time environment for applications. Compared to other virtualization solutions, Zones do not use an
hypervisor --which in fact is another layer of operating system that translates / gets in the way of your system calls to the hardware--, rather Zones are an integral part
of a running Solaris instance. Still, Zones meet the same business objective of server consolidation thru Virtual Machines (VM), isolated from each other and designed to provide fine-grained control over the hardware resources.

The following benefits are often put forward about Solaris Zones :

  • Performance : Zones are very light-weight as they do not each run their own Solaris kernel nor involve an hypervisor. Every CPU cycle is spent in useful work, towards running the applications.
  • Platform Choice : Zones are not limited to Intel-based servers. They are supported on all hardware platforms that are supported by Solaris 10 (and up), e.g. SPARC M-Series, SPARC T-Series, Oracle Engineered Systems (unless specified otherwise). They even run on top of / inside Solaris Domains.
  • Price : as an integral part of Solaris, no additional software needs to be purchased nor installed.

But this is not why Zones are great. What is it then? Ease of Use / Manageability.

Here are a couple of scenarios from our daily lives working with ISV.

At development time... One can create (and keep over time) many VM based on the exact same Solaris installation and patch level; this is in fact the default behavior of Zones. When working collaboratively, making sure that everyone is testing --reproducing a bug e.g.-- on identical environments can be a major source of headaches. If everyone is accessing his own Zone on the same Solaris box, they can be sure, while being isolated from each other and keeping the ability to reboot their own VM e.g., that they will be working on the exact same environment and that a patch will be applied to everyone at the same time, when it is needed / performed. Many of the ISV we work with have adopted the Zones technology to give all developers a Unix environment (out of a single Solaris box) to compile and test the code they increasingly develop on Wintel laptops.

At deployment time...  Again in its default behavior, dynamic resource allocation is applicable to all Zones. One does not need to specify a dedicated amount of CPU or memory in order to define or run a Zone-based VM. This way, peaks of resource requirements due to changes in the application workload can be satisfied on the fly by Oracle
Solaris itself without a sysadmin intervention; Solaris simply allocate all CPU and memory needed
and available automatically --just as in a traditional timeshare environment. Of course, it is possible to configure Zones to cap hardware resources to protect other Zones and maintain whatever SLA. Because of dynamic resource allocation, any developer like SAP here can give straightforward deployment recommendations for its users to consolidate multiple parts --or multiple instances, in a horizontal scalability scheme-- of the application without entering into the sysadmin dimension of things.

Still not using Zones yourself today? Give it a try. The whitepaper mentionned in the introduction recaps on Page 13-14 the few command lines needed to create a Zone. For the full documentation, check out the Solaris Containers Administration Guide.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.