By Jeff Victor on Dec 20, 2006
I hate computers. No, that's not true. They hate me. Probably because I derive pleasure from pushing them to the hirsute edge of their design specifications. They interpret this as sadistic behavior, and think that I am mean for no reason. But that's not true. I have a reason.
Actually, I have two reasons:
- I am curious, and enjoy measuring things
- I want to help you understand the limits of Solaris so you can safely maximize the benefits you obtain from using it, without performing all of these measurements yourself.
Over the past few weeks I have wondered how realistic Solaris' upper bound of 8,191 non-global zones (per Solaris instance) is. So I "acquired" access to a Sun Fire X4600 which has a pre-release build of Solaris on it. This build includes several useful features from Solaris 10 11/06 including:
- zone migration: the ability to move a non-global zone from one computer to another
- zone clone: make an identical copy of an existing non-global zone
- integration of zone clones and ZFS clones, enabling incredibly efficient cloning of zones.
The efficiency extends to both time and space. Originally the only method to create a copy of a zone was configuring a new zone like an existing zone and installing it. This operation took 10-30 minutes, depending mostly on disk speed, and did not include any customizations made to the original zone after it was installed.
Spawn of Non-global Zone
The newer "zone clone" method is a vast improvement because it simply copies the files from the original zone to the new zone. This is much faster (2-5 minutes) and carries with it any post- installation customizations. This method, along with other new features in Solaris 10 11/06, enables a new method of provisioning virtual Solaris systems. I call this new method 'spawning a zone.'
Suppose that your data center uses five applications, but multiple computers run each application for different purposes. These might be test and production systems, for example. Each system that runs the same application has the same set of customizations applied to it.
Many data centers simplify the provisioning process by creating, testing, and internally certifying one or more Solaris bootable images, called 'gold masters,' which are then installed on their systems. This also simplifies troubleshooting because it removes the need to analyze a troubled system for customizations. In some cases, system administrators are specifically trained to troubleshoot systems installed with a gold master.
Solaris zones can be applied to this model by creating a gold master Solaris image that has "gold master zones" pre-installed on it. Each zone is customized for one of the five applications. After a new system is installed from the gold master, only the zone(s) customized for the applications that will be used by this computer are turned on. The rest are left off, merely using up a few hundred megabytes of disk space.
That model is simple and very useful, but often is not flexible enough. For example, it does not allow for multiple instances of one application on one system, each in separate zones.
Instead, a "gold master system" could be created that has one "gold master zone" installed per application, with appropriate customizations made to each zone. When an application is needed on a new or existing system, application provisioning includes these steps:
- clone a gold master zone
- migrate the clone to its new home system (also see my
To Guide on this topic)
- "zoneadm detach" the zone from the old system
- move the zone's files to the new system
- "zoneadm attach" the zone to its new system
- destroy the detached zone on the gold master system
The new, recently migrated zone can then be further customized. If conditions change, and you want to move it to a different computer, you can do that, too.
Part 1 - Summary: Well, this has gotten a bit long-winded, but the explanation in this entry provides the background necessary to understand the next entry, which in turn (finally!) explains this entry's title.