Alta disponibilità sui server virtualizzati: una guida completa

Informatec Digital » Risorse » Alta disponibilità su server virtualizzati: una guida completa

L'alta disponibilità sui server virtualizzati è diventata un requisito fondamentale per qualsiasi organizzazione che non possa permettersi interruzioni del servizio, nemmeno di pochi minuti. Si tratta di garantire che macchine virtuali, applicazioni e dati rimangano accessibili anche in caso di guasto di un server fisico, di un disco, di una rete o persino di un intero data center. Non si tratta solo di avere dei backup, ma di mantenere il servizio attivo in qualsiasi circostanza.

Quando si combinano virtualizzazione , cluster, storage e disaster recovery , emergono numerose tecnologie (KVM, Xen, Hyper-V, RHEL HA, RHEV, CSV, NAS, JBOD, repliche, ecc.) e non è sempre chiaro quale scegliere o come integrarle al meglio. Questo articolo offre una panoramica approfondita delle principali opzioni e approcci: dai cluster tradizionali con storage condiviso alle soluzioni moderne basate sulla replica in tempo reale tra nodi, con esempi specifici relativi alle architetture Red Hat, Microsoft Hyper-V, QNAP e HA-DAS.

Concetti di base dell'alta disponibilità negli ambienti virtualizzati

In un ambiente virtualizzato, l'alta disponibilità (HA) significa che le macchine virtuali (VM) rimangono accessibili anche in caso di guasto di uno o più componenti del sistema (server, dischi, controller, rete, alimentazione, ecc.). Questo non è lo stesso concetto del ripristino di emergenza (DR): l'HA mira a ridurre al minimo o a eliminare i tempi di inattività, mentre il DR in genere accetta un certo periodo di inattività per ripristinare i servizi da un backup.

Per ottenere questo comportamento, vengono combinati diversi componenti: ridondanza hardware, software di clustering, storage tollerante ai guasti e meccanismi di monitoraggio e failover . L'obiettivo è evitare singoli punti di guasto: se un componente si guasta, un altro subentra automaticamente senza intervento manuale (o con un intervento minimo).

Nel mondo della virtualizzazione, questo si traduce tipicamente nella presenza di più host fisici che condividono o replicano lo storage e in un sistema che monitora lo stato dei nodi e delle macchine virtuali. Quando un host si guasta, le macchine virtuali vengono avviate su un altro host, idealmente senza che l'utente se ne accorga o con un'interruzione molto breve.

È inoltre importante distinguere tra soluzioni progettate per ambienti "cloud" elastici e piattaforme HA classiche. Alcuni prodotti cluster hanno una configurazione relativamente statica e un numero massimo di nodi relativamente basso, quindi non sono adatti per la creazione di un cloud di grandi dimensioni, sebbene siano eccellenti per la protezione di un insieme ben definito di servizi critici.

In un ambiente cloud o ibrido, è consigliabile rivedere le strategie specifiche di migrazione e continuità operativa: ad esempio, la migrazione al cloud può far parte della strategia di disaster recovery, ma non sostituisce l'alta disponibilità locale.

Elevata disponibilità sulle piattaforme Red Hat Enterprise Linux e KVM/Xen.

L'ecosistema Red Hat offre diverse opzioni per la protezione delle macchine virtuali tramite cluster e componenti aggiuntivi per l'alta disponibilità . Versioni come Red Hat Enterprise Linux 5 e 6 supportano varie combinazioni di hypervisor e componenti aggiuntivi per cluster.

RHEL 5 supporta due piattaforme di virtualizzazione: Xen (a partire da RHEL 5.0) e KVM (a partire da RHEL 5.4) . Il componente aggiuntivo RHEL 5 Advanced Platform (AP) Cluster consente di gestire sia le macchine virtuali Xen che KVM come risorse del cluster, in modo che l'infrastruttura di alta disponibilità dell'host controlli l'avvio, l'arresto e il failover delle macchine virtuali tra i nodi.

