High Availability on Linux: The service IP address, part 1

In the previous post we saw what is high availability and what we address when a consumer tries to access a service: The closest possible availability time to 100%.

This entry describes what is the service IP address -entry point to them- and how to setup it using two servers.

To implement the things described under these lines is necessary to have two physical or virtual servers and a Linux distribution installed on them.

In order to avoid excessively long entries, I splitted this one into two parts. This first part is an introduction and preparation of systems, while the second shows how to setup the proper service IP address.

The service IP address

When we access to a service the connection is made to an IP address, in a direct way (192.0.2.100) or through a host name (www.example.com).

Suppose we want to access to a web page (http://www.example.com) and that its associated IP address is “192.0.2.100”. This IP address, through which the page is accessible, is called the “service IP address”.

The objective is to have this IP address always available. For consumers the perception should be like the following image:

To achieve it, having a minimum of two servers, one will have the service IP address assigned and the other will be waiting just in case the first one fails to take it.

If server “server-1” wasn’t functional, then server “server-2” would use the service IP address. The service will be degraded -one component in fail state- but operative and accesible for the consumer.

If no server is available the service cannot be given as the service IP address cannot be assigned to none of them.

The consumer can’t access the service. It perception will vary:

The method which allows a server to use a service IP address previously assigned to other one when it becomes unavailable is called “IP failover”.

Multiple standard protocols which implements IP failover methods exists, being VRRP the most famous of them and the one we will be using.

Required setup

Before we start we must have the necessary material prepared.

We will use two servers called “server-1” and “server-2”. I have used Debian 8, but this configuration is practically identical on other distributions like CentOS except where network configuration file path and software installation command varies.

Both servers are connected through “eth0” network interface to a switch and belongs to 192.0.2.0/24 subnet. The switch is connected to a router whose IP address is 192.0.2.1 and acts as a gateway.

The following diagram shows the equipment interconnection:

We will note both servers information for further reference:

System preparation

In Linux multiple VRRP protocol implementations exists. On these articles we are going to use “keepalived” for its extra functionality, but another valid option would be “vrrpd“.

The following steps must be done in both servers.

Depending on the choosen distribution  we may install “keepalived” with “apt” or “yum”:

We also need to load and configure the “dummy” kernel module on the server. It provides a virtual network interface where the service IP address will be assigned.

To load and make it permanent across server reboots we need to run:

To configure it and make it permanent across server reboots we need to run:

Once loaded we will verify that “dummy0″ interface is available:

We’ll leave the interface ready to use:

We need a last change on the operating system: We should allow processes (programs running in the background) to listen network requests on an IP address that doesn’t belong to them.

As the service IP address will be assigned to an unique server, the other one doesn’t have it, so it won’t allow programs to use it to listen for data. That implies,  once the service IP address changes from server, accessing to the server which has the address in such moment and run the necessary programs that, now successfully, can use such IP address.

This will limit us so much and we don’t met the “high availability” premise -The service IP address changes from one server to another, but programs won’t run without manual (human) intervention- so we will configure the system to allow processes to listen on any IP address, even if doesn’t belong to it.

At this point we will verify the following:

– Keepalived software is installed:

– The “dummy” module is loaded and configured:

– The “dummy0” interface exists and is ready to listen:

– The system has the net.ipv4.ip_nonlocal_bind variable set to 1:

Once everything has been checked, we can start configuring the service IP address, but this will be on the next entry on this serie.

Esta entrada también está disponible en: esEspañol (Spanish)

Leave a Reply

Your email address will not be published. Required fields are marked *