cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject RE: [DISCUSS] Zone-wide primary storage target
Date Fri, 04 Jan 2013 00:20:55 GMT
Don't get things tooo complicated, let's make the simple thing work:
One hypervisor in one zone, with one or multiple zone-wide primary storages. Without any special
configurations, NFS/ceph + KVM can work under this configuration.
If there are storage providers which can provide per volume per ISCSI LUN in a scalable way,
then XS/KVM can work under this configuration.  E.g. for Xs, each volume will become a SR,
XS should support it? So we can add two hypervisors in one zone, with multiple zone-wide storages.
I heard of that, vmware has the limitation on how many data stores can be attached to a vcenter.
If that's the case, then we may have problems to support this feature for VMware.
Then, if admin just adds a Vmware cluster and kvm/XS cluster into one zone, with both cluster-wide
and zone-wide primary storages, what can we do? 
1. If the storage allocator is smart enough, which helps to choose the right storage to create
volume in different situations. For example, the storage allocator should know, oh, I can't
create volume on a zone-wide storage, if the hypervisor host is vmware etc.
2. or, admin is smart enough, which can tag the storages differently. E.g. VM created on Vmware
cluster can only be created on a storage tagged by "vmware", if the disk offering has "vmware"
 Tag, while VM created on KVM/XS, can be created on storages which has "zone-wide" tag, etc.

> -----Original Message-----
> From: Hari Kannan []
> Sent: Thursday, January 03, 2013 2:35 PM
> To:
> Subject: RE: [DISCUSS] Zone-wide primary storage target
> Actually, let me clarify my original question, as re-reading it seems like it was
> misleading. Since all hypervisors don't support this capability (for example, XS
> doesn't), but a zone can be heterogeneous (from a hypervisor perspective),
> we need to support the capability to allow both zone-wide and cluster-only
> primary storage for any zone. I was wondering if a single cluster needs to
> support both, seems like it is a nice to have?
> Can you elaborate on the "disk offering" comment - are you suggesting we
> provide the end user the following choices
> a) local disk (we have this today already)
> b) zone wide (new - but we indirectly provide this capability already, as CS
> copies between primary stores if needed - but explicitly choosing this option
> means finding storage only on the shared store. If not chosen, preference is
> to place in shared store, if not possible place in cluster-specific primary store

> we still may not be able to avoid "double" copy - if we have to unmount the
> disk and remount on a cluster that does NOT have shared zone-wide primary
> store (or vice-versa), we still may have to resort to the double copy as is
> done today -

> Hari
> -----Original Message-----
> From: Alex Huang []
> Sent: Thursday, January 3, 2013 1:51 PM
> To:
> Subject: RE: [DISCUSS] Zone-wide primary storage target
> > -----Original Message-----
> > From: Hari Kannan []
> > Sent: Thursday, January 03, 2013 1:46 PM
> > To:
> > Subject: RE: [DISCUSS] Zone-wide primary storage target
> >
> > Hi Alex, Chip,
> >
> > That's easy, I will change the name :-)
> >
> > @ Alex, I wasn't explicitly expecting co-existence of zone-wide
> > primary storage and a "local" (cluster-wide only) primary storage. It
> > seems you have assumed that would be a basic requirement, just wanted
> to confirm.
> No I was giving one use case of where this capability might be useful.  It's not
> a requirement.
> >
> > If that were the case, when a user requests a data volume, must there
> > be an option to choose or how will the allocation work? Will data
> > volumes always come out of the zone-wide storage and root volume
> > always is local or cluster- based primary storage?
> I assume those will go into the disk offering.
> >
> > Finally, should we allow multiple zone-wide primary storage?
> Yes.  Every time we plan for only one, it has come back to bite us because
> physical limits of the resources.  We can certainly present to the end user as
> one zone wide ebs like storage but how it's implemented underneath
> shouldn't be limited.
> --Alex

View raw message