Matriz de suporte para a deteção e avaliação de servidores físicos
Atenção
Este artigo faz referência ao CentOS, uma distribuição Linux que está perto do fim da vida útil. Por favor, considere o seu uso e planeje de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.
Este artigo resume os pré-requisitos e os requisitos de suporte quando você avalia servidores físicos para migração para o Azure usando a ferramenta Azure Migrate: Discovery and assessment . Se você quiser migrar servidores físicos para o Azure, consulte a matriz de suporte à migração.
Para avaliar servidores físicos, crie um projeto e adicione a ferramenta Azure Migrate: Discovery and assessment ao projeto. Depois de adicionar a ferramenta, você implanta o dispositivo Azure Migrate. O dispositivo descobre continuamente servidores locais e envia metadados de servidores e dados de desempenho 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 físicos em um único projeto. |
| Limites de projeto | Pode criar vários projetos numa subscrição do Azure. Para além dos servidores físicos, um projeto pode incluir servidores em VMware e no Hyper-V, até aos limites de avaliação de cada um. |
| Deteção | O dispositivo Azure Migrate pode descobrir até 1.000 servidores físicos. |
| Avaliação | Pode adicionar até 35 000 servidores num único grupo. Pode avaliar até 35 000 servidores numa única avaliação. |
Saiba mais sobre avaliações.
Requisitos do servidor físico
Implantação de servidor físico: o servidor físico pode ser autônomo ou implantado em um cluster.
Tipo de servidores: servidores bare-metal, servidores virtualizados executados no local ou outras nuvens como Amazon Web Services (AWS), Google Cloud Platform (GCP) e Xen.
Nota
Atualmente, o Azure Migrate não suporta a descoberta de servidores paravirtualizados.
Sistema operacional: Todos os sistemas operacionais Windows e Linux podem ser avaliados para migração.
Permissões para servidores Windows
- Para servidores Windows, use uma conta de domínio para servidores ingressados no domínio e uma conta local para servidores que não ingressaram no domínio.
- Para descoberta física, especifique o nome de usuário no formato de nível inferior (domínio\nome de usuário) e o formato UPN (username@domain.com) não é suportado.
Você pode criar a conta de usuário de uma das duas maneiras a seguir.
Opção 1
Crie uma conta que tenha privilégios de administrador nos servidores. Use esta conta para:
- Extraia dados de configuração e desempenho por meio de uma conexão CIM (Common Information Model).
- Execute inventário de software (descoberta de aplicativos instalados).
- Habilite a análise de dependência sem agente usando a comunicação remota do PowerShell.
Nota
Se você quiser executar o inventário de software (descoberta de aplicativos instalados) e habilitar a análise de dependência sem agente em servidores Windows, recomendamos que você use a Opção 1.
Opção 2
- Adicione a conta de usuário a estes grupos: Usuários de Gerenciamento Remoto, Usuários do Monitor de Desempenho e Usuários do Log de Desempenho.
- Se o grupo Usuários de Gerenciamento Remoto não estiver presente, adicione a seguinte conta de usuário ao grupo WinRMRemoteWMIUsers_.
- A conta precisa dessas permissões para que o dispositivo crie uma conexão CIM com o servidor e extraia os metadados de configuração e desempenho necessários das classes WMI (Instrumentação de Gerenciamento do Windows) listadas aqui.
- Em alguns casos, adicionar a conta a esses grupos pode não retornar os dados necessários das classes WMI. A conta pode ser filtrada pelo Controle de Conta de Usuário (UAC). Para superar a filtragem do UAC, a conta de usuário precisa ter as permissões necessárias no Namespace CIMV2 e subnamespaces no servidor de destino. Para habilitar as permissões necessárias, consulte Solucionar problemas do dispositivo Azure Migrate.
Nota
Para Windows Server 2008 e 2008 R2, verifique se o Windows Management Framework 3.0 está instalado nos servidores.
Para descobrir bancos de dados do SQL Server em servidores Windows, há suporte para a autenticação do Windows e do SQL Server. Você pode fornecer credenciais de ambos os tipos de autenticação no gerenciador de configuração do dispositivo. O Azure Migrate requer uma conta de usuário do Windows que seja membro da função de servidor sysadmin.
Permissões para servidor Linux
Para servidores Linux, com base nos recursos que você deseja executar, você pode criar uma conta de usuário de uma das duas maneiras a seguir.
Opção 1
Você precisa de uma conta de usuário sudo nos servidores que você deseja descobrir. Use esta conta para:
- Pull metadados de configuração e desempenho.
- Execute inventário de software (descoberta de aplicativos instalados).
- Habilite a análise de dependência sem agente usando a conectividade Secure Shell (SSH).
Você precisa habilitar o acesso sudo em /usr/bin/bash para executar os comandos listados nos metadados do servidor Linux. Além desses comandos, a conta de usuário também precisa ter permissões para executar comandos ls e netstat para executar a análise de dependência sem agente.
Certifique-se de habilitar o NOPASSWD para que a conta execute os comandos necessários sem solicitar uma senha toda vez que o comando sudo for invocado.
O Azure Migrate and Modernize dá suporte às seguintes distribuições do sistema operacional Linux para descoberta usando uma conta com acesso sudo:
Sistema operativo Versões Red Hat Enterprise Linux 5.1, 5.3, 5.11, 6.x, 7.x, 8.x, 9.x Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04 Oracle Linux 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 Amazon Linux 2.0.2021 Contêiner CoreOS 2345.3.0
Nota
Se você quiser executar o inventário de software (descoberta de aplicativos instalados) e habilitar a análise de dependência sem agente em servidores Linux, recomendamos que você use a Opção 1.
Opção 2
Se não for possível fornecer a conta raiz ou a conta de usuário com acesso sudo, você poderá definir a chave do
isSudoRegistro como o valor0no registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance no servidor do dispositivo. Forneça a uma conta não root os recursos necessários usando os seguintes comandos:Comando Objetivo setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/fdisk
setcap CAP_DAC_READ_SEARCH+eip /sbin/fdisk (se /usr/sbin/fdisk não estiver presente)Coleta dados de configuração de disco. setcap "cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_setuid,
cap_setpcap,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin,
cap_sys_resource,cap_audit_control,cap_setfcap=+eip" /sbin/lvmColeta dados de desempenho do disco. setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/dmidecode Coleta o número de série do BIOS. chmod a+r /sys/class/dmi/id/product_uuid Coleta o GUID do BIOS. Para executar a análise de dependência sem agente no servidor, certifique-se de também definir as permissões necessárias nos arquivos /bin/netstat e /bin/ls usando os seguintes comandos:
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls
sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
Requisitos de aplicação do Azure Migrate
O Azure Migrate usa o dispositivo Azure Migrate para descoberta e avaliação. O dispositivo para servidores físicos pode ser executado em uma máquina virtual (VM) ou em um servidor físico.
- Saiba mais sobre os requisitos de dispositivo para servidores físicos.
- Saiba mais sobre os URLs que o dispositivo precisa acessar em nuvens públicas e governamentais .
- Use um script do PowerShell que você baixa do portal do Azure para configurar o dispositivo.
- Use este script para implantar o dispositivo no Azure Government.
Acesso à porta
A tabela a seguir resume os requisitos de porta para avaliação.
| Dispositivo | Ligação |
|---|---|
| Aplicação | 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>:44368.Conexões de saída nas portas 443 (HTTPS) para enviar metadados de descoberta e desempenho para o Azure Migrate and Modernize. |
| Servidores físicos | Windows: Conexão de entrada na porta WinRM 5985 (HTTP) para extrair metadados de configuração e desempenho de servidores Windows. Linux: Conexões de entrada na porta 22 (TCP) para extrair metadados de configuração e desempenho de servidores Linux. |
Requisitos de inventário de software
Além de descobrir servidores, o Azure Migrate: Discovery and assessment pode executar o inventário de software em servidores. O inventário de software fornece a lista de aplicativos, funções e recursos em execução em servidores Windows e Linux que são descobertos usando o Azure Migrate and Modernize. Ele ajuda você a identificar e planejar um caminho de migração adaptado para suas cargas de trabalho locais.
| Suporte | Detalhes |
|---|---|
| Servidores suportados | Você pode executar o inventário de software em até 1.000 servidores descobertos de cada dispositivo Azure Migrate. |
| Sistemas operativos | Há suporte para servidores que executam todas as versões do Windows e Linux que atendem aos requisitos do servidor e têm as permissões de acesso necessárias. |
| Requisitos de servidor | Os servidores Windows 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 nos servidores Windows para reunir os detalhes das funções e recursos instalados nos servidores. Os servidores Linux devem ter conectividade 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 usado, aqui estão mais alguns comandos: rpm/snap/dpkg, yum/apt-cache, mssql-server. |
| Acesso ao servidor Windows | Uma conta de usuário convidado para servidores Windows. |
| Acesso ao servidor Linux | Uma conta de usuário padrão (acesso não-sudo) para todos os servidores Linux. |
| Acesso à porta | Os servidores Windows precisam de acesso na porta 5985 (HTTP). Os servidores Linux precisam de acesso na porta 22 (TCP). |
| Deteção | O inventário de software é realizado conectando-se diretamente aos servidores usando as credenciais do servidor adicionadas no dispositivo. O appliance reúne 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 é sem agente. Nenhum agente está instalado nos servidores. |
Requisitos de descoberta de instância e banco de dados do SQL Server
O inventário de software identifica instâncias do SQL Server. O dispositivo tenta se conectar às respetivas instâncias do SQL Server por meio das credenciais de autenticação do Windows ou do SQL Server fornecidas no gerenciador de configuração do dispositivo usando essas informações. O dispositivo pode se conectar somente às instâncias do SQL Server às quais ele tem linha de visão de rede. O inventário de software por si só pode não precisar de linha de visão de rede.
Depois que o dispositivo é conectado, ele coleta dados de configuração e desempenho para instâncias e bancos de dados do SQL Server. O dispositivo atualiza os dados de configuração do SQL Server uma vez a cada 24 horas e captura os dados de desempenho a cada 30 segundos.
| Suporte | Detalhes |
|---|---|
| Servidores suportados | Suportado apenas para servidores que executam o SQL Server em seus VMware, Microsoft Hyper-V e ambientes físicos/bare-metal e servidores IaaS (infraestrutura como serviço) de outras nuvens públicas, como AWS e GCP. Você pode descobrir até 750 instâncias do SQL Server ou 15.000 bancos de dados SQL, o que for menor, a partir de um único dispositivo. Recomendamos que você verifique se um dispositivo tem escopo para descobrir menos de 600 servidores executando SQL para evitar problemas de dimensionamento. |
| Servidores Windows | Windows Server 2008 e posterior são suportados. |
| Servidores Linux | Não é atualmente suportado. |
| Mecanismo de autenticação | Há suporte para autenticação do Windows e do SQL Server. Você pode fornecer credenciais de ambos os tipos de autenticação no gerenciador de configuração do dispositivo. |
| Acesso do SQL Server | Para descobrir instâncias e bancos de dados do SQL Server, a conta do Windows ou do SQL Server deve ser membro da função de servidor sysadmin ou ter essas permissões para cada instância do SQL Server. |
| Versões do SQL Server | SQL Server 2008 e posterior 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 | Somente o Mecanismo de Banco de Dados do SQL Server é suportado. Não há suporte para a descoberta do SQL Server Reporting Services, SQL Server Integration Services e SQL Server Analysis Services. |
Nota
Por padrão, o Azure Migrate usa a maneira mais segura de se conectar a instâncias SQL. Ou seja, o Azure Migrate and Modernize criptografa a comunicação entre o dispositivo Azure Migrate e as instâncias do SQL Server de origem definindo a TrustServerCertificate propriedade como true. Além disso, a camada de transporte usa Secure Socket Layer para criptografar o canal e ignorar a cadeia de certificados para validar a confiança. Por esse motivo, o servidor do dispositivo deve ser configurado para confiar na autoridade raiz do certificado.
No entanto, você pode modificar as configurações de conexão selecionando Editar propriedades de conexão do SQL Server no dispositivo. Saiba mais para entender o que escolher.
Configurar o logon personalizado para descoberta do SQL Server
Use os 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 do SQL Server
--- Create a login to run the assessment
use master;
-- NOTE: SQL instances that host replicas of Always On availability groups must use the same SID for the SQL login.
-- After the account is created in one of the members, copy the SID output from the script and include this value
-- when executing against the remaining replicas.
-- When the SID needs to be specified, add the value to the @SID variable definition below.
DECLARE @SID NVARCHAR(MAX) = N'';
IF (@SID = N'')
BEGIN
CREATE LOGIN [evaluator]
WITH PASSWORD = '<provide a strong password>'
END
ELSE
BEGIN
DECLARE @SQLString NVARCHAR(500) = 'CREATE LOGIN [evaluator]
WITH PASSWORD = ''<provide a strong password>''
, SID = ' + @SID
EXEC SP_EXECUTESQL @SQLString
END
SELECT @SID = N'0x'+CONVERT(NVARCHAR(100), sid, 2) FROM sys.syslogins where name = 'evaluator'
IF (ISNULL(@SID,'') != '')
PRINT N'Created login [evaluator] with SID = '''+ @SID +'''. If this instance hosts any Always On Availability Group replica, use this SID value when executing the script against the instances hosting the other replicas'
ELSE
PRINT N'Login creation failed'
GO
-- Create user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
USE [?];
IF (''?'' NOT IN (''tempdb'',''model''))
BEGIN
DECLARE @is_secondary_replica BIT = 0;
IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
BEGIN
DECLARE @innersql NVARCHAR(MAX);
SET @innersql = N''
SELECT @is_secondary_replica = IIF(
EXISTS (
SELECT 1
FROM sys.availability_replicas a
INNER JOIN sys.dm_hadr_database_replica_states b
ON a.replica_id = b.replica_id
WHERE b.is_local = 1
AND b.is_primary_replica = 0
AND a.secondary_role_allow_connections = 2
AND b.database_id = DB_ID()
), 1, 0
);
'';
EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
END
IF (@is_secondary_replica = 0)
BEGIN
CREATE USER [evaluator] FOR LOGIN [evaluator];
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
END
END'
GO
-- Provide server level read-only permissions
USE master;
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
GRANT VIEW SERVER STATE TO [evaluator];
GRANT VIEW ANY DEFINITION TO [evaluator];
GO
-- Provide msdb specific permissions
USE msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [evaluator];
GO
-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
--GO
Requisitos de descoberta de aplicativos Web
O inventário de software identifica a função de servidor Web que existe nos servidores descobertos. Se um servidor tiver um servidor Web instalado, o Azure Migrate and Modernize descobrirá aplicativos Web no servidor.
Você pode adicionar credenciais de domínio e de não domínio no dispositivo. Verifique se a conta usada tem privilégios de administrador local nos servidores de origem. O Azure Migrate and Modernize mapeia automaticamente as credenciais para os respetivos servidores, para que não seja necessário mapeá-las manualmente. Mais importante ainda, essas credenciais nunca são enviadas para a Microsoft e permanecem no dispositivo em execução no ambiente de origem.
Depois que o dispositivo é conectado, ele coleta dados de configuração para aplicativos Web ASP.NET (servidor Web IIS) e aplicativos 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 do ASP.NET | Aplicações Web Java |
|---|---|---|
| Pilha | VMware, Hyper-V e servidores físicos. | VMware, Hyper-V e servidores físicos. |
| Servidores Windows | Windows Server 2008 R2 e posterior são suportados. | Não suportado. |
| Servidores Linux | Não suportado. | Ubuntu Linux 16.04/18.04/20.04, Debian 7/8 e Red Hat Enterprise Linux 5/6/7. |
| Versões do servidor Web | IIS 7.5 e posterior. | Tomcat 8 ou posterior. |
| Privilégios necessários | Administrador local. | Usuário root ou sudo. |
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. Você pode visualizar facilmente dependências com um modo de exibição de mapa em um projeto do Azure Migrate. Você pode usar dependências para agrupar servidores relacionados para migração para o Azure. A tabela a seguir resume os requisitos para configurar a análise de dependência sem agente.
| Suporte | Detalhes |
|---|---|
| Servidores suportados | Você pode habilitar a análise de dependência sem agente em até 1.000 servidores descobertos por dispositivo. |
| Sistemas operativos | Há suporte para servidores que executam todas as versões do Windows e Linux que atendem aos requisitos do servidor e têm as permissões de acesso necessárias. |
| Requisitos de servidor | Os servidores Windows devem ter a comunicação remota do PowerShell habilitada e o PowerShell versão 2.0 ou posterior instalado. 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 ao servidor 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 o comando sudo for invocado. Como alternativa, você pode criar uma conta de usuário que tenha as permissões CAP_DAC_READ_SEARCH e CAP_SYS_PTRACE nos arquivos /bin/netstat e /bin/ls definidos usando os seguintes comandos: sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/lssudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/netstat |
| Acesso à porta | Os servidores Windows precisam de acesso 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 reúne as informações de dependência dos servidores Windows usando a comunicação remota do PowerShell e dos servidores Linux usando a conexão SSH. Nenhum agente é instalado nos servidores para extrair dados de dependência. |
Requisitos de análise de dependência baseada em agente
A análise de dependência ajuda você a identificar dependências entre servidores locais que você deseja avaliar e migrar para o Azure. A tabela a seguir resume os requisitos para configurar a análise de dependência baseada em agente. Atualmente, apenas a análise de dependência baseada em agente é suportada para servidores físicos.
| Requisito | Detalhes |
|---|---|
| Antes da implantação | Você deve ter um projeto em vigor com a ferramenta Azure Migrate: Discovery and assessment adicionada ao projeto. Você implanta a visualização de dependência depois de configurar um dispositivo Azure Migrate para descobrir seus servidores locais. Saiba como criar um projeto pela primeira vez. Saiba como adicionar uma ferramenta de avaliação a um projeto existente. Saiba como configurar o dispositivo Azure Migrate para avaliação de servidores Hyper-V, VMware ou físicos. |
| Azure Government | A visualização de dependência não está disponível no Azure Government. |
| Log Analytics | O Azure Migrate and Modernize usa a solução de Mapa de Serviço nos logs do Azure Monitor para visualização de dependência. Você associa um espaço de trabalho novo ou existente do 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 assinatura 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. Você pode monitorar VMs do Azure em qualquer região. As VMs em si não estão limitadas às regiões suportadas pelo espaço de trabalho do Log Analytics. No Log Analytics, o espaço de trabalho associado ao Azure Migrate and Modernize é marcado com a chave do Projeto de Migração e o nome do projeto. |
| Agentes necessários | Em cada servidor que você deseja analisar, instale os seguintes agentes: - 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 do 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 assinatura que um projeto. O Azure Migrate and Modernize suporta espaços de trabalho residentes nas regiões 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. Você pode monitorar VMs do Azure em qualquer região. As VMs em si não estão limitadas à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 a partir do dia em que você associa o espaço de trabalho do Log Analytics ao projeto. Após 180 dias, aplicam-se os custos padrão do Log Analytics. O uso de qualquer solução diferente do Mapa de Serviços no espaço de trabalho associado do Log Analytics incorre em cobranças padrão para o 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 a camada paga do espaço de trabalho do Log Analytics. Se você tiver projetos criados antes da disponibilidade geral do Azure Migrate (GA em 28 de fevereiro de 2018), poderá incorrer em outras cobranças do Mapa de Serviço. 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. Você pode usar o espaço de trabalho do Log Analytics fora do Azure Migrar e Modernizar. Se você excluir o projeto associado, o espaço de trabalho não será excluído automaticamente. Exclua-o manualmente. Não exclua o espaço de trabalho criado pelo Azure Migrate and Modernize, a menos que exclua o projeto. Se você fizer isso, a funcionalidade de visualização de dependência não funcionará conforme o esperado. |
| Ligação à Internet | Se os servidores não estiverem conectados à Internet, instale o gateway do Log Analytics nos servidores. |
| Azure Government | Não há suporte para análise de dependência baseada em agente. |
Próximos passos
Prepare-se para a descoberta e avaliação físicas.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários