Yes, that is essentially the same thing. You would create your anti-affinity between clusters instead of hosts. That is also an option...
*Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Fri, Sep 9, 2016 at 7:05 PM, Simon Weller <swel...@ena.com> wrote: > Why not just use different primary storage per cluster. You then can > control your storage failure domains on a cluster basis. > > Simon Weller/ENA > (615) 312-6068 > > -----Original Message----- > From: Will Stevens [wstev...@cloudops.com] > Received: Friday, 09 Sep 2016, 5:46PM > To: dev@cloudstack.apache.org [dev@cloudstack.apache.org] > Subject: Re: storage affinity groups > > I have not really thought through this use case, but off the top of my > head, you MAY be able to do something like use host anti-affinity and then > use different primary storage per host affinity. I know this is not the > ideal solution, but it will limit the primary storage failure domain to a > set of affinity hosts. This pushes the responsibility of HA to the > application deployer, which I think you are expecting to the be case > anyway. You still have a single point of failure with the load balancers > unless you implement GSLB. > > This will likely complicate your capacity management, but it may be a short > term solution for your problem until a better solution is developed. > > If I think of other potential solutions I will post them, but that is what > I have for right now. > > *Will STEVENS* > Lead Developer > > *CloudOps* *| *Cloud Solutions Experts > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 > w cloudops.com *|* tw @CloudOps_ > > On Fri, Sep 9, 2016 at 3:44 PM, Yiping Zhang <yzh...@marketo.com> wrote: > > > Will described my use case perfectly. > > > > Ideally, the underlying storage technology used for the cloud should > > provide the reliability required. But not every company has the money > for > > the best storage technology on the market. So the next best thing is to > > provide some fault tolerance redundancy through the app and at the same > > time make it easy to use for end users and administrators alike. > > > > Regards, > > > > Yiping > > > > On 9/9/16, 11:49 AM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> > wrote: > > > > Yep, based on the recent e-mail Yiping sent, I would agree, Will. > > > > At the time being, you have two options: 1) storage tagging 2) > > fault-tolerant primary storage like a SAN. > > ________________________________________ > > From: williamstev...@gmail.com <williamstev...@gmail.com> on behalf > > of Will Stevens <wstev...@cloudops.com> > > Sent: Friday, September 9, 2016 12:44 PM > > To: dev@cloudstack.apache.org > > Subject: Re: storage affinity groups > > > > My understanding is that he wants to do anti-affinity across primary > > storage endpoints. So if he has two web servers, it would ensure > that > > one > > of his web servers is on Primary1 and the other is on Primary2. This > > means > > that if he loses a primary storage for some reason, he only loses one > > of > > his load balanced web servers. > > > > Does that sound about right? > > > > *Will STEVENS* > > Lead Developer > > > > *CloudOps* *| *Cloud Solutions Experts > > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 > > w cloudops.com *|* tw @CloudOps_ > > > > On Fri, Sep 9, 2016 at 2:40 PM, Tutkowski, Mike < > > mike.tutkow...@netapp.com> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > >
