Open Stack

Yeah we were looking at the SameHost and DifferentHost filters and that
will probably do what we need.  Though I was hoping we could do a
combination of both but we can make it work with those filters I
believe.

Thanks,
Brandon

On Thu, 2014-08-28 at 14:56 -0400, Susanne Balle wrote:
> Brandon
> 
> 
> 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.
> 
> 
> 
> 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. 
> 
> 
> 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.
> 
> 
> http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/
> 
> 
> 
> 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.
> 
> 
> Regards
> 
> 
> Susanne 
> 
> 
> 
> Anti-affinity
> 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.
> The Anti-Affinity feature requires certain scheduler filters to be
> enabled on Nova. Edit your/etc/nova/nova.conf in the following way:
> 
> [DEFAULT]
> 
> ...
> 
> scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
> scheduler_default_filters=DifferentHostFilter,SameHostFilter
> This feature is supported by all plugins out of the box.
> 
> 
> http://docs.openstack.org/developer/sahara/userdoc/features.html
> 
> 
> 
> 
> 
> On Thu, Aug 28, 2014 at 1:26 AM, Brandon Logan
> <brandon.logan at rackspace.com> wrote:
>         Nova scheduler has ServerGroupAffinityFilter and
>         ServerGroupAntiAffinityFilter which does the colocation and
>         apolocation
>         for VMs.  I think this is something we've discussed before
>         about taking
>         advantage of nova's scheduling.  I need to verify that this
>         will work
>         with what we (RAX) plan to do, but I'd like to get everyone
>         else's
>         thoughts.  Also, if we do decide this works for everyone
>         involved,
>         should we make it mandatory that the nova-compute services are
>         running
>         these two filters?  I'm also trying to see if we can use this
>         to also do
>         our own colocation and apolocation on load balancers, but it
>         looks like
>         it will be a bit complex if it can even work.  Hopefully, I
>         can have
>         something definitive on that soon.
>         
>         Thanks,
>         Brandon
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev