- L'alta disponibilitat a servidors virtualitzats combina clústers, replicació i emmagatzematge redundant per minimitzar el downtime.
- RHEL, Hyper-V, HA-DAS i solucions NAS com QNAP ofereixen diferents enfocaments d'HA segons mida, pressupost i necessitats.
- La replicació per a DR no substitueix una HA real: el failover automàtic i gairebé sense tall exigeix sincronització propera al temps real.
- Dissenyar bé larquitectura i respectar requisits de maquinari, xarxa i programari és clau per garantir continuïtat de servei.
L' alta disponibilitat en servidors virtualitzats s'ha convertit en un requisit bàsic per a qualsevol organització que no es pot permetre caigudes de servei, ni tan sols d'uns quants minuts. Parlem d'assegurar que les vostres màquines virtuals, aplicacions i dades segueixin accessibles encara que falli un servidor físic, un disc, la xarxa o fins i tot un CPD complet. No és només qüestió de tenir còpies de seguretat, sinó de mantenir el servei en marxa passi el que passi.
Quan barregem virtualització , clústers, emmagatzematge i recuperació davant de desastres , apareixen moltes tecnologies (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, rèpliques, etc.) i no sempre és clar què triar ni com encaixar-ho tot. En aquest article es fa un repàs a fons de les principals opcions i enfocaments: des dels clústers tradicionals amb emmagatzematge compartit fins a solucions modernes basades en replicació en temps real entre nosaltres, passant per casos concrets amb Red Hat, Microsoft Hyper-V, QNAP i arquitectures HA-DAS.
Conceptes bàsics d'alta disponibilitat a entorns virtualitzats
En un entorn virtualitzat, l' alta disponibilitat (HA) implica que les VMs segueixin accessibles encara que fallin un o més components del sistema (servidors, discos, controladores, xarxa, alimentació, etc.). No és el mateix que la recuperació davant de desastres (DR): l'HA busca temps d'inactivitat mínim o gairebé nul, mentre que la DR sol acceptar cert downtime per restaurar serveis des d'una còpia.
Per aconseguir aquest comportament, es combinen diverses peces: redundància de maquinari, programari de clúster, emmagatzematge tolerant a fallades i mecanismes de monitorització i commutació per error . L'objectiu és evitar punts únics de fallada: si es trenca alguna cosa, una altra peça entra en acció sense intervenció manual (o amb la mínima possible).
Al món de la virtualització això es tradueix normalment en disposar de múltiples hosts físics que comparteixen o repliquen l'emmagatzematge , i un sistema que vigila l'estat dels nodes i de les VMs. Quan un host cau, les màquines virtuals s'engeguen en un altre host, idealment sense que l'usuari ho noti o amb una interrupció molt breu.
És important diferenciar també entre solucions pensades per a entorns “tipus núvol” elàstics i plataformes d'HA clàssiques. Certs productes de clúster tenen una configuració relativament estàtica i un nombre màxim de nodes relativament baix, per la qual cosa no són adequats per muntar-te un cloud massiu, encara que sí que són excel·lents per protegir un conjunt de serveis crítics ben definits.
En un entorn cloud o híbrid convé revisar estratègies específiques per a migració i continuïtat: per exemple, migració al núvol pot ser part de l'estratègia de recuperació davant de desastres, però no substitueix l'HA local.
Alta disponibilitat a Red Hat Enterprise Linux i plataformes KVM/Xen
L'ecosistema de Red Hat ofereix diverses opcions per protegir màquines virtuals mitjançant clústers i complements d'alta disponibilitat . En versions com Red Hat Enterprise Linux 5 i 6 se suporten diferents combinacions d'hipervisors i add-ons de clúster.
A RHEL 5 se suporten dues plataformes de virtualització: Xen (des de RHEL 5.0) i KVM (des de RHEL 5.4) . L'add-on RHEL 5 Advanced Platform (AP) Cluster permet gestionar tant VMs Xen com KVM com a recursos de clúster, de manera que la infraestructura d'alta disponibilitat del host és la que controla l'arrencada, parada i failover de les màquines virtuals entre nodes.
Amb RHEL 6 el suport de virtualització se simplifica: només KVM està suportat com a hipervisor . Tot i això, el complement d'Alta Disponibilitat de RHEL 6 segueix permetent tractar les màquines virtuals KVM com a recursos de clúster gestionats per la infraestructura d'HA de l'amfitrió. El gestor de recursos de clúster (rgmanager, a les versions clàssiques) s'encarrega de monitoritzar els nodes i moure els hostes entre servidors físics quan es detecta una fallada.
Aquest enfocament sol anomenar-se “ RHEL Cluster/HA executant-se en hosts físics que actuen com a plataforma de virtualització ”. El mateix clúster de RHEL és el que dirigeix on s'executa cada VM i actua en cas de caiguda d'un node, garantint que les màquines virtuals configurades com a crítiques es reiniciïn en un amfitrió sa.
Un aspecte interessant és que, des del punt de vista del clúster, no importa tant el sistema operatiu hoste de la VM . Qualsevol convidat compatible amb Xen o KVM a RHEL pot tractar-se com a màquina virtual altament disponible: diferents versions de RHEL (3, 4, 5, etc.) i diverses edicions de Microsoft Windows, sempre que estiguin suportades per l'hipervisor. Això dóna força flexibilitat a l'hora de protegir entorns mixtos.
Ara bé, la pròpia Red Hat recomana anar amb compte en triar entre fer servir RHEL High Availability Add-on o plataformes de virtualització més completes com Red Hat Enterprise Virtualization (RHEV) per proporcionar HA de VMs. Totes dues ofereixen funcionalitat d'alta disponibilitat, però els casos d'ús són diferents i cal valorar la mida de l'entorn i el model d'operació.
Quan utilitzar RHEL HA davant RHEV per a alta disponibilitat
A l'hora de decidir si convé RHEL HA Add-on o una plataforma com a RHEV per protegir màquines virtuals, un dels criteris clau és el nombre de hosts físics i el tipus d'ús que es donarà a l'entorn virtualitzat.
L'add-on d'alta disponibilitat de RHEL està pensat per a clústers relativament petits i amb configuració estàtica . Tradicionalment, aquests clústers tenen un límit màxim d'uns 16 nodes físics, cosa que és suficient per a molts entorns corporatius però no encaixa bé amb arquitectures tipus cloud amb desenes o centenars de hosts canviant constantment.
Per això, la pròpia documentació de Red Hat assenyala que no es recomana fer servir exclusivament RHEL HA per construir infraestructures similars al núvol , precisament per aquesta naturalesa estàtica i pel límit de recompte de nodes. Per a escenaris cloud, té més sentit recórrer a plataformes específicament pensades per a aquest model, amb gestors de recursos més elàstics i escalables.
En canvi, si l'objectiu és protegir un nombre moderat de VMs crítiques en un conjunt de hosts ben definit , l'add-on d'HA de RHEL és una solució sòlida: s'integra bé amb el sistema operatiu, es recolza en tecnologies de clúster madures i proporciona la lògica necessària per vigilar i moure VMs en cas de fallada.
En qualsevol cas, és recomanable revisar la documentació més recent de RHEL sobre sistemes operatius convidats suportats i combinacions d'hipervisor i clúster perquè el suport evoluciona amb cada llançament i és important cenyir-se a les matrius oficials.
Alta disponibilitat a Hyper-V: clústers, rèpliques i migració en viu
En entorns Microsoft, l'alta disponibilitat es basa fonamentalment en les prestacions de Hyper-V combinades amb Failover Clustering de Windows Server . L'objectiu és tenir accés consistent a les màquines virtuals fins i tot si hi ha errors de maquinari, problemes a la xarxa o errors de programari.
La peça central són els clústers de commutació per error de Hyper-V . Un clúster d'aquest tipus és un conjunt de servidors (nodes) que comparteixen emmagatzematge i treballen de manera coordinada: si un node cau, les VMs que tenia s'arrenquen automàticament en un altre node del clúster. Tot això es recolza en tecnologies de disc compartit i comunicacions internes específiques.
Perquè això funcioni, és habitual que els nodes comparteixin emmagatzematge mitjançant una SAN (Storage Area Network) o un servidor de fitxers d'escalabilitat horitzontal (SOFS) . Sobre aquesta capa es creen els Cluster Shared Volumes (CSV) , que permeten a tots els nodes accedir simultàniament als mateixos discos on resideixen els fitxers de les màquines virtuals.
Els nodes, a més, es comuniquen per una xarxa dedicada coneguda com a batec del clúster (cluster heartbeat) . Aquesta xarxa està separada de la xarxa de dades de producció i serveix perquè cada servidor notifiqui que és viu. Si el clúster deixa de rebre heartbeats d'un node, es considera que heu fallat i s'inicien les accions de commutació per error.
Un altre element fonamental és la configuració de quòrum . El quòrum defineix quants vots (nodes o testimonis externs) han d'estar actius perquè el clúster segueixi funcionant. Això evita escenaris de “split brain” o “cervell dividit”, on grups de nodes aïllats creen que són el clúster principal i provoquin corrupció de dades. Triar bé el model de quòrum (nodes, disc testimoni, file share witness, etc.) és clau per a l'estabilitat.
Sobre aquesta base, Hyper-V aprofita les capacitats del clúster per habilitar migracions en viu de màquines virtuals entre nodes amb temps d'inactivitat mínim . Durant una operació de manteniment o per rebalancejar càrrega, una VM pot passar d'un amfitrió a un altre sense tallar el servei, movent memòria, estat i connexions actives de forma transparent.
Si, en lloc de manteniment planificat, es produeix una fallada real de maquinari o programari en un node, el clúster executa una commutació per error automàtica . Les màquines virtuals que s'hi executaven s'aixequen en un altre host amb accés al mateix emmagatzematge compartit. La interrupció és més gran que en una migració en viu (cal apagar/encendre la VM), però es manté la continuïtat del servei amb la mínima intervenció humana.
A més del clúster clàssic amb SAN, Hyper-V incorpora altres tecnologies enfocades tant a l'alta disponibilitat com a la recuperació davant de desastres, destacant Hyper-V Replica i la migració en viu sense emmagatzematge compartit.
La Rèplica de Hyper-V és una funció de replicació asincrònica de màquines virtuals entre un amfitrió principal i un o diversos amfitrions de rèplica, normalment ubicats en un altre lloc o CPD. Cada cert interval s'envien canvis a la VM de destinació, creant punts de recuperació que permeten recuperar la VM en un estat recent si el lloc principal pateix un desastre.
Aquest mecanisme compta amb un agent de rèpliques de Hyper-V que coordina el trànsit de replicació, gestiona els punts de recuperació i centralitza les operacions de commutació per error. Permet realitzar tant commutacions planificades (per exemple, per moure la producció a un altre centre) com no planificades (quan cau el lloc principal inesperadament).
Per la seva naturalesa asincrònica, la rèplica està més orientada a DR que a HA “gairebé zero downtime” . Després d'un incident, cal iniciar el failover sobre la VM de rèplica i, encara que el procés és força àgil, implica cert temps d'inactivitat i possible pèrdua dels darrers segons o minuts de dades, depenent de l'interval de replicació configurat.
En paral·lel, Hyper-V ofereix la migració en viu de Shared Nothing , que permet moure una VM entre hosts que no comparteixen emmagatzematge. En aquest model, cada host té el seu propi emmagatzematge local, però la migració en viu copia de manera transparent els discos de la màquina virtual a la destinació mentre la VM segueix en línia, per després commutar l'execució al nou servidor.
Aquesta funcionalitat és especialment útil en entorns sense SAN o sense infraestructura d'emmagatzematge compartit , reduint el cost d'entrada per a pimes o escenaris on no es vol mantenir una xarxa d'emmagatzematge dedicada. Permet, per exemple, reorganitzar hosts o migrar a maquinari nou amb impacte mínim, sense necessitat de parar màquines.
La combinació d'aquestes tecnologies (clústers de commutació per error, CSV, migració en viu amb emmagatzematge compartit o sense i rèplica de Hyper-V) proporciona un ventall ampli d'opcions per dissenyar estratègies de continuïtat de negoci i tolerància a fallades adaptades a diferents pressupostos i nivells d'exigència.
Solucions d'alta disponibilitat amb HA-DAS i Windows Server
Més enllà dels entorns amb grans SAN, hi ha arquitectures pensades per a alta disponibilitat en sistemes d'emmagatzematge directament connectats a servidors (HA-DAS) . Aquestes solucions treuen partit de Windows Server (per exemple, 2012) i de controladores RAID/HBA avançades per oferir clústers en alta disponibilitat sense necessitat de muntar una SAN iSCSI o FC tradicional.
En aquest enfocament, s'utilitzen dos nodes en clúster HA amb emmagatzematge compartit tipus JBOD (xassís de discos “just a bunch of disks” sense intel·ligència pròpia). El JBOD es connecta a tots dos servidors mitjançant controladores Host RAID HBA redundants, de manera que cada node veu el mateix conjunt de discos i pot accedir al mateix RAID de manera simultània.
Aquestes solucions poden assolir capacitats de fins a 180 TB al xassís compartit , treballant amb discos magnètics o SSD hot-swap en diferents nivells RAID. Les controladores RAID solen incorporar 1 GB de memòria cau cadascuna, amb la memòria cau replicada en mirall entre controladores per mantenir coherència i millorar rendiment, i protecció de memòria cau basada en supercondensadors en lloc de bateries tradicionals.
La comunicació entre controladores es realitza típicament a través d' enllaços SAS , cosa que permet prescindir d'enllaços Ethernet de batec per a la sincronització d'estat dels discos. Això aporta una ruta de comunicació directa i altament fiable entre els dos nodes a nivell demmagatzematge.
Una altra característica important és que aquestes arquitectures solen treballar en mode actiu/actiu sobre el mateix RAID . És a dir, tots dos nodes donen servei simultàniament i aprofiten la potència de còmput dels dos servidors, en lloc de deixar un “en espera” fins que falli l'altre. D'aquesta manera s'evita malgastar el 50% de la inversió en maquinari que sol passar en clústers actiu/passiu.
En basar-vos en Windows Server 2012 (o versions posteriors), els administradors es beneficien d'un entorn de gestió familiar: eines, assistents, consola d'administració i model de permisos ja coneguts. El temps d'aprenentatge es redueix al mínim, cosa que també disminueix els costos operatius i els riscos durant la posada en marxa.
Aquest tipus de solucions HA-DAS s'orienten a diversos usos: virtualització de servidors Hyper-V, VDI Windows, emmagatzematge SAN/NAS, bases de dades transaccionals (OLTP) , data warehouse i serveis web en alta disponibilitat . Tot això aprofitant un únic xassís demmagatzematge compartit, dos nodes redundants i la lògica de clúster de Windows.
Alta disponibilitat específica a cabines NAS QNAP i Virtualization Station 4
En l'àmbit dels NAS, fabricants com QNAP han desenvolupat funcionalitats avançades per aconseguir alta disponibilitat tant de l'emmagatzematge com de les màquines virtuals allotjades als seus equips . En particular, combinen el sistema operatiu QuTS hero (basat en ZFS) amb Virtualization Station 4 per oferir replicació en temps real i commutació per error entre dues NAS.
D'una banda, el sistema QuTS hero integra tecnologies de HA per al propi NAS , permetent tenir dos equips idèntics (o similars) configurats com a parella d'alta disponibilitat. Si un dels NAS falla, el segon assumeix la càrrega i els serveis continuen operatius. Això ja protegeix lemmagatzematge i els serveis bàsics del NAS.
Sobre aquesta base, la nova funcionalitat d' alta disponibilitat a Virtualization Station 4 (disponible en fase beta a les versions recents) fa un pas més: permet que les màquines virtuals que s'executen al NAS tinguin tolerància a fallades avançada mitjançant replicació en temps real entre dos dispositius QNAP.
Aquesta funció està disponible només en NAS QNAP amb processadors x86 que executin QuTS hero i compten amb la versió adequada de Virtualization Station 4. L'ús de ZFS i de la tecnologia SnapSync és fonamental, ja que s'encarrega de sincronitzar en temps real les dades de les VM entre tots dos NAS, garantint que la VM replicada estigui sempre
L'esquema de funcionament es basa que dues NAS es recolzen mútuament : el NAS A i el NAS B actuen com a nodes de còpia de seguretat entre si, de forma bidireccional. Cadascú pot tenir les seves pròpies màquines virtuals i, per a les quals es marquen com a protegides per HA, es crea una rèplica a l'altre NAS. En cas d'error d'un dels equips, l'altre agafa el control i arrenca les VM afectades.
Això permet una commutació entre servidors NAS fluida . Es pot activar la protecció HA només per a certes VMs crítiques sense que això afecti altres serveis del NAS (per exemple, tasques de backup, compartició de fitxers, etc.). Cada NAS pot continuar complint el seu rol original mentre protegeix, alhora, les màquines virtuals designades per a alta disponibilitat.
La sincronització en temps real basada en SnapSync assegura que, quan es produeix un incident, la commutació és pràcticament immediata i sense pèrdua de dades . A diferència d'arquitectures tradicionals que depenen d'un emmagatzematge compartit central (SAN), aquesta solució elimina aquest punt únic de fallada: cada NAS manté una còpia completa i coherent de les VM que protegeix.
A més, QNAP defineix múltiples condicions de fallada que poden disparar la commutació : sobrecàrrega perllongada de CPU (per sobre de cert llindar, per exemple, 80% durant un temps), temperatura excessiva del sistema, fallada de discos fins i tot en configuracions RAID, pèrdua d'una de les fonts d'alimentació redundants, entre d'altres. El sistema avalua aquestes condicions i, si es considera que el NAS ja no és fiable, mou la càrrega a l'altre node.
També s'ofereix la possibilitat de fer commutacions manuals , molt útils quan l'equip tècnic vol migrar de manera controlada les màquines virtuals a un altre NAS per fer tasques de manteniment: substituir discos, actualitzar microprogramari, canviar configuracions avançades, etc. La commutació és molt ràpida (de l'ordre de menys d'un segon), cosa que fa que el procés sigui pràcticament transparent per als usuaris.
Un altre punt interessant és que no hi ha cost addicional de llicència : la funcionalitat d'alta disponibilitat a Virtualization Station 4 forma part de la pròpia aplicació i ve inclosa al sistema, sense pagaments extra per node o per VM. Això la torna especialment atractiva per a pimes i entorns que busquen HA amb un cost contingut.
Requisits i limitacions de l'alta disponibilitat a QNAP
Per desplegar correctament aquesta solució sobre QNAP és essencial respectar certs requisits de programari, maquinari i xarxa . No són extremadament complexos, però sí que convé tenir-los molt clars abans de dissenyar l'entorn.
Pel que fa al programari, cal comptar amb QuTS hero en versió h5.3 o superior i amb Virtualization Station 4.1 o posterior. Només aquestes versions incorporen la funcionalitat d'HA d'VM basada en SnapSync. A NAS amb QTS “clàssic” o versions anteriors de Virtualization Station, aquesta característica no està disponible.
A nivell de maquinari, no és obligatori que els dos NAS siguin exactament el mateix model, però sí que s'exigeix que tots dos utilitzin processadors de la mateixa arquitectura i marca (els dos Intel o els dos AMD) . Això simplifica la compatibilitat i garanteix que les VMs replicades puguin executar-se sense problemes a qualsevol dels dispositius.
Pel que fa a la xarxa, és indispensable que els dos NAS estiguin al mateix segment de xarxa i que hi hagi, a més, una connexió directa entre tots dos mitjançant un cable de xarxa físic dedicat per a la sincronització de dades de les màquines virtuals. Aquest enllaç dedicat funciona com a canal fora de banda per a la replicació, evitant interferències amb el trànsit normal d'usuaris.
A la pràctica, el requisit real de maquinari es redueix a això: mateixa família de CPU i enllaç directe entre NAS . Tota la resta (capacitat de disc, RAM, etc.) es dimensiona en funció de les VMs que es vulguin protegir i del rendiment esperat. Si es respecten aquestes condicions, la configuració de HA de QNAP és relativament directa i molt robusta.
Diferència entre alta disponibilitat i replicació/DR simple en màquines virtuals
Moltes vegades es confonen les solucions de replicació de màquines virtuals com a mecanisme de recuperació davant de desastres amb la veritable alta disponibilitat sense temps d'inactivitat (o amb downtime mínim). Totes dues són importants, però resolen problemes diferents.
Per exemple, en entorns amb VMware vSphere és freqüent configurar replicació de VMs a un lloc de DR , de manera que la imatge de disc del servidor principal es va copiant al node de contingència. Això protegeix davant de la pèrdua total del lloc principal, però, quan aquest cau, sol ser necessari fer una recuperació manual: encendre les VMs al lloc de DR, reconfigurar xarxes, validar integritat de dades, etc.
Aquest procés, encara que en part automatitzable, implica un període d'inactivitat que pot anar de minuts a hores, depenent de la complexitat de l'entorn i dels procediments interns. És una estratègia excel·lent de DR, però no compleix l'objectiu de disponibilitat gairebé contínua que s'espera d'una solució HA estricta.
L'alta disponibilitat “de debò” exigeix que hi hagi un mecanisme automàtic o gairebé automàtic de commutació per error , amb temps de tall molt baixos i sense necessitat d'operacions manuals complexes quan un component falla. A més, la sincronització de dades entre el node actiu i el de respatller ha de ser prou estreta per evitar o minimitzar la pèrdua d'informació recent.
Per això, en dissenyar un entorn de VMs altament disponible, cal combinar correctament tecnologies de clúster, replicació en temps (gairebé) real, emmagatzematge redundant i monitorització proactiva . Només així s'aconsegueix que els usuaris segueixin accedint al lloc web, la base de dades o l'aplicació corporativa gairebé sense interrupcions, fins i tot si un servidor o un NAS complet s'apaga de sobte.
A la pràctica, el més habitual és complementar l'alta disponibilitat local (per exemple, un clúster dins d'un mateix CPD) amb una estratègia de recuperació davant de desastres en un altre emplaçament . D'aquesta manera, es cobreixen tant les fallades quotidianes (discos, servidors, fonts, etc.) com esdeveniments més greus (incendis, talls d'energia prolongats, desastres naturals).
Tot aquest ventall de solucions -clústers de RHEL i Hyper-V, arquitectures HA-DAS sense SAN, alta disponibilitat específica a NAS QNAP amb Virtualization Station i replicació avançada de VMs- demostra que, a hores d'ara, és possible dissenyar entorns virtualitzats molt resistents a fallades ajustades a diferents mides d'empresa . Entendre bé les diferències entre cada enfocament, els seus límits (com el nombre màxim de nodes o la necessitat d'emmagatzematge compartit), i els requisits tècnics és clau per triar la combinació adequada i mantenir els serveis crítics en marxa gairebé sense parpellejos.
