Solaris 10 Zones

This section contains a brief description of Solaris 10 zones support for the current release of Communications Suite. An installation sequence example is included. The following topics are addressed in this section:

• Overview of Solaris Zones

• Zones Support for This Release of Communications Suite

• Solaris 10 Whole Root Zones Example

• Solaris 10 Sparse Root Zones Example

Overview of Solaris Zones

The Solaris 10 zones (also known as Solaris containers) feature provides a means of creating virtualized operating system environments within an instance of Solaris OS. This allows one or more processes to run in isolation from other activities on the host. For example, a process running in a zone will only be able to send signals to other processes in the same zone, regardless of user ID and other credential information.

Every Solaris 10 host contains a single global zone. The global zone is both the default zone for the host and the zone used for system-wide administrative control. All processes run in the global zone if no non-global zones are created by the global administrator. Some product components, such as Sun Cluster software can only be installed in the global zone. A non-global zone can be thought of as a box. One or more applications can run in this box without interacting with the rest of the host. Each non-global zone has what appears to be its own instance of an installed Solaris 10 operating system with configuration and other information unique to that non-global zone. The default configuration for a non-global zone is to share portions of its file system with the global zone. Propagation provides non-global visibility and availability to packages that are installed in the global zone.

There are two types of non-global zones supported: whole root zone and sparse root zone. A whole root zone contains a read/write copy of the file system that exists in the global zone. When a whole root non-global zone is created, all packages that are installed on the global zone are made available to the whole root zone. A package database is created and all packages are copied onto the non-global zone, creating a dedicated and independent copy of all files.

A sparse root zone contains a read/write copy of only a portion of the file system existing on the global zone, while other file systems are mounted read-only from the global zone as loopback virtual file systems. The global administrator selects which file systems to share with a sparse root zone at the time the sparse root zone is created. Regardless of zone type, when a package is added to the global zone it is, by default, propagated to all non-global zones. In other words, the package is installed in the global zone as well as all non-global zones. This propagation behavior can optionally be suppressed when the package is added, thus restricting the package to the global zone only.

For your zones deployment to succeed, it is crucial that you plan the tasks and sequence of those tasks very carefully. Communications Suite components can potentially be installed in any of three types of zones in an almost unlimited set of combinations, and in almost any order. In some cases, the order in which Communications Suite product components are installed, and the order in which non-local zones are created, can be very important. For a full description of planning for using Communications Suite in a Solaris zones environment, refer to the Sun Java Enterprise System 5 Installation Planning Guide.

Zones Support for This Release of Communications Suite

The following list describes the level of zones support for this release of Communications Suite:

1. Both whole root zones and sparse root zones are supported.

2. Communications Suite can be installed in the global zone when non-global zones already exist.

3. Non-global zones can be created after Communications Suite is installed in the global zone.

4. Communications Suite can be installed in the global zone even when Communications Suite has already been installed in the whole root non-global zone. Also, Communications Suite can be installed in a whole root non-global zone even if another Communications Suite installation is already installed in the global zone.

5. All shared components in a zone must be from the same release of Communications Suite. Shared components are automatically synchronized to match the most recent Communications Suite release.

6. Whole root and sparse root deployments of Communications Suite should not be mixed on a single computer.

7. Communications Suite can be installed into non-global sparse root zones with the following exceptions:

   • Sun Cluster software, Sun Cluster Geographic Edition, and Sun Cluster Agents can only be installed in the global zone.

   • Message Queue can only be installed or upgraded in the global zone, or in a whole root non-global zone.

   • Before Application Server can be installed into the non-global sparse root zone, any version of Application Server that is bundled with the operating system must be removed from the global zone.

   • The installer does not install shared components or Message Queue into sparse zones. If you attempt to do this, installation halts and you receive a message telling you that shared components and Message Queue must bed installed in the global zone.

8. The installer controls propagation of the packages it installs in the global zone:

   • Shared components always propagate.

   • Message Queue always propagates.

   • All other product components never propagate.

