Sun Microsystems 10 用户手册

下载
页码 121
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 
(
z o n e c f g : a d d   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  (
z o n e c f g : a d d  
d e v i c e
).   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 (
z o n e c f g : a d d   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 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