<div dir="ltr">Brandon<div><br></div><div>I am not sure how ready that nova feature is for general use and have asked our nova lead about that. He is on vacation but should be back by the start of next week. I believe this is the right approach for us moving forward.<br>
</div><div><br></div><div>We cannot make it mandatory to run the 2 filters but we can say in the documentation that if these two filters aren't set that we cannot guaranty Anti-affinity or Affinity. </div><div><br></div>
<div>The other way we can implement this is by using availability zones and host aggregates. This is one technique we use to make sure we deploy our in-cloud services in an HA model. This also would assume that the operator is setting up Availabiltiy zones which we can't.</div>
<div><br></div><div><a href="http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/">http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/</a><br>
</div><div><br></div><div>Sahara is currently using the following filters to support host affinity which is probably due to the fact that they did the work before ServerGroups. I am not advocating the use of those filters but just showing you that we can document the feature and it will be up to the operator to set it up to get the right behavior.</div>
<div><br></div><div>Regards</div><div><br></div><div>Susanne <br></div><div><span style="color:rgb(38,77,105);font-family:'PT Sans',sans-serif;font-size:21.81818199157715px"><br></span></div><div><span style="color:rgb(38,77,105);font-family:'PT Sans',sans-serif;font-size:21.81818199157715px">Anti-affinity</span></div>
<div><span style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:14.545454025268555px;line-height:1.5em">One of the problems in Hadoop running on OpenStack is that there is no ability to control where machine is actually running. We cannot be sure that two new virtual machines are started on different physical machines. As a result, any replication with cluster is not reliable because all replicas may turn up on one physical machine. Anti-affinity feature provides an ability to explicitly tell Sahara to run specified processes on different compute nodes. This is especially useful for Hadoop datanode process to make HDFS replicas reliable.</span></div>
<div><p id="enable-anti-affinity" style="line-height:1.5em;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:14.545454025268555px">The Anti-Affinity feature requires certain scheduler filters to be enabled on Nova. Edit your<tt class="" style="color:rgb(34,34,34);font-size:1.1em;background-color:rgb(236,240,243)"><span class="">/etc/nova/nova.conf</span></tt> in the following way:</p>
<div class="" style="color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:14.545454025268555px"><div class="" style="background-image:initial;background-repeat:initial"><pre style="overflow:auto;padding:10px;color:rgb(85,85,85);line-height:1.2em;border:1px solid rgb(198,201,203);font-size:1.1em;margin-top:1.5em;margin-bottom:1.5em">
[DEFAULT]
...
scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
scheduler_default_filters=DifferentHostFilter,SameHostFilter
</pre></div></div><p style="line-height:1.5em;color:rgb(62,67,73);font-family:Arial,sans-serif;font-size:14.545454025268555px">This feature is supported by all plugins out of the box.</p></div><div><a href="http://docs.openstack.org/developer/sahara/userdoc/features.html">http://docs.openstack.org/developer/sahara/userdoc/features.html</a><br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 1:26 AM, 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">Nova scheduler has ServerGroupAffinityFilter and<br>
ServerGroupAntiAffinityFilter which does the colocation and apolocation<br>
for VMs. I think this is something we've discussed before about taking<br>
advantage of nova's scheduling. I need to verify that this will work<br>
with what we (RAX) plan to do, but I'd like to get everyone else's<br>
thoughts. Also, if we do decide this works for everyone involved,<br>
should we make it mandatory that the nova-compute services are running<br>
these two filters? I'm also trying to see if we can use this to also do<br>
our own colocation and apolocation on load balancers, but it looks like<br>
it will be a bit complex if it can even work. Hopefully, I 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>
</blockquote></div><br></div>