Olá, leitores do Habr! O tema deste artigo será a implementação de ferramentas de recuperação de desastres em sistemas de armazenamento AERODISK Engine. Inicialmente, queríamos escrever um artigo sobre as duas ferramentas: replicação e metrocluster, mas, infelizmente, o artigo acabou sendo muito longo, então dividimos o artigo em duas partes. Vamos do simples ao complexo. Neste artigo, configuraremos e testaremos a replicação síncrona - descartaremos um data center e também quebraremos o canal de comunicação entre os data centers e veremos o que acontece.
Nossos clientes costumam nos fazer várias perguntas sobre replicação, portanto, antes de prosseguirmos com a configuração e teste da implementação de réplicas, falaremos um pouco sobre o que é replicação em armazenamento.
Um pouco de teoria
A replicação em sistemas de armazenamento é um processo contínuo para garantir a identidade dos dados em vários sistemas de armazenamento simultaneamente. Tecnicamente, a replicação é realizada de duas maneiras.
Replicação síncrona – trata-se da cópia de dados do sistema de armazenamento principal para o de backup, seguida da confirmação obrigatória de ambos os sistemas de armazenamento de que os dados foram registrados e confirmados. É após a confirmação de ambos os lados (ambos os sistemas de armazenamento) que os dados são considerados registados e podem ser trabalhados. Isso garante a identidade dos dados garantida em todos os sistemas de armazenamento participantes da réplica.
As vantagens deste método:
- Os dados são sempre idênticos em todos os sistemas de armazenamento
Contras:
- Alto custo da solução (canais de comunicação rápidos, fibra óptica cara, transceptores de ondas longas, etc.)
- Restrições de distância (dentro de várias dezenas de quilômetros)
- Não há proteção contra corrupção lógica de dados (se os dados forem corrompidos (deliberadamente ou acidentalmente) no sistema de armazenamento principal, eles serão corrompidos automática e instantaneamente no sistema de backup, uma vez que os dados são sempre idênticos (esse é o paradoxo)
Replicação assíncrona – trata-se também de copiar dados do sistema de armazenamento principal para o de backup, mas com certo atraso e sem a necessidade de confirmação da gravação do outro lado. Você pode trabalhar com os dados imediatamente após gravá-los no sistema de armazenamento principal e, no sistema de armazenamento de backup, os dados estarão disponíveis após algum tempo. A identidade dos dados neste caso, obviamente, não é garantida de forma alguma. Os dados no sistema de armazenamento de backup estão sempre um pouco “no passado”.
Prós da replicação assíncrona:
- Solução de baixo custo (qualquer canal de comunicação, óptica opcional)
- Sem restrições de distância
- No sistema de armazenamento de backup, os dados não se deterioram se forem danificados no sistema principal (pelo menos por algum tempo); se os dados forem corrompidos, você sempre pode parar a réplica para evitar corrupção de dados no sistema de armazenamento de backup
Contras:
- Os dados em diferentes data centers nem sempre são idênticos
Assim, a escolha do modo de replicação depende dos objetivos do negócio. Se for fundamental para você que o data center de backup contenha exatamente os mesmos dados que o data center principal (ou seja, requisito de negócios para RPO = 0), então você terá que desembolsar o dinheiro e suportar as limitações de um sistema síncrono. réplica. E se o atraso no estado dos dados for aceitável ou simplesmente não houver dinheiro, então você definitivamente precisará usar o método assíncrono.
Destacaremos também separadamente um modo (mais precisamente, uma topologia) como um metrocluster. No modo metrocluster, a replicação síncrona é usada, mas, diferentemente de uma réplica normal, um metrocluster permite que ambos os sistemas de armazenamento operem no modo ativo. Aqueles. você não tem separação entre data centers ativos e em espera. Os aplicativos funcionam simultaneamente com dois sistemas de armazenamento, localizados fisicamente em data centers diferentes. Os tempos de inatividade durante acidentes nessa topologia são muito pequenos (RTO, geralmente minutos). Neste artigo não consideraremos nossa implementação do metrocluster, uma vez que este é um tópico muito amplo e amplo, por isso dedicaremos um próximo artigo separado a ele, na continuação deste.
Além disso, muitas vezes, quando falamos sobre replicação usando sistemas de armazenamento, muitas pessoas têm uma pergunta razoável: > “Muitas aplicações têm suas próprias ferramentas de replicação, por que usar replicação em sistemas de armazenamento? isto é melhor ou pior?
Não há uma resposta clara aqui, então aqui estão os argumentos PARA e CONTRAS:
Argumentos PARA replicação de armazenamento:
- Simplicidade da solução. Com uma ferramenta, você pode replicar todo o seu conjunto de dados, independentemente do tipo de carga e da aplicação. Se você usar uma réplica de aplicativos, terá que configurar cada aplicativo separadamente. Se houver mais de 2 deles, isso será extremamente trabalhoso e caro (a replicação de aplicativos geralmente requer uma licença separada e não gratuita para cada aplicativo. Mas falaremos mais sobre isso a seguir).
- Você pode replicar qualquer coisa – qualquer aplicativo, qualquer dado – e sempre será consistente. Muitos (a maioria) aplicativos não possuem recursos de replicação e as réplicas do sistema de armazenamento são a única maneira de fornecer proteção contra desastres.
- Não há necessidade de pagar a mais pela funcionalidade de replicação de aplicativos. Via de regra, não é barato, assim como as licenças para uma réplica de sistema de armazenamento. Mas você precisa pagar uma vez por uma licença para replicação de armazenamento, e uma licença para réplica de aplicativo precisa ser adquirida para cada aplicativo separadamente. Se houver muitos desses aplicativos, isso custará um bom dinheiro e o custo das licenças para replicação de armazenamento se tornará uma gota no oceano.
Argumentos CONTRA replicação de armazenamento:
- A réplica por meio de aplicativos tem mais funcionalidades do ponto de vista dos próprios aplicativos, o aplicativo conhece melhor seus dados (obviamente), então há mais opções para trabalhar com eles.
- Os fabricantes de alguns aplicativos não garantem a consistência de seus dados se a replicação for feita com ferramentas de terceiros. *
* - tese polêmica. Por exemplo, um conhecido fabricante de SGBD declara oficialmente há muito tempo que seu SGBD só pode ser replicado normalmente usando seus meios, e o resto da replicação (incluindo sistemas de armazenamento) “não é verdade”. Mas a vida mostrou que não é assim. Muito provavelmente (mas isso não é certo) esta simplesmente não é a tentativa mais honesta de vender mais licenças aos clientes.
Como resultado, na maioria dos casos, a replicação do sistema de armazenamento é melhor, porque Esta é uma opção mais simples e menos dispendiosa, mas há casos complexos em que uma funcionalidade específica da aplicação é necessária e é necessário trabalhar com replicação em nível de aplicação.
Chega de teoria, agora pratique
Configuraremos a réplica em nosso laboratório. Em condições de laboratório, emulamos dois data centers (na verdade, dois racks adjacentes que pareciam estar em prédios diferentes). O estande é composto por dois sistemas de armazenamento Engine N2, que são conectados entre si por cabos ópticos. Um servidor físico executando o Windows Server 2016 está conectado a ambos os sistemas de armazenamento usando Ethernet de 10 Gb. O estande é bastante simples, mas isso não muda a essência.
Esquematicamente fica assim:
Logicamente, a replicação é organizada da seguinte forma:
Agora vamos dar uma olhada na funcionalidade de replicação que temos agora.
Dois modos são suportados: assíncrono e síncrono. É lógico que o modo síncrono seja limitado pela distância e pelo canal de comunicação. Em particular, o modo síncrono requer o uso de fibra como física e Ethernet de 10 Gigabit (ou superior).
A distância suportada para replicação síncrona é de 40 quilômetros, o valor de atraso do canal óptico entre data centers é de até 2 milissegundos. Em geral, funcionará com grandes atrasos, mas haverá fortes lentidão durante a gravação (o que também é lógico), portanto, se você estiver planejando replicação síncrona entre data centers, deverá verificar a qualidade da óptica e os atrasos.
Os requisitos para replicação assíncrona não são tão sérios. Mais precisamente, eles não existem. Qualquer conexão Ethernet funcional servirá.
Atualmente, o sistema de armazenamento AERODISK ENGINE suporta replicação para dispositivos de bloco (LUNs) através do protocolo Ethernet (sobre cobre ou óptico). Para projetos onde é necessária a replicação através de uma malha SAN sobre Fibre Channel, estamos atualmente adicionando uma solução apropriada, mas ela ainda não está pronta, portanto, no nosso caso, apenas Ethernet.
A replicação pode funcionar entre qualquer sistema de armazenamento da série ENGINE (N1, N2, N4), desde sistemas juniores até sistemas mais antigos e vice-versa.
A funcionalidade de ambos os modos de replicação é completamente idêntica. Abaixo estão mais detalhes sobre o que está disponível:
- Replicação “one to one” ou “one to one”, ou seja, a versão clássica com dois data centers, o principal e o de backup
- A replicação é “um para muitos” ou “um para muitos”, ou seja, um LUN pode ser replicado para vários sistemas de armazenamento ao mesmo tempo
- Ativar, desativar e “reverter” a replicação, respectivamente, para ativar, desativar ou alterar a direção da replicação
- A replicação está disponível para pools RDG (Raid Distributed Group) e DDP (Dynamic Disk Pool). No entanto, os LUNs de um pool RDG só podem ser replicados para outro RDG. O mesmo acontece com o DDP.
Existem muitos outros recursos pequenos, mas não faz sentido listá-los; iremos mencioná-los à medida que os configurarmos.
Configurando a replicação
O processo de configuração é bastante simples e consiste em três etapas.
- Configuração de rede
- Configuração de armazenamento
- Configurando regras (conexões) e mapeamento
Um ponto importante na configuração da replicação é que as duas primeiras etapas devem ser repetidas no sistema de armazenamento remoto, a terceira etapa - apenas no principal.
Configurando recursos de rede
A primeira etapa é configurar as portas de rede através das quais o tráfego de replicação será transmitido. Para fazer isso, você precisa habilitar as portas e definir seus endereços IP na seção Adaptadores front-end.
Depois disso, precisamos criar um pool (no nosso caso RDG) e um IP virtual para replicação (VIP). VIP é um endereço IP flutuante vinculado a dois endereços “físicos” de controladores de armazenamento (as portas que acabamos de configurar). Esta será a interface principal de replicação. Você também pode operar não com VIP, mas com VLAN, se precisar trabalhar com tráfego marcado.
O processo de criação de um VIP para uma réplica não é muito diferente da criação de um VIP para E/S (NFS, SMB, iSCSI). Neste caso, criamos um VIP normal (sem VLAN), mas certifique-se de indicar que é para replicação (sem este ponteiro não poderemos adicionar VIP à regra na próxima etapa).
O VIP deve estar na mesma sub-rede que as portas IP entre as quais ele flutua.
Repetimos essas configurações em um sistema de armazenamento remoto, com um IP diferente, é claro.
VIPs de diferentes sistemas de armazenamento podem estar em sub-redes diferentes, o principal é que haja roteamento entre eles. No nosso caso, este exemplo é mostrado exatamente (192.168.3.XX e 192.168.2.XX)
Isso completa a preparação da parte da rede.
Configurando armazenamento
A configuração do armazenamento para uma réplica difere do normal apenas porque fazemos o mapeamento através de um menu especial “Mapeamento de Replicação”. Caso contrário, tudo será igual à configuração normal. Agora, em ordem.
No pool R02 criado anteriormente, você precisa criar um LUN. Vamos criá-lo e chamá-lo de LUN1.
Também precisamos criar o mesmo LUN em um sistema de armazenamento remoto de tamanho idêntico. Nós criamos. Para evitar confusão, vamos chamar o LUN remoto de LUN1R
Se precisássemos de um LUN que já existe, ao configurar a réplica, precisaríamos desmontar esse LUN produtivo do host e simplesmente criar um LUN vazio de tamanho idêntico no sistema de armazenamento remoto.
A configuração do armazenamento está concluída, vamos prosseguir para a criação de uma regra de replicação.
Configurando regras de replicação ou links de replicação
Após criar LUNs no sistema de armazenamento, que será o principal no momento, configuramos a regra de replicação LUN1 no sistema de armazenamento 1 para LUN1R no sistema de armazenamento 2.
A configuração é feita no menu “Replicação remota”
Vamos criar uma regra. Para fazer isso, você precisa especificar o destinatário da réplica. Lá também definimos o nome da conexão e o tipo de replicação (síncrona ou assíncrona).
No campo “sistemas remotos” adicionamos nosso sistema de armazenamento2. Para adicionar, é necessário utilizar os sistemas de armazenamento IP de gerenciamento (MGR) e o nome do LUN remoto no qual realizaremos a replicação (no nosso caso, LUN1R). Os IPs de controle são necessários apenas na fase de adição de uma conexão, o tráfego de replicação não será transmitido através deles, para isso será utilizado o VIP previamente configurado.
Já nesta fase podemos adicionar mais de um sistema remoto para a topologia “um para muitos”: clique no botão “adicionar nó”, conforme figura abaixo.
No nosso caso, existe apenas um sistema remoto, por isso nos limitamos a ele.
A regra está pronta. Observe que ele é adicionado automaticamente a todos os participantes da replicação (no nosso caso, são dois). Você pode criar quantas regras desejar, para qualquer número de LUNs e em qualquer direção. Por exemplo, para equilibrar a carga, podemos replicar parte dos LUNs do sistema de armazenamento 1 para o sistema de armazenamento 2, e a outra parte, ao contrário, do sistema de armazenamento 2 para o sistema de armazenamento 1.
Sistema de armazenamento1. Imediatamente após a criação, a sincronização começou.
Sistema de armazenamento2. Vemos a mesma regra, mas a sincronização já terminou.
LUN1 no sistema de armazenamento 1 está na função Primária, ou seja, está ativo. O LUN1R no sistema de armazenamento 2 está na função de Secundário, ou seja, fica em espera caso o sistema de armazenamento 1 falhe.
Agora podemos conectar nosso LUN ao host.
Iremos nos conectar via iSCSI, embora também possa ser feito via FC. Configurar o mapeamento via iSCSI LUN em uma réplica praticamente não difere do cenário usual, portanto não consideraremos isso em detalhes aqui. Na verdade, esse processo está descrito no artigo “".
A única diferença é que criamos o mapeamento no menu “Mapeamento de Replicação”
Configuramos o mapeamento e entregamos o LUN ao host. O host viu o LUN.
Nós o formatamos em um sistema de arquivos local.
É isso, a configuração está completa. Os testes virão a seguir.
Teste
Testaremos três cenários principais.
- Troca regular de função Secundário > Primário. A troca regular de funções é necessária caso, por exemplo, precisemos realizar algumas operações preventivas no data center principal e durante esse período, para que os dados estejam disponíveis, transferimos a carga para o data center de backup.
- Troca de função de emergência Secundário > Primário (falha no data center). Este é o principal cenário para o qual existe replicação, que pode ajudar a sobreviver a uma falha completa do data center sem parar a empresa por um longo período.
- Repartição dos canais de comunicação entre data centers. Verificar o correto comportamento de dois sistemas de armazenamento em condições onde por algum motivo o canal de comunicação entre os data centers não está disponível (por exemplo, uma escavadeira cavou no local errado e quebrou a ótica escura).
Primeiro, começaremos a gravar dados em nosso LUN (gravar arquivos com dados aleatórios). Vemos imediatamente que o canal de comunicação entre os sistemas de armazenamento está sendo utilizado. Isso é fácil de entender se você abrir o monitoramento de carga das portas responsáveis pela replicação.
Ambos os sistemas de armazenamento agora possuem dados “úteis”, podemos iniciar o teste.
Por precaução, vamos dar uma olhada nas somas de hash de um dos arquivos e anotá-las.
Troca regular de funções
A operação de troca de funções (mudando a direção da replicação) pode ser feita com qualquer sistema de armazenamento, mas ainda será necessário ir para ambos, pois será necessário desabilitar o mapeamento no Primário, e habilitá-lo no Secundário (que se tornará Primário ).
Talvez surja agora uma questão razoável: por que não automatizar isso? A resposta é: é simples, a replicação é um meio simples de resiliência a desastres, baseado apenas em operações manuais. Para automatizar essas operações existe o modo metrocluster, totalmente automatizado, mas sua configuração é muito mais complicada. Escreveremos sobre a configuração de um metrocluster no próximo artigo.
No sistema de armazenamento principal, desabilitamos o mapeamento para garantir que a gravação seja interrompida.
Em seguida, em um dos sistemas de armazenamento (não importa, no principal ou no backup) no menu “Replicação remota”, selecione nossa conexão REPL1 e clique em “Alterar função”.
Após alguns segundos, o LUN1R (sistema de armazenamento de backup) torna-se Primário.
Mapeamos LUN1R com sistema de armazenamento2.
Depois disso, nosso drive E: é automaticamente anexado ao host, só que desta vez ele “chegou” do LUN1R.
Por precaução, comparamos as somas de hash.
Identicamente. Teste aprovado.
Failover. Falha no data center
No momento, o principal sistema de armazenamento após a comutação regular é o sistema de armazenamento 2 e LUN1R, respectivamente. Para simular um acidente, desligaremos ambos os controladores de armazenamento2.
Não há mais acesso a ele.
Vamos ver o que está acontecendo no sistema de armazenamento 1 (o de backup no momento).
Vemos que o LUN primário (LUN1R) não está disponível. Uma mensagem de erro apareceu nos logs, no painel de informações e também na própria regra de replicação. Conseqüentemente, os dados do host não estão disponíveis no momento.
Altere a função do LUN1 para Primário.
Estou mapeando para o host.
Certifique-se de que a unidade E apareça no host.
Verificamos o hash.
Tudo está bem. O sistema de armazenamento sobreviveu com sucesso à queda do data center, que estava ativo. O tempo aproximado que gastamos conectando a “reversão” de replicação e conectando o LUN do data center de backup foi de cerca de 3 minutos. É claro que na produção real tudo é muito mais complicado e, além das ações com sistemas de armazenamento, é necessário realizar muito mais operações na rede, nos hosts, nas aplicações. E na vida esse período será muito mais longo.
Gostaria de escrever aqui que tudo, o teste foi concluído com sucesso, mas não tenhamos pressa. O sistema de armazenamento principal está “deitado”, sabemos que quando “caiu” estava na função Primário. O que acontece se ele ligar de repente? Haverá duas funções principais, o que equivale à corrupção de dados? Vamos verificar agora.
Vamos ligar repentinamente o sistema de armazenamento subjacente.
Ele carrega por alguns minutos e depois retorna ao serviço após uma breve sincronização, mas na função de Secundário.
Tudo bem. O cérebro dividido não aconteceu. Pensamos nisso, e sempre após uma queda o sistema de armazenamento sobe para a função de Secundário, independente da função que desempenhou “durante a vida”. Agora podemos dizer com certeza que o teste de falha do data center foi bem-sucedido.
Falha nos canais de comunicação entre data centers
A principal tarefa deste teste é garantir que o sistema de armazenamento não comece a agir de forma estranha se perder temporariamente os canais de comunicação entre dois sistemas de armazenamento e depois reaparecer.
Então. Desconectamos os fios entre os sistemas de armazenamento (vamos imaginar que foram escavados por uma escavadeira).
No Primário vemos que não há ligação com o Secundário.
No Secundário vemos que não há ligação com o Primário.
Tudo funciona bem, e continuamos gravando os dados no sistema de armazenamento principal, ou seja, eles têm a garantia de serem diferentes do de backup, ou seja, estão “separados”.
Em poucos minutos “consertamos” o canal de comunicação. Assim que os sistemas de armazenamento se identificam, a sincronização de dados é ativada automaticamente. Nada é exigido do administrador aqui.
Depois de algum tempo, a sincronização será concluída.
A conexão foi restabelecida, a perda dos canais de comunicação não gerou situações de emergência e, após ligar, a sincronização ocorreu automaticamente.
Descobertas
Analisamos a teoria - o que é necessário e por quê, onde estão os prós e onde estão os contras. Em seguida, configuramos a replicação síncrona entre dois sistemas de armazenamento.
Em seguida, foram realizados testes básicos para comutação normal, falha no data center e falha no canal de comunicação. Em todos os casos, o sistema de armazenamento funcionou bem. Não há perda de dados e as operações administrativas são reduzidas ao mínimo para um cenário manual.
Da próxima vez vamos complicar a situação e mostrar como toda essa lógica funciona em um metrocluster automatizado em modo ativo-ativo, ou seja, quando ambos os sistemas de armazenamento são primários, e o comportamento em caso de falhas do sistema de armazenamento é totalmente automatizado.
Por favor, escreva comentários, teremos prazer em receber críticas e conselhos práticos.
Até a próxima.
Fonte: habr.com