Resolver problemas de reativação pós-falha no local a partir do Azure

  • Artigo

Este artigo descreve como resolver problemas que poderá encontrar quando efetua a reativação pós-falha de VMs do Azure para a sua infraestrutura VMware no local, após a ativação pós-falha para o Azure com o Azure Site Recovery.

A reativação pós-falha envolve essencialmente dois passos principais. Para o primeiro passo, após a ativação pós-falha, tem de voltar a proteger as VMs do Azure para o local para que comecem a replicar. O segundo passo é executar uma ativação pós-falha do Azure para efetuar a reativação pós-falha para o seu site no local.

Problemas comuns

  • Se efetuar uma deteção do vCenter de utilizador só de leitura e proteger máquinas virtuais, a proteção é bem-sucedida e a ativação pós-falha funciona. Durante a nova proteção, a ativação pós-falha falha porque os arquivos de dados não podem ser detetados. Um sintoma é que os arquivos de dados não são listados durante a nova proteção. Para resolver este problema, pode atualizar as credenciais do vCenter com uma conta adequada que tenha permissões e, em seguida, repetir a tarefa.
  • Quando efetua a reativação pós-falha de uma máquina virtual do Linux e a executa no local, pode ver que o pacote do Gestor de Rede foi desinstalado do computador. Esta desinstalação ocorre porque o pacote do Gestor de Rede é removido quando a máquina virtual é recuperada no Azure.
  • Quando uma máquina virtual do Linux é configurada com um endereço IP estático e é efetuada a ativação pós-falha para o Azure, o endereço IP é adquirido ao DHCP. Quando efetua a ativação pós-falha para o local, a máquina virtual continua a utilizar o DHCP para adquirir o endereço IP. Inicie sessão manualmente no computador e, em seguida, defina o endereço IP novamente para um endereço estático, se necessário. Uma máquina virtual do Windows pode adquirir novamente o respetivo endereço IP estático.
  • Se utilizar a edição gratuita ESXi 5.5 ou a edição gratuita do Hypervisor vSphere 6, a ativação pós-falha é bem-sucedida, mas a reativação pós-falha não é bem-sucedida. Para ativar a reativação pós-falha, atualize para a licença de avaliação de qualquer um dos programas.
  • Se não conseguir aceder ao servidor de configuração a partir do servidor de processos, utilize Telnet para verificar a conectividade ao servidor de configuração na porta 443. Também pode tentar enviar ping ao servidor de configuração a partir do servidor de processos. Um servidor de processos também deve ter um heartbeat quando está ligado ao servidor de configuração.
  • Não é possível efetuar a reativação pós-falha de um servidor físico no local do Azure para um site no local do Windows Server 2008 R2 SP1 protegido como um servidor físico no local.
  • Não pode efetuar a reativação pós-falha nas seguintes circunstâncias:
    • Migrou máquinas para o Azure.
    • Moveu uma VM para outro grupo de recursos.
    • Eliminou a VM do Azure.
    • Desativou a proteção da VM.
    • Criou a VM manualmente no Azure. O computador deveria ter sido inicialmente protegido no local e efetuado a ativação pós-falha para o Azure antes da nova proteção.
    • Só pode falhar num anfitrião ESXi. Não pode efetuar a reativação pós-falha de VMs VMware ou servidores físicos para anfitriões Hyper-V, máquinas físicas ou estações de trabalho VMware.

Resolver erros de nova proteção

Esta secção detalha os erros comuns de reproteção e como corrigi-los.

Código de erro 95226

A nova proteção falhou porque a máquina virtual do Azure não conseguiu aceder ao servidor de configuração no local.

Este erro ocorrerá quando:

  • A VM do Azure não consegue aceder ao servidor de configuração no local. Não é possível detetar e registar a VM no servidor de configuração.
  • O serviço de aplicação InMage Scout não está a ser executado na VM do Azure após a ativação pós-falha. O serviço é necessário para as comunicações com o servidor de configuração no local.

Para resolver este problema:

  • Confirme se a rede de VMs do Azure permite que a VM do Azure comunique com o servidor de configuração no local. Pode configurar uma VPN site a site para o datacenter no local ou configurar uma ligação do Azure ExpressRoute com peering privado na rede virtual da VM do Azure.
  • Se a VM conseguir comunicar com o servidor de configuração no local, inicie sessão na VM. Em seguida, verifique o serviço de aplicação do InMage Scout. Se vir que não está a ser executado, inicie o serviço manualmente. Verifique se o tipo de início do serviço está definido como Automático.

Código de erro 78052

Não foi possível concluir a proteção da máquina virtual.

Este problema poderá ocorrer se já existir uma VM com o mesmo nome no servidor de destino principal no qual está a efetuar a reativação pós-falha.

Para resolver este problema:

  • Selecione um servidor de destino diferente num anfitrião diferente para que a nova proteção crie a máquina virtual num anfitrião diferente, onde os nomes não entram em conflito.
  • Também pode utilizar o VMotion para mover o destino principal para um anfitrião diferente, onde não ocorrerá o conflito entre os nomes. Se a VM existente for uma máquina virtual em branco, atribua-lhe um novo nome para que a nova VM possa ser criada no mesmo anfitrião ESXi.

Código de erro 78093

A VM não está em execução, não está a responder ou não está acessível.

Para resolver este problema:

Para voltar a proteger uma VM onde foi efetuada uma ativação pós-falha, a VM do Azure tem de estar a funcionar de modo a que o Serviço de Mobilidade faça o registe com o servidor de configuração no local e possa iniciar a replicação ao comunicar com o servidor de processos. Se a máquina virtual estiver numa rede incorreta ou não estiver a funcionar (não responde ou encerra), o servidor de configuração não poderá aceder ao Serviço de Mobilidade na VM para iniciar a nova proteção.

  • Reinicie a VM para que possa começar a comunicar no local.
  • Reinicie o trabalho de nova proteção depois de iniciar a máquina virtual do Azure.

Código de erro 8061

O arquivo de dados não está acessível a partir do anfitrião ESXi.

Verifique os pré-requisitos do destino principal e os arquivos de dados suportados para a reativação pós-falha.

Resolver erros de reativação pós-falha

Esta secção descreve erros comuns que poderá encontrar durante a reativação pós-falha.

Código de erro 8038

Falha ao apresentar a máquina virtual no local devido ao erro.

Este problema ocorre quando a VM no local é criada num anfitrião que não tem memória suficiente aprovisionada.

Para resolver este problema:

  • Aprovisionar mais memória no anfitrião ESXi.
  • Além disso, pode utilizar o VMotion para mover a VM para outro anfitrião ESXi que tenha memória suficiente para iniciar a VM.