Zones - reducing disk space used
We're currently looking at zones to consolidate our license servers, since fault management tends to be easier/faster when the license server is running in its own zone.
However, as of right now the "sparse" root model configuration requires 578M of space - 495M taken by packages. Having several of zones using the same size like this would eat up disk space quickly.
Ideally, I'd like the zones to be exactly like the global zone with a few changes under /etc
Does anyone know a way to reduce or eliminate the number of packages needed to be installed, or other ways I might cut down disk usage further?
[633 byte] By [
cbcrawfo] at [2007-11-26 11:19:34]
# 1
Do you have a lot of packages that use space in /opt?
A zone I just created a couple of weeks ago is at 77M for the zone.
etc - 42M (mainly gconf and a fair amount of the service databases)
opt - 0.1M
var - 34M (mainly the package database)
Normally /opt isn't shared. Potentially you could do that, but packages that expect to be able to install data there might object.
You can trim and remount many areas. The only limitation is making sure that you leave things local that have to be written to locally (/var and /etc are probably the most necessary). Getting rid of the gnome packages if you don't use them would free up quite a bit of space in some cases.
--
Darren
# 2
Darren's suggestions are right on, though I might add that what we are looking at (no deployment yet, so I'd be interesting in others thoughts) is marking several directories IN /opt as inherit-pkg-dir (specifically some Veritas packages) so that those directories don't get replicated in each zone (which is a waste). We went from about 300mb per zone to about 68mb.
Now of course in this day and age of 146gb boot drives, saving 200mb of space may not seem like a lot, but it makes the installs faster too which is a big benefit when you're testing and rebuilding zones ten times a day :)
The down side is that the directories you specify show up in the "df" output in the zone which is sort of messy and ends up causing questions later which require more time to explain...
# 3
Of course if you regularly patch the box it can increase the disk space requirements considerably.
Some of our zones are up to 1.5 gig just in /var/sadm.
I wish it was smarter about this.
Firstly in time spent applying patches since patching time appears to be roughly proportional to the number of zones ie its all completely serialised.
But also in space taken up by the zones.
Zones seem like a good idea for consolidation at first glance.
Take 10 minimally utilized machines and consolidate them onto one slightly grunty box.
But then you realised that 10 boxes can be patched simultaneously.
Whereas zones take 10 times as long. Which converts your 15 minute downtime to patch into a
2 1/2 hour downtime. Which people tend to notice.
# 4
We're trying to figure out how to speed up patching as well -- it seems silly how long it takes to effectively just update the /var/sadm structures for a sparse zone...
One note though: to reduce space consumed in /var/sadm in a very safe way, you can delete the "obsolete*" files -- these are the backout information from patches that have been superseded at least once, so the only risk is that you will only be able to back out a single "layer" of patching. You can remove the "undo" files as well, but then you cannot backout the related patches.
Infodoc 14295 has a nice overview of what the files in /var/sadm are for those interested.
