Filter
Top Products
Version 3.1-en Solaris 10 Container Guide - 3.1 4. Best Practices Effective: 30/11/2009
4.4.6. Re-installation and service provisioning instead of patching
[dd] Patching of zones can force zones into single user mode, when system patches are applied.
Zone patching can therefore lead into halting the services provided. This service interruption can vary
in length depending on the type of the patches, the number of zones and the number of patches to be
installed. To shorten this period and to achieve predictability of service downtime, re-installation can
be chosen over individual patching.
Zones can be created rapidly in almost any number. These zone installations are considerably
quicker than the re-installation of a computer or the individual patching of zones. It should therefore
be generally considered as a datacenter method to carry out re-installation of zones instead of patch
or upgrade. Newly created zones after all automatically have the current software or patch status of
the global zone after they have been created. Subsequently, the application data and, the application
are moved into the new zone. For this time the zone is not in production.
One of the prerequisites for this procedure is the fact that the application, the configuration and the
data can be moved among zones. The following things must be taken into account:
• Binary programs are installed in zones using the standard procedure for creating zones.
• Service configurations and data are stored in separate directories or file systems in the zone.
• Other modifications to the zones are recorded or can be detected and extracted automatically
(e.g. with bart(1m))
• To "move" a zone, the service is "moved". This is done by copying the configuration and the
service data (if necessary by relocating the file system) as well as by customizing the zone
created to the service requirement. This can be done by extracting, transporting and unpacking
the modification from the original zone to the new zone.
4.4.7. Backup and recovery of zones
[dd] A Backup of Zones can be created by using backup tools from the global zone. The backup can
contain the zone's application data or save them separately. The following things are required for
zone backups:
• Backup of zone configuration with
zonecfg -z <zone1> export -f <zone1>.zonecfg
or directly of the file /etc/zones/<zone>.xml
• If necessary, backup of the associated line in /etc/zones/index
• Backup of the directory tree e.g. /zones/zone1 using backup tools
For recovery, the steps must be carried out in reverse.
• create /zones/zone1
• chmod 700 /zones/zone1 (standard for zone directories)
• If necessary, prepare submounts, if e.g. /zones/zone1/root/var should be a separate
file system
• Install backup
• Where applicable, adjust <zone1>.zonecfg (new path, other mounting points)
• Create the zone configuration with zonecfg -z <zone1> -f <zone1>.zonecfg
• Use zoneadm attach to attach the zone
It must be taken into account when doing a backup of the zone directory that sparse root zones
contain inherit-pkg-dir. To back up directories such as e.g. /usr, /sbin per zone as well is
certainly only useful in the fewest of cases. That is, information must be provided in the backup
configuration whether and how inherit-pkg-dir should be co-backed up.
The Sun StorEdge Enterprise Backup Software (EBS) can e.g. be controlled via .nsr files in
directories such that such directories are not backed up as well.
Veritas Netbackup (NBU) has a central configuration available. That is, in this case, corresponding
configurations must be installed centrally using global rules. If zone migration and backup/restore
from the global zone is scheduled for later, this configuration must accordingly be constructed in a
cross-system manner.
Use of a backup client in the global zone for several local zones allows licensing fees to be saved. To
back up special application data (e.g. databases), the backup client or the backup module must, if
need be, run directly in the local zone (e.g. backup of Oracle with RMAN).
54