Alta disponibilidad en Linux: La IP de servicio, parte 2

En esta segunda parte del artículo se configura la dirección IP de servicio y se comenta el uso de la interfaz de red virtual “dummy0”.

Configurando la IP de servicio

Como ya se mencionó en la primera parte, utilizando “keepalived” -que implementa el protocolo VRRP-, haremos que una dirección IP esté asignada a un servidor de forma inicial; y si este falla, que esa dirección IP sea asignada automáticamente al otro servidor.

El fichero de configuración de”keepalived” es “/etc/keepalived/keepalived.conf”. Cada servidor tendrá el suyo propio, muy similar a su par.

Para el primer servidor, ejecutaremos lo siguiente

Para el segundo servidor, ejecutaremos:

Las líneas resaltadas son aquellas que difieren según el servidor.

Analicemos este fichero de forma genérica:

Las líneas 1 a 3 son un bloque de definiciones globales. En este caso solo hemos utilizado “router_id” para identificar el servidor cuando intercambie información de VRRP. Otra funcionalidad no mostrada aquí es notificar vía email cuando se produce algún cambio de estado.

Las líneas 5 a 28 definen una “instancia VRRP”. Una instancia es un grupo de servidores que se comunicaran entre ellos intercambiando información de estado siguiendo unas reglas que nosotros indiquemos.

Dentro de la instancia VRRP definimos qué estado inicial (línea 6) tiene cada servidor: MASTER, que será el que tenga asignada la dirección IP de servicio por defecto; o BACKUP, que la tendrá si el servidor MASTER no responde o notifica que alguna regla no se cumple.

Cuando un servidor en estado BACKUP no puede comunicarse con el servidor MASTER, o el servidor MASTER informa que no se cumplen las reglas de la instancia VRRP, el servidor BACKUP tomará el estado de MASTER y el servidor MASTER el estado de BACKUP, invirtiendo sus roles.

La información sera intercambiada con un cifrado simétrico a través de la interfaz de red eth0 (línea 7) para evitar que un servidor malintencionado altere el intercambio de información de estado (líneas 12 a 15).

VRRP es un protocolo que intercambia información de estado mediante paquetes de red multicast. Como solo tenemos dos servidores, establecemos una comunicación directa entre ellos –unicast– (líneas 21 a 23) y no utilizaremos el envío de paquetes multicast. Otra razón para hacer esto es la posibilidad de que el switch al que están conectados los servidores no permita el “tráfico multicast”.

En las líneas 17 a 19 indicamos que esta instancia VRRP debe asignar a la interfaz de red “dummy0” la dirección IP de servicio “192.0.2.100/24”. Es aquí donde se define que IP (o IPs) tendrá el servidor si esta en estado MASTER.

En las líneas 25 a 28 le indicamos una regla a VRRP: Vigila las interfaces de red eth0 y dummy0. Si alguna de estas interfaces de red no está disponible (estado “down”), entonces se notificará para que el nodo “BACKUP” (el que no tiene la IP de servicio en ese momento) se la asigne.

Finalmente reiniciaremos en cada servidor el servicio “keepalived”:

Podemos verificar el correcto arranque de keepalived con la configuración arriba indicada mediante el comando journalctl.

Para el primer nodo veremos algo así:

Vemos en las dos últimas líneas como se fuerza una nueva elección de maestro y como este nodo, “servidor-1”, es elegido como tal (MASTER STATE).

Tambien podemos verificar que la interfaz de red “dummy0” tiene asignada la IP 192.0.2.100 al ser el maestro:

En el segundo nodo veremos lo siguiente:

En las dos últimas líneas igualmente vemos que este nodo recibe un aviso de “prioridad superior” (desde el nodo “servidor-1”) y que por tanto pasa a tener el estado de respaldo (BACKUP STATE).

En el segundo nodo no habrá ninguna dirección IP asociada a la interfaz de red “dummy0” al estar como nodo de respaldo:

Verificando el funcionamiento

Con “keepalived” funcionando y los nodos definidos en maestro y esclavo, llega el momento de hacer las pruebas necesarias para verificar que, realmente, el comportamiento es el adecuado.

Utilizaremos el comando “ping” desde algún sistema en la misma subred 192.0.2.100/24 para verificar que la dirección IP de servicio está disponible. Puede hacerse desde el nodo de respaldo, aunque es recomendable utilizar un sistema externo a los nodos que están siendo puestos en marcha:

La primera prueba real que haremos será verificar qué ocurre cuando el nodo activo deja de estar disponible por reinicio o perdida de corriente eléctrica; y la segunda consistirá en simular un fallo en la interfaz de red.

En caso de reinicio del nodo activo

Conectados a ambos nodos, en el maestro reiniciaremos el servidor y en el secundario observaremos qué ocurre:

El nodo esclavo pasa a ser el maestro, y la dirección IP es asignada a este nodo:

La dirección IP de servicio seguirá siendo accesible desde los demás sistemas de la red. La siguiente salida muestra qué percepción ha tenido un cliente durante el proceso desde que falló el primer nodo hasta que el secundario tomó el control y comenzó a responder las peticiones:

Como puede observarse, la dirección IP virtual no ha estado disponible durante 25 segundos.

En caso de perdida de la interfaz de red física

Es posible simular la pérdida de una interfaz de red mediante el siguiente comando:

Podremos comprobar que el nodo esclavo detecta dicho fallo en el maestro y asigna la dirección IP virtual a su interfaz dummy0:

Al igual que en el caso anterior, la dirección IP virtual es reasignada:

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

IP de servicio compartida - Servidor servidor-1 en fallo - Español
En caso de deshabilitar la interfaz de red en el segundo nodo mediante

Al no tener ninguna interfaz habilitada (ni en el primer nodo ni en el segundo), el servicio dejaría de ser prestado.

IP de servicio compartida - Todos los servidores en fallo - Español

El uso de la interfaz virtual “dummy0”

En lugar de utilizar la interfaz de red física “eth0”, decidimos utilizar “dummy0”, una interfaz virtual.

Una ventaja que presenta el uso de la interfaz virtual es la de poder deshabilitarla sin perder conexión al equipo a la hora de su administración.

Tambien podemos deshabilitar la interfaz de red “dummy0” según convenga para tareas administrativas, como la actualización del software del servidor. Al deshabilitarla, el tráfico fluirá automáticamente al nodo esclavo mientras estas tareas son completadas sin afectar a los usuarios.

Notas finales

Por simplicidad a lo largo de estos dos artículos relacionados con la dirección IP de servicio, hemos utilizado una única interfaz de red física tanto para la gestión del servidor como para prestar el servicio.

Es recomendable utilizar múltiples interfaces de red físicas, cada una para una tarea. Idealmente la interfaz de red física “eth0” se utilizará para prestar el servicio, mientras que otra interfaz de red “eth1” será la utilizada para administrar el servidor y donde “keepalived” intercambia el estado de ambos nodos.

De igual modo, por simplicidad, sólo hemos utilizado una conexión para cada tarea. En entornos donde prime la alta disponibilidad debe utilizarse un doble enlace de red mediante “bonding” o “teaming”, utilizando tarjetas de red independientes; en un futuro publicaré sobre ello.

Hemos utilizado una interfaz de red virtual “dummy0” por flexibilidad, de forma que podamos deshabilitarla y seguir operando en el servidor para su mantenimiento. Tambien nos permite forzar a que el nodo esclavo tome el control deshabilitandola en el maestro.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *