Salta el contingut

PR0203 — Alta Disponibilitat de DHCP amb Kea (Hot-Standby)

Informació de la pràctica

Camp Valor
Codi PR0203
Mòdul M0375 — Serveis de Xarxa i Internet
RA RA2 — Configuració Automàtica de Xarxa (DHCP)
Durada estimada 3 hores
Modalitat Individual (2 màquines pròpies)
Lliurament Fitxers de configuració + PDF (documentació) a Moodle
Qualificació 10 punts (rúbrica adjunta)

Objectius

  • Entendre el concepte d'alta disponibilitat (HA) aplicat al servei DHCP i la diferència entre els modes hot-standby i load-balancing de Kea.
  • Desplegar dos servidors Kea DHCP (primari i secundari) mitjançant el hook natiu libdhcp_ha.so, en mode hot-standby.
  • Verificar l'intercanvi de heartbeats i la sincronització d'estat entre els dos servidors via l'API REST.
  • Simular la caiguda del servidor primari i comprovar que el secundari assumeix el servei sense que els clients perdin connectivitat.
  • Documentar el procés de recuperació (failback) quan el servidor primari torna a estar operatiu.

Requisits previs

  • Haver completat PR0201 — Servei DHCP Corporatiu amb Kea: aquesta pràctica reutilitza la mateixa base de configuració (subnet, pool, opcions).
  • 2 màquines virtuals Ubuntu Server 24.04 LTS amb kea-dhcp4-server i kea-ctrl-agent instal·lats (podeu clonar la del PR0201 per estalviar-vos la instal·lació).
  • 1 màquina client (virtual o física) a la mateixa xarxa, amb el rol de client DHCP, per verificar concessions durant el failover.
  • Haver llegit la secció Alta Disponibilitat (HA) de "Kea DHCP a Linux".

Assignació del Rang IP (obligatori)

Reutilitzeu el mateix rang IP que us va correspondre al PR0201 (mateix número de llista N, mateix XX), tal com s'indica al document d'adreçament de xarxa del Moodle.

  • XX = 50 + N (el mateix valor que al PR0201).
  • Exemple: si sou l'alumne número 1, XX = 51, i la vostra xarxa és 172.24.51.0/24.
  • La vostra xarxa de treball serà 172.24.XX.0/24, amb:
  • kea-server (primari) → 172.24.XX.10
  • kea-server2 (secundari) → 172.24.XX.11
  • Pool dinàmic compartit → 172.24.XX.100 - 172.24.XX.200

Personalització obligatòria

Substituïu XX pel valor numèric que us correspongui (50 + N) i NOMCOGNOM pel vostre nom i cognom (en minúscules, sense espais ni accents) a totes les adreces IP, dominis i noms d'amfitrió d'aquesta pràctica. Les captures amb el rang d'exemple (172.24.XX.0/24 literal, o el rang d'un altre company) no es consideraran vàlides.

Part 1: Preparació dels Dos Servidors (30 minuts)

Cloneu la màquina virtual kea-server del PR0201 per obtenir el segon servidor. Un cop clonada, cal canviar-ne el nom d'amfitrió i l'adreça IP (recordeu que un clonatge no ho actualitza automàticament):

# Al servidor primari (ja existent del PR0201)
sudo hostnamectl set-hostname kea-server-NOMCOGNOM

# Al servidor secundari (clon)
sudo hostnamectl set-hostname kea-server2-NOMCOGNOM
# Editeu la configuració de xarxa (netplan) perquè la IP sigui 172.24.XX.11

Verifiqueu que als dos servidors els serveis existeixen i estan aturats o inactius mentre acabeu la configuració:

systemctl status kea-dhcp4-server
systemctl status kea-ctrl-agent

Documenteu: captura de hostnamectl i ip a de cadascun dels dos servidors mostrant els noms i les IP correctes.

Part 2: Configuració Base Idèntica del Subnet (45 minuts)

El bloc Dhcp4 (subnet, pool i opcions) ha de ser exactament el mateix als dos servidors — només diferirà el bloc high-availability que afegireu a la Part 3. Editeu /etc/kea/kea-dhcp4.conf a totes dues màquines amb el mateix contingut:

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "eth0" ]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv"
    },
    "valid-lifetime": 3600,
    "renew-timer": 1800,
    "rebind-timer": 3150,
    "subnet4": [
      {
        "id": 1,
        "subnet": "172.24.XX.0/24",
        "pools": [ { "pool": "172.24.XX.100 - 172.24.XX.200" } ],
        "option-data": [
          { "name": "routers", "data": "172.24.XX.1" },
          { "name": "domain-name-servers", "data": "172.24.XX.10, 8.8.8.8" },
          { "name": "domain-name", "data": "NOMCOGNOM.local" }
        ]
      }
    ],
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/tmp/kea4-ctrl-socket"
    },
    "loggers": [
      {
        "name": "kea-dhcp4",
        "output-options": [ { "output": "/var/log/kea-dhcp4.log" } ],
        "severity": "INFO"
      }
    ]
  }
}

I /etc/kea/kea-ctrl-agent.conf, també idèntic als dos servidors (cadascun escoltant localment al seu propi port 8000):

{
  "Control-agent": {
    "http-host": "0.0.0.0",
    "http-port": 8000,
    "control-sockets": {
      "dhcp4": {
        "socket-type": "unix",
        "socket-name": "/tmp/kea4-ctrl-socket"
      }
    }
  }
}

Reinicieu els serveis als dos servidors i comproveu que arrenquen sense el hook d'HA encara:

sudo systemctl restart kea-dhcp4-server
sudo systemctl restart kea-ctrl-agent

