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
