Ha fip

This article is a draft

This is not a complete article: This is a draft, a work in progress that is intended to be published into an article, which may or may not be ready for inclusion in the main wiki. It should not necessarily be considered factual or authoritative.

Floating IP High Availability

A single VM hosting an application can fail and be offline, which also makes the application inaccessible.

To avoid such a scenario, it is possible to make the floating IP (FIP) high-available, which in turn can be used to make the application high available too.

• 206.12.93.117 - Public IP the world is connecting to

• 192.168.27.251 - Internal Virtual IP, own by the current active system

• vrrp - virtual router redundancy protocol, determines the systems status

The 2 systems communicate via vrrp and determine it's status, as long as the MASTER system responds, the other system will stay in BACKUP mode.

If the MASTER system stops responding, the system will change from BACKUP into MASTER and brings up the internal IP address 192.168.27.251m which it will no be reachable on.

The public IP 206.12.93.117 will be always forward any traffic to the VIP, as long as there is a system reachable via the VIP, your application will be reachable.

---

Active-Passive High-Availability

The scenario in this document describes am active-passive system, where one system is own the VIP and receives all the network traffic for that IP address, while the other one simply stands by as backup system if the current active one fails or becomes unreachable.

There are many way on how to achieve this goal and it depends on the desired outcome what needs to be done and configured.

The setup described below will only make sure that a system is reachable via IP, it will not take care of the availability of your application data, such a files, or it's services, such a a running webserver software.

This example setup will use:

1. 2 VMs hosting the application
2. 1 VIP (shared IP) RFC1918 from within your project
3. 1 HA Floating IP

Now it's time to build the 2 VMs and install the application on both systems, this example here will only have nginx running, displaying the default index page and show that the application is reachable.

---

Step 1: Installing nginx and keepalived

After successfully building the 2 VMs, which will share the internal VIP, install nginx and keepalived.

root@web-srv-1:~# apt-get update && apt-get -y dist-upgrade && apt-get install -y nginx keepalived
[...]
root@web-srv-2:~# apt-get update && apt-get -y dist-upgrade && apt-get install -y nginx keepalived
[...]

---

Step2: Allocating an internal VIP

IP addresses are unique identifiers, which is true within an internal, private network too, therefore we have to make sure to select a VIP which is not already used.

In the left menu, go to Network --> Networks --> your-projectname-network.

Select Ports in the the upper tab.

The network range in the example is from 192.168.27.1-254, all currently allocated addresses are listed in this port list.

Once you have chosen an IP address you want to use and which is not in the port list, go to Compute --> Instances and select the first VM which can later use this VIP.

Select the projects network in the Interfaces tab, then use the tab Allowed Address Pair.

Enter the VIP you have chose earlier via the button Add Allowed Address Pair.

Repeat the exact same steps on the second server and confirm both have the IP address in the Allowed Address Pair

Configure keepalived

Log in into your VM you want to configure as the active system and create the file /etc/keepalived/keepalived.conf.

root@web-srv-1:~# vi /etc/keepalived/keepalived.conf

/etc/keepalived/keepalived.conf on the active system:

vrrp_instance VI_1 {
    state MASTER <-- declare the system as the active system
    interface ens3 <-- NIC of the internal network
    virtual_router_id 50
    priority 100 <-- higher priority means leading node
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass EcbCp2b1 <-- generate a new password
    }
    virtual_ipaddress {
      192.168.27.251
    }
    unicast_peer {
        192.168.27.127  <-- internal IP of the standby system 
    }
}

/etc/keepalived/keepalived.conf on the passive system:

vrrp_instance VI_1 {
    state BACKUP <-- declare the system as the standby
    interface ens3 
    virtual_router_id 50
    priority 50 <-- lower priority if there is a higher on one the network, the higher one takes precedence.
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass EcbCp2b1
    }
    virtual_ipaddress {
      192.168.27.251
    }
    unicast_peer {
        192.168.27.116  <--- IP address of the active system
    }
}

Make sure you allow the vrrp traffic between the systems, in your Security Groups and make sure it is attached to you systems.