Hi Yiping,
Reading your most recent e-mail, it seems like you are looking for a feature
that does more than simply makes sure virtual disks are roughly allocated
equally across the primary storages of a given cluster.
At first, that is what I imagined your request to be.
>From this e-mail, though, it looks like this is something you'd like users to
>be able to personally choose (ex. a user might want virtual disk 1 on
>different storage than virtual disk 2).
Is that a fair representation of your request?
If so, I believe storage tagging (as was mentioned by Marty) is the only way to
do that at present. It does, as you indicated, lead to a proliferation of
offerings, however.
As for how I personally solve this issue: I do not run a cloud. I work for a
storage vendor. In our situation, the clustered SAN that we develop is highly
fault tolerant. If the SAN is offline, then it probably means your entire
datacenter is offline (ex. power loss of some sort).
Talk to you later,
Mike
________________________________________
From: Yiping Zhang <yzh...@marketo.com>
Sent: Friday, September 9, 2016 11:08 AM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups
I am not a Java developer, so I am at a total loss on Mike’s approach. How
would end users choose this new storage pool allocator from UI when
provisioning new instance?
My hope is that if the feature is added to ACS, end users can assign an
anti-storage affinity group to VM instances, just as assign anti-host affinity
groups from UI or API, either at VM creation time, or update assignments for
existing instances (along with any necessary VM stop/start, storage migration
actions, etc).
Obviously, this feature is useful only when there are more than one primary
storage devices available for the same cluster or zone (in case for zone wide
primary storage volumes).
Just curious, how many primary storage volumes are available for your
clusters/zones?
Regards,
Yiping
On 9/8/16, 6:04 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> wrote:
Personally, I think the most flexible way is if you have a developer write
a storage-pool allocator to customize the placement of virtual disks as you see
fit.
You extend the StoragePoolAllocator class, write your logic, and update a
config file so that Spring is aware of the new allocator and creates an
instance of it when the management server is started up.
You might even want to extend ClusterScopeStoragePoolAllocator (instead of
directly implementing StoragePoolAllocator) as it possibly provides some useful
functionality for you already.
________________________________________
From: Marty Godsey <ma...@gonsource.com>
Sent: Thursday, September 8, 2016 6:27 PM
To: dev@cloudstack.apache.org
Subject: RE: storage affinity groups
So what would be the best way to do it? I use templates to make it simple
for my users so that the Xen tools are already installed as an example.
Regards,
Marty Godsey
-----Original Message-----
From: Yiping Zhang [mailto:yzh...@marketo.com]
Sent: Thursday, September 8, 2016 7:55 PM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups
Well, using tags leads to proliferation of templates or service offerings
etc. It is not very scalable and gets out of hand very quickly.
Yiping
On 9/8/16, 4:25 PM, "Marty Godsey" <ma...@gonsource.com> wrote:
I do this by using storage tags. As an example I have some templates
that are either created on SSD or magnetic storage. The template has a storage
tag associated with it and then I assigned the appropriate storage tag to the
primary storage.
Regards,
Marty Godsey
-----Original Message-----
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: Thursday, September 8, 2016 7:16 PM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups
If one doesn't already exist, you can write a custom storage allocator
to handle this scenario.
> On Sep 8, 2016, at 4:25 PM, Yiping Zhang <yzh...@marketo.com> wrote:
>
> Hi, Devs:
>
> We all know how (anti)-host affinity group works in CloudStack, I am
wondering if there is a similar concept for (anti)-storage affinity group?
>
> The use case is as this: in a setup with just one (somewhat)
unreliable primary storage, if the primary storage is off line, then all VM
instances would be impacted. Now if we have two primary storage volumes for the
cluster, then when one of them goes offline, only half of VM instances would be
impacted (assuming the VM instances are evenly distributed between the two
primary storage volumes). Thus, the (anti)-storage affinity groups would make
sure that instance's disk volumes are distributed among available primary
storage volumes just like (anti)-host affinity groups would distribute
instances among hosts.
>
> Does anyone else see the benefits of anti-storage affinity groups?
>
> Yiping
