Como replicar seus servidores on-premises no Hyper-V para o Azure utilizando o Azure Site Recovery

INTRODUÇÃO

Para qualquer empresário, interrupções não planejadas de serviço e interrupções no data center são os piores pesadelos. Felizmente, a Microsoft oferece duas opções de replicação excelentes para dar suporte à recuperação de desastres e continuidade de negócios: o Hyper-V Replica e Azure Site Recovery (ASR).

A alta disponibilidade de VMs do Hyper-V pode ser alcançada por vários meios, um deles é a réplica do Hyper-V. Ela funciona criando e mantendo cópias de VMs especialmente importantes (para os negócios) em um site secundário como, digamos, um data center de backup. Essa solução é tolerante a falhas. Até mesmo a perda de todo o data center não vai refletir em suas VMs.

Embora seja muito vantajosa, uma opção como essa está longe de ser perfeita. Quantas empresas podem pagar um data center secundário, por exemplo? Sem um data center secundário, o que fazer se a tolerância a falhas ainda for necessária no nível da plataforma?

É quando o Azure Site Recovery sai com todas as armas em punho. Os serviços do Azure Site Recovery destinavam-se inicialmente para orquestrar e automatizar a replicação e manutenção no caso de interrupções planejadas ou não de data centers locais e secundários. Agora, ele permite que suas VMs façam failover na nuvem pública do Azure, que serve como seu data center secundário pessoal.

ENTÃO, DO QUE SE TRATA?

Para oferecer suporte à tolerância a falhas, você precisará de pelo menos:

• Garantir a conexão do Azure com sites primários e secundários. Estes canais de conexão servirão para monitorar o estado de áreas protegidas;
• Selecionar as VMs que você precisa proteger com replicação e definir os parâmetros de replicação;
• Desenvolver um plano de recuperação coerente, o que inclui todas as etapas necessárias para mudar para um site secundário, sequência de inicialização de VMs em um data center secundário, vários scripts possíveis e sua sequência de início etc.

O Azure Site Recovery foi criado para contribuir com sua estratégia de BCDR.

ESTRATÉGIA DE CONTINUIDADE DE NEGÓCIOS E RECUPERAÇÃO DE DESASTRES (BCDR).

• Serviço de recuperação de sites – o Site Recovery oferece suporte à continuidade dos negócios evitando que os aplicativos e cargas de trabalho falhem durante as interrupções. Basicamente, ele replica cargas de trabalho em execução em máquinas físicas e virtuais, movendo-as com segurança de um local primário para um destino secundário. Caso seu site primário tenha falhado, execute um failover em seu site secundário e acesse seus aplicativos de lá. Simples assim! Quando o site principal estiver respondendo novamente, você poderá restaurar tudo com a mesma facilidade.
• Serviço de backup – o Backup do Azureé responsável por manter todos os seus dados sãos e salvos, além de recuperar possíveis desastres.

Replicações do Site Recovery:

• VMs do Azure entre diferentes regiões;
• VMs locais, Azure stack VM e servidores bare-metal.

BENEFÍCIOS DO AZURE SITE RECOVERY!

Ele é simples de implantar e gerenciar:

• O Azure Site Recovery é configurado diretamente no Azure e tem atualizações automáticas. Cada nova função é adicionada ao Site Recovery ao ser iniciada;
• O Site Recovery minimiza os problemas de backup gerenciando a ordem dos aplicativos em camadas. Assim, os aplicativos são executados a partir de várias VMs do Azure;
• Para ter certeza de que o Site Recovery pode lidar com seu aplicativo de negócios, você pode fazer um teste. No modo de teste, a recuperação de desastres não interfere nas cargas de trabalho de forma alguma;
• O Site Recovery também emprega controle de acesso baseado em funções do Azure. O Azure Site Recovery fornece três funções internas para gerenciar as operações do Site Recovery: Colaborador, Operador e Leitor. Se isso não for suficiente, você sempre pode dividir as responsabilidades dentro de uma equipe e fornecer direitos de acesso aos usuários para trabalhar com tarefas diferentes;
• A replicação de cargas de trabalho em execução em máquinas com suporte é independente de um aplicativo;
• A replicação é praticamente síncrona, pois o objetivo do ponto de recuperação (RPO) não excede 30 segundos. Isto é mais do que suficiente para a grande maioria dos aplicativos de negócios críticos;
• O Site Recovery oferece suporte à consistência entre aplicativos e aplicativos em camadas durante um failover;
• O Site Recovery também oferece suporte à integração com o SQL Server AlwaysOn e à interação com outros serviços no nível do aplicativo, incluindo replicação do Archive Directory, SQL AlwaysOn, grupos de disponibilidade de banco de dados (DAG) Exchange e Oracle Data Guard);
• Planos de recuperação flexíveis permitem que você restaure toda a pilha de aplicativos sem problemas e também oferece suporte ao gerenciamento manual com o desempenho de scripts externos;
• O gerenciamento avançado de rede do Azure no Site Recovery simplifica os requisitos da rede de aplicativos, incluindo a reserva de endereços IP, a configuração do balanceamento de carga e a integração com o gerenciador de tráfego do Azure para alternar as redes com baixo RPO;
• Uma ampla biblioteca de automação contém cenários que são adequados especificamente para as necessidades dos aplicativos e prontos para uso. Você pode baixá-los e integrá-los aos seus planos de recuperação.