Con RHEL 6, il supporto alla virtualizzazione è semplificato: come hypervisor è supportato solo KVM . Tuttavia, il plugin RHEL 6 High Availability consente ancora di trattare le macchine virtuali KVM come risorse del cluster gestite dall'infrastruttura HA dell'host. Il gestore delle risorse del cluster (rgmanager nelle versioni classiche) è responsabile del monitoraggio dei nodi e dello spostamento delle macchine virtuali tra i server fisici in caso di rilevamento di un errore.

Questo approccio viene spesso definito " cluster RHEL/HA in esecuzione su host fisici che funge da piattaforma di virtualizzazione ". Il cluster RHEL gestisce autonomamente l'esecuzione di ciascuna macchina virtuale e subentra in caso di guasto di un nodo, garantendo che le macchine virtuali configurate come critiche vengano riavviate su un host funzionante.

Un aspetto interessante è che, dal punto di vista del cluster, il sistema operativo guest della macchina virtuale è meno importante . Qualsiasi sistema operativo guest compatibile con Xen o KVM in RHEL può essere trattato come una macchina virtuale ad alta disponibilità: diverse versioni di RHEL (3, 4, 5, ecc.) e varie edizioni di Microsoft Windows, purché siano supportate dall'hypervisor. Ciò offre una notevole flessibilità nella protezione di ambienti misti.

Tuttavia, la stessa Red Hat raccomanda cautela nella scelta tra l'utilizzo dell'add-on RHEL High Availability e piattaforme di virtualizzazione più complete come Red Hat Enterprise Virtualization (RHEV) per garantire l'alta disponibilità delle macchine virtuali. Entrambe offrono funzionalità di alta disponibilità, ma i casi d'uso sono diversi ed è necessario considerare le dimensioni dell'ambiente e il modello operativo.

Quando utilizzare RHEL HA rispetto a RHEV per l'alta disponibilità

Quando si decide se utilizzare l'add-on RHEL HA o una piattaforma come RHEV per proteggere le macchine virtuali, uno dei criteri chiave è il numero di host fisici e il tipo di utilizzo che verrà fatto dell'ambiente virtualizzato.

Il componente aggiuntivo per l'alta disponibilità di RHEL è progettato per cluster relativamente piccoli e con configurazione statica . Tradizionalmente, questi cluster hanno un limite massimo di circa 16 nodi fisici, il che è sufficiente per molti ambienti aziendali ma non si adatta bene alle architetture di tipo cloud con decine o centinaia di host in continuo cambiamento.

Pertanto, la documentazione di Red Hat stessa indica che l'utilizzo esclusivo di RHEL HA per la creazione di infrastrutture di tipo cloud non è raccomandato , proprio a causa della sua natura statica e del limite al numero di nodi. Per gli scenari cloud, è più opportuno utilizzare piattaforme progettate specificamente per tale modello, con gestori di risorse più elastici e scalabili.

D'altro canto, se l'obiettivo è proteggere un numero moderato di macchine virtuali critiche su un insieme ben definito di host , il componente aggiuntivo HA di RHEL rappresenta una soluzione robusta: si integra perfettamente con il sistema operativo, si basa su tecnologie di clustering consolidate e fornisce la logica necessaria per monitorare e spostare le macchine virtuali in caso di guasto.

In ogni caso, è consigliabile consultare la documentazione RHEL più recente sui sistemi operativi guest supportati e sulle combinazioni di hypervisor e cluster , poiché il supporto si evolve a ogni rilascio ed è importante attenersi alle matrici ufficiali.

Alta disponibilità in Hyper-V: cluster, repliche e migrazione live

Negli ambienti Microsoft, l'alta disponibilità si basa fondamentalmente sulle funzionalità di Hyper-V combinate con il clustering di failover di Windows Server . L'obiettivo è garantire un accesso costante alle macchine virtuali anche in caso di guasti hardware, problemi di rete o errori software.

