Matriz de suporte para avaliação e migração de servidor físico

Artigo
11/04/2024

Este artigo resume os pré-requisitos e requisitos de suporte ao avaliar os servidores físicos para migração para o Azure, ao usar a Migrações para Azure: ferramenta de descoberta e avaliação. Se quiser migrar servidores físicos para o Azure, confira a matriz de suporte à migração.

Para avaliar servidores físicos, crie um projeto e adicione a Migrações para Azure: ferramenta de descoberta e avaliação ao projeto. Depois de você adicionar a ferramenta, implante o Dispositivo de Migrações para Azure. O dispositivo descobre continuamente os servidores locais e envia os metadados de servidor e os dados de desempenho para as Migrações para Azure. Após concluir a descoberta, reúna os computadores descobertos em grupos e execute uma avaliação para um grupo.

Limitações

Suporte	Detalhes
Limites de avaliação	É possível descobrir e avaliar até 35.000 servidores físicos em um único projeto.
Limites do projeto	Você pode criar vários projetos em uma assinatura do Azure. Além dos servidores físicos, um projeto pode incluir servidores no VMware e no Hyper-V, até os limites de avaliação de cada um.
Descoberta	O dispositivo de Migrações para Azure pode descobrir até 1.000 servidores físicos.
Avaliação	É possível adicionar até 35.000 servidores em um único grupo. É possível avaliar até 35.000 servidores em uma única avaliação.

Saiba mais sobre as avaliações.

Requisitos de servidor físico

Implantação de servidor físico: o servidor físico pode ser autônomo ou implantado em um cluster.
Tipo de servidores: servidores de computador bare-metal, servidores virtualizados em execução no local ou em outras nuvens, como AWS (Amazon Web Services), GCP (Google Cloud Platform) e Xen.

Observação

No momento, as Migrações para Azure não permitem a descoberta de servidores paravirtualizados.
Sistema operacional:todos os sistemas operacionais Windows e Linux podem ser avaliados para migração.

Permissões para os servidores Windows

Para servidores Windows, use uma conta de domínio para os servidores conectados ao domínio e uma conta local para os servidores que não estão conectados ao domínio.
Para descoberta física, não há suporte para especificar o nome de usuário em formato de nível inferior (domínio\nome de usuário) e formato UPN (username@domain.com).

Você pode criar a conta de usuário de uma das duas maneiras a seguir.

Opção 1

Cria uma conta que tenha privilégios de administrador nos servidores. Use esta conta para:

Efetuar pull de dados de configuração e desempenho por meio de uma conexão CIM (Common Information Model).
Executar inventário de software (descoberta de aplicativos instalados).
Habilite a análise de dependência sem agente usando a comunicação remota do PowerShell.

Observação

Se você quiser executar o inventário de software (descoberta de aplicativos instalados) e habilitar a análise de dependência sem agente em servidores Windows, recomendamos usar a opção 1.

Opção 2

Adicione a conta de usuário a estes grupos: Usuários de Gerenciamento Remoto, Usuários de Monitor de Desempenho e Usuários de Registro de Desempenho.
Se o grupo Usuários de Gerenciamento Remoto não estiver presente, adicione a seguinte conta de usuário ao grupo: WinRMRemoteWMIUsers_.
A conta precisa dessas permissões para que o dispositivo crie uma conexão CIM com o servidor e extraia a configuração e os metadados de desempenho necessários das classes WMI (Instrumentação de Gerenciamento do Windows) listadas aqui.
Em alguns casos, adicionar a conta a esses grupos pode não retornar os dados necessários de classes WMI. A conta pode ser filtrada por UAC (Controle de Conta de Usuário). Para superar a filtragem UAC, a conta de usuário precisa ter as permissões necessárias no namespace e nos subnamespaces CIMV2 no servidor de destino. Para habilitar as permissões necessárias, consulte Solucionar problemas do dispositivo de Migrações para Azure.

Observação

Para Windows Server 2008 e 2008 R2, certifique-se de que o Windows Management Framework 3.0 esteja instalado nos servidores.