Tem menos despesas com infraestrutura do que o normal:

• Não há necessidade de criar um data center secundário caro;
• Menos despesas com implantação, monitoramento, configuração e suporte de infraestrutura de recuperação de desastres;
• Você paga apenas pelos recursos de computação necessários para oferecer suporte a seus aplicativos no Azure.

Suas funções são:

• • O serviço permite que você replique para o data center secundário do Azure suas VMs Hyper-V da nuvem e do ambiente local.
  • Com a função de frequência de replicação, você pode configurá-la a cada 5 minutos ou, como no caso das aplicações mais vitais (aquelas com SQL), a cada 30 segundos.
  • Armazenamento de instantâneos por 2 horas.
  • A frequência de instantâneo recomendada é de 1 vez por hora.

Procedimento de replicação:

• Ao configurar a replicação, o instantâneo é feito e enviado ao Azure imediatamente. Além disso, a mudança de dados é replicada de acordo com as configurações.

A recuperação consiste nas seguintes etapas:

• Recuperação de desastre de VMs após um failover no data center secundário do Azure da última réplica;
• Ligar e verificar VMs;
• Alterar registros em zonas DNS (se necessário);
• Habilitando a réplica reversa para replicar as VMs em casa;

Preços

Durante os períodos de atividade (failover), você também está pagando pelo consumo real de recursos do Azure. Trata-se de um modelo de pagamento pelo que usar para VMs com failover para nuvem.

Tempo de inatividade mínimo graças à recuperação de desastres confiável:

• • Cobrindo a grande maioria dos aplicativos críticos para os negócios, graças ao suporte e à disponibilidade dos serviços do Azure;
  • Recuperação eficiente de desastres com o Azure Site Recovery.

Cenários de replicação do Azure Site Recovery:

Existem três cenários do Azure Site Recovery:

• Replicação de VMs do Azure entre as regiões do Azure;
• Replicação de VMs locais VMware e Hyper-V, replicação de servidores físicos (Windows e Linux) para Azure;
• Replicação de servidores físicos, VMs VMware e Hyper-V locais no System Center VMM para um site secundário.

Ambiente

Em nosso ambiente temos um servidor Windows Server 2019 Datacenter com a feature do Hyper-V instalado, duas máquinas virtuais executando o sistema operacional Windows Server 2019 e o Centos.

Servidor VM-001-Windows Server 2019

Esse servidor tem o endereço IP 192.168.0.10, o firewall do Windows está desabilitado. O servidor tem as funções de Domain Controller, DNS, Web Server (IIS) e também é o File Server.

Active Directory

DNS

File Server

GPO Mapear unidade de Rede

Web Server (IIS)

Passo a Passo

Configurar o DNS do servidor on-premises

01 – Após replicar as máquinas virtuais on-premises para o Azure, será necessário configurar os registros A no DNS com o endereço IP da máquina virtual no Azure. Assim, após o failover, os usuários poderão acessar as aplicações sem interrupção nos serviços. Para que essa configuração funcione é necessária uma VPN configurada entre o ambiente on-premises e o Azure.

02 – O range de IP da subnet utilizado pelas máquinas virtuais no Azure é 10.0.0.0/24. Vou utilizar o IP 10.0.0.10 para a máquina virtual VM-001-Windows Server 2019. Para a VM VM-002-Centos, vou utilizar o IP 10.0.0.11.

