Solucionar problemas de visualização de dependência

Este artigo ajuda a solucionar problemas com a análise de dependência baseada em agente e sem agente, que só está disponível para servidores VMware. Saiba mais sobre os tipos de visualização de dependência suportados no Azure Migrate.

Visualize dependências por >1 hora com análise de dependência sem agente

Com a análise de dependência sem agente, você pode visualizar dependências ou exportá-las em um mapa por um período de até 30 dias.

Visualize dependências para >10 servidores com análise de dependência sem agente

O Azure Migrate oferece um modelo do Power BI que você pode usar para visualizar conexões de rede de vários servidores ao mesmo tempo e filtrar por processo e servidor. Saiba mais sobre como visualizar as dependências de muitos servidores juntos.

CSV de exportação de dependências mostra "Processo desconhecido" com análise de dependência sem agente

Na análise de dependência sem agente, os nomes dos processos são capturados com base no melhor esforço. Em determinados cenários, embora os nomes dos servidores de origem e destino e a porta de destino sejam capturados, não é viável determinar os nomes de processo em ambas as extremidades da dependência. Nesses casos, o processo é marcado como "Processo desconhecido".

Não é possível exportar dados de dependência em um CSV devido ao erro "403: Esta solicitação não está autorizada a executar esta operação"

Se o seu projeto do Azure Migrate tiver conectividade de ponto de extremidade privado, a solicitação para exportar dados de dependência deverá ser iniciada a partir de um cliente conectado à rede virtual do Azure por meio de uma rede privada. Para resolver esse erro, abra o portal do Azure na rede local ou no servidor do dispositivo e tente exportar novamente.

Exportar os erros de análise de dependência

Você pode exportar todos os erros e correções para análise de dependência sem agente do portal selecionando Exportar notificações. O arquivo CSV exportado também contém informações adicionais, como o carimbo de data/hora no qual o erro foi encontrado e se foi um erro na validação ou descoberta de dados de dependência.

Erros comuns de análise de dependência sem agente

O Azure Migrate dá suporte à análise de dependência sem agente usando o Azure Migrate: Discovery and assessment. Saiba mais sobre como executar a análise de dependência sem agente.

Nas VMs VMware, a análise de dependências sem agente é realizada através da ligação aos servidores através do Servidor vCenter com APIs VMware. Nas VMs Hyper-V e servidores físicos, a análise de dependências sem agente é realizada ao ligar diretamente aos servidores Windows com o PowerShell em comunicação remota na porta 5985 (HTTP) e aos servidores Linux com a conectividade SSH na porta 22 (TCP).

A tabela abaixo resume todos os erros encontrados ao coletar dados de dependência por meio de APIs VMware ou conectando-se diretamente a servidores:

Erro 970: DependencyMapInsufficientPrivilegesException

Motivo

O erro geralmente aparece para servidores Linux quando você não forneceu credenciais com os privilégios necessários no dispositivo.

Remediação

Tem duas opções:

• Certifique-se de ter fornecido uma conta de usuário root.
• Certifique-se de que uma conta tenha estas permissões nos ficheiros /bin/netstat e /bin/ls:
  • CAP_DAC_READ_SEARCH
  • CAP_SYS_PTRACE

Para verificar se a conta de utilizador fornecida no dispositivo tem os privilégios necessários:

1. Inicie sessão no servidor onde encontrou este erro com a mesma conta de utilizador mencionada na mensagem de erro.

2. Execute os seguintes comandos no Shell do Azure. Você obterá erros se não tiver os privilégios necessários para a análise de dependência sem agente.

   ps -o pid,cmd | grep -v ]$
   netstat -atnp | awk '{print $4,$5,$7}'
   

3. Defina as permissões necessárias nos arquivos /bin/netstat e /bin/ls executando os seguintes comandos:

   sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls
   sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
   

4. Você pode validar se os comandos anteriores atribuíram as permissões necessárias à conta de usuário ou não.

   getcap /usr/bin/ls
   getcap /usr/bin/netstat
   

5. Execute novamente os comandos fornecidos na etapa 2 para obter uma saída bem-sucedida.

Erro 9014: HTTPGetRequestToRetrieveFileFailed

Motivo

O problema acontece quando o agente de descoberta VMware no appliance tenta baixar o arquivo de saída que contém dados de dependência do sistema de arquivos do servidor por meio do host ESXi no qual o servidor está hospedado.

Remediação

• Você pode testar a conectividade TCP com o host ESXi (nome fornecido na mensagem de erro) na porta 443 (necessário para estar aberto em hosts ESXi para extrair dados de dependência) do dispositivo. Abra o PowerShell no servidor do dispositivo e execute o seguinte comando:

  Test -NetConnection -ComputeName <Ip address of the ESXi host> -Port 443
  