Para descobrir os bancos de dados do SQL Server nos Windows Servers, há suporte para a autenticação do Windows e do SQL Server. É possível fornecer credenciais dos dois tipos de autenticação no gerenciador de configuração de dispositivo. As Migrações para Azure exigem uma conta de usuário do Windows que seja um membro da função de servidor sysadmin.

Permissões para o servidor Linux

Para servidores Linux, com base nos recursos que deseja executar, você pode criar uma conta de usuário de uma de duas maneiras seguintes.

Opção 1

Você precisa de uma conta de usuário com acesso ao sudo nos servidores que deseja descobrir. Use esta conta para:
- Extrair metadados de configuração e desempenho.
- Executar inventário de software (descoberta de aplicativos instalados).
- Habilitar a análise de dependência sem agente usando a conectividade SSH (Secure Shell).
Você precisa habilitar o acesso sudo em /usr/bin/bash para executar os comandos listados nos metadados do servidor Linux. Além desses comandos, a conta de usuário também precisa ter permissões para executar comandos ls e netstat para executar a análise de dependência sem agente.
Verifique se você habilitou NOPASSWD na conta para executar os comandos necessários sem solicitar uma senha sempre que o comando sudo for invocado.

As Migrações para Azure e a Modernização são compatíveis com as seguintes distribuições do sistema operacional Linux para descoberta usando uma conta com acesso ao sudo:

Sistema operacional	Versões
Red Hat Enterprise Linux	5.1, 5.3, 5.11, 6.x, 7.x, 8.x, 9.x
Ubuntu	12.04, 14.04, 16.04, 18.04, 20.04, 22.04
Oracle Linux	6.1, 6.7, 6.8, 6.9, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.3 e 8.5
SUSE Linux	10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2 e 15 SP3
Debian	7, 8, 9, 10 e 11
Amazon Linux	2.0.2021
Contêiner CoreOS	2345.3.0

Observação

Se você quiser executar o inventário de software (descoberta de aplicativos instalados) e habilitar a análise de dependência sem agente em servidores Linux, recomendamos usar a opção 1.

Opção 2

Se você não puder fornecer a conta raiz ou a conta de usuário com acesso sudo, poderá definir a chave do registro isSudo para o valor 0 no registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance no servidor do dispositivo. Forneça uma conta não raiz com as funcionalidades necessárias usando os seguintes comandos:

Comando	Finalidade
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/fdisk setcap CAP_DAC_READ_SEARCH+eip /sbin/fdisk	Coleta dados de configuração de disco.
setcap "cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_setuid, cap_setpcap,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin, cap_sys_resource,cap_audit_control,cap_setfcap=+eip" /sbin/lvm	Coleta dados de desempenho do disco.
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/dmidecode	Coleta o número de série do BIOS.
chmod a+r /sys/class/dmi/id/product_uuid	Coleta o GUID do BIOS.

Para executar a análise de dependência sem agente no servidor, verifique se você também definiu as permissões necessárias em arquivos /bin/netstat e /bin/ls usando 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

Requisitos de dispositivo para as Migrações para Azure

As Migrações para Azure usam o dispositivo das Migrações para Azure para descoberta e avaliação. O dispositivo para servidores físicos pode ser executado em uma VM (máquina virtual) ou em um servidor físico.

Saiba mais sobreos requisitos de dispositivo para servidores físicos.
Saiba mais sobre as URLs do Azure que o dispositivo precisa acessar nas nuvens públicas e governamentais.
Use um script do PowerShell que você baixar no portal do Azure para configurar o dispositivo.
Use o script para implantar o dispositivo no Azure Governamental.

Acesso à porta

A tabela a seguir resume os requisitos de porta para a avaliação.

Dispositivo Conexão

Dispositivo Conexões de entrada na porta TCP 3389 para permitir conexões de área de trabalho remota para o dispositivo.

Conexões de entrada na porta 44368 para acessar remotamente o aplicativo de gerenciamento de dispositivos usando a URL https://<appliance-ip-or-name>:44368.

Conexões de saída nas portas 443 (HTTPS) para enviar metadados de descoberta e desempenho para As Migrações para Azure e Modernização.