03  – Será necessário criar o Reverse Lookup Zones com o endereço IP da subnet do Azure. No servidor VM-001-Windows Server 2019, abra o DNS Manager, Reverse Lookup Zones e clique em New Zone.

04 – Na tela New Zone Wizard, clique em Next.

05 – Na tela Zone Type, deixe selecionado Primary zone, deixe marcada a opção Store the zone in Active Directory (available only if DNS server is a writable domain controller) e clique em Next.

06 – Na tela Active Directory Zone replication scope, deixe selecionado To all DNS servers running on domain controllers in this domain:jadsonalves.com.br e clique em Next.

07 – Na tela Reverse Lookup Zone Name, deixe selecionado IPv4 Reverse Lookup Zone e clique em Next.

08 – Na tela Reverse Lookup Zone Name, em Network ID digite o endereço IP 10.0.0 que corresponde ao IP da subnet do Azure, e clique em Next.

09 – Na tela Dynamic Update, deixe selecionado Allow only secure dynamic updates (recommended for Active Directory) e clique em Next.

10 – Na tela Completing the New Zone Wizard, clique em Finish.

11 – No servidor VM-001-Windows Server 2019, abra o DNS Manager, clique em Forward Lookup Zones, selecione a zona jadsonalves.com.br, clique com o botão direito e selecione New Host (A or AAA).

12 – Na tela New Host, selecione um nome. Aqui vou chamar de VM-001. Em IP address digite o endereço IP 10.0.0.10, marque a opção Create associated pointer (PTR) record e clique em Add host.

13 – Como podemos observar na imagem abaixo, o registro foi adicionado com sucesso. Clique em OK e em seguida clique em Done.

14 – Como podemos observar na imagem abaixo, o registro foi criado. Repita as etapas acima para configurar os registros para os demais servidores.

Criar um Storage Account

É necessário criar um storage account para armazenar os logs de replicação.

15 – Faça login no portal do Azure.

16  – No portal do Azure, pesquise por Storage accounts.

17  – Na tela Storage accounts, clique em + New.

18 – Na tela Create storage account, selecione a assinatura, grupos de recursos e um nome para o storage account. Para a opção location, selecione (US) East US. Em Performance, deixe a opção Standard selecionada. Em account Kind, selecione Storage V2. Para Replication, selecione Locally-redundant storage (LRS). Não vou realizar mais nenhuma alteração para as outras opções. Clique em Review + create.

Configuração do Azure Recovery Vault

19 – No portal, pesquise por Recovery Service Vaults.

20 – Na tela Recovery Services Vaults, clique em Create recovery services vault.

21 – Na tela Create recovery services vault, selecione a assinatura, grupo de recurso, digite um nome para o vault e região, em seguida clique em Review + Create.

22 – Como podemos observar, o recurso foi provisionado com sucesso. Clique em Go to resource.

Configuração do Azure ASR para recuperação de desastres

Prepare infrastructure

23 – Na tela Vault-Site Recovery, navegue até Getting started e clique em Site Recovery.

24 – Na tela Vault-Site Recovery | Site Recovery, em Hyper-V machines to Azure, clique em 1: Prepare infrastructure.

Azure Site Recovery Deployment Planner

O Planejador de Implantação do Site Recovery é uma ferramenta de linha de comando para ambos os cenários de recuperação de desastre, do Hyper-V para o Azure e do VMware para o Azure. É possível criar o perfil remotamente das VMs do VMware usando esta ferramenta sem impacto na produção. Isso entende os requisitos de largura de banda e do armazenamento para o êxito da replicação e do failover de teste.

Você pode executar a ferramenta sem instalar componentes do Site Recovery no local. Para obter resultados precisos da taxa de transferência obtida, execute o planejador em um Windows Server que atenda aos requisitos mínimos do servidor de configuração de Site Recovery. Esta, provavelmente, será uma das primeiras etapas da implantação de produção.

Para maiores informações acesse o link abaixo:

https://docs.microsoft.com/pt-br/azure/site-recovery/hyper-v-deployment-planner-overview

25 – Na tela Prepare infrastructure, baixe o deployment planner. Ele faz a estimativa de largura de banda, armazenamento e outros recursos.

26 – Após realizar o download do deployment planner, extraia o arquivo ASRDeploymentPlanner-v2.52.

27 – Execute o arquivo ASRDeploymentPlanner.

Obtenha a lista de VM para criação de perfil

28 – Crie um arquivo de texto com a lista de todos os servidores Hyper-V. Vou chamar o arquivo de servers.txt

29 – Abra o prompt de comando como administrador e execute o comando abaixo:

30 – No servidor Hyper-V, foi criada uma pasta em C chamada Hyper-V_Profiled Data. Dentro desta pasta, foram criados dois arquivos ServerList.txt que contêm o nome de todos os servidores Hyper-V e o arquivo VMListFile.txt, com o nome de todas as máquinas virtuais dos hosts informados no arquivo VMListFile.txt.

Local de onde o arquivo ASRDeploymentPlanner foi extraído:

cd C:\Users\adm.jadson\Downloads\ASRDeploymentPlanner-v2.52\ASRDeploymentPlanner

Obter a lista de VMs em execução no host:

OBSERVAÇÃO: Será solicitado que você insira a senha da conta que foi informada no comando abaixo. Nesse caso, preciso informar a senha da conta adm.jadson.

ASRDeploymentPlanner.exe -Operation GetVMlist -ServerListFile “C:\Hyper-V_ProfiledData\ServerList.txt” -User adm.jadson -OutputFile “C:\Hyper-V_ProfiledData\VMListFile.txt”

Após executar o comando, será gerado um arquivo .txt no caminho C:\Hyper-V_ProfiledData com a seguinte sintaxe VMListFile_2021-04-18_12-35-13.txt . Dentro deste arquivo está o nome de todas as máquinas virtuais do host Hyper-V.

Perfil de VMs Hyper-V

Neste caso, farei o perfil das VMs por 30 minutos. Na produção, você faria isso por 15-30 dias. Existem bons exemplos na documentação da Microsoft sobre como fazer isso e até mesmo armazenar os dados em uma conta de armazenamento do Microsoft Azure.

https://docs.microsoft.com/pt-br/azure/site-recovery/hyper-v-deployment-planner-run

Se você deseja apenas criar o perfil de um subconjunto de máquinas, edite o arquivo que foi criado acima. Para começar a criar o perfil das máquinas virtuais detectadas, execute o seguinte:

No arquivo abaixo, estou passando o caminho do diretório profiling e arquivo com a lista das máquinas virtuais, e também informando o nome de um conta com permissões de administrador. Informo que a análise das VMs será executada durante 30 minutos.

ASRDeploymentPlanner.exe -Operation StartProfiling -Virtualization Hyper-V -Directory “C:\Hyper-V_ProfiledData” -VMListFile “C:\Hyper-V_ProfiledData\VMListFile_2021-04-18_12-35-13.txt” -NoOfMinutesToProfile 30 -User adm.jadson

Os dados de rastreio e registro da ferramenta são armazenados no diretório de saída que você especificou anteriormente: C:\Hyper-V_ProfiledData.

Gerar um relatório

Para gerar um relatório para análise, execute a ferramenta no modo de geração com o seguinte comando:

OBSERVAÇÃO: O Excel precisa está instalado na máquina onde o comando será executado. Você precisa do Excel 2013 ou superior.

ASRDeploymentPlanner.exe -Operation GenerateReport -virtualization Hyper-V -Directory “C:\Hyper-V_ProfiledData” -VMListFile “C:\Hyper-V_ProfiledData\VMListFile_2021-04-18_12-35-13.txt”

Analisando o Relatório

O relatório do Excel fornecerá detalhes sobre os requisitos estimados de largura de banda, servidores com perfil, armazenamento estimado e custos.

Informações detalhadas sobre o relatório podem ser encontradas aqui:

https://docs.microsoft.com/en-us/azure/site-recovery/hyper-v-deployment-planner-analyze-report

O relatório foi gerado em  C:\Hyper-V_ProfiledData . Execute o arquivo DeploymentPlannerReport_637544326112918533.xlsm.

O vídeo abaixo mostra o conteúdo do relatório do arquivo DeploymentPlannerReport_637544326112918533.xlsm.

31 – Após executar o deployment planner, para a opção Deployment planning completed selecione Yes, I have done it  e clique em Next. 

32 – Em Source settings, para a opção Are you Using System Center VMM to manage Hyper-V hosts, marque a opção No. A opção Hyper-V site será exibida. Clique em Add Hyper-V site, selecione um nome para o Hyper-V site e clique em OK.

33 – Aguarde alguns instantes até o site ser criado. Após a criação do site, clique em Add Hyper-V server.

34 – Na tela Add Server, clique em Download the installer for tge Microsoft Azure Site Recovery Provider para baixar o AzureSiteRecoveryProvider.exe. Para a opção Download the vault registration key to register the host in a Hyper site, clique em Download.

35 – Após realizar o download do AzureSiteRecoveryProvider.exe, o próximo passo é fazer a instalação. Em Download do Windows execute o arquivo AzureSiteRecoveryProvider.exe

36 – Na tela Azure Site Recovery Provider Setup (Hyper-V server), para a opção Microsoft Update, selecione On (recommeded) e clique em Next.

37 – Na tela Installation, deixe o local de instalação padrão e clique em Install.

38 – Após finalizar a instalação clique em Register.

39 – Na tela Vault Settings, clique em Browse e selecione o vault registration do download feito na etapa Add Server. Perceba que após selecionar o arquivo de vault todas as opções serão preenchidas automaticamente, em seguida clique em Next.

40 – Na tela Proxy Settings, deixe a opção padrão Connect directly to Azure Site Recovery without a proxy server selecionada e clique em Next.

41 – Aguarde até o registro do servidor ser finalizado.

42 – Após o registro ser finalizado, clique em Finish.

43 – Abrindo o Services do Windows, perceba que há três serviços criados para o Azure Site Recovery.

44 – De volta ao portal do Azure, feche a tela Add Server. As configurações realizadas não serão exibidas na tela Prepare infrastructure automaticamente. É necessário atualizar a tela.

45 – Após atualizar a tela, em Getting started, clique em Site Recovery. Em seguida, clique em 1: Prepare infrastructure.

46 – Na tela Prepare infrastructure, em Deployment planning completed selecione Yes, I have done it  e clique em Next. 

47 – Para a opção Source settings, em Are you Using System Center VMM to manage Hyper-V hosts, selecione No. Observe que agora já está sendo exibido o site e o host Hyper-V no qual instalei o Azure Site Recovery Provider. Clique em Next.

48 – Para a opção Target settings, selecione a subscription. Para a opção Post-failover deployment model, selecione Resource Manager. Observe que o storage account store foi selecionado automaticamente e a Network vnet-siterecovery também. Clique em Next.

49 – Para a opção Replication policy, clique em Create a new policy and associate. 

50 – Na tela Create an associate policy, especifique um nome de política. Estou usando ReplicationPolicyon-premises.

Para este tutorial, deixarei as configurações padrão. Altere de acordo com a necessidade da sua empresa.

• Copy frequencyindica com que frequência os dados delta, após a replicação inicial, serão replicados. A frequência padrão é a cada cinco minutos.
• Recovery point retention in hours indica que os pontos de recuperação serão retidos por duas horas. O valor máximo permitido para retenção ao proteger máquinas virtuais hospedadas em hosts Hyper-V é de 24 horas.
• App-consistent snapshot frequency in hours indica que os pontos de recuperação contendo instantâneos consistentes com o aplicativo serão criados a cada hora.
• Initial replication start time indica que a replicação inicial começará imediatamente.

OBSERVAÇÃO: A primeira replicação é Full. O recomendado é que não seja executado em horário de expediente, pois pode gerar lentidão na rede. Agende, preferencialmente, para os horários de menor utilização.

51 – Clique em Ok para criar a política.

52 – Quando você cria uma nova política, ela é automaticamente associada ao site Hyper-V especificado. Neste tutorial está associada ao Hyper-V on-premisses. Clique em Next.

53 – Na tela Review, clique em Prepare.

Enable replication

54 – Em Getting started, clique em Site Recovery. Em seguida, clique em 2: Enable replication.

55 – Na tela Enable replication, em Source location, selecione o Hyper-V site e clique em Next.

56 – Na tela Target environment, para a opção Subscription and resource group, selecione a assinatura e grupo de recursos. Para a opção Deployment Modelo, deixe selecionado Resource Manager, observe que o storage account store já está selecionado. Em Network, escolha Configure now for select machines. Em Virtual Network, selecione a vnet e subnet, em seguida clique em Next.

