Zones and high availability – Sun Microsystems SOLARIS 10 User Manual
Page 14
Version 3.1-en
Solaris 10 Container Guide - 3.1 2. Functionality
Effective: 30/11/2009
2.1.7. Zones and high availability
[tf/du/hs] In the presence of all RAS capabilities, a zone has only the availability of a computer and it
decreases with the number of components of the machine (MTBF).
If this availability is not sufficient, so-called failover zones can be implemented using the HA Solaris
Container Agent, allowing zones to be panned among cluster nodes (from Sun Cluster 3.1 08/05).
This increases the availability of the total system considerably. In addition, a container here becomes
a flexible container. That is to say, it is completely irrelevant which of the computers participating in
the cluster the container is running on. Relocating the container can be done manually by
administrative actions or automatically in the event of a computer malfunction.
Alternatively, it is also possible using the HA Solaris Container Agent to start and to stop local zones
including their services. That is, identical zones exist on several computers with identical services that
have no(!) shared storage. The failover of a zone in such a configuration is not possible, because the
zone rootpath cannot be moved between the zones. Instead one of the zones can be stopped and an
identical zone can then be started on another system.
Container clusters (since Sun Cluster 3.2 1/09) offer a third option. A Sun Cluster, where virtual
clusters can be configured, is installed in the global zone. The virtual clusters consist of virtual
computer nodes that are local zones. Administration can be transferred to the zone operators. (see
Solaris container cluster (aka "zone cluster")
2.1.8. Branded zones (Linux and Solaris 8/Solaris 9 compatibility)
[dd/ug] Branded zones allow you to run an OS environment which is different from the one that is
installed in the global zone (BrandZ, since Solaris 10 8/07)
Branded zones extend zone configuration as follows:
•
A brand is a zone attribute.
•
Each brand contains mechanisms for the installation of a branded zone.
•
Each brand can use its own pre-/post-boot procedures.
At runtime, system calls are intercepted and either forwarded to Solaris or emulated. Emulation is
done by modules in libraries contained in the brand. This design has the advantage that additional
brands can easily be introduced without changing the Solaris kernel.
The following brands are currently available:
•
native: Brand for zones with the Solaris 10 version from the global zone
•
lx: Solaris Container for Linux Applications (abbreviated: SCLA)
With this, unmodified 32-bit Linux programs can be used under Solaris on x86 systems. To do
so, a 32-bit Linux distribution that can use a Linux 2.4 kernel must be installed in the zone. The
required Linux programs can then be used and/or installed in the zone.
The Linux distribution and license are themselves not contained in Solaris and must be installed
in each zone (new installations or copies of an existing installation). At least the following Linux
distributions work:
−
CentOS 3.5 – 3.8, RedHat Linux 3.5
–
3.8 (certified)
−
Debian (unsupported, for instructions see blog by Nils Nieuwejaar
http://blogs.sun.com/nilsn/entry/installing_a_debian_zone_with)
•
solaris8/Solaris9: Solaris 8 or Solaris 9 container
This allows you to operate a Solaris 8 or Solaris 9 environment in a zone (SPARC only). Such
containers can be made highly available with the HA Solaris Container Agent. Such types of
zones cannot be used as virtual nodes in a virtual cluster.
•
solaris10: Solaris 10 branded zones for OpenSolaris are in the planning stage
(see
http://opensolaris.org/os/project/s10brand/
)
7