Sun Microsystems 10 manual Data storage, Program/application storage

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