Ola, lectores de Habr! O tema deste artigo será a implementación de ferramentas de recuperación ante desastres nos sistemas de almacenamento do motor AERODISK. Inicialmente, queriamos escribir nun artigo sobre ambas as ferramentas: replicación e metrocluster, pero, por desgraza, o artigo resultou ser demasiado longo, polo que dividimos o artigo en dúas partes. Imos do sinxelo ao complexo. Neste artigo, configuraremos e probaremos a replicación síncrona: soltaremos un centro de datos e tamén romperemos a canle de comunicación entre os centros de datos e veremos que pasa.
Os nosos clientes adoitan facernos varias preguntas sobre a replicación, polo que antes de pasar a configurar e probar a implementación de réplicas, dirémosche un pouco sobre o que é a replicación no almacenamento.
Un pouco de teoría
A replicación en sistemas de almacenamento é un proceso continuo para garantir a identidade dos datos en varios sistemas de almacenamento simultaneamente. Tecnicamente, a replicación realízase de dúas formas.
Replicación síncrona – é copiar datos do sistema de almacenamento principal ao de copia de seguridade, seguido da confirmación obrigatoria de ambos sistemas de almacenamento de que os datos foron rexistrados e confirmados. É despois da confirmación por ambos os dous lados (ambos sistemas de almacenamento) cando os datos se consideran rexistrados e pódense traballar. Isto garante a identidade dos datos garantida en todos os sistemas de almacenamento que participan na réplica.
As vantaxes deste método:
- Os datos son sempre idénticos en todos os sistemas de almacenamento
Contras:
- Alto custo da solución (canles de comunicación rápidas, fibra óptica cara, transceptores de onda longa, etc.)
- Restricións de distancia (dentro de varias decenas de quilómetros)
- Non hai protección contra a corrupción dos datos lóxicos (se os datos están corrompidos (deliberadamente ou accidentalmente) no sistema de almacenamento principal, corromperase automaticamente e instantáneamente no de copia de seguridade, xa que os datos son sempre idénticos (ese é o paradoxo).
Replicación asíncrona – isto tamén é copiar datos do sistema de almacenamento principal ao de copia de seguridade, pero con certo atraso e sen necesidade de confirmar a escritura do outro lado. Podes traballar con datos inmediatamente despois de gravalos no sistema de almacenamento principal, e no sistema de almacenamento de copia de seguranza os datos estarán dispoñibles despois dun tempo. A identidade dos datos neste caso, por suposto, non está asegurada en absoluto. Os datos do sistema de almacenamento de copia de seguranza sempre están un pouco "no pasado".
Pros da replicación asíncrona:
- Solución de baixo custo (calquera canle de comunicación, óptica opcional)
- Sen restricións de distancia
- No sistema de almacenamento de copia de seguridade, os datos non se deterioran se están danados no principal (polo menos durante algún tempo); se os datos se danan, sempre pode deter a réplica para evitar a corrupción dos datos no sistema de almacenamento de copia de seguridade.
Contras:
- Os datos en diferentes centros de datos non sempre son idénticos
Así, a elección do modo de replicación depende dos obxectivos empresariais. Se é fundamental para ti que o centro de datos de copia de seguranza conteña exactamente os mesmos datos que o centro de datos principal (é dicir, o requisito comercial para RPO = 0), entón terás que desembolsar o diñeiro e soportar as limitacións dun sistema sincrónico. réplica. E se o atraso no estado dos datos é aceptable ou simplemente non hai diñeiro, entón definitivamente cómpre usar o método asíncrono.
Destaquemos tamén por separado tal modo (máis precisamente, unha topoloxía) como un metrocluster. No modo metroclúster utilízase a replicación síncrona, pero, a diferenza dunha réplica normal, un metrocluster permite que ambos sistemas de almacenamento funcionen en modo activo. Eses. non ten unha separación entre os centros de datos activos e en espera. As aplicacións funcionan simultaneamente con dous sistemas de almacenamento, que están fisicamente situados en diferentes centros de datos. Os tempos de inactividade durante accidentes en tal topoloxía son moi pequenos (RTO, normalmente minutos). Neste artigo non consideraremos a nosa implementación do metrocluster, xa que este é un tema moi amplo e amplo, polo que lle dedicaremos un seguinte artigo separado na continuación deste.
Ademais, con moita frecuencia, cando falamos de replicación mediante sistemas de almacenamento, moitas persoas teñen unha pregunta razoable: > “Moitas aplicacións teñen as súas propias ferramentas de replicación, por que usar a replicación en sistemas de almacenamento? É mellor ou peor?
Non hai unha resposta clara aquí, así que aquí están os argumentos a favor e en contra:
Argumentos PARA a replicación do almacenamento:
- Sinxeleza da solución. Cunha única ferramenta, pode replicar todo o seu conxunto de datos, independentemente do tipo de carga e da aplicación. Se utilizas unha réplica de aplicacións, terás que configurar cada aplicación por separado. Se hai máis de 2, isto é moi laborioso e caro (a replicación da aplicación normalmente require unha licenza separada e non gratuíta para cada aplicación. Pero máis sobre iso a continuación).
- Podes replicar calquera cousa, calquera aplicación, calquera dato, e sempre será coherente. Moitas (a maioría) das aplicacións non teñen capacidades de replicación e as réplicas do sistema de almacenamento son a única forma de proporcionar protección contra desastres.
- Non hai que pagar de máis pola funcionalidade de replicación da aplicación. Por regra xeral, non é barato, igual que as licenzas para unha réplica do sistema de almacenamento. Pero tes que pagar unha licenza para a replicación de almacenamento unha vez e hai que mercar unha licenza para a réplica da aplicación para cada aplicación por separado. Se hai moitas aplicacións deste tipo, entón custa un centavo bonito e o custo das licenzas para a replicación de almacenamento convértese nunha pinga no océano.
Argumentos CONTRA a replicación do almacenamento:
- A réplica a través de aplicacións ten máis funcionalidades desde o punto de vista das propias aplicacións, a aplicación coñece mellor os seus datos (obviamente), polo que hai máis opcións para traballar con elas.
- Os fabricantes dalgunhas aplicacións non garanten a coherencia dos seus datos se a replicación se fai mediante ferramentas de terceiros. *
* - tese controvertida. Por exemplo, un coñecido fabricante de DBMS estivo declarando oficialmente durante moito tempo que o seu DBMS só se pode replicar normalmente usando os seus medios e que o resto da replicación (incluíndo os sistemas de almacenamento) "non é verdade". Pero a vida demostrou que non é así. O máis probable é (pero non é certo) que este non sexa o intento máis honesto de vender máis licenzas aos clientes.
Como resultado, na maioría dos casos, a replicación desde o sistema de almacenamento é mellor, porque Esta é unha opción máis sinxela e menos custosa, pero hai casos complexos nos que se necesita unha funcionalidade específica da aplicación e é necesario traballar coa replicación a nivel de aplicación.
Rematada a teoría, agora a práctica
Configuraremos a réplica no noso laboratorio. En condicións de laboratorio, emulamos dous centros de datos (de feito, dous racks adxacentes que parecían estar en edificios diferentes). O stand consta de dous sistemas de almacenamento Engine N2, que están conectados entre si por cables ópticos. Un servidor físico que executa Windows Server 2016 está conectado a ambos sistemas de almacenamento mediante Ethernet de 10 Gb. O soporte é bastante sinxelo, pero isto non cambia a esencia.
Esquemáticamente se ve así:
Loxicamente, a replicación organízase do seguinte xeito:
Agora vexamos a funcionalidade de replicación que temos agora.
Admítense dous modos: asíncrono e síncrono. É lóxico que o modo sincrónico estea limitado pola distancia e a canle de comunicación. En particular, o modo síncrono require o uso de fibra como a física e 10 Gigabit Ethernet (ou superior).
A distancia admitida para a replicación síncrona é de 40 quilómetros, o valor de atraso da canle óptica entre centros de datos é de ata 2 milisegundos. En xeral, funcionará con grandes atrasos, pero despois haberá fortes desaceleracións durante a gravación (o que tamén é lóxico), polo que se está a planear a replicación sincrónica entre centros de datos, debe comprobar a calidade da óptica e os atrasos.
Os requisitos para a replicación asíncrona non son tan serios. Máis precisamente, non están aí en absoluto. Calquera conexión Ethernet que funcione servirá.
Actualmente, o sistema de almacenamento AERODISK ENGINE admite a replicación para dispositivos de bloque (LUN) a través do protocolo Ethernet (sobre cobre ou óptico). Para proxectos nos que se require a replicación a través dun tecido SAN sobre Fibre Channel, actualmente estamos engadindo unha solución axeitada, pero aínda non está lista, polo que no noso caso, só Ethernet.
A replicación pode funcionar entre calquera sistema de almacenamento da serie ENGINE (N1, N2, N4) desde sistemas junior ata outros máis antigos e viceversa.
A funcionalidade de ambos os modos de replicación é completamente idéntica. Abaixo amósanse máis detalles sobre o que está dispoñible:
- Replicación “one to one” ou “one to one”, é dicir, a versión clásica con dous centros de datos, o principal e o backup
- A replicación é "un para moitos" ou "un para moitos", é dicir. un LUN pódese replicar en varios sistemas de almacenamento á vez
- Activar, desactivar e "invertir" a replicación, respectivamente, para activar, desactivar ou cambiar a dirección da replicación
- A replicación está dispoñible para grupos RDG (Raid Distributed Group) e DDP (Dynamic Disk Pool). Non obstante, os LUN dun grupo RDG só se poden replicar noutro RDG. O mesmo con DDP.
Hai moitas máis características pequenas, pero non ten sentido enumeralas; mencionarémolas a medida que as configuremos.
Configurando a replicación
O proceso de configuración é bastante sinxelo e consta de tres etapas.
- Configuración da rede
- Configuración de almacenamento
- Establecemento de regras (conexións) e cartografía
Un punto importante na configuración da replicación é que as dúas primeiras etapas deben repetirse no sistema de almacenamento remoto, a terceira etapa, só na principal.
Configurar recursos de rede
O primeiro paso é configurar os portos de rede a través dos cales se transmitirá o tráfico de replicación. Para iso, cómpre activar os portos e establecer os seus enderezos IP na sección Adaptadores front-end.
Despois disto, necesitamos crear un pool (no noso caso RDG) e unha IP virtual para replicación (VIP). VIP é un enderezo IP flotante que está ligado a dous enderezos "físicos" dos controladores de almacenamento (os portos que acabamos de configurar). Esta será a principal interface de replicación. Tamén podes operar non cun VIP, senón cunha VLAN, se precisas traballar con tráfico etiquetado.
O proceso de creación dun VIP para unha réplica non é moi diferente ao de crear un VIP para E/S (NFS, SMB, iSCSI). Neste caso, creamos un VIP normal (sen VLAN), pero asegúrese de indicar que é para replicación (sen este punteiro non poderemos engadir VIP á regra no seguinte paso).
O VIP debe estar na mesma subrede que os portos IP entre os que flota.
Repetimos estas configuracións nun sistema de almacenamento remoto, cunha IP diferente, por suposto.
Os VIP de diferentes sistemas de almacenamento poden estar en diferentes subredes, o principal é que hai enrutamento entre eles. No noso caso, este exemplo móstrase exactamente (192.168.3.XX e 192.168.2.XX)
Isto completa a preparación da parte da rede.
Configurando o almacenamento
A configuración do almacenamento para unha réplica difire do habitual só en que facemos a asignación a través dun menú especial "Mapeamento de replicación". Se non, todo é o mesmo que coa configuración normal. Agora, en orde.
No grupo R02 creado anteriormente, cómpre crear un LUN. Creémolo e chamémoslle LUN1.
Tamén necesitamos crear o mesmo LUN nun sistema de almacenamento remoto de idéntico tamaño. Nós creamos. Para evitar confusións, chamemos ao LUN remoto LUN1R
Se necesitábamos tomar un LUN que xa existe, mentres configuramos a réplica, necesitaríamos desmontar este LUN produtivo do host e simplemente crear un LUN baleiro de idéntico tamaño no sistema de almacenamento remoto.
A configuración de almacenamento completouse, pasemos á creación dunha regra de replicación.
Configurar regras de replicación ou ligazóns de replicación
Despois de crear os LUN no sistema de almacenamento, que será o principal neste momento, configuramos a regra de replicación LUN1 no sistema de almacenamento 1 a LUN1R no sistema de almacenamento 2.
A configuración realízase no menú "Replicación remota".
Imos crear unha regra. Para iso, cómpre especificar o destinatario da réplica. Alí tamén establecemos o nome da conexión e o tipo de replicación (sincrónica ou asíncrona).
No campo “sistemas remotos” engadimos o noso sistema de almacenamento2. Para engadir, cómpre utilizar os sistemas de almacenamento IP de xestión (MGR) e o nome do LUN remoto no que realizaremos a replicación (no noso caso, LUN1R). As IP de control só son necesarias na fase de engadir unha conexión; o tráfico de replicación non se transmitirá a través delas; para iso utilizarase o VIP configurado previamente.
Xa nesta fase podemos engadir máis dun sistema remoto para a topoloxía "uno a moitos": fai clic no botón "engadir nodo", como na figura seguinte.
No noso caso, só hai un sistema remoto, polo que nos limitamos a isto.
A regra está lista. Teña en conta que engádese automaticamente a todos os participantes de replicación (no noso caso hai dous deles). Podes crear tantas regras como queiras, para calquera número de LUN e en calquera dirección. Por exemplo, para equilibrar a carga, podemos replicar parte dos LUN do sistema de almacenamento 1 ao sistema de almacenamento 2, e a outra parte, pola contra, do sistema de almacenamento 2 ao sistema de almacenamento 1.
Sistema de almacenamento 1. Inmediatamente despois da creación, comezou a sincronización.
Sistema de almacenamento 2. Vemos a mesma regra, pero a sincronización xa rematou.
LUN1 no sistema de almacenamento 1 está no papel principal, é dicir, está activo. LUN1R no sistema de almacenamento 2 ten a función de secundario, é dicir, está en espera no caso de que o sistema de almacenamento 1 falle.
Agora podemos conectar o noso LUN ao host.
Conectarémonos mediante iSCSI, aínda que tamén se pode facer mediante FC. Configurar a asignación mediante iSCSI LUN nunha réplica practicamente non é diferente do escenario habitual, polo que non o consideraremos en detalle aquí. En todo caso, este proceso descríbese no artigo "».
A única diferenza é que creamos mapeo no menú "Mapeamento de replicación".
Configuramos o mapeo e demos o LUN ao host. O anfitrión viu o LUN.
Formatámolo nun sistema de ficheiros local.
Isto é todo, a configuración está completa. A continuación virán as probas.
Probas
Probaremos tres escenarios principais.
- Cambio de roles regular Secundario > Primario. É necesario un cambio de rol regular no caso de, por exemplo, que necesitemos realizar algunhas operacións preventivas no centro de datos principal e durante este tempo, para que os datos estean dispoñibles, transferimos a carga ao centro de datos de copia de seguridade.
- Cambio de rol de emerxencia Secundario > Primario (fallo do centro de datos). Este é o escenario principal para o que existe a replicación, que pode axudar a sobrevivir a un fallo completo do centro de datos sen deter a empresa durante un período prolongado.
- Desglose das canles de comunicación entre centros de datos. Comprobar o comportamento correcto de dous sistemas de almacenamento en condicións nas que, por algún motivo, a canle de comunicación entre os centros de datos non está dispoñible (por exemplo, unha escavadora escavou nun lugar equivocado e rompeu a óptica escura).
En primeiro lugar, comezaremos a escribir datos no noso LUN (escribindo ficheiros con datos aleatorios). Inmediatamente vemos que se está a utilizar a canle de comunicación entre os sistemas de almacenamento. Isto é fácil de entender se abres o monitor de carga dos portos responsables da replicación.
Os dous sistemas de almacenamento teñen agora datos "útiles", podemos comezar a proba.
Por se acaso, vexamos as sumas hash dun dos ficheiros e anotámolas.
Cambio de roles regular
A operación de cambio de roles (cambiando a dirección da replicación) pódese facer con calquera sistema de almacenamento, pero aínda así terás que ir a ambos, xa que terás que desactivar a asignación en Primaria e habilitala en Secundaria (que pasará a ser Primaria). ).
Quizais xorde agora unha pregunta razoable: por que non automatizar isto? A resposta é: é sinxelo, a replicación é un medio sinxelo de resiliencia ante desastres, baseado unicamente en operacións manuais. Para automatizar estas operacións, hai un modo de metrocluster, totalmente automatizado, pero a súa configuración é moito máis complicada. Escribiremos sobre a creación dun metrocluster no seguinte artigo.
No sistema de almacenamento principal, desactivamos a asignación para asegurarnos de que se deteña a gravación.
A continuación, nun dos sistemas de almacenamento (non importa, no principal ou na copia de seguridade) no menú "Replicación remota", seleccione a nosa conexión REPL1 e prema en "Cambiar rol".
Despois duns segundos, LUN1R (sistema de almacenamento de seguranza) pasa a ser o principal.
Mapeamos LUN1R co sistema de almacenamento 2.
Despois diso, a nosa unidade E: conéctase automaticamente ao host, só que esta vez "chegou" de LUN1R.
Por se acaso, comparamos as sumas hash.
Idénticamente. Proba superada.
Failover. Fallo do centro de datos
Polo momento, o sistema de almacenamento principal despois do cambio regular é o sistema de almacenamento 2 e LUN1R, respectivamente. Para emular un accidente, apagaremos os dous controladores de almacenamento2.
Non hai máis acceso a ela.
Vexamos que está a suceder no sistema de almacenamento 1 (o de copia de seguridade neste momento).
Vemos que o LUN principal (LUN1R) non está dispoñible. Apareceu unha mensaxe de erro nos rexistros, no panel de información e tamén na propia regra de replicación. En consecuencia, os datos do host non están dispoñibles actualmente.
Cambia o papel de LUN1 a Primario.
Estou facendo mapas para o host.
Asegúrate de que a unidade E aparece no host.
Comprobamos o hash.
Todo está ben. O sistema de almacenamento sobreviviu con éxito á caída do centro de datos, que estaba activo. O tempo aproximado que pasamos conectando a "reversión" de replicación e conectando o LUN desde o centro de datos de copia de seguranza foi duns 3 minutos. Está claro que na produción real todo é moito máis complicado e, ademais das accións con sistemas de almacenamento, cómpre realizar moitas máis operacións na rede, nos hosts, nas aplicacións. E na vida este período de tempo será moito máis longo.
Aquí gustaríame escribir que todo, a proba foi completada con éxito, pero non nos apresuremos. O sistema de almacenamento principal é "mentir", sabemos que cando "caeu", estaba no papel principal. Que pasa se se acende de súpeto? Haberá dous papeis primarios, o que equivale a corrupción de datos? Imos comprobalo agora.
Imos activar de súpeto o sistema de almacenamento subxacente.
Carga durante uns minutos e despois volve ao servizo despois dunha pequena sincronización, pero no papel de Secundario.
Todo ben. O cerebro dividido non ocorreu. Pensamos nisto, e sempre despois dunha caída o sistema de almacenamento pasa ao papel de Secundario, independentemente do papel que tiña "durante a vida". Agora podemos dicir con certeza que a proba de fallo do centro de datos foi exitosa.
Fallo das canles de comunicación entre centros de datos
A principal tarefa desta proba é asegurarse de que o sistema de almacenamento non comeza a actuar de forma estraña se perde temporalmente as canles de comunicación entre dous sistemas de almacenamento e despois aparece de novo.
Entón. Desconectamos os cables entre os sistemas de almacenamento (imaxinamos que foron escavados por unha escavadora).
En Primaria vemos que non hai conexión con Secundaria.
En Secundaria vemos que non hai conexión con Primaria.
Todo funciona ben, e seguimos escribindo datos no sistema de almacenamento principal, é dicir, están garantidos que son diferentes do de copia de seguridade, é dicir, que se "separaron".
En poucos minutos "reparamos" a canle de comunicación. En canto os sistemas de almacenamento se ven, a sincronización de datos actívase automaticamente. Non se require nada do administrador aquí.
Despois dun tempo, a sincronización rematou.
Restableceuse a conexión, a perda das canles de comunicación non provocou ningunha situación de emerxencia e, despois de acenderse, a sincronización produciuse automaticamente.
Descubrimentos
Analizamos a teoría: que é necesario e por que, onde están os pros e onde están os contras. Despois configuramos a replicación síncrona entre dous sistemas de almacenamento.
A continuación, realizáronse probas básicas de conmutación normal, fallo do centro de datos e fallo da canle de comunicación. En todos os casos, o sistema de almacenamento funcionou ben. Non hai perda de datos e as operacións administrativas redúcense ao mínimo para un escenario manual.
A próxima vez complicaremos a situación e mostraremos como funciona toda esta lóxica nun metroclúster automatizado en modo activo-activo, é dicir, cando ambos os sistemas de almacenamento son primarios, e o comportamento en caso de avarías do sistema de almacenamento está totalmente automatizado.
Escriba comentarios, estaremos encantados de recibir críticas sólidas e consellos prácticos.
Ata a próxima.
Fonte: www.habr.com