Matriz de suporte para deteção VMware

Este artigo resume os pré-requisitos e os requisitos de suporte para usar a ferramenta Azure Migrate: Discovery and assessment para descobrir e avaliar servidores em um ambiente VMware para migração para o Azure.

Para avaliar servidores, primeiro, crie um projeto do Azure Migrate. A ferramenta Azure Migrate: Discovery and assessment é adicionada automaticamente ao projeto. Em seguida, implante o dispositivo Azure Migrate. O dispositivo descobre continuamente servidores locais e envia metadados de configuração e desempenho para o Azure. Quando a descoberta estiver concluída, reúna os servidores descobertos em grupos e execute avaliações por grupo.

Ao planejar a migração de servidores VMware para o Azure, consulte a matriz de suporte à migração.

Requisitos do VMware

VMware	Detalhes
vCenter Server	Os servidores que você deseja descobrir e avaliar devem ser gerenciados pelo vCenter Server versão 8.0, 7.0, 6.7, 6.5, 6.0 ou 5.5. Atualmente, não há suporte para a descoberta de servidores fornecendo detalhes do host ESXi no dispositivo. Não há suporte para endereços IPv6 para vCenter Server (para descoberta e avaliação de servidores) e hosts ESXi (para replicação de servidores).
Permissões	A ferramenta Azure Migrate: Discovery and assessment requer uma conta somente leitura do vCenter Server. Se você quiser usar a ferramenta para inventário de software, análise de dependência sem agente, aplicativos Web e descoberta SQL, a conta deve ter privilégios para operações de convidado em máquinas virtuais (VMs) VMware.

Requisitos de servidor

VMware	Detalhes
Sistemas operativos	Todos os sistemas operacionais Windows e Linux podem ser avaliados para migração.
Armazenamento	Há suporte para discos conectados a controladores baseados em SCSI, IDE e SATA.

Requisitos de aplicação do Azure Migrate

O Azure Migrate and Modernize usa o dispositivo Azure Migrate para descoberta e avaliação. Você pode implantar o dispositivo como um servidor em seu ambiente VMware usando um modelo do VMware Open Virtualization Appliance importado para o vCenter Server. Você também pode usar um script do PowerShell. Saiba mais sobre os requisitos do dispositivo VMware.

Aqui estão mais requisitos para o aparelho:

• No Azure Government, você deve implantar o dispositivo usando um script.
• O dispositivo deve ser capaz de acessar URLs específicas em nuvens públicas e nuvens governamentais.

Requisitos de acesso ao porto

Dispositivo	Ligação
Aplicação do Azure Migrate	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. Conexões de saída na porta 443 (HTTPS) para enviar metadados de descoberta e desempenho para o Azure Migrate and Modernize.
vCenter Server	Conexões de entrada na porta TCP 443 para permitir que o dispositivo colete metadados de configuração e desempenho para avaliações. O dispositivo se conecta ao vCenter na porta 443 por padrão. Se o vCenter Server escutar em uma porta diferente, você poderá modificar a porta ao configurar a descoberta.
Anfitriões ESXi	Para a descoberta de inventário de software ou análise de dependência sem agente, o dispositivo se conecta a hosts ESXi na porta TCP 443 para descobrir inventário de software e dependências nos servidores.

Requisitos de inventário de software

Além de descobrir servidores, o Azure Migrate: Discovery and assessment pode 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 o Azure Migrate and Modernize. Ele permite que você identifique e planeje um caminho de migração adaptado para suas cargas de trabalho locais.

