A operação “proteger novamente” falhou nas máquinas virtuais do Azure para a região primária

Quando você faz failover de máquinas virtuais do Azure de uma região para outra usando o Azure Site Recovery, as máquinas virtuais são inicializadas na região secundária, em um estado desprotegido . Se você quiser fazer failback das máquinas virtuais para a região primária, execute as seguintes tarefas:

1. Reproteja as máquinas virtuais na região secundária, para que elas comecem a ser replicadas para a região primária.
2. Depois que a reproteção for concluída e as máquinas virtuais estiverem replicando, você poderá fazer failover da região secundária para a principal.

Pré-requisitos

• O failover da máquina virtual da região primária para a secundária deve ser confirmado. O status da máquina virtual deve ser Failover confirmado antes de começar.
• O site de destino primário deve estar disponível e você deve ser capaz de acessar ou criar recursos nessa região.

Reproteger uma máquina virtual

1. Em Itens replicados do Vault>, clique com o botão direito do mouse na máquina virtual com failover e selecione Reproteger. A direção de reproteção deve ser mostrada de secundária a primária.

   

2. Analise o grupo de recursos, a rede, o armazenamento e os conjuntos de disponibilidade. Em seguida, selecione OK. Se houver recursos marcados como novos, eles serão criados como parte do processo de reproteção.

3. O trabalho de reproteção semeia o local alvo com os dados mais recentes. Após a conclusão do trabalho, ocorre a replicação delta. Em seguida, você pode fazer failover de volta para o site primário. Você pode selecionar a conta de armazenamento ou a rede que deseja usar durante o reprotect, usando a opção personalizar.

   

Personalizar configurações de reproteção

Você pode personalizar as seguintes propriedades da máquina virtual de destino durante a reproteção.

Property	Notas
Grupo de recursos de destino	Modifique o grupo de recursos de destino no qual a máquina virtual é criada. Como parte da reproteção, a máquina virtual de destino é excluída. Quando você reprotege uma máquina virtual com failover para a máquina virtual de origem, o grupo de recursos de destino não pode ser alterado.
Rede virtual de destino	A rede de destino não pode ser alterada durante o trabalho de reproteção. Para alterar a rede, refaça o mapeamento de rede.
Reserva de capacidade	Configure uma reserva de capacidade para a máquina virtual. Você pode criar um novo grupo de reserva de capacidade para reservar capacidade ou selecionar um grupo de reserva de capacidade existente. Saiba mais sobre a reserva de capacidade.
Armazenamento de destino (a máquina virtual secundária não usa discos gerenciados)	Você pode alterar a conta de armazenamento que a máquina virtual usa após o failover.
Discos gerenciados por réplica (a máquina virtual secundária usa discos gerenciados)	O Site Recovery cria discos gerenciados de réplica na região primária para espelhar os discos gerenciados da máquina virtual secundária.
Armazenamento em cache	Você pode especificar uma conta de armazenamento em cache a ser usada durante a replicação. Por padrão, uma nova conta de armazenamento em cache é criada, se ela não existir. Por padrão, o tipo de conta de armazenamento (conta de armazenamento padrão ou conta de armazenamento de Blob de Bloco Premium) que você selecionou para a máquina virtual de origem no local primário original é usado. Por exemplo, durante a replicação da origem original para o destino, se você tiver selecionado Alta Churn, durante a reproteção de volta do destino para a origem original, o blob de Bloco Premium será usado por padrão. Você pode configurá-lo e alterá-lo para nova proteção. Para obter mais informações, consulte Recuperação de desastres da máquina virtual do Azure - Suporte de alta rotatividade.
Conjunto de disponibilidade	Se a máquina virtual na região secundária fizer parte de um conjunto de disponibilidade, você poderá escolher um conjunto de disponibilidade para a máquina virtual de destino na região primária. Por padrão, a Recuperação de Site tenta localizar o conjunto de disponibilidade existente na região primária e usá-lo. Durante a personalização, você pode especificar um novo conjunto de disponibilidade.

