Matriz de compatibilidad con la detección y la evaluación físicas de servidores

Artículo
11/04/2024

En este artículo se resumen los requisitos previos y los requisitos de soporte técnico al evaluar servidores físicos para migrarlos a Azure mediante la herramienta Azure Migrate: detección y evaluación. Si quiere migrar servidores físicos a Azure, consulte la matriz de compatibilidad para la migración.

Para evaluar los servidores físicos, cree un proyecto y agregue la herramienta Azure Migrate: detección y evaluación al proyecto. Después de agregar la herramienta, implemente el dispositivo de Azure Migrate. El dispositivo detecta continuamente los servidores locales y envía sus metadatos y datos de rendimiento a Azure. Una vez finalizada la detección, recopile los servidores detectados en grupos y ejecute una evaluación de un grupo.

Limitaciones

Soporte técnico	Detalles
Límites de evaluación	Puede detectar y evaluar hasta 35 000 servidores físicos en un solo proyecto.
Límites del proyecto	Puede crear varios proyectos en una suscripción a Azure. Además de los servidores físicos, un proyecto puede incluir servidores de VMware y de Hyper-V, hasta sus límites de evaluación.
Detección	El dispositivo de Azure Migrate puede detectar hasta 1000 servidores físicos.
Valoración	Puede agregar hasta 35 000 servidores en un solo grupo. Puede evaluar hasta 35 000 máquinas virtuales en una única evaluación.

Más información sobre las evaluaciones.

Requisitos del servidor físico

Implementación de servidor físico: el servidor físico puede ser independiente o implementarse en un clúster.
Tipo de servidores: servidores sin sistema operativo, servidores virtualizados que se ejecutan de forma local u otras nubes como Amazon Web Services (AWS), Google Cloud Platform (GCP) y Xen.

Nota:

Actualmente, Azure Migrate no admite la detección de servidores paravirtualizados.
sistema operativo: se pueden evaluar todos los sistemas operativos Windows y Linux para la migración.

Permisos para servidores Windows

En el caso de servidores Windows, use una cuenta de dominio para los servidores que estén unidos a un dominio y una cuenta local para los que no.
Para la detección física, especifique el nombre de usuario en formato de nivel descendente (dominio\nombre de usuario) y formato UPN (username@domain.com) no se admite.

Puede crear la cuenta de usuario de una de las dos maneras siguientes.

Opción 1

Creación de una cuenta que disponga de privilegios de administrador en los servidores. Use esta cuenta para:

Extraiga datos de configuración y rendimiento a través de una conexión de modelo de información común (CIM).
Realice el inventario de software (detección de aplicaciones instaladas).
Habilite el análisis de dependencias sin agente mediante la comunicación remota de PowerShell.

Nota:

Si desea realizar el inventario de software (detección de aplicaciones instaladas) y habilitar el análisis de dependencias sin agente en servidores Windows, se recomienda usar la opción 1.

Opción 2

Agregue la cuenta de usuario a estos grupos: usuarios de administración remota, usuarios de Monitor de rendimiento y usuarios del registro de rendimiento.
Si el grupo Usuarios de administración remota no está presente, agregue la siguiente cuenta de usuario al grupo WinRMRemoteWMIUsers_.
La cuenta necesita estos permisos para que el dispositivo cree una conexión CIM con el servidor y extraiga los metadatos de configuración y rendimiento necesarios de las clases de Instrumental de administración de Windows (WMI) que se enumeran aquí.
En algunos casos, es posible que al agregar la cuenta a estos grupos no se devuelvan los datos necesarios de las clases WMI. La cuenta puede filtrarse por Control de cuentas de usuario (UAC). Para superar el filtrado de UAC, la cuenta de usuario debe tener los permisos necesarios en el espacio de nombres CIMV2 y en los subespacios de nombres en el servidor de destino. Para habilitar los permisos necesarios, consulte Solución de problemas del dispositivo de Azure Migrate.

Nota:

En el caso de Windows Server 2008 y 2008 R2, asegúrese de que el Marco de administración de Windows 3.0 esté instalado en los servidores.

