To zone, or not to zone: that is the question:
Whether 'tis nobler in the mind of the administrator to suffer
The slings and arrows of outrageous utilization,
Or to take arms against a sea of application consolidations

One of the most interesting (and often hotly debated) questions raised while planning the adoption of Solaris 10 is when to deploy applications in zones. You can almost hear Howie Mandel asking: zone, or no zone? Some early adopters of Solaris 10 didn't includes zones in their Standard Operating Environment (SOE) certifications, preferring to consider their use later after the new OS environments have been deployed and their comfort level with Solaris 10 improved. There is wisdom in this approach, but perhaps the time is right to reconsider this question.

As with any new technology there are trade-offs that should be considered before committing to a course of action. In the case of Solaris Zones, the considerations aren't quite as complicated as they may seem - in fact they can be reduced to the following question

1. Am I upgrading on existing hardware or installing on new hardware ?

This is the most important question, for several reasons. If you are going to upgrade to Solaris 10 from a previous release and not change the hardware then the most efficient method is to use . Create a new boot environment, install Solaris 10 in the new set of disk slices, and let Live Upgrade manage all of the details of the upgrade (users, file systems, network settings, etc). The upgrade can occur with the applications are running in the current environment, so there is little impact. The previous Solaris environment can be quickly restored if problems are discovered in the new Solaris 10 installation, so the level of risk is minimized.

At present, Live Upgrade is not supported on a system with local zones, but if you are coming from Solaris 8 or 9 you won't have local zones, so this restriction is rather moot. Conversely, if you are installing on new hardware then you won't be using Live Upgrade, at least not initially.

So if you are upgrading on existing hardware then don't deploy zones initially. Perform the upgrade (using Live Upgrade) and once the new environment has settled down, start planning the migration of the existing applications into a zone, at a time that is convenient.


2. Can the application run correctly in a local zone ?

The first question considered the most efficient approach, but we still must consider the feasibility of running applications in zones. And there are a few considerations.

Nonglobal zones have a reduced set of privileges that may cause some applications to fail. An example would be something like a DHCP server that requires raw IP access to communicate with systems that don't have IP addresses. Since this privilege doesn't exist in a local zone (at least until we get configurable privileges and per-zone IP stacks) then this type of application will not work in a local zone.

Some applications that don't appear to work with nonglobal zones may work with a little bit of creativity. An example would be the NFS server - it does work in a nonglobal zone. But that doesn't mean that you can't share data from a nonglobal zone, you just have to use the NFS server in the global zone. Use a writable loopback filesystem between the global and nonglobal zone and share the directory using an NFS server in the global zone. Users in the nonglobal zone can modify and share data, just as if NFS server were running locally. Another example would be a backup client. It may be unnecessary to run a backup client in a nonglobal zone since all files are visible from the global zone. This can also be true for performance data collectors, and actually an interesting design goal for intrusion detection.

And that's really about it. If the application can run in a nonglobal zone and it's convenient to do so, why not ? Let's hear the case of the single nonglobal zone arguments.

• Prosecution: You can't JumpStart a server with nonglobal zones.

Defense: It is true that the JumpStart installation environment doesn't have the services required to build and manage zones. But that doesn't prevent you from developing a simple first boot service to create an initial set of nonglobal zones. Leveraging SMF dependencies and service properties, you can leave a nice log file behind to record what was done during zone creation (artifacts that the scripts indeed ran as expected).


• Prosecution: It takes longer to patch a system with nonglobal zones.

Defense: That is true, but isn't it a really question of degree (ie, this is a civil case, not criminal)? With one nonglobal zone, the additional time required to patch the system is very small - and you can easily make the argument that if your maintenance window isn't large enough to support one nonglobal zone then it is really to small for even a global zone only installation.

But wait, there's more. With a nonglobal zone, it may be possible to have different patch levels or versions of applications. Zones are a user space abstraction so there's only one kernel (and devices), but it is possible to have different versions of nearly all of the user space components. Most applications are insulated from the kernel by libraries (such as libc), so this capability extends to applications as well as the basic OS components. The Branded Zones project in OpenSolaris extends this abstraction so that the user space components don't even have to be Solaris.


• Prosecution: Zones are more complicated to configure and administer.
  Defense: This simply isn't the case. Spend some time with the Zones in a Day workshop and you will see how to script the creation of a nonglobal zone. You will also notice that the zone configuration contains a small subset of all of the platform configuration elements - the nonglobal zone doesn't even contain it's own IP address. Details such as IP multi-pathing (IPMP) or IP Quality of Service (IPQoS) are inherited from the global zone and only need to be configured once on the system. It is certainly less effort to administer two nonglobal zones than two separate servers, and even in the one nonglobal zone case, it's about break even.
  
  From the viewpoint of an application, provisioning managers, such as Sun N1 Service Provisioning System, handle most of the platform details. Even for this form of automation, nonglobal zones represent the most efficient framework for provisioning applications. Reading the design documents for zone cloning and migration show that this will become even more efficient.
  
  It's time for the defense to present their case.
  
  
• Defense: Once you have one nonglobal zone, it's easy to add a second zone.
  The prosecution doesn't have much of a rebuttal. To consolidate future applications, existing applications deployed in the global zone would have to be migrated to a nonglobal zone, which requires a significant additional effort. If the applications are in production, this migration would be challenging and quite disruptive.
  
  
• Defense: All resource usage in a nonglobal zone can be measured.
  Again, the prosecution stays silent. A privileged (root) user can circumvent project level accounting, making it difficult to guarantee that all workload is identified in project level reporting. Nonglobal zones do not see their projects, nor do they have the administrative rights to modify the associated projects, even if they could be observed.
  
  
• Nonglobal zones can be covertly audited

As with the preceding argument, a local zone would have no visibility into intrusion detection and auditing being run in the global zone, specifically security logs. This makes it impossible to cover your tracks if you compromise a zone. In fact, the lack of visible intrusion detection might influence a hacker to stay around a bit longer and leave more evidence that will assist future forensic analysis.


• Defense: Zones and CPU pools may allow lower costs for software licensing.
  Many software partners, such as Oracle, consider the combination of processor pools and nonglobal zones as hard partitioning that may allow for the licensing of a subset of the available resources. Since the nonglobal zone lacks the privileges to change the processor pool configuration, even a rogue administrator or developer cannot invalidate the licensing that is being enforced from the global zone. Regular configuration audits are easy to run to insure future compliance.
  
  We haven't heard from the prosecution lately - are they still here ? Bueller ? Bueller
  
  
• Defense: A compromise in a nonglobal zone doesn't compromise another zone (global or nonglobal).
  The reduction of privileges in a nonglobal zone will prevent a compromise in one zone from affecting another zone. The only user space components that are shared between zones are file systems, and those can be protected somewhat by mount options (nodevice, nosuid, noexec). If a nonglobal zone is compromised, there is a limit on the promotion of privileges that isolates other zones from further compromises.
  
  The prosecution was last seen downloading the latest Software Express and working on a first boot service to create nonglobal zones after a JumpStart installation.

Technocrati Tags: Sun Solaris Zones