Sun Microsystems 10

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 loca l 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 th e 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, et c. on the root file system at irregular intervals. The

applications also use the root file system fo r 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

(zon ecf g: add f s). 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

dev ice ). 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 (zon ec fg: add f s). 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 aft er 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.