Para detectar bases de datos de SQL Server en servidores de Windows, se admite la autenticación de Windows y SQL Server. Puede proporcionar las credenciales de ambos tipos de autenticación en el administrador de configuración del dispositivo. Azure Migrate requiere una cuenta de usuario de Windows que sea un miembro del rol del servidor sysadmin.

Permisos para el servidor Linux

En el caso de los servidores de Linux, en función de las características que quiera ejecutar, puede crear una cuenta de usuario de las dos siguientes maneras.

Opción 1

Necesita una cuenta de usuario sudo en los servidores que quiere detectar. Use esta cuenta para:
- Extraer metadatos de configuración y rendimiento.
- Realizar el inventario de software (detección de aplicaciones instaladas).
- Habilitar el análisis de dependencias sin agente mediante la conectividad de Secure Shell (SSH).
Debe habilitar el acceso a sudo en /usr/bin/bash para ejecutar los comandos enumerados en metadatos del servidor Linux. Además de estos comandos, la cuenta de usuario también debe tener permisos para ejecutar comandos ls y netstat para realizar análisis de dependencias sin agente.
Asegúrese de habilitar NOPASSWD para que la cuenta ejecute los comandos necesarios sin solicitar una contraseña cada vez que se invoque el comando sudo.

Azure Migrate and Modernize admiten las siguientes distribuciones del sistema operativo Linux para la detección mediante una cuenta con acceso sudo:

Sistema operativo	Versiones
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, 22.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
CoreOS Container	2345.3.0

Nota:

Si quiere realizar el inventario de software (detección de aplicaciones instaladas) y habilitar el análisis de dependencias sin agente en servidores Linux, se recomienda usar la opción 1.

Opción 2

Si no puede proporcionar la cuenta raíz o la cuenta de usuario con acceso sudo, puede establecer la clave del registro isSudo en el valor 0 en el registro de HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureAppliance en el servidor del dispositivo. Proporcione una cuenta que no sea de raíz con las funcionalidades necesarias mediante los siguientes comandos:

Get-Help	Propósito
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/fdisk setcap CAP_DAC_READ_SEARCH+eip /sbin/fdisk (si /usr/sbin/fdisk no está presente)	Recopila datos de configuración 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/lvm	Recopila datos de rendimiento de disco.
setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/dmidecode	Recopila el número de serie del BIOS.
chmod a+r /sys/class/dmi/id/product_uuid	Recopila el GUID del BIOS.

Para realizar análisis de dependencias sin agente en el servidor, asegúrese de establecer también los permisos necesarios en los archivos /bin/netstat y /bin/ls mediante los siguientes 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 del dispositivo de Azure Migrate

Azure Migrate usa el dispositivo de Azure Migrate para la detección y la evaluación. El dispositivo para servidores físicos se puede ejecutar en una máquina virtual (VM) o en un servidor físico.

Obtenga información sobre los requisitos del dispositivo para los servidores físicos.
Obtenga información sobre las direcciones URL a las que el dispositivo necesita acceder en nubes públicas y gubernamentales.
Use un script de PowerShell que descargue de Azure Portal para configurar el dispositivo.
Use este script para implementar el dispositivo en Azure Government.

Acceso a puertos

En la tabla siguiente se resumen los requisitos de los puertos para la evaluación.

Dispositivo Conexión

Dispositivo Conexiones entrantes en el puerto TCP 3389 para permitir las conexiones del Escritorio remoto al dispositivo.

Conexiones entrantes en el puerto 44368 para tener acceso de forma remota a la aplicación de administración del dispositivo mediante la dirección URL https://<appliance-ip-or-name>:44368.

Conexiones salientes en los puertos 443 (HTTPS) para enviar metadatos de detección y rendimiento a Azure Migrate and Modernize.

Servidores físicos Windows: conexiones entrantes en el puerto 5985 (HTTP) de WinRM para extraer los metadatos de configuración y rendimiento de los servidores Windows.

Linux: conexiones entrantes en el puerto 22 (TCP) para extraer metadatos de rendimiento y configuración de servidores Linux.