57 – Para a opção Virtual machine selection, selecione quais máquinas virtuais do Hyper-V on-premises você deseja proteger. Selecione as VMs e clique em Next.

58 – Na tela Replication settings, selecione o sistema operacional das máquinas virtuais. Caso a máquina virtual tenha mais de um disco na opção Disks to replicate, você deve selecionar todos os discos que deseja replicar. Em Target name, você pode alterar o nome dos discos caso não deseje utilizar o mesmo nome do ambiente on-premises, em seguida clique em Next.

59 – Observe que recebi um erro ao clicar em Next. A nomenclatura do disco da máquina virtual VM-001-Windows Server 2019 não está em um padrão compatível com o Azure.

60 – Em Target name, altere o nome do disco para VM-001 e clique em Next.

61 – Para a opção Replication Policy, selecione a política de replicação e clique em Next.

62 – Para a opção Review, verifique se todas as informações estão corretas e clique em Enable replication.

63 – Clique na notificação Enabling protection.

64 – Aguarde o fim do job de replicação das VMs.

65 – Observe no Hyper-V o Status da replicação inicial para o Azure Site Recovery.

66 – Vou verificar como está o desempenho da rede do nosso servidor na replicação inicial para o Azure. Como era de se esperar, o tráfego aumentou.

67 – Abra o Hyper-V em servidor on-premises, selecione uma das máquinas virtuais que foram protegidas, clique com o botão direito em Replication –> View Replication Health. Aqui é possível ver informações sobre a replicação e também pausá-la.

68 – Na tela Replication Health, é possível verificar a saúde da replicação, tamanho do arquivo replicado, entre outras informações. É possível observar que a replicação inicial foi finalizada.

69 –  Na tela Vault-SiteRecovery, em Overview, clique em Site Recovery. É possível ter uma visão geral do Site Recovery como integridade da replicação, visualização da infraestrutura etc.

70 – É possível ver as máquinas virtuais protegidas em Protected items –> Replicated items.

Configurador o endereço IP nos servidores replicados para o Azure 

O próximo passo é configurar o endereço IP adicionado no DNS on-premises nos servidores que foram replicados para o Azure. Assim, caso aconteça algum problema no ambiente on-premises, após o failover os usuários poderão acessar as aplicações nos servidores que estão replicados para o Azure.

71 – No portal do Azure, pesquise por Recovery Services Vaults e selecione o Vault-SiteRecovery.

72 – Na tela Vault-SiteRecovery, navegue até Protected items e clique em Replicated items.

73 – Na tela Vault-SiteRecovery | Replicated items, selecione a máquina virtual.

74 – Após selecionar a máquina virtual clique em Computer and Network.

75 – Na tela VM-001-Windows Server 2019 | Compute and Network, em Edit na parte superior, clique em Network interfaces. Em On-Premises network name clique no swicth virtual. Neste exemplo, uso VSwicth-External.

76 – Na tela Network IP address, na opção Private IP address, vou adicionar o endereço de IP fixo que esse servidor terá. Lembram que configurei o endereço IP 10.0.0.10 no DNS para, após o failover, os usuários poderem acessar as aplicações do servidor VM-001-Windows Server 2019? É nessa tela que vou realizar a configuração de endereço IP.

77 – O endereço IP está configurado, como é possível observar na imagem abaixo. Clique em Save. Repita essas etapas para todos os servidores necessários.

Executar um failover de teste para uma VM

78 – Na tela Vault-SiteRecovery | Replicated items, selecione umas das máquinas virtuais.

79 – Após selecionar a VM, é possível ver algumas informações como saudade da replicação e status da VM. Clique em Test Failover.

80 –  A tela Test failover será aberta. Aqui é possível selecionar qual ponto de recuperação deseja utilizar. Em Azure virtual network escolha uma rede virtual para executar o test failover. O recomendado é ter uma rede separada do ambiente de produção para executar o test failover. Como estou em um ambiente de laboratório, vou utilizar a mesma rede do ambiente do Site Recovery.

81 – Vamos clicar na notificação Starting the test failover of VM-001-Windows Server 2019.

82 – Aguarde o job finalizar.

83 – Como podemos observar nosso failover de teste foi finalizado.

84 – Nosso próximo passo será verificar os recursos criados do test failover no resource group RG-SiteRecovery. Perceba que o nome dos recursos criados para VM terminam com test no final. Perceba que a máquina foi provisionada com 1 vcpu e 2 GB de RAM como no ambiente on-premises.

