Matriz de suporte para a deteção e avaliação de servidores físicos

Este artigo resume os pré-requisitos e requisitos de suporte quando avalia servidores físicos para migração para Azure utilizando a ferramenta Azure Migrate: Discovery and assessment. Se quiser migrar servidores físicos para Azure, consulte a matriz de suporte migração.

Para avaliar servidores físicos, cria um projeto e adiciona a ferramenta Azure Migrate: Discovery and assessment ao projeto. Depois de adicionares a ferramenta, implementas o appliance Azure Migrate. O appliance descobre continuamente servidores on-premises e envia metadados e dados de desempenho dos servidores para o Azure. Após a conclusão da descoberta, você reúne os servidores descobertos em grupos e executa uma avaliação para um grupo.

Limitações

Apoio Detalhes
Limites de avaliação Você pode descobrir e avaliar até 35.000 servidores físicos em um único projeto.
Limites do Project Pode criar vários projetos numa subscrição do Azure. Para além dos servidores físicos, um projeto pode incluir servidores no VMware e no Hyper-V, até aos limites de avaliação para cada um.
Descoberta O appliance Azure Migrate pode descobrir até 1.000 servidores físicos.
Avaliação Pode adicionar até 35 000 servidores num único grupo.

Pode avaliar até 35 000 servidores numa única avaliação.

Saiba mais sobre avaliações.

Requisitos do 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 bare-metal, servidores virtualizados executados no local ou outras nuvens como Amazon Web Services (AWS), Google Cloud Platform (GCP) e Xen.

    Nota

    Atualmente, o Azure Migrate não suporta a descoberta de servidores paravirtualizados.

  • Sistema operativo: Todos os sistemas operativos Windows e Linux podem ser avaliados para migração.

    Nota

    O Windows Server 2008, 2008 R2, 2012 e 2012 R2 atingiram o Fim do Suporte (EOS). Revise o seu uso e planeie as atualizações e migrações do sistema operativo em conformidade. Para mais informações, consulte Fim do suporte para:

Como resultado, o Azure Migrate não garante resultados consistentes ou fiáveis para estas versões do sistema operativo. Os clientes podem enfrentar problemas e são fortemente aconselhados a atualizar para uma versão suportada do Windows Server antes de iniciar a migração.

Requisitos do appliance do Azure Migrate

Azure Migrate utiliza o appliance Azure Migrate para descoberta e avaliação. O dispositivo para servidores físicos pode ser executado em uma máquina virtual (VM) ou em um servidor físico.

Acesso à porta

A tabela abaixo resume os requisitos de portas para avaliação.

Dispositivo Ligação
Eletrodoméstico Ligações de entrada na porta TCP 3389 para permitir ligações de ambiente de trabalho remoto ao dispositivo.

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

Ligações de saída na porta 443 (HTTPS) com a finalidade de enviar metadados de descoberta e desempenho para o Azure Migrate e Modernize.
Servidores físicos Windows: As ligações de entrada na porta WinRM 5986 (HTTPS) são usadas para extrair metadados de configuração e desempenho de servidores Windows.

Se os pré-requisitos HTTPS não estiverem configurados nos servidores Hyper-V de destino, a comunicação do appliance voltará para a porta WinRM 5985 (HTTP).

Para impor a comunicação HTTPS sem fallback, alterne o Appliance Config Manager.

Depois de habilitar, verifique se os pré-requisitos estão configurados nos servidores de destino.

- Se os certificados não estiverem configurados nos servidores de destino, a descoberta falhará nos servidores atualmente descobertos e nos servidores recém-adicionados.

- WinRM HTTPS requer um certificado de autenticação de servidor do computador local com um nome comum (CN) correspondente ao nome do host. O certificado não deve ser expirado, revogado ou autoassinado. Consulte o artigo para configurar o WinRM para HTTPS.

- Linux: Conexões de entrada na porta 22 (TCP) para extrair metadados de configuração e desempenho de servidores Linux.

Requisitos de inventário de software

Para além de descobrir servidores, o Azure Migrate: Discovery and Assessment pode realizar inventário de software nos servidores. O inventário de software fornece a lista de aplicações, funções e funcionalidades a correr em servidores Windows e Linux que são descobertas através do Azure Migrate e Modernize. Ele ajuda você a identificar e planejar um caminho de migração adaptado para suas cargas de trabalho locais.

