On Wed, 2010-03-31 at 18:01 -0700, Brett wrote:
> Hi Folks,
> 
> I would like to source opinions of the forum on whether its better to share a 
> zfs storage pool for all zones on a machine or create one zpool per zone? The 
> premise is that this zpool (zonepool) would be sitting on san storage.
> 
> I posed that a consolidated pool (zonepool) with each zone zfs sitting under 
> that was good for ease of management and efficiency of resource. ie:
> zonepool/zone1
> zonepool/zone2
> zonepool/zone3
> 
> However a colleague suggests keeping separate zpools, one for each zone is 
> better for reasons of portability (ie being able to detach a zone and then 
> export the zonepool and move the san storage to another like machine if 
> resource becomes constrained). ie:
> zonepool1/zone1
> zonepool2/zone2
> zonepool3/zone3
> 
> Your thoughts are very welcome.
> Regards Rep

We deploy a zpool for each zone to allow for easier mobility.  We also
use the delegated dataset option, so our config is basically:

zone1/zonepath  <- this is were the zoneroot is stored
zone1/zp00      <- this dataset is delegated to the zone for zone data
zone2/zonepath
zone2/zp00

All application data is stored in child datasets of zp00.  This allows
live upgrade to create clones of the zonepath dataset and keeps our
application data isolated from the zoneroot.

Zone Migration consists of:

shutdown zone
detach zone
export zpool 
rezone LUNs to another machine
import zpool
attach zone

Putting the zones in one pool will use storage more efficiently, but
you're zone migration will require a zfs send -> zfs receive step, which
if you're dealing with large zone datasets could be time consuming.

If you're going to deploy lots of zones that don't use much disk I think
I'd go with option 1, because send/recv with a few gigs of data is
probably no big deal.  If you're zones are going to hold many gigs of
data you're life may be easier with SAN based migration.

-Alex

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to