I think monit is installed currently in the system vm image. Sounds like it
might make more sense to manage haproxy via monit, and allow it to recover the
service should it fail.
----- Original Message -----
From: "Sheng Yang" <sh...@yasker.org>
To: "<dev@cloudstack.apache.org>" <dev@cloudstack.apache.org>
Cc: "Daan Hoogland" <daan.hoogl...@gmail.com>, "int-cloud"
<int-cl...@schubergphilis.com>
Sent: Tuesday, September 17, 2013 6:10:42 PM
Subject: Re: HA redundant virtual router
No, it's not intentional.
the HAproxy is a part of services that redundant router would
enable/disabled according to the MASTER/BACKUP status. All the services
related to redundant router are controlled by services.sh.
What's the failure of HAproxy exactly in your case? And what's the root
cause?
Also, I think just yield due to haproxy failure won't help much since
effort still needed for CS to recover the situation, at least it would need
to notify admin. Better transiting to FAULT state if it's a critical error.
--Sheng
On Tue, Sep 17, 2013 at 12:07 AM, Sten Spans <s...@blinkenlights.nl> wrote:
> On Mon, 16 Sep 2013, Sheng Yang wrote:
>
> The reason for no HA as I said before, due to the complexity. E.g, if
>> there
>> can be 3 routers in the network(which control network is down but not the
>> guest network), and it would cause two of them with the same priority(at
>> certain time). The doc is mainly for describing the current policy and
>> reason, as the basic for possible improvement.
>>
>> I haven't thought much about redundant router with HA, but many times
>> we're
>> dealing with intermittent network issue, so you try to plug off then plug
>> in the network cable to see if HA works as expect.
>>
>> The priority cannot changed on the fly, it's a parameter of keepalived
>> process, which is running. So at least both router need to be stopped
>> before priority reset. And it's not reset to minimum, since the value can
>> go up or down based on the different cases.
>>
>
> Looking at the doc you wrote I see no mention of HAProxy.
> Is this intentional?
>
> A failure of HAProxy (which we've observed in practice) would
> result in a loss of service for loadbalanced ports.
>
> Currently I'm thinking of adding something like the following:
>
> diff -Nru keepalived.conf.templ.orig keepalived.conf.templ
> --- keepalived.conf.templ.orig 2013-09-17 09:02:28.410646521 +0200
> +++ keepalived.conf.templ 2013-09-17 09:03:34.131434084 +0200
> @@ -19,6 +19,12 @@
> router_id [ROUTER_ID]
> }
>
> +vrrp_script check_haproxy {
> + script "/usr/bin/killall -0 haproxy"
> + interval 5
> + weight 10
> +}
> +
> vrrp_script check_bumpup {
> script "[RROUTER_BIN_PATH]/check_**bumpup.sh"
> interval 5
> @@ -47,6 +53,7 @@
> }
>
> track_script {
> + check_haproxy
> check_bumpup
> heartbeat
> }
>
>
> This would boost vrrp priorities if haproxy is running, trigger
> a failover if it fails, and should be harmless on hosts not running
> haproxy.
>
> --
> Sten Spans
>
> "There is a crack in everything, that's how the light gets in."
> Leonard Cohen - Anthem
>