Apoio Detalhes
Servidores suportados Pode realizar inventário de software em até 1.000 servidores descobertos em cada appliance Azure Migrate.
Sistemas operativos São suportados servidores que executam todas as versões de Windows e Linux que cumpram os requisitos do servidor e possuem as permissões de acesso necessárias.
Requisitos de servidor Os servidores Windows devem ter o remoting do PowerShell ativado e a versão 2.0 ou posterior do PowerShell instalada.

O WMI deve estar ativado e disponível nos servidores Windows para recolher os detalhes dos papéis e funcionalidades instalados nos servidores.

Os servidores Linux devem ter conectividade SSH habilitada e garantir que os seguintes comandos possam ser executados nos servidores Linux para extrair os 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 a servidores Windows Uma conta de utilizador 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 5986 (HTTPS) ou 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 no dispositivo.

O dispositivo recolhe a informação sobre o inventário de software em servidores Windows usando a remotização PowerShell e em servidores Linux usando a ligação SSH.

O inventário de software é sem agente. Nenhum agente está instalado nos servidores.

Requisitos de descoberta de instâncias e bases de dados do SQL Server

Inventário de software identifica instâncias do SQL Server. O appliance tenta ligar-se às respetivas instâncias do SQL Server através das credenciais de autenticação Windows Authentication ou SQL Server fornecidas no gestor de configuração do appliance, utilizando esta informação. O appliance só pode ligar-se às instâncias do SQL Server para as quais tem visibilidade na rede. O inventário de software por si só pode não precisar de linha de visão de rede.

Depois de o dispositivo estar ligado, recolhe dados de configuração e desempenho para instâncias e bases 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.

Apoio Detalhes
Servidores suportados Suportado apenas para servidores a executar SQL Server no seu VMware, Microsoft Hyper-V e em ambientes físicos ou bare-metal, bem como para servidores de infraestrutura como serviço (IaaS) de outras clouds públicas, como AWS (Amazon Web Services) e GCP (Google Cloud Platform).

Pode encontrar até 750 instâncias do SQL Server ou 15.000 bases de dados SQL, o que for menor, a partir de um único dispositivo. Recomendamos que você assegure que um aparelho está configurado para descobrir menos de 600 servidores a executar SQL, de forma a evitar problemas de dimensionamento.
Servidores Windows São suportados o Windows Server 2008 e versões posteriores.
Servidores Linux Não é atualmente suportado.
Mecanismo de autenticação São suportados tanto a autenticação do Windows como do SQL Server. Você pode fornecer credenciais de ambos os tipos de autenticação no gerenciador de configuração do dispositivo.
Acesso ao SQL Server Para descobrir instâncias e bases de dados do SQL Server, a conta do Windows/Domínio ou conta do SQL Server requer permissões de leitura de baixo privilégio para cada instância de SQL Server. Você pode usar o utilitário de provisionamento de conta de baixo privilégio para criar contas personalizadas ou usar qualquer conta existente que seja membro da função de servidor sysadmin para simplificar.
Versões do SQL Server O SQL Server 2008 e versões posteriores são suportados.
Edições do SQL Server As edições Enterprise, Standard, Developer e Express são suportadas.
Configuração SQL suportada Há suporte para a descoberta de implantações SQL autônomas, altamente disponíveis e protegidas contra desastres. Também há suporte para 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.
Serviços SQL suportados Apenas o Mecanismo de Banco de Dados do SQL Server é suportado.

A descoberta do SQL Server Reporting Services, SQL Server Integration Services e SQL Server Analysis Services não é suportada.

Nota

Por defeito, o Azure Migrate utiliza a forma mais segura de ligação a instâncias SQL. Isto é, o Azure Migrate and Modernize encripta a comunicação entre o dispositivo Azure Migrate e as instâncias de origem do SQL Server, definindo a propriedade TrustServerCertificate para 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, pode modificar as definições de ligação selecionando Editar propriedades de ligação do SQL Server no dispositivo. Saiba mais para entender o que escolher.

Configure o login personalizado para a descoberta do SQL Server

Use os scripts de exemplo a seguir para criar um login e provisioná-lo com 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 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

