From a Hi-Availability point of view, I would say that
1.
HAProxy is the mechanism to manage multiple copies of actual openstack services (e.g.
MariaDB).
So when one service stops, HAProxy will load-balance or fail-over to the rest instance(s),
and such services will not be single point of failure.
2. Similarly, we need a fail-over mechanism for HAProxy, or the HAProxy will be a single
point of failure. And hence the pacemaker.
We use pacemaker to ensure that when one HAProxy service (instance) fails, some other
instance will take over.
Best regards,
Bruce Tan
On 15 Dec 2016, at 16:54, Raoul Scarazzini <rasca(a)redhat.com>
wrote:
On 15/12/2016 09:42, Dotan, Alon wrote:
> So if understood correctly HAproxy is basically a component in pcs?
It is a systemd resource managed by Pacemaker.
--
Raoul Scarazzini
rasca(a)redhat.com
> -----Original Message-----
> From: Raoul Scarazzini [mailto:rasca@redhat.com]
> Sent: Thursday, December 15, 2016 10:33 AM
> To: Dotan, Alon <alon.dotan(a)hpe.com>; rdo-list(a)redhat.com
> Subject: Re: [rdo-list] tripleo ha topology
>
> On 14/12/2016 22:59, Dotan, Alon wrote:
>> Hey,
>> Some can provide link or explanation about the use of haproxy and
>> pacemaker together in tripleo?
>> Why need pcs if there is galera and haproxy?
>
> Galera is managed via a specific resource agent which takes care of all the stuff
needed to start, stop and, most of all, recover. It automates a lot of tasks which
otherwise will be manual.
>
> Haproxy is managed by Pacemaker because of the Vips. There are specific constraints
that ensures that whether a Vip change the host, haproxy service will follow.
>
> Hope this helps,
>
> --
> Raoul Scarazzini
> rasca(a)redhat.com
>
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com