Il componente principale è rappresentato dai cluster di failover Hyper-V . Un cluster di questo tipo è un insieme di server (nodi) che condividono lo storage e lavorano in modo coordinato: se un nodo si guasta, le macchine virtuali in esecuzione su di esso vengono riavviate automaticamente su un altro nodo del cluster. Tutto ciò è reso possibile da tecnologie di dischi condivisi e da specifiche comunicazioni interne.

Affinché ciò funzioni, i nodi in genere condividono lo storage tramite una SAN (Storage Area Network) o un server di file scalabile (SOFS) . Su questo livello vengono quindi creati i Cluster Shared Volumes (CSV) , che consentono a tutti i nodi di accedere simultaneamente agli stessi dischi in cui risiedono i file delle macchine virtuali.

I nodi comunicano anche tramite una rete dedicata nota come heartbeat del cluster . Questa rete è separata dalla rete dati di produzione e consente a ciascun server di segnalare il proprio stato di attività. Se il cluster smette di ricevere heartbeat da un nodo, quest'ultimo viene considerato guasto e vengono avviate le procedure di failover.

Un altro elemento fondamentale è la configurazione del quorum . Il quorum definisce quanti voti (nodi o witness esterni) devono essere attivi affinché il cluster continui a funzionare. Questo previene scenari di "split brain", in cui gruppi isolati di nodi credono erroneamente di essere il cluster principale e causano il danneggiamento dei dati. La scelta del modello di quorum corretto (nodi, witness su disco, witness su condivisione file, ecc.) è fondamentale per la stabilità.

Sulla base di ciò, Hyper-V sfrutta le funzionalità del cluster per consentire migrazioni live di macchine virtuali tra nodi con tempi di inattività minimi . Durante la manutenzione o il bilanciamento del carico, una VM può essere spostata da un host all'altro senza interruzione del servizio, trasferendo in modo trasparente memoria, stato e connessioni attive.

Se, invece di una manutenzione programmata, si verifica un guasto hardware o software effettivo su un nodo, il cluster esegue un failover automatico . Le macchine virtuali in esecuzione su quel nodo vengono avviate su un altro host con accesso allo stesso storage condiviso. L'interruzione è maggiore rispetto a una migrazione a caldo (le macchine virtuali devono essere spente e riaccese), ma la continuità del servizio è garantita con un intervento umano minimo.

Replica Hyper-V e migrazione live "senza condivisione"

Oltre al classico cluster SAN, Hyper-V integra altre tecnologie incentrate sia sull'alta disponibilità che sul ripristino di emergenza, in particolare Hyper-V Replica e la migrazione live senza storage condiviso.

Hyper-V Replication è una funzionalità di replica asincrona di macchine virtuali che replica le macchine virtuali tra un host primario e uno o più host di replica, in genere situati in un sito o data center diverso. Le modifiche vengono inviate alla VM di destinazione a intervalli regolari, creando punti di ripristino che consentono di ripristinare la VM a uno stato recente in caso di disastro nel sito primario.

