[one-users] (anti-) affinity groups support for scheduler

[Carlos Martín Sánchez]

Hi Stefan,

How do you plan to implement it? I was thinking that instead of making the
scheduler go through all the VMs running on a Host, the core could have
support for this. It could add/remove the value of VM's AFFINITY_GROUP to
the host on deployment/shutdown.

This way the host will have AFFINITY_GROUP="nameA, nameB, nameC"
automatically populated, making the scheduling faster.

Regards
--
Carlos Martín, MSc
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org | cmartin at opennebula.org |
@OpenNebula<http://twitter.com/opennebula><cmartin at opennebula.org>


On Wed, Apr 9, 2014 at 5:03 PM, Paul Batchelor <pbatchelor at blackberry.com>wrote:

> We would definitely see a use for this as well. We have had multiple
> instances of a supposedly redundant service start on the same hypervisor.
> An "anti-affinity" attribute in the template sounds like the perfect fix.
>
> -----Original Message-----
> From: users-bounces at lists.opennebula.org [mailto:
> users-bounces at lists.opennebula.org] On Behalf Of Stefan Kooman
> Sent: 09 April 2014 14:41
> To: users at lists.opennebula.org
> Subject: [one-users] (anti-) affinity groups support for scheduler
>
> Hi List,
>
> I'm trying to accomplish the following. I want to have the "match making
> scheduler" schedule two or more vm's on the same hypervisor (webserver and
> database server, to reduce network traffic between HOSTS. I know there is a
> way of doing this with "CURRENT_VMS". CURRENT_VMS only seems to accept "VM
> ID's" and not the name of a VM. The drawback of having an ID hardcoded in a
> template is that if the VM gets recreated from a template somewhere in the
> future (because of some changes in the template) the REQUIREMENT will never
> be fullfilled and the vm never deployed.
> One way to get around this would be to create so called "(anti-)affinity
> groups. So in a VM TEMPLATE you would define
> "AFFINITY_GROUP=$AFFINITY_GROUP"
> and the scheduler would check if a VM with that particular AFFINITY_GROUP
> is running on a hypervisor. If so, it would place this VM on the same
> hypervisor. If not it deploys the VM on a hypervisor that has highest
> priority after filtering. You might wonder why I would not just select a
> HOST for these particular VM's. With HOST=$HOST I would not be able to
> bring those VM's up on a different hypervisor in case of a disaster without
> modifying a template or manually forcing a deploy. Not something you've got
> time for while battling a (major) outage.
>
> You can think of an AFFINITY_GROUP as a selective "black hole": Sucking up
> VM's it has affinity with.
>
> What do you think of this? Does it makes sense to you? Would you have use
> for this funtionality?
>
> Gr. Stefan
>
>
> --
> | BIT BV  http://www.bit.nl/        Kamer van Koophandel 09090351
> | GPG: 0xD14839C6                   +31 318 648 688 / info at bit.nl
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
> ---------------------------------------------------------------------
> BlackBerry UK Limited
> Registered in England and Wales. Registered No. 04022422, with registered
> office at 200 Bath Road, Slough, Berkshire, SL1 3XE, United Kingdom
>
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20140416/4936940f/attachment-0002.htm>