High Availability on FreeBSD: The service IP address, part 2

In this second part of the article, we configure the service IP address.

Configuring the service IP address

As already mentioned in the first part, using the “carp” kernel module -which implements the protocol with the same name-, we will make an IP address assigned to two nodes, so that if one of them fails, the other continues answering requests.

The configuration consists of an extra line in the /etc/rc.conf file of each node.

For the first node, we will run the following:

For the second, we will run:

Let’s examine this in a generic way:

The first line indicates the use of an IP alias. This means that the ’em0′ NIC will have an additional IP to the one already configured as the primary IP (192.0.2.5/24 in our case for node 1, and 192.0.2.6/24 for the second one). Everything that goes between quotes are the parameters that this alias will take.

The second line states that we are going to use the “inet” family (IPv4), and if it is not specified, it is the default value. Another option is “inet6” for the IPv6 protocol.

In the third line, the virtual host identifier is established. Each service IP address must have the same value in all the nodes where it is configured. If we had more service addresses, this field should change. The allowed values are from 1 to 255.

The fourth line establishes the authentication password with which the participating nodes will be identified in a “vhid“. This key does not set any encryption.

In the fifth line, the IP address that we want as the service IP address is established.

Finally, and only for the secondary node, the value of “advskew” is set to 100. This value introduces a delay when the node is “announced” as a CARP node, modifying its order of precedence; and it is useful when we want to force a primary node automatically, or there are multiple secondary nodes.

At this time the change must be applied in each node.

For the first node we will execute:

And, in the second:

We can verify the correct functioning in several ways.

Using the “ifconfig em0” command in each node:

If we observe the last line, in the first server it shows “CARP: MASTER” and, in the second, “CARP: BACKUP”.

Another option, where we will also see more information such as the choice of the “MASTER” node, state transitions, etc., is the / var / log / messages file of each node:

Verifying functionality

With the configuration already done and activated and, the nodes defined in master and slave, it is time to make the necessary tests to verify that the behavior is appropriate.

We’ll use the “ping” command from some system on the same 192.0.2.100/24 subnet to check the service IP address availability:

The first real test we will do is verify what happens when the master node becomes unavailable due to a reboot or power failure, and the second one consists of network failure simulation.

In case of active node reboot

Connected to both nodes, on the master we’ll reboot the server, and on the second we check what happens:

The backup node becomes the master and the service IP address is assigned to it:

The service IP address continues accessible from other systems on the network. The following output shows what perception a client had  during the process since the first node failed until the secondary took the control and started giving service:

As can be seen, the virtual IP address has not been available for about 3 seconds.

In case of physical network failure

Is possible to simulate the loss of a network interface with the following command:

We can verify that the slave node detects this fault in the master:

As in the previous case, the second server becomes MASTER:

El estado actual del servicio sería como muestra la siguiente imagen:

The current service status is like the following image:

If we disable the network interface on the second node by:

Having no enabled interface (either the first node or the second), the service would no longer be accessible.

Forcing a node as primary

We may want a particular node to always be the primary node.

For this task, we can use an automatic configuration that consists of adding a line to the /etc/sysctl.conf file of the node that we want it to be:

If we do not want to restart the node at this time, we will activate the change in the following way:

We can also temporarily set a node as primary using the following command in the current MASTER node:

Final remarks

For simplicity along these two articles related to the service IP address, we used a single physical network interface for both server management and providing the service.

It is advisable to use multiple physical network interfaces, each for a task. Ideally the physical network interface “em0” will be used to provide the service, while another network interface “em1” will be used to administer the server and where CARP exchanges the status of both nodes.

Similarly, for simplicity, we used only one connection for each task. On production environments, where high availability is essential, must have second network links using “link aggregation” with separate network cards; in the future, I will post about it.

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

Leave a Reply

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