Limpar o failover de teste para uma VM

86 – Na tela Vault-SiteRecovery, em Protected items, clique em Replicated items e selecione a VM-001-Windows Server 2019. Perceba que já existe uma notificação sobre o  Cleanup test failover pending. 

87 – Após selecionar a VM, clique em Cleanup test failover.

88 – Na tela Teste failover Cleanup, é possível escolher executar o Test failover Cleanup e manter os recursos criados no grupo de recursos RG-SiteRecovery ou marcar a opção executar Testing is complete. Delete test failover virtual machine(s), que deleta todos os recursos criados no teste.

89 – Clique na notificação Starting the task to delete the test failover e aguarde o Test failover cleanup ser finalizado.

90 – Como podemos observar, o Test failover cleanup foi finalizado com sucesso e todos os recursos criados foram deletados.

91 – Como podemos observar, a notificação de Cleanupe test failover não está mais disponível.

Failover de VMs do Hyper-V para o Azure

Nesta etapa vou simular um incidente em nosso datacenter on-premises. Este incidente pode ser um incêndio, interrupção na eletricidade do prédio ou até mesmo uma enchente ou qualquer outra coisa que cause a indisponibilidade dos serviços. Sendo assim, os servidores serão replicados e executados no Azure.

92 – Observe que no Hyper-V on-premises em Replication Mode está definido como Primary, após executar o failover isso será alterado para secundário.

93 – Para testar a máquina virtual sendo desligada no ambiente on-premises e iniciando com o endereço de IP da Vnet no Azure, vou executar um IP nos endereços 192.168.0.10 e 10.0.0.10.

94 – Percebam que, por enquanto, só há resposta de ping no endereço IP 192.168.0.10.

95 – No portal do Azure, pesquise por Recovery Services vaults, selecione o vault Vault-SiteRecovery,  clique em Replicated items, selecione a máquina virtual que deseja fazer o Failover e clique em Failover.

96 – Na tela Failover, em Recovery Point, é possível escolher qual ponto de restauração utilizar. Também é possível desligar a máquina virtual no Hyper-V on-premises.

97 – Clique em start failover. 

98 – Aguarde o Failover ser finalizado. Observe que, no Hyper-V, a máquina virtual VM-001-Windows Server 2019  já foi desligada em Replication, Replication State, que está como Prepared for planned failover. 

99 – Após executar o Failover, não é mais possível executar a máquina virtual VM-001-Windows Server 209 no Hyper-V.

100 – Como podemos observar na imagem abaixo, o job de failover foi finalizado com sucesso.

101 – No servidor Hyper-V, como tenho VPN configurada entre o Azure e o ambiente on-premises, já posso observar a resposta de ping no endereço IP 10.0.0.10, da VM que está replicada para o Azure.

102 – No portal do Azure, pesquise por Virtual machines e observe que há a máquina virtual VM-001 em execução, replicada do nosso hyper-v on-premises.

103 – No portal do Azure em Protected items, em Replicated items,  é possível observar que existe o status de Failover completed para a máquina virtual VM-001-Windows Server 2019.

Testar o acesso ao File server e IIS

104 – O vídeo abaixo simula o acesso de um usuário ao file server e IIS no servidor VM-001 replicado para o Azure.

105 – Após selecionar a VM na qual foi feito o failover, clique em Commit para confirmar o failover da VM.

106 – Clique em OK.

107 – Clique na tarefa Commiting Failover.

108 – O Commit foi finalizado com sucesso.

109 – Observe o status da máquina virtual VM-001-Windows Server 2019 que está agora como Failover committed.

Executar o Failback

Após o failover para o Azure, é possível proteger novamente as VMs do Azure replicando-as para o Hyper-V on-premises. Isso significa que as máquinas virtuais voltam a ser executadas no Hyper-V on-premises e continuam replicando para o Azure.

• É feito failback de VMs do Hyper-V do Azure executando um failover planejado do Azure para o site local. Se a direção do failover for do Azure para o local, será considerado um failback.
• Como o Azure é um ambiente altamente disponível e as VMs estão sempre disponíveis, o failback do Azure é uma atividade planejada. É possível planejar um pequeno tempo de inatividade para que as cargas de trabalho possam ser executadas no local novamente.
• O failback planejado desativa as VMs no Azure e baixa as alterações mais recentes. Nenhuma perda de dados é esperada.