Servidores físicos Windows: conexão de entrada na porta WinRM 5985 (HTTP) para efetuar pull de metadados de configuração e desempenho dos servidores Windows.

Linux: conexões de entrada na porta 22 (TCP) para efetuar pull de metadados de configuração e desempenho de servidores Linux.

Dispositivo	Conexão
Dispositivo	Conexões de entrada na porta TCP 3389 para permitir conexões de área de trabalho remota para o dispositivo. Conexões de entrada na porta 44368 para acessar remotamente o aplicativo de gerenciamento de dispositivos usando a URL `https://<appliance-ip-or-name>:44368`. Conexões de saída nas portas 443 (HTTPS) para enviar metadados de descoberta e desempenho para As Migrações para Azure e Modernização.
Servidores físicos	Windows: conexão de entrada na porta WinRM 5985 (HTTP) para efetuar pull de metadados de configuração e desempenho dos servidores Windows. Linux: conexões de entrada na porta 22 (TCP) para efetuar pull de metadados de configuração e desempenho de servidores Linux.

Requisitos de inventário de software

Além de descobrir servidores, as Migrações para Azure: descoberta e avaliação podem executar o inventário de software em servidores. O inventário de software fornece a lista de aplicativos, funções e recursos em execução em servidores Windows e Linux que são descobertos usando Migrações para Azure e Modernização. Ele ajuda você a identificar e planejar um caminho de migração adaptado às cargas de trabalho locais.

Suporte	Detalhes
Servidores com suporte	É possível executar o inventário de softwares em até mil servidores descobertos de cada dispositivo com Migrações para Azure.
Sistemas operacionais	Servidores que executam todas as versões do Windows e do Linux que atendem aos requisitos do servidor e têm as permissões de acesso necessárias têm suporte.
Requisitos de servidor	Os servidores do Windows precisam ter a comunicação remota do PowerShell e a versão 2.0 do PowerShell ou posterior instalado. O WMI deve estar habilitado e disponível em servidores Windows para coletar os detalhes das funções e recursos instalados nos servidores. Os servidores Linux devem ter a conectividade SSH habilitada e garantir que os seguintes comandos possam ser executados nos servidores Linux para realizar pull dos dados do aplicativo: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Com base no tipo de sistema operacional e no tipo de gerenciador de pacotes usado, aqui estão mais alguns comandos: rpm/snap/dpkg, yum/apt-cache, mssql-server.
Acesso ao servidor do Windows	Uma conta de usuário convidado para servidores Windows.
Acesso ao servidor Linux	Uma conta de usuário padrão (acesso não sudo) para todos os servidores Linux.
Acesso à porta	Os servidores Windows precisam de acesso na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP).
Descoberta	O inventário de software é realizado conectando-se diretamente aos servidores usando as credenciais do servidor adicionadas ao dispositivo. O dispositivo coleta as informações sobre o inventário de software de servidores Windows usando a comunicação remota do PowerShell e de servidores Linux usando a conexão SSH. O inventário de software não tem agente. Nenhum agente é instalado nos servidores.

Requisitos da instância do SQL Server e de descoberta de banco de dados

O inventário de softwares identifica instâncias do SQL Server. Ao usar essas informações, dispositivo tenta se conectar às respectivas instâncias do SQL Server pelas credenciais de autenticação do Windows ou do SQL Server fornecidas no gerenciador de configuração do dispositivo. O dispositivo pode se conectar somente às instâncias do SQL Server com as quais possui linha de visão de rede. O inventário de software por si só pode não precisar da linha de visão da rede.

Depois de conectado, o dispositivo coleta dados de desempenho e configuração para as instâncias e bancos de dados do SQL Server. O dispositivo atualiza os dados de configuração do SQL Server uma vez a cada 24 horas e captura os dados de desempenho a cada 30 segundos.

