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.
Two Ubuntu 16.04 LTS x64 server instances (master and backup server).
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.
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).
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
}
}
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
}
}
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
Keepalived works without issues on Vultr, and is ready for all of your high availability architecture designs.