Matriz de suporte para descoberta do VMware

Este artigo resume os pré-requisitos e requisitos de suporte usando a ferramenta Migrações para Azure: descoberta e avaliação para descobrir e avaliar servidores em um ambiente do VMware para migrações para Azure.

Observação

Essa documentação do cenário de migração de VMware de ponta a ponta está atualmente em versão prévia. Para obter mais informações sobre como usar as Migrações para Azure, confira a Documentação do produto Migrações para Azure.

Para avaliar servidores, primeiro crie um projeto Migrações para Azure. A ferramenta Migrações para Azure: descoberta e avaliação será adicionada automaticamente ao projeto. Depois, implante o dispositivo das Migrações para Azure. O dispositivo descobre, continuamente, servidores locais e envia os 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 dos 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 por um 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 que fornecem 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 Migrações para Azure: descoberta e avaliação exige uma conta somente leitura do vCenter Server. Se você deseja usar a ferramenta para inventário de software, análise de dependência sem agente, aplicativos Web e descoberta do SQL, a conta deve ter privilégios para operações de convidado em máquinas virtuais (VMs) VMware.

Requisitos de servidor

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

Requisitos de dispositivo para as Migrações para Azure

A Migração e Modernização do Microsoft Azure usa o dispositivo Migrações para Azure para descoberta e avaliação. Você pode implantar o dispositivo como um servidor em seu ambiente VMware usando um modelo de VMware Open Virtualization dispositivo importado no vCenter Server. Você também pode usar um script doPowerShell. Saiba mais sobre os requisitos de dispositivo para VMware.

Estes são outros requisitos adicionais para o dispositivo:

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

Requisitos de porta de acesso

Dispositivo	Conexão
Dispositivo de Migrações para Azure	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 na porta 443 (HTTPS) para enviar metadados de descoberta e desempenho para a Migração e Modernização do Microsoft Azure.
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 é conectado ao vCenter na porta 443 por padrão. Se o vCenter Server for detectado em uma porta diferente, você pode modificar a porta ao configurar a descoberta.
Hosts ESXi	Para descoberta do inventário de softwareou análise de dependência sem agente, o dispositivo se conectará aos hosts ESXi na porta TCP 443 para descobrir o inventário de software e as dependências nos servidores.

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 a Migração e Modernização do Microsoft Azure. Ele permite identificar e planejar um caminho de migração adaptado às cargas de trabalho locais.

Suporte	Detalhes
Servidores com suporte	Você pode realizar o inventário de software em até 10.000 servidores em execução nos vCenter Servers adicionados a cada dispositivo do Migrações para Azure.
Sistemas operacionais	Com suporte para servidores que executam todas as versões do Windows e Linux.
Requisitos de servidor	Para o inventário de softwares, é necessário instalar as ferramentas do VMware e executá-las nos servidores. A versão das ferramentas do VMware deve ser a versão 10.2.1 ou posterior. Os servidores do Windows precisam ter o PowerShell versão 2.0 ou posterior instalado. A Instrumentação de Gerenciamento do Windows (WMI) deve estar habilitada e disponível nos servidores Windows para reunir os detalhes das funções e dos 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 nas VMs do VMware.
Acesso ao servidor	Você pode adicionar várias credenciais de domínio e não domínio (Windows/Linux) no gerenciador de configurações do dispositivo para o 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 de Migrações para Azure deve ser capaz de conectar-se à porta TCP 443 em hosts ESXi que executam servidores nos quais você deseja executar o inventário de softwares. O servidor executando 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 Migrações para Azure deverá ser capaz de se conectar às seguintes portas TCP e UDP: TCP 135 – Ponto de Extremidade de 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 do Kerberos
Descoberta	O inventário de softwares é executado no vCenter Server usando as ferramentas do VMware instaladas nos servidores. O dispositivo reúne as informações sobre o inventário de software do servidor executando vCenter Server por meio das APIs do vSphere. O inventário de software não tem agente. Nenhum agente será instalado no servidor e o dispositivo não se conectará diretamente aos 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. O dispositivo tenta conectar-se às respectivas instâncias do SQL Server por meio da autenticação do Windows ou das credenciais de autenticação do SQL Server no gerenciador de configurações do dispositivo usando essas informações. O dispositivo pode conectar-se apenas às instâncias do SQL Server com as quais ele tem uma 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 em servidores que executam o SQL Server em seus ambientes VMware, Microsoft Hyper-V e físico/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). É 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 de SQL autônomas, altamente disponíveis e protegidas contra desastres. Também há suporte para a descoberta de implantações de SQL de recuperação de desastres de alta disponibilidade com base em instâncias de cluster de failover Always On e grupos de disponibilidade Always On.
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, a Migração e Modernização do Microsoft Azure utiliza a forma mais segura de se conectar às instâncias SQL. Ou seja, a Migração e Modernização do Microsoft Azure criptografa a comunicação entre o dispositivo Migrações para Azure e as instâncias do SQL Server de origem 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.

