Open Stack

Trevor and I just worked through some scenarios to make sure it can
handle colocation and apolocation.  It looks like it does, however not
everything will so simple, especially when we introduce horizontal
scaling.  Trevor's going to write up an email about some of the caveats
but so far just using a table to track what LB has what VMs and on what
hosts will be sufficient.

Thanks,
Brandon

On Thu, 2014-08-28 at 13:49 -0700, Stephen Balukoff wrote:
> 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.
> 
> 
> Stephen
> 
> 
> On Thu, Aug 28, 2014 at 1:13 PM, Brandon Logan
> <brandon.logan at rackspace.com> wrote:
>         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
>         
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         
> 
> 
> 
> 
> -- 
> Stephen Balukoff 
> Blue Box Group, LLC 
> (800)613-4305 x807
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev