Replicação Hyper-V

Neste artigo, falaremos brevemente sobre o mecanismo de replicação do Hyper-V com ferramentas integradas. Infelizmente, por algum motivo, esse mecanismo é extremamente raramente usado por alguém e, em vez disso, roubar “comprar” produtos como o Veeam Backup, mas usá-los apenas para criar réplicas de VMs.

A replicação do Hyper-V permite fazer uma cópia completa de uma VM para outro hipervisor (servidor) e mantém essa cópia atualizada continuamente. Assim, em caso de colapso total do hipervisor principal, você, como administrador do ambiente de virtualização, após tomar a decisão “O servidor principal não pode ser restaurado e a VM deve ser iniciada no hipervisor de backup”, gastará literalmente alguns minutos para ligar esta VM com a quantidade de dados perdidos não superior a 0,5/5/15 minutos (dependendo da configuração). Além disso, se o sistema operacional convidado também for Windows (de uma geração não inferior à 9ª versão), usando o serviço VSS em conjunto com os componentes de integração, você obterá completos até mesmo os bancos de dados DBMS que estavam funcionando no momento da criação de uma cópia dos dados para o hipervisor de backup.

Depois que a replicação é configurada, o hipervisor principal cria arquivos de disco virtual delta e os transfere para o servidor de réplica (servidor de backup), e o servidor de réplica, ao recebê-lo, o mescla com o disco virtual principal. Dependendo das configurações, você pode obter também réplicas consistentes com aplicativos (o mesmo serviço VSS). Essas cópias “consistentes” garantem que todos os dados contidos nelas estarão intactos, e mesmo em MS SQL, MySQL, PostgreSQL e outros SGBDs, mesmo aqueles muito carregados acabarão no servidor de réplica com seus bancos de dados em estado intacto, e no caso de uma falha inesperada do servidor principal, você terá a oportunidade de obter o último estado da réplica (com uma quantidade mínima de dados perdidos, mas com o risco de que o banco de dados esteja corrompido) ou reverter para um ponto anterior, mas consistente com aplicativos (VSS). E você obterá transações 100% completas dentro do banco de dados.

Dependendo das configurações de replicação do Hyper-V, você pode configurar a frequência de transferência de uma réplica (não consistente) a cada 30 segundos, 5 minutos, 15 minutos. Embora se você se aprofundar no Windows, poderá definir outros parâmetros, não recomendamos fazer isso. Mas você pode obter pontos de reversão consistentes (VSS) somente se tiver seu sistema operacional convidado Windows, e ele tiver e executar o serviço VSS e você ativar nas configurações de replicação a frequência com que precisa fazer um ponto de reversão “consistente”. Por padrão, a Microsoft sugere fazer isso uma vez a cada 4 horas e apresentar um ponto não acordado a cada hora. Todos esses parâmetros também podem ser modificados nas profundezas do Windows, mas não recomendamos fortemente fazer isso aqui. No máximo, você pode alterar a frequência de criação de cópias consistentes para cada 3, 2 ou 1 hora. Mas deve ser lembrado que, ao criar um ponto sequencial, todos os aplicativos no sistema operacional convidado param quase completamente de responder às chamadas e ficam bastante lentos.

Requisitos para tintura:

  • Seus hipervisores devem ser membros de um domínio. Lembre-se de que, se seus controladores de domínio forem as próprias VMs, você deverá ter pelo menos dois deles e em hipervisores diferentes. Pois na hora de carregar o hypervisor, ele não vai detectar um Domain Controller disponível, e se por algum tipo de falha do ambiente de virtualização ou da própria VM com DomainController, você também não conseguirá acessar o hypervisor. Em hipervisores, recomendamos que você instale o AD que não esteja relacionado ao domínio principal da empresa de forma alguma. Nele, crie contas apenas para administradores do ambiente de virtualização. Aloque o segmento de rede do hipervisor para uma VLAN separada (pelo menos), mas é melhor alocar switches separados para pelo menos 10 Gbe. Restrinja o acesso a esse segmento de rede de forma que os administradores do ambiente de virtualização não possam se conectar a hipervisores de nenhum ponto como um segmento local, muito menos da Internet.
  • O subsistema de disco do seu hipervisor deve ter desempenho suficientemente alto, pois o mecanismo de replicação usa quase 2 vezes mais operações com o subsistema de disco no hipervisor principal.
  • Nos hipervisores, nas configurações do Firewall local, você deve habilitar a permissão para conectar via TCP/80 e/ou TCP/443 para transmissão de réplica (a Microsoft irá lembrá-lo disso durante a configuração).

Procedimento para configurar a replicação:

 Se o seu segmento de rede estiver protegido e a criptografia não for necessária, recomendamos que você não a use, pois recursos significativos do hipervisor serão gastos na criptografia.

Selecione a VM na lista e no lado direito do Hyper-V Control Manager clique em “Ativar replicação”. Na primeira tela digite nome do servidor do parceiro de replicação (tudo já deve estar configurado neste parceiro, inclusive TCP/80 aberto ou TCP/443) e clique em “Avançar”:

Selecione o modo de transferência de dados com ou sem criptografia. Não recomendamos habilitar a criptografia se seus dados forem transmitidos em um segmento privado. Mas se precisar configurar a criptografia, você deve entender o que é criptografia assimétrica, configurar corretamente a CA no domínio e obter os certificados corretos em ambos os servidores. Você também precisa levar em consideração o fator de carga excessiva da CPU em ambos os servidores.

Aqui você pode configurar quais discos virtuais precisam ser replicados. Por exemplo, se você não tiver muito espaço livre no servidor parceiro e não quiser, por exemplo, replicar o cache do serviço WSUS, poderá excluir o disco com o WSUS da replicação. Observe que você não poderá adicioná-lo “on the fly” no futuro e precisará recriar os parâmetros de replicação. Você pode recriá-lo de duas maneiras:

  1. Exclua a VM no servidor de réplica.
  2. Exclua os parâmetros de replicação, recrie-os e transfira a réplica inicial para a VM replicada anteriormente. Com essa restauração, a replicação inicial não será totalmente transferida, mas um disco que não foi replicado anteriormente chegará ao servidor de réplica com o nome do disco virtual não especificado no servidor principal, mas na forma de um longo GUID .

Nesta tela, você pode escolher com que frequência enviar uma réplica para o servidor de réplica. Lembre-se de que enviar com muita frequência sobrecarregará o servidor de envio e o servidor de recebimento. Enviar uma réplica com pouca frequência pode levar a problemas de mesclagem das alterações recebidas no lado da réplica.

Ao configurar pontos adicionais, lembre-se de que o servidor réplica deve ter espaço livre igual à quantidade de alterações para o número de horas selecionado (primeiro parâmetro). Lembre-se também de que o serviço VSS está disponível apenas em sistemas operacionais Windows e funciona corretamente em conjunto com o Hyper-V e um sistema operacional Windows convidado da versão 9 ou superior. Outro fator importante é uma diminuição perceptível no desempenho do sistema operacional convidado no momento da criação do ponto VSS. Se o sistema convidado estiver altamente carregado e fazendo isso a cada hora, você obterá o efeito de degradação do desempenho a cada hora. 

Se tudo estiver claro com a transferência da réplica inicial pela rede, então com a transferência na mídia e “Usar existente...” Existem nuances das quais você precisa estar ciente.

  • Para transferir a réplica inicial na mídia, é necessário fazer upload desses dados para essa mídia. E isso pode ser feito simplesmente exportando a VM para a mídia. Mas há uma “nuance” aqui, que será discutida a seguir.
  • Se você já possui uma réplica da sua VM em um servidor de réplica, então você pode iniciar a replicação para acelerar o processo usando a opção “Usar VM existente...”. Observe que o Hyper-V determina qual VM é a mesma na réplica, não por seu nome no gerenciador, mas por seu GUID (um parâmetro interno da VM). Portanto, o nome exato da sua VM na réplica não é importante. Se no momento do início dessa replicação não havia discos virtuais no servidor de réplica, eles serão carregados no servidor de réplica, mas o nome do arquivo deste disco virtual não conterá o nome do servidor de origem, mas um GUID. Este mecanismo é útil nos casos em que você adicionou outro disco à VM de origem e precisa adicionar esse disco à replicação.

Após configurar a replicação, a partir do envio da réplica inicial no servidor principal, o “snapshot” (Ponto de Retorno) será automaticamente excluído e será iniciado o procedimento automático de transferência de todas as alterações para o servidor de réplica.

As vantagens desta solução são óbvias, mas ainda as observarei:
  • Disponível na configuração básica do SO Windows Server.
  • Extremamente fácil de configurar, mesmo para um iniciante.
  • Garante a integridade dos dados dentro da VM para o SO convidado do Windows.
  • No caso de falha do servidor principal ou da própria VM, você precisará de 1 a 5 minutos para verificar o status dos pontos de recuperação no servidor de réplica e executar um failover.
  • Existem pontos de retorno por 24 horas, então você pode retornar não ao último estado (quando os dados dentro da VM já estavam corrompidos), mas escolher o tempo para o ponto de recuperação.
  • A capacidade de configurar “Replicação avançada em um terceiro servidor, o que lhe dá a confiança de que, nas circunstâncias mais negativas, você terá outra cópia de toda a VM.
Mas também há aspectos negativos desta decisão:
  • Em caso de falha do servidor principal, a VM no servidor de réplica não liga sozinha (intervenção humana necessária).
  • Desempenho ligeiramente reduzido devido ao custo excessivo do subsistema de arquivos para criar arquivos de dados que precisam ser transferidos para a réplica.
  • A replicação pode parar de funcionar espontaneamente.

Se ninguém tiver dúvidas específicas com o primeiro ponto, e estiver claro para todos que se você precisar de um nível ainda mais alto de tolerância a falhas, então você precisa usar um “Cluster de Failover” e com o segundo, tudo também fica claro e esta é uma característica da tecnologia e a redução no desempenho não é significativa, então com O terceiro ponto é o problema. Não contrate uma pessoa especial que irá entrar e verificar a cada 15 minutos.

Para isso, desenvolvemos um sensor para o sistema de monitoramento PRTG e irá publicá-lo em nosso site em breve. GitHub. Para o Zabbix também estará pronto, mas um pouco mais tarde. Você pode pegar esse sensor e reescrevê-lo, pois está escrito no PowerShell.

Assine as novidades!

Nós não enviamos spam! Leia nosso política de Privacidadedescobrir mais.

Deixe um comentário

O produto foi adicionado ao carrinho.
0 itens - 0,00 
chat aberto
1
Posso ajudar?
Escaneie o código
Olá 👋
Como posso ajudá-lo?
Este não é um chatbot! As pessoas respondem aqui, então nem sempre instantaneamente 😳
Usamos cookies para oferecer a melhor experiência em nosso site. Ao continuar a usar este site, você concorda com o uso de cookies.
Aceitar
Recusar
Política de Privacidade