Ciao, lettori di Habr! L'argomento di questo articolo sarà l'implementazione di strumenti di resilienza nei sistemi di archiviazione AERODISK Engine. Inizialmente volevamo scrivere in un solo articolo su entrambi gli strumenti: la replica e il metrocluster, ma purtroppo l'articolo è diventato troppo lungo, quindi l'abbiamo diviso in due parti. Passeremo dal semplice al complesso. In questo articolo configureremo e testeremo la replica sincrona: abbatteremo un data center e interromperemo il canale di comunicazione 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, parleremo un po' di cosa sia la replica negli sistemi di archiviazione.
Un po' di teoria
La replica negli sistemi di archiviazione è un processo continuo per garantire l'identità dei dati contemporaneamente su più sistemi di archiviazione. Tecnicamente, la replica viene eseguita con due metodi.
Replica sincrona è il copia dei dati da un sistema di archiviazione principale a uno secondario con la successiva conferma obbligatoria da entrambi i sistemi di archiviazione che i dati siano stati registrati e confermati. Solo dopo la conferma da entrambe le parti (da entrambi i sistemi di archiviazione) i dati si considerano registrati e possono essere utilizzati. In questo modo si garantisce l'identità dei dati su tutti i sistemi di archiviazione coinvolti nella replica.
I vantaggi di questo metodo:
- I dati sono sempre identici su tutti i sistemi di archiviazione
Contro:
- Alto costo della soluzione (canali di comunicazione rapidi, costosa fibra ottica, trasmettitori 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 corrotti (intenzionalmente o accidentalmente) sul sistema di archiviazione principale, essi diventeranno automaticamente e immediatamente corrotti su quello secondario, poiché i dati sono sempre identici (un paradosso))
Replica asincrona è un'altra copia dei dati dal sistema di archiviazione principale a quello secondario, ma con un certo ritardo e senza la necessità di confermare la registrazione dall'altra parte. È possibile lavorare con i dati subito dopo la registrazione sul sistema di archiviazione principale, mentre i dati sul sistema di archiviazione secondario saranno disponibili dopo un certo periodo. L'identità dei dati in questo caso, chiaramente, non è garantita. I dati sul sistema di archiviazione secondario sono sempre un po' "nel passato".
Vantaggi della replica asincrona:
- Costo contenuto della soluzione (qualsiasi canale di comunicazione, fibra ottica opzionale)
- Nessuna limitazione di distanza
- Sulla SAN di riserva, i dati non vengono danneggiati in caso di danneggiamento sulla principale (per lo meno, per un certo periodo di tempo). Se i dati diventano danneggiati, è sempre possibile interrompere la replica per evitare il danneggiamento dei dati sulla SAN di riserva.
Contro:
- I dati nei diversi data center non sono mai identici.
Pertanto, la scelta della modalità di replica dipende dalle esigenze aziendali. Se è fondamentale avere esattamente gli stessi dati nel data center di riserva che in quello principale (ovvero, requisito aziendale RPO=0), è necessario spendere di più e accettare le limitazioni della replica sincrona. Se è tollerabile un ritardo nello stato dei dati o semplicemente non ci sono fondi, allora è decisamente meglio utilizzare il metodo asincrono.
Inoltre, vogliamo evidenziare un modo (più precisamente, una topologia) chiamato metrocluster. Nella modalità metrocluster si utilizza la replica sincrona, ma a differenza della replica normale, il metrocluster consente a entrambe le SAN di lavorare in modalità attiva. Cioè, non ci sono divisioni in data center attivi e di riserva. Le applicazioni funzionano simultaneamente con due SAN, fisicamente localizzate in diversi data center. 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 argomento molto vasto e complesso, quindi dedicheremo un articolo separato a questo, in continuità con il presente.
Inoltre, molto spesso, quando parliamo di replica tramite SAN, molte persone si pongono una domanda legittima: > «Molte applicazioni hanno i propri strumenti di replica, perché utilizzare la replica sulla SAN? È meglio o peggio?»
Non c'è una risposta univoca, quindi presenteremo argomenti a favore e contro:
Argomenti a favore della replica SAN:
- Semplicità della soluzione. Con un singolo strumento puoi replicare l'intero array di dati, indipendentemente dal tipo di carico e di applicazioni. Se si utilizza la replica delle applicazioni, sarà necessario configurare ogni applicazione separatamente. Se ce ne sono più di due, diventa estremamente laborioso e costoso (la replica delle applicazioni richiede, di norma, una licenza separata e a pagamento per ogni applicazione. Ma di questo parleremo più avanti).
- È possibile replicare qualsiasi cosa: qualsiasi applicazione, qualsiasi dato, e saranno sempre coerenti. Molte (la maggior parte) delle applicazioni non dispongono di strumenti di replicazione, e le repliche del sistema di archiviazione (SХД) sono l'unico mezzo per garantire la protezione dai disastri.
- Non è necessario pagare troppo per le funzionalità di replicazione delle applicazioni. Di norma, esse non sono economiche, così come le licenze per le repliche del SХД. Tuttavia, per la licenza di replicazione del SХД è necessario pagare una sola volta, mentre le licenze per le repliche delle applicazioni devono essere acquistate separatamente per ogni applicazione. Se ci sono molte di queste applicazioni, il costo può essere elevato e il prezzo delle licenze per la replicazione del SХД diventa una goccia nell'oceano.
Argomenti CONTRO la replicazione del SХД:
- La replica tramite gli strumenti delle applicazioni offre più funzionalità dal punto di vista delle stesse applicazioni; un'applicazione conosce meglio i propri dati (cosa evidente), quindi ci sono più opzioni per lavorarci.
- I produttori di alcune applicazioni non garantiscono la coerenza dei propri dati se la replicazione viene eseguita tramite strumenti esterni. *
* - tesi discutibile. Ad esempio, una nota azienda produttrice di database ha a lungo dichiarato ufficialmente che il loro database può essere replicato normalmente solo con i propri strumenti, mentre la replicazione esterna (compresa quella SХД) è "non vera". Ma la vita ha mostrato che non è così. È probabile (ma non certo) che sia solo un tentativo poco onesto di vendere ulteriori licenze ai clienti.
In definitiva, nella maggior parte dei casi la replicazione da parte del SХД è migliore, poiché rappresenta un'opzione più semplice e meno costosa, ma ci sono casi complessi in cui è necessaria una funzionalità specifica delle applicazioni, e bisogna lavorare esattamente con la replicazione a livello di applicazioni.
Abbiamo finito con la teoria, ora passiamo alla pratica
Imposteremo la replica nel nostro laboratorio. In condizioni di laboratorio, abbiamo emulato due data center (in realtà, due rack vicini che sembrano trovarsi in edifici diversi). Il banco di prova è composto da due SХД Engine N2 collegati tra loro da cavi in fibra ottica. A entrambi gli SХД è collegato un server fisico con sistema operativo Windows Server 2016 utilizzando 10Gb Ethernet. Il banco di prova è piuttosto semplice, ma ciò non cambia il nocciolo della questione.
Schematizzando, appare così:
Logicamente, la replicazione è organizzata nel seguente modo:
Ora analizziamo le funzionalità di replicazione che abbiamo attualmente.
Sono supportati due modalità: asincrona e sincrona. È logico che la modalità sincrona sia limitata dalla distanza e dal canale di comunicazione. In particolare, la modalità sincrona richiede l'utilizzo della fibra ottica come fisica e un Ethernet da 10 gigabit (o superiore).
La distanza supportata per la replica sincrona è di 40 chilometri, con valori di latenza del canale ottico tra i datacenter fino a 2 millisecondi. In generale, funzionerà anche con latenze maggiori, ma ci saranno forti rallentamenti durante la scrittura (il che è abbastanza logico), dunque se hai in mente di impostare una replica sincrona tra i datacenter, è necessario verificare la qualità della fibra ottica e le latenze.
Per la replica asincrona, i requisiti non sono così severi. Anzi, non ce ne sono affatto. Qualsiasi connessione Ethernet funzionante va bene.
Attualmente, nel sistema di archiviazione AERODISK ENGINE, è supportata la replica per dispositivi a blocchi (LUN) tramite protocollo Ethernet (su rame o fibra ottica). Per progetti che richiedono necessariamente la replica tramite una SAN di rete su Fibre Channel, stiamo attualmente scrivendo una soluzione corrispondente, ma non è ancora pronta, quindi nel nostro caso – solo Ethernet.
La replica può funzionare tra qualsiasi sistema di archiviazione della serie ENGINE (N1, N2, N4) dai modelli più piccoli a quelli più grandi e viceversa.
Le funzionalità di entrambe le modalità di replica sono completamente identiche. Di seguito, maggiori dettagli su ciò che è disponibile:
- Replica «one to one» o «uno a uno», ossia l'opzione classica con due datacenter, uno principale e uno di riserva
- Replica «one to many» o «uno a molti», cioè un LUN può essere replicato su più sistemi di archiviazione contemporaneamente
- Attivazione, disattivazione e «rovesciamento» della replica, rispettivamente per abilitare, disabilitare o modificare la direzione della replica
- La replica è disponibile sia per pool RDG (Raid Distributed Group) che per DDP (Dynamic Disk Pool). Tuttavia, il LUN del pool RDG può essere replicato solo in un altro RDG. Lo stesso vale per DDP.
Ci sono anche molte piccole peculiarità, ma non ha molto senso elencarle, le menzioneremo durante la configurazione.
Configurazione della replica
Il processo di configurazione è piuttosto semplice e consiste in tre fasi.
- Configurazione della rete
- Configurazione dello storage
- Configurazione delle regole (collegamenti) e del mapping
Un aspetto importante della configurazione della replica è che le prime due fasi devono essere ripetute sul sistema di archiviazione remoto, la terza fase – solo su quello 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 tal fine, bisogna attivare le porte e configurarle Indirizzi IP nella sezione degli adattatori Front-end.
Dopo di ciò, dobbiamo creare un pool (nel nostro caso RDG) e un indirizzo IP virtuale per la replica (VIP). Il VIP è un indirizzo IP fluttuante, legato a due indirizzi 'fisici' dei controllori SAN (porte che abbiamo appena configurato). Sarà l'interfaccia principale di replica. Si può anche operare senza VIP, ma utilizzando un VLAN, se si ha bisogno di lavorare con traffico taggato.
Il processo di creazione del VIP per la replica è poco diverso dalla creazione del VIP per l'input-output (NFS, SMB, iSCSI). In questo caso, creiamo un VIP normale (senza VLAN), ma è fondamentale indicare che è per la replica (senza quest'indicazione non potremo aggiungere il VIP alla regola nel passaggio successivo).
Il VIP deve assolutamente essere nella stessa sottorete degli IP delle porte tra le quali 'fluttua'.
Ripetiamo queste impostazioni sul SAN remoto, con un altro indirizzo IP, ovviamente.
I VIP di diversi SAN possono trovarsi in sottoreti diverse, l'importante è che ci sia instradamento tra di essi. Nel nostro caso, viene mostrato proprio questo esempio (192.168.3.XX e 192.168.2.XX)
Con questo, la preparazione della parte di rete è completata.
Configuriamo gli storage
La configurazione dello storage per la replica differisce dalla normale solo per il fatto che il mapping lo facciamo attraverso un menu speciale 'Mapping di replica'. Per il resto, è tutto come nella configurazione normale. Procediamo passo dopo passo.
Nel pool R02 creato in precedenza, è necessario creare un LUN. Creiamo e lo chiamiamo LUN1.
Dobbiamo anche creare un LUN identico su un SAN remoto con la stessa capacità. Creiamo. Per evitare confusione, lo chiameremo LUN1R
Se ci fosse bisogno di utilizzare un LUN già esistente, durante la configurazione della replica sarebbe necessario smontare temporaneamente quel LUN produttivo dall'host, mentre sul SAN remoto deve essere semplicemente creato un LUN vuoto con la stessa capacità.
La configurazione dello storage è completata, passiamo alla creazione della regola di replica.
Configurazione delle regole di replica o dei legami di replica
Dopo aver creato i LUN sui SAN, che attualmente sarà quello principale (Primary), impostiamo la regola di replica per il LUN1 sul SAN1 verso il LUN1R sul SAN2.
La configurazione avviene nel menu 'Replica remota'
Creiamo una regola. Per questo è necessario indicare il destinatario della replica. Qui impostiamo anche il nome della connessione e il tipo di replicazione (sincrona o asincrona).
Nel campo "sistemi remoti" aggiungiamo il nostro SAN2. Per aggiungere è necessario utilizzare gli IP di gestione del SAN (MGR) e il nome del LUN remoto, in cui eseguiremo la replicazione (nel nostro caso LUN1R). Gli IP di gestione sono necessari solo nella fase di aggiunta della connessione, il traffico di replicazione non passerà attraverso di essi, per questo 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 nella figura sottostante.
Nel nostro caso, c'è un solo sistema remoto, quindi ci limitiamo a questo.
La regola è pronta. Si noti che viene aggiunta automaticamente a tutti i membri della replicazione (nel nostro caso sono due). È possibile creare quante più regole si desidera, per qualsiasi numero di LUN e in entrambe le direzioni. Ad esempio, possiamo replicare parte dei LUN dal SAN1 al SAN2 per bilanciare il carico, e un'altra parte viceversa – dal SAN2 al SAN1.
SAN1. Subito dopo la creazione è iniziata la sincronizzazione.
SAN2. Vediamo la stessa regola, ma la sincronizzazione è già terminata.
LUN1 su SAN1 è nella funzione Primary, cioè è attivo. LUN1R su SAN2 è nella funzione Secondary, cioè è in standby, nel caso ci sia un guasto di SAN1.
Ora possiamo collegare il nostro LUN all'host.
Effettueremo il collegamento tramite iSCSI, anche se è possibile farlo anche tramite FC. La configurazione del mapping per il LUN iSCSI nella replica è praticamente identica a quella di uno scenario normale, quindi non la esamineremo dettagliatamente qui. Se necessario, questo processo è descritto nell'articolo "».
L'unica differenza è che creiamo il mapping nel menu "Mapping di replicazione".
Abbiamo configurato il mapping, abbiamo dato il LUN all'host. L'host ha riconosciuto il LUN.
Lo formattiamo nel file system locale.
Tutto, a questo punto la configurazione è completata. Ora procederemo ai test.
Test
Testeremo tre scenari principali.
- Failover normale dei ruoli Secondary > Primary. Il failover normale dei ruoli è necessario nel caso, ad esempio, in cui nel data center principale dobbiamo eseguire alcune operazioni di manutenzione e, in quel momento, per garantire che i dati siano accessibili, trasferiamo il carico nel data center di riserva.
- Commutazione di emergenza dei ruoli Secondario > Primario (guasto del centro dati). Questo è lo scenario principale per cui esiste la replica, che può aiutare a sopravvivere a un guasto totale del centro dati senza fermare il lavoro dell'azienda per un lungo periodo.
- Interruzione dei canali di comunicazione tra i centri dati. Verifica del corretto comportamento di due sistemi di archiviazione dati in condizioni in cui, per qualche motivo, il canale di comunicazione tra i centri dati non è disponibile (ad esempio, un escavatore ha scavato nel posto sbagliato e ha rotto la fibra oscura).
Per iniziare, cominciamo a scrivere i dati sul nostro LUN (scriviamo file con dati casuali). Controlliamo subito che il canale di comunicazione tra i sistemi di archiviazione dati sia in uso. Questo è facile da capire se apriamo il monitoraggio del carico delle porte responsabili della replica.
Ora entrambi i sistemi di archiviazione dati hanno dati "utili", possiamo iniziare il test.
Per precauzione, diamo un'occhiata ai valori di hash di uno dei file e annotiamoli.
Commutazione di ruoli standard
L'operazione di commutazione dei ruoli (cambiamento della direzione della replica) può essere eseguita da qualsiasi sistema di archiviazione dati, ma è necessario andare su entrambi, poiché su quello Primario sarà necessario disattivare il mapping, mentre su quello Secondario (che diventerà Primario) sarà necessario attivarlo.
Ora potrebbe sorgere una domanda legittima: perché non automatizzare questo processo? La risposta è semplice: la replica è un semplice mezzo di resilienza ai disastri, basato esclusivamente su operazioni manuali. Per automatizzare queste operazioni esiste la modalità metrocluster, che è completamente automatizzata, ma la sua configurazione è significativamente più complessa. Scriveremo sulla configurazione del metrocluster nel prossimo articolo.
Sul sistema di archiviazione dati Primario disattiviamo il mapping per garantire l'interruzione della scrittura.
Successivamente, su uno dei sistemi di archiviazione dati (non importa se il Primario o il Secondario) nel menu "Replica remota" selezioniamo la nostra connessione REPL1 e clicchiamo su "Cambia ruolo".
Dopo alcuni secondi, LUN1R (sistema di archiviazione dati Secondario) diventa Primario.
Creiamo il mapping di LUN1R con il sistema di archiviazione dati 2.
Dopo di che, il nostro disco E: si collega automaticamente all'host, solo che questa volta è "arrivato" da LUN1R.
Per precauzione, confrontiamo i valori di hash.
Identico. Test superato.
Commutazione di emergenza. Guasto del centro dati
Attualmente, il sistema di archiviazione dati Primario dopo la commutazione standard è il sistema di archiviazione dati 2 e LUN1R, rispettivamente. Per simulare un guasto, disattiveremo l'alimentazione su entrambi i controller del sistema di archiviazione dati 2.
Non c'è più accesso.
Controlliamo cosa sta succedendo su SCD 1 (attualmente in riserva).
Vediamo che il LUN Primario (LUN1R) non è disponibile. È apparso un messaggio di errore nei log, nel pannello informativo e anche nella stessa regola di replicazione. Di conseguenza, i dati dall'host non sono attualmente accessibili.
Cambiando il ruolo del LUN1 in Primario.
Effettuiamo il mapping all'host.
Ci assicuriamo che il disco E sia apparso sull'host.
Controlliamo l'hash.
Tutto in ordine. L'interruzione del data center, che era attivo, è stata gestita con successo dal SCD. Il tempo approssimativo impiegato per connettere il ‘cambio’ di replicazione e il collegamento del LUN dal data center di riserva è stato di circa 3 minuti. È chiaro che nella produzione reale tutto è molto più complesso e, oltre alle operazioni con il SCD, è necessario eseguire molte altre operazioni nella rete, sugli host, nelle applicazioni. E nella realtà questo intervallo di tempo sarà significativamente più lungo.
Qui vorremmo scrivere che tutto è andato bene e il test è stato completato con successo, ma non affrettiamoci. Il SCD principale è ‘giù’, sappiamo che quando è ‘caduto’, era nel ruolo di Primario. Cosa succederà se si accende improvvisamente? Ci saranno due ruoli Primari, il che equivale a una corruzione dei dati? Controlliamo ora.
Andiamo a riaccendere il SCD che era spento.
Si avvia per alcuni minuti e poi torna in funzione dopo una breve sincronizzazione, ma già nel ruolo di Secondario.
Tutto a posto. Non è successo lo split-brain. Ci abbiamo pensato e, dopo un'interruzione, il SCD si riavvia sempre nel ruolo di Secondario, indipendentemente dal ruolo che aveva ‘in vita’. Ora possiamo affermare con certezza che il test di failover del data center è riuscito.
Interruzione dei canali di comunicazione tra i data center.
L'obiettivo principale di questo test è assicurarsi che il SCD non inizi a comportarsi in modo strano se perde temporaneamente i canali di comunicazione tra i due SCD, e poi li riottiene.
Quindi. Scolleghiamo i cavi tra gli SCD (imagine che siano stati rimossi da un escavatore).
Sul Primario vediamo che non c'è connessione con il Secondario.
Sul Secondario vediamo che non c'è connessione con il Primario.
Funziona tutto normalmente e continuiamo a scrivere dati sul SCD principale, cioè, questi sono già garantiti come diversi rispetto a quelli di riserva, quindi sono ‘separati’.
Dopo alcuni minuti ‘ripariamo’ il canale di comunicazione. Non appena gli SCD si vedono tra loro, la sincronizzazione dei dati si attiva automaticamente. Qui non è richiesta alcuna azione da parte dell'amministratore.
Dopo un po', la sincronizzazione si completa.
La connessione è stata ripristinata, nessuna situazione anomala ha causato interruzioni nei canali di comunicazione e dopo l'accensione la sincronizzazione è avvenuta automaticamente.
Conclusioni
Abbiamo esaminato 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 eseguiti i test principali per il passaggio normale, il guasto del data center e l'interruzione dei canali di comunicazione. In tutti i casi, il sistema di archiviazione ha funzionato bene. Non ci sono state perdite di dati, 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 principali e il comportamento in caso di guasti è completamente automatizzato.
Vi preghiamo di scrivere i vostri commenti, saremo felici di critiche costruttive e consigli utili.
Alla prossima.
Fonte: habr.com