Suporte	Detalhes
Servidores com suporte	Com suporte apenas para servidores que executam o SQL Server em ambientes VMware, Microsoft Hyper-V e físicos/bare-metal e servidores de infraestrutura como serviço (IaaS) de outras nuvens públicas, como AWS e GCP. É possível descobrir até 750 instâncias do SQL Server ou 15 mil bancos de dados SQL, o que for menor, em um único dispositivo. Recomendamos que você garanta que um dispositivo tenha como escopo descobrir menos de 600 servidores executando SQL para evitar problemas de escala.
Servidores Windows	Há suporte para o Windows Server 2008 e posterior.
Servidores Linux	Atualmente sem suporte.
Mecanismo de autenticação	Há suporte para a autenticação do Windows e do SQL Server. É possível fornecer credenciais dos dois tipos de autenticação no gerenciador de configuração de dispositivo.
Acesso ao SQL Server	Para descobrir Instâncias do SQL Server e bancos de dados, a conta do Windows ou SQL Server deve ser membro da função de servidor sysadmin ou ter essas permissões para cada Instância do SQL Server.
Versões do SQL Server	Há suporte para o SQL Server 2008 e posterior.
Edições doSQL Server	Há suporte para as edições Enterprise, Standard, Desenvolvedor e Expresso.
Configuração do SQL com suporte	Há suporte para a descoberta de implantações SQL autônomas, altamente disponíveis e protegidas contra desastres. A descoberta de implantações SQL de alta disponibilidade e recuperação de desastres alimentadas por instâncias de cluster de failover Always On e grupos de disponibilidade Always On também é suportada.
Serviços SQL com suporte	Há suporte somente para o Mecanismo de Banco de Dados do SQL Server. Não há suporte para a descoberta do SQL Server Reporting Services, do SQL Server Integration Services e do SQL Server Analysis Services.

Observação

Por padrão, Migrações para Azure utiliza a forma mais segura de se conectar às instâncias SQL. Ou seja, as Migrações para Azure e Modernizações criptografa a comunicação entre o dispositivo Migrações para Azure e as instâncias de origem do SQL Server definindo a propriedade TrustServerCertificate como true. Além disso, a camada de transporte usa Secure Socket Layer para criptografar o canal e ignorar a cadeia de certificados para validar a confiança. Por esse motivo, o servidor do dispositivo deve ser configurado para confiar na autoridade raiz do certificado.

No entanto, você pode modificar as configurações de conexão selecionando Editar propriedades de conexão do SQL Server no dispositivo. Saiba mais para entender o que escolher.

Use os seguintes scripts de exemplo para criar um login e fornecer-lhe as permissões necessárias.

Autenticação do Windows

-- Create a login to run the assessment
use master;
DECLARE @SID NVARCHAR(MAX) = N'';
CREATE LOGIN [MYDOMAIN\MYACCOUNT] FROM WINDOWS;
SELECT @SID = N'0x'+CONVERT(NVARCHAR, sid, 2) FROM sys.syslogins where name = 'MYDOMAIN\MYACCOUNT'
IF (ISNULL(@SID,'') != '')
  PRINT N'Created login [MYDOMAIN\MYACCOUNT] with SID = ' + @SID
ELSE
  PRINT N'Login creation failed'
GO    

-- Create user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
  USE [?];
  IF (''?'' NOT IN (''tempdb'',''model''))
  BEGIN
    DECLARE @is_secondary_replica BIT = 0;
    IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
    BEGIN
      DECLARE @innersql NVARCHAR(MAX);
      SET @innersql = N''
        SELECT @is_secondary_replica = IIF(
          EXISTS (
              SELECT 1
              FROM sys.availability_replicas a
              INNER JOIN sys.dm_hadr_database_replica_states b
              ON a.replica_id = b.replica_id
              WHERE b.is_local = 1
              AND b.is_primary_replica = 0
              AND a.secondary_role_allow_connections = 2
              AND b.database_id = DB_ID()
          ), 1, 0
        );
      '';
      EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
    END
    IF (@is_secondary_replica = 0)
    BEGIN
      CREATE USER [MYDOMAIN\MYACCOUNT] FOR LOGIN [MYDOMAIN\MYACCOUNT];
      GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
      GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
    END
  END'
GO

-- Provide server level read-only permissions
use master;
GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW SERVER STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW ANY DEFINITION TO [MYDOMAIN\MYACCOUNT];
GO

-- Provide msdb specific permissions
use msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [MYDOMAIN\MYACCOUNT];
GO