O inventário de software identifica a função de servidor Web que existe nos servidores descobertos. Se um servidor for descoberto com um servidor web instalado, o Azure Migrate e o Modernize descobrem aplicações web no servidor.

Você pode adicionar credenciais de domínio e de não domínio no dispositivo. Verifique se a conta usada tem privilégios de administrador local nos servidores de origem. Azure Migrate e Modernize mapeiam automaticamente as credenciais para os respetivos servidores, por isso não precisas de as mapear manualmente. Mais importante ainda, estas credenciais nunca são enviadas para a Microsoft e permanecem no appliance a correr no ambiente de origem.

Depois de o dispositivo estar ligado, recolhe dados de configuração para aplicações web ASP.NET (servidor web IIS) e aplicações web Java (servidores Tomcat). Os dados de configuração de aplicativos Web são atualizados uma vez a cada 24 horas.

Apoio Aplicações web ASP.NET Aplicações web Java
Pilha VMware, Hyper-V e servidores físicos VMware, Hyper-V e servidores físicos
Servidores Windows São suportados o Windows Server 2008 R2 e versões posteriores Não suportado
Servidores Linux Não suportado Servidores que cumprem os requisitos
Versões do servidor Web IIS 7.5 e posteriores Tomcat 8 e posteriores
Protocolo Porta WinRM 5986 (HTTPS) por defeito, se os pré-requisitos HTTPS não estiverem configurados nos servidores alvo, a comunicação volta para a porta WinRM 5985 (HTTP) Porta SSH 22 (TCP)
Privilégios necessários O utilizador menos privilegiado deve fazer parte dos dois grupos de utilizadores: 1. Utilizadores de Gestão Remota 2. IIS_IUSRS. Os utilizadores devem ter permissões de leitura para as seguintes localizações: C:\Windows\system32\inetsrv\config, C:\Windows\system32\inetsrv\config\applicationHost.config e C:\Windows\system32\inetsrv\config\redirection.config.

Adicione o utilizador a 'iniciar sessão como trabalho em lote' usando secpol.msc e certifique-se de que o utilizador não faz parte do 'negar iniciar sessão como trabalho em lote'.
Permissões de leitura (r) e execução (x) definidas recursivamente nos diretórios CATALINA_HOME.

Nota

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

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

A análise de dependência ajuda a analisar as dependências entre os servidores descobertos. Pode visualizar facilmente dependências com uma vista de mapa num projeto Azure Migrate. 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.

Apoio Detalhes
Servidores suportados Você pode habilitar a análise de dependência sem agente em até 1.000 servidores descobertos por dispositivo.
Sistemas operativos São suportados servidores que executam todas as versões de Windows e Linux que cumpram os requisitos do servidor e possuem as permissões de acesso necessárias.
Requisitos de servidor Os servidores Windows devem ter o remoting do PowerShell ativado e a versão 2.0 ou posterior do PowerShell instalada.

Os servidores Linux devem ter 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 a servidores Windows Uma conta de usuário (local ou domínio) com permissões de administrador em servidores.
Acesso ao servidor Linux Consulte este link para acesso ao servidor Linux.
Acesso à porta Os servidores Windows precisam de acesso na porta 5986 (HTTPS) ou 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 no dispositivo.

O dispositivo recolhe a informação de dependência dos servidores Windows através do PowerShell remoting e dos servidores Linux através da ligação SSH.

Nenhum agente é instalado nos servidores para extrair dados de dependência.

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

A análise de dependências baseada em agentes é suportada apenas na vista clássica e não está disponível na nova experiência. A visão clássica está prevista para ser descontinuada até ao final de 2026. Até lá, pode continuar a aceder aos espaços de trabalho do Log Analytics para servidores onde a análise de dependências baseada em agentes já está ativada. No entanto, não podes integrar novos servidores para análise de dependências baseada em agentes. Para mais informações, veja Configurar visualização de dependências.

Se estiver a usar o Service Map para análise de dependências baseada em agentes, migre para o VM Insights. O ServiceMap está retirado de serviço.

Nota

A análise de dependências baseada em agentes não é gratuita. Aplicam-se cobranças de utilização do espaço de trabalho da Log Analytics. Para obter detalhes de preços, consulte Preços do Azure Monitor.

Próximos passos

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