Dispositivo	Conexión
Dispositivo	Conexiones entrantes en el puerto TCP 3389 para permitir las conexiones del Escritorio remoto al dispositivo. Conexiones entrantes en el puerto 44368 para tener acceso de forma remota a la aplicación de administración del dispositivo mediante la dirección URL `https://<appliance-ip-or-name>:44368`. Conexiones salientes en los puertos 443 (HTTPS) para enviar metadatos de detección y rendimiento a Azure Migrate and Modernize.
Servidores físicos	Windows: conexiones entrantes en el puerto 5985 (HTTP) de WinRM para extraer los metadatos de configuración y rendimiento de los servidores Windows. Linux: conexiones entrantes en el puerto 22 (TCP) para extraer metadatos de rendimiento y configuración de servidores Linux.

Requisitos de inventario de software

Además de detectar servidores, "Azure Migrate: detección y evaluación" puede realizar el inventario de software en servidores. El inventario de software proporciona la lista de aplicaciones, roles y características que se ejecutan en servidores de Windows y de Linux, detectados mediante Azure Migrate and Modernize. Le permite identificar y planear una ruta de migración adaptada a sus cargas de trabajo locales.

Soporte técnico	Detalles
Servidores admitidos	Puede ejecutar el inventario de software en un máximo de 1000 servidores, detectados en cada dispositivo de Azure Migrate.
Sistemas operativos	Se admiten los servidores que ejecuten cualquier versión de Windows o de Linux, siempre que cumpla los requisitos del servidor y tenga los permisos de acceso necesarios.
Requisitos del servidor	Los servidores de Windows deben tener habilitado el remoto de PowerShell y la versión 2.0 de PowerShell, u otra posterior, instalada. WMI debe estar habilitado y disponible en los servidores de Windows para recopilar los detalles de los roles y características instalados en los servidores. Los servidores de Linux deben tener habilitada la conectividad SSH y garantizar que se puedan ejecutar los siguientes comandos, en los servidores de Linux, para extraer los datos de la aplicación: list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Según el tipo de SO y de administrador de paquetes que se use, estos comandos adicionales pueden servirle de ayuda: rpm/snap/dpkg, yum/apt-cache, mssql-server.
Acceso a un servidor de Windows	Una cuenta de usuario invitado para los servidores de Windows.
Acceso a un servidor de Linux	Una cuenta de usuario estándar (acceso no sudo) para todos los servidores Linux.
Acceso a puertos	Los servidores de Windows necesitan acceso en el puerto 5985 (HTTP). Los servidores Linux necesitan acceso en el puerto 22 (TCP).
Detección	El inventario de software se realiza con la conexión directa a los servidores, mediante las credenciales de servidor agregadas en el dispositivo. El dispositivo recopila la información sobre el inventario de software de los servidores de Windows mediante el remoto de PowerShell. Para los servidores de Linux, utiliza la conexión SSH. El inventario de software no tiene agente. No se instala ningún agente en los servidores.

Requisitos para la detección de bases de datos e instancias de SQL Server

El inventario de software identifica las instancias de SQL Server. El dispositivo intenta conectarse a las instancias de SQL Server correspondientes mediante la autenticación de Windows o las credenciales de autenticación de SQL Server proporcionadas en el administrador de configuración del dispositivo con esta información. El dispositivo solo puede conectarse a las instancias de SQL Server a las que tiene línea de visión de red. Es posible que el inventario de software por sí mismo no necesite línea de visión de red.

Una vez conectado el dispositivo, este recopila datos de configuración y rendimiento de las instancias y de las bases de datos de SQL Server. El dispositivo actualiza los datos de configuración de SQL Server una vez cada 24 horas y captura los datos de rendimiento cada 30 segundos.

