Sun Microsystems 10 manual Zones and high availability

Version 3.1-enSolaris 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 2.1.9 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