Matrice de support pour la détection VMware

Cet article récapitule les prérequis et les conditions de prise en charge de l’utilisation de l’outil Azure Migrate : découverte et évaluation pour découvrir et évaluer des serveurs dans un environnement VMware pour la migration vers Azure.

Pour évaluer des serveurs, commencez par créer un projet Azure Migrate. L’outil Azure Migrate : découverte et évaluation est automatiquement ajouté au projet. Déployez ensuite l’appliance Azure Migrate. L’appliance découvre en permanence les serveurs locaux et envoie des métadonnées de configuration et de performances à Azure. Une fois la détection terminée, rassemblez les serveurs détectés dans des groupes et exécutez les évaluations par groupe.

Lorsque vous planifiez la migration de serveurs VMware vers Azure, consultez la matrice de prise en charge de la migration.

Configuration requise pour VMware

VMware	Détails
Serveur vCenter	Les serveurs que vous souhaitez découvrir et évaluer doivent être gérés par vCenter Server version 8.0, 7.0, 6.7, 6.5, 6.0 ou 5.5. La découverte des serveurs via la fourniture des détails de l’hôte ESXi dans l’appliance n’est pas prise en charge actuellement. Les adresses IPv6 ne sont pas prises en charge pour un serveur vCenter (pour la découverte et l’évaluation des serveurs) et les hôtes ESXi (pour la réplication de serveurs).
Autorisations	L’outil Azure Migrate : découverte et évaluation nécessite un compte vCenter Server en lecture seule. Si vous souhaitez utiliser l’outil pour l’inventaire logiciel, l’analyse des dépendances sans agent, les applications web et la découverte SQL, le compte doit disposer de privilèges pour les opérations d’invité sur les machines virtuelles (VM) VMware.

Configuration requise au niveau du serveur

VMware	Détails
Systèmes d’exploitation	Tous les systèmes d’exploitation Windows et Linux peuvent être évalués pour la migration.
Stockage	Les disques attachés à des contrôleurs SCSI, IDE et SATA sont pris en charge.

Conditions requises de l’appliance Azure Migrate

Azure Migrer et Moderniser utilise l’appliance Azure Migrate pour la découverte et l’évaluation. Vous pouvez déployer l’appliance en tant que serveur dans votre environnement VMware en utilisant un modèle VMware Open Virtualization Appliance importé dans vCenter Server. Vous pouvez également utiliser un script PowerShell. En savoir plus sur les conditions requises de l’appliance pour VMware.

Voici d’autres exigences pour l’appliance :

• Dans Azure Government, vous devez déployer l’appliance à l’aide d’un script.
• L’appliance doit pouvoir accéder à des URL spécifiques dans des clouds publics et des clouds du secteur public.

Conditions relatives à l’accès aux ports

Appareil	Connexion
Appliance Azure Migrate	Connexions entrantes sur le port TCP 3389 pour permettre des connexions Bureau à distance avec l’appliance. Connexions entrantes sur le port 44368 pour accéder à distance à l’application de gestion de l’appliance à l’aide de l’URL https://<appliance-ip-or-name>:44368. Connexions sortantes sur le port 443 (HTTPS) pour envoyer les métadonnées de découverte et de performances à Azure Migrer et Moderniser.
Serveur vCenter	Connexions entrantes sur le port TCP 443 pour permettre à l’appliance de collecter les métadonnées de configuration et de performances pour les évaluations. L’appliance se connecte à vCenter sur le port 443 par défaut. Si vCenter Server écoute sur un autre port, vous pouvez modifier le port lors de la configuration de la découverte.
Hôtes ESXi	Pour effectuer une découverte de l’inventaire des logiciels ou une analyse des dépendances sans agent, l’appliance se connecte aux hôtes ESXi sur le port TCP 443 pour découvrir l’inventaire des logiciels et les dépendances sur les serveurs.

Exigences pour l’inventaire des logiciels

