Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo resume os pré-requisitos e requisitos de suporte para a utilização da ferramenta Azure Migrate: Discovery and assessment para descobrir e avaliar servidores num ambiente VMware para migração para Azure.
Para avaliar servidores, primeiro, crie um projeto Azure Migrate. A ferramenta Azure Migrate: Discovery and assessment é automaticamente adicionada ao projeto. Depois, implementa o appliance Azure Migrate. O appliance detecta continuamente servidores on-premises ou Solução VMware no Azure 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 planear a migração dos servidores VMware para 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: descoberta e avaliação requer uma conta vCenter Server de leitura apenas. 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 operacionais | Todos os sistemas operativos Windows e Linux podem ser avaliados para migração. |
| Armazenamento | Há suporte para discos conectados a controladores baseados em SCSI, IDE e SATA. |
Requisitos do appliance do Azure Migrate
Azure Migrate e Modernize utilizam o appliance 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, deve implementar 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 | Conexão |
|---|---|
| Azure Migrate appliance | Ligações de entrada na porta TCP 3389 para permitir ligações de ambiente de trabalho remoto à aplicação. 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) para enviar metadados de descoberta e desempenho para Azure Migrate 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 se conecta ao vCenter na porta 443 por padrão. Se o vCenter Server escutar numa porta diferente, você poderá alterar a porta quando configurar a descoberta. |
| Anfitriões ESXi | Para descoberta do inventário de software ou análise de dependência sem agente, o dispositivo conecta-se 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
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. Permite-lhe identificar e planear um percurso de migração adaptado às suas cargas de trabalho on-premises ou do Solução VMware no Azure.
| Apoio | Detalhes |
|---|---|
| Servidores suportados | Pode realizar um inventário de software em até 10.000 servidores que estão a funcionar nos servidores vCenter, adicionados a cada dispositivo Azure Migrate. |
| Sistemas operacionais | São suportados servidores com todas as versões para Windows e Linux. |
| 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 PowerShell versão 2.0 ou posterior instalada. O Windows Management Instrumentation (WMI) deve estar ativado e disponível nos servidores Windows para recolher os detalhes dos papéis e funcionalidades instalados nos servidores. |
| Conta do vCenter Server | Para interagir com os servidores para inventário de software, a conta somente leitura do vCenter Server utilizada para avaliação de software deve ter privilégios para operações de sistema convidado em VMware VMs. |
| Acesso ao servidor | Pode adicionar múltiplos domínios e credenciais sem domínio (Windows/Linux) no gestor de configuração da appliance para inventário de software. Deve ter uma conta de utilizador convidado para servidores Windows e uma conta de utilizador padrão (não acesso sudo) para todos os servidores Linux. |
| Acesso ao porto | O appliance Azure Migrate deve conseguir ligar-se à porta TCP 443 em hosts ESXi que executam servidores onde pretende realizar 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 usar credenciais de domínio, o appliance Azure Migrate deve conseguir ligar-se à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 no Kerberos |
| Descoberta | 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âncias e bases de dados do SQL Server
Inventário de software identifica instâncias do SQL Server. O appliance tenta conectar-se às respetivas instâncias do SQL Server através das credenciais de autenticação Windows Authentication ou SQL Server estabelecidas 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 que estão a executar o SQL Server no VMware, Microsoft Hyper-V e ambientes físicos/bare-metal, bem como em servidores de infraestrutura como serviço (IaaS) de outras nuvens públicas, como a Amazon Web Services (AWS) e a Google Cloud Platform (GCP). 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 se assegure de que uma aplicação tenha escopo para descobrir menos de 600 servidores que executam SQL para evitar problemas de escalonamento. |
| 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 recuperação de desastres de alta disponibilidade, 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. |
Observação
Por defeito, o Azure Migrate and Modernize 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 existente nos servidores descobertos. Se um servidor tiver 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 Windows Server 2008 R2 e posteriores. | Não suportado. |
| Servidores Linux | Não suportado | Servidores que cumprem os requisitos |
| Versões do servidor Web | IIS 7.5 e posterior. | Tomcat 8 ou posterior. |
| Conexão | Usa ferramentas VMware. Se as ferramentas VMware não estiverem instaladas, a porta WinRM 5986 (HTTPS) é usada por defeito. Se os pré-requisitos HTTPS não estiverem configurados nos servidores alvo, a comunicação volta para a porta WinRM 5985 (HTTP) | Usa ferramentas VMware. Se as ferramentas VMware não estiverem instaladas, utiliza-se a porta SSH 22 (TCP). |
| Privilégios necessários | O utilizador 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 os seguintes locais: 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. |
Observação
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 (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, 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 | O VMware Tools (10.2.1 e posterior) deve estar instalado e em execução em servidores que você deseja analisar. Os servidores Windows têm 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 ativado e disponível nos servidores Windows. |
| Conta do vCenter Server | A conta de somente leitura usada pelo Azure Migrate e pelo Modernize para avaliação deve ter privilégios para operações de convidado em máquinas virtuais (VMs) VMware. |
| Acesso a servidores Windows | 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. 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. |
| Acesso ao porto | Appliance Azure Migrate deve conseguir ligar-se na porta TCP 443 em hosts ESXi que executam os servidores cujas dependências pretende 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. |
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 de análise de dependência (baseados em agente)
Análise de dependências ajuda-o a identificar dependências entre servidores on-premises ou Solução VMware no Azure que pretende avaliar e migrar para 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 | Deves ter um projeto implementado com a ferramenta Azure Migrate: Discovery and assessment adicionada ao projeto. Implementa a visualização de dependências depois de configurar um appliance Azure Migrate para descobrir os seus servidores on-premises ou Solução VMware no Azure. Saiba como criar um projeto pela primeira vez. Saiba como adicionar uma ferramenta de descoberta e avaliação a um projeto existente. Aprenda a configurar o Azure Migrate appliance para avaliação de Hyper-V, VMware ou servidores físicos. |
| Servidores suportados | Suportado para todos os servidores no seu ambiente on-premises e Solução VMware no Azure. |
| Análise de Registos | Azure Migrate e o Modernize utilizam a solução Service Map nos registos Azure Monitor para visualização de dependências. Associa um novo ou existente espaço de trabalho de 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 associado à mesma subscrição 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. Pode monitorizar VMs do Azure em qualquer região. As VMs em si não se limitam às regiões suportadas pelo espaço de trabalho do Log Analytics. No Log Analytics, o espaço de trabalho associado ao Azure Migrate é etiquetado com a chave do projeto e o nome do projeto. |
| Agentes necessários | Em cada servidor que você deseja analisar, instale os seguintes agentes: - Azure Monitor agent (AMA) - Agente de dependência Se os servidores on-premises ou Solução VMware no Azure não estiverem ligados à internet, descarregue e instale o gateway Log Analytics neles. Saiba mais sobre a instalação do agente Dependency e do agente Azure Monitor. |
| Espaço de trabalho Log Analytics | O espaço de trabalho deve estar associado à mesma subscrição que o projeto. O Azure Migrate suporta espaços de trabalho localizados nas regiões do 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. Pode monitorizar VMs do Azure em qualquer região. As VMs em si não se limitam à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 no dia em que associa o espaço de trabalho Log Analytics ao projeto. Após 180 dias, aplicam-se as taxas padrão da Log Analytics. Usar qualquer solução que não seja o Service Map no espaço de trabalho de Log Analytics associado implica encargos padrão para 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 o nível pago do espaço de trabalho Log Analytics. Se tiver projetos que criou antes da disponibilidade geral do Azure Migrate (GA a 28 de fevereiro de 2018), poderá incorrer noutros custos relacionados com o Service Map. 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. Pode usar o espaço de trabalho Log Analytics fora do Azure Migrate e Modernize. Se você excluir o projeto associado, o espaço de trabalho não será excluído automaticamente. Exclua-o manualmente. Não apague o espaço de trabalho criado pelo Azure Migrate and Modernize a menos que apague o projeto. Se você fizer isso, a funcionalidade de visualização de dependência não funcionará conforme o esperado. |
| conectividade Internet | Se os servidores não estiverem ligados à internet, instale o gateway Log Analytics nos servidores. |
| Azure Government | Não há suporte para análise de dependência baseada em agente. |
Limitações
| Requisito | Detalhes |
|---|---|
| Limites do Project | Pode criar vários projetos Azure Migrate numa subscrição Azure. Você pode descobrir e avaliar até 35.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é aos limites de avaliação. |
| Descoberta | O Azure Migrate appliance 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. A escala também é válida para aceder a servidores descobertos para Azure Migrate VMware Solution (AVS). O mesmo vCenter pode ser descoberto por vários dispositivos dentro do 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 | 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 da sua jornada de migração para o Azure, utilizando o appliance Azure Migrate, 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.
- Aids como alternativa quando existe uma restrição organizacional para implementar o appliance Azure Migrate.
- É útil quando não podes partilhar credenciais que permitem acesso a servidores on-premises ou Solução VMware no Azure.
- É útil quando restrições de segurança impedem que recolha e envie dados recolhidos pelo appliance para o Azure.
Limitações
Esta seção discute as limitações a serem consideradas.
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 definições do Azure não é aplicável.
- Os servidores estão classificados como desconhecidos no gráfico de insights de utilização do business case e são dimensionados tal como estão, sem redimensionamento adequado para os custos do Azure ou da Solução VMware no Azure.
Próximos passos
- Rever as melhores práticas de avaliação.
- Saiba como se preparar para uma avaliação VMware.