Olá, leitores do Habr! No último artigo, falamos sobre um meio simples de recuperação de desastres em sistemas de armazenamento AERODISK ENGINE - a replicação. Neste artigo, mergulharemos em um tema mais complexo e interessante - o metrocluster, ou seja, um meio de proteção automatizada contra desastres para dois data centers, permitindo que os data centers operem no modo ativo-ativo. Nós vamos te contar, mostrar, quebrar e consertar.
Como sempre, a teoria primeiro
Um metrocluster é um cluster espalhado por vários locais dentro de uma cidade ou região. A palavra “cluster” nos indica claramente que o complexo é automatizado, ou seja, a troca de nós do cluster em caso de falhas ocorre automaticamente.
É aqui que reside a principal diferença entre um metrocluster e a replicação regular. Automação de operações. Ou seja, no caso de determinados incidentes (falha no data center, canais quebrados, etc.), o sistema de armazenamento executará de forma independente as ações necessárias para manter a disponibilidade dos dados. Ao usar réplicas regulares, essas ações são executadas total ou parcialmente manualmente pelo administrador.
O que ele faz?
O principal objetivo que os clientes buscam ao usar determinadas implementações de metrocluster é minimizar o RTO (Recovery Time Objective). Ou seja, minimizar o tempo de recuperação dos serviços de TI após uma falha. Se você usar replicação regular, o tempo de recuperação sempre será maior que o tempo de recuperação com um metrocluster. Por que? Muito simples. O administrador deve estar em sua mesa e alternar a replicação manualmente, e o metrocluster faz isso automaticamente.
Se você não tiver um administrador dedicado de plantão que não durma, não coma, não fume ou fique doente e monitore o estado do sistema de armazenamento 24 horas por dia, então não há como garantir que o administrador irá estar disponível para comutação manual durante uma falha.
Assim, o RTO na ausência de um metrocluster ou de um administrador imortal do 99º nível do serviço de administrador será igual à soma do tempo de comutação de todos os sistemas e o período máximo de tempo após o qual o administrador terá a garantia de começar a trabalhar com sistemas de armazenamento e sistemas relacionados.
Assim, chegamos à conclusão óbvia de que o metrocluster deve ser utilizado se a exigência de RTO for de minutos, e não de horas ou dias, ou seja, quando no caso da pior falha do data center, o departamento de TI deve fornecer tempo ao negócio para restaurar o acesso aos serviços de TI em minutos ou até segundos.
Como isso funciona?
No nível inferior, o metrocluster usa um mecanismo para replicação síncrona de dados, que descrevemos no artigo anterior (consulte. ). Como a replicação é síncrona, os requisitos para ela são correspondentes, ou melhor:
- fibra óptica como física, Ethernet de 10 gigabits (ou superior);
- a distância entre data centers não passa de 40 quilômetros;
- o atraso do canal óptico entre data centers (entre sistemas de armazenamento) é de até 5 milissegundos (idealmente 2).
Todos esses requisitos são de natureza consultiva, ou seja, o metrocluster funcionará mesmo que esses requisitos não sejam atendidos, mas devemos entender que as consequências do não cumprimento desses requisitos são iguais a uma desaceleração na operação de ambos os sistemas de armazenamento em o metroaglomerado.
Portanto, uma réplica síncrona é usada para transferir dados entre sistemas de armazenamento. Como as réplicas alternam automaticamente e, o mais importante, como evitar a divisão do cérebro? Para isso, em um nível superior, é utilizada uma entidade adicional - um árbitro.
Como funciona um árbitro e qual é a sua função?
O árbitro é uma pequena máquina virtual ou cluster de hardware que deve ser lançado em um terceiro local (por exemplo, em um escritório) e fornecer acesso ao sistema de armazenamento via ICMP e SSH. Após o lançamento, o árbitro deve definir o IP e, a seguir, do lado do armazenamento, indicar seu endereço, além dos endereços dos controladores remotos que participam do metrocluster. Depois disso, o árbitro está pronto para trabalhar.
O árbitro monitora constantemente todos os sistemas de armazenamento no metrocluster e caso um determinado sistema de armazenamento não esteja disponível, após confirmar a indisponibilidade de outro membro do cluster (um dos sistemas de armazenamento “ativos”), ele decide iniciar o procedimento de troca de regras de replicação e mapeamento.
Um ponto muito importante. O árbitro deve estar sempre localizado em local diferente daqueles onde estão localizados os sistemas de armazenamento, ou seja, nem no data center 1, onde está instalado o sistema de armazenamento 1, nem no data center 2, onde está instalado o sistema de armazenamento 2.
Por que? Porque esta é a única maneira de um árbitro, com a ajuda de um dos sistemas de armazenamento sobreviventes, poder determinar de forma inequívoca e precisa a queda de qualquer um dos dois locais onde os sistemas de armazenamento estão instalados. Quaisquer outros métodos de colocação de um árbitro podem resultar em divisão cerebral.
Agora vamos mergulhar nos detalhes do trabalho do árbitro.
O árbitro executa vários serviços que pesquisam constantemente todos os controladores de armazenamento. Caso o resultado da enquete seja diferente do anterior (disponível/indisponível), então ele é registrado em um pequeno banco de dados, que também funciona no árbitro.
Vejamos mais detalhadamente a lógica do trabalho do árbitro.
Etapa 1: determinar a indisponibilidade. Um evento de falha do sistema de armazenamento é a ausência de ping de ambos os controladores do mesmo sistema de armazenamento em 5 segundos.
Passo 2. Inicie o procedimento de troca. Após o árbitro perceber que um dos sistemas de armazenamento não está disponível, ele envia uma solicitação ao sistema de armazenamento “ativo” para ter certeza de que o sistema de armazenamento “morto” está realmente morto.
Depois de receber tal comando do árbitro, o segundo sistema de armazenamento (ativo) verifica adicionalmente a disponibilidade do primeiro sistema de armazenamento caído e, se não estiver lá, envia a confirmação de seu palpite ao árbitro. O sistema de armazenamento está realmente indisponível.
Após receber tal confirmação, o árbitro inicia um procedimento remoto para alternar a replicação e aumentar o mapeamento nas réplicas que estavam ativas (primárias) no sistema de armazenamento caído e envia um comando ao segundo sistema de armazenamento para alterar essas réplicas de secundárias para primárias e aumentar o mapeamento. Bem, o segundo sistema de armazenamento, respectivamente, executa esses procedimentos e, em seguida, fornece acesso aos LUNs perdidos por si mesmo.
Por que é necessária uma verificação adicional? Para quórum. Ou seja, a maioria do número total ímpar (3) de membros do cluster deve confirmar a queda de um dos nós do cluster. Só então esta decisão será definitivamente correta. Isso é necessário para evitar trocas errôneas e, consequentemente, divisão do cérebro.
O passo de tempo 2 leva aproximadamente 5 a 10 segundos, portanto, levando em consideração o tempo necessário para determinar a indisponibilidade (5 segundos), dentro de 10 a 15 segundos após o acidente, os LUNs do sistema de armazenamento caído estarão automaticamente disponíveis para trabalhar com o ativo sistema de armazenamento.
É claro que para evitar a perda de conexões com os hosts, você também precisa ter o cuidado de configurar corretamente os tempos limite nos hosts. O tempo limite recomendado é de pelo menos 30 segundos. Isso impedirá que o host interrompa a conexão com o sistema de armazenamento durante a comutação de carga no caso de um desastre e poderá garantir que não haja interrupções de E/S.
Espere um segundo, acontece que se tudo está tão bem com o metrocluster, por que precisamos de replicação regular?
Na realidade, nem tudo é tão simples.
Vamos considerar os prós e os contras do metrocluster
Assim, percebemos que as vantagens óbvias do metrocluster em relação à replicação convencional são:
- Automação total, garantindo tempo mínimo de recuperação em caso de desastre;
- Isso é tudo :-).
E agora, atenção, os contras:
- Custo da solução. Embora o metrocluster nos sistemas Aerodisk não exija licenciamento adicional (a mesma licença é usada para a réplica), o custo da solução ainda será ainda maior do que o uso da replicação síncrona. Você precisará implementar todos os requisitos para uma réplica síncrona, além dos requisitos para o metrocluster associados a switching adicional e site adicional (consulte planejamento do metrocluster);
- Complexidade da solução. Um metrocluster é muito mais complexo do que uma réplica normal e requer muito mais atenção e esforço para planejamento, configuração e documentação.
No final Metrocluster é certamente uma solução muito avançada tecnologicamente e boa quando você realmente precisa fornecer RTO em segundos ou minutos. Mas se não houver tal tarefa, e o RTO em horas for adequado para os negócios, então não faz sentido atirar em pardais com um canhão. A replicação habitual entre trabalhadores e camponeses é suficiente, uma vez que um cluster metropolitano causará custos adicionais e complicações à infra-estrutura de TI.
Planejamento de metrocluster
Esta seção não pretende ser um guia completo para o projeto de metroclusters, mas apenas mostra as principais orientações que devem ser elaboradas se você decidir construir tal sistema. Portanto, ao realmente implementar um metrocluster, envolva o fabricante do sistema de armazenamento (ou seja, nós) e outros sistemas relacionados para consultas.
Plataformas
Conforme declarado acima, um metrocluster requer no mínimo três sites. Dois data centers onde funcionarão os sistemas de armazenamento e sistemas relacionados, bem como um terceiro local onde atuará o árbitro.
A distância recomendada entre data centers não é superior a 40 quilômetros. Uma distância maior provavelmente causará atrasos adicionais, o que no caso de um metrocluster é extremamente indesejável. Lembramos que os atrasos devem ser de até 5 milissegundos, embora seja aconselhável mantê-los dentro de 2.
Recomenda-se verificar os atrasos também durante o processo de planejamento. Qualquer provedor mais ou menos maduro que forneça fibra óptica entre data centers pode organizar uma verificação de qualidade rapidamente.
Quanto aos atrasos antes do árbitro (ou seja, entre o terceiro site e os dois primeiros), o limite de atraso recomendado é de até 200 milissegundos, ou seja, uma conexão VPN corporativa regular pela Internet é adequada.
Comutação e rede
Ao contrário do esquema de replicação, onde é suficiente conectar sistemas de armazenamento de locais diferentes, o esquema metrocluster requer a conexão de hosts com ambos os sistemas de armazenamento em locais diferentes. Para deixar mais claro qual é a diferença, ambos os esquemas são mostrados abaixo.
Como pode ser visto no diagrama, nossos hosts do site 1 analisam o sistema de armazenamento 1 e o sistema de armazenamento 2. Além disso, ao contrário, os hosts do site 2 analisam o sistema de armazenamento 2 e o sistema de armazenamento 1. Ou seja, cada host vê os dois sistemas de armazenamento. Este é um pré-requisito para o funcionamento do metrocluster.
É claro que não há necessidade de conectar cada host com um cabo óptico a outro data center; nenhuma porta ou cabo será suficiente. Todas essas conexões devem ser feitas através de switches Ethernet 10G+ ou FibreChannel 8G+ (FC serve apenas para conectar hosts e sistemas de armazenamento para IO, o canal de replicação atualmente está disponível apenas via IP (Ethernet 10G+).
Agora algumas palavras sobre a topologia da rede. Um ponto importante é a configuração correta das sub-redes. É necessário definir imediatamente várias sub-redes para os seguintes tipos de tráfego:
- A sub-rede de replicação na qual os dados serão sincronizados entre sistemas de armazenamento. Podem ser vários, neste caso não importa, tudo depende da topologia de rede atual (já implementada). Se houver dois deles, obviamente o roteamento deverá ser configurado entre eles;
- Sub-redes de armazenamento através das quais os hosts acessarão os recursos de armazenamento (se for iSCSI). Deve haver uma sub-rede desse tipo em cada data center;
- Sub-redes de controle, ou seja, três sub-redes roteáveis em três locais a partir dos quais os sistemas de armazenamento são gerenciados, e o árbitro também está localizado lá.
Não consideramos aqui sub-redes para acesso aos recursos do host, pois elas são altamente dependentes das tarefas.
Separar tráfego diferente em sub-redes diferentes é extremamente importante (é especialmente importante separar a réplica da E/S), porque se você misturar todo o tráfego em uma sub-rede “grossa”, então esse tráfego será impossível de gerenciar, e em nas condições de dois data centers, isso ainda pode causar diferentes opções de colisão de rede. Não nos aprofundaremos neste assunto no âmbito deste artigo, pois você pode ler sobre o planejamento de uma rede estendida entre data centers com recursos de fabricantes de equipamentos de rede, onde isso é descrito detalhadamente.
Configuração do árbitro
O árbitro deve fornecer acesso a todas as interfaces de gerenciamento do sistema de armazenamento por meio dos protocolos ICMP e SSH. Você também deve pensar na segurança do árbitro. Há uma nuance aqui.
O failover do árbitro é altamente desejável, mas não obrigatório. O que acontece se o árbitro cair na hora errada?
- O funcionamento do metrocluster no modo normal não será alterado, pois arbtir não tem absolutamente nenhum efeito na operação do metrocluster no modo normal (sua tarefa é alternar a carga entre data centers em tempo hábil)
- Além disso, se o árbitro, por um motivo ou outro, cair e “dormir durante” um acidente no data center, nenhuma troca acontecerá, porque não haverá ninguém para dar os comandos de troca necessários e organizar um quorum. Nesse caso, o metrocluster se transformará em um esquema regular com replicação, que deverá ser trocado manualmente em caso de desastre, o que afetará o RTO.
O que se segue disso? Se você realmente precisa garantir um RTO mínimo, você precisa garantir que o árbitro seja tolerante a falhas. Existem duas opções para isso:
- Inicie uma máquina virtual com um árbitro em um hipervisor tolerante a falhas; felizmente, todos os hipervisores adultos suportam tolerância a falhas;
- Se no terceiro local (em um escritório convencional) você tiver preguiça de instalar um cluster normal e não houver nenhum cluster de hipervoz existente, então fornecemos uma versão de hardware do árbitro, que é feita em uma caixa 2U na qual dois comuns servidores x-86 funcionam e podem sobreviver a uma falha local.
Recomendamos fortemente garantir a tolerância a falhas do árbitro, apesar do metrocluster não precisar dele no modo normal. Mas, como mostram tanto a teoria como a prática, se construirmos uma infra-estrutura verdadeiramente fiável e à prova de desastres, então é melhor agir pelo seguro. É melhor proteger você e sua empresa da “lei da maldade”, ou seja, da falha tanto do árbitro quanto de um dos locais onde está localizado o sistema de armazenamento.
Arquitetura da solução
Considerando os requisitos acima, obtemos a seguinte arquitetura geral de solução.
Os LUNs devem ser distribuídos uniformemente entre dois locais para evitar sobrecarga severa. Ao mesmo tempo, ao dimensionar ambos os data centers, você deve incluir não apenas o dobro do volume (que é necessário para armazenar dados simultaneamente em dois sistemas de armazenamento), mas também o dobro do desempenho em IOPS e MB/s para evitar a degradação do aplicativo em caso de falha de um dos data centers.
Separadamente, observamos que com a abordagem adequada ao dimensionamento (isto é, desde que tenhamos fornecido os limites superiores adequados de IOPS e MB/s, bem como os recursos necessários de CPU e RAM), se um dos sistemas de armazenamento no O cluster metro falhar, não haverá uma queda séria no desempenho sob condições de trabalho temporário em um sistema de armazenamento.
Isso é explicado pelo fato de que quando dois sites operam simultaneamente, a replicação síncrona “consome” metade do desempenho de gravação, uma vez que cada transação deve ser gravada em dois sistemas de armazenamento (semelhante ao RAID-1/10). Portanto, se um dos sistemas de armazenamento falhar, a influência da replicação desaparece temporariamente (até que o sistema de armazenamento com falha se recupere) e obtemos um aumento duplo no desempenho de gravação. Depois que os LUNs do sistema de armazenamento com falha são reiniciados no sistema de armazenamento em funcionamento, esse aumento duplo desaparece devido ao fato de que a carga aparece nos LUNs do outro sistema de armazenamento e voltamos ao mesmo nível de desempenho que tínhamos antes do “queda”, mas apenas no âmbito de um site.
Com a ajuda de um dimensionamento competente, você pode garantir condições sob as quais os usuários não sentirão a falha de todo um sistema de armazenamento. Mas repetimos mais uma vez, isto requer um dimensionamento muito cuidadoso, para o qual, aliás, pode contactar-nos gratuitamente :-).
Configurando um metrocluster
A configuração de um metrocluster é muito semelhante à configuração da replicação regular, que descrevemos em . Portanto, vamos nos concentrar apenas nas diferenças. Montamos uma bancada em laboratório baseada na arquitetura acima, apenas em uma versão mínima: dois sistemas de armazenamento conectados via Ethernet 10G, dois switches 10G e um host que olha através dos switches em ambos os sistemas de armazenamento com portas 10G. O árbitro é executado em uma máquina virtual.
Ao configurar IPs virtuais (VIPs) para uma réplica, você deve selecionar o tipo VIP – para metrocluster.
Criamos dois links de replicação para dois LUNs e os distribuímos em dois sistemas de armazenamento: LUN TEST Primário no sistema de armazenamento 1 (link METRO), LUN TEST2 Primário para o sistema de armazenamento 2 (link METRO2).
Para eles, configuramos dois alvos idênticos (no nosso caso iSCSI, mas FC também é suportado, a lógica de configuração é a mesma).
Sistema de armazenamento1:
Sistema de armazenamento2:
Para conexões de replicação, foram feitos mapeamentos em cada sistema de armazenamento.
Sistema de armazenamento1:
Sistema de armazenamento2:
Configuramos o multipath e o apresentamos ao host.
Configurando um árbitro
Você não precisa fazer nada de especial com o árbitro em si; basta habilitá-lo no terceiro site, fornecer um IP e configurar o acesso a ele via ICMP e SSH. A configuração em si é realizada nos próprios sistemas de armazenamento. Neste caso, basta configurar o árbitro uma vez em qualquer um dos controladores de armazenamento do metrocluster; essas configurações serão distribuídas a todos os controladores automaticamente.
Na seção Replicação remota >> Metrocluster (em qualquer controlador) >> o botão “Configurar”.
Entramos no IP do árbitro, bem como nas interfaces de controle de dois controladores de armazenamento remotos.
Depois disso, você precisa habilitar todos os serviços (o botão “Reiniciar tudo”). Se forem reconfigurados no futuro, os serviços deverão ser reiniciados para que as configurações tenham efeito.
Verificamos se todos os serviços estão funcionando.
Isso conclui a configuração do metrocluster.
Teste de colisão
O crash test no nosso caso será bastante simples e rápido, já que a funcionalidade de replicação (switching, consistência, etc.) foi discutida em . Portanto, para testar a confiabilidade do metrocluster, basta verificarmos a automação da detecção de falhas, comutação e ausência de perdas de registro (paradas de E/S).
Para isso, emulamos uma falha total de um dos sistemas de armazenamento desligando fisicamente ambos os seus controladores, tendo primeiro iniciado a cópia de um arquivo grande para o LUN, que deve ser ativado no outro sistema de armazenamento.
Desative um sistema de armazenamento. No segundo sistema de armazenamento vemos alertas e mensagens nos logs informando que a conexão com o sistema vizinho foi perdida. Caso sejam configuradas notificações via monitoramento SMTP ou SNMP, o administrador receberá as notificações correspondentes.
Exatamente 10 segundos depois (visível em ambas as capturas de tela), a conexão de replicação METRO (aquela que era Primária no sistema de armazenamento com falha) tornou-se automaticamente Primária no sistema de armazenamento em funcionamento. Usando o mapeamento existente, o LUN TEST permaneceu disponível para o host, a gravação caiu um pouco (dentro dos 10% prometidos), mas não foi interrompida.
O teste foi concluído com sucesso.
Resumindo
A atual implementação do metrocluster nos sistemas de armazenamento AERODISK Engine série N permite resolver totalmente problemas onde é necessário eliminar ou minimizar o tempo de inatividade dos serviços de TI e garantir o seu funcionamento 24/7/365 com custos mínimos de mão-de-obra.
Podemos dizer, claro, que tudo isto é teoria, condições laboratoriais ideais, e assim por diante... MAS temos vários projectos implementados nos quais implementámos funcionalidades de resiliência a desastres, e os sistemas funcionam perfeitamente. Um de nossos clientes bastante conhecidos, que utiliza apenas dois sistemas de armazenamento em uma configuração à prova de desastres, já concordou em publicar informações sobre o projeto, portanto na próxima parte falaremos sobre a implementação de combate.
Obrigado, estamos ansiosos para uma discussão produtiva.
Fonte: habr.com