Home Linux Linux HA Keepalived .. en 5 minutos

Linux HA Keepalived .. en 5 minutos

by José Luis Sánchez Borque

Cuando hablamos de alta disponibilidad en Linux (HA), pensamos muchas veces en complejos y caros dispositivos de redundancia y balanceo de carga. Nada más lejos de la realidad. Disponemos de diferentes paquetes que nos proporcionan la posibilidad de crear Clusters HA capaces de redundar determinados servicios o de crear IP flotantes que mejoren la disponibilidad de nuestra red.

Al final, un buen administrador de red siempre ha de pensar en redundar aquellos servicios más críticos en la empresa.

Dos de los servicios más conocidos son:

  • Heartbeat
  • keepalived

Cuando emplear uno y otro es vital para «acertar» con  nuestra solución.

La diferencia entre estos dos servicios es simple:

  • Un producto orientado a clústeres, como heartbeat, garantizará que un recurso compartido estará presente como máximo en un lugar. Esto es muy importante para sistemas de archivos compartidos, discos, etc. Está diseñado para desactivar un servicio en un nodo y activarlo en otro durante un cambio. De esa forma, es posible que nunca se acceda simultáneamente al recurso compartido. Esta es una tarea muy difícil de lograr y lo hace bien.
  • Un producto orientado a la red como keepalived garantizará que una dirección IP compartida estará presente en al menos un lugar. Tened en cuenta que ya no estoy hablando de un servicio o recurso, solo juega con las direcciones IP. No intentará bajar o subir ningún servicio, solo considerará una cierta cantidad de criterios para decidir qué nodo es el más adecuado para ofrecer el servicio. Pero el servicio ya debe estar activo en ambos nodos. Como tal, es muy adecuado para enrutadores redundantes, cortafuegos y proxies, pero no para arreglos de discos ni sistemas de archivos.

En  nuestro pequeño ejemplo de laboratorio nos vamos a plantear un reto:

Redundar la salida hacía internet. Imaginemos que la conectividad hacía Internet es vital para nuestra empresa. Por lo tanto contrataremos dos proveedores de Internet diferentes. Esto implicará tener también dos Routers/Firewalls que soporten cada una de estas salidas hacía Internet.

Veamos el esquema inicial:

Cómo podemos ver necesitaremos tres redes:

La RED Internet simula la conexión a Internet.

La RED LAN nuestra red interna, donde además tendremos un servicio que mapearemos desde el exterior.

La RED Sync es para mejorar rendimiento del sistema. Conviene que la detección del Cluster de Ip flotante esté en una red separada a la de producción, dado que si está saturada puede haber «falsos positivos» de desconexión. Mejor una red solo para este propósito.

La distribución que estoy utilizando es una Ubuntu 22.04 LTS.

Paso a enseñaros la configuración IP de ambas máquinas lb101 y lb102:

