Filter
Top Products
Version 3.1-en Solaris 10 Container Guide - 3.1 4. Best Practices Effective: 30/11/2009
4.1.6. Storage concepts
4.1.6.1. Storage for the root file system of the local zones
[ug] It is usually sufficient for several zones to share a file system.
If the influence from the zones to the file system is to be uncoupled, it is recommended to give each
zone its own file system.
With the new ZFS file system by Solaris 10, this can be achieved with little effort. Since Solaris 10
10/08, ZFS can be used as zone root. Prior to Solaris 10 10/08, although it was possible to run a
zone on ZFS, an upgrade was not supported; therefore, Solaris 10 10/08 is urgently recommended
for zones on ZFS.
With the availability of iSCSI in Solaris 10 8/07 as a client initiator and as target emulator, this
technology as well can be used as a storage technology for zone root file systems. The mobility of
zones, e.g. in connection with zoneadm detach / zoneadm attach, thereby increases by
the flexible utilization of iSCSI volumes in different systems with network access.
For a system that is to have a high number of zones installed on it, using a storage subsystem with
cache for the root file systems is recommended. Each OS instance and by association each zone
write messages, log entries, utmp entries, etc. on the root file system at irregular intervals. The
applications also use the root file system for logs if applicable. In many instances, this can lead to a
bottleneck on the file system (less critical for ZFS).
4.1.6.2. Data storage
[ug] Data storage (files, databases) is planned in the same way as for dedicated computers. The
storage devices are connected to the computer that contains the zones. The file systems are
mounted directly in the global zone and transferred to the zones per loopback mount
(zonecfg:add fs). Then, the file systems can also be used for data transfer by other zones, if
they are configured.
Alternatively, it is possible to have file systems (zonecfg:add fs) mounted by the
zoneadmd(1M) directly when booting the zone, thereby making them available to individual zones
exclusively. Since in this case access to the raw device and the block device is not possible within the
zone, such a file system while booting a zone is mounted with zoneadm -z <zone> boot by
the global zone at e.g. /zones/<zonename>/root/<filesystem> and appears in the local zone as
/<filesystem>. However, due to bug 6495558, the file system will not be checked or repaired by
zoneadm in case of need. To plan the file system layout of zones, alternatives should therefore be
used if necessary.
Devices, e.g. for databases, can also be specifically assigned to a local zone (zonecfg:add
device). Assigning the same device to several zones is useful in exceptional cases only;
coordination of the device use is strongly advised.
4.1.6.3. Program/application storage
[ug] This procedure (see above) can also be selected for programs used by the applications.
All software can be installed in a global zone directory, and this directory can be assigned to the local
zones (zonecfg:add fs). This is comparable to software being located on an NFS server in the
data center; here, a local file system is used which is made available to the zone.
Thereby, the software is available to all zones after being installed once. The computer's autonomy
remains untouched. This type of software distribution is useful for non-pkg software only. pkg
software is distributed or inherited to the zones by the zone's installation mechanisms.
38