[Openstack-docs] OpenStack HA Guide - Moving forward to Active / Active Setup
Florian Haas
florian at hastexo.com
Tue Apr 30 17:44:14 UTC 2013
Hey Emilien,
sorry for the delayed response. Comments inline.
On Fri, Apr 26, 2013 at 11:50 PM, Emilien Macchi
<emilien.macchi at enovance.com> wrote:
> Hi,
>
>
> Today the OpenStack HA guide written by Florian Haas and my self needs
> to be updated from active / passive to active / active mode.
Sorry to barge in here, but as I've said in the past, including my
Summit talk, it's unfortunately not quite that clean-cut. We don't
have an active/active story for all OpenStack components, not even for
all of the core/integrated projects.
> Since some services have been updated in Grizzly, I would like to submit
> a new documentation explaining how to configure this setup :
>
> - API nodes (all OpenStack APIs) -> load balanced by HAproxy (I'll share
> my running configuration)
Well HAProxy is great, but despite its name it's a bit of a misnomer.
HAProxy can itself be made highly available, and it can proxy _to_
highly available services, but it doesn't ensure that a backend
service (or a configurable number of backend services) is in fact
running, nor does it recover them when they fail, right? So what is
your proposed story for supporting the "I need X instances of API
service Y across these Z nodes" use case?
> - Scheduler nodes (*-scheduler + nova-conductor) -> Multiple running :
> horizontal scale
Same question as above applies. :)
> - Compute nodes (nova-compute + Quantum L3 Agent + Quantum DHCP Agent +
> Quantum L2 Agent + Quantum Metadata Agent) : no HA, but scaling of
> Quantum L3 & DHCP agents
nova-compute can actually made HA just fine. It's not super elegant,
but it works. In an active/passive configuration for individual
compute pairs, we can do this today with just the nova-compute upstart
job and a virtual IP for novncproxy to connect to. Active/active would
just require another OCF resource agent.
> - Storage node (cinder-volume) -> can't be run in full HA as far I know.
Yes it can. Very easy if your storage backend is non-local (such as
RBD), only involves overriding --host in cinder.conf and using a
virtual IP to bind Cinder to. With the iSCSI backend, it gets a bit
trickier (actually it gets rather ugly), but I see no problems with
just documenting "if you want Cinder in an HA configuration, here are
the recommended backends: X, Y, Z".
> - RabbitMQ cluster
This should work fine with anything that uses Kombu 2.5.0+.
> - MySQL Cluster (Galera)
This I'm not 100% sure of. Galera with --wsrep_causal_reads=1 might
work fine, but you'd still need a virtual IP to connect to it. Or do
you suggest to do this with HAProxy as well?
> Then, I'll like to know what is the best choice :
> - Split the guide in two parts : Active / Active & Active / Passive ?
Yes, this is the only viable option as far as I can see.
> - Drop Active / Passive part and updating it for Active / Active setup ?
Not possible just yet in my opinion, but by all means please feel free
to correct me.
What do others think?
Cheers,
Florian
More information about the Openstack-docs
mailing list