Wednesday Nov 05, 2008

Messaging Server: Installing Multiple Instances

With the continued move towards using Solaris Zones for creating a Messaging Server installation of multiple instances, another approach to this situation might be getting lost in the mix. New in the Communications Suite installer (available with Messaging Server 6.3p1 and 7.0) is an "altroot" power user feature that enables you to install multiple instances of Messaging Server on the same host.

For more information, see the following document:

Performing Multiple Installations with an Alternate Root

A few caveats with this approach:

  • This feature gets limited operational testing, so we recommend field testing before deployment in your environment.
  • You have to configure the different instances to use different interfaces (for all the components) to prevent conflicts.
  • There are a few Messaging Server features that just won't work (for example, SNMP), and others that might require hand-editing to work (for example, SMF startup).
  • You need to understand the implications of altroot patching as well (it creates a SVR4 package/patch datastore separate from the main OS datastore for that information).

Hat tip CN

Wednesday Apr 11, 2007

Communications Software Summit, Part Deux: Comms Suite & Zones

Per my previous post, I described how the Comms practice recently held a Communications Suite Softwware Summit, and how I was going to summarize some of the talks that took place. So, here's our second installment, titled "Deploying Communications Suite in Solaris OS 10 Zones." (And a big thanks to Jhawk, from whom I am stealing this info outright.)


This summary covers:

  • Review of Solaris Zones
  • Using Zones with Communications Suite
  • Backing up and restoring Zones
  • Patching Zones
Review of Solaris Zones

A typical installation of the global zone resembles the following, consisting of two resources (NIC and file systems), and the Solaris packages:

Your data, including configuration and user/groups info, lives on the file system.

Sidebar: All systems that run Solaris 10 contain a master zone, called the global zone. The global zone is the original Solaris OS instance. It has access to the physical hardware and can control all processes. It also has the authority to create and control new zones, called non-global zones, in which applications run. Non-global zones do not run inside the global zone—they run along side it—yet the global zone can look inside non-global zones to see how they are configured, monitor, and control them.

Next comes the sparse zone:

This figure shows that the sparse zone is actually a sub-instance of Solaris, on Solaris. The sparse zone shares the same physical devices but contains a logical NIC (NIC:0). The sparse zone also shares some packages with the global zone (/usr, /platform, /sbin), and contains local copies of other packages (/opt, /var/opt, /etc). In the sparse zone, users and groups are unique but have global IDs.

After the sparse zone comes the non-sparse zone (also called the whole root zone), as shown below:

Here, all the Solaris packages are copied to the zone and not shared.

The advantage to the sparse zone is that it has a better security model. Also, some applications, such as Communications Suite, have problems with writing to a shared /usr. For such applications, you should use a non-sparse zone.

Sidebar: The non-sparse zone model provides maximum flexibility. All file systems are private to the zone. The advantages of this model include the capability for global administrators to customize their zones file system layout. This would be done, for example, to add arbitrary unbundled or third-party packages.

Why Use Zones?

Reasons include:

  • Easier installations and recovery. Have a problem that requires an OS reload? Just 'blow away' the zone and continue (rather than having to do it the old fashioned way of reloading the entire OS).
  • Provides better security on production systems.
  • Well suited for Communications Express and MMP/MTA installs.
  • Better control over Resource Pools . BTW, define a Resource Pool, even if you're not going to use it. Why? Enables better management of CPU and memory resources.

Where Not to Use Zones

  • Only available on SPARC/x86, so sorry Linux users, you're out of luck.
  • If you're requiring HA, it's possible, but requires special handling, so for now, for Comms, we're saying don't.
  • Systems with small disk space aren't going to work.
  • Best practice so far: don't use in your data centers.

Installing Communications Suite with Zones

Okay, now we're into the good stuff. In a nut shell, here's what we are recommending for Comms Suite and Zones:

  • Use the non-sparse zone for Java ES 2005Q4. In Comms 5, officially, we support sparse zones, though there are bugs (and workarounds).
  • First step on your Solaris-installed host: Run the Comms installer to install the shared components on the global zone, because there is a set of packages in /usr key to the rest of the installation. THIS IS THE KEY STEP.
  • Create your non-global zone.
  • From the created zone, run the Comms installer and install Comms Suite.
  • Lastly, you patch the installation with MS/CS/etc. patches. You need to patch shared components in the global zone (pkgadd -G) and individual components in the non-global zone (pkgadd).

Helpful Hint: Create your runtime users with unique UIDs. This enables you to track users from the global zone.

Backing up the Zone

Here I will cheat and let the preso do the talking:

For More Information

Deploying Sun Java Enterprise System 2005Q4 on the Sun Fire T2000 Server Using Solaris Containers

Solaris 10 Zones, Communications Suite 5 Installation Guide

Solaris Container Trick #1 : Monitoring Users Processes


Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.


« June 2016