Suporte	Detalhes
Servidores suportados	Você pode executar o inventário de software em até 10.000 servidores em execução nos Servidores vCenter adicionados a cada dispositivo Azure Migrate.
Sistemas operativos	Servidores que executam todas as versões Windows e Linux são suportados.
Requisitos de servidor	Para o inventário de software, o VMware Tools deve ser instalado e executado em seus servidores. A versão do VMware Tools deve ser a versão 10.2.1 ou posterior. Os servidores Windows devem ter o PowerShell versão 2.0 ou posterior instalado. O WMI (Instrumentação de Gerenciamento do Windows) deve estar habilitado e disponível nos servidores Windows para reunir os detalhes das funções e recursos instalados nos servidores.
Conta do vCenter Server	Para interagir com os servidores para inventário de software, a conta somente leitura do vCenter Server usada para avaliação deve ter privilégios para operações de convidado em VMs VMware.
Acesso ao servidor	Você pode adicionar várias credenciais de domínio e não domínio (Windows/Linux) no gerenciador de configuração do dispositivo para inventário de software. Você deve ter uma conta de usuário convidado para servidores Windows e uma conta de usuário padrão (acesso não-sudo) para todos os servidores Linux.
Acesso à porta	O dispositivo Azure Migrate deve ser capaz de se conectar à porta TCP 443 em hosts ESXi executando servidores nos quais você deseja executar o inventário de software. O servidor que executa o vCenter Server retorna uma conexão de host ESXi para baixar o arquivo que contém os detalhes do inventário de software. Se você usar credenciais de domínio, o dispositivo Azure Migrate deverá ser capaz de se conectar às seguintes portas TCP e UDP: TCP 135 – Ponto de extremidade RPC TCP 389 – LDAP TCP 636 – LDAP SSL TCP 445 – SMB TCP/UDP 88 – Autenticação Kerberos TCP/UDP 464 – Operações de alteração Kerberos
Deteção	O inventário de software é realizado a partir do vCenter Server usando o VMware Tools instalado nos servidores. O appliance reúne as informações sobre o inventário de software do servidor que executa o vCenter Server por meio das APIs do vSphere. O inventário de software é sem agente. Nenhum agente está instalado no servidor e o dispositivo não se conecta diretamente aos servidores.

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

O inventário de software identifica instâncias do SQL Server. O dispositivo tenta se conectar às respetivas instâncias do SQL Server por meio das credenciais de autenticação do Windows ou do SQL Server no gerenciador de configuração do dispositivo usando essas informações. O dispositivo pode se conectar somente às instâncias do SQL Server às quais ele tem linha de visão de rede. O inventário de software por si só pode não precisar de linha de visão de rede.

Depois que o dispositivo é conectado, ele coleta dados de configuração e desempenho para 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 suportados	Suportado apenas para servidores que executam o SQL Server em seus VMware, Microsoft Hyper-V e ambientes físicos/bare-metal e servidores de infraestrutura como serviço (IaaS) de outras nuvens públicas, como Amazon Web Services (AWS) e Google Cloud Platform (GCP). Você pode descobrir até 750 instâncias do SQL Server ou 15.000 bancos de dados SQL, o que for menor, a partir de um único dispositivo. Recomendamos que você verifique se um dispositivo tem escopo para descobrir menos de 600 servidores executando SQL para evitar problemas de dimensionamento.
Servidores Windows	Windows Server 2008 e posterior são suportados.
Servidores Linux	Não é atualmente suportado.
Mecanismo de autenticação	Há suporte para autenticação do Windows e do SQL Server. Você pode fornecer credenciais de ambos os tipos de autenticação no gerenciador de configuração do dispositivo.
Acesso do SQL Server	Para descobrir instâncias e bancos de dados do SQL Server, a conta do Windows ou do 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	SQL Server 2008 e posterior 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 recuperação de desastres de alta disponibilidade com tecnologia de instâncias de cluster de failover Always On e grupos de disponibilidade Always On.
Serviços SQL suportados	Somente o Mecanismo de Banco de Dados do SQL Server é suportado. Não há suporte para a descoberta do SQL Server Reporting Services, SQL Server Integration Services e SQL Server Analysis Services.

Nota

Por padrão, o Azure Migrate and Modernize usa a maneira mais segura de se conectar a instâncias SQL. Ou seja, o Azure Migrate and Modernize criptografa a comunicação entre o dispositivo Azure Migrate e as instâncias do SQL Server de origem definindo a TrustServerCertificate propriedade 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.

Configurar o logon personalizado para 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 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

O inventário de software identifica a função de servidor Web existente nos servidores descobertos. Se um servidor tiver um servidor Web instalado, o Azure Migrate and Modernize descobrirá aplicativos 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. O Azure Migrate and Modernize mapeia automaticamente as credenciais para os respetivos servidores, para que não seja necessário mapeá-las manualmente. Mais importante ainda, essas credenciais nunca são enviadas para a Microsoft e permanecem no dispositivo em execução no ambiente de origem.

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

