Ciao, lettori di Habr! Nell'ultimo articolo abbiamo parlato di un semplice mezzo di ripristino di emergenza nei sistemi di archiviazione AERODISK ENGINE: la replica. In questo articolo approfondiremo un argomento più complesso e interessante: il metrocluster, ovvero un mezzo di protezione automatizzata dai disastri per due data center, che consente ai data center di funzionare in modalità attivo-attivo. Te lo diremo, te lo mostreremo, lo spezzeremo e lo sistemeremo.
Come al solito, prima la teoria
Un metrocluster è un cluster distribuito su più siti all'interno di una città o regione. La parola "cluster" ci suggerisce chiaramente che il complesso è automatizzato, ovvero il cambio dei nodi del cluster in caso di guasti avviene automaticamente.
È qui che risiede la differenza principale tra un metrocluster e la replica regolare. Automazione delle operazioni. Cioè, in caso di determinati incidenti (guasto del data center, canali interrotti, ecc.), il sistema di storage eseguirà autonomamente le azioni necessarie per mantenere la disponibilità dei dati. Quando si utilizzano repliche regolari, queste azioni vengono eseguite interamente o parzialmente manualmente dall'amministratore.
A cosa serve?
L'obiettivo principale che i clienti perseguono quando utilizzano determinate implementazioni di metrocluster è ridurre al minimo l'RTO (Recovery Time Objective). Cioè per ridurre al minimo i tempi di ripristino dei servizi IT dopo un guasto. Se utilizzi la replica regolare, il tempo di ripristino sarà sempre più lungo del tempo di ripristino con un metrocluster. Perché? Molto semplice. L'amministratore deve essere alla sua scrivania e cambiare manualmente la replica, e il metrocluster lo fa automaticamente.
Se non si dispone di un amministratore dedicato in servizio che non dorme, non mangia, non fuma o si ammala e controlla lo stato del sistema di storage 24 ore su XNUMX, non c'è modo di garantire che l'amministratore lo faccia essere disponibile per la commutazione manuale durante un guasto.
Di conseguenza, l'RTO in assenza di un metrocluster o di un amministratore immortale del 99 ° livello del servizio di amministrazione sarà pari alla somma del tempo di commutazione di tutti i sistemi e del periodo di tempo massimo dopo il quale è garantito che l'amministratore inizi a lavorare con sistemi di stoccaggio e relativi sistemi.
Pertanto, arriviamo all’ovvia conclusione che il metrocluster dovrebbe essere utilizzato se il requisito per l’RTO è di minuti e non di ore o giorni, ovvero quando, in caso di grave guasto del data center, il reparto IT deve fornire all’azienda tempo per ripristinare l'accesso ai servizi IT in pochi minuti o addirittura secondi.
Come funziona?
Al livello inferiore, il metrocluster utilizza un meccanismo di replica sincrona dei dati, che abbiamo descritto nel precedente articolo (vedi. ). Poiché la replica è sincrona, i requisiti per essa sono corrispondenti, o meglio:
- fibra ottica come fisica, 10 gigabit Ethernet (o superiore);
- la distanza tra i data center non è superiore a 40 chilometri;
- il ritardo del canale ottico tra data center (tra sistemi di storage) è fino a 5 millisecondi (in modo ottimale 2).
Tutti questi requisiti sono di natura consultiva, cioè il metrocluster funzionerà anche se questi requisiti non vengono soddisfatti, ma dobbiamo capire che le conseguenze del mancato rispetto di questi requisiti equivalgono a un rallentamento del funzionamento di entrambi i sistemi di stoccaggio in il metrocluster.
Quindi, per trasferire i dati tra sistemi di storage viene utilizzata una replica sincrona. In che modo le repliche cambiano automaticamente e, soprattutto, come evitare lo split-brain? Per fare ciò, a un livello superiore, viene utilizzata un'entità aggiuntiva: un arbitro.
Come funziona un arbitro e qual è il suo compito?
L'arbitro è una piccola macchina virtuale o un cluster hardware che deve essere avviato su un terzo sito (ad esempio in un ufficio) e fornire l'accesso al sistema di storage tramite ICMP e SSH. Dopo il lancio, l'arbitro dovrebbe impostare l'IP, quindi dal lato dello storage indicare il suo indirizzo, più gli indirizzi dei controllori remoti che partecipano al metrocluster. Dopodiché l'arbitro è pronto a lavorare.
L'arbitro monitora costantemente tutti i sistemi di storage del metrocluster e se un particolare sistema di storage non è disponibile, dopo aver confermato l'indisponibilità da un altro membro del cluster (uno dei sistemi di storage “live”), decide di avviare la procedura di cambio delle regole di replica e mappatura.
Un punto molto importante. L'arbitro deve sempre trovarsi in un sito diverso da quello in cui sono ubicati i sistemi di storage, ovvero né nel data center 1, dove è installato il sistema di storage 1, né nel data center 2, dove è installato il sistema di storage 2.
Perché? Perché solo così un arbitro, con l'aiuto di uno dei sistemi di stoccaggio sopravvissuti, può determinare in modo inequivocabile e preciso il crollo di uno qualsiasi dei due siti in cui sono installati i sistemi di stoccaggio. Qualsiasi altro metodo per collocare un arbitro può provocare una divisione del cervello.
Entriamo ora nei dettagli del lavoro dell'arbitro.
L'arbitro esegue diversi servizi che interrogano costantemente tutti i controller di archiviazione. Se il risultato del sondaggio differisce dal precedente (disponibile/non disponibile), allora viene registrato in un piccolo database, che funziona anche sull'arbitro.
Consideriamo più in dettaglio la logica del lavoro dell'arbitro.
Passaggio 1: determinare l'indisponibilità. Un evento di guasto del sistema di storage è l'assenza di ping da entrambi i controller dello stesso sistema di storage entro 5 secondi.
Passaggio 2. Avviare la procedura di cambio. Dopo che l'arbitro si è accorto che uno dei sistemi di stoccaggio non è disponibile, invia una richiesta al sistema di stoccaggio “attivo” per assicurarsi che il sistema di stoccaggio “morto” sia davvero morto.
Dopo aver ricevuto tale comando dall'arbitro, il secondo sistema di archiviazione (live) verifica inoltre la disponibilità del primo sistema di archiviazione caduto e, se non è presente, invia conferma all'arbitro della sua ipotesi. Il sistema di storage infatti non è disponibile.
Dopo aver ricevuto tale conferma, l'arbitro avvia una procedura remota per cambiare replica e aumentare la mappatura su quelle repliche che erano attive (primarie) sul sistema di storage caduto e invia un comando al secondo sistema di storage per modificare queste repliche da secondarie a primarie e aumentare la mappatura. Bene, il secondo sistema di archiviazione, rispettivamente, esegue queste procedure e quindi fornisce l'accesso ai LUN persi da solo.
Perché è necessaria un'ulteriore verifica? Per il quorum. Cioè, la maggioranza del numero totale dispari (3) dei membri del cluster deve confermare la caduta di uno dei nodi del cluster. Solo allora questa decisione sarà definitivamente corretta. Ciò è necessario per evitare commutazioni errate e, di conseguenza, split-brain.
La fase temporale 2 richiede circa 5 - 10 secondi, pertanto, tenendo conto del tempo necessario per determinare l'indisponibilità (5 secondi), entro 10 - 15 secondi dopo l'incidente, le LUN del sistema di storage caduto saranno automaticamente disponibili per funzionare con il sistema attivo sistema di archiviazione.
È chiaro che per evitare di perdere la connessione con gli host bisogna avere cura anche di configurare correttamente i timeout sugli host. Il timeout consigliato è di almeno 30 secondi. Ciò impedirà all'host di interrompere la connessione al sistema di storage durante il cambio di carico in caso di disastro e può garantire che non vi siano interruzioni di I/O.
Aspetta un secondo, si scopre che se tutto va così bene con il metrocluster, perché abbiamo bisogno di una replica regolare?
In realtà, tutto non è così semplice.
Consideriamo i pro e i contro del metrocluster
Quindi, ci siamo resi conto che gli ovvi vantaggi del metrocluster rispetto alla replica convenzionale sono:
- Automazione completa, garantendo tempi di ripristino minimi in caso di disastro;
- È tutto :-).
E ora, attenzione, i contro:
- Costo della soluzione. Sebbene il metrocluster nei sistemi Aerodisk non richieda licenze aggiuntive (viene utilizzata la stessa licenza della replica), il costo della soluzione sarà comunque ancora più elevato rispetto all'utilizzo della replica sincrona. Sarà necessario implementare tutti i requisiti per una replica sincrona, più i requisiti per il metrocluster associato allo switching aggiuntivo e al sito aggiuntivo (vedi pianificazione del metrocluster);
- Complessità della soluzione. Il metrocluster è molto più complesso di una replica normale e richiede molta più attenzione e impegno per la pianificazione, la configurazione e la documentazione.
Infine. Metrocluster è sicuramente una soluzione tecnologicamente molto avanzata e valida quando è realmente necessario fornire RTO in pochi secondi o minuti. Ma se non esiste un compito del genere e l'RTO in ore va bene per gli affari, allora non ha senso sparare ai passeri da un cannone. La consueta replica lavoratore-contadino è sufficiente, poiché un cluster metropolitano causerà costi aggiuntivi e complicazioni per l’infrastruttura IT.
Pianificazione del Metrocluster
Questa sezione non pretende di essere una guida completa alla progettazione del metrocluster, ma mostra solo le indicazioni principali che dovrebbero essere elaborate se si decide di costruire un sistema di questo tipo. Pertanto, quando si implementa effettivamente un metrocluster, assicurarsi di coinvolgere il produttore del sistema di storage (ovvero noi) e altri sistemi correlati per consultazioni.
terreno di gioco
Come affermato in precedenza, un metrocluster richiede un minimo di tre siti. Due data center dove opereranno i sistemi di storage e i sistemi correlati, nonché un terzo sito dove lavorerà l’arbitro.
La distanza consigliata tra i data center non è superiore a 40 chilometri. Una distanza maggiore è molto probabile che causi ulteriori ritardi, che nel caso di un metrocluster sono estremamente indesiderabili. Ricordiamo che i ritardi dovrebbero arrivare fino a 5 millisecondi, anche se è consigliabile mantenerli entro 2.
Si consiglia di verificare i ritardi anche durante il processo di pianificazione. Qualsiasi fornitore più o meno maturo che fornisce fibra ottica tra data center può organizzare un controllo di qualità abbastanza rapidamente.
Per quanto riguarda i ritardi davanti all'arbitro (ovvero tra il terzo sito e i primi due), la soglia di ritardo consigliata è fino a 200 millisecondi, ovvero è adatta una normale connessione VPN aziendale su Internet.
Commutazione e rete
A differenza dello schema di replica, in cui è sufficiente connettere sistemi di storage da siti diversi, lo schema metrocluster richiede la connessione di host con entrambi i sistemi di storage in siti diversi. Per rendere più chiaro quale sia la differenza, entrambi gli schemi sono mostrati di seguito.
Come si può vedere dal diagramma, gli host del nostro sito 1 esaminano sia il sistema di storage 1 che il sistema di storage 2. Inoltre, al contrario, gli host del sito 2 esaminano sia il sistema di storage 2 che il sistema di storage 1. Cioè, ciascun host vede entrambi i sistemi di storage. Questo è un prerequisito per il funzionamento del metrocluster.
Naturalmente non è necessario collegare ciascun host con un cavo ottico a un altro data center; non saranno sufficienti né porte né cavi. Tutte queste connessioni devono essere effettuate tramite switch Ethernet 10G+ o FibreChannel 8G+ (FC è solo per la connessione di host e sistemi di storage per IO, il canale di replica è attualmente disponibile solo tramite IP (Ethernet 10G+).
Ora qualche parola sulla topologia della rete. Un punto importante è la corretta configurazione delle sottoreti. È necessario definire subito più sottoreti per le seguenti tipologie di traffico:
- La sottorete di replica su cui verranno sincronizzati i dati tra i sistemi di archiviazione. Potrebbero essercene diversi, in questo caso non importa, tutto dipende dalla topologia di rete attuale (già implementata). Se sono due, ovviamente è necessario configurare il routing tra di loro;
- Sottoreti di archiviazione attraverso le quali gli host accederanno alle risorse di archiviazione (se è iSCSI). Dovrebbe esserci una di queste sottoreti in ciascun data center;
- Sottoreti di controllo, ovvero tre sottoreti instradabili su tre siti da cui vengono gestiti i sistemi di storage, dove si trova anche l'arbitro.
Non consideriamo qui le sottoreti per l'accesso alle risorse dell'host, poiché dipendono fortemente dalle attività.
Separare il traffico diverso in sottoreti diverse è estremamente importante (è particolarmente importante separare la replica dall'I/O), perché se si mescola tutto il traffico in una sottorete "spessa", questo traffico sarà impossibile da gestire e in a causa delle condizioni di due data center ciò può comunque causare diverse opzioni di collisione di rete. Non approfondiremo questo problema nell'ambito di questo articolo, poiché puoi leggere sulla pianificazione di una rete estesa tra data center sulle risorse dei produttori di apparecchiature di rete, dove questo è descritto in modo molto dettagliato.
Configurazione dell'arbitro
L'arbitro deve fornire l'accesso a tutte le interfacce di gestione del sistema di storage tramite i protocolli ICMP e SSH. Dovresti anche pensare alla sicurezza dell'arbitro. C'è una sfumatura qui.
Il failover dell'arbitro è altamente auspicabile, ma non obbligatorio. Cosa succede se l'arbitro cade nel momento sbagliato?
- Il funzionamento del metrocluster in modalità normale non cambierà, perché arbtir non ha assolutamente alcun effetto sul funzionamento del metrocluster in modalità normale (il suo compito è trasferire tempestivamente il carico tra i data center)
- Inoltre, se l'arbitro per un motivo o per l'altro cade e "dorme" in un incidente nel data center, non avverrà alcun cambio, perché non ci sarà nessuno a dare i comandi di cambio necessari e ad organizzare il quorum. In questo caso, il metrocluster si trasformerà in uno schema regolare con replica, che dovrà essere commutato manualmente durante un disastro, che influenzerà l'RTO.
Cosa ne consegue? Se è davvero necessario garantire un RTO minimo, è necessario assicurarsi che l'arbitro sia tollerante agli errori. Ci sono due opzioni per questo:
- Avvia una macchina virtuale con un arbitro su un hypervisor con tolleranza agli errori, fortunatamente tutti gli hypervisor per adulti supportano la tolleranza agli errori;
- Se nel terzo sito (in un ufficio convenzionale) sei troppo pigro per installare un cluster normale e non esiste un cluster Hypervozor, allora abbiamo fornito una versione hardware dell'Arbiter, che è realizzata in una scatola 2U in cui due normali I server x-86 funzionano e possono sopravvivere a un guasto locale.
Raccomandiamo vivamente di garantire la tolleranza agli errori dell'arbitro, nonostante il fatto che il metrocluster non ne abbia bisogno in modalità normale. Ma come mostrano sia la teoria che la pratica, se si costruisce un’infrastruttura veramente affidabile e a prova di disastro, allora è meglio andare sul sicuro. È meglio proteggere te stesso e la tua attività dalla “legge della meschinità”, cioè dal fallimento sia dell'arbitro che di uno dei siti in cui si trova il sistema di stoccaggio.
Architettura della soluzione
Considerando i requisiti di cui sopra, otteniamo la seguente architettura generale della soluzione.
I LUN devono essere distribuiti uniformemente su due siti per evitare un grave sovraccarico. Allo stesso tempo, nel dimensionamento di entrambi i data center, è necessario includere non solo il doppio volume (necessario per archiviare i dati contemporaneamente su due sistemi di storage), ma anche il doppio delle prestazioni in IOPS e MB/s per evitare il degrado delle applicazioni in in caso di guasto di uno dei data center ov.
Separatamente, notiamo che con il corretto approccio al dimensionamento (ovvero a condizione che abbiamo fornito i limiti superiori adeguati di IOPS e MB/s, nonché le risorse CPU e RAM necessarie), se uno dei sistemi di storage nel Il cluster metropolitano fallisce, non si verificherà un grave calo delle prestazioni in condizioni di lavoro temporaneo su un sistema di stoccaggio.
Ciò è spiegato dal fatto che quando due siti funzionano contemporaneamente, la replica sincrona “consuma” metà delle prestazioni di scrittura, poiché ogni transazione deve essere scritta su due sistemi di archiviazione (simile a RAID-1/10). Pertanto, se uno dei sistemi di storage si guasta, l'influenza della replica temporaneamente (fino al ripristino del sistema di storage guasto) scompare e otteniamo un duplice aumento delle prestazioni di scrittura. Dopo che i LUN del sistema di storage guasto vengono riavviati sul sistema di storage funzionante, questo duplice aumento scompare a causa del fatto che il carico viene visualizzato dai LUN dell'altro sistema di storage e si ritorna allo stesso livello di prestazioni che avevamo prima del "caduta", ma solo nell'ambito di un sito.
Con l'aiuto di un dimensionamento competente è possibile garantire condizioni in cui gli utenti non avvertiranno affatto il guasto di un intero sistema di storage. Ma lo ripetiamo ancora una volta, ciò richiede un dimensionamento molto accurato, per il quale, tra l'altro, puoi contattarci gratuitamente :-).
Creazione di un metrocluster
La configurazione di un metrocluster è molto simile alla configurazione della replica regolare, descritta in . Pertanto, concentriamoci solo sulle differenze. Abbiamo allestito un banco in laboratorio basato sull'architettura di cui sopra, solo in una versione minimale: due sistemi di storage collegati tramite Ethernet 10G, due switch 10G e un host che guarda attraverso gli switch entrambi i sistemi di storage con porte 10G. L'arbitro viene eseguito su una macchina virtuale.
Quando si configurano gli IP virtuali (VIP) per una replica, è necessario selezionare il tipo VIP - per metrocluster.
Abbiamo creato due collegamenti di replica per due LUN e li abbiamo distribuiti su due sistemi di storage: LUN TEST Primario sul sistema di storage 1 (collegamento METRO), LUN TEST2 Primario per il sistema di storage 2 (collegamento METRO2).
Per loro abbiamo configurato due target identici (nel nostro caso iSCSI, ma è supportato anche FC, la logica di configurazione è la stessa).
Sistema di archiviazione1:
Sistema di archiviazione2:
Per le connessioni di replica, sono state effettuate mappature su ciascun sistema di storage.
Sistema di archiviazione1:
Sistema di archiviazione2:
Abbiamo configurato multipath e lo abbiamo presentato all'host.
Costituzione di un arbitro
Non devi fare nulla di speciale con l’arbitro stesso; devi solo abilitarlo sul terzo sito, dargli un IP e configurarne l’accesso tramite ICMP e SSH. La configurazione stessa viene eseguita dai sistemi di archiviazione stessi. In questo caso è sufficiente configurare una volta l'arbitro su uno qualsiasi dei controller di storage del metrocluster; queste impostazioni verranno distribuite automaticamente a tutti i controller.
Nella sezione Replica remota >> Metrocluster (su qualsiasi controller) >> il pulsante “Configura”.
Inseriamo l'IP dell'arbitro, nonché le interfacce di controllo di due controller di archiviazione remoti.
Successivamente, è necessario abilitare tutti i servizi (il pulsante "Riavvia tutto"). Se riconfigurati in futuro, i servizi dovranno essere riavviati affinché le impostazioni abbiano effetto.
Controlliamo che tutti i servizi siano in esecuzione.
Questo completa la configurazione del metrocluster.
Crash test
Il crash test nel nostro caso sarà abbastanza semplice e veloce, poiché la funzionalità di replica (switching, consistenza, ecc.) è stata discussa in . Pertanto, per testare l'affidabilità del metrocluster, è sufficiente verificare l'automazione del rilevamento dei guasti, della commutazione e dell'assenza di perdite di registrazione (interruzioni I/O).
Per fare ciò, emuliamo un guasto completo di uno dei sistemi di storage spegnendo fisicamente entrambi i suoi controller, dopo aver iniziato a copiare un file di grandi dimensioni sulla LUN, che deve essere attivato sull'altro sistema di storage.
Disabilitare un sistema di archiviazione. Sul secondo sistema di storage vediamo avvisi e messaggi nei log che indicano che la connessione con il sistema vicino è stata persa. Se sono configurate le notifiche tramite monitoraggio SMTP o SNMP, l'amministratore riceverà le notifiche corrispondenti.
Esattamente 10 secondi dopo (visibile in entrambi gli screenshot), la connessione di replica METRO (quella che era Primaria sul sistema di storage guasto) è diventata automaticamente Primaria sul sistema di storage funzionante. Usando la mappatura esistente, LUN TEST è rimasto a disposizione dell'host, la registrazione è leggermente diminuita (entro il 10% promesso), ma non è stata interrotta.
Il test è stato completato con successo.
Riassumendo
L'attuale implementazione del metrocluster nei sistemi di storage della serie N AERODISK Engine consente di risolvere pienamente i problemi in cui è necessario eliminare o ridurre al minimo i tempi di inattività dei servizi IT e garantirne il funzionamento 24 ore su 7, 365 giorni su XNUMX, XNUMX giorni all'anno con costi di manodopera minimi.
Possiamo dire, ovviamente, che tutto questo è teoria, condizioni ideali di laboratorio e così via... MA abbiamo una serie di progetti implementati in cui abbiamo implementato funzionalità di resilienza ai disastri e i sistemi funzionano perfettamente. Uno dei nostri clienti abbastanza noti, che utilizza solo due sistemi di storage in una configurazione a prova di disastro, ha già accettato di pubblicare informazioni sul progetto, quindi nella parte successiva parleremo dell'implementazione del combattimento.
Grazie, speriamo in una discussione produttiva.
Fonte: habr.com