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 ao descobrir e avaliar servidores locais em execução em um ambiente Hyper-V para migração para Azure usando a ferramenta Migrações para Azure: Descoberta e avaliação. Se você quiser migrar servidores em execução no Hyper-V para Azure, consulte a matriz de suporte migration.
Para configurar a descoberta e a avaliação de servidores em execução no Hyper-V, crie um projeto e adicione o Migrações para Azure: ferramenta de descoberta e avaliação ao projeto. Depois que a ferramenta for adicionada, você implantará o dispositivo Migrações para Azure. O dispositivo descobre continuamente servidores locais e envia metadados do servidor e dados de desempenho para 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 | É possível descobrir e avaliar até 35 mil servidores físicos em um único projeto. |
| Limites do projeto | Você pode criar vários projetos em uma assinatura Azure. Além dos servidores em Hyper-V, um projeto pode incluir servidores VMware e servidores físicos, até os limites de avaliação para cada um. |
| Descoberta | O dispositivo Migrações para Azure pode descobrir até 5.000 servidores em execução no Hyper-V. O dispositivo pode se conectar a até 300 hosts Hyper-V. |
| Avaliação | É possível adicionar até 35 mil computadores em um único grupo. É possível avaliar até 35 mil servidores para um único grupo. |
Saiba mais sobre as avaliações.
Requisitos do host do Hyper-V
| Suporte | Detalhes |
|---|---|
| host Hyper-V | O host Hyper-V pode ser autônomo ou implantado em um 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 contam com suporte. Você não pode avaliar servidores localizados em hosts Hyper-V executando Windows Server 2012. |
| Permissões | Você precisa de permissões de Administrador no host Hyper-V. Se você não quiser atribuir permissões de Administrador, crie uma conta de usuário local ou de domínio e adicione a conta de usuário a esses grupos: Usuários de Gerenciamento Remoto, Administradores Hyper-V e Usuários Monitor de Desempenho. |
| Comunicação remota do PowerShell | PowerShell remoting precisa estar ativado em cada host Hyper-V. |
| Réplica de Hyper-V | Se você usar Hyper-V Replica (ou tiver vários servidores com os mesmos identificadores de servidor) e descobrir os servidores originais e replicados usando Migrações para Azure e Modernizar, a avaliação gerada por Migrações para Azure e Modernizar poderá não ser precisa. |
Requisitos do servidor
| Suporte | Detalhes |
|---|---|
| Sistema operacional | Todos os sistemas operacionais podem ter a migração avaliada. |
| Serviços de integração | Hyper-V Integration Services deve estar em execução em servidores que você avalia para capturar informações do sistema operacional. |
| Armazenamento | Disco local, DAS, JBOD, espaços de armazenamento, CSV e SMB. Esses armazenamentos de host do Hyper-V onde o VHD/VHDX está armazenado têm suporte. Controladores virtuais IDE e SCSI são suportados. |
Requisitos de dispositivo para as Migrações para Azure
Migrações para Azure e Modernize usa a ferramenta Migrações para Azure appliance para descoberta e avaliação. Você pode implantar o dispositivo usando um VHD Hyper-V compactado que você baixa do portal ou usando um script PowerShell. Para mais informações:
- Saiba mais sobre os requisitos appliance para Hyper-V.
- Saiba mais sobre as URLs do Azure que o dispositivo precisa acessar nas nuvens públicas e governamentais.
- Use o script para implantar o dispositivo no Azure Governamental.
Acesso à porta
A tabela a seguir resume os requisitos de porta para a avaliação.
| Dispositivo | Conexão |
|---|---|
| Dispositivo | 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 do dispositivo usando a URL: https://<appliance-ip-or-name>:44368Conexões de saída nas portas 443 (HTTPS) para enviar metadados de descoberta e desempenho para As Migrações para Azure e Modernização. |
| Hyper-V host/cluster | A conexão de entrada usa a porta WinRM 5986 (HTTPS) por padrão. Se os pré-requisitos HTTPS não estiverem configurados nos servidores de destino, a comunicação retornará à porta WinRM 5985 (HTTP) para coletar metadados e dados de desempenho para servidores Hyper-V usando uma sessão de CIM (Common Information Model). |
| Servidores | Windows servidores 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
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 ajuda você a identificar e planejar um caminho de migração adaptado às cargas de trabalho locais.
| Suporte | Detalhes |
|---|---|
| Servidores com suporte | Você pode realizar inventário de software em até 5.000 servidores em execução em hosts/clusters Hyper-V adicionados a cada dispositivo de Migrações para Azure. |
| Sistemas operacionais | Todas as versões Windows e Linux com Hyper-V integration services habilitados. |
| Requisitos do servidor | Windows servidores devem ter a comunicação remota do PowerShell habilitada e o PowerShell versão 2.0 ou posterior instalado. O WMI deve estar habilitado e disponível em servidores Windows para coletar os detalhes das funções e recursos 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, localizar, head, sed, ps, print, sort, único. Com base no tipo de sistema operacional e no tipo de gerenciador de pacotes usado, aqui estão mais alguns comandos: rpm/snap/dpkg, yum/apt-cache, mssql-server. |
| 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 | Windows servidores precisam de acesso na porta 5986 (HTTPS) ou na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP). 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 software é realizado conectando-se diretamente aos servidores usando as credenciais do servidor adicionadas ao dispositivo. O dispositivo coleta as informações sobre o inventário de software de servidores Windows usando a comunicação remota do PowerShell e de servidores Linux usando a conexão SSH. O inventário de software não tem agente. Nenhum agente é instalado nos servidores. |
Requisitos para descoberta de instância e banco de dados do SQL Server
Software inventory identifica instâncias de SQL Server. O dispositivo usa essas informações e tenta se conectar às respectivas instâncias de SQL Server por meio das credenciais de autenticação autenticação do Windows ou SQL Server fornecidas no gerenciador de configurações do dispositivo. 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 que o dispositivo estiver conectado, ele coletará dados de configuração e desempenho para SQL Server instâncias e bancos de dados. SQL Server dados de configuração são atualizados uma vez a cada 24 horas. Os dados de desempenho são capturados a cada 30 segundos.
| Suporte | Detalhes |
|---|---|
| Servidores com suporte | Com suporte apenas para servidores que executam o SQL Server em ambientes VMware, Microsoft Hyper-V e físicos/bare-metal e servidores de infraestrutura como serviço (IaaS) de outras nuvens públicas, como Azure Web Services e Google Cloud Platform. 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 o escopo para descobrir menos que 600 servidores executando o SQL para evitar problemas de colocação em 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. A descoberta de implantações SQL de alta disponibilidade e recuperação de desastres alimentadas por instâncias de cluster de failover Always On e grupos de disponibilidade Always On também é suportada. |
| 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 o 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 exemplos de script a seguir para criar um logon 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
Inventário de software identifica a função de servidor web que existe 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. 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.
| Suporte | 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. | Sem suporte. |
| Servidores Linux | Sem suporte | Servidores que atendem aos requisitos. |
| Versões do servidor Web | IIS 7.5 e posterior | Tomcat 8 ou posterior |
| Protocolo | Por padrão, a porta WinRM 5986 (HTTPS) se os pré-requisitos HTTPS não estiverem configurados nos servidores de destino, a comunicação retornará à porta WinRM 5985 (HTTP) | Porta SSH 22 (TCP) |
| Privilégios necessários | O usuário menos privilegiado 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 locais: 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" usando secpol.msc e garanta que o usuário não esteja no grupo "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)
A 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.
| Suporte | Detalhes |
|---|---|
| Servidores com suporte | Você pode habilitar a análise de dependência sem agente em até 1.000 servidores (em vários hosts/clusters Hyper-V) descobertos por dispositivo. |
| Sistemas operacionais | Todas as versões Windows e Linux com Hyper-V integration services habilitados. |
| Requisitos do servidor | Windows servidores devem ter a comunicação remota do PowerShell habilitada e o PowerShell versão 2.0 ou posterior instalado. Os servidores Linux devem ter a 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 ao Windows Server | Uma conta de usuário (local ou de domínio) com permissões de administrador em servidores |
| Acesso ao servidor do 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, habilitar NOPASSWD para que a conta execute os comandos necessários sem solicitar uma senha sempre que um comando sudo for invocado. |
| Acesso à porta | Windows servidores 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 ao dispositivo. A ferramenta coleta as informações de dependência de servidores Windows usando a execução remota do PowerShell e de servidores Linux usando a conexão SSH. Nenhum agente está instalado nos servidores para realizar pull de dados de dependência. |
Requisitos da análise de dependência baseada em agente
Dependency analysis ajuda a identificar dependências entre servidores locais que você deseja avaliar e migrar para Azure. A tabela resume os requisitos para configurar a análise de dependência baseada em agente. Hyper-V atualmente só dá suporte à visualização 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. Aprenda a criar um projeto pela primeira vez. Learn how para adicionar a ferramenta Migrações para Azure: Descoberta e avaliação a um projeto existente. Saiba como configurar o equipamento para a descoberta e avaliação de servidores no Hyper-V. |
| Azure Governamental | A visualização de dependência não está disponível no Azure Governamental. |
| 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 após adicioná-lo. O espaço de trabalho deve estar na mesma assinatura que o projeto. O espaço de trabalho deve residir 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 espaço de trabalho deve estar em uma região em que o Mapa do Serviço é 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 espaço de trabalho associado ao Migrações para Azure and Modernize é marcado com a chave do Projeto de Migração e o nome do projeto. |
| Agentes necessários | Instale os seguintes agentes em cada servidor que quiser analisar: Agente de Monitoramento da Microsoft (MMA) Agente de dependência Se os servidores locais não estiverem conectados à Internet, você precisará baixar e instalar o gateway Log Analytics neles. Saiba mais sobre a instalação do agente de dependência e MMA. |
| espaço de trabalho do Log Analytics | O espaço de trabalho deve estar na mesma assinatura que o projeto. Migrações para Azure e Modernize dá suporte a workspaces que residem nas regiões Leste dos EUA, Sudeste Asiático e Europa Ocidental. O espaço de trabalho deve estar em uma região em que o Mapa do Serviço é 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. Você não pode modificar o espaço de trabalho de um projeto após adicioná-lo. |
| Custos | 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. 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 é excluído, o workspace não é excluído com ele. Depois que você excluir o projeto, o uso do Mapa do Serviço não será mais gratuito. Cada nó é cobrado de acordo com o nível pago do workspace do 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 o pagamento somente após 180 dias, recomendamos que você crie um novo projeto. Os workspaces que foram criados antes da disponibilidade geral ainda serão cobrados. |
| Gerenciamento | Ao registrar agentes no espaço de trabalho, use a ID e a chave fornecidas pelo projeto. Você pode usar o espaço de trabalho do Log Analytics fora do 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, você precisará instalar o gateway de Log Analytics neles. |
| Azure Governamental | A análise de dependência baseada em agente não é compatível. |
Próximas etapas
Prepare-se para descoberta de servidores em execução no Hyper-V.