Suporte	Aplicações Web do ASP.NET	Aplicações Web Java
Pilha	VMware, Hyper-V e servidores físicos.	VMware, Hyper-V e servidores físicos.
Servidores Windows	Windows Server 2008 R2 e posterior são suportados.	Não suportado.
Servidores Linux	Não suportado.	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 posterior.	Tomcat 8 ou posterior.
Protocolo	WinRM porta 5985 (HTTP)	Porta SSH 22 (TCP)
Privilégios necessários	Administrador local.	Usuário root ou sudo.

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. Você pode visualizar facilmente dependências com um modo de exibição de mapa em um projeto do Azure Migrate. 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 suportados	Você pode habilitar a análise de dependência sem agente em até 1.000 servidores (em vários vCenter Servers) descobertos por dispositivo.
Servidores Windows	Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 (64 bits) Windows Server 2008 (32 bits)
Servidores Linux	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 OracleLinux 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, 8.5 SUSE Linux 10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3 Debian 7, 8, 9, 10, 11
Requisitos de servidor	O VMware Tools (10.2.1 e posterior) deve estar instalado e em execução em servidores que você deseja analisar. Os servidores devem ter o PowerShell versão 2.0 ou posterior instalado. O WMI deve estar habilitado e disponível em servidores Windows.
Conta do vCenter Server	A conta somente leitura usada pelo Azure Migrate and Modernize para avaliação deve ter privilégios para operações de convidado em VMs VMware.
Acesso ao servidor Windows	Conta de utilizador 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, certifique-se de habilitar o NOPASSWD para que a conta execute os comandos necessários sem solicitar uma senha toda vez que um comando sudo for invocado. Como alternativa, 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 definidos 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
Acesso à porta	O dispositivo Azure Migrate deve ser capaz de se conectar à porta TCP 443 em hosts ESXi que executam os servidores que têm dependências que você deseja descobrir. O servidor que executa o vCenter Server retorna uma conexão de host ESXi para baixar o arquivo que contém os dados de dependência.
Método de descoberta	As informações de dependência entre servidores são coletadas usando o VMware Tools instalado no servidor que executa o vCenter Server. O appliance reúne as informações do servidor usando APIs do vSphere. Nenhum agente está instalado no servidor e o dispositivo não se conecta diretamente aos servidores.

Nota

Em algumas versões recentes do ss sistema operacional Linux, o comando netstat foi substituído pelo comando, tenha isso em mente ao preparar os servidores.

Requisitos de análise de dependência (baseados em agente)

A análise de dependência ajuda a identificar dependências entre servidores locais que você deseja avaliar e migrar para o Azure. A tabela a seguir resume os requisitos para configurar a análise de dependência baseada em agente.

Requisito	Detalhes
Antes da implantação	Você deve ter um projeto em vigor com a ferramenta Azure Migrate: Discovery and assessment adicionada ao projeto. Você implanta a visualização de dependência depois de configurar um dispositivo Azure Migrate para descobrir seus servidores locais. Saiba como criar um projeto pela primeira vez. Saiba como adicionar uma ferramenta de descoberta e avaliação a um projeto existente. Saiba como configurar o dispositivo Azure Migrate para avaliação de servidores Hyper-V, VMware ou físicos.
Servidores suportados	Suporte para todos os servidores em seu ambiente local.
Log Analytics	O Azure Migrate and Modernize usa a solução de Mapa de Serviço nos logs do Azure Monitor para visualização de dependência. Você associa um espaço de trabalho novo ou existente do Log Analytics a um projeto. Não é possível 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 estar localizado nas regiões Leste dos EUA, Sudeste Asiático ou Europa Ocidental. Espaços de trabalho em outras regiões não podem ser associados a um projeto. O espaço de trabalho deve estar em uma região na qual o Mapa de Serviços é suportado. Você pode monitorar VMs do Azure em qualquer região. As VMs em si não estão limitadas às regiões suportadas pelo espaço de trabalho do Log Analytics. No Log Analytics, o espaço de trabalho associado ao Azure Migrate é marcado com a chave do projeto e o nome do projeto.
Agentes necessários	Em cada servidor que você deseja analisar, instale os seguintes agentes: - Agente do Azure Monitor (AMA) - Agente de dependência Se os servidores locais não estiverem conectados à Internet, baixe e instale o gateway do Log Analytics neles. Saiba mais sobre como instalar o agente de dependência e o agente do Azure Monitor.
Área de trabalho do Log Analytics	O espaço de trabalho deve estar na mesma assinatura que o projeto. O Azure Migrate dá suporte a espaços de trabalho localizados nas regiões Leste dos EUA, Sudeste Asiático e Europa Ocidental. O espaço de trabalho deve estar em uma região na qual o Mapa de Serviços é suportado. Você pode monitorar VMs do Azure em qualquer região. As VMs em si não estão limitadas às regiões suportadas pelo espaço de trabalho do Log Analytics. Não é possível modificar o espaço de trabalho de um projeto depois de adicioná-lo.
Custo	A solução de Mapa de Serviços não incorre em quaisquer encargos durante os primeiros 180 dias. A contagem começa a partir do dia em que você associa o espaço de trabalho do Log Analytics ao projeto. Após 180 dias, aplicam-se os custos padrão do Log Analytics. O uso de qualquer solução diferente do Mapa de Serviços no espaço de trabalho associado do Log Analytics incorre em cobranças padrão para o Log Analytics. Quando o projeto é excluído, o espaço de trabalho não é excluído automaticamente. Depois de excluir o projeto, o uso do Mapa de Serviço não é gratuito. Cada nó é cobrado de acordo com a camada paga do espaço de trabalho do Log Analytics. Se você tiver projetos criados antes da disponibilidade geral do Azure Migrate (GA em 28 de fevereiro de 2018), poderá incorrer em outras cobranças do Mapa de Serviço. Para garantir que você seja cobrado somente após 180 dias, recomendamos que você crie um novo projeto. Os espaços de trabalho criados antes do GA ainda são cobrados.
Gestão	Ao registrar agentes no espaço de trabalho, use a ID e a chave fornecidas pelo projeto. Você pode usar o espaço de trabalho do Log Analytics fora do Azure Migrar e Modernizar. Se você excluir o projeto associado, o espaço de trabalho não será excluído automaticamente. Exclua-o manualmente. Não exclua o espaço de trabalho criado pelo Azure Migrate and Modernize, a menos que exclua o projeto. Se você fizer isso, a funcionalidade de visualização de dependência não funcionará conforme o esperado.
Ligação à Internet	Se os servidores não estiverem conectados à Internet, instale o gateway do Log Analytics nos servidores.
Azure Government	Não há suporte para análise de dependência baseada em agente.

