Formação
Módulo
Planejar e implementar atualizações, backups e recuperação de desastres - Training
Planeje a recuperação de desastres.
Este browser já não é suportado.
Atualize para o Microsoft Edge para tirar partido das mais recentes funcionalidades, atualizações de segurança e de suporte técnico.
Este artigo descreve como solucionar erros comuns no Azure Site Recovery durante a replicação e recuperação de máquinas virtuais (VM) do Azure de uma região para outra. Para obter mais informações sobre configurações com suporte, consulte a matriz de suporte para replicar VMs do Azure.
Verifique se sua assinatura está habilitada para criar VMs do Azure na região de destino que você planeja usar como sua região de recuperação de desastres (DR). Sua assinatura precisa de cota suficiente para criar VMs dos tamanhos necessários. Por predefinição, o Site Recovery escolhe uma VM de destino com um tamanho igual ao da VM de origem. Se não estiver disponível um tamanho correspondente, o Site Recovery escolherá automaticamente o tamanho disponível mais próximo.
Se não houver nenhum tamanho que suporte a configuração da VM de origem, a seguinte mensagem será exibida:
Replication couldn't be enabled for the virtual machine <VmName>.
Entre em contato com o suporte de cobrança do Azure para habilitar sua assinatura para criar VMs dos tamanhos necessários no local de destino. Em seguida, tente novamente a operação com falha.
Se a localização de destino tiver uma restrição de capacidade, desative a replicação para essa localização. Em seguida, ative a replicação para uma localização diferente onde a subscrição tenha quota suficiente para criar VMs com os tamanhos necessários.
Se nem todos os certificados raiz confiáveis mais recentes estiverem presentes na VM, seu trabalho para habilitar a replicação para a Recuperação de Site poderá falhar. A autenticação e a autorização de chamadas de serviço de Recuperação de Site da VM falham sem esses certificados.
Se o trabalho de habilitação de replicação falhar, a seguinte mensagem será exibida:
Site Recovery configuration failed.
Os certificados raiz confiáveis necessários para autorização e autenticação não estão presentes na máquina virtual.
Para uma VM que executa o sistema operacional Windows, instale as atualizações mais recentes do Windows para que todos os certificados raiz confiáveis estejam presentes na VM. Siga o processo típico de gerenciamento de atualizações do Windows ou gerenciamento de atualizações de certificados em sua organização para obter os certificados raiz mais recentes e a lista de revogação de certificados atualizada nas VMs.
Para verificar se o problema foi resolvido, vá para login.microsoftonline.com
a partir de um navegador na sua VM.
Para obter mais informações, consulte Configurar raízes confiáveis e certificados não permitidos.
Siga as orientações fornecidas pelo distribuidor da versão do seu sistema operacional Linux para obter os certificados raiz confiáveis mais recentes e a lista de revogação de certificados mais recente na VM.
Como o SUSE Linux usa links simbólicos, ou links simbólicos, para manter uma lista de certificados, siga estas etapas:
Inicie sessão como utilizador root . O símbolo de hash (#
) é a linha de comandos predefinida.
Para alterar o diretório, execute este comando:
cd /etc/ssl/certs
Verifique se o certificado de autoridade de certificação raiz da Symantec está presente:
ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
Se o certificado de autoridade de certificação raiz da Symantec não for encontrado, execute o seguinte comando para baixar o arquivo. Verifique se há erros e siga as ações recomendadas para falhas de rede.
wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
Verifique se o certificado de autoridade de certificação raiz de Baltimore está presente:
ls Baltimore_CyberTrust_Root.pem
Se o certificado da autoridade de certificação raiz de Baltimore não for encontrado, execute este comando para baixar o certificado:
wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem
Verifique se o certificado de DigiCert_Global_Root_CA está presente:
ls DigiCert_Global_Root_CA.pem
Se o DigiCert_Global_Root_CA não for encontrado, execute os seguintes comandos para baixar o certificado:
wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
Para atualizar os hashes do requerente do certificado para os certificados recentemente transferidos, execute o script rehash:
c_rehash
Para verificar se foram criados hashes do requerente como symlinks para os certificados, execute estes comandos:
ls -l | grep Baltimore
lrwxrwxrwx 1 root root 29 Jan 8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem
-rw-r--r-- 1 root root 1303 Jun 5 2014 Baltimore_CyberTrust_Root.pem
ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5
-rw-r--r-- 1 root root 1774 Jun 5 2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
lrwxrwxrwx 1 root root 62 Jan 8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
ls -l | grep DigiCert_Global_Root
lrwxrwxrwx 1 root root 27 Jan 8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem
-rw-r--r-- 1 root root 1380 Jun 5 2014 DigiCert_Global_Root_CA.pem
Crie uma cópia do arquivo VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem com o nome do arquivo b204d74a.0:
cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0
Crie uma cópia do arquivo Baltimore_CyberTrust_Root.pem com o nome de arquivo 653b494a.0:
cp Baltimore_CyberTrust_Root.pem 653b494a.0
Crie uma cópia do arquivo DigiCert_Global_Root_CA.pem com o nome do arquivo 3513523f.0:
cp DigiCert_Global_Root_CA.pem 3513523f.0
Verifique se os ficheiros estão presentes:
ls -l 653b494a.0 b204d74a.0 3513523f.0
-rw-r--r-- 1 root root 1774 Jan 8 09:52 3513523f.0
-rw-r--r-- 1 root root 1303 Jan 8 09:52 653b494a.0
-rw-r--r-- 1 root root 1774 Jan 8 09:52 b204d74a.0
Para que a replicação do Site Recovery funcione, é necessária conectividade de saída para URLs específicas da VM. Se sua VM estiver atrás de um firewall ou usar regras NSG (grupo de segurança de rede) para controlar a conectividade de saída, você poderá enfrentar um desses problemas. Embora continuemos a oferecer suporte ao acesso de saída via URLs, o uso de uma lista de permissões de intervalos de IP não é mais suportado.
Se estiver a utilizar DNS personalizado, certifique-se de que o servidor DNS está acessível a partir da região de recuperação de desastres.
Para verificar se a VM usa uma configuração de DNS personalizada:
Tente aceder ao servidor DNS a partir da máquina virtual. Se o servidor DNS não estiver acessível, torne-o acessível fazendo failover sobre o servidor DNS ou criando a linha de site entre a rede DR e o DNS.
Nota
Se você usar pontos de extremidade privados, certifique-se de que as VMs possam resolver os registros DNS privados.
Não é possível estabelecer uma conexão com pontos de extremidade IP4 de autenticação e identidade do Microsoft 365.
O Azure Site Recovery exigia acesso aos intervalos de IP do Microsoft 365 para autenticação. Se você estiver usando regras/proxy de firewall do Grupo de Segurança de Rede (NSG) do Azure para controlar a conectividade de rede de saída na VM, certifique-se de usar a regra NSG baseada na marca de serviço Microsoft Entra para permitir o acesso à ID do Microsoft Entra. Não suportamos mais regras NSG baseadas em endereço IP.
Não é possível estabelecer uma conexão com os pontos de extremidade do serviço Azure Site Recovery.
Se você estiver usando regras/proxy de firewall do NSG (Grupo de Segurança de Rede) do Azure para controlar a conectividade de rede de saída na VM, certifique-se de usar marcas de serviço. Não oferecemos mais suporte ao uso de uma lista de permissões de endereços IP por meio de NSGs para o Azure Site Recovery.
As configurações de proxy personalizadas são inválidas e o agente do serviço de mobilidade não detetou automaticamente as configurações de proxy do Internet Explorer.
O agente do serviço de mobilidade deteta as configurações de proxy do Internet Explorer no Windows e /etc/environment
no Linux.
Se você preferir definir proxy apenas para o serviço de mobilidade, então você pode fornecer os detalhes do proxy em ProxyInfo.conf localizado em:
/usr/local/InMage/config/
C:\ProgramData\Microsoft Azure Site Recovery\Config
O ProxyInfo.conf deve ter as configurações de proxy no seguinte formato INI .
[proxy]
Address=http://1.2.3.4
Port=567
Nota
O agente do serviço de mobilidade suporta apenas proxies não autenticados.
Para especificar as URLs necessárias ou os intervalos de IP necessários, siga as orientações em Sobre a rede no Azure para a replicação do Azure.
Um novo disco conectado à VM deve ser inicializado. Se o disco não for encontrado, a seguinte mensagem será exibida:
Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.
Certifique-se de que os discos de dados foram inicializados e, em seguida, tente novamente a operação.
Se o problema persistir, contacte o suporte.
Para tornar o status de replicação da VM íntegro novamente, você pode optar por proteger os discos ou descartar o aviso.
Vá para Discos de nome> da VM de Itens>Replicados.
Selecione o disco desprotegido e, em seguida, selecione Ativar replicação:
Vá para Nome da VM de itens>replicados.
Selecione o aviso na seção Visão geral e, em seguida, selecione OK.
Quando a Recuperação de Site protege a máquina virtual, ela cria links na máquina virtual de origem. Quando você remove a proteção ou desabilita a replicação, o Site Recovery remove esses links como parte do trabalho de limpeza. Se a máquina virtual tiver um bloqueio de recursos, o trabalho de limpeza será concluído com as informações. As informações dizem que a máquina virtual foi removida do cofre dos Serviços de Recuperação, mas que alguns dos links obsoletos não puderam ser limpos na máquina de origem.
Você pode ignorar esse aviso se nunca pretender proteger essa máquina virtual novamente. Mas se você tiver que proteger essa máquina virtual mais tarde, siga as etapas nesta seção para limpar os links.
Aviso
Se não fizer a limpeza:
Nota
A Recuperação de Site não exclui a máquina virtual de origem nem a afeta de forma alguma enquanto você executa essas etapas.
Remova o bloqueio do grupo de recursos VM ou VM. Por exemplo, na imagem a seguir, o bloqueio de recursos na VM nomeada MoveDemo
deve ser excluído:
Baixe o script para remover uma configuração obsoleta do Site Recovery.
Execute o script, Cleanup-stale-asr-config-Azure-VM.ps1. Forneça a ID da Assinatura, o Grupo de Recursos da VM e o nome da VM como parâmetros.
Se você for solicitado a fornecer credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.
A máquina virtual tem uma configuração obsoleta da proteção anterior do Site Recovery.
Uma configuração obsoleta pode ocorrer em uma VM do Azure se você habilitou a replicação para a VM do Azure usando a Recuperação de Site e, em seguida:
Nota
A Recuperação de Site não exclui a máquina virtual de origem nem a afeta de forma alguma enquanto você executa essas etapas.
Remova o bloqueio do grupo de recursos VM ou VM. Por exemplo, na imagem a seguir, o bloqueio de recursos na VM nomeada MoveDemo
deve ser excluído:
Baixe o script para remover uma configuração obsoleta do Site Recovery.
Execute o script, Cleanup-stale-asr-config-Azure-VM.ps1. Forneça a ID da Assinatura, o Grupo de Recursos da VM e o nome da VM como parâmetros.
Se você for solicitado a fornecer credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.
Atualmente, a Recuperação de Site exige que o grupo de recursos da região de origem e as máquinas virtuais estejam no mesmo local. Se não estiverem, não conseguirá encontrar a máquina virtual ou o grupo de recursos quando tentar aplicar proteção.
Como solução alternativa, você pode habilitar a replicação a partir da VM em vez do cofre dos Serviços de Recuperação. Vá para Recuperação de desastres de propriedades>da VM>de origem e habilite a replicação.
Talvez você não consiga encontrar o grupo de recursos no momento da proteção se o grupo de recursos não fizer parte da assinatura selecionada. Certifique-se de que o grupo de recursos pertence à subscrição que está a utilizar.
Talvez você não veja a VM que deseja habilitar para replicação se existir uma configuração obsoleta do Site Recovery na VM do Azure. Essa condição pode ocorrer se você habilitar a replicação para a VM do Azure usando a Recuperação de Site e, em seguida:
Nota
Certifique-se de atualizar o AzureRM.Resources
módulo antes de usar o script mencionado nesta seção. A Recuperação de Site não exclui a máquina virtual de origem nem a afeta de forma alguma enquanto você executa essas etapas.
Remova o bloqueio, se houver, do grupo de recursos VM ou VM. Por exemplo, na imagem a seguir, o bloqueio de recursos na VM nomeada MoveDemo
deve ser excluído:
Baixe o script para remover uma configuração obsoleta do Site Recovery.
Execute o script, Cleanup-stale-asr-config-Azure-VM.ps1. Forneça a ID da Assinatura, o Grupo de Recursos da VM e o nome da VM como parâmetros.
Se você for solicitado a fornecer credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.
A máquina virtual tem uma extensão instalada em um estado de falha ou sem resposta
Vá para Extensões de Configurações>de Máquinas>Virtuais e verifique se há extensões em um estado de falha. Desinstale qualquer extensão com falha e tente novamente proteger a máquina virtual.
Para habilitar a replicação na VM, seu estado de provisionamento deve ser Bem-sucedido. Execute as seguintes etapas para verificar o estado de provisionamento:
Durante a configuração de recuperação de desastre, se a VM de origem fizer parte de uma rede virtual e outra VM da mesma rede virtual já estiver mapeada com uma rede no grupo de recursos de destino, a caixa de listagem suspensa seleção de rede não estará disponível (aparecerá esmaecida) por padrão.
A desativação da replicação de uma VM não exclui o mapeamento de rede. O mapeamento deve ser excluído do cofre dos Serviços de Recuperação onde a VM foi protegida. Selecione o cofre dos Serviços de Recuperação e vá para Gerenciar>Infraestrutura de Recuperação de Site>para Mapeamento de Rede de Máquinas>Virtuais do Azure.
A rede de destino que foi configurada durante a configuração de recuperação de desastres pode ser alterada após a configuração inicial e depois que a VM estiver protegida. Para modificar o mapeamento de rede, selecione o nome da rede:
Quando o erro COM+ ou Volume Shadow Copy Service (VSS) ocorre, a seguinte mensagem é exibida:
Site Recovery extension failed to install.
Defina o Aplicativo do Sistema COM+ e o Serviço de Cópias de Sombra de Volume para o modo de inicialização automática ou manual.
Abra a consola Serviços no Windows.
Verifique se o Aplicativo do Sistema COM+ e o Serviço de Cópias de Sombra de Volume não estão definidos como Desativado como Tipo de Inicialização.
Quando esse erro ocorre, a seguinte mensagem é exibida:
Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.
O disco é menor do que o tamanho suportado de 1024 MB.
Certifique-se de que o tamanho do disco está dentro do intervalo de tamanho suportado e, em seguida, tente novamente a operação.
Os arquivos de configuração do Linux Grand Unified Bootloader (GRUB) (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg ou /etc/default/grub) podem especificar os nomes reais dos dispositivos em vez dos valores de identificador universalmente exclusivo (UUID) para os root
parâmetros e resume
. A Recuperação de Site requer UUIDs porque os nomes dos dispositivos podem ser alterados. Após a reinicialização, uma VM pode não apresentar o mesmo nome no failover, resultando em problemas.
Os exemplos a seguir são linhas de arquivos GRUB onde os nomes dos dispositivos aparecem em vez dos UUIDs necessários:
Arquivo /boot/grub2/grub.cfg:
linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts
Arquivo: /boot/grub/menu.lst
kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314
Substitua cada nome de dispositivo pelo UUID correspondente:
Encontre o UUID do dispositivo executando o comando blkid <device name>
. Por exemplo:
blkid /dev/sda1
/dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
blkid /dev/sda2
/dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"
Substitua o nome do dispositivo por seu UUID, nos formatos root=UUID=<UUID>
e resume=UUID=<UUID>
. Por exemplo, após a substituição, a linha de /boot/grub/menu.lst seria semelhante à seguinte linha:
kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314
Tente novamente a proteção.
Os arquivos de configuração do GRUB (/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg ou /etc/default/grub) podem conter os parâmetros rd.lvm.lv
ou rd_LVM_LV
. Esses parâmetros identificam os dispositivos LVM (Logical Volume Manager) que devem ser descobertos no momento da inicialização. Se esses dispositivos LVM não existirem, o próprio sistema protegido não inicializará e ficará preso no processo de inicialização. O mesmo problema também será visto com a VM de failover. Eis alguns exemplos:
Arquivo: /boot/grub2/grub.cfg no RHEL7:
linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8
Arquivo: /etc/default/grub no RHEL7:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet
Arquivo: /boot/grub/menu.lst no RHEL6:
kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet
Em cada exemplo, o GRUB tem que detetar dois dispositivos LVM com os nomes root
e swap
do grupo rootvg
de volumes.
Se o dispositivo LVM não existir, crie-o ou remova os parâmetros correspondentes dos arquivos de configuração do GRUB. Em seguida, tente novamente ativar a proteção.
O serviço de Mobilidade de Recuperação de Site tem muitos componentes, um dos quais é chamado de driver de filtro. O driver de filtro é carregado na memória do sistema somente durante a reinicialização do sistema. Sempre que uma atualização do serviço de mobilidade inclui alterações no driver de filtro, a máquina é atualizada, mas você ainda vê um aviso de que algumas correções exigem uma reinicialização. O aviso aparece porque as correções do driver de filtro podem entrar em vigor somente quando o novo driver de filtro é carregado, o que acontece apenas durante uma reinicialização.
Nota
Isto é apenas um aviso. A replicação existente continua a funcionar mesmo após a atualização do novo agente. Você pode optar por reiniciar sempre que quiser os benefícios do novo driver de filtro, mas o driver de filtro antigo continua funcionando se você não reiniciar.
Além do driver de filtro, os benefícios de quaisquer outros aprimoramentos e correções na atualização do serviço de mobilidade entram em vigor sem a necessidade de uma reinicialização.
Esse erro ocorre quando o disco gerenciado pela réplica já existe, sem marcas esperadas, no grupo de recursos de destino.
Esse problema pode ocorrer se a máquina virtual foi protegida anteriormente e quando a replicação foi desabilitada, o disco de réplica não foi removido.
Exclua o disco de réplica identificado na mensagem de erro e tente novamente o trabalho de proteção com falha.
Este erro ocorre em máquinas Linux em que o disco do SO está encriptado utilizando o Azure Disk Encryption (ADE). Este é um problema válido apenas na versão 9.35 do Agente.
O instalador não consegue encontrar o disco raiz que hospeda o sistema de arquivos raiz.
Execute as seguintes etapas para corrigir esse problema.
Encontre os bits do agente no diretório /var/lib/waagent em máquinas RHEL usando o comando abaixo:
# find /var/lib/ -name Micro\*.gz
Resultado esperado:
/var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz
Crie um novo diretório e altere o diretório para esse novo diretório.
Extraia o arquivo do agente encontrado na primeira etapa aqui, usando o comando abaixo:
tar -xf <Tar Ball File>
Abra o arquivo prereq_check_installer.json e exclua as seguintes linhas. Salve o arquivo depois disso.
{
"CheckName": "SystemDiskAvailable",
"CheckType": "MobilityService"
},
Invoque o instalador usando o comando:
./install -d /usr/local/ASR -r MS -q -v Azure
Se o instalador for bem-sucedido, tente novamente habilitar o trabalho de replicação.
Este erro ocorre quando o tempo da máquina de origem avança e, em seguida, retrocede em pouco tempo, para corrigir a alteração. Você pode não notar a mudança, pois o tempo é corrigido muito rapidamente.
Como corrigir: Para resolver esse problema, aguarde até que o tempo do sistema cruze o tempo futuro enviesado. Outra opção é desabilitar e habilitar a replicação novamente, o que só é viável para replicação direta (dados replicados da região primária para a secundária) e não é aplicável para a replicação reversa (dados replicados da região secundária para a primária).
Replicar VMs do Azure para outra região do Azure.
Formação
Módulo
Planejar e implementar atualizações, backups e recuperação de desastres - Training
Planeje a recuperação de desastres.