Antes de iniciar revise os tipos de failback

Para fazer failback de VMs do Hyper-V no Azure para a VM local original, execute um failover planejado do Azure para o site local da seguinte maneira:

110 – Em Replicated items, seleciona a VM VM-001-Windows Server 2019, em seguida clique em Planned Failover.

111 – A tela Planned failover será aberta. Observe que a direção do failover está indicada. O failover vai ocorrer do Microsoft Azure para o Hyper-V on-premises. Neste exemplo em Data Sync, vou selecionar Minimize downtime. Caso a máquina virtual tenha sido perdida, é possível criá-la selecionado a opção Create the virtual machine on-premises if it does not exist already.

Em Data Sync, selecione uma das opção:

1. • Minimize downtime, sincronizar dados antes do failover (sincronizar apenas alterações delta) – essa opção minimiza o tempo de inatividade das VMs, pois sincroniza sem desligá-las.
     • Fase 1 : tira um instantâneo da VM do Azure e o copia para o host Hyper-V local. A máquina continua em execução no Azure.
     • Fase 2 : desliga a VM do Azure para que nenhuma nova alteração ocorra nela. O conjunto final de alterações delta é transferido para o servidor local e a VM local é iniciada.
   • Full download, sincronizar dados apenas durante o failover – essa opção é mais rápida porque presumimos que a maior parte do disco mudou e não queremos perder tempo calculando somas de verificação. Esta opção não executa cálculos de checksum.
     • Ele executa um download do disco.
     • Recomendamos que você use essa opção se estiver executando o Azure por um tempo (um mês ou mais) ou se a VM local for excluída.

112 – Clique na notificação Stanting Planned Failover.

113 – Aguarde o fim do job Planned failover.

114 – No Hyper-V on-premises, observe que o Hyper-V tirou um Checkpoint da máquina virtual VM-001-Windows Server 2019. Também é possível observar a porcentagem do status do processo de Failback.

115 – Se selecionar a opção Minimize downtime, depois que a sincronização inicial de dados for concluída e estiver prestes a desligar as máquinas virtuais no Azure, na tela Planned failover, clique em  Complete Failover. Isso faz o seguinte:

• • Encerra a máquina Azure.
  • Transfere as alterações mais recentes para a VM local.
  • Inicia a VM local.

116 – A notificação Compete Failover será aberta. Clique em Yes para prosseguir.

117 – Clique na notificação Resume. Observe que a VM do Azure já está sendo desligada. Aguarde todas as etapas serem finalizadas.

118 – Observe que a VM-001 foi desalocada.

119 – Como podemos observar, o job Planned failover foi finalizado.

120 – Em Replicated items, observe que existe o Status Finalize failback pending para VM-001-Windows Server 2019.

121 – Após selecionar a VM-001-Windows Server 2019, clique em Commit.

122 – Na tela Commit, clique em OK.

123 – Clique na notificação Committing Failover.

124 – Aguarde o job Commit ser finalizado.

125 – Para concluir o failback, clique em Reverse replicate para iniciar a replicação da VM local para o Azure novamente.

126 – Na tela Reverse replication, clique em OK

127 – Clique na notificação Starting Rever Replication.

128 – Aguarde o job rever replication ser finalizado.

129 – No portal do Azure, pesquise por Virtual machines e observe que a máquina virtual VM-001 foi deletada.

130 – Observe que a máquina virtual VM-001-Windows Server 2019 está com o status de Protected, ou seja, a VM on-premises está sendo replicada novamente para o Azure.

131 – Vou analisar o ambiente on-premises após o Failbak.

132 – Como podemos observar, a VM-001-Windows Server 2019 já está em execução e replicando para o Azure novamente.

Jádson Alves

Graduado em Informática Licenciatura pela Universidade Tiradentes, Pós Graduado em Administração e Segurança de Sistemas Computacionais pela Universidade Estácio de Sá, MBA em Gestão de Redes de Computadores pela FANESE, Certificações  MCT,  Azure Administrator, MCSE Core Infrastructure e  MCSA Windows Server 2012, com mais de 07 anos de experiência em TI. Com conhecimento em Windows Server, Linux, Virtualização, Azure, Zabbix.

jadsonalves.com.br/