¡Hola lectores de Habr! En el último artículo, hablamos sobre un medio simple de recuperación ante desastres en los sistemas de almacenamiento AERODISK ENGINE: la replicación. En este artículo, nos sumergiremos en un tema más complejo e interesante: un metrocluster, es decir, una herramienta automatizada de protección contra desastres para dos centros de datos que permite que los centros de datos funcionen en modo activo-activo. Contaremos, mostraremos, romperemos y arreglaremos.
Como siempre, al comienzo de la teoría
Un metrocluster es un cluster espaciado en varios sitios dentro de una ciudad o distrito. La palabra "clúster" nos sugiere claramente que el complejo está automatizado, es decir, la conmutación de los nodos del clúster en caso de fallas (conmutación por error) se produce automáticamente.
Aquí es donde radica la principal diferencia entre un metrocluster y la replicación regular. Automatización de operaciones. Es decir, ante determinadas incidencias (fallo del centro de datos, rotura de canales, etc.), el sistema de almacenamiento realizará de forma autónoma las acciones necesarias para mantener la disponibilidad de los datos. Cuando se utilizan réplicas normales, el administrador realiza estas acciones total o parcialmente de forma manual.
¿Para qué sirve?
El objetivo principal que persiguen los clientes que utilizan ciertas implementaciones de metrocluster es minimizar el RTO (objetivo de tiempo de recuperación). Es decir, minimizar el tiempo de recuperación de los servicios TI tras un fallo. Si utiliza la replicación convencional, el tiempo de recuperación siempre será mayor que el tiempo de recuperación con un clúster metropolitano. ¿Por qué? Muy simple. El administrador debe estar en el lugar de trabajo y cambiar la replicación manualmente, mientras que el clúster metropolitano lo hace automáticamente.
Si no tiene un administrador de guardia dedicado que no duerma, no coma, no fume ni se enferme, pero que observe el estado del sistema de almacenamiento las 24 horas del día, entonces no hay forma de garantizar que el administrador lo haga. estar disponible para el cambio manual durante una falla.
En consecuencia, el RTO en ausencia de un clúster metropolitano o un administrador inmortal del nivel 99 del servicio de servicio de los administradores será igual a la suma del tiempo de conmutación de todos los sistemas y el período máximo de tiempo después del cual se garantiza que el administrador empezar a trabajar con el sistema de almacenamiento y los sistemas relacionados.
Por lo tanto, llegamos a la conclusión obvia de que se debe usar el metrocluster si el requisito de RTO es de minutos, no de horas o días, es decir, cuando en caso de la caída más terrible del centro de datos, el departamento de TI debe proporcionar el negocio con tiempo para restaurar el acceso a los servicios de TI en minutos o incluso segundos.
Como funciona?
En el nivel inferior, el metrocluster utiliza el mecanismo de replicación de datos sincrónicos que describimos en el artículo anterior (ver más abajo). ). Dado que la replicación es síncrona, los requisitos para ello son adecuados, o más bien:
- fibra como física, ethernet de 10 gigabits (o superior);
- la distancia entre los centros de datos no supera los 40 kilómetros;
- retraso del canal óptico entre centros de datos (entre sistemas de almacenamiento) hasta 5 milisegundos (óptimamente 2).
Todos estos requisitos son de carácter consultivo, es decir, el clúster metro funcionará aunque no se cumplan estos requisitos, pero hay que entender que las consecuencias del incumplimiento de estos requisitos equivalen a ralentizar el funcionamiento de ambos sistemas de almacenamiento. en el conglomerado de metro.
Por lo tanto, se utiliza una réplica síncrona para transferir datos entre sistemas de almacenamiento, pero ¿cómo cambian automáticamente las réplicas y, lo que es más importante, cómo evitar el cerebro dividido? Para hacer esto, en el nivel superior, se utiliza una entidad adicional: el árbitro.
¿Cómo trabaja un árbitro y cuál es su tarea?
El árbitro es una pequeña máquina virtual o un clúster de hardware que debe iniciarse en un tercer sitio (por ejemplo, en una oficina) y brindar acceso al almacenamiento a través de ICMP y SSH. Después de comenzar, el árbitro debe establecer la IP y luego especificar su dirección desde el lado del almacenamiento, además de las direcciones de los controladores remotos que participan en el clúster metro. Después de eso, el árbitro está listo para comenzar.
El árbitro supervisa constantemente todos los sistemas de almacenamiento en el clúster metropolitano y, en caso de que un sistema de almacenamiento en particular no esté disponible, después de la confirmación de la falta de disponibilidad de otro miembro del clúster (uno de los sistemas de almacenamiento "en vivo"), decide iniciar el procedimiento para cambiar las reglas de replicación y el mapeo.
Un punto muy importante. El árbitro siempre debe estar ubicado en un sitio diferente a aquellos en los que se encuentran los sistemas de almacenamiento, es decir, ni en el CPD 1, donde se encuentra el almacenamiento 1, ni en el CPD 2, donde se encuentra instalado el almacenamiento 2.
¿Por qué? Porque solo de esta manera el árbitro, con la ayuda de uno de los sistemas de almacenamiento supervivientes, puede determinar sin ambigüedades y con precisión la caída de cualquiera de los dos sitios donde están instalados los sistemas de almacenamiento. Cualquier otra forma de colocar un árbitro puede resultar en un cerebro dividido.
Ahora profundicemos en los detalles del trabajo del árbitro.
Varios servicios se ejecutan en el árbitro que sondea constantemente todos los controladores de almacenamiento. Si el resultado de la encuesta difiere del anterior (disponible/no disponible), se escribe en una pequeña base de datos que también funciona en el árbitro.
Considere la lógica del árbitro con más detalle.
Paso 1. Determinación de indisponibilidad. Un evento que indica una falla del sistema de almacenamiento es la ausencia de un ping de ambos controladores del mismo sistema de almacenamiento durante 5 segundos.
Paso 2. Inicio del procedimiento de cambio. Después de que el árbitro se da cuenta de que uno de los sistemas de almacenamiento no está disponible, envía una solicitud al sistema de almacenamiento "activo" para asegurarse de que el sistema de almacenamiento "inactivo" esté realmente inactivo.
Después de recibir dicho comando del árbitro, el segundo sistema de almacenamiento (activo) comprueba adicionalmente la disponibilidad del primer sistema de almacenamiento caído y, si no, envía al árbitro la confirmación de su suposición. SHD, de hecho, no está disponible.
Después de recibir dicha confirmación, el árbitro inicia un procedimiento remoto para cambiar la replicación y generar el mapeo en aquellas réplicas que estaban activas (primarias) en el sistema de almacenamiento caído, y envía un comando al segundo sistema de almacenamiento para convertir estas réplicas de secundarias en primarias. y levante el mapeo. Bueno, el segundo sistema de almacenamiento, respectivamente, realiza estos procedimientos, luego de lo cual brinda acceso a los LUN perdidos desde sí mismo.
¿Por qué se necesita una verificación adicional? Para quórum. Es decir, la mayoría del número total impar (3) de miembros del clúster debe confirmar la caída de uno de los nodos del clúster. Solo entonces esta decisión será exactamente correcta. Esto es necesario para evitar una conmutación errónea y, en consecuencia, un cerebro dividido.
El paso 2 demora entre 5 y 10 segundos, por lo que, teniendo en cuenta el tiempo requerido para determinar la indisponibilidad (5 segundos), dentro de los 10 a 15 segundos posteriores a la falla, los LUN con un sistema de almacenamiento caído estarán automáticamente disponibles para trabajar con Live. almacenamiento.
Está claro que para evitar romper la conexión con los hosts, también debe cuidar la configuración correcta de los tiempos de espera en los hosts. El tiempo de espera recomendado es de al menos 30 segundos. Esto evita que el host interrumpa la conexión con el almacenamiento durante una carga de conmutación por error y puede garantizar que no haya interrupciones de E/S.
Espere un segundo, resulta que si todo está bien con el clúster metropolitano, ¿por qué necesitamos una replicación regular?
De hecho, no todo es tan simple.
Considere los pros y los contras del metrocluster
Entonces, nos dimos cuenta de que las ventajas obvias del metrocluster en comparación con la replicación convencional son:
- Automatización completa, que garantiza un tiempo de recuperación mínimo en caso de desastre;
- Y eso es :-).
Y ahora, atención, contras:
- Costo de la solución. Aunque el metrocluster en los sistemas de Aerodisk no requiere licencias adicionales (se usa la misma licencia que para la réplica), el costo de la solución seguirá siendo incluso más alto que el uso de la replicación síncrona. Deberá implementar todos los requisitos para una réplica síncrona, además de los requisitos para el clúster metropolitano asociado con la conmutación adicional y el sitio adicional (consulte la planificación del clúster metropolitano);
- La complejidad de la decisión. Un metrocluster es mucho más complejo que una réplica regular y requiere mucha más atención y esfuerzo para planificar, configurar y documentar.
Al final Metrocluster es sin duda una solución muy tecnológica y buena cuando realmente necesita proporcionar RTO en segundos o minutos. Pero si no existe tal tarea, y RTO en horas está bien para los negocios, entonces no tiene sentido disparar gorriones desde un cañón. La réplica habitual de trabajadores y campesinos es suficiente, ya que el clúster metropolitano causará costos adicionales y complicará la infraestructura de TI.
Planificación de clústeres de metro
Esta sección no pretende ser un tutorial completo sobre el diseño de clústeres metropolitanos, sino que solo muestra las direcciones principales que deben seguirse si decide construir un sistema de este tipo. Por lo tanto, durante la implementación real del clúster metropolitano, asegúrese de involucrar al fabricante del sistema de almacenamiento (es decir, a nosotros) y otros sistemas relacionados para su consulta.
Plataformas
Como se indicó anteriormente, un clúster metropolitano requiere un mínimo de tres sitios. Dos centros de datos, donde funcionarán los sistemas de almacenamiento y los sistemas relacionados, así como un tercer sitio, donde funcionará el árbitro.
La distancia recomendada entre centros de datos no supera los 40 kilómetros. Es muy probable que una mayor distancia cause retrasos adicionales, que son muy indeseables en el caso de un clúster metropolitano. Recuerde que los retrasos deben ser de hasta 5 milisegundos, aunque es conveniente mantenerse dentro de los 2.
También se recomienda verificar los retrasos durante el proceso de planificación. Cualquier proveedor más o menos adulto que suministre fibra entre centros de datos puede organizar un control de calidad con bastante rapidez.
En cuanto a las demoras para el árbitro (es decir, entre el tercer sitio y los dos primeros), el umbral de demora recomendado es de hasta 200 milisegundos, es decir, una conexión VPN corporativa regular a través de Internet servirá.
Conmutación y red
A diferencia del esquema de replicación, en el que es suficiente conectar sistemas de almacenamiento de diferentes sitios, el esquema de clúster metropolitano requiere conectar hosts a ambos sistemas de almacenamiento en diferentes sitios. Para que quede más claro cuál es la diferencia, ambos esquemas se enumeran a continuación.
Como puede ver en el diagrama, tenemos hosts del sitio 1 que analizan tanto el almacenamiento 1 como el almacenamiento 2. Además, por el contrario, los hosts del sitio 2 analizan tanto el almacenamiento 2 como el almacenamiento 1. Es decir, cada host ve ambos sistemas de almacenamiento. Este es un requisito previo para el funcionamiento del metrocluster.
Por supuesto, no es necesario llevar cada host con un cable óptico a otro centro de datos, no habrá suficientes puertos y cables. Todas estas conexiones deben realizarse a través de conmutadores Ethernet 10G+ o FibreChannel 8G+ (FC solo para conectar hosts y almacenamiento para IO, el canal de replicación actualmente solo está disponible a través de IP (Ethernet 10G+).
Ahora unas pocas palabras sobre la topología de la red. Un punto importante es la correcta configuración de las subredes. Debe definir inmediatamente varias subredes para los siguientes tipos de tráfico:
- Subred para la replicación, sobre la cual se sincronizarán los datos entre los sistemas de almacenamiento. Puede haber varios de ellos, en este caso no importa, todo depende de la topología de red actual (ya implementada). Si hay dos de ellos, entonces, obviamente, se debe configurar el enrutamiento entre ellos;
- Subredes de almacenamiento a través de las cuales los hosts accederán a los recursos de almacenamiento (si es iSCSI). Debe haber una subred de este tipo en cada centro de datos;
- Subredes de control, es decir, tres subredes enrutables en tres sitios desde los que se administra el almacenamiento, y el árbitro también se encuentra allí.
Aquí no consideramos las subredes para acceder a los recursos del host, ya que dependen en gran medida de las tareas.
Separar el tráfico diferente en subredes diferentes es extremadamente importante (es especialmente importante separar la réplica de la E/S), porque si mezcla todo el tráfico en una subred "gruesa", entonces este tráfico será imposible de administrar, y en las condiciones de dos centros de datos aún pueden causar varias opciones de colisión de red. No profundizaremos en este tema en el marco de este artículo, ya que puede leer sobre la planificación de una red extendida entre centros de datos sobre los recursos de los fabricantes de equipos de red, donde esto se describe con gran detalle.
Configuración del árbitro
El árbitro debe proporcionar acceso a todas las interfaces de control del sistema de almacenamiento a través de los protocolos ICMP y SSH. También debe pensar en la tolerancia a fallas del árbitro. Aquí hay un matiz.
La conmutación por error del árbitro es muy deseable, pero no obligatoria. ¿Y qué pasa si el árbitro falla en el momento equivocado?
- El funcionamiento del metrocluster en el modo normal no cambiará, porque arbtir no afecta en absoluto el funcionamiento del metrocluster en modo normal (su tarea es cambiar la carga entre los centros de datos a tiempo)
- Al mismo tiempo, si el árbitro por una razón u otra cae y "duerme" el accidente en el centro de datos, no se producirá ningún cambio, porque no habrá nadie para dar los comandos de cambio necesarios y organizar el quórum. En este caso, el clúster de metro se convertirá en un esquema de replicación regular, que deberá cambiarse manualmente durante un desastre, lo que afectará el RTO.
¿Qué se sigue de esto? Si realmente necesita proporcionar un RTO mínimo, debe garantizar la tolerancia a fallas del árbitro. Hay dos opciones para esto:
- Ejecute una máquina virtual con un árbitro en un hipervisor tolerante a fallas, ya que todos los hipervisores para adultos admiten la tolerancia a fallas;
- Si en el tercer sitio (en una oficina condicional) es demasiado flojo instalar un clúster normal y no existe un clúster de hipervisores, entonces proporcionamos una versión de hardware del árbitro, que se fabrica en una caja de 2U, en la que dos funcionan los servidores x-86 ordinarios y que pueden sobrevivir a una falla local.
Recomendamos enfáticamente que asegure la tolerancia a fallas del árbitro, a pesar de que el clúster metropolitano no lo necesita en modo normal. Pero como muestran tanto la teoría como la práctica, si construye una infraestructura tolerante a desastres verdaderamente confiable, entonces es mejor ir a lo seguro. Es mejor protegerse a usted y a su negocio de la "ley de la mezquindad", es decir, de la falla tanto del árbitro como de uno de los sitios donde se encuentra el sistema de almacenamiento.
Arquitectura de soluciones
Teniendo en cuenta los requisitos anteriores, obtenemos la siguiente arquitectura de solución general.
Los LUN deben distribuirse uniformemente entre los dos sitios para evitar una congestión severa. Al mismo tiempo, al dimensionar en ambos centros de datos, es necesario proporcionar no solo el doble de volumen (que es necesario para almacenar datos simultáneamente en dos sistemas de almacenamiento), sino también el doble de rendimiento en IOPS y MB / s para evitar degradación de las aplicaciones en caso de falla de uno de los centros de datos - ov.
Por separado, observamos que con el enfoque adecuado para dimensionar (es decir, siempre que hayamos proporcionado los límites superiores adecuados de IOPS y MB / s, así como los recursos de CPU y RAM necesarios), si uno de los sistemas de almacenamiento en el clúster metropolitano falla, no habrá una caída grave en el rendimiento de las condiciones de trabajo temporal en un sistema de almacenamiento.
Esto se explica por el hecho de que en condiciones de dos sitios trabajando simultáneamente, ejecutar la replicación síncrona "come" la mitad del rendimiento de escritura, ya que cada transacción debe escribirse en dos sistemas de almacenamiento (similar a RAID-1/10). Por lo tanto, si uno de los sistemas de almacenamiento falla, el efecto de la replicación desaparece temporalmente (hasta que el sistema de almacenamiento fallido se recupera) y obtenemos un aumento del doble en el rendimiento de escritura. Después de que los LUN del sistema de almacenamiento fallido se reiniciaron en el sistema de almacenamiento en funcionamiento, este doble aumento desaparece debido al hecho de que hay una carga de los LUN de otro sistema de almacenamiento y volvemos al mismo nivel de rendimiento que teníamos antes del “caer”, pero solo dentro de la misma plataforma.
Con la ayuda de un dimensionamiento competente, es posible proporcionar condiciones en las que los usuarios no sientan la falla de todo el sistema de almacenamiento. Pero una vez más, esto requiere un dimensionamiento muy cuidadoso, que, por cierto, puedes contactarnos gratis :-).
Configuración de un clúster metropolitano
La configuración de un clúster metropolitano es muy similar a la configuración de la replicación regular, que describimos en . Así que centrémonos en las diferencias. Montamos un banco en el laboratorio basado en la arquitectura anterior, solo en la versión mínima: dos sistemas de almacenamiento conectados a través de Ethernet 10G entre sí, dos conmutadores 10G y un host que mira a través de los conmutadores a ambos sistemas de almacenamiento con puertos 10G. El árbitro se ejecuta en una máquina virtual.
Al configurar la IP virtual (VIP) para una réplica, debe seleccionar el tipo de VIP: para un clúster metropolitano.
Creó dos enlaces de replicación para dos LUN y los distribuyó en dos sistemas de almacenamiento: LUN TEST Primario en almacenamiento1 (conexión METRO), LUN TEST2 Primario para almacenamiento2 (conexión METRO2).
Para ellos, configuramos dos objetivos idénticos (en nuestro caso, iSCSI, pero también se admite FC, la lógica de configuración es la misma).
almacenamiento1:
almacenamiento2:
Para los enlaces de replicación, se realizaron asignaciones en cada sistema de almacenamiento.
almacenamiento1:
almacenamiento2:
Configuramos multipath y se lo presentamos al host.
Configuración de un árbitro
No necesita hacer nada especial con el árbitro en sí, solo necesita encenderlo en el tercer sitio, configurar su IP y configurar el acceso a él a través de ICMP y SSH. La propia configuración se realiza desde los propios sistemas de almacenamiento. Al mismo tiempo, es suficiente configurar el árbitro una vez en cualquiera de los controladores de almacenamiento en el clúster metro, esta configuración se distribuirá a todos los controladores automáticamente.
En Replicación remota>> Metrocluster (en cualquier controlador)>> botón Configurar.
Ingresamos la IP del árbitro, así como las interfaces de control de los dos controladores de almacenamiento remoto.
Después de eso, debe habilitar todos los servicios (botón "Reiniciar todo"). Si vuelve a configurar en el futuro, los servicios deben reiniciarse para que la configuración surta efecto.
Comprobamos que todos los servicios están funcionando.
Esto completa la configuración del metrocluster.
Prueba de choque
La prueba de choque en nuestro caso será bastante simple y rápida, ya que la funcionalidad de replicación (conmutación, consistencia, etc.) se consideró en . Por lo tanto, para probar la confiabilidad del clúster de metro, basta con que verifiquemos la automatización de la detección de accidentes, el cambio y la ausencia de pérdidas de escritura (paradas de E/S).
Para hacer esto, emulamos una falla completa de uno de los sistemas de almacenamiento apagando físicamente ambos controladores, luego de comenzar a copiar un archivo grande a un LUN, que debe activarse en otro sistema de almacenamiento.
Deshabilite un sistema de almacenamiento. En el segundo sistema de almacenamiento, vemos alertas y mensajes en los registros de que la conexión con el sistema vecino ha desaparecido. Si se configuran las notificaciones a través de la supervisión de SMTP o SNMP, se enviarán las notificaciones correspondientes al administrador.
Exactamente 10 segundos después (visto en ambas capturas de pantalla), el enlace de replicación METRO (el que era principal en el sistema de almacenamiento caído) se convirtió automáticamente en principal en el sistema de almacenamiento en funcionamiento. Usando el mapeo existente, LUN TEST permaneció disponible para el host, la grabación bajó un poco (dentro del 10 por ciento prometido), pero no se detuvo.
La prueba se completó con éxito.
Resumiendo
La implementación actual del metrocluster en los sistemas de almacenamiento AERODISK Engine N-series le permite resolver completamente los problemas en los que necesita eliminar o minimizar el tiempo de inactividad de los servicios de TI y garantizar su funcionamiento en modo 24/7/365 con costos laborales mínimos.
Puede decir, por supuesto, que todo esto es teoría, condiciones ideales de laboratorio, etc. PERO tenemos una serie de proyectos implementados en los que implementamos la funcionalidad de recuperación ante desastres y los sistemas funcionan perfectamente. Uno de nuestros clientes bastante conocidos, donde solo se utilizan dos sistemas de almacenamiento en una configuración tolerante a desastres, ya accedió a publicar información sobre el proyecto, por lo que en la siguiente parte hablaremos sobre la implementación de combate.
Gracias, esperando una discusión productiva.
Fuente: habr.com