Cicle formatiu: Administració de sistemes informàtics en xarxa (ASIX)
Mòdul: 0378. Seguretat i alta disponibilitat
L’alta disponibilitat (High Availability, HA) és el conjunt de tècniques, arquitectures i procediments que permeten que un servei informàtic estigui operatiu el màxim de temps possible, minimitzant el temps d’aturada (downtime), tant planificat com no planificat.
L’objectiu no és eliminar les avaries —cosa impossible—, sinó dissenyar el sistema perquè cap component individual (single point of failure, SPOF) pugui aturar el servei complet.
La disponibilitat es mesura en percentatge de temps en funcionament durant un any:
| Disponibilitat | Downtime anual | Downtime mensual |
|---|---|---|
| 99% (“dos nous”) | 3,65 dies | 7,3 hores |
| 99,9% (“tres nous”) | 8,76 hores | 43,8 minuts |
| 99,99% (“quatre nous”) | 52,6 minuts | 4,4 minuts |
| 99,999% (“cinc nous”) | 5,26 minuts | 26 segons |
Cada “nou” addicional multiplica per deu el cost d’implementació (maquinari redundant, xarxes duplicades, personal de guàrdia, etc.). Cal triar el nivell de disponibilitat en funció del cost real d’una aturada per a l’organització, no per moda tecnològica.
Un servei “ininterromput” real no existeix; el que es persegueix és que les interrupcions siguin:
Per aconseguir-ho es combinen mecanismes de detecció de fallada (health checks, heartbeat) amb mecanismes de commutació automàtica (failover).
Dos indicadors clau que cal conèixer abans de dissenyar qualsevol arquitectura HA:
La integritat de dades es garanteix amb rèpliques síncrones (sense pèrdua, però amb més latència) o asíncrones (menys latència, però amb risc de pèrdua de les últimes escriptures).
Escriptura síncrona: Client → Node A → (espera confirmació) → Node B → ACK → Client
Escriptura asíncrona: Client → Node A → ACK immediat → (rèplica en segon pla) → Node BExisteixen dos models bàsics de redundància de servidors:
A la pràctica 1 d’aquest tutorial implementarem un esquema actiu-passiu amb Keepalived i el protocol VRRP.
Un clúster d’alta disponibilitat és un conjunt de servidors (nodes) que treballen coordinats i es vigilen mútuament per garantir que un servei sempre s’executa en algun node del conjunt. Els components típics són:
El balanceig de càrrega (load balancing) reparteix les peticions entrants entre diversos servidors backend, aportant dos beneficis simultanis: repartiment de la càrrega de treball i tolerància a fallades (si un backend cau, el balancejador deixa d’enviar-hi trànsit).
Algorismes habituals: round robin, least connections, source IP hash, ponderat per capacitat (weighted).
A la pràctica 2 implementarem balanceig de càrrega HTTP amb HAProxy.
Abans d’arribar a la capa de software, cal identificar quins components de maquinari eliminen punts únics de fallada:
| Component | Solució de redundància |
|---|---|
| Font d’alimentació | Fonts redundants hot-swap (N+1) al servidor |
| Disc | RAID 1/5/6/10, controladores RAID redundants |
| Xarxa | Targetes de xarxa en bonding/teaming, dos commutadors, dos routers (VRRP/HSRP) |
| Alimentació elèctrica | SAI (UPS) + generador |
| Refrigeració | Sistemes de climatització redundants al CPD |
| Servidor complet | Clúster de servidors (nodes redundants) |
| Emmagatzematge centralitzat | Cabines SAN/NAS amb controladores dobles, RAID i rèplica |
La redundància de maquinari resol fallades físiques, però no protegeix de fallades lògiques (errors humans, corrupció de dades, ransomware). Per això la HA es complementa sempre amb còpies de seguretat, no la substitueix.
La virtualització desacobla el servei (màquina virtual) del maquinari físic que l’executa. Aquesta separació és clau per a la HA perquè permet:
| Eina | Tipus | Ús típic en HA |
|---|---|---|
| Proxmox VE | Hipervisor tipus 1 (bare metal) | Clústers HA de producció i laboratori, ja treballat en tutorials anteriors |
| VMware vSphere/ESXi | Hipervisor tipus 1 | HA i DRS en entorns empresarials |
| VirtualBox | Hipervisor tipus 2 | Entorns de proves en un sol PC, ideal per practicar aquest RA sense maquinari dedicat |
| KVM/QEMU + libvirt | Hipervisor tipus 1 (Linux) | Base de moltes solucions HA de codi obert |
| LXC/Docker | Contenidors | Serveis lleugers, escalat horitzontal ràpid |
Cal distingir dos nivells, que sovint es confonen:
En aquest tutorial ens centrarem sobretot en el punt 2, ja que és el que permet simular un entorn de producció complet dins d’un sol host físic o portàtil, tal com demana el contingut 6.9 (Simulació de serveis mitjançant virtualització).
Per seguir les pràctiques d’aquest tutorial necessitem com a mínim:
Esquema de xarxa que farem servir a totes les pràctiques (adaptable a la vostra xarxa d’aula):
192.168.56.0/24
┌──────────────┬──────────────┬──────────────┐
│ │ │ │
srv-web1 srv-web2 srv-lb srv-client
192.168.56.11 192.168.56.12 192.168.56.10 192.168.56.100Objectiu: implantar un servidor redundant en esquema actiu-passiu, de manera que si el servidor principal cau, un segon servidor assumeixi automàticament la seva IP i el servei, sense intervenció manual.
Dues VM (srv-web1 i srv-web2) amb Apache
instal·lat, que comparteixen una IP virtual (VIP) 192.168.56.20. El protocol VRRP
(Virtual Router Redundancy Protocol), implementat via
Keepalived, decideix en cada moment quin dels dos nodes
“posseeix” la VIP.
| Màquina | IP real | Rol inicial |
|---|---|---|
| srv-web1 | 192.168.56.11 | MASTER |
| srv-web2 | 192.168.56.12 | BACKUP |
| VIP compartida | 192.168.56.20 | — |
sudo apt update
sudo apt install -y keepalived apache2Personalitzem la pàgina d’inici de cada node per poder identificar quin respon:
echo "Servidor: $(hostname)" | sudo tee /var/www/html/index.htmlsudo nano /etc/keepalived/keepalived.confvrrp_script chk_apache {
script "/usr/bin/pgrep apache2"
interval 2
weight 2
}
vrrp_instance VI_1 {
state MASTER
interface enp0s8
virtual_router_id 51
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass thos2024
}
virtual_ipaddress {
192.168.56.20/24
}
track_script {
chk_apache
}
}Mateix fitxer, amb dues diferències: state BACKUP i una priority més baixa.
vrrp_instance VI_1 {
state BACKUP
interface enp0s8
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass thos2024
}
virtual_ipaddress {
192.168.56.20/24
}
track_script {
chk_apache
}
}El virtual_router_id ha de ser idèntic
als dos nodes (identifica la instància VRRP); la priority
és el que decideix qui guanya l’elecció a MASTER quan ambdós estan
vius.
sudo systemctl enable --now keepalived
ip addr show enp0s8 # comprovem que la VIP apareix només al node MASTERDes de srv-client:
curl http://192.168.56.20El vrrp_script és clau: sense ell, Keepalived només
detecta que la interfície de xarxa és viva, no que el servei Apache
respon. Un servidor amb la xarxa activa, però Apache caigut seguiria
sent “MASTER” sense aquest control addicional.
Objectiu: implantar un balancejador de càrrega a l’entrada de la xarxa interna que reparteixi peticions entre diversos servidors backend i n’exclogui automàticament els que no responen.
Si ja heu seguit el tutorial específic d’HAProxy d’aquest curs, aquesta secció en repassa els conceptes aplicant-los directament al context d’aquest RA6; podeu ampliar-la amb la configuració SSL/TLS ja treballada allà.
Una tercera VM, srv-lb (192.168.56.10), rep tot el
trànsit HTTP dels clients i el reparteix entre srv-web1 i srv-web2.
srv-client → srv-lb (192.168.56.10:80) → { srv-web1:80, srv-web2:80 }sudo apt update
sudo apt install -y haproxysudo nano /etc/haproxy/haproxy.cfgfrontend web_frontend
bind *:80
default_backend web_backend
backend web_backend
balance roundrobin
option httpchk GET /
http-check expect status 200
server web1 192.168.56.11:80 check
server web2 192.168.56.12:80 check
listen stats
bind *:8404
stats enable
stats uri /stats
stats refresh 10ssudo systemctl restart haproxyfor i in $(seq 1 6); do curl -s http://192.168.56.10; doneHauríeu de veure alternar les respostes de srv-web1 i srv-web2 (algorisme round robin).
Obriu http://192.168.56.10:8404/stats des del navegador:
mostra l’estat (UP/DOWN) de cada backend en temps real, connexions
actives i comptador d’errors.
Noteu la diferència de rol respecte a la pràctica 1: Keepalived/VRRP proporciona redundància pel que fa a la IP (útil per a serveis que no admeten repartiment senzill, o per fer HA del propi balancejador), mentre que HAProxy proporciona repartiment de càrrega actiu-actiu real entre backends. En entorns de producció ambdues tècniques es combinen: dos HAProxy en actiu-passiu amb Keepalived, cadascun balancejant cap al mateix conjunt de servidors web.
Objectiu: implantar un sistema d’emmagatzematge redundant sobre servidors, de manera que les dades es mantinguin sincronitzades entre dos nodes sense necessitat d’una cabina SAN física.
DRBD (Distributed Replicated Block Device) replica en temps real, a escala de bloc, el contingut d’un disc entre dos servidors, com un “RAID 1 per xarxa”. El node primari (Primary) llegeix i escriu normalment; el secundari (Secondary) rep totes les escriptures i les aplica al seu propi disc.
srv-storage1 (Primary) <---- xarxa dedicada ----> srv-storage2 (Secondary)
/dev/sdb1 ─────────── replicació síncrona ────────── /dev/sdb1Cada VM necessita un segon disc sense format (p. ex. /dev/sdb, 2 GB) i el paquet DRBD:
sudo apt update
sudo apt install -y drbd-utilssudo nano /etc/drbd.d/r0.resresource r0 {
protocol C;
on srv-storage1 {
device /dev/drbd0;
disk /dev/sdb;
address 192.168.56.21:7789;
meta-disk internal;
}
on srv-storage2 {
device /dev/drbd0;
disk /dev/sdb;
address 192.168.56.22:7789;
meta-disk internal;
}
}protocol C és una replicació síncrona:
l’escriptura no es confirma a l’aplicació fins que ambdós nodes l’han
desada. És la configuració amb RPO més baix (idealment zero), a costa de
latència addicional en cada escriptura.
sudo drbdadm create-md r0
sudo drbdadm up r0Al node que farà de primari:
sudo drbdadm primary --force r0Comprovem l’estat de sincronització:
sudo drbdadm status r0
# o bé
cat /proc/drbdsudo mkfs.ext4 /dev/drbd0
sudo mkdir -p /mnt/dades
sudo mount /dev/drbd0 /mnt/dades
echo "prova alta disponibilitat" | sudo tee /mnt/dades/prova.txtDRBD per si sol només replica el bloc de dades; no decideix automàticament quin node ha de ser primari en cas de fallada. Per això, en entorns reals, DRBD es combina amb un gestor de clúster (Pacemaker) que automatitza aquesta commutació — el que veurem tot seguit.
Objectiu: avaluar i implantar un sistema de clúster que augmenti la fiabilitat automatitzant la detecció de fallades i la migració de serveis.
Un clúster Pacemaker/Corosync gestiona recursos (una IP virtual, un servei Apache, un dispositiu DRBD…) i els manté sempre actius en algun node del clúster, movent-los automàticament si el node que els executa falla.
sudo apt update
sudo apt install -y pacemaker corosync pcs
sudo systemctl enable --now pcsdsudo passwd hacluster # mateixa contrasenya a tots dos nodes
sudo pcs host auth srv-web1 srv-web2 -u haclusterDes de qualsevol dels dos nodes:
sudo pcs cluster setup cluster_thos srv-web1 srv-web2
sudo pcs cluster start --all
sudo pcs cluster enable --allCom que només tenim dos nodes, desactivem el quorum estricte (en producció, amb 3+ nodes, no cal aquest pas):
sudo pcs property set no-quorum-policy=ignore
sudo pcs property set stonith-enabled=falseDesactivar STONITH (fencing) només és acceptable en un entorn de pràctiques. En producció, l’absència de fencing pot provocar split-brain: dos nodes creient-se cadascun “el primari” i escrivint dades de manera incoherent. En un clúster real cal configurar un dispositiu de fencing (IPMI, controladora de la VM, PDU intel·ligent…).
sudo pcs resource create vip ocf:heartbeat:IPaddr2 \
ip=192.168.56.30 cidr_netmask=24 op monitor interval=5s
sudo pcs resource create web_service ocf:heartbeat:apache \
configfile=/etc/apache2/apache2.conf \
statusurl="http://localhost/server-status" op monitor interval=10sVolem que la IP i Apache viatgin sempre junts, en aquest ordre:
sudo pcs resource group add grup_web vip web_servicesudo pcs statusAquesta ordre mostra els nodes, el seu estat (Online/Offline), i en
quin node s’està executant grup_web en aquest moment.
En una implantació completa, el recurs DRBD de la pràctica 3 també es
gestionaria com a recurs de Pacemaker (ocf:linbit:drbd), de
manera que la promoció a Primary i el muntatge del sistema de
fitxers siguin automàtics i estiguin sincronitzats amb el moviment del
servei Apache. És l’exercici natural d’ampliació d’aquest RA per a
l’alumnat que vulgui aprofundir-hi.
Objectiu: analitzar com evolucionar una solució HA quan la demanda creix per sobre de la capacitat prevista inicialment.
| Estratègia | Descripció | Quan aplicar-la |
|---|---|---|
| Escalat vertical (scale up) | Augmentar CPU/RAM/disc d’un node existent | Solució ràpida a curt termini; té un límit físic |
| Escalat horitzontal (scale out) | Afegir més nodes al clúster o al pool de backend | Solució que escala millor a llarg termini; requereix arquitectura stateless o amb estat compartit |
| Autoescalat | Afegir/treure nodes automàticament segons mètriques de càrrega (CPU, connexions) | Entorns amb demanda molt variable (pics estacionals, campanyes) |
| Migració a núvol públic o híbrid | Desplaçar part de la infraestructura a IaaS/PaaS | Quan el CPD propi no pot créixer més o cal disponibilitat geogràfica |
| CDN i càtxing | Reduir la càrrega real sobre els servidors d’origen | Contingut estàtic o poc canviant, trànsit d’usuaris geogràficament dispers |
| Bases de dades distribuïdes / replicades | Evitar que la BD esdevingui el nou coll d’ampolla | Quan els servidors d’aplicació ja escalen però la BD no |
| Contenidors i orquestració (Kubernetes) | Escalat horitzontal molt granular i automatitzat | Arquitectures de microserveis |
Objectiu: esquematitzar i documentar una solució d’alta disponibilitat per a un supòsit donat, integrant tot el que s’ha treballat en aquest RA.
Per a cadascun dels supòsits següents (o un altre de proposat pel professorat), l’alumnat ha de lliurar un document que inclogui:
No hi ha una única solució “correcta” per a cada supòsit: l’objectiu de l’activitat és que l’alumnat justifiqui, amb criteris tècnics i econòmics, per què tria un nivell de redundància i unes tècniques concretes (servidor redundant, clúster, balanceig, emmagatzematge replicat) i no unes altres. Un excés d’HA per a un requisit modest és, tècnicament, tan mal disseny com un dèficit d’HA per a un servei crític.
| Criteri | Insuficient | Suficient | Excel·lent |
|---|---|---|---|
| Anàlisi del supòsit | No identifica requisits de RTO/RPO | Identifica RTO/RPO de manera genèrica | Justifica RTO/RPO amb dades concretes del supòsit |
| Esquema | Falta o incomplet | Mostra els nodes principals | Inclou xarxa, maquinari redundant i fluxos de dades |
| Implantació pràctica | No es prova el failover | Es prova el failover una vegada | Es documenten temps i es comparen diverses tècniques |
| Pla de futur | No es planteja escalat | Proposa una estratègia d’escalat | Prioritza diverses estratègies justificadament |
# Keepalived
sudo systemctl status keepalived
sudo journalctl -u keepalived -f
# HAProxy
sudo systemctl restart haproxy
sudo haproxy -c -f /etc/haproxy/haproxy.cfg # validar sintaxi
# DRBD
sudo drbdadm status r0
sudo drbdadm primary|secondary r0
# Pacemaker/Corosync
sudo pcs status
sudo pcs resource move <recurs> <node>
sudo pcs node standby|unstandby <node>