Unless your business is heavily dependent on Solaris, you may not know what it is. Solaris is the name of a brand/flavor of UNIX operating system originally developed by Sun Microsystems. Traditionally it ran on hardware provided by Sun as well. Solaris superseded their earlier SunOS and recently changed names to Oracle Solaris to reflect the acquisition of Sun by Oracle. In many places you will still see the OS refer to “SunOS”. Sun’s original platform, SPARC (Scalable Processor Architecture) was and still is a competitor for Intel’s platform, now referenced as x86 or x64.
SPARC was one of the earlier processor platforms to support 64 bit CPUs (circa 1993) as well as Symmetric multiprocessing (SMP). This allowed servers to utilize more than one processor. Sun SPARCs were popular for scaling 4,8 and even 64 or higher processors earlier than other vendors(circa 1993). It is hard to believe these days but in the late 80’s and early 90’s many servers were limited to one processor, core and thread. The only way to scale out an environment was to add more servers due to this limitation. Today with home PCs, it is not uncommon to see dual x 8+ core machines. Even cell phones today are multi core and sometimes dual processor.
As with most hardware, processing power started to outpace the actual compute needs for various software and massively powerful systems were purchased to scale but not always used at 100% of their potential. Sometimes beefy systems were sized for end of month runs but sat relatively idle for the remainder of the month. For Intel based platforms, VMware was making a name for itself in the virtualization world in the late 1990’s to allow better utilization of those processors. VMware is limited to Intel platforms though. Solaris started to see a need for this and implemented their virtualization platform called Solaris Containers in 2004. Over the years, terminology has changed from containers to zones. The implications of the various names can be confusing but for simplicity sake, we will refer to the entire infrastructure/technology as zones.
In a fresh Solaris install, there is a default global zone. This is the parent zone. In VMware terminology, this would be the host operating system. From there, you can create non-global zones. There are a few different types. The non-global zones cannot detect each other or the parent as there is a virtualization layer that segments these. Only the global zone is aware of all of the other zones.
A Sparse Root Zone requires the smallest overhead. It essentially shares the same running kernel as the global zone and most of the userland and packages. It can read the majority of the global zone’s files (depending on sysadmin configuration) but has its own storage for writing. For those familiar with VMware this would be closely related to a thin provisioned linked clone.
A Whole Root Zone contains a complete read/write copy of the global zone. In VMware terms this is most closely related to a full clone of the global zone to a non global zone. This takes up substantially more space than the sparse root zone but allows more flexibility in the configuration of it since a full copy for read/write is made.
Finally, a Branded Zone is one that supports an entirely different version of Solaris. The two previously mentioned zones all share the same running kernel and userland. In some cases you may need a previous version of Solaris for backwards compatibility. For example if you are running Solaris 11 on the global zone but need to run Solaris 10 for your ERP, a Branded Zone will help facilitate that. In this setup, it more closely resembles a traditional hypervisor as the OS version is not dependent on the global zone OS version. It does still require the OS to be Solaris though. The global zone provides some emulation of system calls to previous versions in order to help facilitate this.
From the global zone you can start, stop, install new zones and even uninstall zones as necessary. As with most UNIX operating systems, it is very easy to script this as necessary and you could automate the need to spin up zones or deprovision as necessary. Below, I have a zone already installed but set to not auto boot and have booted it manually.
This separation and isolation is necessary for virtualization to work as expected. For example, you do not want your ERP system competing with resources with your custom application that processes business transactions but also lets each of them expand into shared resources as necessary. Otherwise you could just avoid zones all together. Virtualizing in this manner does save on costs and space resulting in purchasing multiple machines, powering them and finding rack space for them. As with any virtualization effort, one does need to calculate all costs, hard and soft, involved with consolidating resources and actual savings of that effort. Usually the case with SPARC servers is that you do not want to under provision but you do want to fully utilize due to the cost of the equipment and zones help walk this fine line.
In summary, if you use Solaris or are a Solaris shop, you probably know a little about zones. With the move to the cloud, Solaris is not as popular of an operating system these days because massively large servers are not always needed. Many UNIX admins have also nick named it “Slowaris”. Cases where they are usually needed are extremely large enterprises that may have legacy applications that may be overly expensive to rewrite or migrate to more economical platforms. Solaris has been a very mature platform over the years so you are bound to run across an organization that has standardized on it for certain needs.