<div dir="ltr">We need to be careful. I believe that a user can use these filters to keep requesting VMs in the case of nova to get to the size of your cloud. <div><br></div><div>Also given that nova now has ServerGroups let's not make a quick decision on using something that is being replaced with something better. I suggest we investigated ServerGroups a little more before we discard it. <div>
<br><div>The operator should really decide how he/she wants Anti-affinity by setting the right filters in nova.</div><div><br></div><div>Susanne</div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Aug 28, 2014 at 5:12 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Trevor and I just worked through some scenarios to make sure it can<br>
handle colocation and apolocation. It looks like it does, however not<br>
everything will so simple, especially when we introduce horizontal<br>
scaling. Trevor's going to write up an email about some of the caveats<br>
but so far just using a table to track what LB has what VMs and on what<br>
hosts will be sufficient.<br>
<br>
Thanks,<br>
Brandon<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, 2014-08-28 at 13:49 -0700, Stephen Balukoff wrote:<br>
> I'm trying to think of a use case that wouldn't be satisfied using<br>
> those filters and am not coming up with anything. As such, I don't see<br>
> a problem using them to fulfill our requirements around colocation and<br>
> apolocation.<br>
><br>
><br>
> Stephen<br>
><br>
><br>
> On Thu, Aug 28, 2014 at 1:13 PM, Brandon Logan<br>
> <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
> Yeah we were looking at the SameHost and DifferentHost filters<br>
> and that<br>
> will probably do what we need. Though I was hoping we could<br>
> do a<br>
> combination of both but we can make it work with those filters<br>
> I<br>
> believe.<br>
><br>
> Thanks,<br>
> Brandon<br>
><br>
> On Thu, 2014-08-28 at 14:56 -0400, Susanne Balle wrote:<br>
> > Brandon<br>
> ><br>
> ><br>
> > I am not sure how ready that nova feature is for general use<br>
> and have<br>
> > asked our nova lead about that. He is on vacation but should<br>
> be back<br>
> > by the start of next week. I believe this is the right<br>
> approach for us<br>
> > moving forward.<br>
> ><br>
> ><br>
> ><br>
> > We cannot make it mandatory to run the 2 filters but we can<br>
> say in the<br>
> > documentation that if these two filters aren't set that we<br>
> cannot<br>
> > guaranty Anti-affinity or Affinity.<br>
> ><br>
> ><br>
> > The other way we can implement this is by using availability<br>
> zones and<br>
> > host aggregates. This is one technique we use to make sure<br>
> we deploy<br>
> > our in-cloud services in an HA model. This also would assume<br>
> that the<br>
> > operator is setting up Availabiltiy zones which we can't.<br>
> ><br>
> ><br>
> ><br>
> <a href="http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/" target="_blank">http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/</a><br>
> ><br>
> ><br>
> ><br>
> > Sahara is currently using the following filters to support<br>
> host<br>
> > affinity which is probably due to the fact that they did the<br>
> work<br>
> > before ServerGroups. I am not advocating the use of those<br>
> filters but<br>
> > just showing you that we can document the feature and it<br>
> will be up to<br>
> > the operator to set it up to get the right behavior.<br>
> ><br>
> ><br>
> > Regards<br>
> ><br>
> ><br>
> > Susanne<br>
> ><br>
> ><br>
> ><br>
> > Anti-affinity<br>
> > One of the problems in Hadoop running on OpenStack is that<br>
> there is no<br>
> > ability to control where machine is actually running. We<br>
> cannot be<br>
> > sure that two new virtual machines are started on different<br>
> physical<br>
> > machines. As a result, any replication with cluster is not<br>
> reliable<br>
> > because all replicas may turn up on one physical machine.<br>
> > Anti-affinity feature provides an ability to explicitly tell<br>
> Sahara to<br>
> > run specified processes on different compute nodes. This is<br>
> especially<br>
> > useful for Hadoop datanode process to make HDFS replicas<br>
> reliable.<br>
> > The Anti-Affinity feature requires certain scheduler filters<br>
> to be<br>
> > enabled on Nova. Edit your/etc/nova/nova.conf in the<br>
> following way:<br>
> ><br>
> > [DEFAULT]<br>
> ><br>
> > ...<br>
> ><br>
> ><br>
> scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler<br>
> > scheduler_default_filters=DifferentHostFilter,SameHostFilter<br>
> > This feature is supported by all plugins out of the box.<br>
> ><br>
> ><br>
> ><br>
> <a href="http://docs.openstack.org/developer/sahara/userdoc/features.html" target="_blank">http://docs.openstack.org/developer/sahara/userdoc/features.html</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Thu, Aug 28, 2014 at 1:26 AM, Brandon Logan<br>
> > <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
> > Nova scheduler has ServerGroupAffinityFilter and<br>
> > ServerGroupAntiAffinityFilter which does the<br>
> colocation and<br>
> > apolocation<br>
> > for VMs. I think this is something we've discussed<br>
> before<br>
> > about taking<br>
> > advantage of nova's scheduling. I need to verify<br>
> that this<br>
> > will work<br>
> > with what we (RAX) plan to do, but I'd like to get<br>
> everyone<br>
> > else's<br>
> > thoughts. Also, if we do decide this works for<br>
> everyone<br>
> > involved,<br>
> > should we make it mandatory that the nova-compute<br>
> services are<br>
> > running<br>
> > these two filters? I'm also trying to see if we can<br>
> use this<br>
> > to also do<br>
> > our own colocation and apolocation on load<br>
> balancers, but it<br>
> > looks like<br>
> > it will be a bit complex if it can even work.<br>
> Hopefully, I<br>
> > can have<br>
> > something definitive on that soon.<br>
> ><br>
> > Thanks,<br>
> > Brandon<br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Stephen Balukoff<br>
> Blue Box Group, LLC<br>
> <a href="tel:%28800%29613-4305%20x807" value="+18006134305">(800)613-4305 x807</a><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>