Solução de problemas de replicação para VMs VMware e servidores físicos
Este artigo descreve alguns problemas comuns e erros específicos que você pode encontrar ao replicar VMs locais da VMware e servidores físicos no Azure usando o Site Recovery.
Etapa 1: Monitorar a integridade do servidor de processo
O Site Recovery usa o servidor de processo para receber e otimizar os dados replicados e enviá-los para o Azure.
Recomendamos que você monitore a integridade dos servidores de processo no portal, para garantir que eles estejam conectados e funcionando corretamente, e que a replicação esteja progredindo para os computadores de origem que estão associados ao servidor de processo.
- Saiba mais sobre como monitorar servidores de processo.
- Examinar as melhores práticas.
- Solucionar problemas de integridade do servidor de processo.
Etapa 2: Solucionar problemas de conectividade e replicação
Problemas de conectividade entre o servidor de origem e o servidor de processo ou entre o servidor de processo e o Azure geralmente causam falhas de replicação iniciais e contínuas.
Para resolver esses problemas, consulte Solucionar problemas de conectividade e de replicação.
Etapa 3: Solucionar problemas de computadores de origem que não estão disponíveis para replicação
Ao tentar selecionar o computador de origem para habilitar a replicação por meio do Azure Site Recovery, o computador pode não estar disponível para você por um dos seguintes motivos:
- Duas máquinas virtuais com o mesmo UUID de instância: se houver duas máquinas virtuais no vCenter com o mesmo UUID de instância, a primeira máquina virtual descoberta pelo servidor de configuração será mostrada no portal do Azure. Para resolver esse problema, assegure que não haja duas máquinas virtuais com o mesmo UUID de instância. Esse cenário é geralmente visto em instâncias em que uma VM de backup se torna ativa e é conectada aos nossos registros de descoberta. Consulte Azure Site Recovery – VMware para o Azure: Como limpar entradas duplicadas ou obsoletas para resolver esse problema.
- Credenciais incorretas de usuário do vCenter: Verifique se você adicionou as credenciais corretas do vCenter durante a configuração do servidor de configuração, usando o modelo OVF ou a configuração unificada. Para verificar as credenciais que você adicionou durante a instalação, consulte Modificar credenciais para a descoberta automática.
- Privilégios insuficientes do vCenter: Se as permissões fornecidas para acessar o vCenter não têm as permissões necessárias, pode ocorrer falha ao descobrir máquinas virtuais. Verifique se as permissões descritas em Preparar uma conta para a descoberta automática foram adicionadas à conta de usuário do vCenter.
- Servidores de gerenciamento do Azure Site Recovery: Se a máquina virtual for usada como o servidor de gerenciamento em uma ou mais das seguintes funções: servidor de Configuração/servidor de processo de expansão/servidor de destino Mestre, não será possível escolher a máquina virtual no portal. Servidores de gerenciamento não podem ser replicados.
- Já protegida/com failover por meio dos serviços do Azure Site Recovery: Se a máquina virtual já estiver protegida ou com failover por meio do Site Recovery, essa máquina virtual não estará disponível para seleção de proteção no portal. Verifique se a máquina virtual que você está procurando no portal já não está protegida por algum outro usuário ou sob uma assinatura diferente.
- vCenter não conectado: verifique se o vCenter está em um estado conectado. Para verificar isso, acesse o cofre dos Serviços de Recuperação > Infraestrutura do Site Recovery > Servidores de Configuração > clique no respectivo servidor de configuração > uma folha será aberta à direita com os detalhes dos servidores associados. Verifique se o vCenter está conectado. Se ele estiver em um estado “Não Conectado”, resolva o problema e, em seguida atualize o servidor de configuração no portal. Depois disso, a máquina virtual não é listada no portal.
- ESXi desligado: se o host ESXi no qual a máquina virtual reside estiver no estado desligado, a máquina virtual não é listada ou não pode ser selecionada no portal do Azure. Ligue o host ESXi e atualize o servidor de configuração no portal. Depois disso, a máquina virtual é listada no portal.
- Reinicialização pendente: se houver uma reinicialização pendente na máquina virtual, não será possível selecioná-la no portal do Azure. Conclua as atividades de reinicialização pendente e atualize o servidor de configuração. Depois disso, a máquina virtual é listada no portal.
- IP não encontrado ou Computador não tem endereço IP: Se a máquina virtual não tiver um endereço IP válido associado a ela, não é possível selecioná-la no portal do Azure. Atribua um endereço IP válido à máquina virtual e atualize o servidor de configuração. Também pode ser causado se o computador não tiver um endereço IP válido associado a um de seus NICs. Atribua um endereço IP válido a todos os NICs ou remova o NIC que não tem o IP. Depois disso, a máquina virtual é listada no portal.
Solucionar problemas de máquinas virtuais protegidas que estão esmaecidas no portal
As máquinas virtuais que são replicadas no Site Recovery não estão disponíveis no portal do Azure se há entradas duplicadas no sistema. Saiba mais sobre como excluir entradas obsoletas e resolver o problema.
Outro motivo pode ser que o computador tenha sido clonado. Quando os computadores se movem pelo hipervisor e se a ID do BIOS é alterada, o agente de mobilidade bloqueará a replicação. A replicação de computadores clonados não tem suporte do Site Recovery.
Nenhum ponto de recuperação consistente de falha disponível para a VM nos últimos “XXX” minutos
Veja a seguir uma lista de alguns dos problemas mais comuns:
Problemas de replicação inicial [erro 78169]
Na parte superior acima, para verificar se não há problemas relacionados à conectividade, largura de banda ou sincronização de tempo, verifique se:
- Nenhum software antivírus está bloqueando o Azure Site Recovery. Saiba mais sobre exclusões de pasta necessárias para o Azure Site Recovery.
Computadores de origem com variação alta [erro 78188]
Causas possíveis:
- A taxa de alteração de dados (bytes de gravação/s) nos discos listados da máquina virtual é mais do que os limites com suporte do Azure Site Recovery para o tipo de conta de armazenamento de destino de replicação.
- Há um pico repentino na taxa de rotatividade em função do qual uma grande quantidade de dados está pendente para upload.
Para resolver o problema:
Verifique se o tipo de conta de armazenamento de destino (Standard ou Premium) é provisionado de acordo com o requisito de taxa de rotatividade na origem.
Se você já estiver replicando para um disco gerenciado Premium (tipo asrseeddisk), verifique se o tamanho do disco dá suporte à taxa de rotatividade observada de acordo com os limites do Site Recovery. Você pode aumentar o tamanho do asrseeddisk, se necessário. Siga estas etapas:
- Navegue até a folha Discos da máquina replicada afetada e copie o nome do disco de réplica
- Navegar até este disco gerenciado de réplica
- Você poderá ver uma faixa na folha Visão Geral dizendo que uma URL SAS foi gerada. Clique nessa faixa e cancele a exportação. Ignore esta etapa se você não vir a faixa.
- Assim que a URL SAS for revogada, vá para a folha de Configuração do Disco Gerenciado e aumente o tamanho para que o Azure Site Recovery dê suporte à rotatividade observada no disco de origem.
Se a variação observada for temporária, aguarde algumas horas para que o carregamento de dados pendente seja atualizado e crie pontos de recuperação.
Se o disco contiver dados não críticos, como logs temporários, dados de teste, etc., considere mover esses dados para outro lugar ou exclua completamente este disco da replicação
Se o problema persistir, use o planejador de implantação do Site Recovery para ajudar a planejar a replicação.
Computadores de origem sem pulsação [erro 78174]
Isso acontece quando o agente de Mobilidade do Azure Site Recovery no computador de origem está se comunicando com o Servidor de Configuração (CS).
Para resolver o problema, use as seguintes etapas para verificar a conectividade de rede da VM de origem no Servidor de Configuração:
Verifique se a Máquina de Origem está funcionando.
Entre no Computador de Origem usando uma conta que tenha privilégios de administrador.
Verifique se os seguintes serviços estão em execução e, se não estiverem, reinicie os serviços:
- Svagents (agente do InMage Scout VX)
- Serviço de Aplicativo InMage Scout
No Computador de Origem, examine os logs no local para obter os detalhes do erro:
C:\Program Files (X86)\Microsoft Azure Site Recovery\agent\svagents*.log
Servidor de processo sem pulsação [erro 806]
Caso não haja nenhuma pulsação no Servidor de Processo, verifique se:
A VM do servidor de processo está em execução
Verifique os seguintes logs no Servidor de Processo para obter detalhes do erro:
C:\ProgramData\ASR\home\svsystems\eventmanager*.log
e
C:\ProgramData\ASR\home\svsystems\monitor_protection*.log
Servidor do destino mestre sem pulsação [erro 78022]
Isso acontece quando o agente de Mobilidade do Azure Site Recovery no Destino Mestre não está se comunicando com o Servidor de Configuração.
Para resolver o problema, use as seguintes etapas para verificar o status do serviço:
Verifique se o Destino Mestre está em execução.
Entre na VM do Destino Mestre usando uma conta que tenha privilégios de administrador.
Verifique se o serviço svagents está em execução. Se estiver em execução, reinicie o serviço
Verifique os logs no local para obter detalhes do erro:
C:\Program Files (X86)\Microsoft Azure Site Recovery\agent\svagents*.log
Para registrar o destino mestre no servidor de configuração, navegue até a pasta %PROGRAMDATA%\ASR\Agent e execute o seguinte no prompt de comando:
cmd cdpcli.exe --registermt net stop obengine net start obengine exit
A proteção não pôde ser habilitada com êxito para a máquina virtual [erro 78253]
Esse erro poderá ocorrer se uma política de replicação não tiver sido associada corretamente ao servidor de configuração. Também pode ocorrer se a política associada ao servidor de configuração não for válida.
Para confirmar a causa desse erro, navegue até o cofre de recuperação > gerenciar Infraestrutura do Site Recovery e, em seguida, exiba as políticas de replicação para máquinas físicas e VMware para marcar o status das políticas configuradas.
Para resolve o problema, você pode associar a política ao servidor de configuração em uso ou criar uma nova política de replicação e associá-la. Se a política for inválida, você poderá desassociar e excluí-la.
ID do erro 78144 — nenhum ponto de recuperação consistente com o aplicativo disponível para a VM nos últimos “XXX” minutos
Foram feitas melhorias nas versões do agente de mobilidade 9.23 e 9.27 para lidar com os comportamentos de falha de instalação do VSS. Verifique se você está nas versões mais recentes para obter a melhor orientação sobre a solução de falhas do VSS.
Alguns dos problemas mais comuns estão listados a seguir:
Causa 1: Problema conhecido no SQL Server 2008/2008 R2
Como corrigir: há um problema conhecido no SQL Server 2008/2008 R2. Consulte este artigo da base de dados Agente do Azure Site Recovery ou outro backup do VSS de não componentes falha para um servidor que hospeda o SQL Server 2008 R2
Causa 2: Os trabalhos do Azure Site Recovery trabalhos falham nos servidores que hospedam qualquer versão das instâncias do SQL Server com bancos AUTO_CLOSE
Como corrigir : consulte o artigo da base de dados
Como corrigir : Consulte o artigo da base de dados
Causa 3: Problema conhecido no SQL Server 2016 e 2017
Como corrigir : consulte o artigo da base de dados
Causa 4: Consistência do aplicativo não habilitada em servidores do Linux
Como corrigir : o Azure Site Recovery para o Sistema Operacional Linux dá suporte a scripts personalizados de aplicativo para consistência de aplicativo. As opções de scripts prévios e posteriores serão usadas pelo Agente de Mobilidade do Azure Site Recovery para consistência do aplicativo. Veja aqui as etapas para habilitá-lo.
Mais causas devido a problemas relacionados ao VSS:
Para solucionar mais problemas, verifique os arquivos no computador de origem para obter o código de erro exato para a falha:
C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\Application Data\ApplicationPolicyLogs\vacp.log
Como localizar os erros no arquivo? Procure a cadeia de caracteres "vacpError" abrindo o arquivo vacp.log em um editor
Ex:
vacpError
:220#Following disks are in FilteringStopped state [\\.\PHYSICALDRIVE1=5, ]#220|^|224#FAILED: CheckWriterStatus().#2147754994|^|226#FAILED to revoke tags.FAILED: CheckWriterStatus().#2147754994|^|
No exemplo anterior, 2147754994 é o código de erro que informa sobre a falha, conforme mostrado:
O gravador VSS não está instalado — erro 2147221164
Como corrigir: para gerar uma marca de consistência do aplicativo, o Azure Site Recovery usa o VSS (Serviço de Cópias de Sombra de Volume) da Microsoft. Ele instala um provedor do VSS para sua operação para obter instantâneos da consistência do aplicativo. Este provedor do VSS é instalado como um serviço. Caso o serviço do provedor do VSS não esteja instalado, a criação do instantâneo de consistência do aplicativo falha com a ID de erro 0x80040154 "Classe não registrada".
Consulte o artigo para solução de problemas de instalação do gravador VSS
O gravador VSS está desabilitado — Erro 2147943458
Como corrigir: para gerar uma marca de consistência do aplicativo, o Azure Site Recovery usa o VSS (Serviço de Cópias de Sombra de Volume) da Microsoft. Ele instala um provedor do VSS para sua operação para obter instantâneos da consistência do aplicativo. Este provedor do VSS é instalado como um serviço. Caso o serviço do provedor do VSS esteja desabilitado, a criação do instantâneo de consistência do aplicativo falha com a ID de erro “O serviço especificado está desabilitado e não pode ser iniciado (0x80070422)”.
- Se o VSS estiver desabilitado,
- Verifique se o tipo de inicialização do serviço do provedor do VSS está definido como Automático.
- Reinicie os seguintes serviços:
- Serviço de Cópias de Sombra de Volume
- Provedor de VSS do Azure Site Recovery
- Serviço VDS
VSS PROVIDER NOT_REGISTERED - Error 2147754756
Como corrigir: para gerar uma marca de consistência do aplicativo, o Azure Site Recovery usa o VSS (Serviço de Cópias de Sombra de Volume) da Microsoft.
Verifique se o serviço do Provedor do VSS do Azure Site Recovery está instalado.
- Repita a instalação do provedor usando os seguintes comandos:
- Desinstalar o provedor existente: C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Uninstall.cmd
- Reinstalar: C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\InMageVSSProvider_Install.cmd
Verifique se o tipo de inicialização do serviço do provedor do VSS está definido como Automático. – Reinicie os seguintes serviços: – serviço VSS – Provedor do VSS do Azure Site Recovery – serviço VDS
ID de erro 95001 - Permissões insuficientes encontradas
Esse erro ocorre quando você tenta habilitar a replicação e as pastas do aplicativo não têm permissões suficientes.
Como corrigir: para resolver esse problema, verifique se o usuário IUSR tem função de proprietário para todas as pastas seguintes -
- C\ProgramData\Microsoft Azure Site Recovery\private
- O diretório de instalação. Por exemplo, se o diretório de instalação for a unidade F, forneça as permissões corretas para:
- F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems
- A pasta \pushinstallsvc no diretório de instalação. Por exemplo, se o diretório de instalação for a unidade F, forneça as permissões corretas para -
- F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\pushinstallsvc
- A pasta \etc no diretório de instalação. Por exemplo, se o diretório de instalação for a unidade F, forneça as permissões corretas para -
- F:\Program Files (x86)\Microsoft Azure Site Recovery\home\svsystems\etc
- C:\Temp
- C:\thirdparty\php5nts
- Todos os itens no caminho a seguir -
- C:\thirdparty\rrdtool-1.2.15-win32-perl58\rrdtool\Release*
Solucionar problemas e lidar com alterações de hora em servidores replicados
Esse erro ocorre quando a hora do computador de origem avança e, em seguida, volta em pouco tempo para corrigir a alteração. Talvez você não perceba a alteração, pois a hora é corrigida rapidamente.
Como corrigir: Para resolver esse problema, aguarde até que a hora do sistema atinja a hora futura distorcida. Outra opção é desabilitar e habilitar a replicação novamente, o que só é viável para a replicação direta (dados replicados do local para o Azure) e não se aplica à replicação reversa (dados replicados do Azure para o local).
Próximas etapas
Se precisar de mais ajuda, poste sua pergunta na página do Microsoft Q&A para o Azure Site Recovery. Temos uma comunidade ativa e um dos nossos engenheiros poderá ajudá-lo.