Open Stack

On 2 June 2013 15:13, Alexandra Kisin <KISIN at il.ibm.com> wrote:

> 1. Does Pacemaker is the preferred tool to base OpenStack HA solution on ?
> 2. Are there any alternatives for Pacemaker ?
>

We've tried both pacemaker and the keepalived/haproxy combo.

Pacemaker works well for active/passive configurations. It's ideal when you
only want a service to run on one node, as it will shut down the service on
the other node(s) when the service moves. Pacemaker also has the advantage
of using multicast or unicast configurations (vs keepalived which *has* to
use multicast). The downside to pacemaker is that it's a little harder to
configure and takes a little more experience to manage.

Keepalived provides for active/passive configurations as well, but is
easier to install and manage. As mentioned, though, it only uses multicast
(VRRP, in fact).

HAProxy does load balancing, but also keeps an eye on the availability of
the services. This provides a level of HA too.

Note that almost all of Openstack's services can run active-active if you
implement it correctly (usually combined with memcached). There is
therefore little need for active/passive clusters. The only place where
active/passive setups are needed is for your database (eg: MySQL) or your
message queue (eg: RabbitMQ). Even then, both of those can be configured to
be active-active in a cluster.

In the automated deployments used by Rackspace Private Cloud and Mirantis
FUEL they both use keepalived & haproxy. Keepalived is used to provide
virtual IP's to run the services on which are exposed through haproxy,
which then distributes the load accordingly. You can read up on the high
level architectures on their respective websites.


> 4. Is the guide mentioned above can be used in continue to the basic
> Grizzly installation guide or any additional steps should be performed
> before ?
>

There are many different ways to deploy Openstack, which is both a strength
and a weakness. The documenters try to capture common methods but are
reliant on contributors to provide the right information. Once you've
decided on an architecture and figured out how to implement it the
community would welcome a documentation submission!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130604/7c7e9e82/attachment.html>