High Availability Using Private Networking on Ubuntu 16.04 With Keepalived

Last Updated: Fri, Mar 9, 2018
Linux Guides Load Balancer Scaling System Admin Ubuntu
Archived content

This article is outdated and may not work correctly for current operating systems or software.

Some high availability architectures require a floating IP address. This functionality is available on the Vultr platform once private networking has been enabled. Vultr offers an IP range in each private network: "You can use any IPs you like on the private network. We assign one IP by default, but you can ignore it and use other ones if you like.". Therefore, we can use any virtual IP within the private IP range. This example features a passive/active setup. The master server will claim the floating IP unless the server goes down. If the master server is down, the floating IP will be claimed by the backup server.

Note: Your network adapter names may not match the examples. See our article How to Find the Network Adapter Names for a Vultr Cloud Server.

Prerequisites

Preparing the system

Start by enabling the private network on each VPS. This feature has been well documented.

Log into each system as a sudo user, and update the system and its packages:

apt-get update && apt-get upgrade 

Once this is done, we are ready to start with installing and configuring Keepalived.

Installing Keepalived

Now that each system is up-to-date and has a private IP, you can install Keepalived on both of them.

apt-get install keepalived

This will install the high availability daemon. Keepalived is a program that provides high availability and load balancing functionality based on the Virtual Router Redundancy Protocol (VRRP).

Master server

On the master server, edit the Keepalived configuration file.

nano /etc/keepalived/keepalived.conf

The virtual_ipaddress is the IP we will be floating between servers. The priority defines who will own the IP. For the master, we will use a priority of 200.

We will be using the 10.99.0.200 as our floating virtual IP.

vrrp_instance VI_1 {

    state MASTER

    interface ens7

    virtual_router_id 51

    priority 200

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass thisismysupersecretpassword

    }

    virtual_ipaddress {

        10.99.0.200

    }

}

Backup server

On the backup server, edit the Keepalived configuration file.

nano /etc/keepalived/keepalived.conf

Here we will define the virtual_ipaddress just like on the master server. The difference here is that the priority of this server is lower, so it will only claim the IP when the master is not online.

vrrp_instance VI_1 {

    state BACKUP

    interface ens7

    virtual_router_id 51

    priority 100

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass thisismysupersecretpassword

    }

    virtual_ipaddress {

        10.99.0.200

    }

}

Usage and testing

Once both Keepalived services are configured, start each service and enable it at boot.

systemctl start keepalived

systemctl enable keepalived

On a third server (or on the backup server) start by pinging our shared IP:

ping 10.99.0.200

Now reboot the master server and watch the IP move to the backup server. This is usually indicated by a small increase in ping latency.

64 bytes from 10.99.0.200: icmp_seq=80 ttl=64 time=0.384 ms

64 bytes from 10.99.0.200: icmp_seq=81 ttl=64 time=1.33 ms    <<< failover has happened

64 bytes from 10.99.0.200: icmp_seq=82 ttl=64 time=0.388 ms

64 bytes from 10.99.0.200: icmp_seq=83 ttl=64 time=0.339 ms

64 bytes from 10.99.0.200: icmp_seq=84 ttl=64 time=0.570 ms

Conclusion

Keepalived works without issues on Vultr, and is ready for all of your high availability architecture designs.

Want to contribute?

You could earn up to $600 by adding new articles.