¡Hola lectores de Habr! El tema de este artículo será la implementación de herramientas de recuperación ante desastres en los sistemas de almacenamiento AERODISK Engine. Inicialmente, queríamos escribir un artículo sobre ambas herramientas: replicación y metrocluster, pero, desafortunadamente, el artículo resultó ser demasiado largo, por lo que lo dividimos en dos partes. Vayamos de lo simple a lo complejo. En este artículo, configuraremos y probaremos la replicación sincrónica: eliminaremos un centro de datos y también romperemos el canal de comunicación entre los centros de datos y veremos qué sucede.
Nuestros clientes suelen hacernos diversas preguntas sobre la replicación, por lo que antes de pasar a configurar y probar la implementación de réplicas, te contamos un poco sobre qué es la replicación en almacenamiento.
Un poco de teoría
La replicación en sistemas de almacenamiento es un proceso continuo para garantizar la identidad de los datos en varios sistemas de almacenamiento simultáneamente. Técnicamente, la replicación se logra de dos maneras.
replicación sincrónica – se trata de copiar datos del sistema de almacenamiento principal al de respaldo, seguido de la confirmación obligatoria de ambos sistemas de almacenamiento de que los datos han sido registrados y confirmados. Es después de la confirmación por ambas partes (ambos sistemas de almacenamiento) que los datos se consideran registrados y se puede trabajar con ellos. Esto garantiza la identidad de los datos garantizada en todos los sistemas de almacenamiento que participan en la réplica.
Las ventajas de este método:
- Los datos son siempre idénticos en todos los sistemas de almacenamiento.
Contras:
- Alto costo de la solución (canales de comunicación rápidos, fibra óptica costosa, transceptores de onda larga, etc.)
- Restricciones de distancia (dentro de varias decenas de kilómetros)
- No hay protección contra la corrupción de datos lógicos (si los datos se corrompen (deliberada o accidentalmente) en el sistema de almacenamiento principal, se corromperán automática e instantáneamente en el de respaldo, ya que los datos son siempre idénticos (esa es la paradoja)
replicación asincrónica – esto también es copiar datos del sistema de almacenamiento principal al de respaldo, pero con cierto retraso y sin necesidad de confirmar la escritura en el otro lado. Puede trabajar con datos inmediatamente después de grabarlos en el sistema de almacenamiento principal, y en el sistema de almacenamiento de respaldo los datos estarán disponibles después de un tiempo. Por supuesto, en este caso la identidad de los datos no está garantizada en absoluto. Los datos en el sistema de almacenamiento de respaldo siempre están un poco "en el pasado".
Ventajas de la replicación asincrónica:
- Solución de bajo coste (cualquier canal de comunicación, óptica opcional)
- Sin restricciones de distancia
- En el sistema de almacenamiento de respaldo, los datos no se deterioran si se dañan en el principal (al menos por algún tiempo); si los datos se corrompen, siempre puede detener la réplica para evitar la corrupción de datos en el sistema de almacenamiento de respaldo.
Contras:
- Los datos en diferentes centros de datos no siempre son idénticos
Por tanto, la elección del modo de replicación depende de los objetivos comerciales. Si es fundamental para usted que el centro de datos de respaldo contenga exactamente los mismos datos que el centro de datos principal (es decir, el requisito comercial para RPO = 0), entonces tendrá que desembolsar dinero y aceptar las limitaciones de un centro de datos sincrónico. réplica. Y si el retraso en el estado de los datos es aceptable o simplemente no hay dinero, entonces definitivamente debe utilizar el método asincrónico.
Resaltamos también por separado un modo (más precisamente, una topología) como metrocluster. En el modo metrocluster, se utiliza la replicación síncrona, pero, a diferencia de una réplica normal, un metrocluster permite que ambos sistemas de almacenamiento funcionen en modo activo. Aquellos. no hay una separación entre los centros de datos activos y en espera. Las aplicaciones funcionan simultáneamente con dos sistemas de almacenamiento, que están ubicados físicamente en diferentes centros de datos. Los tiempos de inactividad en caso de accidente en una topología de este tipo son muy pequeños (RTO, normalmente minutos). En este artículo no consideraremos nuestra implementación del metrocluster, ya que este es un tema muy amplio y espacioso, por lo que le dedicaremos un próximo artículo aparte, a continuación de este.
Además, muy a menudo, cuando hablamos de replicación utilizando sistemas de almacenamiento, muchas personas tienen una pregunta razonable: > “Muchas aplicaciones tienen sus propias herramientas de replicación, ¿por qué utilizar la replicación en sistemas de almacenamiento? ¿Es mejor o peor?
No hay una respuesta clara aquí, así que aquí están los argumentos a favor y en contra:
Argumentos a favor de la replicación del almacenamiento:
- Simplicidad de la solución. Con una sola herramienta, puede replicar todo su conjunto de datos, independientemente del tipo de carga y la aplicación. Si utiliza una réplica de aplicaciones, deberá configurar cada aplicación por separado. Si hay más de 2, entonces esto requiere mucha mano de obra y es costoso (la replicación de aplicaciones generalmente requiere una licencia separada y no gratuita para cada aplicación. Pero hablaremos de eso más adelante).
- Puede replicar cualquier cosa (cualquier aplicación, cualquier dato) y siempre será coherente. Muchas (la mayoría) de las aplicaciones no tienen capacidades de replicación y las réplicas del sistema de almacenamiento son la única forma de brindar protección contra desastres.
- No es necesario pagar de más por la funcionalidad de replicación de aplicaciones. Por regla general, no es barato, al igual que las licencias para una réplica del sistema de almacenamiento. Pero debe pagar una licencia para la replicación del almacenamiento una vez y se debe comprar una licencia para la réplica de la aplicación para cada aplicación por separado. Si hay muchas aplicaciones de este tipo, entonces cuesta un centavo y el costo de las licencias para la replicación del almacenamiento se convierte en una gota en el océano.
Argumentos EN CONTRA de la replicación del almacenamiento:
- La réplica a través de aplicaciones tiene más funcionalidad desde el punto de vista de las propias aplicaciones, la aplicación conoce mejor sus datos (obviamente), por lo que hay más opciones para trabajar con ellas.
- Los fabricantes de algunas aplicaciones no garantizan la coherencia de sus datos si la replicación se realiza mediante herramientas de terceros. *
* - tesis controvertida. Por ejemplo, un conocido fabricante de DBMS ha estado declarando oficialmente durante mucho tiempo que su DBMS sólo puede replicarse normalmente utilizando sus medios, y que el resto de la replicación (incluidos los sistemas de almacenamiento) "no es cierto". Pero la vida ha demostrado que no es así. Lo más probable (pero esto no es seguro) es que este no sea el intento más honesto de vender más licencias a los clientes.
Como resultado, en la mayoría de los casos, la replicación desde el sistema de almacenamiento es mejor, porque Esta es una opción más simple y menos costosa, pero hay casos complejos en los que se necesita una funcionalidad de aplicación específica y es necesario trabajar con replicación a nivel de aplicación.
Terminamos con la teoría, ahora practicamos.
Configuraremos la réplica en nuestro laboratorio. En condiciones de laboratorio, emulamos dos centros de datos (de hecho, dos racks adyacentes que parecían estar en edificios diferentes). El stand consta de dos sistemas de almacenamiento Engine N2, que están conectados entre sí mediante cables ópticos. Un servidor físico que ejecuta Windows Server 2016 está conectado a ambos sistemas de almacenamiento mediante Ethernet de 10 Gb. El stand es bastante sencillo, pero esto no cambia la esencia.
Esquemáticamente se ve así:
Lógicamente, la replicación se organiza de la siguiente manera:
Ahora veamos la funcionalidad de replicación que tenemos ahora.
Se admiten dos modos: asíncrono y síncrono. Es lógico que el modo síncrono esté limitado por la distancia y el canal de comunicación. En particular, el modo síncrono requiere el uso de fibra como física y 10 Gigabit Ethernet (o superior).
La distancia admitida para la replicación síncrona es de 40 kilómetros, el valor de retraso del canal óptico entre centros de datos es de hasta 2 milisegundos. En general, funcionará con grandes retrasos, pero luego habrá fuertes desaceleraciones durante la grabación (lo cual también es lógico), por lo que si planeas una replicación sincrónica entre centros de datos, debes verificar la calidad de la óptica y los retrasos.
Los requisitos para la replicación asincrónica no son tan serios. Más precisamente, no existen en absoluto. Cualquier conexión Ethernet que funcione servirá.
Actualmente, el sistema de almacenamiento AERODISK ENGINE admite replicación para dispositivos de bloque (LUN) a través del protocolo Ethernet (sobre cobre u óptico). Para proyectos donde se requiere replicación a través de un tejido SAN sobre Fibre Channel, actualmente estamos agregando una solución adecuada, pero aún no está lista, por lo que en nuestro caso, solo Ethernet.
La replicación puede funcionar entre cualquier sistema de almacenamiento de la serie ENGINE (N1, N2, N4), desde sistemas junior hasta sistemas más antiguos y viceversa.
La funcionalidad de ambos modos de replicación es completamente idéntica. A continuación se muestran más detalles sobre lo que está disponible:
- Replicación “one to one” o “one to one”, es decir, la versión clásica con dos centros de datos, el principal y el de respaldo
- La replicación es "uno a muchos" o "uno a muchos", es decir Un LUN se puede replicar en varios sistemas de almacenamiento a la vez.
- Activar, desactivar e “invertir” la replicación, respectivamente, para habilitar, deshabilitar o cambiar la dirección de la replicación.
- La replicación está disponible para grupos RDG (Raid Distributed Group) y DDP (Dynamic Disk Pool). Sin embargo, los LUN de un grupo de RDG solo se pueden replicar en otro RDG. Lo mismo con DDP.
Hay muchas más funciones pequeñas, pero no tiene sentido enumerarlas; las mencionaremos a medida que configuremos.
Configurar la replicación
El proceso de configuración es bastante sencillo y consta de tres etapas.
- Configuración de red
- Configuración de almacenamiento
- Configuración de reglas (conexiones) y mapeo
Un punto importante al configurar la replicación es que las dos primeras etapas deben repetirse en el sistema de almacenamiento remoto, la tercera etapa, solo en el principal.
Configurar recursos de red
El primer paso es configurar los puertos de red a través de los cuales se transmitirá el tráfico de replicación. Para hacer esto, debe habilitar los puertos y configurar sus direcciones IP en la sección Adaptadores de front-end.
Después de esto, necesitamos crear un grupo (en nuestro caso RDG) y una IP virtual para replicación (VIP). VIP es una dirección IP flotante que está vinculada a dos direcciones "físicas" de controladores de almacenamiento (los puertos que acabamos de configurar). Esta será la interfaz de replicación principal. También puede operar no con VIP, sino con VLAN, si necesita trabajar con tráfico etiquetado.
El proceso de creación de una VIP para una réplica no es muy diferente de la creación de una VIP para E/S (NFS, SMB, iSCSI). En este caso, creamos una VIP normal (sin VLAN), pero asegúrese de indicar que es para replicación (sin este puntero no podremos agregar VIP a la regla en el siguiente paso).
El VIP debe estar en la misma subred que los puertos IP entre los que flota.
Repetimos estos ajustes en un sistema de almacenamiento remoto, con otra IP, por supuesto.
Los VIP de diferentes sistemas de almacenamiento pueden estar en diferentes subredes, lo principal es que existe enrutamiento entre ellos. En nuestro caso, este ejemplo se muestra exactamente (192.168.3.XX y 192.168.2.XX)
Esto completa la preparación de la parte de la red.
Configurar el almacenamiento
La configuración del almacenamiento para una réplica difiere de lo habitual sólo en que realizamos el mapeo a través de un menú especial "Mapeo de replicación". Por lo demás, todo es igual que con la configuración normal. Ahora, en orden.
En el grupo R02 creado anteriormente, debe crear un LUN. Creémoslo y llamémoslo LUN1.
También necesitamos crear el mismo LUN en un sistema de almacenamiento remoto de idéntico tamaño. Nosotros creamos. Para evitar confusiones, llamemos al LUN remoto LUN1R
Si necesitáramos tomar un LUN que ya existe, mientras configuramos la réplica, necesitaríamos desmontar este LUN productivo del host y simplemente crear un LUN vacío de idéntico tamaño en el sistema de almacenamiento remoto.
La configuración del almacenamiento está completa, pasemos a crear una regla de replicación.
Configurar reglas de replicación o enlaces de replicación
Luego de crear LUN en el sistema de almacenamiento, que será el principal en este momento, configuramos la regla de replicación LUN1 en el sistema de almacenamiento 1 a LUN1R en el sistema de almacenamiento 2.
La configuración se realiza en el menú “Replicación remota”.
Creemos una regla. Para hacer esto, debe especificar el destinatario de la réplica. Allí también configuramos el nombre de la conexión y el tipo de replicación (síncrona o asíncrona).
En el campo “sistemas remotos” añadimos nuestro sistema de almacenamiento2. Para agregar, debe usar los sistemas de almacenamiento IP de administración (MGR) y el nombre del LUN remoto en el que realizaremos la replicación (en nuestro caso, LUN1R). Las IP de control son necesarias solo en la etapa de agregar una conexión; el tráfico de replicación no se transmitirá a través de ellas; para esto se utilizará la VIP previamente configurada.
Ya en esta etapa podemos agregar más de un sistema remoto para la topología "uno a muchos": haga clic en el botón "agregar nodo", como en la figura siguiente.
En nuestro caso solo existe un sistema remoto, por lo que nos limitamos a este.
La regla está lista. Tenga en cuenta que se agrega automáticamente en todos los participantes de la replicación (en nuestro caso hay dos). Puede crear tantas reglas como desee, para cualquier número de LUN y en cualquier dirección. Por ejemplo, para equilibrar la carga, podemos replicar parte de los LUN del sistema de almacenamiento 1 al sistema de almacenamiento 2, y la otra parte, por el contrario, del sistema de almacenamiento 2 al sistema de almacenamiento 1.
Sistema de almacenamiento1. Inmediatamente después de la creación, comenzó la sincronización.
Sistema de almacenamiento2. Vemos la misma regla, pero la sincronización ya finalizó.
LUN1 en el sistema de almacenamiento 1 tiene la función principal, es decir, está activo. LUN1R en el sistema de almacenamiento 2 tiene la función de Secundario, es decir, está en espera en caso de que falle el sistema de almacenamiento 1.
Ahora podemos conectar nuestro LUN al host.
Nos conectaremos vía iSCSI, aunque también se puede hacer vía FC. Configurar el mapeo a través de iSCSI LUN en una réplica prácticamente no difiere del escenario habitual, por lo que no lo consideraremos en detalle aquí. En todo caso, este proceso se describe en el artículo "".
La única diferencia es que creamos el mapeo en el menú "Mapeo de replicación".
Configuramos el mapeo y le entregamos el LUN al host. El anfitrión vio el LUN.
Lo formateamos en un sistema de archivos local.
Eso es todo, la configuración está completa. Las pruebas vendrán después.
pruebas
Probaremos tres escenarios principales.
- Cambio de rol regular Secundario > Primario. Es necesario un cambio de roles regular en caso de que, por ejemplo, necesitemos realizar algunas operaciones preventivas en el centro de datos principal y durante este tiempo, para que los datos estén disponibles, transfiramos la carga al centro de datos de respaldo.
- Cambio de rol de emergencia Secundario > Primario (falla del centro de datos). Este es el escenario principal para el cual existe la replicación, que puede ayudar a sobrevivir a una falla total del centro de datos sin detener a la empresa durante un período prolongado.
- Desglose de canales de comunicación entre centros de datos. Verificar el correcto comportamiento de dos sistemas de almacenamiento en condiciones donde por alguna razón el canal de comunicación entre los centros de datos no está disponible (por ejemplo, una excavadora cavó en el lugar equivocado y rompió la óptica oscura).
Primero, comenzaremos a escribir datos en nuestro LUN (escribir archivos con datos aleatorios). Inmediatamente vemos que se está utilizando el canal de comunicación entre los sistemas de almacenamiento. Esto es fácil de entender si abre el monitoreo de carga de los puertos responsables de la replicación.
Ambos sistemas de almacenamiento ahora tienen datos “útiles”, podemos comenzar la prueba.
Por si acaso, veamos las sumas hash de uno de los archivos y escribámoslas.
Cambio de roles regular
La operación de cambiar roles (cambiar la dirección de replicación) se puede realizar con cualquier sistema de almacenamiento, pero aún necesitará ir a ambos, ya que deberá deshabilitar el mapeo en Primario y habilitarlo en Secundario (que se convertirá en Primario). ).
Quizás ahora surja una pregunta razonable: ¿por qué no automatizar esto? La respuesta es: es simple, la replicación es un medio simple de resiliencia ante desastres, basado únicamente en operaciones manuales. Para automatizar estas operaciones existe el modo metrocluster, está totalmente automatizado, pero su configuración es mucho más complicada. Escribiremos sobre la configuración de un metrocluster en el próximo artículo.
En el sistema de almacenamiento principal, desactivamos el mapeo para garantizar que se detenga la grabación.
Luego, en uno de los sistemas de almacenamiento (no importa, principal o de respaldo), en el menú "Replicación remota", seleccione nuestra conexión REPL1 y haga clic en "Cambiar rol".
Después de unos segundos, LUN1R (sistema de almacenamiento de respaldo) se convierte en Primario.
Mapeamos LUN1R con el sistema de almacenamiento2.
Después de esto, nuestra unidad E: se conecta automáticamente al host, solo que esta vez “llegó” desde LUN1R.
Por si acaso, comparamos las sumas hash.
Idénticamente. Prueba aprobada.
Conmutación por error. Fallo del centro de datos
Por el momento, el sistema de almacenamiento principal después del cambio regular es el sistema de almacenamiento 2 y LUN1R, respectivamente. Para emular un accidente, apagaremos ambos controladores de almacenamiento2.
Ya no hay acceso a él.
Veamos qué sucede en el sistema de almacenamiento 1 (el de respaldo en este momento).
Vemos que el LUN primario (LUN1R) no está disponible. Apareció un mensaje de error en los registros, en el panel de información y también en la propia regla de replicación. En consecuencia, los datos del anfitrión no están disponibles actualmente.
Cambie la función de LUN1 a Primaria.
Estoy haciendo un mapeo al host.
Asegúrese de que la unidad E aparezca en el host.
Comprobamos el hash.
Todo esta bien. El sistema de almacenamiento sobrevivió con éxito a la caída del centro de datos, que estaba activo. El tiempo aproximado que dedicamos a conectar la “inversión” de replicación y conectar el LUN desde el centro de datos de respaldo fue de aproximadamente 3 minutos. Está claro que en la producción real todo es mucho más complicado y, además de las acciones con los sistemas de almacenamiento, es necesario realizar muchas más operaciones en la red, en los hosts y en las aplicaciones. Y en la vida este período de tiempo será mucho más largo.
Aquí me gustaría escribir que todo, la prueba se ha completado con éxito, pero no nos apresuremos. El sistema de almacenamiento principal está “mentido”, sabemos que cuando “cayó” estaba en el rol Primario. ¿Qué pasa si de repente se enciende? Habrá dos roles primarios, ¿lo que equivale a corrupción de datos? Comprobémoslo ahora.
De repente encendamos el sistema de almacenamiento subyacente.
Se carga durante unos minutos y luego vuelve al servicio tras una breve sincronización, pero en el rol de Secundario.
Todo bien. El cerebro dividido no sucedió. Pensamos en esto, y siempre después de una caída el sistema de almacenamiento pasa al rol de Secundario, independientemente del rol que cumplió “durante la vida”. Ahora podemos decir con certeza que la prueba de falla del centro de datos fue exitosa.
Fallo de los canales de comunicación entre centros de datos.
La tarea principal de esta prueba es asegurarse de que el sistema de almacenamiento no comience a actuar de manera extraña si pierde temporalmente los canales de comunicación entre dos sistemas de almacenamiento y luego vuelve a aparecer.
Entonces. Desconectamos los cables entre los sistemas de almacenamiento (imaginemos que fueron excavados por una excavadora).
En Primaria vemos que no hay conexión con Secundaria.
En Secundaria vemos que no hay conexión con Primaria.
Todo funciona bien y seguimos escribiendo datos en el sistema de almacenamiento principal, es decir, se garantiza que serán diferentes al de respaldo, es decir, se han “separado”.
En unos minutos “reparamos” el canal de comunicación. Tan pronto como los sistemas de almacenamiento se ven, la sincronización de datos se activa automáticamente. Aquí no se requiere nada del administrador.
Después de un tiempo, se completa la sincronización.
Se restableció la conexión, la pérdida de los canales de comunicación no provocó ninguna situación de emergencia y, tras el encendido, la sincronización se realizó automáticamente.
Hallazgos
Analizamos la teoría: qué se necesita y por qué, dónde están los pros y los contras. Luego configuramos la replicación sincrónica entre dos sistemas de almacenamiento.
A continuación, se llevaron a cabo pruebas básicas de conmutación normal, falla del centro de datos y falla del canal de comunicación. En todos los casos, el sistema de almacenamiento funcionó bien. No hay pérdida de datos y las operaciones administrativas se mantienen al mínimo para un escenario manual.
La próxima vez complicaremos la situación y mostraremos cómo funciona toda esta lógica en un metrocluster automatizado en modo activo-activo, es decir, cuando ambos sistemas de almacenamiento son primarios y el comportamiento en caso de fallas del sistema de almacenamiento está completamente automatizado.
Por favor escriba sus comentarios, estaremos encantados de recibir críticas sólidas y consejos prácticos.
Hasta la próxima vez.
Fuente: habr.com