Solucionar problemas do servidor de processo

  • Artigo

O servidor de processo do Site Recovery é usado quando você configura a recuperação de desastres para o Azure para VMs VMware locais e servidores físicos. Este artigo descreve como solucionar problemas no servidor de processo, incluindo problemas de replicação e conectividade.

Saiba mais sobre o servidor de processo.

Antes de começar

Antes de iniciar a solução de problemas:

  1. Verifique se você entendeu como monitorar os servidores de processo.
  2. Revise as práticas recomendadas abaixo.
  3. Siga as considerações sobre capacidade e use as diretrizes de dimensionamento para o servidor de configuração ou os servidores de processo autônomo.

Práticas recomendadas para a implantação do servidor de processo

Para ter um desempenho ideal dos servidores de processo, resumimos várias práticas recomendadas gerais.

Prática recomendada Detalhes
Usage Verifique se o servidor de configuração/servidor de processo autônomo só é usado para a finalidade pretendida. Não execute nada mais no computador.
Endereço IP Verifique se o servidor de processo tem um endereço IPv4 estático e se o NAT não está configurado.
Controlar a memória/uso da CPU Mantenha o uso da CPU e da memória em 70%.
Garantir espaço livre Espaço livre refere-se ao espaço em disco de cache no servidor de processo. Os dados de replicação são armazenados no cache antes de serem carregados no Azure.

Mantenha o espaço livre acima de 25%. Se ficar abaixo de 20%, a replicação será limitada para os computadores replicados associados ao servidor de processo.

Verificar integridade do servidor de processo

A primeira etapa da solução de problemas é verificar a integridade e o status do servidor de processo. Para fazer isso, examine todos os alertas, verifique se os serviços necessários estão em execução e se há uma pulsação no servidor de processo. Essas etapas são resumidas no gráfico a seguir, seguidas por procedimentos para ajudar a executá-las.

Troubleshoot process server health

Etapa 1: Solucionar problemas de alertas da integridade do servidor de processo

O servidor de processo gera vários alertas de integridade. Esses alertas e as ações recomendadas são resumidos na tabela a seguir.

Tipo de alerta Erro Solucionar problemas
Healthy Nenhum O servidor de processo está conectado e íntegro.
Warning Os serviços especificados não estão em execução. 1. Verifique se os serviços estão em execução.
2. Se os serviços estiverem sendo executados conforme o esperado, siga as instruções abaixo para solucionar problemas de conectividade e replicação.
Warning Utilização da CPU > 80% nos últimos 15 minutos. 1. Não adicione novos computadores.
2. Verifique se o número de VMs que usam o servidor de processo está alinhado com os limites definidos e considere configurar um servidor de processo adicional.
3. Siga as instruções abaixo para solucionar problemas de conectividade e replicação.
Critical Utilização da CPU > 95% nos últimos 15 minutos. 1. Não adicione novos computadores.
2. Verifique se o número de VMs que usam o servidor de processo está alinhado com os limites definidos e considere configurar um servidor de processo adicional.
3. Siga as instruções abaixo para solucionar problemas de conectividade e replicação.
4. Se o problema persistir, execute o Planejador de Implantações para a replicação do VMware/servidor físico.
Warning Uso de memória > 80% nos últimos 15 minutos. 1. Não adicione novos computadores.
2. Verifique se o número de VMs que usam o servidor de processo está alinhado com os limites definidos e considere configurar um servidor de processo adicional.
3. Siga as instruções associadas ao aviso.
4. Se o problema persistir, siga as instruções abaixo para solucionar problemas de conectividade e replicação.
Critical Uso de memória > 95% nos últimos 15 minutos. 1. Não adicione novos computadores e considere a configuração de um servidor de processo adicional.
2. Siga as instruções associadas ao aviso.
3. 4. Se o problema continuar, siga as instruções abaixo para solucionar problemas de conectividade e replicação.
4. Se o problema persistir, execute o Planejador de Implantações para os problemas de replicação do VMware/servidor físico.
Warning Espaço livre na pasta de cache < 30% nos últimos 15 minutos. 1. Não adicione novos computadores e considere a configuração de um servidor de processo adicional.
2. Verifique se o número de VMs que usam o servidor de processo se alinha com as diretrizes.
3. Siga as instruções abaixo para solucionar problemas de conectividade e replicação.
Critical Espaço livre < 25% nos últimos 15 minutos 1. Siga as instruções associadas ao aviso para resolver o problema.
2. 3. Siga as instruções abaixo para solucionar problemas de conectividade e replicação.
3. Se o problema persistir, execute o Planejador de Implantações para a replicação do VMware/servidor físico.
Critical Não há pulsação no servidor de processo por 15 minutos ou mais. O serviço tmansvs não está comunicando com o servidor de configuração. 1) Verifique se o servidor de processo está em execução.
2. Verifique se o tmansvc está em execução no servidor de processo.
3. Siga as instruções abaixo para solucionar problemas de conectividade e replicação.