• Se o comando retornar a conectividade bem-sucedida, vá para Visão geral>da descoberta e avaliação>do projeto>Azure Migrate Manage>Appliances, selecione o nome do dispositivo e selecione Atualizar serviços.

Erro 9018: PowerShellNotFound

Motivo

O erro geralmente aparece para servidores que executam o Windows Server 2008 ou inferior.

Remediação

Instale o Windows PowerShell 5.1 neste local no servidor. Siga as instruções em Instalar e configurar o WMF 5.1 para instalar o PowerShell no Windows Server.

Depois de instalar a versão necessária do PowerShell, verifique se o erro foi resolvido seguindo as etapas neste site.

Erro 9022: GetWMIObjectAccessDenied

Remediação

Verifique se a conta de usuário fornecida no dispositivo tem acesso ao namespace WMI e aos subnamespaces. Para definir o acesso:

1. Vá para o servidor que está relatando esse erro.
2. Pesquise e selecione Executar no menu Iniciar . Na caixa de diálogo Executar, digite wmimgmt.msc na caixa de texto Abrir e selecione Enter.
3. O console wmimgmt é aberto onde você pode encontrar o Controle WMI (Local) no painel esquerdo. Clique com o botão direito do mouse nele e selecione Propriedades no menu.
4. Na caixa de diálogo Propriedades do Controle WMI (Local), selecione a guia Títulos.
5. Na guia Títulos, selecione Segurança para abrir a caixa de diálogo Segurança para ROOT.
6. Selecione Avançado para abrir a caixa de diálogo Configurações avançadas de segurança para raiz .
7. Selecione Adicionar para abrir a caixa de diálogo Entrada de permissão para raiz .
8. Clique em Selecionar uma entidade de segurança para abrir a caixa de diálogo Selecionar Usuários, Computadores, Contas de Serviço ou Grupos .
9. Selecione os nomes de usuário ou grupos que deseja conceder acesso ao WMI e selecione OK.
10. Certifique-se de conceder permissões de execução e selecione Este namespace e subnamespaces na lista suspensa Aplica-se a .
11. Selecione Aplicar para salvar as configurações e fechar todas as caixas de diálogo.

Depois de obter o acesso necessário, verifique se o erro foi resolvido seguindo as etapas neste site.

Erro 9032: InvalidRequest

Motivo

Pode haver várias razões para este problema. Um motivo é quando o nome de usuário fornecido (credenciais do servidor) no gerenciador de configuração do dispositivo tem caracteres XML inválidos. Caracteres inválidos causam um erro ao analisar a solicitação SOAP.

Remediação

• Verifique se o nome de usuário das credenciais do servidor não tem caracteres XML inválidos e está no username@domain.com formato. Este formato é popularmente conhecido como formato UPN.
• Depois de editar as credenciais no aparelho, verifique se o erro foi resolvido seguindo as etapas neste site.

Erro 10002: ScriptExecutionTimedOutOnVm

Motivo

• Este erro ocorre quando o servidor está lento ou não responde e o script executado para extrair os dados de dependência começa a atingir o tempo limite.
• Depois que o agente de descoberta encontra esse erro no servidor, o dispositivo não tenta a análise de dependência sem agente no servidor posteriormente para evitar sobrecarregar o servidor que não responde.
• Você continuará a ver o erro até verificar o problema com o servidor e reiniciar o serviço de descoberta.

Remediação

1. Faça login no servidor que está encontrando esse erro.

2. Execute os seguintes comandos no PowerShell:

   Get-WMIObject win32_operatingsystem;
   Get-WindowsFeature  | Where-Object {$_.InstallState -eq 'Installed' -or ($_.InstallState -eq $null -and $_.Installed -eq 'True')};
   Get-WmiObject Win32_Process;
   netstat -ano -p tcp | select -Skip 4;
   

3. Se os comandos produzirem o resultado em alguns segundos, vá para Visão geral>da descoberta e avaliação>do projeto>Azure Migrate Manage>Appliances, selecione o nome do dispositivo e selecione Atualizar serviços para reiniciar o serviço de descoberta.

4. Se os comandos estiverem expirando sem dar nenhuma saída, você precisa:

   • Descubra quais processos estão consumindo alta CPU ou memória no servidor.
   • Tente fornecer mais núcleos ou memória para esse servidor e execute os comandos novamente.

Erro 10005: GuestCredentialNotValid

Remediação

• Verifique a validade das credenciais (nome amigável fornecido no erro) selecionando Revalidar credenciais no gerenciador de configuração do dispositivo.
• Certifique-se de que pode iniciar sessão no servidor afetado utilizando a mesma credencial fornecida no dispositivo.
• Você pode tentar usar outra conta de usuário (para o mesmo domínio, caso o servidor esteja associado ao domínio) para esse servidor em vez da conta de administrador.
• O problema pode acontecer quando a comunicação do Catálogo <Global -> Controlador de Domínio é interrompida. Verifique esse problema criando uma nova conta de usuário no controlador de domínio e fornecendo a mesma no dispositivo. Também pode ser necessário reiniciar o controlador de domínio.
• Depois de executar as etapas de correção, verifique se o erro foi resolvido seguindo as etapas neste site.

