Partilhar via

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

  • Artigo

Este artigo descreve como solucionar problemas que você pode encontrar ao fazer failback de VMs do Azure para sua infraestrutura VMware local, após failover para o Azure usando o Azure Site Recovery.

O failback envolve essencialmente duas etapas principais. Para a primeira etapa, após o failover, você precisa reproteger as VMs do Azure para o local para que elas comecem a replicar. A segunda etapa é executar um failover do Azure para fazer failover de volta ao seu site local.

Problemas comuns

  • Se você executar uma descoberta do vCenter de usuário somente leitura e proteger máquinas virtuais, a proteção será bem-sucedida e o failover funcionará. Durante a reproteção, o failover falha porque os armazenamentos de dados não podem ser descobertos. Um sintoma é que os armazenamentos de dados não são listados durante a reproteção. Para resolver esse problema, você pode atualizar as credenciais do vCenter com uma conta apropriada que tenha permissões e, em seguida, tente novamente o trabalho.
  • Quando você faz failback de uma máquina virtual Linux e a executa localmente, você pode ver que o pacote do Network Manager foi desinstalado da máquina. Essa desinstalação ocorre porque o pacote do Network Manager é removido quando a máquina virtual é recuperada no Azure.
  • Quando uma máquina virtual Linux é configurada com um endereço IP estático e é transferida para o Azure, o endereço IP é adquirido do DHCP. Quando você faz failover para o local, a máquina virtual continua a usar DHCP para adquirir o endereço IP. Inicie sessão manualmente na máquina e, em seguida, defina o endereço IP de volta para um endereço estático, se necessário. Uma máquina virtual do Windows pode adquirir seu endereço IP estático novamente.
  • Se você usar a edição gratuita do ESXi 5.5 ou a edição livre do hipervisor vSphere 6, o failover será bem-sucedido, mas o failback não terá êxito. Para habilitar o failback, 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 processo, utilize Telnet para verificar a conectividade com o servidor de configuração na porta 443. Você também pode tentar executar ping no servidor de configuração a partir do servidor de processo. Um servidor de processo também deve ter uma pulsação quando estiver conectado ao servidor de configuração.
  • Um servidor Windows Server 2008 R2 SP1 protegido como um servidor físico local não pode ser submetido a falha de volta do Azure para um site local.
  • Não é possível fazer failback nas seguintes circunstâncias:
    • Você migrou máquinas para o Azure.
    • Você moveu uma VM para outro grupo de recursos.
    • Você excluiu a VM do Azure.
    • Você desabilitou a proteção da VM.
    • Você criou a VM manualmente no Azure. A máquina deve ter sido inicialmente protegida no local e feito failover para o Azure antes da reproteção.
    • Você pode falhar apenas em um host ESXi. Não é possível fazer failback de VMs VMware ou servidores físicos para hosts Hyper-V, máquinas físicas ou estações de trabalho VMware.

Solucionar erros de reproteção

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

Código de erro 95226

Reprotect falhou porque a máquina virtual do Azure não conseguiu alcançar o servidor de configuração 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 de serviço está definido como Automático.

Código de erro 78052

Não foi possível concluir a proteção para a 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á respondendo 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 armazenamento de dados não é acessível a partir do host 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 seção descreve erros comuns que você pode encontrar durante o failback.

Código de erro 8038

Falha ao abrir a máquina virtual local devido ao erro.

Esse problema acontece quando a VM local é exibida em um host que não tem memória suficiente provisionada.

Para resolver este problema:

  • Provisione mais memória no host ESXi.
  • Além disso, você pode usar o VMotion para mover a VM para outro host ESXi que tenha memória suficiente para inicializar a VM.