Soporte técnico	Detalles
Servidores admitidos	Solo se admite para servidores que ejecutan SQL Server en VMware, Microsoft Hyper-V y entornos físicos o sin sistema operativo y servidores de infraestructura como servicio (IaaS) de otras nubes públicas, como AWS y GCP. Puede detectar hasta 750 instancias de SQL Server o 15 000 bases de datos SQL, lo que sea menor, desde un único dispositivo. Se recomienda asegurarse de que un dispositivo tenga como ámbito descubrir menos de 600 servidores que ejecutan SQL para evitar problemas de escalado.
Servidores Windows	Se admiten Windows Server 2008 y versiones posteriores.
Servidores Linux	No se admite actualmente.
Mecanismo de autenticación	Se admiten tanto la autenticación de Windows como la de SQL Server. Puede proporcionar las credenciales de ambos tipos de autenticación en el administrador de configuración del dispositivo.
Acceso de SQL Server	Para detectar bases de datos e instancias de SQL Server, la cuenta de Windows o SQL Server deberá ser miembro del rol de servidor sysadmin o tener estos permisos para cada instancia de SQL Server.
Versiones de SQL Server	Se admiten SQL Server 2008 y versiones posteriores.
Ediciones deSQL Server	Se admiten las ediciones Enterprise, Standard, Developer y Express.
Configuración de SQL compatible	Se admite la detección de implementaciones de SQL independientes, de alta disponibilidad y protegidas por desastres. También se admite la detección de implementaciones de SQL y recuperación ante desastres de alta disponibilidad con tecnología de instancias de clúster de conmutación por error Always On y grupos de disponibilidad Always On.
Servicios SQL compatibles	Solo se admite el motor de base de datos de SQL Server. No se admite la detección de SQL Server Reporting Services, SQL Server Integration Services y SQL Server Analysis Services.

Nota:

De forma predeterminada, Azure Migrate usa la forma más segura de conectarse a instancias de SQL. Es decir, Azure Migrate and Modernize cifra la comunicación entre el dispositivo de Azure Migrate y las instancias de SQL Server de origen al establecer la propiedad TrustServerCertificate en true. Además, la capa de transporte usa Secure Socket Layer para cifrar el canal y omitir la cadena de certificados para validar la confianza. Por este motivo, el servidor del dispositivo se debe configurar para confiar en la entidad de certificación raíz del certificado.

Sin embargo, puede modificar la configuración de conexión; para ello, seleccione Editar las propiedades de conexión de SQL Server en el dispositivo. Descubra más para saber lo que elegir.

Use los siguientes scripts de ejemplo para crear un inicio de sesión y aprovisionarlo con los permisos necesarios.

Autenticación de 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

Los inicios de sesión de autenticación

--- 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 detección de aplicaciones web

El inventario de software identifica el rol de servidor web que existe en los servidores detectados. Si se descubre que un servidor tiene un servidor web instalado, Azure Migrate and Modernize descubre las aplicaciones web que haya en él.

Puede agregar credenciales de dominio y que no sean de dominio al dispositivo. Asegúrese de que la cuenta usada tenga privilegios de administrador local en los servidores de origen. Azure Migrate and Modernize asigna automáticamente las credenciales a los servidores respectivos para que no tenga que hacerlo manualmente. Lo más importante es que estas credenciales nunca se envían a Microsoft y permanecen en el dispositivo que se ejecuta en el entorno de origen.

Una vez conectado el dispositivo, recopila datos de configuración para las aplicaciones web de ASP.NET (servidor web de IIS) y las aplicaciones web de Java (servidores Tomcat). Los datos de configuración de las aplicaciones web se actualizan una vez cada 24 horas.

Soporte técnico	Aplicaciones web ASP.NET	Aplicaciones web de Java
Pila	Servidores físicos, Hyper-V y VMware.	Servidores físicos, Hyper-V y VMware.
Servidores Windows	Se admiten Windows Server 2008 R2 y versiones posteriores.	No admitida.
Servidores Linux	No admitida.	Ubuntu Linux 16.04/18.04/20.04, Debian 7/8 y Red Hat Enterprise Linux 5/6/7.
Versiones del servidor web	IIS 7.5 y versiones posteriores.	Tomcat 8 o versiones posteriores.
Privilegios requeridos	Administrador local.	Usuario raíz o sudo.

Nota:

Los datos siempre se cifran en reposo y durante el tránsito.

Requisitos para el análisis de dependencias (sin agentes)