Erro 10012: CredentialNotProvided

Motivo

Este erro ocorre quando você forneceu uma credencial de domínio com o nome de domínio errado no gerenciador de configuração do dispositivo. Por exemplo, se você forneceu credenciais de domínio com o nome user@abc.com de usuário, mas forneceu o nome de domínio como def.com, essas credenciais não serão tentadas se o servidor estiver conectado a def.com e você receberá essa mensagem de erro.

Remediação

• Vá para o gerenciador de configuração do dispositivo para adicionar uma credencial de servidor ou editar uma existente, conforme explicado na causa.
• Depois de executar as etapas de correção, verifique se o erro foi resolvido seguindo as etapas neste site.

Verificação de mitigação

Depois de usar as etapas de mitigação para os erros anteriores, verifique se a atenuação funcionou executando alguns comandos PowerCLI do servidor do dispositivo. Se os comandos forem bem-sucedidos, significa que o problema foi resolvido. Caso contrário, verifique e siga os passos de remediação novamente.

Para VMs VMware (usando o pipe VMware)

1. Execute os seguintes comandos para configurar a PowerCLI no servidor do dispositivo:

   Install-Module -Name VMware.PowerCLI -AllowClobber
   Set-PowerCLIConfiguration -InvalidCertificateAction Ignore
   

2. Conecte-se ao servidor vCenter a partir do dispositivo fornecendo o endereço IP do servidor vCenter no comando e as credenciais no prompt:

   Connect-VIServer -Server <IPAddress of vCenter Server>
   

3. Conecte-se ao servidor de destino a partir do dispositivo fornecendo o nome do servidor e as credenciais do servidor, conforme fornecido no dispositivo:

   $vm = get-VM <VMName>
   $credential = Get-Credential
   

4. Para análise de dependência sem agente, execute os seguintes comandos para ver se você obtém uma saída bem-sucedida.

   • Para servidores Windows:

     Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'Get-WmiObject Win32_Process'" -GuestCredential $credential
     
     Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'netstat -ano -p tcp'" -GuestCredential $credential
     

   • Para servidores Linux:

     Invoke-VMScript -VM $vm -ScriptText "ps -o pid,cmd | grep -v ]$" -GuestCredential $credential
     
     Invoke-VMScript -VM $vm -ScriptText "netstat -atnp | awk '{print $4,$5,$7}'" -GuestCredential $credential
     

Para VMs Hyper-V e servidores físicos (usando pipe de conexão direta)

Para servidores Windows:

1. Conecte-se ao servidor Windows executando o comando:

   $Server = New-PSSession –ComputerName <IPAddress of Server> -Credential <user_name>
   

   e introduza as credenciais do servidor no pedido.

2. Execute os seguintes comandos para validar a análise de dependência sem agente para ver se você obtém uma saída bem-sucedida:

   Invoke-Command -Session $Server -ScriptBlock {Get-WmiObject Win32_Process}
   Invoke-Command -Session $Server -ScriptBlock {netstat -ano -p tcp}
   

Para servidores Linux:

1. Instale o cliente OpenSSH

   Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
   

2. Instale o servidor OpenSSH

   Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
   

3. Iniciar e configurar o OpenSSH Server

   Start-Service sshd
   Set-Service -Name sshd -StartupType 'Automatic'
   

4. Conectar-se ao OpenSSH Server

   ssh username@servername
   

5. Execute os seguintes comandos para validar a análise de dependência sem agente para ver se você obtém uma saída bem-sucedida:

   ps -o pid,cmd | grep -v ]$
   netstat -atnp | awk '{print $4,$5,$7}'
   

Depois de verificar se a atenuação funcionou, vá para Visão geral do Azure Migrate project>Discovery and assessment>Overview>Manage>Appliances, selecione o nome do dispositivo e selecione Atualizar serviços para iniciar um novo ciclo de descoberta.

O espaço de trabalho My Log Analytics não está listado quando você tenta configurar o espaço de trabalho no Azure Migrate para análise de dependência baseada em agente

Atualmente, o Azure Migrate dá suporte à criação de espaços de trabalho do OMS nas regiões Leste dos EUA, Sudeste Asiático e Europa Ocidental. Se o espaço de trabalho for criado fora do Azure Migrate em qualquer outra região, atualmente não poderá ser associado a um projeto.

Visualização de dependência baseada em agente no Azure Government

A análise de dependência baseada em agente não é suportada no Azure Government. Use a análise de dependência sem agente, que só está disponível para servidores VMware.

As dependências baseadas em agente não são exibidas após a instalação do agente

Depois de instalar os agentes de visualização de dependência em VMs locais, o Azure Migrate normalmente leva de 15 a 30 minutos para exibir as dependências no portal. Se você esperou por mais de 30 minutos, verifique se o Microsoft Monitoring Agent (MMA) pode se conectar ao espaço de trabalho do Log Analytics.

Para VMs do Windows:

1. No Painel de Controle, inicie o MMA.

2. Nas propriedades>do Microsoft Monitoring Agent Azure Log Analytics (OMS), verifique se o Status do espaço de trabalho está verde.

3. Se o status não estiver verde, tente remover o espaço de trabalho e adicioná-lo novamente ao MMA.

   

Para VMs Linux, certifique-se de que os comandos de instalação para MMA e o agente de dependência foram bem-sucedidos. Consulte mais orientações para solução de problemas neste site.

Sistemas operacionais suportados para análise de dependência baseada em agente

• Agente MMS: Os sistemas operacionais Windows e Linux suportados.
• Agente de dependência: Os sistemas operacionais Windows e Linux suportados.

Visualize dependências por >1 hora com análise de dependência baseada em agente

Com a análise de dependência baseada em agente, embora o Azure Migrate permita que você volte a uma data específica no último mês, a duração máxima para a qual você pode visualizar as dependências é de uma hora. Por exemplo, você pode usar a funcionalidade de duração de tempo no mapa de dependência para exibir dependências de ontem, mas pode visualizá-las apenas por um período de uma hora. Você pode usar os logs do Azure Monitor para consultar os dados de dependência por um período mais longo.

Visualize dependências para >10 servidores com análise de dependência baseada em agente

No Azure Migrate, com a análise de dependência baseada em agente, você pode visualizar dependências para grupos com até 10 VMs. Para grupos maiores, divida as VMs em grupos menores para visualizar dependências.

Os servidores mostram "Install agent" para análise de dependência baseada em agente

Depois de migrar servidores com visualização de dependência habilitada para o Azure, os servidores podem mostrar a ação Instalar agente em vez de Exibir dependências devido ao seguinte comportamento:

• Após a migração para o Azure, os servidores locais são desativados e as VMs equivalentes são criadas no Azure. Esses servidores adquirem um endereço MAC diferente.
• Os servidores também podem ter um endereço IP diferente, dependendo se você manteve o endereço IP local ou não.
• Se os endereços MAC e IP forem diferentes dos locais, o Azure Migrate não associará os servidores locais a nenhum dado de dependência do Mapa de Serviços. Nesse caso, ele mostra a opção de instalar o agente em vez de exibir dependências.
• Após uma migração de teste para o Azure, os servidores locais permanecem ativados conforme o esperado. Servidores equivalentes criados no Azure adquirem endereços MAC diferentes e podem adquirir endereços IP diferentes. A menos que você bloqueie o tráfego de log de saída do Azure Monitor desses servidores, o Azure Migrate não associará os servidores locais a nenhum dado de dependência do Mapa de Serviços. Nesse caso, ele mostra a opção de instalar agentes em vez de exibir dependências.

Capturar tráfego de rede

Para coletar logs de tráfego de rede:

1. Inicie sessão no portal do Azure.
2. Selecione F12 para iniciar as Ferramentas de Desenvolvimento. Se necessário, desmarque a configuração Limpar entradas na navegação .
3. Selecione a guia Rede e comece a capturar o tráfego de rede:
   • No Chrome, selecione Preservar registo. A gravação deve começar automaticamente. Um círculo vermelho indica que o tráfego está sendo capturado. Se o círculo vermelho não aparecer, selecione o círculo preto para começar.
   • No Microsoft Edge e Internet Explorer, a gravação deve iniciar automaticamente. Caso contrário, selecione o botão verde de reprodução.
4. Tente reproduzir o erro.
5. Depois de encontrar o erro durante a gravação, pare a gravação e salve uma cópia da atividade gravada:
   • No Chrome, clique com o botão direito do rato e selecione Guardar como HAR com conteúdo. Essa ação compacta e exporta os logs como um arquivo HTTP (har).
   • No Microsoft Edge ou Internet Explorer, selecione a opção Exportar tráfego capturado. Essa ação compacta e exporta o log.
6. Selecione a guia Console para verificar se há avisos ou erros. Para salvar o log do console:
   • No Chrome, clique com o botão direito do rato em qualquer parte do registo da consola. Selecione Salvar como para exportar e compacte o log.
   • No Microsoft Edge ou Internet Explorer, clique com o botão direito do mouse nos erros e selecione Copiar tudo.
7. Feche as Ferramentas de Desenvolvimento.

Próximos passos

Crie ou personalize uma avaliação.