demo@lb101:~$ cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    ens33:
      addresses: [192.168.1.101/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        search: [mytcpip.local]
        addresses: [192.168.1.1]
    ens36:
      addresses: [192.168.2.101/24]
    ens37:
      addresses: [192.168.3.101/24]
  version: 2
demo@lb102:~$ cat /etc/netplan/00-installer-config.yaml
network:
  ethernets:
    ens33:
      addresses: [192.168.1.102/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        search: [mytcpip.local]
        addresses: [192.168.1.1]
    ens36:
      addresses: [192.168.2.102/24]
    ens37:
      addresses: [192.168.3.102/24]
  version: 2

La idea es crear una IP flotante en la red de Internet y otra en la red LAN que redunde tanto la entrada a los posibles servicios publicados de la red interna (mapeo de puertos) , como al salida a internet de las máquinas internas. Hay dos Gateways..

Veamos esquema:

linux-ha-keepalived

Definiremos dos nuevas IPs para gestionar las IPs flotantes:

  • Red Internet: 192.168.1.103
  • Red Lan: 192.168.3.103

Todos los ordenadores de la red interna pasarán a tener como Gateway dicha IP: 192.168.3.103

Instalaremos en primer lugar el servicio keepalived. Nada más fácil que el típico:

demo@lb102:~$ sudo apt install keepalived

Tendremos que hacerlo en los dos routers evidentemente.

Veamos la configuración IP actual de ambas máquinas antes de configurar el servicio:

demo@lb101:~$ ip -4 addr | grep inet
inet 127.0.0.1/8 scope host lo
inet 192.168.1.101/24 brd 192.168.1.255 scope global ens33
inet 192.168.2.101/24 brd 192.168.2.255 scope global ens36
inet 192.168.3.101/24 brd 192.168.3.255 scope global ens37
demo@lb102:~$ ip -4 addr | grep inet
inet 127.0.0.1/8 scope host lo
inet 192.168.1.102/24 brd 192.168.1.255 scope global ens33
inet 192.168.2.102/24 brd 192.168.2.255 scope global ens36
inet 192.168.3.102/24 brd 192.168.3.255 scope global ens37

Realizaremos siempre las pruebas de conectividad oportunas para ver que todo funciona antes de «liarnos» con la configuración.

La configuración es sumamente sencilla:

Nodo LB101

demo@lb101:~$ cat /etc/keepalived/keepalived.conf

vrrp_instance lb101a {

  interface ens33

  state MASTER
  virtual_router_id 10
  priority 50

  unicast_src_ip 192.168.2.101
  unicast_peer {
    192.168.2.102
  }

  virtual_ipaddress {
    192.168.1.103 dev ens33
  }
}

vrrp_instance lb101b {

  interface ens37

  state MASTER
  virtual_router_id 20
  priority 50

  unicast_src_ip 192.168.2.101
  unicast_peer {
    192.168.2.102
  }

  virtual_ipaddress {
    192.168.3.103 dev ens37
  }
}

Nodo LB102

demo@lb102:~$ cat /etc/keepalived/keepalived.conf
vrrp_instance lb102a {
  interface ens33

  state BACKUP
  virtual_router_id 10
  priority 60

  unicast_src_ip 192.168.2.102
  unicast_peer {
    192.168.2.101
  }

  virtual_ipaddress {
    192.168.1.103 dev ens33
  }
}

vrrp_instance lb102b {
  interface ens37

  state BACKUP
  virtual_router_id 20
  priority 60

  unicast_src_ip 192.168.2.102
  unicast_peer {
    192.168.2.101
  }

  virtual_ipaddress {
    192.168.3.103 dev ens37
  }
}

En cada fichero de configuración  hemos definido dos secciones, una por IP flotante que nos interesa.  El parámetro state especifica que Router es el principal (el que responde a dicha IP) y cual secundario.

El parámetro virtual_router_id es un número que debe identifica de forma univoca a la instancia. No debe coincidir con ningun otro. Tampoco debe coincidir con el de su PEER, es decir el otro extremos, pero POR COHERENCIA los hago coincidir, así todo es más fácil de seguir.

Podéis encontrar más información sobre los diferentes parámetros en el siguiente enlace:  AYUDA

Un tema importante son las directivas unicast_srv y unicast_peer. Por defecto, si no indicamos lo contrario keepalived emplea direcciones multicast sobre la misma red donde está definida la ip flotando para determinar que nodo del cluster está operativo. Nosotros habíamos dedicido mejorar eso, y crear una red específica de supervisión: La red SYNC.

Para especificar que queremos utilizar unicast y esa red, establecemos las directivas mencionadas de la forma correcta. Cada nodo con su peer correspondiente. Ver esquemas….

Una vez reiniciados los servicios en los dos nodos, todo estará operativo:

sudo systemctl restart keepalived.service

Si vemos las IP’s en ambos nodos vemos que aparecen dos nuevas IP’s flotantes.

demo@lb101:~$ ip -4 addr | grep inet
inet 127.0.0.1/8 scope host lo
inet 192.168.1.101/24 brd 192.168.1.255 scope global ens33
inet 192.168.1.103/32 scope global ens33
inet 192.168.2.101/24 brd 192.168.2.255 scope global ens36
inet 192.168.3.101/24 brd 192.168.3.255 scope global ens37
demo@lb102:~$ ip -4 addr | grep inet
inet 127.0.0.1/8 scope host lo
inet 192.168.1.102/24 brd 192.168.1.255 scope global ens33
inet 192.168.1.103/32 scope global ens33
inet 192.168.2.102/24 brd 192.168.2.255 scope global ens36
inet 192.168.3.102/24 brd 192.168.3.255 scope global ens37
inet 192.168.3.103/32 scope global ens37

Si hacemos un PING desde un ordenador de la RED «Internet», un Windows en este caso vemos que responde. ADemás interesante ver que la MAC correcponde con la de la tarjeta ens33 del nodo lb101 que es el que está activo.

C:\Users\usuario>ping 192.168.1.103 -n 1

Haciendo ping a 192.168.1.103 con 32 bytes de datos:
Respuesta desde 192.168.1.103: bytes=32 tiempo<1m TTL=64

Estadísticas de ping para 192.168.1.103:
Paquetes: enviados = 1, recibidos = 1, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 0ms, Máximo = 0ms, Media = 0ms

C:\Users\usuario>arp -a | find "1.103"
192.168.1.103 00-0c-29-77-e4-d1 dinámico

Podemos comprobarlo fácilmente:

demo@lb101:~$ ip a show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:0c:29:77:e4:d1 brd ff:ff:ff:ff:ff:ff
altname enp2s1
inet 192.168.1.101/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet 192.168.1.103/32 scope global ens33
valid_lft forever preferred_lft forever

Para ver que funciona, y dado que es un laboratorio, empleo el método más drástico.. Apago el nodo LB101. Y tras unos momentos de crisis, que pueden ser mayores o menores en función  de las prestaciones de nuestro sistema vemos que todo funciona, solo hemos tenido una perdida de paquete IP. OJo, en sistemas críticos puede implicar la desconexión de clientes según el protocolo, y que tengan que volver a conectarse.

C:\Users\usuario>ping 192.168.1.103 -t

Haciendo ping a 192.168.1.103 con 32 bytes de datos:
Tiempo de espera agotado para esta solicitud.
Respuesta desde 192.168.1.103: bytes=32 tiempo=1ms TTL=64
Respuesta desde 192.168.1.103: bytes=32 tiempo<1m TTL=64
Respuesta desde 192.168.1.103: bytes=32 tiempo<1m TTL=64

Podemos ver en la tabla ARP como la MAC ha cambiado y ya corresponde a la del  otro nodo.

C:\Users\usuario>arp -a | find "1.103"
192.168.1.103 00-0c-29-f3-80-3a dinámico

Veamos lo mismo desde dentro. Tengo un PROXMOX

 

POST dedicado especialmente a Gino, el sabe el motivo… y las cosas que se pueden hacer en 25 minutos a full.

You may also like

2 comments

Gino E. diciembre 16, 2022 - 8:58 pm

Muchas gracias por hacer fácil lo que muchas veces parece complicado de entender.
Un saludo MAESTRO!!

Reply
José Luis Sánchez Borque diciembre 17, 2022 - 3:18 pm

De nada. Lo importante entre todos mejorar el conocimiento.

Reply

Leave a Comment