El análisis de dependencias le ayuda a analizar las dependencias entre los servidores detectados. Puede visualizar fácilmente las dependencias con una vista de mapa en un proyecto de Azure Migrate. Puede usar dependencias para agrupar servidores relacionados para la migración a Azure. En la tabla siguiente, se resumen los requisitos para configurar el análisis de dependencias sin agente.

Soporte técnico	Detalles
Servidores admitidos	Puede habilitar el análisis de dependencias sin agente en hasta 1000 servidores, detectados por dispositivo.
Sistemas operativos	Se admiten los servidores que ejecuten cualquier versión de Windows o de Linux, siempre que cumpla los requisitos del servidor y tenga los permisos de acceso necesarios.
Requisitos del servidor	Los servidores de Windows deben tener habilitado el remoto de PowerShell y la versión 2.0 de PowerShell, u otra posterior, instalada. Los servidores de Linux deben tener habilitada la conectividad SSH y garantizar que se puedan ejecutar los siguientes comandos, en los servidores de Linux: touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
Acceso a un servidor de Windows	Cuenta de usuario invitado
Acceso a un servidor de Linux	Cuenta de usuario sudo con permisos para ejecutar comandos ls y netstat. Si proporciona una cuenta de usuario sudo, asegúrese de habilitar NOPASSWD para que la cuenta ejecute los comandos necesarios sin preguntar por una contraseña cada vez que se invoca el comando sudo. Como alternativa, puede crear una cuenta de usuario que tenga los permisos CAP_DAC_READ_SEARCH y CAP_SYS_PTRACE en los archivos /bin/netstat y /bin/ls, establecidos mediante los comandos siguientes: `sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/ls` `sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep usr/bin/netstat`
Acceso a puertos	Los servidores de Windows necesitan acceso en el puerto 5985 (HTTP). Los servidores Linux necesitan acceso en el puerto 22 (TCP).
Método de detección	El análisis de dependencias sin agente se realiza con la conexión directa a los servidores mediante las credenciales de servidor agregadas en el dispositivo. El dispositivo recopila la información sobre la dependencia de los servidores de Windows mediante el remoto de PowerShell. Para los servidores de Linux mediante la conexión SSH. No hay ningún agente instalado en los servidores para extraer datos de dependencia.

Requisitos para el análisis de dependencia con agentes

El análisis de dependencias le ayuda a identificar las dependencias entre los servidores locales que quiere evaluar y migrar a Azure. En la tabla siguiente se resumen los requisitos para configurar el análisis de dependencias basadas en agentes. Actualmente, solo se admite el análisis de dependencias basadas en agentes para los servidores físicos.