Outre la découverte des serveurs, Azure Migrate : découverte et évaluation peuvent exécuter l’inventaire des logiciels sur les serveurs. L’inventaire logiciel fournit la liste des applications, des rôles et des fonctionnalités exécutés sur les serveurs Windows et Linux, découverts à l’aide d’Azure Migrer et Moderniser. Il vous permet d’identifier et de planifier un chemin de migration adapté à vos charges de travail locales.

Support	Détails
Serveurs pris en charge	Vous pouvez effectuer un inventaire logiciel sur un maximum de 10 000 serveurs exécutés sur les serveurs VMware vCenter ajoutés à chaque appliance Azure Migrate.
Systèmes d’exploitation	Les serveurs exécutant toutes les versions de Windows et Linux sont pris en charge.
Configuration requise au niveau du serveur	Pour effectuer un inventaire de logiciels, les outils VMware doivent être installés et en cours d’exécution sur vos serveurs. La version des outils VMware doit être la version 10.2.1 ou une version ultérieure. PowerShell version 2.0 ou ultérieure doit être installé sur les serveurs Windows. Windows Management Instrumentation (WMI) doit être activé et disponible sur les serveurs Windows pour recueillir les détails des rôles et fonctionnalités installés sur les serveurs.
Compte vCenter Server	Pour interagir avec les serveurs en vue de l’inventaire de logiciels, le compte vCenter Server en lecture seule utilisé pour l’évaluation doit disposer de privilèges pour les opérations d’invités sur les machines virtuelles VMware.
Accès au serveur	Vous pouvez ajouter plusieurs informations d’identification de domaine et hors domaine (Windows/Linux) au gestionnaire de configuration de l’appliance pour l’inventaire de logiciels. Vous devez disposer d’un compte d’utilisateur invité pour les serveurs Windows et d’un compte d’utilisateur standard (accès non sudo) pour tous les serveurs Linux.
Accès au port	L’appliance Azure Migrate doit être en mesure de se connecter au port TCP 443 sur les hôtes ESXi exécutant les serveurs sur lesquels vous souhaitez effectuer un inventaire de logiciels. Le serveur exécutant vCenter Server retourne une connexion d’hôte ESXi pour télécharger le fichier contenant les détails de l’inventaire des logiciels. Si vous utilisez des informations d’identification de domaine, l’appliance Azure Migrate doit être en mesure de se connecter aux ports TCP et UDP suivants : TCP 135 – Point de terminaison RPC TCP 389 – LDAP TCP 636 – LDAP SSL TCP 445 – SMB TCP/UDP 88 – Authentification Kerberos TCP/UDP 464 – Opérations de modification Kerberos
Découverte	L’inventaire de logiciels s’exécute à partir de vCenter Server à l’aide d’outils VMware installés sur les serveurs. L’appliance recueille les informations sur l’inventaire des logiciels à partir du serveur exécutant vCenter Server par l’intermédiaire d’API vSphere. L’inventaire de logiciels est sans agent. Aucun agent n’est installé sur le serveur et l’appliance ne se connecte pas directement aux serveurs.

Exigences en matière de découverte de base de données et d’instance SQL Server

L’inventaire de logiciels identifie des instances SQL Server. L’appliance tente de se connecter aux diverses instances SQL Server grâce aux informations d’identification pour l’authentification Windows ou SQL Server fournies dans le gestionnaire de configuration de l’appliance à l’aide de ces informations. L’appliance peut se connecter uniquement aux instances SQL Server vers lesquelles elle dispose d’une ligne de vue réseau. L’inventaire logiciel lui-même n’a pas nécessairement besoin d’une visibilité réseau.

Une fois connectée, l’appliance recueille les données de configuration et de performances pour les instances et bases de données SQL Server. L’appliance met à jour les données de configuration SQL Server une fois toutes les 24 heures et capture les données de performances toutes les 30 secondes.

