Hola, lectors de Habr! El tema d'aquest article serà la implementació d'eines de recuperació de desastres als sistemes d'emmagatzematge del motor AERODISK. Inicialment, volíem escriure en un article sobre ambdues eines: replicació i metrocluster, però, malauradament, l'article va resultar massa llarg, així que vam dividir l'article en dues parts. Passem del simple al complex. En aquest article, configurarem i provarem la replicació síncrona: deixarem caure un centre de dades i també trencarem el canal de comunicació entre els centres de dades i veurem què passa.
Els nostres clients sovint ens fan diverses preguntes sobre la rèplica, així que abans de passar a configurar i provar la implementació de rèpliques, us explicarem una mica què és la rèplica a l'emmagatzematge.
Una mica de teoria
La replicació en sistemes d'emmagatzematge és un procés continu per garantir la identitat de les dades en diversos sistemes d'emmagatzematge simultàniament. Tècnicament, la replicació s'aconsegueix de dues maneres.
Replicació síncrona – Es tracta de copiar dades del sistema d'emmagatzematge principal al de còpia de seguretat, seguit de la confirmació obligatòria d'ambdós sistemes d'emmagatzematge que les dades s'han enregistrat i confirmat. És després de la confirmació per ambdues parts (ambdós sistemes d'emmagatzematge) que les dades es consideren enregistrades i es poden treballar. Això garanteix la identitat de dades garantida en tots els sistemes d'emmagatzematge que participen en la rèplica.
Els avantatges d'aquest mètode:
- Les dades són sempre idèntiques a tots els sistemes d'emmagatzematge
Contres:
- Alt cost de la solució (canals de comunicació ràpids, fibra òptica cara, transceptors d'ona llarga, etc.)
- Restriccions de distància (dins de diverses desenes de quilòmetres)
- No hi ha protecció contra la corrupció de dades lògiques (si les dades estan malmeses (deliberadament o accidentalment) al sistema d'emmagatzematge principal, es corromprà automàticament i instantàniament en el de còpia de seguretat, ja que les dades són sempre idèntiques (aquesta és la paradoxa).
Replicació asíncrona – això també és copiar dades del sistema d'emmagatzematge principal al de còpia de seguretat, però amb un cert retard i sense necessitat de confirmar l'escriptura a l'altre costat. Podeu treballar amb dades immediatament després d'enregistrar-les al sistema d'emmagatzematge principal, i al sistema d'emmagatzematge de còpia de seguretat les dades estaran disponibles al cap d'un temps. La identitat de les dades en aquest cas, per descomptat, no està assegurada en absolut. Les dades del sistema d'emmagatzematge de còpia de seguretat sempre són una mica "en el passat".
Avantatges de la replicació asíncrona:
- Solució de baix cost (qualsevol canal de comunicació, òptica opcional)
- Sense restriccions de distància
- Al sistema d'emmagatzematge de còpia de seguretat, les dades no es deterioren si es fan malbé al sistema principal (almenys durant algun temps); si les dades es corrompen, sempre podeu aturar la rèplica per evitar que les dades es corrompin al sistema d'emmagatzematge de còpia de seguretat.
Contres:
- Les dades dels diferents centres de dades no sempre són idèntiques
Per tant, l'elecció del mode de replicació depèn dels objectius empresarials. Si és fonamental per a vostè que el centre de dades de còpia de seguretat contingui exactament les mateixes dades que el centre de dades principal (és a dir, el requisit comercial per a RPO = 0), haureu de gastar diners en efectiu i suportar les limitacions d'un sistema sincrònic. rèplica. I si el retard en l'estat de les dades és acceptable o simplement no hi ha diners, definitivament haureu d'utilitzar el mètode asíncron.
Destaquem també per separat aquest mode (més precisament, una topologia) com a metrocluster. En el mode de metroclúster, s'utilitza la replicació síncrona, però, a diferència d'una rèplica normal, un metroclúster permet que els dos sistemes d'emmagatzematge funcionin en mode actiu. Aquells. no teniu una separació entre els centres de dades actius i en espera. Les aplicacions funcionen simultàniament amb dos sistemes d'emmagatzematge, que es troben físicament en centres de dades diferents. Els temps d'inactivitat durant els accidents en aquesta topologia són molt petits (RTO, normalment minuts). En aquest article no considerarem la nostra implementació del metroclúster, ja que es tracta d'un tema molt ampli i ampli, per la qual cosa li dedicarem un article següent a part, a continuació d'aquest.
A més, molt sovint, quan parlem de replicació mitjançant sistemes d'emmagatzematge, moltes persones tenen una pregunta raonable: > “Moltes aplicacions tenen les seves pròpies eines de replicació, per què utilitzar la replicació en sistemes d'emmagatzematge? És millor o pitjor?
No hi ha una resposta clara aquí, així que aquí teniu els arguments A favor i en CONTRE:
Arguments per a la replicació d'emmagatzematge:
- Simplicitat de la solució. Amb una eina, podeu replicar tot el vostre conjunt de dades, independentment del tipus de càrrega i de l'aplicació. Si utilitzeu una rèplica d'aplicacions, haureu de configurar cada aplicació per separat. Si n'hi ha més de 2, això és extremadament laboriós i costós (la rèplica de l'aplicació sol requerir una llicència independent i no gratuïta per a cada aplicació. Però més informació a continuació).
- Podeu replicar qualsevol cosa, qualsevol aplicació, qualsevol dada, i sempre serà coherent. Moltes (la majoria) d'aplicacions no tenen capacitats de replicació, i les rèpliques del sistema d'emmagatzematge són l'única manera de proporcionar protecció contra desastres.
- No cal pagar en excés per la funcionalitat de replicació d'aplicacions. Per regla general, no és barat, igual que les llicències per a una rèplica del sistema d'emmagatzematge. Però heu de pagar una llicència per a la rèplica d'emmagatzematge una vegada i s'ha de comprar una llicència per a la rèplica de l'aplicació per a cada aplicació per separat. Si hi ha moltes aplicacions d'aquest tipus, costa un cèntim bastant i el cost de les llicències per a la replicació d'emmagatzematge es converteix en una gota a la galleda.
Arguments en contra de la replicació d'emmagatzematge:
- La rèplica a través d'aplicacions té més funcionalitat des del punt de vista de les pròpies aplicacions, l'aplicació coneix millor les seves dades (òbviament), així que hi ha més opcions per treballar-hi.
- Els fabricants d'algunes aplicacions no garanteixen la coherència de les seves dades si la replicació es fa amb eines de tercers. *
* - tesi controvertida. Per exemple, un conegut fabricant de SGBD ha estat declarant oficialment durant molt de temps que el seu SGBD només es pot replicar normalment amb els seus mitjans, i la resta de la replicació (inclosos els sistemes d'emmagatzematge) "no és certa". Però la vida ha demostrat que això no és així. El més probable (però això no és segur) no és simplement l'intent més honest de vendre més llicències als clients.
Com a resultat, en la majoria dels casos, la replicació des del sistema d'emmagatzematge és millor, perquè Aquesta és una opció més senzilla i menys costosa, però hi ha casos complexos en què es necessita una funcionalitat específica de l'aplicació i cal treballar amb la replicació a nivell d'aplicació.
Acabada la teoria, ara la pràctica
Configurarem la rèplica al nostre laboratori. En condicions de laboratori, vam emular dos centres de dades (de fet, dos bastidors adjacents que semblaven estar en edificis diferents). L'estand consta de dos sistemes d'emmagatzematge Engine N2, connectats entre si per cables òptics. Un servidor físic que executa Windows Server 2016 està connectat als dos sistemes d'emmagatzematge mitjançant Ethernet de 10 Gb. L'estand és bastant senzill, però això no canvia l'essència.
Esquemàticament es veu així:
Lògicament, la replicació s'organitza de la següent manera:
Ara mirem la funcionalitat de replicació que tenim ara.
S'admeten dos modes: asíncron i síncron. És lògic que el mode síncron estigui limitat per la distància i el canal de comunicació. En particular, el mode síncron requereix l'ús de fibra com a física i 10 Gigabit Ethernet (o superior).
La distància admesa per a la replicació síncrona és de 40 quilòmetres, el valor de retard del canal òptic entre centres de dades és de fins a 2 mil·lisegons. En general, funcionarà amb grans retards, però després hi haurà forts desacceleraments durant l'enregistrament (que també és lògic), de manera que si planifiqueu una rèplica sincrònica entre centres de dades, hauríeu de comprovar la qualitat de l'òptica i els retards.
Els requisits per a la replicació asíncrona no són tan greus. Més precisament, no hi són en absolut. Qualsevol connexió Ethernet que funcioni ho farà.
Actualment, el sistema d'emmagatzematge AERODISK ENGINE admet la replicació de dispositius de bloc (LUN) mitjançant el protocol Ethernet (sobre coure o òptic). Per als projectes on es requereix la replicació a través d'un teixit SAN sobre Fibre Channel, actualment estem afegint una solució adequada, però encara no està preparada, per tant, en el nostre cas, només Ethernet.
La replicació pot funcionar entre qualsevol sistema d'emmagatzematge de la sèrie ENGINE (N1, N2, N4), des de sistemes júniors fins a sistemes més antics i viceversa.
La funcionalitat dels dos modes de replicació és completament idèntica. A continuació es mostren més detalls sobre el que està disponible:
- Replicació “one to one” o “one to one”, és a dir, la versió clàssica amb dos centres de dades, el principal i el de còpia de seguretat
- La replicació és "un a molts" o "un a molts", és a dir. un LUN es pot replicar a diversos sistemes d'emmagatzematge alhora
- Activar, desactivar i "invertir" la replicació, respectivament, per activar, desactivar o canviar la direcció de la replicació
- La replicació està disponible tant per a les agrupacions RDG (Raid Distributed Group) com per a les agrupacions DDP (Dynamic Disk Pool). Tanmateix, els LUN d'un grup RDG només es poden replicar a un altre RDG. El mateix amb DDP.
Hi ha moltes més característiques petites, però no té cap sentit particular enumerar-les; les esmentarem a mesura que les configurem.
Configuració de la replicació
El procés de configuració és bastant senzill i consta de tres etapes.
- Configuració de la xarxa
- Configuració d'emmagatzematge
- Configuració de regles (connexions) i mapeig
Un punt important a l'hora de configurar la replicació és que les dues primeres etapes s'han de repetir al sistema d'emmagatzematge remot, la tercera etapa, només a la principal.
Configuració de recursos de xarxa
El primer pas és configurar els ports de xarxa a través dels quals es transmetrà el trànsit de rèplica. Per fer-ho, heu d'habilitar els ports i establir les seves adreces IP a la secció Adaptadors frontals.
Després d'això, hem de crear un pool (en el nostre cas RDG) i una IP virtual per a la replicació (VIP). VIP és una adreça IP flotant que està lligada a dues adreces "físiques" de controladors d'emmagatzematge (els ports que acabem de configurar). Aquesta serà la interfície de replicació principal. També podeu operar no amb un VIP, sinó amb una VLAN, si necessiteu treballar amb trànsit etiquetat.
El procés de creació d'un VIP per a una rèplica no és molt diferent de crear un VIP per a E/S (NFS, SMB, iSCSI). En aquest cas, creem un VIP normal (sense VLAN), però assegureu-vos d'indicar que és per a la replicació (sense aquest punter no podrem afegir VIP a la regla en el pas següent).
El VIP ha d'estar a la mateixa subxarxa que els ports IP entre els quals flota.
Repetim aquests paràmetres en un sistema d'emmagatzematge remot, amb una IP diferent, és clar.
Els VIP de diferents sistemes d'emmagatzematge poden estar en diferents subxarxes, el més important és que hi hagi encaminament entre ells. En el nostre cas, aquest exemple es mostra exactament (192.168.3.XX i 192.168.2.XX)
Això completa la preparació de la part de xarxa.
Configuració d'emmagatzematge
La configuració de l'emmagatzematge per a una rèplica difereix de l'habitual només en què fem el mapeig a través d'un menú especial "Mapa de rèplica". En cas contrari, tot és igual que amb la configuració normal. Ara, en ordre.
Al grup R02 creat anteriorment, heu de crear un LUN. Creem-lo i anomenem-lo LUN1.
També hem de crear el mateix LUN en un sistema d'emmagatzematge remot de mida idèntica. Creem. Per evitar confusions, truquem al LUN remot LUN1R
Si haguéssim de prendre un LUN que ja existeix, llavors, mentre configurem la rèplica, hauríem de desmuntar aquest LUN productiu de l'amfitrió i, simplement, crear un LUN buit de mida idèntica al sistema d'emmagatzematge remot.
La configuració d'emmagatzematge s'ha completat, passem a crear una regla de replicació.
Configuració de regles de replicació o enllaços de replicació
Després de crear els LUN al sistema d'emmagatzematge, que serà el principal de moment, configurem la regla de replicació LUN1 al sistema d'emmagatzematge 1 a LUN1R al sistema d'emmagatzematge 2.
La configuració es fa al menú "Replicació remota".
Creem una regla. Per fer-ho, heu d'especificar el destinatari de la rèplica. Allà també establim el nom de la connexió i el tipus de replicació (síncrona o asíncrona).
Al camp "sistemes remots" afegim el nostre sistema d'emmagatzematge2. Per afegir, cal utilitzar els sistemes d'emmagatzematge IP de gestió (MGR) i el nom del LUN remot en el qual realitzarem la replicació (en el nostre cas, LUN1R). Les IP de control només es necessiten en l'etapa d'afegir una connexió; el trànsit de rèplica no es transmetrà a través d'elles; per a això s'utilitzarà el VIP configurat anteriorment.
Ja en aquesta etapa podem afegir més d'un sistema remot per a la topologia "un a molts": feu clic al botó "afegir node", com a la figura següent.
En el nostre cas, només hi ha un sistema remot, així que ens limitem a això.
La regla està a punt. Tingueu en compte que s'afegeix automàticament a tots els participants de rèplica (en el nostre cas n'hi ha dos). Podeu crear tantes regles com vulgueu, per a qualsevol nombre de LUN i en qualsevol direcció. Per exemple, per equilibrar la càrrega, podem replicar part dels LUN del sistema d'emmagatzematge 1 al sistema d'emmagatzematge 2, i l'altra part, per contra, del sistema d'emmagatzematge 2 al sistema d'emmagatzematge 1.
Sistema d'emmagatzematge 1. Immediatament després de la creació, va començar la sincronització.
Sistema d'emmagatzematge 2. Veiem la mateixa regla, però la sincronització ja s'ha acabat.
El LUN1 del sistema d'emmagatzematge 1 té la funció principal, és a dir, està actiu. LUN1R al sistema d'emmagatzematge 2 té el paper de secundari, és a dir, està en espera en cas que el sistema d'emmagatzematge 1 falla.
Ara podem connectar el nostre LUN a l'amfitrió.
Ens connectarem mitjançant iSCSI, encara que també es pot fer mitjançant FC. Configurar el mapeig mitjançant iSCSI LUN en una rèplica pràcticament no és diferent de l'escenari habitual, per la qual cosa no ho considerarem en detall aquí. En qualsevol cas, aquest procés es descriu a l'article "».
L'única diferència és que creem mapes al menú "Mapa de replicació".
Vam configurar el mapeig i vam donar el LUN a l'amfitrió. L'amfitrió va veure el LUN.
El formem en un sistema de fitxers local.
Això és tot, la configuració està completa. Les proves vindran a continuació.
Proves
Provarem tres escenaris principals.
- Canvi de rol habitual Secundària > Primària. Cal un canvi de rol periòdic en cas, per exemple, de realitzar algunes operacions preventives al centre de dades principal i durant aquest temps, perquè les dades estiguin disponibles, transferim la càrrega al centre de dades de còpia de seguretat.
- Canvi de rol d'emergència Secundària > Primària (error del centre de dades). Aquest és l'escenari principal per al qual existeix la replicació, que pot ajudar a sobreviure a una fallada completa del centre de dades sense aturar l'empresa durant un període prolongat.
- Desglossament dels canals de comunicació entre centres de dades. Comprovació del comportament correcte de dos sistemes d'emmagatzematge en condicions en què per algun motiu el canal de comunicació entre els centres de dades no està disponible (per exemple, una excavadora va cavar en un lloc equivocat i va trencar l'òptica fosca).
Primer, començarem a escriure dades al nostre LUN (escrivint fitxers amb dades aleatòries). De seguida veiem que s'està utilitzant el canal de comunicació entre els sistemes d'emmagatzematge. Això és fàcil d'entendre si obriu el control de càrrega dels ports responsables de la replicació.
Tots dos sistemes d'emmagatzematge tenen ara dades "útils", podem començar la prova.
Per si de cas, mirem les sumes hash d'un dels fitxers i anotem-les.
Canvi de rol regular
L'operació de canvi de rols (canviant la direcció de la replicació) es pot fer amb qualsevol sistema d'emmagatzematge, però encara caldrà anar a tots dos, ja que caldrà desactivar el mapeig a Primari i habilitar-lo a Secundària (que es convertirà en Primari). ).
Potser ara sorgeix una pregunta raonable: per què no automatitzar-ho? La resposta és: és senzill, la replicació és un mitjà senzill de resiliència als desastres, basat únicament en operacions manuals. Per automatitzar aquestes operacions, hi ha un mode de metrocluster, totalment automatitzat, però la seva configuració és molt més complicada. Escriurem sobre la creació d'un metroclúster al proper article.
Al sistema d'emmagatzematge principal, desactivem el mapeig per garantir que s'atura la gravació.
A continuació, en un dels sistemes d'emmagatzematge (no importa, principal o còpia de seguretat) al menú "Replicació remota", seleccioneu la nostra connexió REPL1 i feu clic a "Canviar rol".
Després d'uns segons, LUN1R (sistema d'emmagatzematge de còpia de seguretat) esdevé principal.
Mapem LUN1R amb el sistema d'emmagatzematge 2.
Després d'això, la nostra unitat E: s'adjunta automàticament a l'amfitrió, només que aquesta vegada "va arribar" de LUN1R.
Per si de cas, comparem les sumes hash.
De manera idèntica. Prova superada.
Failover. Falla del centre de dades
De moment, el sistema d'emmagatzematge principal després del canvi regular és el sistema d'emmagatzematge 2 i LUN1R, respectivament. Per emular un accident, apagarem els dos controladors d'emmagatzematge2.
No hi ha més accés.
Vegem què passa al sistema d'emmagatzematge 1 (el de còpia de seguretat en aquest moment).
Veiem que el LUN principal (LUN1R) no està disponible. Va aparèixer un missatge d'error als registres, al tauler d'informació i també a la pròpia regla de rèplica. En conseqüència, les dades de l'amfitrió no estan disponibles actualment.
Canvieu el rol de LUN1 a Primari.
Estic fent mapes a l'amfitrió.
Assegureu-vos que la unitat E apareix a l'amfitrió.
Comprovem el hash.
Tot està bé. El sistema d'emmagatzematge va sobreviure amb èxit a la caiguda del centre de dades, que estava actiu. El temps aproximat que vam dedicar a connectar la "inversió" de rèplica i connectar el LUN des del centre de dades de còpia de seguretat va ser d'uns 3 minuts. És evident que en la producció real tot és molt més complicat i, a més de les accions amb sistemes d'emmagatzematge, cal fer moltes més operacions a la xarxa, als hosts, a les aplicacions. I a la vida aquest període de temps serà molt més llarg.
Aquí m'agradaria escriure que tot, la prova s'ha completat amb èxit, però no ens apurem. El sistema d'emmagatzematge principal és "mentir", sabem que quan va "caure", estava en el paper de Primària. Què passa si s'encén de sobte? Hi haurà dos rols principals, que equival a corrupció de dades? Comprovem-ho ara.
Activem de sobte el sistema d'emmagatzematge subjacent.
Es carrega durant uns minuts i després torna al servei després d'una breu sincronització, però en el paper de Secundària.
Tot correcte. El cervell dividit no va passar. Hem pensat en això, i sempre després d'una caiguda el sistema d'emmagatzematge s'eleva a la funció de Secundària, independentment del paper que tingués "durant la vida". Ara podem dir amb seguretat que la prova de fallada del centre de dades va tenir èxit.
Falla dels canals de comunicació entre centres de dades
La tasca principal d'aquesta prova és assegurar-se que el sistema d'emmagatzematge no comenci a actuar de manera estranya si perd temporalment els canals de comunicació entre dos sistemes d'emmagatzematge i després torna a aparèixer.
Tan. Desconnectem els cables entre els sistemes d'emmagatzematge (imaginem que van ser excavats per una excavadora).
A Primària veiem que no hi ha cap connexió amb Secundària.
A Secundària veiem que no hi ha cap connexió amb Primària.
Tot funciona bé, i seguim escrivint dades al sistema d'emmagatzematge principal, és a dir, es garanteix que són diferents del de còpia de seguretat, és a dir, s'han "separat".
En pocs minuts “reparem” el canal de comunicació. Tan bon punt els sistemes d'emmagatzematge es veuen, la sincronització de dades s'activa automàticament. No cal res de l'administrador aquí.
Després d'un temps, la sincronització s'ha completat.
La connexió es va restablir, la pèrdua dels canals de comunicació no va provocar cap situació d'emergència i, després de l'encesa, la sincronització es va fer automàticament.
Troballes
Hem analitzat la teoria: què es necessita i per què, on són els pros i on són els contres. A continuació, configurem la replicació síncrona entre dos sistemes d'emmagatzematge.
A continuació, es van realitzar proves bàsiques per a la commutació normal, la fallada del centre de dades i la fallada del canal de comunicació. En tots els casos, el sistema d'emmagatzematge va funcionar bé. No hi ha pèrdua de dades i les operacions administratives es redueixen al mínim per a un escenari manual.
La propera vegada complicarem la situació i mostrarem com funciona tota aquesta lògica en un metroclúster automatitzat en mode actiu-actiu, és a dir, quan tots dos sistemes d'emmagatzematge són primaris, i el comportament en cas de fallades del sistema d'emmagatzematge està totalment automatitzat.
Si us plau, escriviu comentaris, estarem encantats de rebre crítiques sòlides i consells pràctics.
Fins la pròxima vegada.
Font: www.habr.com