Ciao, lettori di Habr! L'argomento di questo articolo sarà l'implementazione degli strumenti di disaster recovery nei sistemi di storage AERODISK Engine. Inizialmente volevamo scrivere in un articolo su entrambi gli strumenti: replica e metrocluster, ma sfortunatamente l'articolo si è rivelato troppo lungo, quindi abbiamo diviso l'articolo in due parti. Passiamo dal semplice al complesso. In questo articolo configureremo e testeremo la replica sincrona: lasceremo cadere un data center e interromperemo anche il canale di comunicazione tra i data center e vedremo cosa succede.
I nostri clienti spesso ci pongono varie domande sulla replica, quindi prima di passare alla configurazione e al test dell'implementazione delle repliche, vi diremo qualcosa su cos'è la replica nello storage.
Un po 'di teoria
La replica nei sistemi di storage è un processo continuo volto a garantire l'identità dei dati su più sistemi di storage contemporaneamente. Tecnicamente, la replica viene eseguita in due modi.
Replica sincrona – si tratta della copia dei dati dal sistema di archiviazione principale a quello di backup, seguita dalla conferma obbligatoria da parte di entrambi i sistemi di archiviazione che i dati sono stati registrati e confermati. È solo dopo la conferma da entrambe le parti (entrambi i sistemi di archiviazione) che i dati vengono considerati registrati e possono essere elaborati. Ciò garantisce l'identità dei dati garantita su tutti i sistemi di storage che partecipano alla replica.
I vantaggi di questo metodo:
- I dati sono sempre identici su tutti i sistemi di storage
contro:
- Costo elevato della soluzione (canali di comunicazione veloci, fibra ottica costosa, ricetrasmettitori a onda lunga, ecc.)
- Restrizioni sulla distanza (entro diverse decine di chilometri)
- Non esiste alcuna protezione contro la corruzione logica dei dati (se i dati vengono danneggiati (intenzionalmente o accidentalmente) sul sistema di archiviazione principale, verranno automaticamente e immediatamente danneggiati su quello di backup, poiché i dati sono sempre identici (questo è il paradosso)
Replica asincrona – anche questo sta copiando i dati dal sistema di archiviazione principale a quello di backup, ma con un certo ritardo e senza la necessità di confermare la scrittura sull'altro lato. È possibile lavorare con i dati immediatamente dopo averli registrati nel sistema di archiviazione principale e nel sistema di archiviazione di backup i dati saranno disponibili dopo un po' di tempo. L'identità dei dati in questo caso, ovviamente, non è affatto garantita. I dati sul sistema di archiviazione di backup sono sempre un po’ “nel passato”.
Vantaggi della replica asincrona:
- Soluzione a basso costo (qualsiasi canale di comunicazione, ottica opzionale)
- Nessuna limitazione di distanza
- Sul sistema di storage di backup i dati non si deteriorano se vengono danneggiati su quello principale (almeno per un certo periodo); se i dati si danneggiano è sempre possibile fermare la replica per evitare il danneggiamento dei dati sul sistema di storage di backup
contro:
- I dati nei diversi data center non sono sempre identici
Pertanto, la scelta della modalità di replica dipende dagli obiettivi aziendali. Se per te è fondamentale che il data center di backup contenga esattamente gli stessi dati del data center principale (ovvero, requisito aziendale per RPO = 0), allora dovrai sborsare denaro e sopportare le limitazioni di un data center sincrono replica. E se il ritardo nello stato dei dati è accettabile o semplicemente non ci sono soldi, allora devi assolutamente utilizzare il metodo asincrono.
Evidenziamo anche separatamente una modalità (più precisamente, una topologia) come un metrocluster. Nella modalità metrocluster viene utilizzata la replica sincrona ma, a differenza di una replica regolare, un metrocluster consente a entrambi i sistemi di storage di funzionare in modalità attiva. Quelli. non esiste una separazione tra data center attivi e in standby. Le applicazioni funzionano contemporaneamente con due sistemi di storage, fisicamente posizionati in data center diversi. I tempi di inattività durante gli incidenti in tale topologia sono molto ridotti (RTO, solitamente minuti). In questo articolo non considereremo la nostra implementazione del metrocluster, poiché si tratta di un argomento molto ampio e capiente, quindi gli dedicheremo un prossimo articolo separato, in continuazione di questo.
Inoltre, molto spesso, quando si parla di replica tramite sistemi di storage, molte persone si pongono una domanda ragionevole: > “Molte applicazioni dispongono di propri strumenti di replica, perché utilizzare la replica sui sistemi di storage? E' migliore o peggiore?
Non esiste una risposta chiara qui, quindi ecco gli argomenti A FAVORE e CONTRO:
Argomenti PER la replica dello storage:
- Semplicità della soluzione. Con un unico strumento puoi replicare l'intero set di dati, indipendentemente dal tipo di carico e dall'applicazione. Se utilizzi una replica dalle applicazioni, dovrai configurare ciascuna applicazione separatamente. Se ce ne sono più di 2, ciò è estremamente dispendioso in termini di manodopera e costoso (la replica dell'applicazione di solito richiede una licenza separata e non gratuita per ciascuna applicazione. Ma ne parleremo più avanti).
- Puoi replicare qualsiasi cosa, qualsiasi applicazione, qualsiasi dato, e sarà sempre coerente. Molte (la maggior parte) delle applicazioni non dispongono di funzionalità di replica e le repliche dal sistema di storage rappresentano l'unico modo per fornire protezione dai disastri.
- Non è necessario pagare più del dovuto per la funzionalità di replica dell'applicazione. Di norma non è economico, proprio come le licenze per una replica del sistema di archiviazione. Ma è necessario pagare una licenza per la replica dell'archiviazione una volta e una licenza per la replica dell'applicazione deve essere acquistata separatamente per ciascuna applicazione. Se esistono molte di queste applicazioni, costa un bel soldo 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 ha più funzionalità dal punto di vista delle applicazioni stesse, l'applicazione conosce meglio i suoi dati (ovviamente), quindi ci sono più opzioni per lavorare con essi.
- I produttori di alcune applicazioni non garantiscono la coerenza dei propri dati se la replica viene eseguita utilizzando strumenti di terze parti. *
* - tesi controversa. Ad esempio, un noto produttore di DBMS dichiara ufficialmente da molto tempo che il suo DBMS può essere replicato normalmente solo con i suoi mezzi e che il resto della replica (compresi i sistemi di archiviazione) “non è vera”. Ma la vita ha dimostrato che non è così. Molto probabilmente (ma questo non è certo) questo semplicemente non è il tentativo più onesto di vendere più licenze ai clienti.
Di conseguenza, nella maggior parte dei casi, la replica dal sistema di archiviazione è migliore, perché Si tratta di un'opzione più semplice e meno costosa, ma esistono casi complessi in cui sono necessarie funzionalità specifiche dell'applicazione ed è necessario lavorare con la replica a livello di applicazione.
Basta con la teoria, ora la pratica
Configureremo la replica nel nostro laboratorio. In condizioni di laboratorio, abbiamo emulato due data center (in effetti, due rack adiacenti che sembravano trovarsi in edifici diversi). Lo stand è composto da due sistemi di storage Engine N2, collegati tra loro tramite cavi ottici. Un server fisico che esegue Windows Server 2016 è connesso a entrambi i sistemi di storage tramite Ethernet da 10 Gb. Lo stand è abbastanza semplice, ma questo non cambia l'essenza.
Schematicamente appare così:
Logicamente, la replica è organizzata come segue:
Ora diamo un'occhiata alla funzionalità di replica di cui disponiamo ora.
Sono supportate 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 fisica e di 10 Gigabit Ethernet (o superiore).
La distanza supportata per la replica sincrona è di 40 chilometri, il valore di ritardo del canale ottico tra i data center arriva fino a 2 millisecondi. In generale funzionerà con grandi ritardi, ma poi ci saranno forti rallentamenti durante la registrazione (il che è anche logico), quindi se stai pianificando una replica sincrona tra data center, dovresti controllare la qualità dell'ottica e i ritardi.
I requisiti per la replica asincrona non sono così seri. Più precisamente, non ci sono affatto. Qualsiasi connessione Ethernet funzionante andrà bene.
Attualmente, il sistema di storage AERODISK ENGINE supporta la replica per dispositivi a blocchi (LUN) tramite il protocollo Ethernet (su rame o ottico). Per i progetti in cui è richiesta la replica tramite una struttura SAN su Fibre Channel, stiamo attualmente aggiungendo una soluzione adeguata, ma non è ancora pronta, quindi nel nostro caso solo Ethernet.
La replica può funzionare tra qualsiasi sistema di storage della serie ENGINE (N1, N2, N4) dai sistemi junior a quelli più vecchi e viceversa.
La funzionalità di entrambe le modalità di replica è completamente identica. Di seguito sono riportati maggiori dettagli su ciò che è disponibile:
- Replica “one to one” o “one to one”, ovvero la versione classica con due data center, quello principale e quello di backup
- La replica è “uno a molti” o “uno a molti”, cioè una LUN può essere replicata su più sistemi di storage contemporaneamente
- Attivare, disattivare e "invertire" la replica, rispettivamente, per abilitare, disabilitare o modificare la direzione della replica
- La replica è disponibile sia per i pool RDG (Raid Distributed Group) che per i pool DDP (Dynamic Disk Pool). Tuttavia, i LUN di un pool RDG possono essere replicati solo su un altro RDG. Stessa cosa per il DDP.
Ci sono molte altre piccole funzionalità, ma non ha senso elencarle; le menzioneremo durante la configurazione.
Impostazione della replica
Il processo di installazione è abbastanza semplice e si compone di tre fasi.
- Configurazione di rete
- Configurazione dell'archiviazione
- Impostazione di regole (connessioni) e mappatura
Un punto importante nell'impostazione della replica è che le prime due fasi dovrebbero essere ripetute sul sistema di archiviazione remoto, la terza fase solo su quello principale.
Configurazione delle risorse di rete
Il primo passaggio consiste nel configurare le porte di rete attraverso le quali verrà trasmesso il traffico di replica. Per fare ciò è necessario abilitare le porte e impostare i loro indirizzi IP nella sezione Adattatori front-end.
Successivamente, dobbiamo creare un pool (nel nostro caso RDG) e un IP virtuale per la replica (VIP). VIP è un indirizzo IP mobile legato a due indirizzi "fisici" dei controller di archiviazione (le porte che abbiamo appena configurato). Questa sarà l'interfaccia di replica principale. Puoi anche operare non con un VIP, ma con una VLAN, se devi lavorare con traffico taggato.
Il processo di creazione di un VIP per una replica non è molto diverso dalla creazione di un VIP per I/O (NFS, SMB, iSCSI). In questo caso creiamo un VIP normale (senza VLAN), ma assicurati di indicare che è per la replica (senza questo puntatore non potremo aggiungere VIP alla regola nel passaggio successivo).
Il VIP deve trovarsi nella stessa sottorete delle porte IP tra le quali fluttua.
Ripetiamo queste impostazioni su un sistema di archiviazione remoto, ovviamente con un IP diverso.
I VIP di diversi sistemi di archiviazione possono trovarsi in sottoreti diverse, l'importante è che ci sia un routing tra di loro. Nel nostro caso, questo esempio è mostrato esattamente (192.168.3.XX e 192.168.2.XX)
Questo completa la preparazione della parte di rete.
Configurazione dell'archiviazione
La configurazione dell'archiviazione per una replica differisce dal solito solo per il fatto che eseguiamo la mappatura tramite un menu speciale "Mappatura replica". Per il resto tutto è uguale alla configurazione normale. Ora, in ordine.
Nel pool R02 precedentemente creato è necessario creare una LUN. Creiamolo e chiamiamolo LUN1.
Dobbiamo anche creare la stessa LUN su un sistema di archiviazione remoto di dimensioni identiche. Noi creiamo. Per evitare confusione, chiameremo il LUN remoto LUN1R
Se avessimo bisogno di prendere una LUN già esistente, durante la configurazione della replica dovremmo smontare questa LUN produttiva dall'host e creare semplicemente una LUN vuota di dimensioni identiche sul sistema di archiviazione remoto.
La configurazione dello storage è completata, passiamo alla creazione di una regola di replica.
Impostazione di regole di replica o collegamenti di replica
Dopo aver creato le LUN sul sistema di storage, che al momento sarà quello primario, configuriamo la regola di replica LUN1 sul sistema di storage 1 su LUN1R sul sistema di storage 2.
L'impostazione viene effettuata nel menu “Replica remota”.
Creiamo una regola. Per fare ciò, è necessario specificare il destinatario della replica. Lì impostiamo anche il nome della connessione e il tipo di replica (sincrona o asincrona).
Nel campo “sistemi remoti” aggiungiamo il nostro sistema di storage2. Per aggiungerlo, è necessario utilizzare l'IP di gestione dei sistemi di storage (MGR) e il nome della LUN remota su cui eseguiremo la replica (nel nostro caso, LUN1R). Gli IP di controllo sono necessari solo nella fase di aggiunta di una connessione; attraverso di essi non verrà trasmesso il traffico di replica; per questo verrà utilizzato il VIP precedentemente configurato.
Già in questa fase possiamo aggiungere più di un sistema remoto per la topologia “uno a molti”: cliccare il pulsante “aggiungi nodo”, come nella figura sotto.
Nel nostro caso il sistema remoto è uno solo, quindi ci limitiamo a questo.
La regola è pronta. Tieni presente che viene aggiunto automaticamente su tutti i partecipanti alla replica (nel nostro caso sono due). È possibile creare quante regole si desidera, per qualsiasi numero di LUN e in qualsiasi direzione. Ad esempio, per bilanciare il carico, possiamo replicare parte delle LUN dal sistema di storage 1 al sistema di storage 2, e l'altra parte, al contrario, dal sistema di storage 2 al sistema di storage 1.
Sistema di archiviazione1. Immediatamente dopo la creazione è iniziata la sincronizzazione.
Sistema di archiviazione2. Vediamo la stessa regola, ma la sincronizzazione è già terminata.
LUN1 sul sistema di storage 1 ha il ruolo primario, ovvero è attivo. LUN1R sul sistema di storage 2 ha il ruolo di Secondario, ovvero è in standby in caso di guasto del sistema di storage 1.
Ora possiamo connettere il nostro LUN all'host.
Ci collegheremo tramite iSCSI, sebbene sia possibile farlo anche tramite FC. L'impostazione della mappatura tramite iSCSI LUN in una replica non è praticamente diversa dallo scenario abituale, quindi non lo considereremo in dettaglio qui. Semmai, questo processo è descritto nell’articolo “'.
L'unica differenza è che creiamo la mappatura nel menu “Replication Mapping”.
Abbiamo impostato la mappatura e fornito il LUN all'host. L'host ha visto il LUN.
Lo formattiamo in un file system locale.
Questo è tutto, la configurazione è completa. I test verranno dopo.
Test
Testeremo tre scenari principali.
- Cambio di ruolo regolare Secondario > Primario. È necessario un regolare cambio di ruolo nel caso in cui, ad esempio, dobbiamo eseguire alcune operazioni preventive nel data center principale e durante questo periodo, affinché i dati siano disponibili, trasferiamo il carico al data center di backup.
- Cambio di ruolo di emergenza Secondario > Primario (guasto del data center). Questo è lo scenario principale per il quale esiste la replica, che può aiutare a sopravvivere a un guasto completo del data center senza fermare l'azienda per un periodo prolungato.
- Interruzione dei canali di comunicazione tra data center. Verifica del corretto comportamento di due sistemi di storage in condizioni in cui per qualche motivo il canale di comunicazione tra i data center non è disponibile (ad esempio, un escavatore ha scavato nel posto sbagliato e ha rotto l'ottica oscura).
Per prima cosa inizieremo a scrivere i dati sul nostro LUN (scrivendo file con dati casuali). Vediamo subito che il canale di comunicazione tra i sistemi di stoccaggio viene utilizzato. Questo è facile da capire se si apre il monitoraggio del carico delle porte responsabili della replica.
Entrambi i sistemi di storage ora hanno dati “utili”, possiamo iniziare il test.
Per ogni evenienza, diamo un'occhiata alle somme hash di uno dei file e annotiamole.
Cambio di ruolo regolare
L'operazione di cambio ruoli (cambiamento della direzione della replica) può essere fatta con qualsiasi sistema storage, ma bisognerà comunque passare a entrambi, poiché bisognerà disabilitare la mappatura su Primario, e abilitarla su Secondario (che diventerà Primario ).
Forse ora sorge una domanda ragionevole: perché non automatizzare tutto questo? 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; è completamente automatizzata, ma la sua configurazione è molto più complicata. Scriveremo della creazione di un metrocluster nel prossimo articolo.
Sul sistema di archiviazione principale, disabilitiamo la mappatura per garantire che la registrazione si interrompa.
Quindi su uno dei sistemi di storage (non importa, principale o di backup) nel menu “Replica remota”, seleziona la nostra connessione REPL1 e fai clic su “Cambia ruolo”.
Dopo alcuni secondi, LUN1R (sistema di archiviazione di backup) diventa Primario.
Mappiamo LUN1R con il sistema di archiviazione2.
Successivamente, il nostro disco E: viene automaticamente collegato all'host, solo che questa volta è "arrivato" da LUN1R.
Per ogni evenienza, confrontiamo le somme hash.
Identico. Test superato.
Failover. Guasto del data center
Al momento, il sistema di storage principale dopo il passaggio regolare è rispettivamente il sistema di storage 2 e LUN1R. Per emulare un incidente, spegneremo entrambi i controller di archiviazione2.
Non è più possibile accedervi.
Vediamo cosa succede sul sistema di storage 1 (quello di backup al momento).
Vediamo che il LUN primario (LUN1R) non è disponibile. È apparso un messaggio di errore nei registri, nel pannello delle informazioni e anche nella regola di replica stessa. Di conseguenza, i dati dell'host non sono attualmente disponibili.
Modificare il ruolo di LUN1 in Primario.
Sto eseguendo la mappatura sull'host.
Assicurati che l'unità E sia visualizzata sull'host.
Controlliamo l'hashish.
Va tutto bene. Il sistema di storage è sopravvissuto con successo alla caduta del data center, che era attivo. Il tempo approssimativo impiegato per connettere l'"inversione" della replica e connettere la LUN dal data center di backup è stato di circa 3 minuti. È chiaro che nella produzione reale tutto è molto più complicato e oltre alle azioni con i sistemi di storage è necessario eseguire molte più operazioni sulla rete, sugli host, nelle applicazioni. E nella vita questo periodo di tempo sarà molto più lungo.
Qui vorrei scrivere che tutto, il test è stato portato a termine con successo, ma non abbiamo fretta. Il sistema di stoccaggio principale è “mentivo”, sappiamo che quando “è caduto”, era nel ruolo Primario. Cosa succede se si accende all'improvviso? Ci saranno due ruoli primari, il che equivale alla corruzione dei dati? Controlliamolo ora.
Accendiamo improvvisamente il sistema di archiviazione sottostante.
Si carica per qualche minuto e poi torna in servizio dopo una breve sincronizzazione, ma nel ruolo di Secondario.
Tutto ok. Il cervello diviso non è avvenuto. Abbiamo pensato a questo, e sempre dopo una caduta il sistema di accumulo assume il ruolo di Secondario, indipendentemente dal ruolo che ha avuto “durante la vita”. Ora possiamo dire con certezza che il test di guasto del data center ha avuto esito positivo.
Guasto dei canali di comunicazione tra data center
Il compito principale di questo test è garantire che il sistema di storage non inizi a comportarsi in modo strano se perde temporaneamente i canali di comunicazione tra due sistemi di storage e poi riappare.
COSÌ. Scolleghiamo i cavi tra i sistemi di stoccaggio (immaginiamo che siano stati scavati da un escavatore).
Sulla Primaria vediamo che non c'è connessione con la Secondaria.
Sulla Secondaria vediamo che non c'è connessione con la Primaria.
Tutto funziona bene e continuiamo a scrivere i dati sul sistema di archiviazione principale, cioè è garantito che siano diversi da quello di backup, cioè si sono “separati”.
In pochi minuti “ripariamo” il canale di comunicazione. Non appena i sistemi di storage si incontrano, la sincronizzazione dei dati viene attivata automaticamente. Non è richiesto nulla all'amministratore qui.
Dopo qualche tempo, la sincronizzazione è completata.
La connessione è stata ripristinata, la perdita dei canali di comunicazione non ha causato situazioni di emergenza e dopo l'accensione la sincronizzazione è avvenuta automaticamente.
risultati
Abbiamo analizzato la teoria: cosa è necessario e perché, dove sono i pro e dove sono i contro. Quindi configuriamo la replica sincrona tra due sistemi di storage.
Successivamente, sono stati eseguiti test di base per la commutazione normale, il guasto del data center e il guasto del canale di comunicazione. In tutti i casi, il sistema di archiviazione ha funzionato bene. Non si verifica alcuna perdita di dati e le operazioni amministrative sono ridotte al minimo per uno scenario manuale.
La prossima volta complicheremo la situazione e mostreremo come funziona tutta questa logica in un metrocluster automatizzato in modalità attivo-attivo, ovvero quando entrambi i sistemi di storage sono primari e il comportamento in caso di guasti del sistema di storage è completamente automatizzato.
Per favore scrivete commenti, saremo lieti di ricevere valide critiche e consigli pratici.
Fino alla prossima volta.
Fonte: habr.com