Zones Best Practices

From Siwiki

Jump to: navigation, search

Contents

[edit] Zones Best Practices

This page is about Solaris Zones Best Practices, which are a collection of usage recommendations. See the Zones page for general information about Solaris Zones.

This documentation is from the OpenSolaris and Solaris Internals communities, it is not a product of Sun Microsystems.

[edit] Best From the Global Zone

The following are best executed from the global zone,

  • patching - to keep all zones in sync.
  • backups - to skip shared filesystems.
  • storage administration - as accessing /dev files are easier from the global zone.
  • network administration - such as changing the IP address, which must be done from global.

[edit] Zone Backups

The following is a summary of methods that can be used to backup zones. Many zones share files with the global zone, through use of loopback filesystem readonly mounts (usually /usr, /lib, /sbin and /platform); we don't want to backup these lofs directories as they may be already backed up via the usual global zone backup strategy, which makes zone backups not exactly straightforward.

  • Shutting down the zone
  • UFS snapshots
  • find and cpio
  • NetBackup
  • Legato

These methods backup the zone files. Remember to also backup the config file from /etc/zones - for example, /etc/zones/smallzone.xml.

Shutting down the zone So that we don't descend down lofs shares and backup duplicates of the global zone's files, here we shutdown the zone first before doing a backup. Any backup tool could be used, ufsdump is demonstrated here,

# zlogin -S smallzone init 5
# zoneadm list -cv
  ID NAME             STATUS         PATH                          
   0 global           running        /                             
   - smallzone        installed      /export/smallzone             
# ufsdump 0f /backup/smallzone.ufsdump /export/smallzone
  DUMP: Date of this level 0 dump: Thu Apr 14 08:55:56 2005
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rdsk/c0t0d0s0 (lambda:/) to /backup/smallzone.ufsdump. 
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Writing 32 Kilobyte records
  DUMP: Estimated 235508 blocks (114.99MB).
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]
  DUMP: 234494 blocks (114.50MB) on 1 volume at 2394 KB/sec
  DUMP: DUMP IS DONE
# zoneadm -z smallzone boot

[edit] UFS snapshots

This approach uses the "fssnap" command, which first appeared in Solaris 8 2/02. This can give us a clean, consistant backup of the zone files only, and can be run on a live zone. In the following example we have a zone under /export/smallzone, a separate /var to use as the backing store, and our destination backup is /backup/smallzone.ufsdump,

# fssnap -o bs=/var/tmp /
/dev/fssnap/0
# mount -o ro /dev/fssnap/0 /mnt
# ufsdump 0f /backup/smallzone.ufsdump /mnt/export/smallzone
  DUMP: Date of this level 0 dump: Wed Apr 13 09:08:14 2005
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rfssnap/0 (lambda:/mnt) to /backup/smallzone.ufsdump.  
  DUMP: Mapping (Pass I) [regular files]
  DUMP: Mapping (Pass II) [directories]
  DUMP: Writing 32 Kilobyte records
  DUMP: Estimated 231034 blocks (112.81MB).
  DUMP: Dumping (Pass III) [directories]
  DUMP: Dumping (Pass IV) [regular files]
  DUMP: 230014 blocks (112.31MB) on 1 volume at 2227 KB/sec
  DUMP: DUMP IS DONE
# umount /mnt
# fssnap -d /
Deleted snapshot 0.

[edit] find and cpio

The following method uses find and cpio on a live zone. We assume the zone is installed under UFS, and use find switches to restrict the search to UFS - and to not descend down lofs mount points,

# cd /
# find export/smallzone -fstype lofs -prune -o -fstype ufs | cpio -oc -O /backup/smallzone.cpio   
# ls -l backup/smallzone.cpio
-rwxr-xr-x   1 root     root     98566144 Apr 12 12:34 backup/smallzone.cpio

[edit] NetBackup

It is possible to use NetBackup to backup a live zone, it will need to be configured to skip the lofs shared mounts (/usr, /lib, ...) that were configured for the zone.

[edit] Legato

Legato can be used in the same way as NetBackup, it needs to be configured to skip the lofs mounts.

[edit] Zone Patches

To understand how patches works, lets go back and look at the different models for zones.

[edit] Big Zone

This is the Big-Zone, or the "Whole Root Model".

Image:ZRC_big-zone1.png

