Virtuosity

In my last posting I wrote about the advantages of combining multiple applications onto a single server using lightweight Solaris Containers (aka Local or Non-Global Zones) versus the hypervisor approach. I really like that I can provision a new virtual OS environment in a few minutes with negligible overhead and have confidence my applications will perform well. I also like that I don't have to install, license and manage multiple complete OS stacks especially if I don't need to support different OS types on a given server. For a Solaris shop, using zones to deploy applications is an attractive option for safely increasing server utilization and also helps System Administrators become more aware of specific application requirements, both from a technical resource and an SLA perspective. A solid understanding of both are important in multi-tenant, virtualized environments.

Although zones provide all standard Solaris interfaces and don't impose any new ABIs or APIs, there are instances where some applications wont run in a non-global zone. Examples include applications which: depend on being an NFS server; use any network interfaces below TCP/IP; configure network interfaces; access /dev/kmem, create or manipulate /dev entries, etc. These situations are rare but to be safe I recommend candidate applications go through a qualification process to identify potential installation or runtime issues, especially if root permission is needed to install or run the application.

The Solaris 10 OS introduced Process Rights Management. Process Rights Management extends the Solaris process model through the use of Privilege Sets which control process access to system resources and kernel services. Local zones operate with a reduced set of process privileges relative to the global zone. As a result, all processes running in a non-global zone also have reduced privilege and certain system calls may return errors. Again, for the vast majority of data center users, developers and applications this reduced privileged environment is not a problem. On the contrary, because non-global zones are somewhat less capable than the global zone they provide an extra measure of protection. A malicious individual or virus that exploits an application vulnerability or otherwise gains "root" access to the local zone will find they can do much less damage than they could with similar access to a non-restricted host environment.

Again, 99% of Solaris applications, even older binaries built on previous Solaris releases, will run just fine in non-global zones but it pays to take the time to fully qualify new or migrating services before attempting a production deployment. Rather than replicate some excellent work on these topics I've provided some resources that will come in handy for ISVs and System Admins wanting to take a conservative approach to deploying their applications into Solaris zones:

• Bringing your Application into the Zone
• Qualification Best Practices for Application Support in Non-Global Zones
• System Administration Guide: Solaris Containers-Resource Management and Solaris Zones
• Zones and Containers FAQ at OpenSolaris.org
• Virtualization Blueprints at wikis.sun.com
• Wikipedia: Solaris Containers