Requisito	Detalles
Antes de la implementación	Debe tener un proyecto al que se le haya agregado la herramienta Azure Migrate: detección y evaluación. La visualización de dependencias se implementa después de configurar un dispositivo de Azure Migrate para detectar los servidores locales. Aprenda a crear un proyecto por primera vez. Aprenda a agregar una herramienta de evaluación a un proyecto existente. Aprenda a configurar un dispositivo de Azure Migrate para la evaluación de Hyper-V, VMware o de servidores físicos.
Azure Government	La visualización de dependencias no está disponible en Azure Government.
Log Analytics	Azure Migrate and Modernize utiliza la solución Service Map de los registros de Azure Monitor para la visualización de dependencias. Puede asociar a un proyecto un área de trabajo de Log Analytics nueva o existente. No se puede modificar el área de trabajo de un proyecto después de que agrega el área de trabajo. El área de trabajo debe estar en la misma suscripción que el proyecto. El área de trabajo debe residir en las regiones Este de EE. UU., Sudeste Asiático u Oeste de Europa. Las áreas de trabajo de otras regiones no se pueden asociar a un proyecto. El área de trabajo debe estar en una región en la que se admita Service Map. Puede supervisar máquinas virtuales de Azure en cualquier región. Las máquinas virtuales no se limitan a las regiones admitidas por el área de trabajo de Log Analytics. En Log Analytics, el área de trabajo asociada con Azure Migrate and Modernize se etiqueta con la clave del proyecto de migración y el nombre del proyecto.
Agentes necesarios	En cada servidor que quiera analizar, instale los siguientes agentes: - Microsoft Monitoring Agent (MMA) - Dependency Agent Si los servidores locales no están conectados a Internet, tiene que descargar e instalar la puerta de enlace de Log Analytics en ellas. Conozca más información sobre la instalación de Dependency Agent y MMA.
Área de trabajo de Log Analytics	El área de trabajo debe estar en la misma suscripción que un proyecto. Azure Migrate and Modernize admite áreas de trabajo que residen en las regiones Este de EE. UU., Sudeste Asiático y Oeste de Europa. El área de trabajo debe estar en una región en la que se admita Service Map. Puede supervisar máquinas virtuales de Azure en cualquier región. Las máquinas virtuales no se limitan a las regiones admitidas por el área de trabajo de Log Analytics. No se puede modificar el área de trabajo de un proyecto después de que agrega el área de trabajo.
Costos	La solución de Service Map no incurre en ningún cargo durante los primeros 180 días. El recuento comienza desde el día en que asocia el área de trabajo de Log Analytics con el proyecto. Transcurridos los 180 días, se aplicarán las tarifas normales de Log Analytics. Usar una solución que no sea Service Map en el área de trabajo de Log Analytics asociada generará los gastos estándar de Log Analytics. Cuando se elimina el proyecto, el área de trabajo no se elimina automáticamente. Después de eliminar el proyecto, el uso de Service Map no es gratuito. Cada nodo se cobra según el nivel de pago del área de trabajo de Log Analytics. Si tiene proyectos creados antes de que Azure Migrate estuviera disponible con carácter general (GA el 28 de febrero de 2018), puede incurrir en cargos de Service Map adicionales. Para garantizar el cargo solo después de 180 días, es recomendable que cree un proyecto. Las áreas de trabajo creadas antes de la disponibilidad general siguen siendo facturables
Administración	Al registrar agentes en el área de trabajo, use el identificador y la clave proporcionados por el proyecto. Puede usar el área de trabajo de Log Analytics fuera de Azure Migrate and Modernize. Si elimina el proyecto asociado, el área de trabajo no se elimina automáticamente. Elimínela manualmente. No elimine el área de trabajo creada por Azure Migrate and Modernize, a menos que elimine el proyecto. Si lo hace, la funcionalidad de visualización de dependencias no funciona según lo previsto.
Conectividad de Internet	Si los servidores no están conectados a Internet, instale la puerta de enlace de Log Analytics en ellos.
Azure Government	El análisis de dependencias basado en agente no se admite.

Pasos siguientes

Prepárese para la detección de servidores físicos.

Compartir a través de

Matriz de compatibilidad con la detección y la evaluación físicas de servidores

Limitaciones

Requisitos del servidor físico

Permisos para servidores Windows

Opción 1

Opción 2

Permisos para el servidor Linux

Opción 1

Opción 2

Requisitos del dispositivo de Azure Migrate

Acceso a puertos

Requisitos de inventario de software

Requisitos para la detección de bases de datos e instancias de SQL Server

Autenticación de Windows

Los inicios de sesión de autenticación

Requisitos de detección de aplicaciones web

Requisitos para el análisis de dependencias (sin agentes)

Requisitos para el análisis de dependencia con agentes

Pasos siguientes

Comentarios

Recursos adicionales

Compartir a través de

Matriz de compatibilidad con la detección y la evaluación físicas de servidores

Limitaciones

Requisitos del servidor físico

Permisos para servidores Windows

Opción 1

Opción 2

Permisos para el servidor Linux

Opción 1

Opción 2

Requisitos del dispositivo de Azure Migrate

Acceso a puertos

Requisitos de inventario de software

Requisitos para la detección de bases de datos e instancias de SQL Server

Configuración del inicio de sesión personalizado para la detección de SQL Server

Autenticación de Windows

Los inicios de sesión de autenticación

Requisitos de detección de aplicaciones web

Requisitos para el análisis de dependencias (sin agentes)

Requisitos para el análisis de dependencia con agentes

Pasos siguientes

Comentarios

Recursos adicionales