Open Stack

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