Ball Dawg!

I’ve had a “backup” puppet server for some time now, but the fail-over was completely manual. Meaning if the main puppet server failed, I’d actually need to change DNS to point to the other server. This if fine for environments where a bit of downtime does not hurt, but in a production environment it’s less than ideal. When I had a bit of spare time recently I decided to implement an automatic fail over for our environment. To do this I decided to use HAProxy for the load balancing and keepalived to manage a virtual IP.


This setup assumes that when you setup your puppet master you didn’t use the actual machine name as the puppet server name in your puppet.conf. For example, in my case I used puppet.domain.com, as apposed to the actual DNS name of the machine it lives on. puppet.domain.com is just a CNAME to the machines DNS name, but since web based SSL is based off the DNS name you are connecting too I can float different machines behind puppet.domain.com and the client is none the wiser. To do it you’ll need to sign puppet.machine.com with puppetca and mirror your CA to your backup machine.

To make this setup work, first you’ll need a virtual IP to point puppet.machine.com at and setup keepalived to manage it. The keepalived setup was fairly straight forward, both machines were on the same network so I just picked an IP and configured keepalived on each machine. In my case the configurations were as follows:

vrrp_instance VI_1 {
        interface bond0
        state MASTER
        virtual_router_id 51
        priority 101
        authentication {
            auth_type PASS
            auth_pass PASSWORD
        }
        virtual_ipaddress {
                192.168.33.61/26 dev bond0
        }
        notify_master /sw/keepalived/scripts/notify_master.sh
        notify_backup /sw/keepalived/scripts/notify_backup.sh
        notify_fault /sw/keepalived/scripts/notify_backup.sh
}

Basically for bonded interface 0, add the virtual interface of 192.168.33.61/26, and this machine has a priority of 101, or master. The three entries at the bottom are what to run if the machine should fail over or fail back. The other machine has a similar setup, except it has the priority of 100, or backup.

After starting up keepalived on both machines, they negotiate and the machine with the higher priority ends up with the IP enabled on bond0 as a secondary address.

Next I needed something to manage fail-over of the puppet “service” should the interface/IP stay up and just the puppet service fail. For this I decided to use HAProxy. It’s configuration is, again, fairly straight forward. You need to setup a front end to listen on the default puppet master port, and a back end that has both your puppet master machines in it. The configuration is as follows:

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     10000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    log                     global
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 8000

frontend        puppet 192.168.33.61:8140
    mode tcp
    default_backend     puppet0

backend puppet0
    mode        tcp
    option      ssl-hello-chk
    balance     roundrobin
    server      server1 192.168.33.17:8140 check
    server      server2 192.168.33.27:8140 check backup

This configuration and the installation of haproxy is mirrored on the second server.

Now if you recall I had some scripts that were to run should keepalived feel the need to fail to/from the backup server. Because haproxy binds to the address on start up, you can’t have it running on your backup server. To work around the script is run upon keepalived starting that IP on the system, the script starts haproxy.

With the complicated part done, it was just a matter of mirroring my puppet manifests and files between the two machines, and making sure they stay up to date. Ideally you’d have them on some sort of NAS which is just mounted on both machines which would make them being out of date impossible.