Support	Détails
Serveurs pris en charge	Pris en charge uniquement pour les serveurs exécutant SQL Server dans vos environnements VMware, Microsoft Hyper-V et les environnements physiques/nus, et pour les serveurs IaaS (Infrastructure as a Service) d’autres clouds publics, tels qu’Amazon Web Services (AWS) et Google Cloud Platform (GCP). Vous pouvez découvrir jusqu’à 750 instances SQL Server ou 15 000 bases de données SQL, selon la valeur la plus faible, depuis une seule appliance. Nous vous recommandons de faire en sorte qu’une appliance soit limitée à la découverte de moins de 600 serveurs exécutant SQL, de façon à éviter les problèmes de mise à l’échelle.
Serveurs Windows	Windows Server 2008 et les versions ultérieures sont pris en charge.
Serveurs Linux	Non prise en charge.
Mécanisme d’authentification	Les authentifications Windows et SQL Server sont toutes deux prises en charge. Vous pouvez fournir des informations d’identification des deux types d’authentification dans le gestionnaire de configuration de l’appliance.
Accès à SQL Server	Pour découvrir des instances et des bases de données SQL Server, le compte Windows ou SQL Server doit être membre du rôle serveur sysadmin ou disposer de ces autorisations pour chaque instance SQL Server.
Versions de SQL Server	SQL Server 2008 et les versions ultérieures sont pris en charge.
Éditions de SQL Server	Les éditions Enterprise, Standard, Développeur et Express sont prises en charge.
Configuration de SQL prise en charge	La découverte des déploiements SQL autonomes, hautement disponibles et protégés contre les sinistres est prise en charge. La découverte des déploiements SQL de récupération d’urgence à haute disponibilité alimentés par les instances de cluster de basculement Always On et les groupes de disponibilité Always On est également prise en charge.
Services SQL pris en charge	Seul le moteur de base de données SQL Server est pris en charge. La découverte de SQL Server Reporting Services, de SQL Server Integration Services et de SQL Server Analysis Services n’est pas prise en charge.

Remarque

Par défaut, Azure Migrer et Moderniser utilise le moyen le plus sécurisé de se connecter à des instances SQL. Ainsi, Azure Migrer et Moderniser chiffre les communications entre l’appliance Azure Migrate et les instances SQL Server sources lorsque en définissant la propriété TrustServerCertificate sur true. De plus, la couche transport utilise Secure Socket Layer pour chiffrer le canal et contourner la chaîne de certificat pour valider l’approbation. Pour cette raison, le serveur de l’appliance doit être configuré pour approuver l’autorité racine du certificat.

Cependant, vous pouvez modifier les paramètres de connexion en sélectionnant Modifier les propriétés de connexion de SQL Server sur l’appliance. Plus d’informations pour comprendre ce que vous devez choisir.

Configurer la connexion personnalisée pour la découverte de SQL Server

Utilisez les exemples de scripts suivants pour créer une connexion et y provisionner les autorisations nécessaires.

Authentification 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

Authentification 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

Exigences pour la découverte d’applications web

L’inventaire de logiciels identifie le rôle serveur web existant sur les serveurs découverts. Si un serveur web est installé sur un serveur, Azure Migrer et Moderniser découvre les applications web sur le serveur.

Vous pouvez ajouter les informations d’identification de domaine et de non-domaine sur l’appliance. Assurez-vous que le compte utilisé dispose de privilèges Administrateur local sur les serveurs sources. Azure Migrer et Moderniser mappe automatiquement les informations d’identification sur les serveurs respectifs, vous n’êtes donc pas obligé de les mapper manuellement. Plus important encore, ces informations d’identification ne sont jamais envoyées à Microsoft et restent sur l’appliance s’exécutant dans l’environnement source.

Une fois que l’appliance est connectée, elle recueille les données de configuration pour les applications web ASP.NET (serveur web IIS) et les applications web Java (serveurs Tomcat). Les données de configuration des applications web sont mises à jour une fois par jour.