Configurar o logon personalizado para descoberta do SQL Server

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

O inventário de software identifica a função de servidor Web existente nos servidores descobertos. Se um servidor tiver um servidor Web instalado, a Migração e Modernização do Microsoft Azure 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. A Migração e Modernização do Microsoft Azure mapeia automaticamente as credenciais para os respectivos servidores, para que você não precise mapeá-las 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.
Protocolo	Porta WinRM 5985 (HTTP)	Porta SSH 22 (TCP)
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 ativar 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 e 8.5 SUSE Linux 10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3 Debian 7, 8, 9, 10 e 11
Requisitos de servidor	As ferramentas do VMware (10.2.1 e posterior) devem ser instaladas e executadas nos 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 pela Migração e Modernização do Microsoft Azure para avaliação deve ter privilégios para operações de convidado em VMs VMware.
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. Caso esteja fornecendo uma conta de usuário com acesso ao sudo, verifique se você habilitou NOPASSWD para a conta a fim de executar os comandos necessários sem solicitar uma senha sempre que um 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 /bin/ls sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
Acesso à porta	O dispositivo de Migrações para Azure deve conseguir se conectar à porta TCP 443 em hosts ESXi que executam os servidores com as dependências você deseja descobrir. O servidor executando 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 as ferramentas do VMware instaladas no servidor executando VCenter Server. O dispositivo 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.

Observação

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

Requisitos da análise de dependência baseada (com agente)

A análise de dependência ajuda a identificar dependências entre os servidores locais que você 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.

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 descoberta e 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.
Servidores com suporte	Com suporte para todos os servidores no ambiente local.
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 workspace deve estar localizado 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 à Migrações para Azure é marcado com a chave e o nome do projeto.
Agentes necessários	Instale os seguintes agentes em cada servidor que quiser analisar: – 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. Saiba mais sobre a instalação do agente de dependência e o agente do Azure Monitor.
Espaço de Trabalho do Log Analytics	O espaço de trabalho deve estar na mesma assinatura que o projeto. As Migrações para Azure são compatíveis com os workspaces localizados nas regiões leste dos EUA, sudeste da Ásia e oeste da Europa. 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 após adicioná-lo.
Custo	A solução Mapa do Serviço não incorre em nenhuma cobrança nos primeiros 180 dias. A contagem inicia a partir do 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.

Limitações

Requisito	Detalhes
Limites do projeto	Você pode criar vários projetos Migrações para Azure em uma assinatura do Azure. É possível descobrir e avaliar até 50.000 servidores em um ambiente do 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.
Descoberta	O dispositivo de Migrações para Azure pode descobrir até 10.000 servidores em execução em vários vCenter Servers. O dispositivo dá suporte à 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 no Azure.
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.

Importar servidores usando o RVTools XLSX (versão prévia)

Como parte do seu percurso de migração para o Azure usando o dispositivo Migrações para Azure, você primeiro descobre servidores, inventário e cargas de trabalho. No entanto, para uma avaliação rápida antes de implementar o dispositivo, você pode importar os servidores usando o arquivo RVTools XLSX (versão prévia).

Principais benefícios

Usando um arquivo XLSX do RVTools:

• Ajuda a criar um caso de negócios ou avaliar os servidores antes de implantar o dispositivo.
• Ajuda como alternativa quando há uma restrição organizacional para implantar o dispositivo Migrações para Azure.
• É útil quando você não pode compartilhar credenciais que permitem o acesso a servidores locais.
• É útil quando as restrições de segurança o impedem de reunir e enviar os 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 estiver importando servidores usando um arquivo XLSX do RVTools e criando um caso de negócios, 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 caso de negócios e são dimensionados como estão, sem o dimensionamento correto para o custo do Azure ou da Solução VMware no Azure.

Considerações sobre a avaliação

Caso esteja importando servidores usando um arquivo RVTools XLSX para criar uma avaliação com os seguintes critérios:

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

Não é possível fornecer informações de histórico de desempenho ou percentil.

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

Próximas etapas

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