<div dir="ltr">I'm trying to think of a use case that wouldn't be satisfied using those filters and am not coming up with anything. As such, I don't see a problem using them to fulfill our requirements around colocation and apolocation.<div>
<br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 1:13 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">Yeah we were looking at the SameHost and DifferentHost filters and that<br>
will probably do what we need. Though I was hoping we could do a<br>
combination of both but we can make it work with those filters I<br>
believe.<br>
<br>
Thanks,<br>
Brandon<br>
<div class="HOEnZb"><div class="h5"><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 and have<br>
> asked our nova lead about that. He is on vacation but should be back<br>
> by the start of next week. I believe this is the right approach for us<br>
> moving forward.<br>
><br>
><br>
><br>
> We cannot make it mandatory to run the 2 filters but we can say in the<br>
> documentation that if these two filters aren't set that we cannot<br>
> guaranty Anti-affinity or Affinity.<br>
><br>
><br>
> The other way we can implement this is by using availability zones and<br>
> host aggregates. This is one technique we use to make sure we deploy<br>
> our in-cloud services in an HA model. This also would assume that the<br>
> operator is setting up Availabiltiy zones which we can't.<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 host<br>
> affinity which is probably due to the fact that they did the work<br>
> before ServerGroups. I am not advocating the use of those filters but<br>
> just showing you that we can document the feature and it 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 there is no<br>
> ability to control where machine is actually running. We cannot be<br>
> sure that two new virtual machines are started on different physical<br>
> machines. As a result, any replication with cluster is not reliable<br>
> because all replicas may turn up on one physical machine.<br>
> Anti-affinity feature provides an ability to explicitly tell Sahara to<br>
> run specified processes on different compute nodes. This is especially<br>
> useful for Hadoop datanode process to make HDFS replicas reliable.<br>
> The Anti-Affinity feature requires certain scheduler filters to be<br>
> enabled on Nova. Edit your/etc/nova/nova.conf in the following way:<br>
><br>
> [DEFAULT]<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>
> <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 colocation and<br>
> apolocation<br>
> for VMs. I think this is something we've discussed before<br>
> about taking<br>
> advantage of nova's scheduling. I need to verify that this<br>
> will work<br>
> with what we (RAX) plan to do, but I'd like to get everyone<br>
> else's<br>
> thoughts. Also, if we do decide this works for everyone<br>
> involved,<br>
> should we make it mandatory that the nova-compute services are<br>
> running<br>
> these two filters? I'm also trying to see if we can use this<br>
> to also do<br>
> our own colocation and apolocation on load balancers, but it<br>
> looks like<br>
> it will be a bit complex if it can even work. 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>
> <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>
> <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><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>