HA amb Linux i keepalived

Introducció

En el món dels servidors, és crucial garantir una alta disponibilitat en serveis per evitar i minimitzar possibles interrupcions. Precisament sobre aquest tema tracta aquest post, on utilitzarem el programa keepalived per implementar un sistema amb IP virtual, on si cau un dels servidors, s’assignarà aquesta IP a l’altre i, des del punt de vista d’un usuari, pràcticament no es notarà.

Què és i com funciona keepalived?

keepalived és un programa de routing escrit en C. Aquest programa permet implementar tan alta disponibilitat com balanceig de càrrega per a sistemes Linux.

Per dur a terme el balanceig de càrrega, keepalived utilitza un mòdul del kernel anomenat Linux Virtual Server, incorporat a IPVS.

Per l’alta disponibilitat, keepalived utilitza el protocol VRRP (Virtual Router Redundancy Protocol), que implementa una adreça IP virtual utilitzada per diferents equips alhora.

En aquest post instal·larem keepalived en dos servidors Debian i els configurarem sense serveis, perquè tinguin redundància, de manera que si un cau però l’altre segueix viu, es “quedi” la IP virtual.

Implementació

Primer instal·lem el programa en les dues màquines:

$ sudo apt install keepalived

I ara configurarem el servei. En aquest cas, la màquina 1 serà el principal (MASTER) i la 2, la secundària (BACKUP).

En el meu cas, com que virtualitzo amb KVM, qemu i libvirt i per defecte la xarxa agafa el rang 122, utiltitzaré aquest rang per l’exemple.

Configuració

En les màquines haurem de crear un arxiu de configuració amb diversos paràmetres. Aquests arxius contindran:

• state

  Aqui escriurem si el servidor serà el MASTER o el BACKUP.

• interface

  Aquí indicarem la interfície que volem configurar perquè contingui la IP virtual.

• virtual_router_id

  Aquesta serà la ID de la instància d’aquest VRRP, i ha de coincidir en tots els nostres servidors.

• priority

  La prioritat del servidor a l’hora de “quedar-se” la IP virtual. El MASTER és el que ha de tenir més prioritat.

• advert_int

  L’interval d’anuncis VRRP en segons (la freqüència amb la que el MASTER anuncia la seva presència).

• authentication

  Aquest apartat és on s’autenticaran els dispositius que utilitzin aquest protocol. Cal proporcionar una contrasenya.

• virtual_ipaddress

  L’adreça IP virtual que compartiran el MASTER i el/s BACKUPS.

• unicast

  Aquests ajustos no són necessaris però són útils per només transmetre la informació VRRP entre els servidors.

Configuració en el servidor 1

Aquest serà el servidor MASTER, és a dir, el principal a l’hora d’agafar la IP virtual.

Crearem un arxiu de configuració /etc/keepalived.conf amb el següent:

vrrp_instance VI_1 {
   state MASTER
   interface enp1s0
   virtual_router_id 50
   priority 100
   advert_int 1
   unicast_src_ip 192.168.122.254
   unicast_peer {
      192.168.122.253
   }
   authentication {
      auth_type PASS
      auth_pass 12345678
   }
   virtual_ipaddress {
      192.168.122.2
   }
}

Configuració en el servidor 2

Aquest serà el servidor BACKUP, és a dir, si cau el MASTER agafarà la IP virtual.

Crearem un arxiu de configuració /etc/keepalived.conf amb el següent:

vrrp_instance VI_1 {
   state BACKUP
   interface enp1s0
   virtual_router_id 50
   priority 50
   advert_int 1
   unicast_src_ip 192.168.122.253
   unicast_peer {
      192.168.122.254
   }
   authentication {
      auth_type PASS
      auth_pass 12345678
   }
   virtual_ipaddress {
      192.168.122.2
   }
}

Habilitem el servei

Un cop creat el fitxer amb el contingut, activem i habilitem el servei als dos equips amb:

$ sudo systemctl enable --now keepalived

I si no ens retorna cap error, acabem de verificar que vagi bé:

$ sudo systemctl status keepalived
● keepalived.service - Keepalive Daemon (LVS and VRRP)
     Loaded: loaded (/lib/systemd/system/keepalived.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-01-30 18:26:16 CET; 43min ago
       Docs: man:keepalived(8)
             man:keepalived.conf(5)
             man:genhash(1)
             https://keepalived.org
   Main PID: 505 (keepalived)
      Tasks: 2 (limit: 2306)
     Memory: 6.7M
        CPU: 113ms
     CGroup: /system.slice/keepalived.service
             ├─505 /usr/sbin/keepalived --dont-fork
             └─518 /usr/sbin/keepalived --dont-fork

de gen. 30 18:26:16 ha-master Keepalived[505]: Configuration file /etc/keepalived/keepalived.conf
de gen. 30 18:26:16 ha-master Keepalived[505]: NOTICE: setting config option max_auto_priority should result in better keepalived performance
de gen. 30 18:26:16 ha-master Keepalived[505]: Starting VRRP child process, pid=518
de gen. 30 18:26:16 ha-master systemd[1]: keepalived.service: Got notification message from PID 518, but reception only permitted for main PID 505
de gen. 30 18:26:16 ha-master Keepalived_vrrp[518]: (/etc/keepalived/keepalived.conf: Line 13) Unknown keyword 'auht_pass'
de gen. 30 18:26:16 ha-master Keepalived_vrrp[518]: (VI_1) Authentication specified but no password given. Ignoring
de gen. 30 18:26:16 ha-master systemd[1]: Started keepalived.service - Keepalive Daemon (LVS and VRRP).
de gen. 30 18:26:16 ha-master Keepalived_vrrp[518]: (VI_1) Entering BACKUP STATE (init)
de gen. 30 18:26:16 ha-master Keepalived[505]: Startup complete
de gen. 30 19:04:08 ha-master Keepalived_vrrp[518]: (VI_1) Entering MASTER STATE

Proves

Per verificar les IPs que tinc, obriré tres terminals, les de les màquines virtuals i la de la meva màquina host, i miraré les IPs de cadascuna de les virtuals.

Aquí podem verificar que el host MASTER té dues IPs per la seva interfície de xarxa, la seva i la virtual.

Tiraré un ping a la IP virtual (192.168.122.2) des de la meva màquina host:

Aturo el servei de kepalived a la màquina 1 i mostro les IP de la màquina 2

Com podem comprovar, ni tan sols he perdut pings, però l’adreça IP ha passat del MASTER al BACKUP.

Conclusió

En aquesta guia hem vist el que és keepalived i com configurar-lo per implementar alta disponibilitat en servidors Linux. Com hem pogut comprovar, la seva configuració bàsica és senzilla i ràpida d’implementar, alhora que molt potent per entorns que hagin de garantir un uptime elevat i requereixin redundància.

A més, es pot combinar amb serveis de monitorització per acabar de tenir un entorn d’alta disponibilitat i redundància sota control.

I fins aquí el post d’avui. Si t’ha semblat útil pots deixar un comentari i compartir-lo. Ens veiem al següent!