mirror of
https://github.com/apache/cloudstack.git
synced 2025-10-26 08:42:29 +01:00
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>
####################################################
Note there is a new systemvm build script based on
Veewee(Vagrant) under tools/appliance.
####################################################
1. The buildsystemvm.sh script builds a 32-bit system vm disk based on the Debian Squeeze distro. This system vm can boot on any hypervisor thanks to the pvops support in the kernel. It is fully automated
2. The files under config/ are the specific tweaks to the default Debian configuration that are required for CloudStack operation.
3. The variables at the top of the buildsystemvm.sh script can be customized:
IMAGENAME=systemvm # dont touch this
LOCATION=/var/lib/images/systemvm #
MOUNTPOINT=/mnt/$IMAGENAME/ # this is where the image is mounted on your host while the vm image is built
IMAGELOC=$LOCATION/$IMAGENAME.img
PASSWORD=password # password for the vm
APT_PROXY= #you can put in an APT cacher such as apt-cacher-ng
HOSTNAME=systemvm # dont touch this
SIZE=2000 # dont touch this for now
DEBIAN_MIRROR=ftp.us.debian.org/debian
MINIMIZE=true # if this is true, a lot of docs, fonts, locales and apt cache is wiped out
4. The systemvm includes the (non-free) Sun JRE. You can put in the standard debian jre-headless package instead but it pulls in X and bloats the image.
5. You need to be 'root' to run the buildsystemvm.sh script
6. The image is a raw image. You can run the convert.sh tool to produce images suitable for Citrix Xenserver, VMWare and KVM.
* Conversion to Citrix Xenserver VHD format requires the vhd-util tool. You can use the
-- checked in config/bin/vhd-util) OR
-- build the vhd-util tool yourself as follows:
a. The xen repository has a tool called vhd-util that compiles and runs on any linux system (http://xenbits.xensource.com/xen-4.0-testing.hg?file/8e8dd38374e9/tools/blktap2/vhd/ or full Xen source at http://www.xen.org/products/xen_source.html).
b. Apply this patch: http://lists.xensource.com/archives/cgi-bin/mesg.cgi?a=xen-devel&i=006101cb22f6%242004dd40%24600e97c0%24%40zhuo%40cloudex.cn.
c. Build the vhd-util tool
cd tools/blktap2
make
sudo make install
* Conversion to ova (VMWare) requires the ovf tool, available from
http://communities.vmware.com/community/vmtn/server/vsphere/automationtools/ovf
* Conversion to QCOW2 requires qemu-img