By unixman on Aug 11, 2007
Last week I had an opportunity to meet with and present to one of our interesting financial customers (who will remain nameless for non-disclosure reasons). Subject of the meetings had been Solaris, virtualization, container management, processor roadmap discussions (and so forth).
During the meeting we discussed how Solaris Zones are being used with a real business strategy in mind. Although Zones are a nice feature of Solaris, when taken at face value it doesn't really stand out until you do something creative with it, something so customer-specific (yet amazing!) that vendors typically do not offer out of the box. What I am referring to here is facility that's been developed [in-house] that focuses on empowering lines of business units to self-sufficiently create Solaris Zone environments for themselves, via a webtool.
Not only that, but what had been demo'ed to me actually appeared as a working, really thought through, solution that, at its core, has business drivers in mind. One of the key deliverables of this webtool is that it leverages inexpensive technology to enable the consumer to request an instantiation of a pre-defined zone profile (and there are a few), with storage, processing power, memory, IP allocation, etc. - self-sufficiently via the intranet web! On top of that, a Zone gets provisioned and becomes available for use in less then a minute!
How does this exponentiate the coolness factor ? It allows the customer to expedite the time to requisite hardware/processing space in the datacenter and shrink that from what it would otherwise be (and you know how long that may take) ...down to 20 seconds!
I was amazed. The idea is really straight forward - there are a number of servers, SAN storage and IP address pools that are allocated for LOB's as a co-operative. Leveraging Solaris Zones (often referred to as Containers), the tool offers up an opportunity for end-users to pick a pre-defined Zone profile (there's a set, reflecting typical types of applications that are of utmost interest, held in a cpio archive). An end-user access the internal website, chooses an available profile, fills out some basic information about a zone and submits a form. Within seconds, the work is done. The user sees progress of zone creation, gets notified by email when the process is complete. Because it is a shared environment, a zone has an expiration date (think: leasing) that can be adjusted (if needed).
8/12/07 - Update and a response to comments -
I understand the tools were pretty much PHP and CGI-like scripts on the backend to call things like zonecfg(1M) and zoneadm(1M). I do not have specifics as to the effort, however I inquired as to the timeframe for getting this sort of thing done and I understand it was done in a matter of a few months, by one key person working on this often on their own time - as a pet project.
Since this is based on the Solaris 10 11/06 release (which backported\* a ton of Zone/ZFS integration code from OpenSolaris/Nevada), the zone clone feature is leveraged, so is the ZFS filesystem, which is what zones get deployed to and how reservation and quotas are enforced. They also provide storage for data on ZFS so its easier to manage and delegate complete control of ZFS filesystems to the Zone administrator - voila!
\*For those that may not be aware of this fact, a currently available commercial release of Solaris does get features from the next release currently in development. As such, Solaris 10 does get certain features from the next release of Solaris being developed in the OpenSolaris community. The codename for the SunOS 5.11 kernel is Nevada and that is where new features appear first, prior to getting (if appropriate) backported/integrated into the Solaris 10 codebase. See http://www.opensolaris.org for more.