Communications Software Summit, Part Deux: Comms Suite & Zones
By Joesciallo-Oracle on Apr 11, 2007
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
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?
- 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