Installing Communications Suite on Solaris Zones

Skip to end of metadata
Go to start of metadata

Installing Oracle Communications Unified Communications Suite on Solaris Zones
Version 7 Update 2

This information explains how to install Communications Suite on Solaris OS 10 Zones. For an overview of Solaris OS 10 with Communications Suite, see Overview of Solaris Zones.

Topics:

Installing on Solaris OS 10 Zones: Best Practices

You can install Communications Suite components in the global zone, whole root non-global zones, and sparse non-global zones. Follow these guidelines:

  • Treat the global zone as an "administration zone." Install shared components and OS patches in the global zone that are to be shared among all zones. However, do not install and run products from the global zone.
  • Use whole root non-global zones to run Communications Suite products. Do not use the global zone or sparse zones. A whole root zone can have versions that are different from other whole root zones, thus giving it a measure of being "self-contained".
  • There is one exception to the above two guidelines: install HA agents (MS_SCHA, CS_SCHA, IM_SCHA) in the global zone only. The Comms Installer automatically propagates HA agents to all non-global zones (i.e. the -G switch to pkgadd is not used for HA agents).

However be aware of the following aspects of zones:

  • You can have different shared component versions in the whole root non-global zone, but it isn't entirely insulated. If you do a packaging or patching operation in the global zone for a shared component, that operation is also attempted in the whole root zone. Thus, to truly have different shared component versions, use an alternate root.
  • To avoid affecting whole root zones you can attempt to never install and patch shared components in the global zone. However, it might not be realistic to never have to install or patch a shared component in the global zone. For example, NSS is a shared component, but it is part of Solaris OS. So to expect to never install and patch NSS in the global zone seems unrealistic, especially given it is a security component.
  • Although it isn't a recommended best practice, you can use Communications Suite products in sparse non-global zones. Do note that shared components cannot be installed into the default root because many of them install into the read-only shared file system (/usr). Thus, you must run the installer in the global zone to install shared components into the default root. Prepend your selection with ~ in the global zone to install only the dependencies (that is, shared components). You do not have to install in the global zone first before installing in the sparse zone. The installer allows you to continue even when you do not install all the dependencies. However, upgrading the shared components in the global zone affects the sparse non-global zones, thus requiring downtime for all affected zones simultaneously.

Installing into a Non-Global Whole Root Zone

The non-global whole root zone scenario is the equivalent of installing Messaging Server on a single box with no zones. Simply install Communications Suite as you normally would.

Caution
Any operations performed in the global zone (such as installations, uninstallations, and patching) affect the whole root zones.

Installing into a Non-Global Sparse Root Zone

Although it isn't a recommended best practice, you can use Communications Suite Products in a non-global sparse root zone. To install Communications Suite in a non-global sparse root zone, you first need to install/upgrade the applicable OS patches and shared components in the global zone. You are unable to do so in the sparse root zone, because the /usr directory (where the shared components reside) is a read-only directory in the sparse root zone.

  1. Follow pre-installation requirements as described in Installation Overview.
  2. Verify that you are about to install the shared components and OS patches in the global zone and not the sparse root zone. To verify you are in the global zone, run zonename. The output should be global.
  3. Run the installer in the global zone and only install/upgrade the OS patches and the Shared Components. Do not install Communications Suite components in the global zone. To do this, add a ~ (tilde) to the component number you want to install in the sparse zone.
    For example, if you plan to install Messaging Server in the sparse zone, you select ~1 during the global zone installation. The installer will know to only install dependencies and not the product itself.
  4. Once you have the shared components and OS patches installed, install Communications Suite components in the sparse root zone.

Guidelines for Using SunCluster HA Packages in a Non-Global Zone

The HA agents (MS_SCHA, IM_SCHA, and CS_SCHA) should be installed in the global zone only. The Communications Suite Installer will propagate the installation of the HA agent to all non-global zones. This is required since the version of the HA agent must be identical on all zones.

Take the following steps to install the Communications Suite 7 Update 1 Sun Cluster HA agent in non-global zones:

  1. Run the Communications Suite command in the global zone only:
    # commpkg install
    

    This command installs the Sun Cluster HA Agent package on global zone and all non-global zones.

  2. If you have sparse zones that need the HA agent, run the Sun Cluster HA Agent initial configuration command in the global zone:
    # <scha_base>/bin/init-config
    
  3. In the whole root zones where you are going to use the HA agent, run the Sun Cluster HA Agent initial configuration command in the global zone:
    # <scha_base>/bin/init-config
    
Labels:
installing installing Delete
zones zones Delete
commsuite commsuite Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.