Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo resume os pré-requisitos e os requisitos de suporte para usar o Migrações para Azure: ferramenta de descoberta e avaliação para descobrir e avaliar servidores em um ambiente VMware para migração para Azure.
Para avaliar os servidores, primeiro, crie um projeto de Migrações para Azure. A ferramenta Migrações para Azure: Descoberta e avaliação é adicionada automaticamente ao projeto. Em seguida, implante o dispositivo de Migrações para Azure. O dispositivo descobre continuamente servidores locais ou Solução VMware no Azure e envia metadados de configuração e desempenho para 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 Azure, consulte a matriz de suporte migration.
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 por meio do fornecimento de detalhes do host ESXi no appliance. 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 requer 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 quanto à migração. |
| Armazenamento | Há suporte para discos anexados a controladores SCSI, IDE e SATA. |
Migrações para Azure requisitos do dispositivo
Migrações para Azure e Modernize usa a ferramenta Migrações para Azure appliance 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:
- Em 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 |
|---|---|
| Migrações para Azure dispositivo | Conexões de entrada na porta TCP 3389 para permitir conexões remotas à área de trabalho do equipamento. 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 o Migrações para Azure e 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 é 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, o Migrações para Azure: Discovery and assessment pode realizar 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 descobertos usando Migrações para Azure e Modernizar. Ele permite identificar e planejar um caminho de migração personalizado para suas cargas de trabalho locais ou Solução VMware no Azure.
| Apoio | Detalhes |
|---|---|
| Servidores com suporte | Você pode realizar o inventário de software em até 10.000 servidores operando nos vCenter Servers, adicionados a cada instância do Migrações para Azure. |
| Sistemas operacionais | Há suporte para servidores que executam todas as versões 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. Windows servidores devem ter o PowerShell versão 2.0 ou posterior instalado. Instrumentação de Gerenciamento do Windows (WMI) deve estar habilitada e disponível nos servidores Windows para coletar os detalhes das funções e recursos instalados nos servidores. |
| Conta do vCenter Server | Para interagir com os servidores para o inventário de software, a conta de somente leitura do vCenter Server usada para avaliação deve ter privilégios para as operações de convidado nas VMs do VMware. |
| Acesso ao servidor | Você pode adicionar vários domínios e credenciais de nondomain (Windows/Linux) no gerenciador de configurações 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 Migrações para Azure deve ser capaz de se conectar à porta TCP 443 em hosts ESXi que executam servidores nos quais você deseja executar o inventário de software. 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 para descoberta de instância e banco de dados do SQL Server
Software inventory identifica instâncias de SQL Server. O dispositivo tenta se conectar às respectivas 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 SQL Server às quais ele tem 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 que o dispositivo estiver conectado, ele coletará dados de configuração e desempenho para SQL Server instâncias e bancos de dados. 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 com suporte | Com suporte apenas para servidores que executam SQL Server em seu VMware, Microsoft Hyper-V e ambientes físicos/bare-metal e servidores iaaS (infraestrutura como serviço) de outras nuvens públicas, como o Amazon Web Services (AWS) e o Google Cloud Platform (GCP). Você pode descobrir até 750 instâncias de SQL Server ou 15.000 bancos de dados SQL, o que for menor, de 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 | Windows Server 2008 e posteriores têm suporte. |
| Servidores Linux | Atualmente sem suporte. |
| Mecanismo de autenticação | Há suporte para autenticação Windows e 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 as instâncias e bancos de dados SQL Server, a conta Windows/Domínio ou a conta SQL Server requer essas permissões de leitura de baixo privilégio para cada instância 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. |
| SQL Server versões | SQL Server 2008 e posteriores têm suporte. |
| edições do SQL 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 desastre de alta disponibilidade alimentadas por Instâncias de cluster de failover Always On e grupos de disponibilidade AlwaysOn. |
| Serviços SQL com suporte | É oferecido suporte apenas para o Mecanismo de Banco de Dados do SQL Server. Não há suporte para a descoberta de SQL Server Reporting Services, SQL Server Integration Services e SQL Server Analysis Services. |
Observação
Por padrão, Migrações para Azure e Modernize usa a forma mais segura de conexão com instâncias SQL. Ou seja, Migrações para Azure e Modernizar criptografa a comunicação entre o dispositivo de Migrações para Azure e as instâncias de 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 appliance. Saiba mais para entender o que escolher.
Configurar o logon personalizado para a 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 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, Migrações para Azure e Modernizar descobrirá aplicativos Web no servidor.
Você pode adicionar credenciais de domínio e não domínio no dispositivo. Verifique se a conta usada tem privilégios de administrador local nos servidores de origem. Migrações para Azure e Modernizar 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 para 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 ASP.NET aplicativos Web (servidor Web IIS) e aplicativos Web Java (servidores Tomcat). Os dados de configuração dos aplicativos Web são atualizados a cada 24 horas.
| Apoio | ASP.NET aplicativos Web | Java aplicativos Web |
|---|---|---|
| Pilha | VMware, Hyper-V e servidores físicos. | VMware, Hyper-V e servidores físicos. |
| servidores Windows | Windows Server 2008 R2 e posteriores têm suporte. | Não há suporte. |
| Servidores Linux | Sem suporte | Servidores que atendem aos requisitos |
| Versões do servidor Web | IIS 7.5 e versões posteriores. | Tomcat 8 ou versões posteriores. |
| Conexão | Usa ferramentas do VMware. Se as ferramentas do VMware não estiverem instaladas, a porta WinRM 5986 (HTTPS) será usada por padrão. Se os pré-requisitos HTTPS não estiverem configurados nos servidores de destino, a comunicação retornará à porta WinRM 5985 (HTTP) | Usa ferramentas do VMware. Se as ferramentas do VMware não estiverem instaladas, a porta SSH 22 (TCP) será usada. |
| Privilégios necessários | O usuário deve fazer parte dos dois grupos de usuários 1. Usuários de Gerenciamento Remoto 2. IIS_IUSRS. Os usuários devem ter permissões de leitura para os seguintes diretórios: C:\Windows\system32\inetsrv\config, C:\Windows\system32\inetsrv\config\applicationHost.config e C:\Windows\system32\inetsrv\config\redirection.config. Adicione o usuário a "fazer logon como tarefa em lote" com o uso de secpol.msc e verifique se o usuário não faz parte do "negar logon como tarefa em lote" | Ler (r) e Executar (x) permissões recursivamente em todos os diretórios CATALINA_HOME. |
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 Migrações para Azure. Você pode usar dependências para agrupar servidores relacionados para migração para Azure. A tabela a seguir resume os requisitos para configurar a análise de dependência sem agente.
| Apoio | 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 6.x, 7.x, 8.x, 9.x, 9.5 Ubuntu 24.04, 22.04, 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, 11 Alma Linux 8.x, 9.x Rocky Linux 8.x, 9.x |
| Requisitos de servidor | As ferramentas do VMware (10.2.1 e posterior) devem ser instaladas e executadas nos servidores que você deseja analisar. Windows Servers têm o PowerShell versão 2.0 ou posterior. Os servidores Linux têm o Bash versão 4.0 ou posterior instalado. O WMI deve estar habilitado e disponível em servidores Windows. |
| Conta do vCenter Server | A conta somente leitura usada por Migrações para Azure e Modernizar para avaliação deve ter privilégios para operações de convidado em VMs VMware. |
| Acesso ao Windows Server | Uma conta de usuário (local ou domínio) com permissões de administrador em servidores. |
| 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. |
| Acesso à porta | O dispositivo Migrações para Azure deve ser capaz de se conectar à porta TCP 443 em hosts ESXi executando os servidores que têm dependências que 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)
Dependency analysis ajuda a identificar dependências entre servidores locais ou Solução VMware no Azure que você deseja avaliar e migrar para 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 o Migrações para Azure: ferramenta de descoberta e avaliação adicionada ao projeto. Você implanta a visualização de dependência depois de configurar um dispositivo de Migrações para Azure para descobrir seus servidores locais ou Solução VMware no Azure. Aprenda a criar um projeto pela primeira vez. Aprenda a adicionar uma ferramenta de descoberta e avaliação a um projeto existente. Saiba como configurar o dispositivo de Migrações para Azure para avaliação de servidores físicos Hyper-V, VMware ou físicos. |
| Servidores com suporte | Com suporte para todos os servidores em seu ambiente local e Solução VMware no Azure. |
| Análise de Logs | Migrações para Azure and Modernize usa a solução Service Map nos logs do Azure Monitor para visualização de dependências. Você associa um workspace 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 Azure VMs em qualquer região. As próprias VMs não se limitam às regiões compatíveis com o workspace Log Analytics. Em Log Analytics, o workspace associado ao Migrações para Azure é marcado com a chave do projeto 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 ou Solução VMware no Azure não estiverem conectados à Internet, baixe e instale o gateway de Log Analytics neles. Saiba mais sobre como instalar o agente Dependency e o agente Azure Monitor. |
| Área de trabalho do Log Analytics | O espaço de trabalho deve estar na mesma assinatura que o projeto. Migrações para Azure dá suporte a workspaces localizados nas regiões Leste dos EUA, Sudeste Asiático e Oeste da Europa. O workspace deve estar em uma região onde o Mapa do Serviço é suportado. Você pode monitorar Azure VMs em qualquer região. As próprias VMs não se limitam às regiões compatíveis com o workspace Log Analytics. Você não pode modificar o espaço de trabalho de um projeto depois de adicioná-lo. |
| Custo | A solução Mapa do Serviço não incorre em nenhuma cobrança nos primeiros 180 dias. A contagem começa a partir do dia em que você associa o workspace Log Analytics ao projeto. Após 180 dias, os encargos de Log Analytics padrão se aplicam. Usar qualquer solução diferente do Mapa de Serviço no workspace Log Analytics associado resulta 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 você tiver projetos que criou antes da disponibilidade geral do Migrações para Azure (GA) em 28 de fevereiro de 2018, poderá incorrer em cobranças adicionais do Service Map. Para garantir que você seja cobrado só após 180 dias, recomendamos que você crie um novo projeto. Os workspaces que foram criados antes da disponibilidade geral ainda sã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 do Log Analytics fora do Migrações para Azure and Modernize. Caso exclua o projeto associado, o espaço de trabalho não será excluído automaticamente. Exclua-o manualmente. Não exclua o workspace criado pelo Migrações para Azure e Modernize, a menos que você exclua 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 Log Analytics nos servidores. |
| Azure Governamental | A análise de dependência baseada em agente não é suportada. |
Limitações
| Requisito | Detalhes |
|---|---|
| Limites do projeto | Você pode criar vários projetos Migrações para Azure em uma assinatura Azure. É possível descobrir e avaliar até 35.000 servidores em um ambiente do VMware em um só projeto. Um projeto pode incluir servidores físicos e servidores de um ambiente de Hyper-V, até os limites de avaliação. |
| Descoberta | O dispositivo Migrações para Azure pode descobrir até 10.000 servidores em execução em vários servidores vCenter. O dispositivo dá suporte à adição de vários vCenter Servers. Você pode adicionar até 10 vCenter Servers por dispositivo. A escala também é válida para acessar servidores descobertos para Migrações para Azure AVS (Solução VMware). O mesmo vCenter pode ser descoberto por vários dispositivos no mesmo projeto, mas não é recomendável ter a mesma VM descoberta por vários dispositivos. Mais detalhes sobre como definir o escopo de descoberta. |
| 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 percurso de migração para Azure usando o dispositivo de Migrações para Azure, primeiro você 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 de Migrações para Azure.
- É útil quando você não pode compartilhar credenciais que permitem o acesso a servidores locais ou Solução VMware no Azure.
- É útil quando restrições de segurança impedem que você colete e envie dados coletados pelo dispositivo para Azure.
Limitações
Esta seção discute as limitações a serem consideradas.
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 de Azure não é aplicável.
- Os servidores são classificados como desconhecidos no gráfico de insights sobre casos de uso empresarial e são dimensionados sem ajuste de dimensionamento para custos do Azure ou Solução VMware no Azure.
Próximas etapas
- Revise melhores práticas de avaliação.
- Saiba como se preparar para uma avaliação do VMware.