Documenteu: per què és imprescindible que subnet4 sigui idèntic als dos servidors en un desplegament HA (què passaria si un client rebés opcions diferents segons quin dels dos servidors el respongués?).

Part 3: Configuració del Hook d'Alta Disponibilitat (1 hora)

Afegiu el bloc hooks-libraries dins de Dhcp4 a cada servidor. El contingut és el mateix als dos, excepte el camp this-server-name.

A kea-server (172.24.XX.10), afegiu dins Dhcp4:

"hooks-libraries": [
  {
    "library": "/usr/lib/kea/hooks/libdhcp_ha.so",
    "parameters": {
      "high-availability": [
        {
          "this-server-name": "server1",
          "mode": "hot-standby",
          "heartbeat-delay": 10000,
          "max-response-delay": 60000,
          "max-ack-delay": 5000,
          "max-unacked-clients": 0,
          "peers": [
            {
              "name": "server1",
              "url": "http://172.24.XX.10:8000/",
              "role": "primary"
            },
            {
              "name": "server2",
              "url": "http://172.24.XX.11:8000/",
              "role": "standby"
            }
          ]
        }
      ]
    }
  }
]

A kea-server2 (172.24.XX.11), el mateix bloc canviant només:

"this-server-name": "server2",

Un únic bloc peers, idèntic als dos servidors

El bloc peers llista tots els membres de la relació HA (inclòs ell mateix) amb el seu rol. És el camp this-server-name qui indica a cada servidor "qui és ell" dins d'aquesta llista — per això el bloc peers no canvia entre servidors, només this-server-name.

Valideu la sintaxi abans de reiniciar (imprescindible amb JSON) i reinicieu el servei als dos servidors:

sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
sudo systemctl restart kea-dhcp4-server

Consulteu l'estat d'HA via l'API REST (a cada servidor, contra el seu propi port 8000):

curl -X POST -H "Content-Type: application/json" \
     -d '{"command": "status-get", "service": ["dhcp4"]}' \
     http://172.24.XX.10:8000/

Al camp high-availability de la resposta hauríeu de veure l'estat local (state) i l'estat de comunicació amb el company (communication-state), que hauria d'acabar en "hot-standby" (o "load-balancing", segons el mode) un cop completada la sincronització inicial.

Documenteu: captura de status-get amb el bloc high-availability dels dos servidors, mostrant que tots dos es reconeixen mútuament i l'estat és estable.

Part 4: Verificació del Failover i Failback (45 minuts)

Failover (caiguda del primari)

Des de la màquina client, sol·liciteu una concessió normal i comproveu que la serveix el primari:

sudo dhclient -r eth0
sudo dhclient eth0
ip a show eth0

Ara atureu el servei al servidor primari:

# Al kea-server (172.24.XX.10)
sudo systemctl stop kea-dhcp4-server

Al cap d'uns segons (superat el max-response-delay), consulteu l'estat al secundari:

curl -X POST -H "Content-Type: application/json" \
     -d '{"command": "status-get", "service": ["dhcp4"]}' \
     http://172.24.XX.11:8000/

L'estat hauria d'haver canviat a "partner-down": el secundari assumeix en solitari el servei de tot el pool. Des del client, forceu una nova petició DHCP i comproveu que segueix obtenint IP amb normalitat (ara servida pel secundari):

sudo dhclient -r eth0
sudo dhclient eth0

Documenteu: captura de status-get al secundari mostrant l'estat partner-down, i captura de la concessió obtinguda pel client mentre el primari està aturat.

Failback (recuperació del primari)

Torneu a arrencar el servei al primari:

# Al kea-server (172.24.XX.10)
sudo systemctl start kea-dhcp4-server

Consulteu de nou status-get a tots dos servidors i observeu la transició d'estats (normalment waiting → syncing → ready → l'estat normal del mode configurat) fins que el primari recupera el seu rol actiu.

Documenteu: captura de status-get als dos servidors un cop finalitzada la resincronització, confirmant que ambdós han tornat a l'estat normal.

Qüestions

Responeu al document de lliurament:

  1. Quina diferència hi ha entre els modes hot-standby i load-balancing del hook libdhcp_ha.so? En quin escenari triaríeu cadascun (per exemple, si el servidor secundari té menys capacitat que el primari)?
  2. Per què cal que la configuració de subnet4 (rangs, opcions) sigui idèntica als dos servidors, mentre que el bloc high-availability és l'únic que canvia entre ells?
  3. Quins estats pot mostrar un servidor Kea en una relació HA (waiting, syncing, ready, partner-down, etc.) i què indica cadascun sobre la salut de la parella?
  4. Compareu aquest mecanisme amb el failover peer clàssic d'ISC DHCP (vist a l'activitat d'aprofundiment AP0208): quins avantatges aporta el hook natiu de Kea en termes d'observabilitat i facilitat de configuració?

Lliurament

  1. Fitxers de configuració: kea-dhcp4.conf i kea-ctrl-agent.conf dels dos servidors (identifiqueu clarament quin és quin, p. ex. kea-dhcp4-server1.conf / kea-dhcp4-server2.conf).
  2. Documentació PDF amb:
  3. El vostre número de llista N i el rang 172.24.XX.0/24 calculat
  4. Captures de cada part (1 a 4)
  5. Respostes a les 4 qüestions
  6. README.md amb un resum dels passos de desplegament de la relació HA i de la prova de failover/failback realitzada.

Criteris d'Avaluació

Consulteu la rúbrica detallada per a la puntuació completa (10 punts, 4 blocs + penalitzacions).

Recursos Addicionals

Data de creació: Setembre 2026 Autor: Curs M0375 - Serveis de Xarxa i Internet