La documentació de Proxmox VE diu del seu propi ha-manager una cosa que gairebé cap fullet de virtualització no gosaria escriure: que té «temps típics de detecció d'error i failover d'uns 2 minuts, de manera que no pots aconseguir més d'un 99,999 % de disponibilitat». És al manual oficial, a la pàgina que la gent es salta per arribar al botó d'activar. Aquest paràgraf és la definició honesta del que compres quan actives HA: no compres que no caigui; compres que s'aixequi sola.
La distància entre aquestes dues frases és la que separa un projecte que surt bé d'una reunió incòmoda sis mesos després. Fa anys que operem clústers de Proxmox VE en producció, i la conversa que més repetim comença just després dels tres clics que l'activen: què deixa de passar i què comença a passar llavors. Perquè comencen a passar coses.
Què passa de debò quan mor un node
Un node amb vint màquines virtuals s'apaga en sec: font morta, kernel penjat, algú que ensopega amb un cable. La resta del clúster deixa de veure'l i comprova que continua tenint majoria de vots. Després toca esperar, i aquí hi ha el detall que ordena tota la resta: a Proxmox el node perdut no l'aïlla ningú des de fora, s'aïlla ell sol — el seu propi watchdog el reinicia tan bon punt deixa de poder atendre'l. Passat aquest termini, el clúster pot donar per segur que ja ningú no escriu des de l'altre costat, i llavors arrenca els serveis als nodes que continuen vius. La documentació anomena aquesta cadena detecció d'error i failover, i li posa la xifra que hem citat a dalt: uns dos minuts.
Convé dir amb totes les lletres què vol dir «moure». No és una migració en calent. La migració en calent copia la memòria d'una màquina encesa a un altre node i el sistema operatiu convidat ni se n'assabenta; requereix que el node d'origen sigui viu per poder copiar aquella memòria. Aquí el node d'origen no existeix. Les màquines s'arrenquen de zero en un altre lloc, exactament igual que si els haguessis tret l'endoll. I aquesta diferència, que en un diagrama són dues fletxes semblants, al rellotge del dilluns al matí és una altra cosa.
Els cinc nous surten d'una resta
El «99,999 %» de la documentació sona a màrqueting fins que el passes a minuts. Un any té 525.600 minuts, i d'aquí surt tota la resta:
- →99,999 % són 5 minuts i 15 segons de tall a l'any. Un sol failover de dos minuts s'endú el 38 % d'aquest pressupost anual. Tres incidents i ja no hi ha cinc nous ni amb el millor maquinari del mercat.
- →99,99 % són 52 minuts i 34 segons a l'any: uns vint-i-sis failovers de dos minuts. Aquesta és la xifra que, al nostre parer, es pot defensar en una pime amb un clúster ben muntat, i ja és una xifra excel·lent.
- →99,9 % són 8 hores i 46 minuts a l'any. És a dir: una tarda sencera d'aturada anual continua sent «tres nous». Molta gent que promet cinc nous està lliurant això, i no passa res; el que passa és que ho ha escrit malament al contracte.
I hi ha un matís que cau de totes les presentacions: aquest sostre és el de l'hipervisor, no el del teu servei. Mesura des que el clúster detecta el problema fins que la màquina virtual arrenca. El que passa dins de la màquina virtual a partir d'aquell segon no ho compta ningú.
Dins de la màquina virtual hi ha hagut una apagada
Ningú no ha dit al sistema convidat que s'apagués ordenadament. Així que arrenca com arrenca qualsevol màquina després d'una apagada: el sistema de fitxers revisa el seu registre de transaccions, la base de dades refà el journal i decideix quines transaccions confirma i quines llença, els serveis s'aixequen en l'ordre que els toca —que poques vegades és l'ordre que necessita l'aplicació— i les cues que estaven a mitges es queden a mitges. En un servidor de fitxers això són segons. En un ERP amb la seva base de dades, el seu servidor d'aplicacions i tres integracions que reintenten, això no són segons.
D'aquí surt l'única mesura que de debò importa i que gairebé mai no està feta: quant triga la teva aplicació a estar operativa des d'un arrencada en fred. No quant triga a encendre's la VM: quant triga a permetre que un usuari facturi. Aquesta xifra, sumada als dos minuts de l'hipervisor, és el teu temps de recuperació real davant la caiguda d'un node. És la mateixa conversa que vam tenir parlant dels >dos números que se signen sense haver-los calculat, aplicada a un escenari molt més petit i molt més freqüent que un desastre.
I de vegades la caiguda la provoca la mateixa HA
Aquesta és la part que sorprèn qui acaba d'activar-la, i està descrita amb una claredat admirable al manual. Quan un node perd el quòrum del clúster, «l'LRM espera que es formi un nou quòrum. Fins que hi ha quòrum, el node no pot resetejar el watchdog. Si hi ha serveis actius al node, o si el procés LRM o CRM no es planifica o mor, això dispararà un reinici quan el watchdog hagi expirat (això passa als 60 segons)».
Llegeix-ho una altra vegada pensant en la teva xarxa. Un node sa, amb les seves màquines virtuals funcionant i el seu emmagatzematge perfectament accessible, es reinicia sol als seixanta segons per haver deixat de parlar amb els seus companys, amb tot el maquinari intacte. I qui decideix si aquesta conversa es manté és un switch, un cable o una targeta de xarxa.
Per això la documentació del clúster és tan insistent amb una cosa que al pressupost sembla un caprici: «la pila de clúster de Proxmox VE requereix una xarxa fiable amb latències per sota de 5 mil·lisegons (rendiment de LAN) entre tots els nodes per funcionar de manera estable», i recomana «una targeta de xarxa física dedicada per al trànsit de clúster» perquè la xarxa de clúster, encara que mou molt poques dades, «és molt sensible a la latència». Demana a més, expressament, que aquesta xarxa no es faci servir «per a cap propòsit d'alt trànsit, com ara emmagatzematge en xarxa o migració en viu». Aquesta última frase és la que més vegades hem vist ignorada, i hi ha al darrere més d'un reinici que al principi no tenia explicació: una migració en viu d'una màquina gran saturant el mateix enllaç pel qual corosync ha d'arribar a temps.
Aquell reinici brutal és la funció, no la fallada
Costa acceptar-ho la primera vegada que et passa, però el reinici automàtic és el que fa que tota la resta sigui segura. Es diu fencing, i el seu propòsit és que el clúster pugui afirmar, sense cap dubte, que el node desaparegut ja no escriu a l'emmagatzematge compartit. Sense aquesta certesa no es pot recuperar res: la documentació adverteix que si s'escriu des de dos nodes alhora «es poden destruir totes les dades de la VM».
Així que el tracte és explícit i convé signar-lo amb els ulls oberts: acceptes perdre un node sa durant un minut a canvi de no partir mai un disc en dos. Ens sembla un tracte excel·lent. Però és un tracte, no un regal, i qui no ho entengui viurà el primer reinici per watchdog com una traïció del producte quan és el sistema fent exactament el que promet.
Els requisits que tothom es salta
El manual els llista sense cerimònia, en quatre línies, i són els quatre llocs on, segons la nostra experiència, es trenquen els clústers que arriben demanant ajuda:
- 1«Almenys tres nodes de clúster (per tenir un quòrum fiable)». Amb dos nodes no hi ha majoria possible quan es perden de vista: cadascun té un vot i cap no pot decidir. Per això existeix el QDevice, que aporta «un tercer vot» des d'una màquina externa. Compte amb la paraula: aporta un vot, no un node. No fa córrer VM i no substitueix un tercer servidor.
- 2«Emmagatzematge compartit per a VM i contenidors». Si els discos viuen al disc local del node que s'ha mort, no hi ha res per arrencar enlloc. Aquí és on entra la decisió de fons —Ceph, una cabina, replicació— que ja vam desgranar a rèplica 3 contra erasure coding amb els comptes complets. I on es decideix si el teu «emmagatzematge compartit» és en realitat un únic punt de fallada amb llums boniques.
- 3«Redundància de maquinari (a tot arreu)» i «fer servir components de servidor fiables». Dit d'una altra manera: l'HA no substitueix les dues fonts d'alimentació, els discos en mirall ni el SAI. És el que es posa a sobre de tot això quan ja hi és.
- 4Una xarxa de clúster que no depengui de la sort. No apareix a la llista de requisits amb aquest nom, però és el que decideix si els altres tres serveixen d'alguna cosa. El mateix manual assenyala que els enllaços addicionals per al trànsit de clúster «ofereixen redundància per si la xarxa dedicada cau», amb suport per a fins a vuit enllaços. Un segon anell per una altra targeta i un altre switch costa molt poc comparat amb el que evita.
Quan NO muntem HA
Vendre alta disponibilitat és còmode: ningú no discuteix una proposta que promet que no cauràs. Ens sembla més útil dir quan la desaconsellem, encara que impliqui un projecte més petit.
Si l'aplicació ja sap agrupar-se sola, posar-hi HA per sota acostuma a fer més nosa que servei: dos nodes de base de dades replicats entre ells no volen que l'hipervisor en reiniciï un pel seu compte a mitja commutació. Passa una cosa semblant amb les màquines que tenen maquinari passat directament —una clau, una targeta, un autòmat de planta—: no poden arrencar en un altre node, així que de poc serveix prometre'ls un lloc on tornar. I quan hi ha dos servidors i una cabina compartida, l'exercici honest és preguntar què passa si el que cau és la cabina: si la resposta és «tot», l'HA està protegint el punt que menys falla.
I hi ha el cas més freqüent de tots, el que gairebé mai no es diu en veu alta: quan cinc minuts de tall al mes no costen res al negoci. Allà l'alta disponibilitat afegeix complexitat, i la complexitat és l'altre nom de les avaries estranyes. Hi ha empreses a les quals hem recomanat gastar-se aquests diners en còpies provades i en un pla de restauració cronometrat, i dormir millor. Cap d'elles no ens ha dit després que se'n penedís.
El que sí que fem abans de donar un clúster per bo
- →Estirar el cable expressament. Amb càrrega real, abans que entri en producció, i amb un cronòmetre: des que es talla fins que l'aplicació torna a respondre. Aquesta xifra és la que va al pla de continuïtat i la que s'ensenya a direcció.
- →Manteniment amb el mode de manteniment, no amb
reboot. Proxmox portaha-manager crm-command node-maintenance enable NODE, que fa que «tots els serveis gestionats per HA migrin a altres nodes» abans de tocar res. És la diferència entre apedaçar un node un dimarts a la tarda i explicar per què es van reiniciar vuit màquines. - →Col·locar el QDevice on no caigui amb la resta. Un tercer vot que viu al mateix rack, amb el mateix switch i el mateix quadre elèctric que els dos nodes no és un àrbitre: és un tercer jugador del mateix equip.
- →Deixar el clúster tan tancat com disponible. Un node que es recupera sol però al qual s'entra amb una contrasenya del 2019 no està millor que abans; la resta del repàs és al checklist de hardening que apliquem a cada clúster.
La pregunta amb què comencem
Quan algú ens demana alta disponibilitat, la primera pregunta no és quants nodes té ni quin emmagatzematge fa servir. És aquesta: quant triga la teva aplicació principal a tornar a funcionar després d'una apagada? Si ningú no ho ha mesurat mai, aquesta és la feina d'aquesta setmana, i probablement canviï el projecte sencer. Si la xifra és alta, l'HA la millorarà poc i cal arreglar una altra cosa primer. I si la xifra és baixa i el negoci aguanta un parell de minuts, llavors sí: dos minuts de failover automàtic a les quatre de la matinada són una nit sencera de son, que és més o menys el que compra l'alta disponibilitat quan està ben posada.
Fonts: temps de detecció i failover d'uns 2 minuts, sostre del 99,999 %, requisits (tres nodes, emmagatzematge compartit, redundància de maquinari, components de servidor), comportament del watchdog als 60 segons sense quòrum, propòsit del fencing i mode de manteniment — capítol ha-manager de la documentació de Proxmox VE i wiki d'alta disponibilitat; latència per sota de 5 ms, targeta dedicada, avís sobre emmagatzematge en xarxa i migració en viu, enllaços redundants i QDevice com a tercer vot — capítol de gestió de clúster. El mateix capítol publica la seva taula de disponibilitat (99,9 % → 8,76 hores; 99,99 % → 52,56 minuts; 99,999 % → 5,26 minuts a l'any); les conversions a minuts i segons són aritmètica directa sobre 525.600 minuts a l'any. Imatge de portada: fotografia d'un polsador d'aturada d'emergència, CC0, via el directori de fotos de WordPress.
El teu clúster aguanta que li treguis un node?
A everyWAN dissenyem i operem infraestructura i cloud sobre Proxmox VE, amb la xarxa de clúster feta com toca i el failover cronometrat abans d'entrar en producció. Si en mesurar-ho surt que no necessites HA, t'ho diem.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN