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 quando descobre e avalia servidores on-premises a correr num ambiente Hyper-V para migração para Azure utilizando a ferramenta Azure Migrate: Discovery and assessment. Se quiser migrar servidores a correr em Hyper-V para Azure, consulte a matriz de suporte migração.
Para configurar a descoberta e avaliação de servidores a correr no Hyper-V, cria-se um projeto e adiciona-se a ferramenta Azure Migrate: Discovery and assessment ao projeto. Depois de adicionar a ferramenta, implementas o appliance Azure Migrate. O appliance descobre continuamente servidores on-premises e envia metadados e dados de desempenho do servidor para o Azure. Após a conclusão da descoberta, você reúne os servidores descobertos em grupos e executa uma avaliação para um grupo.
Limitações
| Suporte | Detalhes |
|---|---|
| Limites de avaliação | Você pode descobrir e avaliar até 35.000 servidores em um único projeto. |
| Limites do Project | Pode criar vários projetos numa subscrição do Azure. Para além dos servidores em Hyper-V, um projeto pode incluir servidores em VMware e servidores físicos, até aos limites de avaliação para cada um. |
| Descoberta | O appliance Azure Migrate pode descobrir até 5.000 servidores a correr no Hyper-V. O appliance pode ligar-se a até 300 hosts Hyper-V. |
| Avaliação | Pode adicionar até 35 000 servidores num único grupo. Você pode avaliar até 35.000 servidores em uma única avaliação para um grupo. |
Saiba mais sobre avaliações.
Requisitos do host Hyper-V
| Suporte | Detalhes |
|---|---|
| Hospedeiro Hyper-V | O host Hyper-V pode ser autónomo ou implementado num cluster. O host Hyper-V pode executar Windows Server 2022, Windows Server 2019, Windows Server 2016 ou Windows Server 2012 R2. As instalações Server Core desses sistemas operacionais também são suportadas. Não podes avaliar servidores localizados em hosts Hyper-V a correr Windows Server 2012. |
| Permissões | Precisas de permissões de administrador no host Hyper-V. Se não quiser atribuir permissões de Administrador, crie uma conta de utilizador local ou de domínio e adicione a conta de utilizador a estes grupos: Utilizadores de Gestão Remota, Administradores Hyper-V e Utilizadores do Performance Monitor. |
| Remotização do PowerShell | PowerShell remoting deve estar ativada em cada host Hyper-V. |
| Réplica Hyper-V | Se usar o Hyper-V Replica (ou tiver vários servidores com os mesmos identificadores de servidor), e descobrir tanto o servidor original como o replicado usando o Azure Migrate e o Modernize, a avaliação gerada pelo Azure Migrate e Modernize pode não ser precisa. |
Requisitos de servidor
| Suporte | Detalhes |
|---|---|
| Sistema operativo | Todos os sistemas operacionais podem ser avaliados para migração. |
| Serviços de integração | Hyper-V Integration Services deve estar a correr em servidores que avalia para capturar informação do sistema operativo. |
| Armazenamento | Disco local, DAS, JBOD, Espaços de Armazenamento, CSV e SMB. Estes são os armazenamentos do Hyper-V Host nos quais os VHD/VHDX são armazenados e que são suportados. Controladores virtuais IDE e SCSI são suportados. |
Requisitos do appliance do Azure Migrate
Azure Migrate e Modernize utilizam o appliance Azure Migrate para descoberta e avaliação. Podes implementar o appliance usando um VHD comprimido Hyper-V que descarregas do portal ou usando um script PowerShell. Para mais informações:
- Aprenda sobre os requisitos de dispositivo para Hyper-V.
- Saiba mais sobre os URLs que o dispositivo precisa acessar em nuvens públicas e governamentais .
- Usa o script para implementar o appliance em Azure Government.
Acesso ao porto
A tabela a seguir resume os requisitos de portas para avaliação.
| Dispositivo | Ligação |
|---|---|
| Aparelho | 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>:44368Ligações de saída na porta 443 (HTTPS) com a finalidade de enviar metadados de descoberta e desempenho para o Azure Migrate e Modernize. |
| Hyper-V anfitrião/cluster | A ligação de entrada usa a porta WinRM 5986 (HTTPS) por defeito. Se os pré-requisitos HTTPS não estiverem configurados nos servidores alvo, a comunicação recorre à porta WinRM 5985 (HTTP) para recolher metadados e dados de desempenho para servidores Hyper-V através de uma sessão do Common Information Model (CIM). |
| Servidores | Os servidores Windows precisam de acesso na porta 5986 (HTTPS) ou na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP) para realizar inventário de software e análise de dependência sem agente. |
Requisitos de inventário de software
Para além de descobrir servidores, o Azure Migrate: Discovery and Assessment pode realizar inventário de software nos servidores. O inventário de software fornece a lista de aplicações, funções e funcionalidades a correr em servidores Windows e Linux que são descobertas através do Azure Migrate e Modernize. Ele ajuda você a identificar e planejar um caminho de migração adaptado para suas cargas de trabalho locais.
| Suporte | Detalhes |
|---|---|
| Servidores suportados | Pode efetuar um inventário de software em até 5.000 servidores em execução em hosts/clusters Hyper-V adicionados a cada dispositivo Azure Migrate. |
| Sistemas operativos | Todas as versões Windows e Linux com serviços de integração Hyper-V ativados. |
| Requisitos de servidor | Os servidores Windows devem ter o remoting do PowerShell ativado e a versão 2.0 ou posterior do PowerShell instalada. O WMI deve estar ativado e disponível nos servidores Windows para recolher os detalhes dos papéis e funcionalidades instalados nos servidores. Os servidores Linux devem ter a conectividade Secure Shell (SSH) habilitada e garantir que os seguintes comandos possam ser executados nos servidores Linux para extrair os dados do aplicativo: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Com base no tipo de sistema operacional e no tipo de gerenciador de pacotes que está sendo usado, aqui estão mais alguns comandos: rpm/snap/dpkg, yum/apt-cache, mssql-server. |
| 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 | Os servidores Windows precisam de acesso na porta 5986 (HTTPS) ou na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP). 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 Kerberos |
| Descoberta | O inventário de software é realizado conectando-se diretamente aos servidores usando as credenciais do servidor adicionadas no dispositivo. O dispositivo recolhe a informação sobre o inventário de software em servidores Windows usando a remotização PowerShell e em servidores Linux usando a ligação SSH. O inventário de software é sem agente. Nenhum agente está instalado nos servidores. |
Requisitos de descoberta de instâncias e bases de dados do SQL Server
Inventário de software identifica instâncias do SQL Server. O appliance utiliza esta informação e tenta ligar-se às respetivas instâncias do SQL Server através das credenciais de Windows authentication ou SQL Server fornecidas no gestor de configuração do appliance. 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. Os dados de configuração do SQL Server são atualizados uma vez a cada 24 horas. Os dados de desempenho são capturados a cada 30 segundos.
| Suporte | Detalhes |
|---|---|
| Servidores suportados | Suportado apenas para servidores a correr SQL Server no seu VMware, Microsoft Hyper-V e ambientes físicos/bare-metal e servidores de infraestrutura como serviço (IaaS) de outras clouds públicas, como Azure Web Services e Google Cloud Platform. Pode encontrar até 750 instâncias do SQL Server ou 15.000 bases de dados SQL, o que for menor, a partir de um único dispositivo. Recomendamos que 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 alta disponibilidade e recuperação de desastres com tecnologia de instâncias de cluster de failover Always On e grupos de disponibilidade Always On. |
| Serviços SQL suportados | Apenas o Mecanismo de Banco de Dados do SQL Server é suportado. A descoberta do SQL Server Reporting Services, SQL Server Integration Services e SQL Server Analysis Services não é suportada. |
Nota
Por defeito, o Azure Migrate 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 a 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 a user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
USE [?];
IF (''?'' NOT IN (''tempdb'',''model''))
BEGIN
DECLARE @is_secondary_replica BIT = 0;
IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
BEGIN
DECLARE @innersql NVARCHAR(MAX);
SET @innersql = N''
SELECT @is_secondary_replica = IIF(
EXISTS (
SELECT 1
FROM sys.availability_replicas a
INNER JOIN sys.dm_hadr_database_replica_states b
ON a.replica_id = b.replica_id
WHERE b.is_local = 1
AND b.is_primary_replica = 0
AND a.secondary_role_allow_connections = 2
AND b.database_id = DB_ID()
), 1, 0
);
'';
EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
END
IF (@is_secondary_replica = 0)
BEGIN
CREATE USER [evaluator] FOR LOGIN [evaluator];
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
END
END'
GO
-- Provide server level read-only permissions
USE master;
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
GRANT VIEW SERVER STATE TO [evaluator];
GRANT VIEW ANY DEFINITION TO [evaluator];
GO
-- Provide msdb specific permissions
USE msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [evaluator];
GO
-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
--GO
Requisitos de descoberta de aplicativos Web
O inventário de software identifica a função de servidor Web que existe nos servidores descobertos. Se um servidor for descoberto com um servidor web instalado, o Azure Migrate e o Modernize descobrem aplicações web no servidor.
Você pode adicionar credenciais de domínio e de não domínio no dispositivo. Verifique se a conta usada tem privilégios de administrador local nos servidores de origem. Azure Migrate e Modernize mapeiam automaticamente as credenciais para os respetivos servidores, por isso não precisas de as mapear manualmente. 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.
| Suporte | 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 cumpram os requisitos. |
| Versões do servidor Web | IIS 7.5 e posteriores | Tomcat 8 ou posterior |
| Protocolo | Porta WinRM 5986 (HTTPS) por defeito, se os pré-requisitos HTTPS não estiverem configurados nos servidores alvo, a comunicação volta para a porta WinRM 5985 (HTTP) | Porta SSH 22 (TCP) |
| Privilégios necessários | O utilizador menos privilegiado deve fazer parte dos dois grupos de utilizadores: 1. Utilizadores de Gestão Remota 2. IIS_IUSRS. Os utilizadores devem ter permissões de leitura para as seguintes localizações: C:\Windows\system32\inetsrv\config, C:\Windows\system32\inetsrv\config\applicationHost.config e C:\Windows\system32\inetsrv\config\redirection.config. Adicione o utilizador a 'iniciar sessão como trabalho em lote' usando secpol.msc e certifique-se de que o utilizador não faz parte do 'negar iniciar sessão como trabalho em lote'. |
Permissões de leitura (r) e Executar (x) recursivamente em todos os diretórios CATALINA_HOME. |
Nota
Os dados são sempre encriptados em repouso e durante o trânsito.
Requisitos de análise de dependência (sem agente)
A análise de dependência ajuda a analisar as dependências entre os servidores descobertos. Pode visualizar facilmente dependências com uma vista de mapa num projeto Azure Migrate. Pode usar dependências para agrupar servidores relacionados para migração para o Azure. A tabela a seguir resume os requisitos para configurar a análise de dependência sem agente.
| Suporte | Detalhes |
|---|---|
| Servidores suportados | Pode ativar a análise de dependências sem agente em até 1.000 servidores (em vários hosts/clusters Hyper-V) identificados por dispositivo. |
| Sistemas operativos | Todas as versões Windows e Linux com serviços de integração Hyper-V ativados. |
| Requisitos de servidor | Os servidores Windows devem ter o remoting do PowerShell ativado e a versão 2.0 ou posterior do PowerShell instalada. Os servidores Linux devem ter conectividade SSH habilitada e garantir que os seguintes comandos possam ser executados nos servidores Linux: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date. |
| Acesso a servidores Windows | Uma conta de usuário (local ou domínio) com permissões de administrador em servidores |
| Acesso ao servidor Linux | 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 | Os servidores Windows precisam de acesso na porta 5986 (HTTPS) ou na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP). |
| Método de descoberta | A análise de dependência sem agente é realizada conectando-se diretamente aos servidores usando as credenciais do servidor adicionadas no dispositivo. O dispositivo recolhe a informação de dependência dos servidores Windows através do PowerShell remoting e dos servidores Linux através da ligação SSH. Nenhum agente é instalado nos servidores para extrair dados de dependência. |
Requisitos de análise de dependência baseada em agente
Análise de dependências ajuda-o a identificar dependências entre servidores on-premises que pretende avaliar e migrar para Azure. A tabela resume os requisitos para configurar a análise de dependência baseada em agente. O Hyper-V atualmente só suporta visualização de dependências baseada em agentes.
| 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 no local. Saiba como criar um projeto pela primeira vez. Aprenda como adicionar a ferramenta Azure Migrate: Descoberta e avaliação a um projeto existente. Aprenda como configurar o appliance para descoberta e avaliação de servidores em Hyper-V. |
| Azure Government | A visualização de dependências não está disponível no Azure Government. |
| 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 na mesma subscrição que o projeto. O espaço de trabalho deve residir 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 e ao Modernize está etiquetado com a chave Migration Project e o nome do project. |
| Agentes necessários | Em cada servidor que você deseja analisar, instale os seguintes agentes: Agente de Monitorização da Microsoft (MMA) Agente de dependência Se os servidores on-premises não estiverem ligados à internet, precisa de descarregar e instalar o gateway Log Analytics neles. Saiba mais sobre como instalar o agente de dependência e o MMA. |
| área de trabalho do Log Analytics | O espaço de trabalho deve estar na mesma subscrição que o projeto. O Azure Migrate and Modernize suporta espaços de trabalho situados 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. |
| Custos | 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 junto com ele. 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 o pagamento apenas após 180 dias, recomendamos que 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, você usa 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, tens de instalar o gateway Log Analytics neles. |
| Azure Government | Não há suporte para análise de dependência baseada em agente. |
Próximos passos
Prepare-se para a descoberta de servidores que estão a executar no Hyper-V.