Table key

Etapa 2: Verificar serviços do servidor de processo

Os serviços que devem estar em execução no servidor de processo são resumidos na tabela a seguir. Há pequenas diferenças nos serviços, dependendo de como o servidor de processo é implantado.

Para todos os serviços, exceto o obengine (Agente de Serviços de Recuperação do Microsoft Azure), verifique se o StartType está definido para Automático ou Automático (Início Atrasado) .

Implantação Serviços em execução
Servidor de processo no servidor de configuração ProcessServer; ProcessServerMonitor; cxprocessserver; InMage PushInstall; Serviço de Upload de Log (LogUpload); Serviço de Aplicativo do InMage Scout; Agente de Serviços de Recuperação do Microsoft Azure (obengine); InMage Scout VX Agent-Sentinel/Outpost (svagents); tmansvc; Serviço de Publicação na World Wide Web (W3SVC); MySQL; Serviço do Microsoft Azure Site Recovery (dra)
Servidor de processo em execução como um servidor autônomo ProcessServer; ProcessServerMonitor; cxprocessserver; InMage PushInstall; Serviço de Upload de Log (LogUpload); Serviço de Aplicativo do InMage Scout; Agente de Serviços de Recuperação do Microsoft Azure (obengine); InMage Scout VX Agent-Sentinel/Outpost (svagents); tmansvc.
Servidor de processo implantado no Azure para failback ProcessServer; ProcessServerMonitor; cxprocessserver; InMage PushInstall; Serviço de Upload de Log (LogUpload)

Etapa 3: Verificar pulsação do servidor de processo

Se não houver pulsação no servidor de processo (código de erro 806), faça o seguinte:

  1. Verifique se a VM do servidor de processo está em execução.

  2. Verifique esses logs em busca de erros.

    C:\ProgramData\ASR\home\svsystems\eventmanager*.log C\ProgramData\ASR\home\svsystems\monitor_protection*.log

Verificar conectividade e replicação

As falhas de replicação inicial e contínua geralmente são causadas por problemas de conectividade entre os computadores de origem e o servidor de processo, ou entre o servidor de processo e o Azure. Essas etapas são resumidas no gráfico a seguir, seguidas por procedimentos para ajudar a executá-las.

Flowchart showing steps to troubleshoot connectivity and replication.

Etapa 4: Verificar sincronização do tempo no computador de origem

Verifique se a data/hora do sistema do computador replicado está em sincronia. Saiba mais

Etapa 5: Verificar software antivírus no computador de origem

Verifique se nenhum software antivírus no computador replicado está bloqueando o Site Recovery. Se você precisar excluir o Site Recovery de programas antivírus, veja este artigo.

Etapa 6: Verificar conectividade do computador de origem

  1. Instale o cliente Telnetno computador de origem, se necessário. Não use Ping.

  2. No computador de origem, execute ping no servidor de processo na porta HTTPS com Telnet. Por padrão, 9443 é a porta HTTPS para o tráfego de replicação.

    telnet <process server IP address> <port>

  3. Verifique se a conexão foi bem-sucedida.

