cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] Affinity / Anti-affinity Rules
Date Mon, 07 Jan 2013 14:29:58 GMT
On Mon, Jan 7, 2013 at 1:22 AM, Chris Sears <chris.x.sears@sungard.com> wrote:
> Greetings,
>
> I understand the motivation for a feature like this, but I'm concerned that
> the concepts of affinity and anti-affinity might not be appropriate
> cloud-level abstractions to expose to end users. Also, it might be
> difficult to effectively automate decisions about fault and performance
> domains, both of which would vary greatly between deployments.
>
> Using anti-affinity rules to make sure HA-related VMs aren't placed on the
> same host seems like the most critical use case. What if we narrowed the
> scope of the feature to just address that issue? Building on Chiradeep's
> idea, VMs could have an anti-affinity group attribute. VMs in the same
> anti-affinity group must be placed on different hosts. For the first
> implementation, the guarantee would only apply to initial provisioning.

It could actually apply any time a planner is used to select a host
(which I think also includes CloudStack "HA").

> @Manan, would that be sufficient?
>
> Regards
>
>  - Chris
>
>
> On Fri, Jan 4, 2013 at 6:50 PM, Prachi Damle <Prachi.Damle@citrix.com>wrote:
>
>> Yes, requirements seem vague. What parameters define
>> affinity/anti-affinity?
>>
>> Requirements mention
>> >>  For each VM, users should be able to provide both (Affinity VMs and
>> Anti-affinity VMs) lists concurrently. For example, VM-A can have affinity
>> with VMs B & C and anti-affinity with VMs D & E at the same time.
>> >> When configuring Affinity / anti-affinity for a VM, users should be
>> allowed to provide a list of affinity / anti-affinity VMs (via API) or
>> select affinity /anti-affinity VMs from a list (via UI)
>>
>> When user specifies VM-A can have affinity with VMs B & C does that mean
>> they should be placed on same pod or same hypervisor(cluster or host) by
>> the allocation logic?
>>
>> -Prachi
>> -----Original Message-----
>> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
>> Sent: Thursday, January 03, 2013 6:06 PM
>> To: CloudStack DeveloperList
>> Subject: Re: [DISCUSS] Affinity / Anti-affinity Rules
>>
>> Actually the proposal is quite vague.
>> What does affinity mean to the end-user?
>> What guarantees are being asked for?
>>  - the vms are on the same hypervisor (affinity)
>>  - the vms are not on the same hypervisor (anti)
>>  - the vms are interconnected by a high-speed interconnect (affinity)
>>  - the vms are in different failure domains (host/cluster/pod)
>>
>> I find the concept of affinity groups useful.
>> A possible workflow would be
>> 1. Create an affinity group of type 'Foo'
>> 1a. Group type indicates the guarantee
>> 2. Create a VM in the group
>>
>> VMs can only leave groups on vm destruction.
>>
>> But without the specific type of guarantee, it is hard to discuss this
>> proposal.
>>
>> On 1/3/13 4:23 PM, "Manan Shah" <manan.shah@citrix.com> wrote:
>>
>> >Hi,
>> >
>> >I would like to propose a new feature for enabling Affinity /
>> >Anti-affinity rules in CS 4.1. I have created a JIRA ticket and
>> >provided the requirements at the following location.  Please provide
>> >feedback on the requirements.
>> >
>> >JIRA Ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-739
>> >Requirements:
>> >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Affinity+-+Anti-
>> >aff
>> >i
>> >nity+rules
>> >
>> >
>> >Regards,
>> >Manan Shah
>> >
>>
>>
>>

Mime
View raw message