9. The Sun Java Web Console shared component can only be upgraded in the global zone.

Solaris 10 Whole Root Zones Example

This is an example of installing Communications Suite software in a Solaris 10 whole root non-global zone.

To Develop a Sequence for Solaris 10 Zones (Whole Root)

The following high-level tasks are required:

1. Verifying that Solaris 10 is installed on your host

   The global zone is automatically created.

2. Verifying that all the non-global zones specified in your implementation plan have been created by the global zone administrator as “whole root” zones

   For information on creating non-global zones, refer to Chapter 18, Planning and Configuring Non-Global Zones (Tasks), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

3. Starting the installer in the global zone, and selecting only shared components at component selection.

   Select only Shared Components at component selection; no other components should be selected. When shared component installation is complete, the shared component are in the global zone and are also propagated to all non-global zones.

   ---

   Note –

   Shared components can be installed into a whole root local zone with the exception of Sun Java Web Console. If the installer detects a bundled version of Sun Java Web Console, you cannot proceed until Sun Java Web Console is removed or upgraded from the global zone.

   ---

4. Checking the installation sequence guidelines

   Check to see what guidelines apply to this example and make adjustments as needed.

5. Checking the installation prerequisites

   Check to see what tasks you might need to perform for this installation before starting.

6. Starting the installer in the desired non-global zone

7. At component selection, choosing the components you want

   Some components cannot be installed in a non-global zone because they require access to global zone capabilities. These components are unavailable at component selection.

8. Running the installation

9. Viewing the Installation Summary and Log

10. Completing postinstallation configuration as needed

    Chapter 6, Completing Communications Suite Postinstallation Configuration provides post-installation configuration instructions.

11. Starting product components

    Chapter 7, Verifying Installed Product Components provides procedures for starting and stopping the product components.

12. Repeating this process in additional non-global zones as needed

Solaris 10 Sparse Root Zones Example

This is an example of installing Communications Suite software in a Solaris 10 sparse root non-global zone.

To Develop a Sequence For Solaris 10 Zones (Sparse Root)

1. Verifying that Solaris 10 is installed on your host

   The global zone is automatically created.

2. Verifying that all the non-global zones specified in your implementation plan have been created by the global zone administrator as “sparse root” zones

   For information on creating non-global zones, refer to Chapter 18, Planning and Configuring Non-Global Zones (Tasks), in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

3. Checking the installation sequence guidelines

   Check to see what guidelines apply to this example and make adjustments as needed.

4. Checking the installation prerequisites

   Check to see what tasks you might need to perform for this installation before starting.

5. Starting the installer in the global zone, and selecting only shared components at component selection.

   Select only Shared Components at component selection; no other components should be selected. When shared component installation is complete, the shared component are in the global zone and are also propagated to all non-global zones.

6. If Message Queue is being used, upgrading Message Queue in the global zone

   Message Queue comes bundled with Solaris 10 and an incompatible version must be upgraded or removed. After upgrade, Message Queue is in the global zone and is also propagated to the non-global zones.

7. If Application Server is being used, Application Server must be removed.

   Application Server comes bundled in Solaris 10 and must be removed from the global zone. Use the pkginfo —I | grep —I “application server” command to list the Application Server packages that are on the host. After removing the Application Server packages, Application Server can be installed with the other product components in the non-global zone.

8. Starting the installer in the desired non-global zone

9. At component selection, choosing the components you want

   Some components cannot be installed in a non-global zone because they require access to global zone capabilities. These components are unavailable at component selection.

10. Running the installation

11. Viewing the Installation Summary and Log

12. Completing postinstallation configuration as needed

    Chapter 6, Completing Communications Suite Postinstallation Configuration provides post-installation configuration instructions.

13. Starting product components

    Chapter 7, Verifying Installed Product Components provides procedures for starting and stopping the product components.

14. Repeating this process in additional non-global zones as needed