Conectividade Detalhes Ação
Bem-sucedida O Telnet mostra uma tela em branco e o servidor de processo pode ser acessado. Nenhuma ação adicional é necessária.
Sem êxito Você não consegue conectar Verifique se a porta de entrada 9443 é permitida no servidor de processo. Por exemplo, se você tiver uma rede de perímetro ou uma sub-rede filtrada. Verifique a conectividade novamente.
Parcialmente bem-sucedida Você consegue conectar, mas o computador de origem relata que o servidor de processo não pode ser acessado. Continue com o próximo procedimento de solução de problemas.

Etapa 7: Solucionar problemas em um servidor de processo inacessível

Se o servidor de processo não estiver acessível a partir do computador de origem, o erro 78186 será exibido. Se não for resolvido, esse problema fará com que os pontos de recuperação consistentes do aplicativo e com falhas não sejam gerados conforme o esperado.

Solucione problemas verificando se o computador de origem pode acessar o endereço IP do servidor de processo e execute a ferramenta cxpsclient nesse computador para verificar a conexão de ponta a ponta.

Verificar conexão IP no servidor de processo

Se o Telnet for bem-sucedido, mas o computador de origem relatar que o servidor de processo não pode ser acessado, verifique se você pode acessar o endereço IP do servidor de processo.

  1. Em um navegador da Web, tente acessar o endereço https://<PS_IP>:<PS_Data_Port>/.
  2. Se essa verificação mostra um erro de certificado HTTPS, isso é normal. Se você ignorar o erro, verá a mensagem: 400 - Solicitação Incorreta. Isso significa que o servidor não pode atender à solicitação do navegador e a conexão HTTPS padrão está correta.
  3. Se essa verificação não funcionar, anote a mensagem de erro do navegador. Por exemplo, um erro 407 indicará um problema com a autenticação de proxy.

Verificar conexão com cxpsclient

Além disso, você pode executar a ferramenta cxpsclient para verificar a conexão de ponta a ponta.

  1. Execute a ferramenta da seguinte maneira:

    <install folder>\cxpsclient.exe -i <PS_IP> -l <PS_Data_Port> -y <timeout_in_secs:recommended 300>

  2. No servidor de processo, verifique os logs gerados nestas pastas:

    C:\ProgramData\ASR\home\svsystems\transport\log\cxps.err C:\ProgramData\ASR\home\svsystems\transport\log\cxps.xfer

Verificar logs da VM de origem para obter falhas de upload (erro 78028)

O problema com os uploads de dados bloqueados dos computadores de origem para o serviço de processo pode resultar em pontos de recuperação consistentes com falhas e do aplicativo não sendo gerados.

  1. Para solucionar as falhas de upload da rede, você pode procurar erros neste log:

    C:\Program Files (x86)\Microsoft Azure Site Recovery\agent\svagents*.log

  2. Usar o restante dos procedimentos neste artigo pode ajudá-lo a resolver os problemas de upload dos dados.

Etapa 8: Verificar se o servidor de processo está enviando dados por push

Verifique se o servidor de processo está enviando dados por push ativamente para o Azure.

  1. No servidor de processo, abra o Gerenciador de Tarefas (pressione Ctrl+Shift+Esc).

  2. Selecione a guia Desempenho>Abrir Monitor de Recursos.

  3. Na página Monitor de Recursos, selecione a guia Rede. Em Processos com Atividade de Rede, verifique se o cbengine.exe está enviando ativamente grandes volumes de dados.

    Screenshot showing a large number for volumes under processes with network activity.

Se cbengine.exe não estiver enviando um grande volume de dados, conclua as etapas nas seções a seguir.

Etapa 9: Verificar conexão do servidor de processo com o armazenamento de blobs do Azure

  1. Em Monitor de Recursos, selecione cbengine. exe.
  2. Em Conexões TCP, verifique se há conectividade do servidor de processo com o armazenamento do Azure.

Screenshot showing connectivity between cbengine.exe and the Azure Blob storage URL.

Verificar serviços

