Working with Solaris 10 Zones

Zones are a Solaris^TM Containers technology, introduced in Solaris 10, that provides separate operating environments on a machine and logically isolates applications from one another. Zones allow you to create virtual operating system environments within an instance of the Solaris operating system. Running applications in different zones allows you to run different instances or different versions of the same application on the same machine while, at the same time, permitting centralized administration and efficient sharing of resources.

Zone Basics

A zone environment includes a global zone and one or more nonglobal zones. When Solaris 10 is first installed on a system, there is only a single, global zone. An administrator can then create one or more nonglobal zones as children of the global zone. Each zone appears as an independent system running Solaris, with its own IP address, system configuration, instances of running applications, and area of the file system.

The global zone contains resources that can be shared among nonglobal zones. This allows the centralization of certain administrative functions: for example, packages installed in the global zone are available (propagated) to all existing nonglobal zones. This enables you to centralize life-cycle management like installation, upgrade, and uninstallation. At the same time, the isolation provided by nonglobal zones results in greater security and allows you to have differently configured instances or different versions of the same application running on the same machine.

Nonglobal zones are of two types: whole-root and sparse-root. Which of these you choose as an environment for an application depends on how you want to balance administrative control with resource optimization.

• A whole-root zone contains a read/write copy of the global zone’s file system. Packages installed in the global zone are automatically copied (with their registry information) to the whole-root zone. This maximizes administrative control at the expense of resource sharing.

• A sparse-root zone contains a read/write copy of a portion of the global zone’s file system; other file systems are mounted as read-only file systems. Packages installed in the global zone are available to the sparse-root zone by means of read-only file systems and through the automatic synchronization of registry information. Sparse-root zones optimize resource sharing at the cost of centralized administration.

Sun Java Enterprise System Zone Limitations

The components that make up the Sun Java Enterprise System (JES) depend on some shared components; this creates some limitations in working with zones. As a JES component, Message Queue is subject to these limitations. In a zone environment, shared components are governed by the following rules:

• All shared components within a zone must be of the same JES version. This requirement has three consequences:

  • If you want to install different versions of shared components, each version must reside in a separate zone.

  • Within a zone, if a shared component is upgraded or a later version is installed, then all shared components must be upgraded.

  • When you install shared components in the global zone, you must take care that shared components in nonglobal zones are upgraded if necessary.

• Shared components cannot be installed in sparse-root zones because of the read/only file system. Instead, they must be installed in the global zone. Those product components that depend on shared components must first be installed in the global zone and then propagated to nonglobal zones. In particular, since Message Queue is installed in the /usr directory, it must be installed or upgraded in the global zone first.

For more information on zones and their use in JES, see the following sources:

• Sun Java Enterprise System Installation Guide for UNIX, Chapter 2 (“Example Installation Sequences”), section “Solaris 10 Zones Examples”

• Sun Java Enterprise System Installation Planning Guide, Appendix A (“Java ES and Solaris 10 Zones”)

Message Queue Cases

When Message Queue is installed in the global zone, it is configured to propagate to all nonglobal zones. After installing Message Queue in the global zone, you will have the same version installed in all zones: if you log into any zone and execute the following command:

# pkginfo -l SUNWiqu

you will see the same version installed as in the global zone. You can then run independent instances of the Message Queue broker in each zone, since they do not share the instance and configuration data kept in the /var and /etc directories. Most other JES components are not propagated if they are installed in the global zone.

Because Message Queue is propagated to nonglobal zones, the global instance is forever linked to the installations in the nonglobal zones. Therefore, any time you uninstall or upgrade Message Queue in the global zone, it will affect instances running in the nonglobal zones. Always be aware of this cascading effect; the following example shows how it might cause unintended results:

1. You install Message Queue 4.3 in the global zone. This results in the Message Queue 4.3 packages also being installed in all nonglobal zones.

2. You uninstall Message Queue 4.3 in a whole-root zone.

3. You install Message Queue 3.7 UR1 in the whole-root zone. You now have different versions of Message Queue running in different zones, a configuration you might find useful.

4. You uninstall Message Queue 4.3 from the global zone. This will uninstall Message Queue from all other zones, including the Message Queue 3.7 UR1 instance in the whole-root zone.

The following two use cases show how to install different instances and different versions of Message Queue in different zones.

If you want to install Message Queue in a whole-root zone on Solaris 10, 10U1, or 10U2, you must upgrade Lockhart in the global zone first. See the workaround for bug 645030 for additional information.

To Install the Same Version of Message Queue in Different Zones

1. Install the desired version of Message Queue in the global zone.

   This version will be propagated to all existing nonglobal zones. If you create additional nonglobal zones, Message Queue will also be propagated to these zones. Note that you can install different instances in whole-root zones as well as sparse-root zones, but using sparse-root zones allows you to make more efficient use of disk space and other resources.

2. If you want Message Queue to be propagated to any other nonglobal zones, create these zones now.

3. Run an instance of Message Queue in each nonglobal zone.

To Install Different Versions of Message Queue in Different Zones

1. Uninstall Message Queue from the global zone.

   This will automatically uninstall it from all nonglobal zones as well.

2. Create whole-root zones and configure each zone not to share the /usr directory.

3. Install different versions of Message Queue in each whole-root zone.

   ---

   Note –

   Remember that later installing or uninstalling Message Queue in the global zone will affect all instances (and versions) running in whole-root zones.

   ---