O que acontece durante a reproteção?

Por padrão, ocorre o seguinte:

1. Uma conta de armazenamento em cache é criada na região onde a máquina virtual com failover está sendo executada.
2. Se a conta de armazenamento de destino (a conta de armazenamento original na região primária) não existir, uma nova será criada. O nome da conta de armazenamento atribuída é o nome da conta de armazenamento usada pela máquina virtual secundária, sufixada com asr.
3. Se sua máquina virtual usa discos gerenciados, os discos gerenciados de réplica são criados na região primária para armazenar os dados replicados dos discos da máquina virtual secundária.
4. Réplicas temporárias dos discos de origem (discos anexados às máquinas virtuais na região secundária) são criadas com o nome ms-asr-<GUID>, que são usadas para transferir / ler dados. Os discos temporários nos permitem utilizar a largura de banda completa do disco em vez de apenas 16% da largura de banda dos discos originais (que estão conectados à máquina virtual). Os discos temporários são excluídos assim que a reproteção for concluída.
5. Se o conjunto de disponibilidade de destino não existir, um novo será criado como parte do trabalho de reproteção, se necessário. Se você personalizou as configurações de reproteção, o conjunto selecionado é usado.

Quando você aciona um trabalho de reproteção e a máquina virtual de destino existe, ocorre o seguinte:

1. A máquina virtual do lado de destino será desativada se estiver em execução.
2. Se a máquina virtual estiver usando discos gerenciados, uma cópia do disco original será criada com um -ASRReplica sufixo. Os discos originais são excluídos. As -ASRReplica cópias são usadas para replicação.
3. Se a máquina virtual estiver usando discos não gerenciados, os discos de dados da máquina virtual de destino serão desanexados e usados para replicação. Uma cópia do disco do sistema operacional é criada e anexada na máquina virtual. O disco original do SO é desanexado e utilizado para replicação.
4. Apenas as alterações entre o disco de origem e o disco de destino são sincronizadas. Os diferenciais são calculados comparando ambos os discos e, em seguida, transferidos. Confira abaixo o tempo estimado para concluir a reproteção.
5. Após a conclusão da sincronização, a replicação delta é iniciada e um ponto de recuperação é criado de acordo com a política de replicação.

Quando você aciona um trabalho de reproteção e a máquina virtual de destino e os discos não existem, ocorre o seguinte:

1. Se a máquina virtual estiver usando discos gerenciados, os discos de réplica serão criados com -ASRReplica sufixo. As -ASRReplica cópias são usadas para replicação.
2. Se a máquina virtual estiver usando discos não gerenciados, os discos de réplica serão criados na conta de armazenamento de destino.
3. Os discos inteiros são copiados da região com failover para a nova região de destino.
4. Após a conclusão da sincronização, a replicação delta é iniciada e um ponto de recuperação é criado de acordo com a política de replicação.

Nota

Os ms-asr discos são discos temporários que são excluídos após a conclusão da ação de reproteção . Ser-lhe-á cobrado um custo mínimo com base no preço do disco gerido do Azure durante o tempo em que estes discos estiverem ativos.

Tempo estimado para fazer a reproteção

Na maioria dos casos, o Azure Site Recovery não replica os dados completos para a região de origem. A quantidade de dados replicados depende das seguintes condições:

1. O Azure Site Recovery não oferece suporte à reproteção se os dados da máquina virtual de origem forem excluídos, corrompidos ou inacessíveis por algum motivo. Por exemplo, uma alteração ou exclusão de um grupo de recursos. Como alternativa, você pode desativar a proteção de recuperação de desastres anterior e habilitar uma nova proteção da região atual.
2. Se os dados da máquina virtual de origem estiverem acessíveis, os diferenciais serão calculados comparando os discos e apenas as diferenças serão transferidas. Neste caso, o tempo de reproteção é maior ou igual ao checksum calculation time + checksum differentials transfer time + time taken to process the recovery points from Azure Site Recovery agent + auto scale time.

