Ola, lectores de Habr! No último artigo, falamos dun medio sinxelo de recuperación ante desastres nos sistemas de almacenamento AERODISK ENGINE: a replicación. Neste artigo, mergullaremos nun tema máis complexo e interesante: o metrocluster, é dicir, un medio de protección automatizada contra desastres para dous centros de datos, que permite que os centros de datos funcionen en modo activo-activo. Contámoschelo, mostrámolo, rompelo e arranxámolo.
Como de costume, primeiro a teoría
Un metrocluster é un cluster repartido por varios sitios dentro dunha cidade ou rexión. A palabra "clúster" indícanos claramente que o complexo está automatizado, é dicir, o cambio de nodos do clúster en caso de fallos ocorre automaticamente.
Aquí é onde reside a principal diferenza entre un metrocluster e a replicación regular. Automatización de operacións. É dicir, no caso de producirse determinadas incidencias (falla do centro de datos, canles rotas, etc.), o sistema de almacenamento realizará de forma independente as accións necesarias para manter a dispoñibilidade dos datos. Cando se usan réplicas habituais, estas accións realízanas total ou parcialmente manualmente o administrador.
O que fai?
O obxectivo principal que perseguen os clientes cando usan determinadas implementacións de metrocluster é minimizar o RTO (Obxectivo de tempo de recuperación). É dicir, minimizar o tempo de recuperación dos servizos informáticos tras un fallo. Se utiliza a replicación regular, o tempo de recuperación sempre será maior que o tempo de recuperación cun metrocluster. Por que? Moi sinxelo. O administrador debe estar na súa mesa e cambiar a replicación manualmente, e o metrocluster faino automaticamente.
Se non tes un administrador dedicado de servizo que non dorme, non come, non fuma nin se enferma e observa o estado do sistema de almacenamento as 24 horas do día, non hai forma de garantir que o administrador estar dispoñible para a conmutación manual durante un fallo.
En consecuencia, RTO en ausencia dun metrocluster ou dun administrador inmortal do nivel 99 do servizo de administrador será igual á suma do tempo de conmutación de todos os sistemas e o período máximo de tempo despois do cal o administrador está garantido para comezar a traballar. con sistemas de almacenamento e sistemas relacionados.
Así, chegamos á conclusión obvia de que o metroclúster debería utilizarse se o requisito de RTO é de minutos, non de horas ou días, é dicir, cando no caso de que se produza o peor fallo do centro de datos, o departamento de TI debe proporcionar tempo á empresa. restaurar o acceso aos servizos de TI en minutos, ou mesmo segundos.
Como funciona isto?
No nivel inferior, o metrocluster usa un mecanismo para a replicación de datos síncrona, que describimos no artigo anterior (ver. ). Dado que a replicación é sincrónica, os requisitos para ela son correspondentes, ou mellor dito:
- fibra óptica como física, 10 gigabit Ethernet (ou superior);
- a distancia entre os centros de datos non supera os 40 quilómetros;
- o atraso da canle óptica entre centros de datos (entre sistemas de almacenamento) é de ata 5 milisegundos (de forma óptima 2).
Todos estes requisitos son de carácter consultivo, é dicir, o metroclúster funcionará aínda que estes requisitos non se cumpran, pero hai que entender que as consecuencias do incumprimento destes requisitos equivalen a unha ralentización do funcionamento de ambos os sistemas de almacenamento en o metrocluster.
Entón, unha réplica síncrona utilízase para transferir datos entre sistemas de almacenamento, e como se cambian automaticamente as réplicas e, o máis importante, como evitar a división do cerebro? Para iso, a un nivel superior, úsase unha entidade adicional: un árbitro.
Como funciona un árbitro e cal é a súa tarefa?
O árbitro é unha pequena máquina virtual ou un clúster de hardware que debe lanzarse nun terceiro sitio (por exemplo, nunha oficina) e proporcionar acceso ao sistema de almacenamento mediante ICMP e SSH. Despois do lanzamento, o árbitro debe configurar a IP e, a continuación, desde o lado do almacenamento indicar o seu enderezo, ademais dos enderezos dos controladores remotos que participan no metrocluster. Despois diso, o árbitro está preparado para traballar.
O árbitro supervisa constantemente todos os sistemas de almacenamento do metrocluster e se un determinado sistema de almacenamento non está dispoñible, despois de confirmar a non dispoñibilidade doutro membro do clúster (un dos sistemas de almacenamento "en vivo"), decide iniciar o procedemento para cambiar as regras de replicación. e cartografía.
Un punto moi importante. O árbitro deberá estar sempre situado nun lugar diferente a aquel no que se atopan os sistemas de almacenamento, é dicir, nin no centro de datos 1, onde está instalado o sistema de almacenamento 1, nin no centro de datos 2, onde está instalado o sistema de almacenamento 2.
Por que? Porque esta é a única forma en que un árbitro, coa axuda dun dos sistemas de almacenamento superviventes, pode determinar de forma inequívoca e precisa a caída de calquera dos dous sitios onde están instalados os sistemas de almacenamento. Calquera outro método de colocar un árbitro pode producir un cerebro dividido.
Agora imos mergullo nos detalles do traballo do árbitro.
O árbitro executa varios servizos que sondean constantemente todos os controladores de almacenamento. Se o resultado da enquisa difire do anterior (dispoñible/non dispoñible), entón rexístrase nunha pequena base de datos, que tamén funciona no árbitro.
Vexamos con máis detalle a lóxica do traballo do árbitro.
Paso 1: determina a non dispoñibilidade. Un evento de fallo do sistema de almacenamento é a ausencia de ping dos dous controladores do mesmo sistema de almacenamento nun prazo de 5 segundos.
Paso 2. Inicia o procedemento de cambio. Despois de que o árbitro se decatou de que un dos sistemas de almacenamento non está dispoñible, envía unha solicitude ao sistema de almacenamento "en vivo" para asegurarse de que o sistema de almacenamento "morto" está realmente morto.
Despois de recibir tal comando do árbitro, o segundo sistema de almacenamento (en directo) comproba ademais a dispoñibilidade do primeiro sistema de almacenamento caído e, se non está alí, envía ao árbitro a confirmación da súa suposición. O sistema de almacenamento realmente non está dispoñible.
Despois de recibir tal confirmación, o árbitro inicia un procedemento remoto para cambiar a replicación e aumentar a asignación naquelas réplicas que estaban activas (principais) no sistema de almacenamento caído e envía un comando ao segundo sistema de almacenamento para cambiar estas réplicas de secundaria a primaria e elevar mapeo. Ben, o segundo sistema de almacenamento, en consecuencia, realiza estes procedementos e, a continuación, proporciona acceso aos LUN perdidos desde si mesmo.
Por que é necesaria unha verificación adicional? Para quórum. É dicir, a maioría do número total impar (3) de membros do clúster debe confirmar a caída dun dos nodos do clúster. Só entón esta decisión será definitivamente correcta. Isto é necesario para evitar cambios erróneos e, en consecuencia, dividir o cerebro.
O paso de tempo 2 leva aproximadamente entre 5 e 10 segundos, polo que, tendo en conta o tempo necesario para determinar a non dispoñibilidade (5 segundos), dentro dos 10 - 15 segundos posteriores ao accidente, os LUN do sistema de almacenamento caído estarán dispoñibles automaticamente para traballar co directo. sistema de almacenamento.
Está claro que para evitar a perda de conexións cos hosts, tamén cómpre ter coidado de configurar correctamente os tempos de espera nos hosts. O tempo de espera recomendado é de polo menos 30 segundos. Isto evitará que o host corte a conexión ao sistema de almacenamento durante o cambio de carga en caso de desastre e pode garantir que non haxa interrupcións de E/S.
Agarda un segundo, resulta que se todo está tan ben co metrocluster, por que necesitamos unha replicación regular?
En realidade, non todo é tan sinxelo.
Consideremos os pros e os contras do metrocluster
Entón, decatámonos de que as vantaxes obvias do metrocluster en comparación coa replicación convencional son:
- Automatización total, garantindo un tempo mínimo de recuperación en caso de desastre;
- Iso é todo :-).
E agora, atención, os contras:
- Custo da solución. Aínda que o metroclúster dos sistemas Aerodisk non require licenzas adicionais (utilízase a mesma licenza que para a réplica), o custo da solución aínda será aínda maior que o uso da replicación síncrona. Deberá implementar todos os requisitos para unha réplica síncrona, ademais dos requisitos para o clúster de metro asociado con conmutación adicional e sitio adicional (consulte a planificación do clúster de metro);
- Complexidade da solución. O metrocluster é moito máis complexo que unha réplica normal, e require moita máis atención e esforzo para a planificación, configuración e documentación.
Finalmente. Metrocluster é certamente unha solución moi avanzada tecnoloxicamente e unha boa solución cando realmente necesitas proporcionar RTO en segundos ou minutos. Pero se non hai tal tarefa e RTO en horas está ben para os negocios, entón non ten sentido disparar gorrións desde un canón. A replicación obreiro-campesiña habitual é suficiente, xa que un clúster de metro provocará custos adicionais e complicación da infraestrutura informática.
Planificación de Metrocluster
Esta sección non pretende ser unha guía completa para o deseño de metrocluster, senón que só mostra as principais direccións que se deben elaborar se decide construír un sistema deste tipo. Polo tanto, cando se implemente un metroclúster, asegúrese de involucrar ao fabricante do sistema de almacenamento (é dicir, nós) e a outros sistemas relacionados para as consultas.
Sedes
Como se indicou anteriormente, un metrocluster require un mínimo de tres sitios. Dous centros de datos onde funcionarán os sistemas de almacenamento e os sistemas relacionados, así como un terceiro sitio onde traballará o árbitro.
A distancia recomendada entre centros de datos non é superior a 40 quilómetros. É moi probable que unha distancia maior cause atrasos adicionais, que son moi indesexables no caso dun clúster de metro. Lembrámosche que os atrasos deben ser de ata 5 milisegundos, aínda que é recomendable mantelos dentro de 2.
Recoméndase comprobar os atrasos tamén durante o proceso de planificación. Calquera provedor máis ou menos maduro que proporcione fibra óptica entre centros de datos pode organizar un control de calidade con bastante rapidez.
En canto aos atrasos ante o árbitro (é dicir, entre o terceiro sitio e os dous primeiros), o limiar de atraso recomendado é de ata 200 milisegundos, é dicir, é adecuada unha conexión VPN corporativa regular a través de Internet.
Conmutación e rede
A diferenza do esquema de replicación, onde é suficiente conectar sistemas de almacenamento de sitios diferentes, o esquema de metrocluster require conectar hosts con ambos sistemas de almacenamento en sitios diferentes. Para que quede máis claro cal é a diferenza, os dous esquemas móstranse a continuación.
Como se pode ver no diagrama, os nosos hosts do sitio 1 miran tanto o sistema de almacenamento 1 como o sistema de almacenamento 2. Ademais, pola contra, os hosts do sitio 2 miran tanto o sistema de almacenamento 2 como o sistema de almacenamento 1. É dicir, cada host ve os dous sistemas de almacenamento. Este é un requisito previo para o funcionamento do metrocluster.
Por suposto, non hai necesidade de conectar cada host cun cable óptico a outro centro de datos; ningún porto ou cable será suficiente. Todas estas conexións deben realizarse a través de conmutadores Ethernet 10G+ ou FibreChannel 8G+ (FC só é para conectar hosts e sistemas de almacenamento para IO, a canle de replicación só está dispoñible actualmente a través de IP (Ethernet 10G+).
Agora algunhas palabras sobre a topoloxía da rede. Un punto importante é a correcta configuración das subredes. É necesario definir inmediatamente varias subredes para os seguintes tipos de tráfico:
- A subrede de replicación sobre a que se sincronizarán os datos entre os sistemas de almacenamento. Pode haber varios deles, neste caso non importa, todo depende da topoloxía de rede actual (xa implementada). Se hai dous deles, obviamente hai que configurar o enrutamento entre eles;
- Subredes de almacenamento a través das cales os hosts accederán aos recursos de almacenamento (se é iSCSI). Debe haber unha subrede deste tipo en cada centro de datos;
- Subredes de control, é dicir, tres subredes enrutables en tres sitios desde os que se xestionan os sistemas de almacenamento, e alí tamén se sitúa o árbitro.
Non consideramos subredes para acceder aos recursos do host aquí, xa que dependen moito das tarefas.
Separar diferentes tráficos en diferentes subredes é extremadamente importante (é especialmente importante separar a réplica da E/S), porque se mestura todo o tráfico nunha subrede "grosa", entón este tráfico será imposible de xestionar, e as condicións de dous centros de datos, isto aínda pode causar diferentes opcións de colisión de rede. Non afondaremos nesta cuestión no marco deste artigo, xa que podes ler sobre a planificación dunha rede estendida entre centros de datos sobre os recursos dos fabricantes de equipos de rede, onde se describe con gran detalle.
Configuración do árbitro
O árbitro debe proporcionar acceso a todas as interfaces de xestión do sistema de almacenamento a través dos protocolos ICMP e SSH. Tamén debes pensar na seguridade do árbitro. Aquí hai un matiz.
A conmutación por fallo do árbitro é moi desexable, pero non é necesaria. Que pasa se o árbitro choca no momento equivocado?
- O funcionamento do metroclúster en modo normal non cambiará, porque arbtir non ten ningún efecto no funcionamento do metrocluster en modo normal (a súa tarefa é cambiar a carga entre os centros de datos de forma oportuna)
- Ademais, se o árbitro por un motivo ou outro cae e "durmi" nun accidente no centro de datos, non se producirá ningún cambio, porque non haberá ninguén que dea os comandos de cambio necesarios e organice un quórum. Neste caso, o metroclúster converterase nun esquema regular con replicación, que terá que cambiarse manualmente durante un desastre, o que afectará ao RTO.
Que se segue disto? Se realmente precisa garantir un RTO mínimo, debe asegurarse de que o árbitro é tolerante a fallos. Hai dúas opcións para iso:
- Inicie unha máquina virtual cun árbitro nun hipervisor tolerante a fallos, afortunadamente todos os hipervisores adultos admiten tolerancia a fallos;
- Se no terceiro sitio (nunha oficina convencional) é demasiado preguiceiro para instalar un clúster normal e non hai un clúster de hipervozor existente, fornecemos unha versión de hardware do árbitro, que está feita nunha caixa de 2U na que dous Os servidores x-86 funcionan e poden sobrevivir a un fallo local.
Recomendamos encarecidamente garantir a tolerancia a fallos do árbitro, a pesar de que o metrocluster non o necesita en modo normal. Pero como demostran tanto a teoría como a práctica, se constrúes unha infraestrutura a proba de desastres verdadeiramente fiable, entón é mellor xogar con seguridade. É mellor protexerse a si mesmo e á súa empresa da "lei da mesquindade", é dicir, da falla tanto do árbitro como dun dos sitios onde se atopa o sistema de almacenamento.
Arquitectura de solución
Tendo en conta os requisitos anteriores, obtemos a seguinte arquitectura xeral de solución.
Os LUN deben distribuírse uniformemente en dous sitios para evitar unha sobrecarga grave. Ao mesmo tempo, ao dimensionar en ambos os centros de datos, debe incluír non só o dobre volume (que é necesario para almacenar datos simultaneamente en dous sistemas de almacenamento), senón tamén o dobre rendemento en IOPS e MB/s para evitar a degradación da aplicación en o caso de falla dun dos centros de datos.ov.
Por separado, observamos que co enfoque adecuado para o dimensionamento (é dicir, sempre que proporcionemos os límites superiores adecuados de IOPS e MB/s, así como os recursos de CPU e RAM necesarios), se un dos sistemas de almacenamento do clúster metropolitano falla, non haberá unha caída seria no rendemento en condicións de traballo temporal nun sistema de almacenamento.
Isto explícase polo feito de que, en condicións de traballo de dous sitios simultaneamente, a execución da replicación síncrona "come" a metade do rendemento de escritura, xa que cada transacción debe escribirse en dous sistemas de almacenamento (semellante ao RAID-1 / 10). Entón, se un dos sistemas de almacenamento falla, o efecto da replicación desaparece temporalmente (ata que se eleva o sistema de almacenamento fallido) e obtemos un aumento dobre no rendemento de escritura. Despois de que os LUN do sistema de almacenamento fallido se reinicien no sistema de almacenamento en funcionamento, este aumento dobre desaparece debido ao feito de que hai unha carga dos LUN doutro sistema de almacenamento e volvemos ao mesmo nivel de rendemento que tiñamos antes do "caer", pero só no marco dun sitio.
Coa axuda dun dimensionamento competente, pode garantir condicións nas que os usuarios non sentirán o fallo de todo o sistema de almacenamento. Pero repetimos unha vez máis, isto require un talle moi coidado, para o que, por certo, podes contactar connosco de balde :-).
Creación dun metrocluster
Configurar un metroclúster é moi similar a configurar a réplica regular, que describimos en . Polo tanto, centrémonos só nas diferenzas. Montamos un banco no laboratorio baseado na arquitectura anterior, só nunha versión mínima: dous sistemas de almacenamento conectados mediante Ethernet 10G, dous conmutadores 10G e un host que mira a través dos conmutadores de ambos os sistemas de almacenamento con portos 10G. O árbitro execútase nunha máquina virtual.
Ao configurar IP virtuais (VIP) para unha réplica, debe seleccionar o tipo VIP - para metrocluster.
Creamos dúas ligazóns de replicación para dous LUN e distribuímolas en dous sistemas de almacenamento: LUN TEST Primario no sistema de almacenamento 1 (ligazón METRO), LUN TEST2 Primario para o sistema de almacenamento 2 (ligazón METRO2).
Para eles, configuramos dous obxectivos idénticos (no noso caso iSCSI, pero tamén se admite FC, a lóxica de configuración é a mesma).
Sistema de almacenamento 1:
Sistema de almacenamento 2:
Para as conexións de replicación, realizáronse mapeamentos en cada sistema de almacenamento.
Sistema de almacenamento 1:
Sistema de almacenamento 2:
Configuramos rutas múltiples e presentámola ao host.
Constitución dun árbitro
Non necesitas facer nada especial co propio árbitro; só tes que activalo no terceiro sitio, darlle unha IP e configurar o acceso a el mediante ICMP e SSH. A propia configuración realízase desde os propios sistemas de almacenamento. Neste caso, abonda con configurar o árbitro unha vez en calquera dos controladores de almacenamento do metrocluster; esta configuración distribuirase a todos os controladores automaticamente.
Na sección Replicación remota >> Metrocluster (en calquera controlador) >> o botón “Configurar”.
Introducimos a IP do árbitro, así como as interfaces de control de dous controladores de almacenamento remoto.
Despois diso, cómpre activar todos os servizos (o botón "Reiniciar todo"). Se se reconfigura no futuro, os servizos deben reiniciarse para que a configuración teña efecto.
Comprobamos que todos os servizos estean funcionando.
Isto completa a configuración do metrocluster.
Proba de choque
A proba de choque no noso caso será bastante sinxela e rápida, xa que a funcionalidade de replicación (conmutación, coherencia, etc.) foi discutida en . Polo tanto, para probar a fiabilidade do metrocluster, abonda con comprobar a automatización da detección de fallos, a conmutación e a ausencia de perdas de gravación (paradas de E/S).
Para iso, emulamos un fallo completo dun dos sistemas de almacenamento apagando fisicamente os dous controladores, xa que primeiro comezamos a copiar un ficheiro grande no LUN, que debe activarse no outro sistema de almacenamento.
Desactivar un sistema de almacenamento. No segundo sistema de almacenamento, vemos alertas e mensaxes nos rexistros de que a conexión co sistema veciño desapareceu. Se as notificacións a través de SMTP ou SNMP están configuradas, enviaranse as notificacións adecuadas ao administrador.
Exactamente 10 segundos despois (visible en ambas as capturas de pantalla), a conexión de replicación de METRO (a que era Principal no sistema de almacenamento fallido) converteuse automaticamente en Principal no sistema de almacenamento en funcionamento. Usando o mapeamento existente, LUN TEST permaneceu dispoñible para o host, a gravación descendeu un pouco (dentro do 10 por cento prometido), pero non se interrompeu.
A proba completouse con éxito.
Resumindo
A implantación actual do metrocluster nos sistemas de almacenamento da serie N de AERODISK Engine permite resolver plenamente os problemas nos que é necesario eliminar ou minimizar o tempo de inactividade dos servizos informáticos e garantir o seu funcionamento 24/7/365 cun mínimo custo laboral.
Podemos dicir, por suposto, que todo isto é teoría, condicións ideais de laboratorio, etc... PERO temos unha serie de proxectos implementados nos que implementamos a funcionalidade de resiliencia ante desastres, e os sistemas funcionan perfectamente. Un dos nosos clientes bastante coñecidos, que só usa dous sistemas de almacenamento nunha configuración a proba de desastres, xa aceptou publicar información sobre o proxecto, polo que na seguinte parte falaremos da implementación do combate.
Grazas, esperamos unha discusión produtiva.
Fonte: www.habr.com