How to setup floating IP using keepalived

Services that require high availability typically use floating IPs. Floating IP address can be transferred between multiple servers allowing for failover or upgrading of production software.

This article will guide you through basic setup of floating IP using the keepalived software on CentOS 7. The keepalived software uses VRRP protocol and IP multicasting for communication between servers.

Pre-requirements

Dedicated servers

Floating IP address setup is possible only with dedicated servers, but not cloud servers.

Layer 2 segment

Servers have to be joined into the same layer 2 segment (i.e. VLAN). Please note, that creation of custom L2 segments is available in selected locations, so the servers must be in an eligible location. You can view eligible locations in the L2 segment creation dialog in the Customer Portal.

Creating L2 segment and leasing IP alias

Let's say we have two dedicated servers in the DFW1 location, named "master-keepalived" and "slave-keepalived".

Now we need to create a new L2 segment in "Networks > L2 segments" section of the Customer Portal. The type of VLAN is "Native" as we only use one VLAN, and the type is "External" because we will be using public address space. Name is irrelevant, and we need to add both of our servers to the hosts subsection.

It takes 3-5 minutes for new segment to be created. Use the "Refresh" button next to the segment status to check if the status has changed from "pending" to "active".

After the segment became active, we need to add an IP alias, which will be the floating IP. Add one, click "Save".

Setting up keepalived

Install and enable keepalived daemon on both servers:

yum install keepalived
systemctl enable keepalived

In our demo configuration we have two servers: MASTER and BACKUP. The floating IP address is assigned to the MASTER in normal course of action. Responsibility of the BACKUP server is to take over the floating IP and the load from the MASTER server in case of its failure, and vice versa.

MASTER's config (/etc/keepalived/keepalived.conf) looks like following:

! Configuration File for keepalived
global_defs {
   router_id uMASTER
}

vrrp_instance VI_1 {
    state MASTER
    interface agge
    virtual_router_id 230
    priority 101                        # PAY ATTENTION ON PRIORITY!!
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass SecPassWord              #changepass if need
    }


   virtual_ipaddress {
       173.0.146.251/32 dev agge label agge:0
    }
}

BACKUP's config (/etc/keepalived/keepalived.conf) looks like following:

! Configuration File for keepalived
global_defs {
   router_id uBACKUP
}

vrrp_instance VI_1 {
    state BACKUP
    interface agge
    virtual_router_id 230
    priority 100                        # PAY ATTENTION ON PRIORITY!!
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass SecPassWord              #changepass if need
    }


   virtual_ipaddress {
       173.0.146.251/32 dev agge label agge:0
    }
}

Some notes on configuration file:

state BACKUP, MASTER - defines the role of a server
173.0.146.251/32 dev agge label agge:0 - sets the network interface to which the floating IP address will be assigned.

Now we are ready to start keepalived on both servers:

systemctl start keepalived

Testing failover

You can see in the ifconfig output, that the floating IP is assigned to the MASTER server by default:

# ifconfig
agge:0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 1500
        inet 173.0.146.251  netmask 255.255.255.255  broadcast 0.0.0.0
        ether 20:47:47:85:e4:3e  txqueuelen 1000  (Ethernet)

To test failover, start pinging the floating IP, then stop keepalived on the MASTER:

systemctl stop keepalived

You will see short timed packet loss in the ping output, which takes place while the BACKUP server takes floating IP over:

ping 173.0.146.251


64 bytes from 173.0.146.251: icmp_seq=59 ttl=53 time=260.582 ms
64 bytes from 173.0.146.251: icmp_seq=60 ttl=53 time=314.723 ms
64 bytes from 173.0.146.251: icmp_seq=62 ttl=53 time=498.176 ms
64 bytes from 173.0.146.251: icmp_seq=63 ttl=53 time=167.139 ms
Request timeout for icmp_seq 64                                <----------------------------
64 bytes from 173.0.146.251: icmp_seq=65 ttl=53 time=597.598 ms
64 bytes from 173.0.146.251: icmp_seq=66 ttl=53 time=172.361 ms
64 bytes from 173.0.146.251: icmp_seq=67 ttl=53 time=240.334 ms

Suggested Articles