-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; DROP USER [MYDOMAIN\MYACCOUNT]'
-- DROP LOGIN [MYDOMAIN\MYACCOUNT];
--GO

Autenticação do SQL Server

--- Create a login to run the assessment
use master;
-- NOTE: SQL instances that host replicas of Always On availability groups must use the same SID for the SQL login.
 -- After the account is created in one of the members, copy the SID output from the script and include this value
 -- when executing against the remaining replicas.
 -- When the SID needs to be specified, add the value to the @SID variable definition below.
DECLARE @SID NVARCHAR(MAX) = N'';
IF (@SID = N'')
BEGIN
 CREATE LOGIN [evaluator]
     WITH PASSWORD = '<provide a strong password>'
END
ELSE
BEGIN
 DECLARE @SQLString NVARCHAR(500) = 'CREATE LOGIN [evaluator]
   WITH PASSWORD = ''<provide a strong password>''
   , SID = ' + @SID
 EXEC SP_EXECUTESQL @SQLString
END
SELECT @SID = N'0x'+CONVERT(NVARCHAR(100), sid, 2) FROM sys.syslogins where name = 'evaluator'
IF (ISNULL(@SID,'') != '')
 PRINT N'Created login [evaluator] with SID = '''+ @SID +'''. If this instance hosts any Always On Availability Group replica, use this SID value when executing the script against the instances hosting the other replicas'
ELSE
 PRINT N'Login creation failed'
GO

-- Create user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
 USE [?];
 IF (''?'' NOT IN (''tempdb'',''model''))
 BEGIN
   DECLARE @is_secondary_replica BIT = 0;
   IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
   BEGIN
     DECLARE @innersql NVARCHAR(MAX);
     SET @innersql = N''
       SELECT @is_secondary_replica = IIF(
         EXISTS (
           SELECT 1
           FROM sys.availability_replicas a
           INNER JOIN sys.dm_hadr_database_replica_states b
             ON a.replica_id = b.replica_id
           WHERE b.is_local = 1
             AND b.is_primary_replica = 0
             AND a.secondary_role_allow_connections = 2
             AND b.database_id = DB_ID()
         ), 1, 0
       );
     '';
     EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
   END

   IF (@is_secondary_replica = 0)
   BEGIN
       CREATE USER [evaluator] FOR LOGIN [evaluator];
       GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
       GRANT VIEW DATABASE STATE TO [evaluator];
   END
 END'
GO

-- Provide server level read-only permissions
USE master;
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
GRANT VIEW SERVER STATE TO [evaluator];
GRANT VIEW ANY DEFINITION TO [evaluator];
GO

-- Provide msdb specific permissions
USE msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [evaluator];
GO

-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
--GO

Requisitos de descoberta de aplicativos Web

Inventário de software identifica a função de servidor web que existe nos servidores descobertos. Se for descoberto que um servidor tem um servidor Web instalado, as Migrações para Azure e Modernizações descobrem aplicativos Web no servidor.

Você pode adicionar credenciais de domínio e não domínio ao dispositivo. Verifique se a conta usada tem privilégios de administrador local nos servidores de origem. As Migrações para Azure e Modernizações mapeia automaticamente as credenciais para os respetivos servidores, para que não tenha de as mapear manualmente. O mais importante é que essas credenciais nunca são enviadas à Microsoft e permanecem no dispositivo em execução no ambiente de origem.

Depois que o dispositivo estiver conectado, ele coletará dados de configuração para aplicativos Web ASP.NET (servidor Web IIS) e aplicativos Web Java (servidores Tomcat). Os dados de configuração dos aplicativos Web são atualizados a cada 24 horas.

Suporte	Aplicativos Web ASP.NET	Aplicativos Web Java
Pilha	VMware, Hyper-V e servidores físicos.	VMware, Hyper-V e servidores físicos.
Servidores Windows	Há suporte para o Windows Server 2008 R2 e posterior.	Não há suporte.
Servidores Linux	Não há suporte.	Ubuntu Linux 16.04/18.04/20.04, Debian 7/8 e Red Hat Enterprise Linux 5/6/7.
Versões do servidor Web	IIS 7.5 e versões posteriores.	Tomcat 8 ou versões posteriores.
Privilégios necessários	Administrador local.	Usuário root ou sudo.

Observação

Os dados são sempre criptografados em repouso e durante o trânsito.

Requisitos para a análise de dependência (sem agente)

Análise de dependência ajuda a analisar as dependências entre os servidores descobertos. Você pode visualizar facilmente dependências com uma exibição de mapa em um projeto de Migrações para Azure. Você pode usar dependências para agrupar servidores relacionados para migração para o Azure. A tabela a seguir resume os requisitos para configurar a análise de dependência sem agente.

Suporte	Detalhes
Servidores com suporte	Você pode habilitar a análise de dependência sem agente em até 1.000 servidores, descobertos por dispositivo.
Sistemas operacionais	Servidores que executam todas as versões do Windows e do Linux que atendem aos requisitos do servidor e têm as permissões de acesso necessárias têm suporte.
Requisitos de servidor	Os servidores do Windows precisam ter a comunicação remota do PowerShell e a versão 2.0 do PowerShell ou posterior instalado. Os servidores Linux devem ter a conectividade SSH habilitada e garantir que os seguintes comandos possam ser executados nos servidores Linux: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
Acesso ao servidor do Windows	Conta de usuário convidado
Acesso ao servidor Linux	Uma conta de usuário sudo com permissões para executar comandos ls e netstat. Se você estiver fornecendo uma conta de usuário sudo, verifique se habilitou NOPASSWD na conta para executar os comandos necessários sem solicitar uma senha sempre que o comando sudo for invocado. Alternativamente, você pode criar uma conta de usuário que tenha as permissões CAP_DAC_READ_SEARCH e CAP_SYS_PTRACE nos arquivos /bin/netstat e /bin/ls definidas usando os seguintes comandos: `sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/ls` `sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/netstat`
Acesso à porta	Os servidores Windows precisam de acesso na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP).
Método de descoberta	A análise de dependência sem agente é realizada conectando-se diretamente aos servidores usando as credenciais do servidor adicionadas ao dispositivo. O dispositivo reúne as informações de dependência de servidores Windows usando a comunicação remota do PowerShell e de servidores Linux usando a conexão SSH. Nenhum agente está instalado nos servidores para realizar pull de dados de dependência.

Requisitos da análise de dependência baseada em agente

A Análise de dependência ajuda a identificar dependências entre os computadores locais que deseja avaliar e migrar para o Azure. A tabela a seguir resume os requisitos para a configuração da análise de dependência baseada em agente. Atualmente, somente a análise de dependência baseada em agente tem suporte para servidores físicos.

Requisito	Detalhes
Antes da implantação	Você deve ter um projeto em vigor com as Migrações para Azure: ferramenta de descoberta e avaliação adicionada ao projeto. Implante a visualização de dependência depois de configurar um dispositivo de Migrações para Azure para descobrir os computadores locais. Aprenda a criar um projeto pela primeira vez. Aprenda a adicionar uma ferramenta de avaliação a um projeto existente. Aprenda a configurar o dispositivo de Migrações para Azure para avaliação de Hyper-V, VMware ou servidores físicos.
Azure Governamental	A visualização de dependência não está disponível no Azure Governamental.
Log Analytics	As Migrações para Azure e Modernizações utiliza a solução Mapa do Serviço em registos do Azure Monitor para visualização de dependências. Associe um workspace do Log Analytics novo ou existente a um projeto. Você não pode modificar o espaço de trabalho de um projeto depois de adicioná-lo. O espaço de trabalho deve estar na mesma assinatura que o projeto. O espaço de trabalho deve residir nas regiões leste dos EUA, sudeste da Ásia ou oeste da Europa. Os espaços de trabalho em outras regiões não podem ser associados a um projeto. O workspace deve estar em uma região onde o Mapa do Serviço seja compatível. Você pode monitorar VMs do Azure em qualquer região. As VMs em si não estão limitadas às regiões com suporte do workspace do Log Analytics. No Log Analytics, o espaço de trabalho associado as Migrações para Azure e Modernizações é marcado com a chave do Projeto de Migração e o nome do projeto.
Agentes necessários	Instale os seguintes agentes em cada servidor que quiser analisar: - MMA (Microsoft Monitoring Agent) - Agente de dependência Se os servidores locais não estiverem conectados à Internet, você precisará baixar e instalar o gateway do Log Analytics neles. Saiba mais sobre a instalação do agente de dependência e MMA.
Espaço de Trabalho do Log Analytics	O workspace deve estar na mesma assinatura que um projeto. As Migrações para Azure e Modernizações suporta espaços de trabalho residentes nas regiões Leste dos EUA, Sudeste Asiático e Europa Ocidental. O workspace deve estar em uma região onde o Mapa do Serviço seja compatível. Você pode monitorar VMs do Azure em qualquer região. As VMs em si não estão limitadas às regiões com suporte do workspace do Log Analytics. Você não pode modificar o espaço de trabalho de um projeto depois de adicioná-lo.
Custos	A solução Mapa do Serviço não gera nenhuma cobrança nos primeiros 180 dias. A contagem começa no dia em que você associa o workspace do Log Analytics ao projeto. Após 180 dias, os encargos padrão do Log Analytics entram em vigor. A utilização de qualquer solução que não seja o Mapa do Serviço no espaço de trabalho associado do Log Analytics incorre em taxas padrão para o Log Analytics. Quando o projeto for excluído, o workspace não será excluído automaticamente. Depois de excluir o projeto, o uso do Mapa do Serviço não será gratuito. Cada nó é cobrado de acordo com o nível pago do espaço de trabalho Log Analytics. Se tiver projetos criados antes da disponibilidade geral das Migrações para Azure (disponibilidade geral em 28 de fevereiro de 2018), poderá incorrer em outros encargos do Mapa do Serviço. Para garantir que você seja cobrado somente após 180 dias, recomendamos que você crie um projeto. Os workspaces que foram criados antes da disponibilidade geral ainda serão cobrados.
Gerenciamento	Ao registrar agentes no workspace, use a ID e a chave fornecidas pelo projeto. Você pode usar o espaço de trabalho Log Analytics fora do Migrações para Azure e Modernizações. Caso exclua o projeto associado, o espaço de trabalho não será excluído automaticamente. Exclua-o manualmente. Não elimine o espaço de trabalho criado por Migrações para Azure e Modernizações, a menos que elimine o projeto. Se você fizer isso, a funcionalidade de visualização de dependência não funcionará conforme o esperado.
Conectividade com a Internet	Se os servidores não estiverem conectados à Internet, instale o gateway do Log Analytics nos servidores.
Azure Governamental	A análise de dependência baseada em agente não é compatível.

Próximas etapas

Prepare-se para a descoberta de servidores físicos.

Compartilhar via

Matriz de suporte para avaliação e migração de servidor físico

Limitações

Requisitos de servidor físico

Permissões para os servidores Windows

Opção 1

Opção 2

Permissões para o servidor Linux

Opção 1

Opção 2

Requisitos de dispositivo para as Migrações para Azure

Acesso à porta

Requisitos de inventário de software

Requisitos da instância do SQL Server e de descoberta de banco de dados

Autenticação do Windows

Autenticação do SQL Server

Requisitos de descoberta de aplicativos Web

Requisitos para a análise de dependência (sem agente)

Requisitos da análise de dependência baseada em agente

Próximas etapas

Comentários

Recursos adicionais

Compartilhar via

Matriz de suporte para avaliação e migração de servidor físico

Limitações

Requisitos de servidor físico

Permissões para os servidores Windows

Opção 1

Opção 2

Permissões para o servidor Linux

Opção 1

Opção 2

Requisitos de dispositivo para as Migrações para Azure

Acesso à porta

Requisitos de inventário de software

Requisitos da instância do SQL Server e de descoberta de banco de dados

Configurar o logon personalizado para descoberta do SQL Server

Autenticação do Windows

Autenticação do SQL Server

Requisitos de descoberta de aplicativos Web

Requisitos para a análise de dependência (sem agente)

Requisitos da análise de dependência baseada em agente

Próximas etapas

Comentários

Recursos adicionais