Limitações

Requisito	Detalhes
Limites de projeto	Você pode criar vários projetos do Azure Migrate em uma assinatura do Azure. Você pode descobrir e avaliar até 50.000 servidores em um ambiente VMware em um único projeto. Um projeto pode incluir servidores físicos e servidores de um ambiente Hyper-V, até os limites de avaliação.
Deteção	O dispositivo Azure Migrate pode descobrir até 10.000 servidores em execução em vários vCenter Servers. O appliance suporta a adição de vários vCenter Servers. Você pode adicionar até 10 vCenter Servers por dispositivo. Esse valor também é válido para a Solução VMware do Azure.
Avaliação	Pode adicionar até 35 000 servidores num único grupo. Pode avaliar até 35 000 servidores numa única avaliação.

Saiba mais sobre as avaliações.

Importar servidores usando RVTools XLSX (visualização)

Como parte de sua jornada de migração para o Azure usando o dispositivo Azure Migrate, você primeiro descobre servidores, inventário e cargas de trabalho. No entanto, para uma avaliação rápida antes de implantar o dispositivo, você pode importar os servidores usando o arquivo RVTools XLSX (visualização).

Principais benefícios

Usando um arquivo RVTools XLSX:

• Ajuda a criar um business case ou avaliar os servidores antes de implantar o dispositivo.
• Ajuda como alternativa quando há uma restrição organizacional para implantar o dispositivo Azure Migrate.
• É útil quando você não pode compartilhar credenciais que permitem acesso a servidores locais.
• É útil quando restrições de segurança impedem que você colete e envie dados coletados pelo dispositivo para o Azure.

Limitações

Esta seção discute as limitações a serem consideradas.

Considerações sobre casos de negócios

Se você estiver importando servidores usando um arquivo RVTools XLSX e criando um business case, aqui estão algumas limitações:

• A duração do histórico de desempenho nas configurações do Azure não é aplicável.
• Os servidores são classificados como desconhecidos no gráfico de insights de utilização do business case e são dimensionados como estão, sem dimensionamento correto para o custo da Solução VMware do Azure ou do Azure.

Considerações de avaliação

Se você estiver importando servidores usando um arquivo RVTools XLSX para criar uma avaliação com os seguintes critérios:

• Critérios de dimensionamento como baseados no desempenho da CPU e memória configuradas (com base nas CPUs e colunas de memória do RVTools XLSX).
• Critérios de armazenamento (MiB em uso e MB em uso para versões anteriores à 4.1.2).

Você não poderá fornecer histórico de desempenho ou informações de percentil.

Para obter uma adequação/prontidão precisa do sistema operacional na avaliação da VM do Azure e da Solução VMware do Azure, insira a versão e a arquitetura do sistema operacional nas respetivas colunas.

Próximos passos

• Rever as melhores práticas de avaliação.
• Saiba como se preparar para uma avaliação VMware.