Ciao, lettori di Habr! Nell'articolo precedente, abbiamo parlato di una semplice misura di resilienza alle catastrofi nei sistemi di archiviazione AERODISK ENGINE: la replica. In questo articolo ci immergeremo in un tema più complesso e interessante: il metrocluster, ovvero uno strumento automatizzato per la protezione contro le catastrofi per due datacenter, che consente ai datacenter di operare in modalità attiva-attiva. Racconteremo, mostreremo, romperemo e ripareremo.
Come al solito, iniziamo con la teoria
Il metrocluster è un cluster distribuito su più sedi all'interno di una città o di un'area. La parola "cluster" ci suggerisce chiaramente che il complesso è automatizzato, il che significa che il passaggio dei nodi del cluster in caso di guasti (failover) avviene automaticamente.
Qui si trova la principale differenza tra metrocluster e la normale replica. Automazione delle operazioni. In caso di determinati eventi (guasto del datacenter, interruzione dei collegamenti, ecc.), il sistema di archiviazione eseguirà autonomamente le azioni necessarie per garantire la disponibilità dei dati. Con le normali repliche, tali azioni vengono eseguite interamente o parzialmente manualmente dall'amministratore.
A cosa serve?
L'obiettivo principale dei clienti che utilizzano diverse implementazioni del metrocluster è ridurre al minimo il RTO (Recovery Time Objective). Questo significa ridurre al minimo il tempo di ripristino dei servizi IT dopo un guasto. Se si utilizza la normale replica, il tempo di ripristino sarà sempre maggiore rispetto a quello di un metrocluster. Perché? Molto semplice. L'amministratore deve essere presente in loco e commutare manualmente la replica, mentre il metrocluster lo fa automaticamente.
Se non hai un amministratore a guardia dedicato, che non dorme, non mangia, non fuma e non si ammala, e che guarda lo stato del sistema di archiviazione 24 ore su 24, non puoi garantire che l'amministratore sarà disponibile per commutare manualmente durante un guasto.
Di conseguenza, il RTO in assenza di metrocluster o di un amministratore immortale di livello 99 del servizio di addetti sarà pari alla somma del tempo di commutazione di tutti i sistemi e dell'intervallo di tempo massimo entro il quale l'amministratore inizierà sicuramente a lavorare con il sistema di archiviazione e i sistemi correlati.
Dunque arriviamo a una conclusione ovvia: il metrocluster deve essere utilizzato nel caso in cui il requisito per l'RTO sia di minuti, non di ore o giorni. Vale a dire, quando, in caso del peggior fallimento del data center, il dipartimento IT deve garantire all'azienda il tempo per il ripristino dell'accesso ai servizi IT in pochi minuti, se non secondi.
Come funziona?
A livello inferiore, il metrocluster utilizza un meccanismo di replica sincrona dei dati, che abbiamo descritto nel precedente articolo (vedi. ). Poiché la replica è sincrona, anche i requisiti ad essa associati sono di conseguenza, e più precisamente:
- fibra ottica come fisica, Ethernet a 10 gigabit (o superiore);
- distanza massima tra i data center non superiore a 40 chilometri;
- latenza del canale ottico tra i data center (tra le unità di storage) fino a 5 millisecondi (ottimale 2).
Tutti questi requisiti sono di natura raccomandativa, cioè il metrocluster funzionerà anche se questi requisiti non vengono rispettati, ma è importante capire che le conseguenze della mancata osservanza di questi requisiti equivalgono a un rallentamento delle prestazioni di entrambe le unità di storage nel metrocluster.
Quindi, per la trasmissione dei dati tra le unità di storage si utilizza una replica sincrona; in che modo le repliche vengono automaticamente commutate e, soprattutto, come evitare il "split-brain"? A questo scopo, a livello superiore viene utilizzata un'entità aggiuntiva: l'arbitro.
Come funziona l'arbitro e qual è il suo compito?
L'arbitro è una piccola macchina virtuale o un cluster hardware che deve essere avviato in una terza sede (ad esempio, in un ufficio) e deve garantire l'accesso alle unità di storage tramite ICMP e SSH. Dopo l'avvio, l'arbitro deve impostare un IP e poi, dal lato delle unità di storage, specificare il suo indirizzo e gli indirizzi dei controller remoti che partecipano al metrocluster. Dopo di che, l'arbitro è pronto per lavorare.
L'arbitro esegue un monitoraggio costante di tutte le unità di storage nel metrocluster e, in caso di inattività di un determinato sistema di storage, dopo aver confermato l'inattività da un altro membro del cluster (una delle unità di storage "attive"), prende una decisione sull'avvio della procedura di commutazione delle regole di replica e sulla mappatura.
Un aspetto molto importante. L'arbitro deve sempre trovarsi in una sede diversa da quella in cui si trovano le unità di storage, cioè né nel data center 1, dove si trova l'unità di storage 1, né nel data center 2, dove è installata l'unità di storage 2.
Perché? Perché solo in questo modo l'arbitro, con l'aiuto di uno dei controller SCD rimasti, può determinare in modo chiaro e senza errori il verificarsi di guasti in uno dei due siti dove sono installati i controller SCD. Qualsiasi altra modalità di posizionamento dell'arbitro potrebbe portare a uno split-brain.
Ora approfondiamo i dettagli del funzionamento dell'arbitro.
Sull'arbitro sono attive diverse applicazioni che interrogano continuamente tutti i controller SCD. Se il risultato dell'interrogazione è diverso dal precedente (disponibile/non disponibile), viene registrato in un piccolo database che opera anche sull'arbitro.
Esaminiamo la logica di funzionamento dell'arbitro in modo più dettagliato.
Passo 1. Determinazione della non disponibilità. L'evento che segnala un guasto del SCD è l'assenza di ping da entrambi i controller di uno stesso SCD per 5 secondi.
Passo 2. Avvio della procedura di commutazione. Dopo che l'arbitro ha compreso che uno degli SCD non è disponibile, invia una richiesta all'SCD 'vivo' per accertarsi che l'SCD 'morto' sia realmente inutilizzabile.
Dopo aver ricevuto tale comando dall'arbitro, il secondo SCD (quello 'vivo') verifica ulteriormente la disponibilità del primo SCD, se non è disponibile, invia all'arbitro la conferma della sua supposizione. L'SCD è realmente non disponibile.
Dopo aver ricevuto tale conferma, l'arbitro avvia la procedura remota di commutazione della replica e attivazione del mapping su quelle repliche che erano attive (primarie) sul SCD guastato e invia il comando al secondo SCD di trasformare queste repliche da secondarie a primarie e attivare il mapping. Il secondo SCD, di conseguenza, esegue queste procedure, dopo di che garantisce l'accesso agli LUN persi.
Perché è necessaria una verifica aggiuntiva? Per il quorum. Cioè la maggioranza del numero dispari (3) di membri del cluster deve confermare il guasto di uno dei nodi del cluster. Solo allora questa decisione sarà davvero corretta. Questo è necessario per evitare commutazioni errate e, di conseguenza, lo split-brain.
Il passo 2 richiede circa 5-10 secondi, quindi, considerando il tempo necessario per determinare la non disponibilità (5 secondi), entro 10-15 secondi dopo un guasto, gli LUN del SCD guastato saranno automaticamente disponibili per lavorare con il SCD vivo.
Evidentemente, per evitare la disconnessione con gli host, è necessario anche prendersi cura dell'impostazione corretta dei timeout sugli host. Il timeout raccomandato è di almeno 30 secondi. Questo impedirà all'host di interrompere la connessione con lo storage durante il passaggio del carico in caso di emergenza e garantirà la continuità delle operazioni di input/output.
Aspetta un attimo, quindi se il metrocluster funziona così bene, a cosa serve la replica normale?
In realtà le cose non sono così semplici.
Analizziamo i pro e i contro del metrocluster.
Dunque, abbiamo capito che i vantaggi evidenti del metrocluster rispetto alla replica normale sono:
- Automazione totale, che garantisce un minimo tempo di recupero in caso di disastro;
- E tutto :-).
Ora, attenzione, i contro:
- Costo della soluzione. Anche se il metrocluster nei sistemi Aerodisk non richiede licenze aggiuntive (si utilizza la stessa licenza della replica), il costo della soluzione sarà comunque superiore rispetto all'uso della replica sincrona. Sarà necessario soddisfare tutti i requisiti per la replica sincrona, più i requisiti per il metrocluster relativi a ulteriori commutazioni e location aggiuntive (vedi pianificazione del metrocluster);
- Complessità della soluzione. Il metrocluster è strutturato in modo significativamente più complesso rispetto a una replica normale e richiede molta più attenzione e risorse per la pianificazione, la configurazione e la documentazione.
In sintesi. Il metrocluster è sicuramente una soluzione molto tecnologica e valida quando è davvero necessario garantire un RTO in secondi o minuti. Ma se tale esigenza non esiste e un RTO in ore va bene per il business, non ha senso utilizzare strumenti così complessi. È sufficiente una replica normale, poiché il metrocluster comporterà costi aggiuntivi e una complicazione dell'infrastruttura IT.
Pianificazione del metrocluster
Questa sezione non pretende di essere una guida esaustiva alla progettazione del metrocluster, ma mostra solo le principali direzioni da considerare se hai deciso di costruire un sistema simile. Pertanto, durante l'effettiva implementazione del metrocluster, assicurati di coinvolgere per consulenze il produttore dello storage (cioè noi) e altri sistemi correlati.
Location
Come indicato sopra, per il metroklauster sono necessarie almeno tre sedi. Due data center, in cui opereranno i sistemi di archiviazione e i sistemi correlati, e una terza sede, dove opererà l'arbitro.
La distanza raccomandata tra i data center è di non oltre 40 chilometri. Distanze maggiori comportano un'alta probabilità di ritardi aggiuntivi, che nel caso del metroklauster sono estremamente indesiderabili. Ricordiamo che i ritardi devono essere fino a 5 millisecondi, anche se sarebbe preferibile rimanere entro 2.
Si consiglia di controllare anche i ritardi durante la fase di pianificazione. Qualsiasi provider di una certa esperienza che offre fibra ottica tra i data center può organizzare un test di qualità piuttosto rapidamente.
Per quanto riguarda i ritardi fino all'arbitro (cioè tra la terza sede e le due prime), il limite raccomandato è fino a 200 millisecondi, quindi un normale collegamento VPN aziendale sopra la rete Internet sarà sufficiente.
Commutazione e rete
A differenza dello schema con replica, dove è sufficiente collegare tra loro i sistemi di archiviazione da sedi diverse, lo schema con il metroklauster richiede il collegamento degli host a entrambi i sistemi di archiviazione in sedi diverse. Per chiarire le differenze, entrambe le configurazioni sono indicate di seguito.
Come si può vedere nello schema, gli host della sede 1 si collegano sia al sistema di archiviazione 1 sia al sistema di archiviazione 2. Allo stesso modo, gli host della sede 2 si collegano sia al sistema di archiviazione 2 sia al sistema di archiviazione 1. Ciò significa che ogni host vede entrambi i sistemi di archiviazione. Questa è una condizione essenziale per il funzionamento del metroklauster.
Naturalmente, non c'è bisogno di estendere ogni host con un cavo ottico all'altro data center, non ci sarebbero abbastanza porte e cavi. Tutte queste connessioni devono essere eseguite tramite switch Ethernet 10G+ o FibreChannel 8G+ (FC solo per il collegamento tra host e sistemi di archiviazione per IO; il canale di replica è al momento disponibile solo tramite IP (Ethernet 10G+).
Ora alcune parole sulla topologia della rete. Un elemento importante è la corretta configurazione delle sottoreti. È necessario definire subito diverse sottoreti per i seguenti tipi di traffico:
- Sottorete per la replica, attraverso la quale i dati verranno sincronizzati tra i sistemi di archiviazione. Possono essercene diverse; in questo caso non ha importanza, tutto dipende dalla topologia di rete attuale (già implementata). Se ce ne sono due, ovviamente, deve essere configurato il routing tra di esse.
- Sottoreti di archiviazione dati, attraverso le quali gli host accederanno alle risorse dello storage (se è iSCSI). È necessario avere una di queste sottoreti in ogni data center;
- Sottoreti di gestione, cioè tre sottoreti instradabili in tre posizioni, da cui avviene la gestione dello storage, dove si trova anche l'arbitro.
Non consideriamo qui le sottoreti per l'accesso alle risorse degli host, poiché esse dipendono fortemente dai compiti specifici.
È estremamente importante separare il traffico diverso in sottoreti diverse (è particolarmente importante separare la replica dall'input-output), poiché mescolare tutto il traffico in un'unica "sottorete grossa" renderà impossibile la gestione di quel traffico, e in presenza di due data center questo potrebbe causare varie forme di collisioni di rete. Non approfondiremo molto questo aspetto in questo articolo, poiché della pianificazione di una rete estesa tra i data center si può leggere in risorse di produttori di apparecchiature di rete, dove viene descritto in dettaglio.
Configurazione dell'arbitro
L'arbitro deve garantire l'accesso a tutte le interfacce di gestione dello storage tramite i protocolli ICMP e SSH. È importante anche considerare la resilienza dell'arbitro. C'è un aspetto da considerare.
La resilienza dell'arbitro è auspicabile ma non obbligatoria. Cosa succede se l'arbitro si guasta in un momento non opportuno?
- Il funzionamento del metrocluster in condizioni normali non cambierà, poiché l'arbitro non influisce in alcun modo sul funzionamento normale del metrocluster (il suo compito è quello di commutare tempestivamente il carico tra i data center).
- Se l'arbitro si guasta e "passa" oltre un'emergenza in un data center, non ci sarà alcuna commutazione, perché non ci sarà nessuno a dare i comandi necessari per la commutazione e a organizzare il quorum. In questo caso, il metrocluster si trasformerà in uno schema normale con replica, che dovrà essere commutato manualmente durante la catastrofe, il che influenzerà il RTO.
Cosa ne consegue? Se è davvero necessario garantire un valore minimo di RTO, è necessario garantire la resilienza dell'arbitro. Ci sono due opzioni per farlo:
- Eseguire una macchina virtuale con l'arbitro su un hypervisor resiliente, fortunatamente tutti gli hypervisor avanzati supportano la resilienza.
- Se sulla terza piattaforma (nell'ufficio convenzionale) è difficile montare un cluster adeguato e non esiste un cluster di iperconvergenza, abbiamo previsto una soluzione hardware per l'arbitro, realizzata in un contenitore 2U, in cui operano due normali server x-86 e che può superare un guasto locale.
Raccomandiamo vivamente di garantire la ridondanza dell'arbitro anche se, in condizioni normali, non è necessaria per il metrocluster. Ma come dimostrano sia la teoria che la pratica, se si desidera costruire un'infrastruttura realmente resiliente ai disastri, è meglio essere previdenti. È consigliabile proteggere se stessi e il proprio business dalla "legge di Murphy", ovvero dall'improvviso guasto sia dell'arbitro che di uno dei siti dove è posizionato lo storage.
Architettura della soluzione
Considerando i requisiti sopra indicati, otteniamo la seguente architettura generale della soluzione.
I LUN devono essere distribuiti uniformemente su due piattaforme per evitare sovraccarichi eccessivi. Inoltre, nella fase di sizing, in entrambi i data center deve essere prevista non solo una capacità doppia (necessaria per memorizzare i dati contemporaneamente su due storage), ma anche una doppia performance in IOPS e MB/s, per evitare degrado delle applicazioni in caso di guasto di uno dei data center.
Vale la pena notare che con un approccio adeguato al sizing (ossia, a condizione che abbiamo previsto adeguati limiti superiori per IOPS e MB/s, così come le risorse necessarie di CPU e RAM) in caso di guasto di uno degli storage nel metrocluster non ci sarà un significativo calo delle performance durante la temporanea operatività su uno storage.
Questo è dovuto al fatto che nelle condizioni di funzionamento simultaneo di due piattaforme, la replica sincrona 'consuma' metà delle performance in scrittura, poiché ogni transazione deve essere registrata su entrambi gli storage (analogamente a RAID-1/10). Pertanto, in caso di guasto di uno degli storage, l'influenza della replica scompare temporaneamente (fino al ripristino dello storage guasto), e otteniamo un raddoppio delle performance in scrittura. Dopo che i LUN dello storage guasto sono stati riavviati su quello funzionante, questo raddoppio delle performance svanisce a causa del carico proveniente dai LUN dell'altro storage, e torniamo allo stesso livello di performance che avevamo prima del 'guasto', ma solo all'interno di una singola piattaforma.
Grazie a un sizing accurato, è possibile creare condizioni in cui gli utenti non percepiranno affatto il fallimento di un'intera SAN. Ma ripetiamo, ciò richiede un sizing molto attento, al quale, per inciso, potete rivolgervi gratuitamente a noi :-).
Configurazione del metrocluster
La configurazione di un metrocluster è molto simile alla configurazione di una replica normale, che abbiamo descritto in . Pertanto, ci concentreremo solo sulle differenze. Abbiamo impostato un ambiente di laboratorio basato sull'architettura sopra, ma in un formato minimo: due SAN collegate tra loro tramite Ethernet 10G, due switch 10G e un host che accede a entrambe le SAN tramite porte 10G. L'arbitro funziona su una macchina virtuale.
Quando si impostano gli IP virtuali (VIP) per la replica, è necessario scegliere il tipo di VIP – per il metrocluster.
Abbiamo creato due connessioni di replica per due LUN e le abbiamo distribuite su due SAN: LUN TEST Primary su SAN1 (connessione METRO), LUN TEST2 Primary per SAN2 (connessione METRO2).
Per questi abbiamo configurato due target identici (nel nostro caso iSCSI, ma è supportato anche FC, la logica di configurazione è la stessa).
SAN1:
SAN2:
Per le connessioni di replica sono stati creati mapping su ciascuna SAN.
SAN1:
SAN2:
Abbiamo configurato il multipath e lo abbiamo presentato all'host.
Configurare l'arbitro
Non è necessario fare molto con l'arbitro stesso, basta accenderlo nel terzo sito, assegnargli un IP e configurare l'accesso tramite ICMP e SSH. La configurazione stessa viene effettuata dalle SAN. Inoltre, la configurazione dell'arbitro deve essere eseguita una sola volta su uno qualsiasi dei controller della SAN nel metrocluster; queste impostazioni verranno propagate automaticamente a tutti i controller.
Nella sezione Replica remota>> Metrocluster (su qualsiasi controller)>> pulsante 'Configura'.
Inseriamo l'IP dell'arbitro e le interfacce di gestione dei due controller della SAN remota.
Dopo di ciò, è necessario avviare tutti i servizi (pulsante 'Riavvia tutto'). In caso di riconfigurazione in futuro, è fondamentale riavviare i servizi affinché le impostazioni abbiano effetto.
Controlliamo che tutti i servizi siano attivi.
A questo punto, la configurazione del metrocluster è completata.
Crash test
Il crash test nel nostro caso sarà abbastanza semplice e veloce, poiché la funzionalità di replica (failover, consistenza, ecc.) è stata trattata in . Pertanto, per testare l'affidabilità del metrocluster, è sufficiente verificare l'automazione del rilevamento dei guasti, il passaggio e l'assenza di perdite durante la scrittura (interruzioni dell'input/output).
Per questo emuliamo un guasto completo di uno dei sistemi di archiviazione, spegnendo fisicamente entrambi i suoi controller, avviando in precedenza il trasferimento di un grande file su un LUN, che deve attivarsi su un altro sistema di archiviazione.
Disconnettiamo un sistema di archiviazione. Sul secondo sistema vediamo avvisi e messaggi nei log riguardo la perdita di connessione con il sistema adiacente. Se le notifiche sono impostate tramite SMTP o monitoraggio SNMP, l'amministratore riceverà le comunicazioni pertinenti.
Esattamente dopo 10 secondi (visibile in entrambi gli screenshot) la connessione di replica METRO (quella che era primaria sul sistema di archiviazione guasto) è diventata automaticamente primaria sul sistema di archiviazione attivo. Utilizzando il mapping esistente, il LUN TEST è rimasto accessibile all'host, la scrittura ha subito una leggera diminuzione (nel limite del 10% promesso), ma non si è interrotta.
Il test è stato completato con successo.
Riassumiamo
L'attuale implementazione del metrocluster nei sistemi di archiviazione della serie N di AERODISK Engine consente di affrontare pienamente compiti in cui è necessario ridurre o minimizzare i tempi di inattività dei servizi IT e garantire il loro funzionamento in modalità 24/7/365 con il minimo sforzo.
Si può certamente dire che tutto questo è teoria, condizioni di laboratorio ideali e così via... MA abbiamo una serie di progetti realizzati in cui abbiamo implementato funzionalità di resilienza ai disastri, e i sistemi funzionano egregiamente. Uno dei nostri clienti abbastanza noti, in cui sono utilizzati proprio due sistemi di archiviazione in configurazione resiliente ai disastri, ha già dato il consenso per la pubblicazione delle informazioni sul progetto, quindi nella prossima parte parleremo dell'implementazione in campo.
Grazie, attendiamo una discussione produttiva.
Fonte: habr.com