Support	Applications web ASP.NET	Applications web Java
Pile	Serveurs VMware, Hyper-V et physiques.	Serveurs VMware, Hyper-V et physiques.
Serveurs Windows	Windows Server 2008 R2 et les versions ultérieures sont pris en charge.	Non pris en charge.
Serveurs Linux	Non pris en charge.	Ubuntu Linux 16.04/18.04/20.04, Debian 7/8 et Red Hat Enterprise Linux 5/6/7.
Versions de serveur web	IIS 7.5 et versions ultérieures.	Tomcat 8 et versions ultérieures.
Protocol	Port WinRM 5985 (HTTP)	Port SSH 22 (TCP)
Privilèges requis	Administrateur local.	Utilisateur root ou sudo.

Remarque

Les données sont toujours chiffrées au repos et pendant le transit.

Conditions relatives à l’analyse des dépendances (sans agent)

L’analyse des dépendances vous aide à analyser les dépendances entre les serveurs découverts. Vous pouvez facilement visualiser les dépendances avec une vue cartographique dans un projet Azure Migrate. Vous pouvez utiliser des dépendances pour regrouper les serveurs associés pour la migration vers Azure. Le tableau suivant récapitule les conditions requises pour la configuration de l’analyse des dépendances sans agent.

Support	Détails
Serveurs pris en charge	Vous pouvez activer l’analyse des dépendances sans agent sur un maximum de 1 000 serveurs (sur plusieurs serveurs vCenter) découverts par appliance.
Serveurs Windows	Windows Server 2022 Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 (64 bits) Windows Server 2008 (32 bits)
Serveurs Linux	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 OracleLinux 6.1, 6.7, 6.8, 6.9, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.3, 8.5 SUSE Linux 10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3 Debian 7, 8, 9, 10, 11
Configuration requise au niveau du serveur	Les outils VMware (10.2.1 et versions ultérieures) doivent être installés et en cours d’exécution sur les serveurs que vous voulez analyser. PowerShell, versions 2.0 ou ultérieures, doit être installé sur les serveurs. WMI doit être activé et disponible sur les serveurs Windows.
Compte vCenter Server	Le compte en lecture seule utilisé par Azure Migrer et Moderniser pour l’évaluation doit disposer de privilèges pour les opérations d’invité sur des machines virtuelles VMware.
Accès au serveur Windows	Compte d'utilisateur invité
Accès au serveur Linux	Compte d’utilisateur sudo disposant des autorisations nécessaires pour exécuter les commandes ls et netstat. Si vous fournissez un compte d’utilisateur sudo, assurez-vous d’avoir activé NOPASSWD pour que le compte exécute les commandes requises sans demander un mot de passe chaque fois que la commande sudo est appelée. Vous pouvez également créer un compte d’utilisateur disposant des autorisations CAP_DAC_READ_SEARCH et CAP_SYS_PTRACE sur les fichiers /bin/netstat et /bin/ls, définies à l’aide des commandes suivantes : sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat
Accès au port	L’appliance Azure Migrate doit pouvoir se connecter au port TCP 443 sur les hôtes ESXi exécutant les serveurs dont vous souhaitez découvrir les dépendances. Le serveur exécutant vCenter Server retourne une connexion d’hôte ESXi pour télécharger le fichier contenant les données de dépendance.
Méthode de détection	Les informations de dépendance entre serveurs sont collectées à partir des outils VMware sur le serveur exécutant vCenter Server. L’appliance recueille les informations à partir du serveur à l’aide d’API vSphere. Aucun agent n’est installé sur le serveur, et l’appliance ne se connecte pas directement aux serveurs.

Remarque

Dans certaines versions récentes du système d'exploitation Linux, la commande netstat a été remplacée par la commande ss; tenez-en compte lors de la préparation des serveurs.

Conditions relatives à l’analyse des dépendances (basée sur un agent)

L’analyse des dépendances vous permet d’identifier les dépendances entre les serveurs locaux que vous souhaitez évaluer et migrer vers Azure. Le tableau suivant récapitule les conditions requises pour la configuration de l’analyse des dépendances basées sur un agent.

