Resolver erros de replicação de VMs do Azure para Azure

  • Artigo

Atenção

Este artigo faz referência ao CentOS, uma distribuição Linux que está se aproximando do status de Fim da Vida Útil (EOL). Por favor, considere o seu uso e planeje de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.

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.

Problemas de cota de recursos do Azure (código de erro 150097)

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>.

Causas possíveis

  • O ID da subscrição não está ativado para criar VMs na localização da região de destino.
  • O ID da subscrição não está ativado ou não tem quota suficiente para criar tamanhos específicos de VM na localização da região de destino.
  • Não foi encontrado nenhuma VM com o tamanho adequado correspondente à contagem (2) do cartão da interface de rede (NIC) da VM para o ID da subscrição na localização da região de destino.

Corrigir o problema

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.

Certificados raiz confiáveis (código de erro 151066)

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.

Causa possível

Os certificados raiz confiáveis necessários para autorização e autenticação não estão presentes na máquina virtual.

Corrigir o problema

Windows

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.

  • Se você estiver em um ambiente desconectado, siga o processo padrão de atualização do Windows em sua organização para obter os certificados.
  • Se os certificados necessários não estiverem presentes na VM, as chamadas para o serviço de Recuperação de Site falharão por motivos de segurança.

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.

Linux

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:

  1. Inicie sessão como utilizador root . O símbolo de hash (#) é a linha de comandos predefinida.

  2. Para alterar o diretório, execute este comando:

    cd /etc/ssl/certs

  3. 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

  4. 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

  5. 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

  6. Para atualizar os hashes do requerente do certificado para os certificados recentemente transferidos, execute o script rehash:

    c_rehash

  7. 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

  8. 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

  9. Crie uma cópia do arquivo Baltimore_CyberTrust_Root.pem com o nome de arquivo 653b494a.0:

    cp Baltimore_CyberTrust_Root.pem 653b494a.0

  10. 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

  11. 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

URLs de saída ou intervalos de IP (código de erro 151037 ou 151072)

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.

Causas possíveis

  • Não é possível estabelecer uma conexão com pontos de extremidade de Recuperação de Site devido a uma falha de resolução do DNS (Sistema de Nomes de Domínio).
  • Esse problema é mais comum durante a reproteção quando você fez failover na máquina virtual, mas o servidor DNS não está acessível a partir da região de recuperação de desastres (DR).

Corrigir o problema

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:

  1. Abra Máquinas virtuais e selecione a VM.
  2. Navegue até Configurações de VMs e selecione Rede.
  3. Em Rede virtual/sub-rede, selecione o link para abrir a página de recursos da rede virtual.
  4. Vá para Configurações e selecione Servidores DNS.

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.

com-erro.

Problema 2: Falha na configuração da Recuperação de Site (151196)

Causa possível

Não é possível estabelecer uma conexão com pontos de extremidade IP4 de autenticação e identidade do Microsoft 365.

Corrigir o problema

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.

Problema 3: Falha na configuração da Recuperação de Site (151197)

Causa possível

Não é possível estabelecer uma conexão com os pontos de extremidade do serviço Azure Site Recovery.

Corrigir o problema

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.

Problema 4: A replicação falha quando o tráfego de rede usa o servidor proxy local (151072)

Causa possível

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 (IE).

Corrigir o problema

  1. O agente do serviço de mobilidade deteta as configurações de proxy do IE no Windows e /etc/environment no Linux.

  2. 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:

    • Linux: /usr/local/InMage/config/
    • Janelas: C:\ProgramData\Microsoft Azure Site Recovery\Config

  3. 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.

Mais informações

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.

Disco não encontrado na VM (código de erro 150039)

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.

Causas possíveis

  • Um novo disco de dados foi anexado à VM, mas não foi inicializado.
  • O disco de dados dentro da VM não está relatando corretamente o valor de número de unidade lógica (LUN) no qual o disco foi anexado à VM.

Corrigir o problema

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.

Vários discos disponíveis para proteção (código de erro 153039)

Causas possíveis

  • Um ou mais discos foram adicionados recentemente à máquina virtual após a proteção.
  • Um ou mais discos foram inicializados após a proteção da máquina virtual.

Corrigir o problema

Para tornar o status de replicação da VM íntegro novamente, você pode optar por proteger os discos ou descartar o aviso.

Para proteger os discos

  1. Vá para Discos de nome> da VM de Itens>Replicados.

  2. Selecione o disco desprotegido e, em seguida, selecione Ativar replicação:

    Habilite a replicação em discos de VM.

Para rejeitar a advertência

  1. Vá para Nome da VM de itens>replicados.

  2. Selecione o aviso na seção Visão geral e, em seguida, selecione OK.

    Dispense o aviso de novo disco.

VM removida do cofre concluída com informações (código de erro 150225)

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:

  • Quando você habilita a replicação por meio do cofre dos Serviços de Recuperação, a máquina virtual não será listada.
  • Se você tentar proteger a VM usando a recuperação de desastres de configurações>da máquina>virtual, a operação falhará com a mensagem A replicação não pode ser habilitada devido aos links de recursos obsoletos existentes na VM.

Corrigir o problema

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.

  1. 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:

    Remova o bloqueio da VM.

  2. Baixe o script para remover uma configuração obsoleta do Site Recovery.

  3. 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.

  4. Se você for solicitado a fornecer credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.

Replicação não habilitada em VM com recursos obsoletos (código de erro 150226)

Causas possíveis

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:

  • Você desabilitou a replicação, mas a VM de origem tinha um bloqueio de recurso.
  • Você excluiu o cofre do Site Recovery sem desabilitar explicitamente a replicação na VM.
  • Você excluiu o grupo de recursos que contém o cofre de Recuperação de Site sem desabilitar explicitamente a replicação na VM.

Corrigir o problema

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.

  1. 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:

    Remova o bloqueio da VM.

  2. Baixe o script para remover uma configuração obsoleta do Site Recovery.

  3. 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.

  4. Se você for solicitado a fornecer credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.

Não é possível selecionar VM ou grupo de recursos no trabalho de habilitação de replicação

Problema 1: O grupo de recursos e a VM de origem estão em locais diferentes

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.

Problema 2: O grupo de recursos não faz parte da assinatura selecionada

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.

Problema 3: Configuração obsoleta

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:

  • Você excluiu o cofre do Site Recovery sem desabilitar explicitamente a replicação na VM.
  • Você excluiu o grupo de recursos que contém o cofre de Recuperação de Site sem desabilitar explicitamente a replicação na VM.
  • Você desabilitou a replicação, mas a VM de origem tinha um bloqueio de recurso.

Corrigir o problema

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.

  1. 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:

    Remova o bloqueio da VM.

  2. Baixe o script para remover uma configuração obsoleta do Site Recovery.

  3. 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.

  4. Se você for solicitado a fornecer credenciais do Azure, forneça-as. Em seguida, verifique se o script é executado sem falhas.

Não é possível selecionar uma VM para proteção

Causa possível

A máquina virtual tem uma extensão instalada em um estado de falha ou sem resposta

Corrigir o problema

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.

O estado de provisionamento da VM não é válido (código de erro 150019)

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:

  1. No portal do Azure, selecione o Explorador de Recursos em Todos os Serviços.
  2. Expanda a lista Subscrições e selecione a sua subscrição.
  3. Expanda a lista ResourceGroups e selecione o grupo de recursos da VM.
  4. Expanda a lista Recursos e selecione sua VM.
  5. Verifique o campo provisioningState na visualização de instância no lado direito.

Corrigir o problema

  • Se o provisioningState for Failed, entre em contato com o suporte com detalhes para solucionar problemas.
  • Se o provisioningState estiver atualizando, outra extensão pode estar sendo implantada. Verifique se há operações em andamento na VM, aguarde a conclusão delas e tente novamente o trabalho de Recuperação de Site com falha para habilitar a replicação.

Não é possível selecionar a VM de destino

Problema 1: A VM está conectada a uma rede que já está mapeada para uma rede de destino

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.

Lista de seleção de rede indisponível.

Problema 2: Você protegeu anteriormente a VM e, em seguida, desabilitou a replicaçã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.

Exclua o mapeamento de rede.

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:

Modifique o mapeamento de rede.

COM+ ou VSS (código de erro 151025)

Quando o erro COM+ ou Volume Shadow Copy Service (VSS) ocorre, a seguinte mensagem é exibida:

Site Recovery extension failed to install.

Causas possíveis

  • O serviço Aplicativo do Sistema COM+ está desabilitado.
  • O Serviço de Cópias de Sombra de Volume está desativado.

Corrigir o problema

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.

  1. Abra a consola Serviços no Windows.

  2. 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.

    Verifique o tipo de inicialização do COM mais o Aplicativo do Sistema e o Serviço de Cópias de Sombra de Volume.

Tamanho do disco gerenciado não suportado (código de erro 150172)

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.

Causa possível

O disco é menor do que o tamanho suportado de 1024 MB.

Corrigir o problema

Certifique-se de que o tamanho do disco está dentro do intervalo de tamanho suportado e, em seguida, tente novamente a operação.

Proteção não ativada quando o GRUB usa o nome do dispositivo (código de erro 151126)

Causas possíveis

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

Corrigir o problema

Substitua cada nome de dispositivo pelo UUID correspondente:

  1. 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"

  2. 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

  3. Tente novamente a proteção.

A proteção falhou porque o dispositivo GRUB não existe (código de erro 151124)

Causa possível

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 rootvgde volumes.

Corrigir o problema

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.

Atualização do serviço de mobilidade concluída com avisos (código de erro 151083)

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.

Proteção não ativada se existir disco gerenciado por réplica

Esse erro ocorre quando o disco gerenciado pela réplica já existe, sem marcas esperadas, no grupo de recursos de destino.

Causa possível

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.

Corrigir o problema

Exclua o disco de réplica identificado na mensagem de erro e tente novamente o trabalho de proteção com falha.

Falha ao ativar a proteção, pois o instalador não consegue encontrar o disco raiz (código de erro 151137)

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.

Causas Possíveis

O instalador não consegue encontrar o disco raiz que hospeda o sistema de arquivos raiz.

Corrigir o problema

Execute as seguintes etapas para corrigir esse problema.

  1. Encontre os bits do agente sob o diretório /var/lib/waagent em máquinas RHEL e CentOS 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

  2. Crie um novo diretório e altere o diretório para esse novo diretório.

  3. Extraia o arquivo do agente encontrado na primeira etapa aqui, usando o comando abaixo:

    tar -xf <Tar Ball File>

  4. Abra o arquivo prereq_check_installer.json e exclua as seguintes linhas. Salve o arquivo depois disso.

       {
      "CheckName": "SystemDiskAvailable",
      "CheckType": "MobilityService"
   },

  5. Invoque o instalador usando o comando:

    ./install -d /usr/local/ASR -r MS -q -v Azure

  6. Se o instalador for bem-sucedido, tente novamente habilitar o trabalho de replicação.

Solucionar problemas e lidar com alterações de tempo em servidores replicados

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).

Próximos passos

Replicar VMs do Azure para outra região do Azure.