Se não houver conectividade do servidor de processo com a URL do armazenamento de blobs do Azure, verifique se esses serviços estão em execução.

  1. No Painel de Controle, selecione Serviços.

  2. Verifique se os seguintes serviços estão em execução:

    • cxprocessserver
    • Agente do InMage Scout VX – Sentinel/Outpost
    • Agente de Serviços dos Serviços de Recuperação do Microsoft Azure
    • Serviço do Microsoft Azure Site Recovery
    • tmansvc

  3. Iniciar ou reiniciar qualquer serviço que não está em execução.

  4. Verifique se o servidor está conectado e acessível.

Etapa 10: verificar conexão do servidor de processo com o endereço IP público do Azure

  1. No serviço de processo, em %programfiles%\Agente de Serviços de Recuperação do Microsoft Azure\Temp, abra o arquivo CBEngineCurr.errlog mais recente.
  2. No arquivo, procure 443 ou a cadeia de caracteres falha na tentativa de conexão.

Error logs in the Temp folder

  1. Se você tiver problemas, encontre o endereço IP público do Azure no arquivo CBEngineCurr.currLog usando a porta 443:

telnet <your Azure Public IP address as seen in CBEngineCurr.errlog> 443

  1. Na linha de comando no servidor de processo, use o Telnet para executar ping no seu endereço IP público do Azure.
  2. Se não conseguir conectar, siga o procedimento a seguir.

Etapa 11: Verifique as configurações de firewall do servidor de processo.

Verifique se o firewall baseado em endereço IP no servidor de processo bloqueia o acesso.

  1. Para as regras de firewall baseadas em endereço IP:

    a) Baixe a lista completa de intervalos de IP do datacenter do Microsoft Azure.

    b) Adicione intervalos de endereços IP à sua configuração de firewall para garantir que o firewall permita a comunicação com o Azure (e com a porta HTTPS padrão, 443).

    c) Permita os intervalos de endereço IP para a região do Azure de sua assinatura e a região Oeste dos EUA do Azure (usados para o controle de acesso e o gerenciamento de identidades).

  2. Para os firewalls baseados em URL, adicione as URLs listadas na tabela a seguir à configuração do firewall.

    Nome URL comercial URL governamental Descrição
    Microsoft Entra ID login.microsoftonline.com login.microsoftonline.us Usado para controle de acesso e gerenciamento de identidades.
    Backup *.backup.windowsazure.com *.backup.windowsazure.us Usado para transferência de dados de replicação e coordenação.
    Replicação *.hypervrecoverymanager.windowsazure.com *.hypervrecoverymanager.windowsazure.us Usado para operações de gerenciamento de replicação e coordenação.
    Armazenamento *.blob.core.windows.net *.blob.core.usgovcloudapi.net Usado para acessar a conta de armazenamento que armazena os dados replicados.
    Telemetria (opcional) dc.services.visualstudio.com dc.services.visualstudio.com Usado para telemetria.
    Sincronização da hora time.windows.com time.nist.gov Usado para verificar a sincronização de data/hora entre o tempo do sistema e o tempo global, em todas as implantações.

Etapa 12: Verificar configurações de proxy do servidor de processo

  1. Se você estiver usando um servidor proxy, verifique se o nome do servidor proxy é resolvido pelo servidor DNS. Verifique o valor fornecido ao definir o servidor de configuração na chave do registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure Site Recovery\ProxySettings.

  2. Em seguida, verifique se as mesmas configurações estão sendo usadas pelo agente do Azure Site Recovery para enviar dados.

    a) Procure o Backup do Microsoft Azure.

    b) Abra o Backup do Microsoft Azure e selecione Ação>Alterar Propriedades.

    c) Na guia Configuração do Proxy, o endereço de proxy deve ser igual ao endereço de proxy exibido nas configurações do registro. Caso contrário, altere-a para o mesmo endereço.

Etapa 13: Verificar largura de banda

Aumente a largura de banda entre o servidor de processo e o Azure, depois verifique se o problema ainda ocorre.

Próximas etapas

Se precisar de mais ajuda, poste sua pergunta na página de Perguntas e Respostas da Microsoft para o Azure Site Recovery.