Condition requise	Détails
Avant le déploiement	Vous devez disposer d’un projet, avec l’outil Azure Migrate : Découverte et évaluation ajouté au projet. Vous déployez la visualisation des dépendances après avoir configuré une appliance Azure Migrate pour découvrir vos serveurs locaux. Découvrez comment créer un projet pour la première fois. Découvrez comment ajouter un outil de découverte et d’évaluation à un projet existant. Découvrez comment configurer l’appliance Azure Migrate pour l’évaluation de serveurs Hyper-V, VMware ou physiques.
Serveurs pris en charge	Pris en charge pour tous les serveurs dans votre environnement local.
Log Analytics	Azure Migrate and Modernize utilise la solution Service Map dans Journaux Azure Monitor pour la visualisation des dépendances. Vous associez un espace de travail Log Analytics nouveau ou déjà existant à un projet. Vous ne pouvez pas modifier l’espace de travail pour un projet après avoir ajouté un espace de travail. L’espace de travail doit se trouver dans le même abonnement que le projet. L’espace de travail doit se situer dans les régions USA Est, Asie Sud-Est ou Europe Ouest. Les espaces de travail des autres régions ne peuvent pas être associés à un projet. L’espace de travail doit se trouver dans une région dans laquelle Service Map est pris en charge. Vous pouvez surveiller les machines virtuelles Azure de n’importe quelle région. Les machines virtuelles elles-même ne sont pas limitées aux régions prises en charge par l’espace de travail Log Analytics. Dans Log Analytics, l’espace de travail associé à Azure Migrate est marqué avec la clé de projet et le nom du projet.
Agents nécessaires	Sur chaque serveur à analyser, installez les agents suivants : - Agent Azure Monitor (AMA) - Agent de dépendances Si les serveurs locaux ne sont pas connectés à Internet, téléchargez et installez la passerelle Log Analytics sur ceux-ci. En savoir plus sur l’installation de l’agent Dependency Agent et de l’agent Azure Monitor.
Espace de travail Log Analytics	L’espace de travail doit se trouver dans le même abonnement que le projet. Azure Migrate prend en charge les espaces de travail situés dans les régions USA Est, Asie Sud-Est et Europe Ouest. L’espace de travail doit se trouver dans une région dans laquelle Service Map est pris en charge. Vous pouvez surveiller les machines virtuelles Azure de n’importe quelle région. Les machines virtuelles elles-même ne sont pas limitées aux régions prises en charge par l’espace de travail Log Analytics. Vous ne pouvez pas modifier l’espace de travail d’un projet après avoir ajouté un espace de travail.
Coûts	La solution Service Map n’entraîne aucun frais durant les 180 premiers jours. Le décompte débute le jour où vous associez l'espace de travail Log Analytics au projet. Au bout de 180 jours, des frais Log Analytics standard s’appliquent. L’utilisation d’une autre solution que Service Map dans l’espace de travail Log Analytics associé entraîne des frais standard pour l’espace de travail Log Analytics. Lorsque le projet est supprimé, l’espace de travail n’est pas supprimé automatiquement. Une fois que vous avez supprimé le projet, l’utilisation de Service Map n’est plus gratuite. Chaque nœud est facturé en fonction du niveau payant de l’espace de travail Log Analytics. Si vous avez créé des projets avant la disponibilité générale d’Azure Migrate (le 28 février 2018), vous pouvez encourir d’autres frais liés à Service Map. Pour garantir que des frais ne vous sont facturés qu’après 180 jours, nous vous recommandons de créer un nouveau projet. Les espaces de travail créés avant la disponibilité générale sont toujours facturables.
Gestion	Lorsque vous inscrivez des agents dans l’espace de travail, utilisez l’ID et la clé fournis par le projet. Vous pouvez utiliser l’espace de travail Log Analytics en dehors d’Azure Migrate and Modernize. Si vous supprimez le projet associé, l’espace de travail n’est pas automatiquement supprimé. Supprimez-le manuellement. Ne supprimez pas l’espace de travail créé par Azure Migrate and Modernize, sauf si vous supprimez le projet. La suppression de l’espace de travail entraînerait un dysfonctionnement de la fonctionnalité de visualisation des dépendances.
Connectivité Internet	Si les serveurs ne sont pas connectés à Internet, installez la passerelle Log Analytics sur ceux-ci.
Azure Government	L'analyse des dépendances basée sur un agent n'est pas prise en charge.

