Ciao lettori di Habr! Il tema di questo articolo sarà l'implementazione di strumenti di tolleranza ai guasti nei sistemi di storage AERODISK Engine. Inizialmente volevamo scrivere un articolo unico su entrambi gli strumenti: la replica e il metrocluster, ma purtroppo l'articolo è diventato troppo ampio, quindi abbiamo deciso di suddividerlo in due parti. Procediamo dal semplice al complesso. In questo articolo configureremo e testeremo la replica sincrona – simuleremo un guasto in un data center e interromperemo il collegamento tra i data center per vedere cosa succede.
I nostri clienti ci pongono spesso diverse domande sulla replica, quindi, prima di passare alla configurazione e al test dell'implementazione delle repliche, ci faremo una breve introduzione su cosa sia la replica nei sistemi di storage.
Un po' di teoria
La replica nei sistemi di storage è un processo continuo che garantisce l'identità dei dati simultaneamente su più sistemi di storage. Tecnicamente, la replica viene eseguita in due modi.
Replica sincrona – è la copia dei dati da uno storage primario a uno secondario con successiva conferma obbligatoria da entrambe le unità di storage che i dati sono stati scritti e confermati. Solo dopo la conferma da entrambe le parti (da entrambe le unità di storage) i dati sono considerati scritti e possono essere utilizzati. In questo modo si garantisce l'identità dei dati su tutte le unità di storage coinvolte nella replica.
Vantaggi di questo metodo:
- I dati sono sempre identici su tutte le unità di storage
Contro:
- Alto costo della soluzione (canali di comunicazione rapidi, fibra ottica costosa, transceiver a lungo raggio, ecc.)
- Limitazioni di distanza (nell'ordine di alcune decine di chilometri)
- Nessuna protezione contro la corruzione logica dei dati (se i dati vengono danneggiati (intenzionalmente o accidentalmente) sulla unità di storage primaria, diventeranno automaticamente e istantaneamente danneggiati anche sulla secondaria, poiché i dati sono sempre identici (questo è un paradosso))
Replica asincrona – è anch'essa una copia dei dati dal sistema di archiviazione principale a quello secondario, ma con un certo ritardo e senza necessità di conferma della registrazione dall'altro lato. È possibile lavorare sui dati immediatamente dopo la registrazione nel sistema principale, mentre sui dati secondari saranno disponibili dopo un certo periodo. In questo caso, la corrispondenza dei dati non è affatto garantita. I dati nel sistema secondario sono sempre un po' "nel passato".
Vantaggi della replica asincrona:
- Costo contenuto della soluzione (qualsiasi canale di comunicazione, la fibra ottica è opzionale)
- Nessuna limitazione di distanza
- I dati nel sistema secondario non vengono danneggiati in caso di corruzione nel sistema principale (almeno per un certo periodo); se i dati diventano corrotti, è sempre possibile interrompere la replica per evitare la corruzione dei dati nel sistema secondario
Contro:
- I dati in diversi data center non sono mai identici
La scelta della modalità di replica dipende, quindi, dagli obiettivi aziendali. Se è fondamentale avere esattamente gli stessi dati nel centro di elaborazione dati di backup (cioè, l'esigenza aziendale di RPO=0), è necessario fare un investimento e accettare le limitazioni della replica sincronizzata. Se, invece, è tollerabile una certa latenza nei dati o se semplicemente non ci sono fondi sufficienti, è decisamente meglio optare per il metodo asincrono.
Mettiamo in evidenza separatamente una modalità (piuttosto, una topologia) chiamata metrocluster. Nella modalità metrocluster si utilizza la replica sincronizzata, ma, a differenza della replica tradizionale, il metrocluster consente a entrambe le SAN di operare in modalità attiva. In altre parole, non ci sono distinzioni tra i centri di dati attivi e di riserva. Le applicazioni operano simultaneamente con due SAN fisicamente situate in diversi centri di dati. I tempi di inattività in caso di guasti in tale topologia sono molto brevi (RTO, di solito, minuti). In questo articolo non tratteremo la nostra implementazione del metrocluster, poiché è un tema molto ampio e articolato, quindi dedicheremo un articolo separato a questo argomento, in continuazione a questo.
Molto spesso, quando parliamo di replica tramite storage, molte persone si chiedono: > «Molte applicazioni hanno i propri strumenti di replica, perché dovremmo usare la replica tramite storage? È meglio o peggio?»
Non c'è una risposta semplice, quindi presenteremo gli argomenti A FAVORE e CONTRO:
Argomenti A FAVORE della replica tramite storage:
- Semplicità della soluzione. Con un unico strumento puoi replicare l'intero array di dati, indipendentemente dal tipo di carico e di applicazioni. Utilizzando la replica delle applicazioni, dovrai configurare ogni applicazione singolarmente. Se ce ne sono più di due, è estremamente laborioso e costoso (la replica delle applicazioni richiede, di norma, una licenza separata e a pagamento per ciascuna applicazione. Ma di questo parleremo più avanti).
- Puoi replicare qualsiasi cosa – qualsiasi applicazione, qualsiasi dato – e saranno sempre coerenti. Molti (la maggior parte) delle applicazioni non dispongono di strumenti di replica, e le repliche tramite storage sono l'unico mezzo per garantire la protezione da disastri.
- Non è necessario pagare in eccesso per le funzionalità di replica delle applicazioni. Di solito, ha un costo significativo, così come le licenze per la replica dello storage. Tuttavia, la licenza per la replica dello storage deve essere acquistata una sola volta, mentre la licenza per la replica delle applicazioni deve essere acquistata separatamente per ogni applicazione. Se ci sono molte applicazioni, ciò comporta costi elevati, e il costo delle licenze per la replica dello storage diventa una goccia nell'oceano.
Argomenti CONTRO la replica dello storage:
- La replica tramite applicazioni offre maggiore funzionalità dal punto di vista delle stesse applicazioni; l'applicazione conosce meglio i propri dati (cosa evidente), quindi ci sono più opzioni per lavorare con essi.
- I produttori di alcune applicazioni non garantiscono la coerenza dei propri dati se si utilizza la replica con strumenti di terze parti.*
* - affermazione controversa. Ad esempio, una nota azienda produttrice di DBMS dichiarava per molto tempo che il loro DBMS poteva essere replicato correttamente solo con i loro strumenti, e che qualsiasi altra forma di replica (inclusa quella dello storage) non è 'vera'. Ma la realtà ha dimostrato il contrario. Probabilmente (ma non è certo) si tratta semplicemente di un tentativo non del tutto onesto di vendere ulteriori licenze ai clienti.
In molti casi, la replica da parte dello storage è la soluzione migliore, poiché è più semplice e meno costosa. Tuttavia, ci sono situazioni complesse in cui è richiesta una funzionalità specifica delle applicazioni, e in questi casi è necessario lavorare con la replica a livello di applicazione.
Abbiamo finito con la teoria, ora passiamo alla pratica.
Configureremo la replica nel nostro laboratorio. In condizioni di laboratorio abbiamo emulato due data center (in realtà, due rack posti uno accanto all'altro come se fossero in edifici diversi). L'setup consiste in due unità di storage Engine N2, collegate tra loro tramite cavi in fibra ottica. A entrambe le unità di storage è collegato un server fisico con Windows Server 2016, utilizzando Ethernet a 10Gb. L'installazione è piuttosto semplice, ma questo non cambia il suo scopo.
Schematizzando, appare così:
Logicamente, la replica è organizzata nel seguente modo:
Ora analizziamo le funzionalità di replica che abbiamo a disposizione.
Sono supportati due modalità: asincrona e sincrona. È logico che la modalità sincrona sia limitata dalla distanza e dal canale di comunicazione. In particolare, per la modalità sincrona è necessario utilizzare fibra ottica come supporto fisico e Ethernet a 10 gigabit (o superiore).
La distanza supportata per la replica sincrona è di 40 chilometri, con valori di latenza del canale ottico tra i data center fino a 2 millisecondi. In generale, funzionerà anche con latenze più elevate, ma ci saranno forti ritardi durante la scrittura (il che è comprensibile); quindi, se stai contemplando la replica sincrona tra i data center, è necessario verificare la qualità dell'ottica e le latenze.
Per la replica asincrona i requisiti non sono così severi. In effetti, non ci sono requisiti specifici. Qualsiasi connessione Ethernet funzionante andrà bene.
Attualmente, nel sistema di archiviazione AERODISK ENGINE è supportata la replica per dispositivi a blocchi (LUN) tramite protocollo Ethernet (sia su rame che su fibra ottica). Per i progetti in cui è assolutamente necessaria la replica attraverso un fabric SAN su Fibre Channel, stiamo attualmente sviluppando una soluzione corrispondente, ma finché non sarà pronta, nel nostro caso è disponibile solo Ethernet.
La replica può funzionare tra qualsiasi sistema di archiviazione della serie ENGINE (N1, N2, N4), sia dai sistemi più piccoli a quelli più grandi e viceversa.
Le funzionalità di entrambi i modi di replica sono completamente identiche. Di seguito sono riportati ulteriori dettagli su ciò che è disponibile:
- Replica 'one to one' o 'uno a uno', ovvero la variante classica con due data center, principale e di riserva.
- La replica «one to many» o «uno a molti», ovvero un LUN può essere replicato su più sistemi di storage contemporaneamente.
- Attivazione, disattivazione e «rivoluzionamento» della replica, rispettivamente, per abilitare, disabilitare o cambiare la direzione della replica.
- La replica è disponibile sia per i gruppi RDG (Raid Distributed Group) che per i DDP (Dynamic Disk Pool). Tuttavia, un LUN del gruppo RDG può essere replicato solo in un altro RDG. Con DDP funziona in modo simile.
Ci sono anche molte altre piccole peculiarità, ma non ha molto senso elencarle, le menzioneremo durante la configurazione.
Configurazione della replica
Il processo di configurazione è piuttosto semplice e consiste di tre fasi.
- Configurazione della rete
- Configurazione dello storage
- Configurazione delle regole (collegamenti) e del mappatura
Un aspetto importante della configurazione della replica è che le prime due fasi devono essere ripetute su un sistema di storage remoto, mentre la terza fase deve essere eseguita solo sul principale.
Configurazione delle risorse di rete
Per prima cosa, è necessario configurare le porte di rete attraverso le quali verrà trasmesso il traffico di replica. A tale scopo, è necessario attivare le porte e impostarle Indirizzi IP nella sezione degli adattatori Front-end.
Dopo di ciò, dobbiamo creare un pool (nel nostro caso RDG) e un IP virtuale per la replica (VIP). Il VIP è un indirizzo IP fluttuante, assegnato a due indirizzi "fisici" dei controller di storage (porte che abbiamo appena configurato). Sarà l'interfaccia principale per la replica. Possiamo anche usare un VLAN se dobbiamo gestire il traffico taggato.
Il processo di creazione di un VIP per la replica è simile a quello per la creazione di un VIP per l'input/output (NFS, SMB, iSCSI). In questo caso, creiamo un VIP normale (senza VLAN), specificando obbligatoriamente che è per la replica (senza questa indicazione non potremo aggiungere il VIP alla regola nel passaggio successivo).
Il VIP deve appartenere alla stessa sottorete degli IP delle porte tra cui "fluttua".
Ripetiamo queste impostazioni sullo storage remoto, ovviamente con un IP diverso.
I VIP di diversi storage possono trovarsi in sottoreti diverse, ma è fondamentale che ci sia instradamento tra di essi. Nel nostro caso viene mostrato proprio questo esempio (192.168.3.XX e 192.168.2.XX).
A questo punto, la preparazione della parte di rete è completata.
Configuriamo gli storage
La configurazione dello storage per la replica si differenzia da quella normale solo per il fatto che la mappatura viene effettuata attraverso il menu speciale "Mappatura della replica". Per il resto, è tutto come per la configurazione normale. Procediamo per ordine.
Nel pool R02 già creato, è necessario creare un LUN. Lo creiamo e lo chiamiamo LUN1.
Dobbiamo anche creare un LUN identico su un sistema di storage remoto con la stessa capacità. Creiamo. Per evitare confusione, chiameremo il LUN remoto LUN1R.
Se avessimo bisogno di prendere un LUN già esistente, durante la configurazione della replica questo LUN produttivo dovrebbe essere smontato dall'host, mentre sul sistema di storage remoto è sufficiente creare un LUN vuoto di capacità identica.
La configurazione dello storage è completata, passiamo alla creazione della regola di replica.
Configurazione delle regole di replica o dei collegamenti di replica.
Dopo aver creato i LUN sul sistema di storage che sarà attualmente principale (Primary), configuriamo la regola di replica di LUN1 su SХD1 in LUN1R su SХD2.
La configurazione avviene nel menu "Replica remota".
Creiamo la regola. A questo scopo, è necessario specificare il destinatario della replica. Qui impostiamo anche il nome del collegamento e il tipo di replica (sincrona o asincrona).
Nel campo "sistemi remoti" aggiungiamo il nostro storage SAN2. Per aggiungere è necessario utilizzare l'IP di gestione SAN (MGR) e il nome del LUN remoto in cui eseguiremo la replica (nel nostro caso LUN1R). Gli IP di gestione sono necessari solo durante la fase di aggiunta del collegamento; il traffico di replica non passerà attraverso di essi, ma verrà utilizzato il VIP configurato in precedenza.
Già a questo punto possiamo aggiungere più di un sistema remoto per la topologia "one to many": premiamo il pulsante "aggiungi nodo", come mostrato nell'immagine qui sotto.
Nel nostro caso c'è solo un sistema remoto, quindi ci limitiamo a questo.
La regola è pronta. Nota che viene aggiunta automaticamente a tutti i partecipanti alla replica (nel nostro caso sono due). È possibile creare quante più regole si desidera, per qualsiasi numero di LUN e in qualsiasi direzione. Ad esempio, possiamo per bilanciare il carico replicare alcuni LUN da SAN1 a SAN2, mentre altri in senso inverso – da SAN2 a SAN1.
SAN1. Subito dopo la creazione è iniziata la sincronizzazione.
SAN2. Vediamo la stessa regola, ma la sincronizzazione è già terminata.
LUN1 su SCD1 è in ruolo Primario, quindi è attivo. LUN1R su SCD2 è in ruolo Secondario, quindi è in standby nel caso in cui SCD1 fallisca.
Ora possiamo collegare il nostro LUN all'host.
Effettueremo il collegamento tramite iSCSI, anche se è possibile farlo tramite FC. La configurazione del mapping del LUN iSCSI nella replica non è praticamente diversa dallo scenario normale, quindi non la tratteremo in dettaglio qui. Se necessario, questo processo è descritto nell'articolo «».
L'unica differenza è che creiamo il mapping nel menu «Mapping Replica»
Abbiamo configurato il mapping e dato il LUN all'host. L'host ha visto il LUN.
Lo formattiamo nel file system locale.
Tutto, la configurazione è completa. Ora inizieranno i test.
Test
Testeremo tre scenari principali.
- Commuta normalmente i ruoli da Secondario a Primario. La commutazione normale dei ruoli è necessaria nel caso in cui, ad esempio, nel data center principale dobbiamo eseguire operazioni di manutenzione e per questo periodo, affinché i dati siano disponibili, trasferiamo il carico nel data center di backup.
- Commutazione di emergenza dei ruoli da Secondario a Primario (guasto del data center). Questo è lo scenario principale per cui esiste la replicazione, che può contribuire a sopravvivere a un guasto totale del data center senza interrompere l'attività aziendale per un lungo periodo.
- Interruzione dei canali di comunicazione tra i data center. Verifica del corretto funzionamento di due sistemi di archiviazione dati in condizioni in cui, per qualsiasi motivo, il canale di comunicazione tra i data center non è disponibile (ad esempio, un escavatore ha scavato nel posto sbagliato e ha danneggiato la fibra ottica).
Per cominciare, iniziamo a scrivere dati sul nostro LUN (scriviamo file con dati casuali). Subito controlliamo cosa viene utilizzato nel canale di comunicazione tra i sistemi di archiviazione. È facile capire se apriamo il monitoraggio del carico delle porte responsabili della replicazione.
Ora entrambe le unità di archiviazione contengono dati 'utili', possiamo iniziare il test.
Per sicurezza, diamo un'occhiata ai checksum di uno dei file e annotiamolo.
Commute di ruoli regolare
L'operazione di commutazione dei ruoli (cambiamento della direzione della replicazione) può essere effettuata con qualsiasi unità di archiviazione, ma sarà comunque necessario operare su entrambe, poiché su quella Primaria sarà necessario disattivare il mapping, e sulla Secondaria (che diventerà Primaria) attivarlo.
È lecito chiedersi perché non automatizzare questo processo. La risposta è semplice: la replicazione è un metodo di resilienza alle catastrofi basato esclusivamente su operazioni manuali. Per automatizzare queste operazioni esiste la modalità metrocluster, che è completamente automatizzata, ma la sua configurazione è notevolmente più complessa. Scriveremo della configurazione del metrocluster nel prossimo articolo.
Sulla principale array di archiviazione disabilitiamo il mapping per garantire l'interruzione della scrittura.
Poi su uno dei sistemi di archiviazione (non importa se principale o secondario) nel menu "Replicazione remota" selezioniamo la nostra connessione REPL1 e clicchiamo su "Cambia ruolo".
Dopo qualche secondo, LUN1R (sistema di archiviazione secondario) diventa Primary.
Effettuiamo il mapping di LUN1R con il sistema di archiviazione 2.
Dopo di che, l'host collega automaticamente il nostro disco E:, solo che questa volta è "arrivato" da LUN1R.
Per sicurezza, confrontiamo le somme hash.
Identico. Test superato.
Failover. Guasto del Data Center.
Attualmente, il sistema di archiviazione principale dopo il normale failover è il sistema 2 e LUN1R, rispettivamente. Per simulare un guasto, disattiveremo l'alimentazione su entrambi i controllori di sistema 2.
Non c'è più accesso a essa.
Controlliamo cosa succede sullo storage 1 (attualmente in riserva).
Vediamo che il Primary LUN (LUN1R) non è disponibile. È comparso un messaggio di errore nei log, nel pannello informativo, e anche nella regola di replica stessa. Di conseguenza, i dati dall'host non sono attualmente accessibili.
Cambiamo il ruolo di LUN1 in Primary.
Facciamo il mapping all'host.
Ci assicuriamo che il disco E sia apparso sull'host.
Controlliamo l'hash.
Tutto in ordine. Il fallimento del data center attivo è stato gestito con successo dallo storage. Il tempo approssimativo che abbiamo impiegato per avviare la replica e collegare il LUN dal data center di riserva è stato di circa 3 minuti. È chiaro che nel mondo reale tutto è molto più complicato e, oltre alle operazioni con lo storage, è necessario eseguire molte altre operazioni in rete, sugli host e nelle applicazioni. Nella pratica, questo intervallo di tempo sarà significativamente più lungo.
Vorremmo scrivere che è tutto, il test è stato completato con successo, ma non affrettiamoci. Lo storage principale è 'giù', sappiamo che quando 'è caduto', era nel ruolo di Primary. Cosa succederà se si accende improvvisamente? Ci saranno due ruoli Primary, il che equivale a corruzione dei dati? Ora verifichiamo.
Andiamo ad accendere improvvisamente lo storage giù.
Ci vogliono alcuni minuti per ricaricarsi e dopo un breve processo di sincronizzazione torna in funzione, ma come secondaria.
Tutto ok. Non c'è stato alcun split brain. Ci abbiamo pensato, e dopo un guasto della SAN, si riavvia come secondaria, indipendentemente dal ruolo che aveva 'in vita'. Ora possiamo dire con certezza che il test di failover del data center è andato a buon fine.
Guasto dei canali di comunicazione tra i data center
L'obiettivo principale di questo test è assicurarsi che la SAN non inizi a comportarsi in modo strano se perde temporaneamente i canali di comunicazione tra due SAN, e poi li ripristina.
Dunque. Scollegiamo i cavi tra le SAN (immaginiamo che un escavatore li abbia colpiti).
Sul primary vediamo che non c'è connessione con il secondario.
Sul secondario vediamo che non c'è connessione con il primary.
Tutto funziona correttamente, e continuiamo a scrivere dati sulla SAN principale, quindi ora sono già garantita diverse dalla riserva, cioè 'si sono separate'.
Dopo alcuni minuti ripristiniamo il canale di comunicazione. Non appena le SAN si riconoscono, la sincronizzazione dei dati si attiva automaticamente. Qui non è richiesto nulla dall'amministratore.
Dopo un po', la sincronizzazione si completa.
La connessione è stata ripristinata, non ci sono state situazioni anomale e l'interruzione dei canali di comunicazione non ha causato problemi; dopo l'accensione, la sincronizzazione è avvenuta automaticamente.
Conclusioni
Abbiamo analizzato la teoria – cosa e perché è necessario, dove sono i vantaggi e dove gli svantaggi. Poi abbiamo configurato la replica sincrona tra due sistemi di archiviazione.
Successivamente, sono stati effettuati i test principali per il passaggio regolare, il guasto del data center e l'interruzione dei canali di comunicazione. In tutti i casi, il sistema di archiviazione ha funzionato correttamente. Non ci sono stati perdite di dati e le operazioni amministrative sono state ridotte al minimo per lo scenario manuale.
La prossima volta complicheremo la situazione e mostreremo come tutta questa logica funziona in un metrocluster automatizzato in modalità active-active, cioè quando entrambi i sistemi di archiviazione sono primari e il comportamento in caso di guasti è completamente automatizzato.
Vi preghiamo di scrivere commenti, saremo felici di critiche costruttive e consigli utili.
Arrivederci.
Fonte: habr.com