Fatores que regem o tempo de reproteção no cenário 2

Os seguintes fatores afetam o tempo de reproteção quando a máquina virtual de origem está acessível no cenário 2:

1. Tempo de cálculo da soma de verificação - O tempo necessário para concluir o processo de replicação de habilitação do local principal para o local de recuperação de desastres é usado como referência para o cálculo diferencial da soma de verificação. Navegue até Cofres dos Serviços de>Recuperação Monitorando>trabalhos de Recuperação de Site para ver o tempo necessário para concluir o processo de habilitação da replicação. Este será o tempo mínimo necessário para concluir o cálculo da soma de verificação.

2. A transferência diferencial de dados da soma de verificação acontece em aproximadamente 23% da taxa de transferência do disco.

3. O tempo necessário para processar os pontos de recuperação enviados do agente do Azure Site Recovery – o agente do Azure Site Recovery também continua a enviar pontos de recuperação durante a fase de cálculo e transferência da soma de verificação. No entanto, o Azure Site Recovery processa-os apenas quando a transferência de comparação da soma de verificação estiver concluída. O tempo necessário para processar os pontos de recuperação será de cerca de um quinto (1/5) do tempo necessário para o cálculo dos diferenciais da soma de verificação e o tempo de transferência dos diferenciais da soma de verificação (tempo para o cálculo do diferencial da soma de verificação + tempo para a transferência do diferencial da soma de verificação). Por exemplo, se o tempo necessário para o cálculo do diferencial da soma de verificação e a transferência do diferencial da soma de verificação for de 15 horas, o tempo necessário para processar os pontos de recuperação do agente será de três horas.

4. O tempo de escala automática é de aproximadamente 20-30 minutos.

Exemplo de cenário:

Vamos pegar o exemplo da captura de tela a seguir, onde Habilitar replicação do local principal para o local de recuperação de desastres levou uma hora e 12 minutos. O tempo de cálculo da soma de verificação seria de pelo menos uma hora e 12 minutos. Supondo que a quantidade de alteração de dados pós-failover é de 45 GB, e o disco tem uma taxa de transferência de 60 Mbps, a transferência diferencial ocorrerá a 14 Mbps, e o tempo necessário para a transferência diferencial será de 45 GB / 14 Mbps, ou seja, aproximadamente 55 minutos. O tempo necessário para processar os pontos de recuperação é aproximadamente um quinto do tempo total necessário para o cálculo da soma de verificação (72 minutos) e o tempo necessário para a transferência de dados (55 minutos), que é de aproximadamente 25 minutos. Além disso, leva de 20 a 30 minutos para o dimensionamento automático. Assim, o tempo total para a reproteção deve ser de pelo menos três horas.

O acima é uma ilustração simples de como estimar o tempo de reproteção.

Quando a máquina virtual é reprotegida da região de recuperação de desastres para a região primária (ou seja, após o failover da região primária para a região de recuperação de desastres), a máquina virtual de destino (máquina virtual de origem original) e a(s) NIC(s) associada(s) são excluídas.

No entanto, quando a máquina virtual é protegida novamente da região primária para a região de recuperação de desastres após failback, não excluímos a máquina virtual e a(s) NIC(s) associada(s) na região de recuperação de desastres que foram criadas durante o failover anterior.

Próximos passos

Depois que a máquina virtual estiver protegida, você poderá iniciar um failover. O failover desliga a máquina virtual na região secundária e cria e inicializa a máquina virtual na região primária, com breve tempo de inatividade durante esse processo. Recomendamos que você escolha um momento apropriado para esse processo e que execute um failover de teste antes de iniciar um failover completo para o site primário.

Saiba mais sobre o failover do Azure Site Recovery.