Limites

Condition requise	Détails
Limites de projet	Vous pouvez créer plusieurs projets Azure Migrate dans un abonnement Azure. Vous pouvez découvrir et évaluer jusqu’à 50 000 serveurs dans un environnement VMware d’un même projet. Un projet peut inclure des serveurs physiques et des serveurs d’un environnement Hyper-V, dans les limites de l’évaluation.
Découverte	L’appliance Azure Migrate peut découvrir jusqu’à 10 000 serveurs s’exécutant sur plusieurs vCenter Servers. L’appliance prend en charge l’ajout de plusieurs vCenter Servers. Vous pouvez ajouter jusqu’à 10 vCenter Servers par appliance. Ce montant est également valide pour Azure VMware Solution.
Évaluation	Vous pouvez ajouter jusqu’à 35 000 serveurs dans un groupe unique. Vous pouvez évaluer jusqu’à 35 000 serveurs par évaluation.

En savoir plus sur les évaluations.

Importer des serveurs à l’aide de XLSX RVTools (préversion)

Dans le cadre de votre parcours de migration vers Azure à l’aide de l’appliance Azure Migrate, vous découvrez d’abord les serveurs, l’inventaire et les charges de travail. Toutefois, pour une évaluation rapide avant de déployer l’appliance, vous pouvez importer les serveurs à l’aide du fichier XLSX RVTools (préversion).

Principaux avantages

Utiliser un fichier XLSX RVTools :

• Permet de créer un cas d’entreprise ou d’évaluer les serveurs avant de déployer l’appliance.
• Aide comme alternative lorsqu’il existe une restriction organisationnelle pour déployer l’appliance Azure Migrate.
• Vous aide lorsque vous n’arrivez pas à partager des informations d’identification qui autorisent l’accès aux serveurs locaux.
• Est utile lorsque les contraintes de sécurité vous empêchent de collecter et d’envoyer les données collectées par l’appliance à Azure.

Limites

Cette section traite des limitations à prendre en compte.

Considérations relatives à l’analyse de rentabilité

Si vous importez des serveurs à l’aide d’un fichier XLSX RVTools et que vous créez un cas d’entreprise, notez ces quelques limitations :

• La durée de l’historique des performances dans les paramètres Azure n’est pas applicable.
• Les serveurs sont classés comme inconnus dans le graphique d’insights d’utilisation des cas d’entreprise et sont dimensionnés tels quels sans dimensionnement approprié pour le coût Azure ou Azure VMware Solution.

Considérations relatives à l’évaluation

Si vous importez des serveurs à l’aide d’un fichier XLSX RVTools pour créer une évaluation avec les critères suivants :

• Critères de dimensionnement en fonction des performances de l’UC et de la mémoire configurées (en fonction des processeurs et des colonnes mémoire de XLSX RVTools).
• Critères de stockage (Mio en cours d’utilisation et Mo en cours d’utilisation pour les versions antérieures à la version 4.1.2).

Vous ne pourrez pas fournir d’historique des performances ou des informations de centile.

Pour obtenir une compatibilité ou une préparation de système d’exploitation précise dans l’évaluation Azure VM et Azure VMware Solution, entrez la version et l’architecture du système d’exploitation dans les colonnes correspondantes.

Étapes suivantes

• Passez en revue les meilleures pratiques relatives à l’évaluation.
• Découvrez comment vous préparer une évaluation VMware.