mirror of https://github.com/apache/cloudstack.git
ebc70a51e2
Reimplement router.redundant.vrrp.interval settingGlobal setting `router.redundant.vrrp.interval` is not used any more and it is now set to a hardcoded 1. This results in a failover from master->backup when the backup doesn't hear from the master in ~3.6sec. This is a bit too tight, as we've seen failovers during live migrations. We could reproduce it in about half of the cases. Setting this to setting to 2 (tested it by hardcoding it in the systemvms) gives twice as much time and we didn't see issues any more. Instead of updating the hardcoded setting from 1 to 2, I reimplemented the global setting by sending it to the router with the cmd_line, as the non-VPC router also does. Background: Why is the maximum failover time in the example 3.6 seconds? This comes from the advertisement interval and the skew time. The default advertisement interval is 1 second (configurable in keepalived.conf). The skew time helps to keep everyone from trying to transition at once. It is a number between 0 and 1, based on the formula (256 - priority) / 256 As defined in the RFC, the backup must receive an advertisement from the master every (3 * advert_int) + skew_time seconds. If it doesn't hear anything from the master, it takes over. With a backup router priority of 100 (as in the example), the failover will happen at most 3.6 seconds after the master goes down. Source: http://www.hollenback.net/KeepalivedForNetworkReliability * pr/1486: Configure rVPC for router.redundant.vrrp.interval advert_int setting Have rVPCs use the router.redundant.vrrp.interval setting Signed-off-by: Will Stevens <williamstevens@gmail.com> |
||
|---|---|---|
| .. | ||
| bindir | ||
| certs | ||
| conf | ||
| conf.dom0 | ||
| css | ||
| distro | ||
| images | ||
| js | ||
| libexec | ||
| patches/debian | ||
| scripts | ||
| test/python | ||
| ui | ||
| vm-script | ||
| pom.xml | ||
| systemvm-descriptor.xml | ||