Just some thoughts on when you might want to use zone and some ideas of how to introduce zones into your environment and culture!
Solaris 10 containers is a new type of virtualization technology that can provide Solaris 10 customers with another choice for doing data center consolidation of your Solaris Operating Environment servers and services. Solaris 10 Containers can help you scale your services and improve system utilization by securely running multiple, software-isolated applications on a single system. Solaris Containers is composed of Solaris 10 Zones plus resource management. You can dynamically control application and resource priorities while improving resource utilization and reduce downtime, which in turn leads to lower solution costs.
Build customized, isolated zones each with their own IP address, file system, a single service or application, users associated with that service, and assigned resources to safely and easily consolidate systems.
Guarantee sufficient CPU and memory resource allocation to applications while retaining the ability to use idle resources as needed
Reserve and allocate a specific CPU or group of CPUs for the exclusive use of the zone, for example to limit licensing costs
Automatically recover from potentially catastrophic system problems by leveraging the combined functionality of Predictive Self Healing and Solaris Zones
When to deploy applications in Zones?
As with any new technology there are trade-offs that should be considered before committing to any course of action. In the case of Solaris Zones it is pretty simple and straight forward:
1. Are you upgrading on existing hardware or installing on new hardware?
If you are installing on new hardware, install the latest Solaris 10 Operating Environment as a normal and then create Non- Global Zones (NGZ) as required for each user land application and service. If you are going to upgrade to Solaris 10 from a previous release and not change the hardware then the most efficient method to upgrade is to use Live Upgrade (LU). Once the new environment is installed you will be running Solaris 10 Zones by default because your upgraded environment will be running the Solaris 10 Global Zone (GZ) with the default Solaris Resource Manager (SRM) resources. This also means that by default your applications will be running in the GZ.
Notes: A Solaris 10 Zones best practice is to run all user land services/applications (ie: Web, Database, etc.) each in their own NGZ and use the GZ primarily as a management zone only. So the next step after using LU is to create NGZ's and to migrate user land applications out of the GZ. Multiple services can be combined within a zone, if for example, their workload characteristics would benefit more from being within the same environment vs the benefits of isolation/security etcetera or if they must be within the same environment to function - ie: if they will not work on seperate servers, then they should be installed within the same zone, rather than separate zones.
2. What about moving my application from the Global Zone to running correctly in a Non Global Zone?
NGZ has a reduced set of privileges that may cause some applications to fail. Most user land applications will run in a NGZ. There are a few exceptions, and these are usually applications that try to talk directly to hardware, network devices or the kernel. All which if allowed would break the least privilege security model for zones. For example, a DHCP server, requires raw IP access to communicate with systems that don't have IP addresses. Since this privilege doesn't exist in a NGZ (at least until we get configurable privileges and per-Zone IP stacks planned in a future release of Solaris 10) then this type of application will not work in a NGZ. This can also be true for performance data collector agents.
3. What about the process of creating a zone and the time needed to create a zone?
The process of creating a zone is simple and straight forward. There are three kinds of zones, Sparse Root, Full Root, and customized zones that fall in between, basically the difference is the different degrees of sharing the file system from the GZ. A Sparse Root zone (the most desirable) is light weight and installs quickly because it basically runs a process that shares 4 existing GZ directories that are read only mounted from the GZ and copies very few files that add up to around 70Mb, which is roughly how much extra disk space is required to create a sparse zone (Oracle, for example, will install and runs well in a Sparse Root zone). The 4 directories inherited by Sparse Root zone that are shared from the GZ as read only are /usr, /lib, /sbin and /platform. A Full Root zone on the other hand is a copy of just about all the files in the GZ, which is usually greater than 3 GB). The best practice for creating zones is to create a sparse root zone when possible as it shares most of the operating system from the global zone through the use of the loopback filesystem (lofs) as read only mounts. Creating the sparse root zone usually takes less than 10 minutes to initialize the packages it needs for the new zone. A "verify" is run first to check that zone is configured correctly and it is ok, then run the install, and then boot the zone. Once we can see the sparse root zone is up and running, we can now login for the first time to the console of that zone and we can answer system identification questions to complete install. The system then reboots in a matter of seconds. All of this can be scripted. The main directories that are not lofs shared from the global zone are /etc and /var. Basically there are only 3 simple command to learn to create and manage zones: zonecfg, zoneadm and zlogin. Use zonecfg to create zone configuration files which include allocating system resources for zones; use zoneadm to install, uninstall, boot, halt and status zones; use zlogin to login to zone and manage via console.
4. What about migrating my application?
Majority of applications are simple and straight forward and do not require recompiling of any applications. The majority of applications do not try to directly manipulate hardware, network devices or the kernel and install normally without any problems. Installing applications in a NGZ is simple and works just as it did when you performed the install in the GZ. Once your applications are all migrated to their appropriate zones you will be able to manage these zones through a delegated admin for the individual zones or from the GZ or both, plus you gain all the benefits and features offered by using zones.
A Couple Zone Best Practices
Use Solaris 10 GZ as a management Zone only and install all user land applications each in their own Sparse Root NGZs
Try to Mix and Match NGZ's each runing different types of services that have different workload characteristics to get better efficiency & utilization on the same physical machine. (ie: different I/O patterns, different peak processing times, etc.)
Provide dedicated servers for dedicated services in NGZs
Things to think about when deploying zones
Sizing & Resource Optimization
Server Consolidation
Application Isolation
Rapid Application Deployment
Application Availability
Sizing & Resource Optimization
Solaris Zones can further enable customized security, performance or utilization requirements, through zone sizing. IT managers and system administrators also have the ability to run a zone bound to a specific set of CPUs. This ensures that applications assigned to these CPUs will have sole access to these resources and may benefit from lower licensing costs dependant on the application's licensing. (For example, Oracle licensing costs are lower using "Capped Zones" that only have access to run on a subset of the processors/cores physically installed on a given server).
Delegated authority model - Solaris 10 gives the main system administrator sole control to assign portions of a system's resources to specific isolated zones. While local administrators do not have global control, they do have control over the applications and environments within their assigned zone.
Fine Tune Performance - By allowing systems administrators to assign a zone to CPUs grouped on a single system board for example, Solaris 10 enables control over performance within the zone due to the locality between CPUs and their memory resources.
Server Consolidation
A primary objective of the Solaris 10 Operating System design is to deliver tools that help you do more with less by consolidating your applications onto fewer systems. Solaris Zones allow administrators to create multiple virtual environments on a single system so applications can safely run without endangering each other. As a result, companies can better consolidate applications onto fewer servers without concern for resource constraints, fault propagation, or security, making consolidation simple, safe, and secure. Administrators also gain tight control over allocation of system and network resources, significantly improving resource utilization.
Application Isolation and Managing Resources
With Solaris Zones, application(s) runing within that zone are running in their own private, isolated environment - separate from the underlying hardware - virtually eliminating error propagation, unauthorized access, and unintentional intrusions among Solaris Zones. Providing a fine granularity of control, Solaris Resource Manager enable administrators to ensure that all workloads have access to an appropriate amount of computing resources and that no workload is able to starve out other workloads unless authorized to do so. This resource management, called Solaris Resource Manager, uses the concept of Containers (introduced in Solaris 9) to group application(s) and resources. Solaris Resource Manager can be applied at the container level and/or at the Zone level (note that some Sun documentation, web sites, and personnel use the term Containers and Zones interchangeably, but they are different). Because resources are isolated and dedicated to a Solaris Zone and its applications rather than a complete system, highly efficient application consolidation is now possible. For example, Web servers typically listen to network port 80, and in order to do that they require root privileges, which entails a high security risk. To reduce these risks and run multiple Web servers per system, each Web server can run in a Solaris Zone and listen to its own unique port 80, operating in an isolated and secure manner.
Rapid Application Deployment
Developing new applications and services—and getting them operational as quickly as possible—can be a critical success factor for any business. Solaris Zones can speed application deployment by enabling applications to be developed, tested, and deployed on a single server without fear that they will impact one another. Private zone identities also make it possible to have multiple development versions of the same application on the same system. As a result, Solaris Zones can help lower costs by eliminating the need to purchase a new system for new releases or revisions. Multiple deployment scenarios can be tested with ease, and administrators can roll back to previous settings and configurations if needed.
Application Availability
As an increasing number of applications are consolidated onto a single server, the potential exists for underlying hardware or complex software problems to negatively affect a much wider range of users and services than in the past. In the case of an underlying hardware problem, the Predictive Self Healing functionality in Solaris 10 has been specifically designed to work with Solaris Zones to automatically detect and mitigate hardware problems before they occur. In the event of a complex software issue causing system and application availability issues, DTrace technology is Zone aware so it can view activities either in a Solaris Zone or across an entire system, giving system administrators the ability to determine the root cause of system issues as they happen (or proactively tuning an application) in real time on production systems.