Questo meccanismo utilizza un agente di replica Hyper-V che coordina il traffico di replica, gestisce i punti di ripristino e centralizza le operazioni di failover. Consente sia failover pianificati (ad esempio, per spostare l'ambiente di produzione in un altro sito) sia failover non pianificati (quando il sito primario si arresta inaspettatamente).

A causa della sua natura asincrona, la replica è più orientata al ripristino di emergenza ( DR) che all'alta disponibilità (HA) con tempi di inattività prossimi allo zero. Dopo un incidente, è necessario avviare un failover sulla VM di replica e, sebbene il processo sia piuttosto agile, comporta un certo tempo di inattività e la potenziale perdita degli ultimi secondi o minuti di dati, a seconda dell'intervallo di replica configurato.

Parallelamente, Hyper-V offre la migrazione live Shared Nothing , che consente di spostare una macchina virtuale tra host che non condividono lo storage. In questo modello, ogni host dispone di un proprio storage locale, ma la migrazione live copia in modo trasparente i dischi della macchina virtuale nella destinazione mentre la macchina virtuale rimane online, per poi trasferire l'esecuzione sul nuovo server.

Questa funzionalità è particolarmente utile in ambienti privi di SAN o di un'infrastruttura di storage condivisa , riducendo i costi iniziali per le PMI o in scenari in cui il mantenimento di una rete di storage dedicata non è auspicabile. Consente, ad esempio, di riorganizzare gli host o migrare a nuovo hardware con un impatto minimo, senza dover spegnere le macchine esistenti.

La combinazione di queste tecnologie (cluster di failover, CSV, migrazione live con o senza storage condiviso e replica Hyper-V) offre un'ampia gamma di opzioni per la progettazione di strategie di continuità operativa e tolleranza ai guasti, adattabili a diversi budget e livelli di domanda.

Soluzioni ad alta disponibilità con HA-DAS e Windows Server

Oltre agli ambienti con SAN di grandi dimensioni, esistono architetture progettate per l'alta disponibilità in sistemi di storage collegati direttamente ai server (HA-DAS) . Queste soluzioni sfruttano Windows Server (ad esempio, 2012) e controller RAID/HBA avanzati per fornire cluster ad alta disponibilità senza la necessità di configurare una SAN iSCSI o FC tradizionale.

Questo approccio utilizza due nodi cluster HA con storage JBOD condiviso (semplicemente un insieme di dischi senza alcuna intelligenza integrata). Il JBOD si connette a entrambi i server tramite controller HBA Host RAID ridondanti, in modo che ogni nodo veda lo stesso set di dischi e possa accedere simultaneamente allo stesso array RAID.

Queste soluzioni possono raggiungere capacità fino a 180 TB in uno chassis condiviso , funzionando con unità magnetiche o SSD hot-swap in diversi livelli RAID. I controller RAID in genere integrano 1 GB di cache ciascuno, con la cache replicata su tutti i controller per mantenere la coerenza e migliorare le prestazioni, e la protezione della cache si basa su supercondensatori anziché sulle tradizionali batterie.

La comunicazione tra i controller avviene in genere tramite collegamenti SAS , eliminando la necessità di collegamenti Ethernet heartbeat per la sincronizzazione dello stato del disco. Ciò fornisce un percorso di comunicazione diretto e altamente affidabile tra i due nodi di storage.

Un'altra caratteristica importante è che queste architetture operano tipicamente in modalità attivo/attivo sullo stesso array RAID . Ciò significa che entrambi i nodi forniscono servizio simultaneamente e sfruttano la potenza di calcolo di entrambi i server, invece di lasciare uno "in standby" fino al guasto dell'altro. Questo evita di sprecare il 50% dell'investimento hardware che di solito si verifica nei cluster attivo/passivo.

Utilizzando Windows Server 2012 (o versioni successive), gli amministratori beneficiano di un ambiente di gestione familiare: strumenti, procedure guidate, console di gestione e modello di autorizzazioni già noti. I tempi di apprendimento sono ridotti al minimo, con conseguente riduzione dei costi operativi e dei rischi durante l'implementazione.

Queste soluzioni HA-DAS sono pensate per diversi utilizzi: virtualizzazione di server Hyper-V, VDI Windows, storage SAN/NAS, database transazionali (OLTP) , data warehousing e servizi web ad alta disponibilità . Tutto ciò è reso possibile sfruttando un singolo chassis di storage condiviso, due nodi ridondanti e la logica di clustering di Windows.

Elevata disponibilità specifica per array NAS QNAP e Virtualization Station 4

Nel settore NAS, produttori come QNAP hanno sviluppato funzionalità avanzate per garantire un'elevata disponibilità sia per lo storage che per le macchine virtuali ospitate sui loro dispositivi . In particolare, combinano il sistema operativo QuTS hero (basato su ZFS) con Virtualization Station 4 per offrire replica e failover in tempo reale tra due dispositivi NAS.

Da un lato, il sistema QuTS hero integra le tecnologie di alta disponibilità (HA) direttamente nel NAS , consentendo di configurare due dispositivi identici (o simili) come una coppia ad alta disponibilità. In caso di guasto di un NAS, il secondo subentra automaticamente e i servizi rimangono operativi. Ciò protegge sia lo storage che i servizi principali del NAS.

Partendo da queste basi, la nuova funzionalità di alta disponibilità di Virtualization Station 4 (disponibile in versione beta nelle versioni recenti) fa un ulteriore passo avanti: consente alle macchine virtuali in esecuzione sul NAS di beneficiare di una tolleranza ai guasti avanzata tramite la replica in tempo reale tra due dispositivi QNAP.

Questa funzionalità è disponibile solo sui dispositivi NAS QNAP con processori x86 che eseguono QuTS hero e la versione appropriata di Virtualization Station 4. L'utilizzo di ZFS e della tecnologia SnapSync è essenziale, in quanto sincronizza i dati delle macchine virtuali tra i due dispositivi NAS in tempo reale, garantendo che la macchina virtuale replicata sia sempre aggiornata.

Lo schema operativo si basa su due dispositivi NAS che si supportano a vicenda : NAS A e NAS B fungono da nodi di backup l'uno per l'altro, in entrambe le direzioni. Ciascuno può ospitare le proprie macchine virtuali e, per quelle contrassegnate come protette da HA, viene creata una replica sull'altro NAS. In caso di guasto di uno dei dispositivi, l'altro ne assume il controllo e avvia le macchine virtuali interessate.

Ciò consente una commutazione fluida tra i server NAS . La protezione ad alta disponibilità (HA) può essere attivata solo per specifiche macchine virtuali critiche senza influire sugli altri servizi NAS (ad esempio, backup, condivisione file, ecc.). Ogni NAS può continuare a svolgere la sua funzione originale proteggendo al contempo le macchine virtuali designate per l'alta disponibilità.

La sincronizzazione in tempo reale basata su SnapSync garantisce che, in caso di incidente, il failover sia praticamente istantaneo e senza perdita di dati . A differenza delle architetture tradizionali che si basano su un'area di archiviazione condivisa centrale (SAN), questa soluzione elimina il singolo punto di guasto: ogni NAS mantiene una copia completa e coerente delle macchine virtuali che protegge.

Inoltre, QNAP definisce diverse condizioni di guasto che possono innescare un failover : sovraccarico prolungato della CPU (al di sopra di una determinata soglia, ad esempio l'80% per un certo periodo di tempo), temperatura di sistema eccessiva, guasto del disco anche in configurazioni RAID, perdita di uno degli alimentatori ridondanti, tra gli altri. Il sistema valuta queste condizioni e, se il NAS viene ritenuto inaffidabile, trasferisce il carico all'altro nodo.

Il sistema offre anche la possibilità di migrazioni manuali , molto utili quando il team tecnico desidera migrare macchine virtuali su un altro NAS in modo controllato per attività di manutenzione come la sostituzione dei dischi, l'aggiornamento del firmware, la modifica delle impostazioni avanzate, ecc. La migrazione è molto rapida (nell'ordine di meno di un secondo), rendendo il processo praticamente trasparente per gli utenti.

Un altro aspetto interessante è l' assenza di costi di licenza aggiuntivi : la funzionalità di alta disponibilità di Virtualization Station 4 è integrata nell'applicazione stessa ed è inclusa nel sistema, senza costi extra per nodo o per macchina virtuale. Questo la rende particolarmente attraente per le PMI e gli ambienti che cercano alta disponibilità a un costo ragionevole.

Requisiti e limitazioni dell'alta disponibilità in QNAP

Per implementare con successo questa soluzione su QNAP, è fondamentale soddisfare determinati requisiti software, hardware e di rete . Non sono particolarmente complessi, ma è importante averli ben chiari prima di progettare l'ambiente.

Per quanto riguarda il software, sono richiesti QuTS hero versione h5.3 o superiore e Virtualization Station 4.1 o successiva. Solo queste versioni includono la funzionalità VM HA basata su SnapSync. Questa funzionalità non è disponibile sui dispositivi NAS con QTS "classico" o versioni precedenti di Virtualization Station.

A livello hardware, i due dispositivi NAS non devono essere necessariamente dello stesso modello, ma devono utilizzare processori della stessa architettura e marca (entrambi Intel o entrambi AMD) . Questo semplifica la compatibilità e garantisce che le macchine virtuali replicate possano essere eseguite senza problemi su entrambi i dispositivi.

Per quanto riguarda la rete, è fondamentale che entrambi i dispositivi NAS si trovino sullo stesso segmento di rete e che vi sia una connessione diretta tra di essi tramite un cavo di rete fisico dedicato per la sincronizzazione dei dati delle macchine virtuali. Questo collegamento dedicato funge da canale "out-of-band" per la replica, evitando interferenze con il normale traffico utente.

In pratica, i requisiti hardware effettivi si riducono a questo: la stessa famiglia di CPU e un collegamento diretto tra i dispositivi NAS . Tutto il resto (capacità del disco, RAM, ecc.) viene dimensionato in base al numero di macchine virtuali da proteggere e alle prestazioni previste. Se queste condizioni sono soddisfatte, la configurazione HA di QNAP è relativamente semplice e molto robusta.

Differenza tra alta disponibilità e replica/disaster recovery semplice nelle macchine virtuali

Le soluzioni di replica delle macchine virtuali come meccanismo di ripristino di emergenza vengono spesso confuse con la vera alta disponibilità con tempi di inattività pari a zero (o minimi). Entrambe sono importanti, ma risolvono problemi diversi.

Ad esempio, negli ambienti VMware vSphere, è comune configurare la replica delle macchine virtuali verso un sito di disaster recovery (DR) , in modo che l'immagine del disco del server primario venga copiata sul nodo di disaster recovery. Questo protegge dalla perdita totale del sito primario, ma in caso di guasto, di solito è necessario un ripristino manuale: accensione delle macchine virtuali nel sito DR, riconfigurazione delle reti, verifica dell'integrità dei dati e così via.

Questo processo, sebbene parzialmente automatizzabile, comporta tempi di inattività che possono variare da minuti a ore, a seconda della complessità dell'ambiente e delle procedure interne. Si tratta di un'ottima strategia di ripristino d'emergenza, ma non soddisfa l'obiettivo di disponibilità quasi continua richiesto da una soluzione di alta disponibilità (HA) rigorosa.

Una vera alta disponibilità richiede un meccanismo di failover automatico o quasi automatico con tempi di inattività minimi e senza necessità di complesse operazioni manuali in caso di guasto di un componente. Inoltre, la sincronizzazione dei dati tra i nodi attivi e di backup deve essere sufficientemente precisa da prevenire o ridurre al minimo la perdita di informazioni recenti.

Pertanto, nella progettazione di un ambiente VM ad alta disponibilità, è fondamentale combinare correttamente tecnologie di clustering, replica quasi in tempo reale, storage ridondante e monitoraggio proattivo . Solo in questo modo gli utenti possono continuare ad accedere al sito web, al database o all'applicazione aziendale con interruzioni minime, anche in caso di arresto improvviso di un intero server o NAS.

In pratica, l'approccio più comune consiste nell'integrare l'alta disponibilità locale (ad esempio, un cluster all'interno dello stesso data center) con una strategia di disaster recovery in una sede diversa . In questo modo, vengono gestiti sia i guasti di routine (dischi, server, alimentatori, ecc.) sia gli eventi più gravi (incendi, interruzioni di corrente prolungate, calamità naturali).

Questa vasta gamma di soluzioni – cluster RHEL e Hyper-V, architetture HA-DAS senza SAN, alta disponibilità dedicata su NAS QNAP con Virtualization Station e replica avanzata di macchine virtuali – dimostra che ora è possibile progettare ambienti virtualizzati altamente tolleranti ai guasti, personalizzati in base alle diverse dimensioni e budget aziendali . Una conoscenza approfondita delle differenze tra ciascun approccio, dei loro limiti (come il numero massimo di nodi o la necessità di storage condiviso) e dei requisiti tecnici è fondamentale per scegliere la combinazione giusta e mantenere i servizi critici in funzione in modo pressoché ininterrotto.