From the above we can see that on the global zone all directories are read+write, and an the big zone all directories are also read+write. The following options are available,

  • After logging into the big zone, a patch may be added using "patchadd" (but not a kernel patch).
  • After logging into the global zone, a patch may be added to the global zone only by using "patchadd -G".
  • After logging into the global zone, a patch may added to all the zones using "patchadd".

For the third option, read the output of patchadd carefully - you will see the command iterate over all the non-global zones. If a non-global zone is not running when patchadd is run, patchadd will boot the non-global zone into single user mode so that the patchadd will work, and then return the zone to it's original state. The end result is that all zones are patched.

Do you want every zone to be running at a different patch level? Probably not. Depending on your requirements, it may well be best to manage patching from the global zone only.

If you run a patch cluster from the global zone and you have zones that aren't booted, the current behaviour is to boot and shutdown each zone for each patch. This adds considerable time to the patch cluster - it helps to boot all zones before beginning so that patchadd doesn't need to toggle their state. (this behaviour may be improved, check how your current version of Solaris 10 behaves).


[edit] Small Zone

This is the Small-Zone, also called the "Sparse Root Model",

Image:ZRC_small-zone1.png

From the above we can see that the global zone has all directories read+write, and the small zone has most of the operating system directories read only. The following options are available,

  • After logging into the small zone, regular patches that modify /usr can not be added.
  • After logging into the global zone, using "patchadd -G" will also update files shared by the small zone.
  • After logging into the global zone, a patch may be added to all the zones properly using "patchadd".

Scenario 2 leaves the small zone in an odd state (some shared files are patched, but /var not updated).

Scenario 3 becomes more interesting. When the patch is initially added to the global zone, since the non-global zones share the operating system directories, they will immediately be accessing patched files. The patchadd command will still iterate over all the non-global zones - it needs to, to update other patch related files in /var; during which it may complain that many files are read only. The end result is that all zones are patched. Recommendations

Although this depends on your environment and requirements, it would seem best to manage patching from the global zone only, and let the global zone iterate over all non-global zones to patch them also. It helps if all zones are booted before patching.

Sun is also promoting the use of Patch Manager to patch servers these days. See "man smpatch", especially the examples.

[edit] Zone Packages

To understand how packages work, lets look at the different models for zones.

[edit] Small Zone

This is the Small-Zone, also called the "Sparse Root Model",

Image:ZRC_small-zone1.png

From the above we can see that the global zone has all directories read+write, and the small zone has most of the operating system directories read only.

The following options are available,

  • After logging into the small zone, packages may be added so long as they don't modify /usr, /lib, /platform and /sbin. Eg, to install them under /opt. "pkgadd" is used.
  • After logging into the global zone, using "pkgadd -G" will add the package to the global zone, and may share some files to the small zone.
  • After logging into the global zone, using "pkgadd" will install everything in all zones.

Scenario 2 leaves the small zone in an odd state - it may contain much of the package, without being (pkginfo) aware.

[edit] Big Zone

This is the Big-Zone, or the "Whole Root Model".

Image:ZRC_big-zone1.png

From the above we can see that on the global zone all directories are read+write, and an the big zone all directories are also read+write. The following options are available,

  • After logging into the big zone, a package may be added using "pkgadd".
  • After logging into the global zone, a package may be added to the global zone only by using "pkgadd -G".
  • After logging into the global zone, a package may added to all the zones using "pkgadd".

The big zone is more flexible than the small zone - here we can add package independently and usually without problems. Recommendations

Although this depends on your environment and requirements, it would seem that if the non-global zone had the need to install and maintain their own packages, they are better off as a big zone. If not, the small zone model would be fine.

[edit] SunFreeware.com packages

These like to install themselves under /usr/local, and for many zones /usr/local is a read only shared filesystem. This prevents non-global zone admins from easily adding their own packages from SunFreeware.com.

Now, if you use these packages from the Software Companion CD there isn't a problem, as they install themselves under /opt/sfw - which is always read write!

A suggestion to solve the shared /usr/local issue is this: create a symlink on the global zone from "/usr/local" to "/opt/local", and create an /opt/local directory in every non global zone. Now any package adds in the non global zone will add to their /opt/local, not attempt to write to the read only /usr/local.

[edit] Resources

See the following for other resources on Solaris Zones,

Zones FAQ

Solaris Internals
Personal tools
The Books
The Ads