Tableau de prise en charge pour l’évaluation Hyper-V

  • Article

Attention

Cet article fait référence à CentOS, une distribution Linux bientôt en fin de vie. Faites le point sur votre utilisation et organisez-vous en conséquence.

Cet article récapitule les prérequis et les conditions de prise en charge lors de la découverte et de l’évaluation de serveurs locaux s’exécutant dans un environnement Hyper-V en vue d’une migration vers Azure en utilisant l’outil Azure Migrate : Découverte et évaluation. Si vous voulez migrer des serveurs s’exécutant sur Hyper-V vers Azure, consultez la matrice de prise en charge de la migration.

Pour configurer la découverte et l’évaluation des serveurs s’exécutant sur Hyper-V, vous créez un projet et vous y ajoutez l’outil Azure Migrate : Découverte et évaluation. Une fois l’outil ajouté, vous déployez l’appliance Azure Migrate. L’appliance découvre en permanence les serveurs locaux, et envoie les métadonnées ainsi que les données de performances du serveur à Azure. Une fois la découverte terminée, vous rassemblez les serveurs découverts dans des groupes, puis vous effectuer une évaluation pour un groupe.

Limites

Support Détails
Limites d’évaluation Vous pouvez découvrir et évaluer jusqu’à 35 000 serveurs dans un même projet.
Limites de projet Vous pouvez créer plusieurs projets dans un abonnement Azure. En plus de serveurs sur Hyper-V, un projet peut inclure des serveurs sur VMware et des serveurs physiques, jusqu’aux limites d’évaluation pour chacun d’eux.
Découverte L’appliance Azure Migrate peut découvrir jusqu’à 5 000 serveurs s’exécutant sur Hyper-V.

L’appliance peut se connecter à jusqu’à 300 hôtes Hyper-V.
Évaluation Vous pouvez ajouter jusqu’à 35 000 serveurs dans un groupe unique.

Vous pouvez évaluer jusqu’à 35 000 serveurs par évaluation pour un groupe.

Apprenez-en davantage sur les évaluations.

Configuration requise pour l’hôte Hyper-V

Support Détails
Hôte Hyper-V L'hôte Hyper-V peut être autonome ou déployé dans un cluster.

L’hôte Hyper-V peut exécuter Windows Server 2022, Windows Server 2019, Windows Server 2016 ou Windows Server 2012 R2. Les installations minimales de serveurs de ces systèmes d’exploitation sont également prises en charge.
Vous ne pouvez pas évaluer des serveurs situés sur des hôtes Hyper-V exécutant Windows Server 2012.
Autorisations Vous avez besoin des privilèges Administrateur sur l’hôte Hyper-V.
Si vous ne voulez pas attribuer de privilèges Administrateur, créez un compte d’utilisateur local ou de domaine, puis ajoutez-le à ces groupes : Utilisateurs de gestion à distance, Administrateurs Hyper-V et Utilisateurs de l’Analyseur de performances.
Communication à distance PowerShell La communication à distance PowerShell doit être activée sur chaque hôte Hyper-V.
Réplication Hyper-V Si vous utilisez un réplica Hyper-V (ou si vous avez plusieurs serveurs avec les mêmes identificateurs), et que vous découvrez des serveurs d’origine et des serveurs répliqués en utilisant Azure Migrer et Moderniser, il se peut que l’évaluation générée par Azure Migrer et Moderniser ne soit pas exacte.

Configuration requise au niveau du serveur

Support Détails
Système d’exploitation Tous les systèmes d’exploitation peuvent être évalués dans une optique de migration.
Integration Services Les services d’intégration Hyper-V doivent s’exécuter sur les serveurs que vous évaluez pour capturer les informations du système d’exploitation.
Stockage Disque local, DAS, JBOD, Espaces de stockage, CSV et SMB. Ces stockages d’hôte Hyper-V sur lesquels sont stockés les disques VHD/VHDX sont pris en charge.
Les contrôleurs virtuels IDE et SCSI 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 utilisant un disque dur virtuel Hyper-V compressé que vous téléchargez depuis le portail ou en utilisant un script PowerShell. Pour plus d'informations :

Accès au port

Le tableau suivant résume les exigences du port pour l’évaluation.

Appareil Connexion
Appliance 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 en utilisant 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.
Hôte/cluster Hyper-V Connexion entrante sur le port WinRM 5985 (HTTP) pour extraire les métadonnées et les données de performances des serveurs sur Hyper-V en utilisant une session Common Information Model (CIM).
Serveurs Les serveurs Windows ont besoin d’un accès sur le port 5985 (HTTP). Les serveurs Linux ont besoin d’un accès sur le port 22 (TCP) pour effectuer l’inventaire logiciel et l’analyse des dépendances sans agent.

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 en utilisant Azure Migrer et Moderniser. Il vous aide à identifier et à 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 5 000 serveurs en cours d’exécution sur des hôtes/clusters Hyper-V ajoutés à chaque appliance Azure Migrate.
Systèmes d’exploitation Toutes les versions Windows et Linux avec les services d’intégration Hyper-V activés.
Configuration requise au niveau du serveur La fonction de communication à distance PowerShell doit être activée et la version 2.0 ou ultérieure de PowerShell doit être installée sur les serveurs Windows.

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.

La connectivité SSH (Secure Shell) doit être activée sur les serveurs Linux et les commandes suivantes doivent pouvoir être exécutées sur les serveurs Linux pour extraire les données des applications : list, tail, awk, grep, locate, head, sed, ps, print, sort, uniq. Selon le type de système d’exploitation et le type de gestionnaire de package utilisé, voici quelques commandes supplémentaires : rpm/snap/dpkg, yum/apt-cache, mssql-server.
Accès au serveur Vous pouvez ajouter plusieurs informations d’identification de domaine et hors domaine (Windows/Linux) dans le gestionnaire de configuration de l’appliance pour l’inventaire logiciel.

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 Les serveurs Windows ont besoin d’un accès sur le port 5985 (HTTP). Les serveurs Linux ont besoin d’un accès sur le port 22 (TCP).

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 changement Kerberos
Découverte L’inventaire logiciel est effectué en se connectant directement aux serveurs avec les informations d’identification des serveurs ajoutées sur l’appliance.

L’appliance recueille les informations relatives à l’inventaire logiciel auprès des serveurs Windows en utilisant la communication à distance PowerShell, et auprès des serveurs Linux en utilisant une connexion SSH.

L’inventaire de logiciels est sans agent. Aucun agent n’est installé sur les 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 utilise ces informations et tente de se connecter aux instances SQL Server respectives en utilisant les informations d’identification pour l’authentification Windows ou SQL Server fournies dans le gestionnaire de configuration de l’appliance. L’appliance peut se connecter seulement aux instances SQL Server vers lesquelles elle a une visibilité 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. Les données de configuration de SQL Server sont mises à jour une fois par jour. Les données de performances sont capturées toutes les 30 secondes.

Support Détails
Serveurs pris en charge Pris en charge seulement 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, comme Services web Azure et Google Cloud Platform.

Vous pouvez découvrir jusqu’à 750 instances SQL Server ou 15 000 bases de données SQL, selon la valeur la moins élevée, à partir d’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étection des déploiements SQL autonomes à haute disponibilité et protégés contre les sinistres est prise en charge. La découverte des déploiements SQL à haute disponibilité et de récupération d’urgence avec la technologie des instances de cluster de basculement Always On et des 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 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étection 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 a user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
  USE [?];
  IF (''?'' NOT IN (''tempdb'',''model''))
  BEGIN
    DECLARE @is_secondary_replica BIT = 0;
    IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
    BEGIN
      DECLARE @innersql NVARCHAR(MAX);
      SET @innersql = N''
        SELECT @is_secondary_replica = IIF(
          EXISTS (
              SELECT 1
              FROM sys.availability_replicas a
              INNER JOIN sys.dm_hadr_database_replica_states b
              ON a.replica_id = b.replica_id
              WHERE b.is_local = 1
              AND b.is_primary_replica = 0
              AND a.secondary_role_allow_connections = 2
              AND b.database_id = DB_ID()
          ), 1, 0
        );
      '';
      EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
    END
    IF (@is_secondary_replica = 0)
    BEGIN
      CREATE USER [MYDOMAIN\MYACCOUNT] FOR LOGIN [MYDOMAIN\MYACCOUNT];
      GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
      GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
    END
  END'
GO

-- Provide server level read-only permissions
use master;
GRANT SELECT ON sys.sql_expression_dependencies TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [MYDOMAIN\MYACCOUNT];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW DATABASE STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW SERVER STATE TO [MYDOMAIN\MYACCOUNT];
GRANT VIEW ANY DEFINITION TO [MYDOMAIN\MYACCOUNT];
GO

-- Provide msdb specific permissions
use msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [MYDOMAIN\MYACCOUNT];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [MYDOMAIN\MYACCOUNT];
GO

-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; DROP USER [MYDOMAIN\MYACCOUNT]'
-- DROP LOGIN [MYDOMAIN\MYACCOUNT];
--GO

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 a user in every database other than tempdb, model, and secondary AG databases (with connection_type = ALL) and provide minimal read-only permissions.
USE master;
EXECUTE sp_MSforeachdb '
 USE [?];
 IF (''?'' NOT IN (''tempdb'',''model''))
 BEGIN
   DECLARE @is_secondary_replica BIT = 0;
   IF CAST(PARSENAME(CAST(SERVERPROPERTY(''ProductVersion'') AS VARCHAR), 4) AS INT) >= 11
   BEGIN
     DECLARE @innersql NVARCHAR(MAX);
     SET @innersql = N''
       SELECT @is_secondary_replica = IIF(
         EXISTS (
           SELECT 1
           FROM sys.availability_replicas a
           INNER JOIN sys.dm_hadr_database_replica_states b
             ON a.replica_id = b.replica_id
           WHERE b.is_local = 1
             AND b.is_primary_replica = 0
             AND a.secondary_role_allow_connections = 2
             AND b.database_id = DB_ID()
         ), 1, 0
       );
     '';
     EXEC sp_executesql @innersql, N''@is_secondary_replica BIT OUTPUT'', @is_secondary_replica OUTPUT;
   END

   IF (@is_secondary_replica = 0)
   BEGIN
       CREATE USER [evaluator] FOR LOGIN [evaluator];
       GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
       GRANT VIEW DATABASE STATE TO [evaluator];
   END
 END'
GO

-- Provide server level read-only permissions
USE master;
GRANT SELECT ON sys.sql_expression_dependencies TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_regenumkeys TO [evaluator];
GRANT EXECUTE ON OBJECT::sys.xp_instance_regread TO [evaluator];
GRANT VIEW DATABASE STATE TO [evaluator];
GRANT VIEW SERVER STATE TO [evaluator];
GRANT VIEW ANY DEFINITION TO [evaluator];
GO

-- Provide msdb specific permissions
USE msdb;
GRANT EXECUTE ON [msdb].[dbo].[agent_datetime] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobsteps] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syssubsystems] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobhistory] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscategories] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysjobs] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmaintplan_plans] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[syscollector_collection_sets] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profile] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_profileaccount] TO [evaluator];
GRANT SELECT ON [msdb].[dbo].[sysmail_account] TO [evaluator];
GO

-- Clean up
--use master;
-- EXECUTE sp_MSforeachdb 'USE [?]; BEGIN TRY DROP USER [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;'
-- BEGIN TRY DROP LOGIN [evaluator] END TRY BEGIN CATCH PRINT ERROR_MESSAGE() END CATCH;
--GO

Exigences pour la découverte d’applications web

L’inventaire logiciel identifie le rôle de 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 hors 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 aux serveurs respectifs : vous n’avez donc pas à les mapper manuellement. 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, CentOS 6/7 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.
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 hôtes/clusters Hyper-V) découverts par appliance.
Systèmes d’exploitation Toutes les versions Windows et Linux avec les services d’intégration Hyper-V activés.
Configuration requise au niveau du serveur La fonction de communication à distance PowerShell doit être activée et la version 2.0 ou ultérieure de PowerShell doit être installée sur les serveurs Windows.

La connectivité SSH doit être activée sur les serveurs Linux et les commandes suivantes doivent pouvoir être exécutées sur les serveurs Linux : touch, chmod, cat, ps, grep, echo, sha256sum, awk, netstat, ls, sudo, dpkg, rpm, sed, getcap, which, date.
Accès au serveur Windows Un compte d’utilisateur (local ou de domaine) avec des autorisations d’administrateur sur les serveurs.
Accès au serveur Linux Un 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 aussi 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 en utilisant les 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 Les serveurs Windows ont besoin d’un accès sur le port 5985 (HTTP). Les serveurs Linux ont besoin d’un accès sur le port 22 (TCP).
Méthode de détection L’analyse des dépendances sans agent est effectuée en se connectant directement aux serveurs avec les informations d’identification des serveurs ajoutées sur l’appliance.

L’appliance recueille les informations relatives aux dépendances auprès des serveurs Windows en utilisant la communication à distance PowerShell, et auprès des serveurs Linux en utilisant la connexion SSH.

Aucun agent n’est installé sur les serveurs pour extraire les données de dépendance.

Conditions requises de l’analyse des dépendances basées sur un agent

L’analyse des dépendances vous permet d’identifier les dépendances entre les machines locales que vous souhaitez évaluer et migrer vers Azure. Le tableau récapitule les conditions requises pour la configuration de l’analyse des dépendances basées sur un agent. Actuellement, Hyper-V prend uniquement en charge la visualisation 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 l’outil Azure Migrate : Découverte et évaluation à un projet existant.
Découvrez comment configurer l’appliance pour la découverte et l’évaluation des serveurs sur Hyper-V.
Azure Government La visualisation des dépendances n’est pas disponible dans Azure Government.
Log Analytics Azure Migrer et Moderniser 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 résider 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 Migrer et Moderniser est étiqueté avec la clé du projet de migration et le nom du projet.
Agents nécessaires Sur chaque serveur à analyser, installez les agents suivants :

Microsoft Monitoring Agent (MMA)
Agent de dépendances

Si les serveurs locaux ne sont pas connectés à Internet, vous devez télécharger et installer la passerelle Log Analytics sur ceux-ci.

En savoir plus sur l’installation de Dependency Agent et de MMA.
Espace de travail Log Analytics L’espace de travail doit se trouver dans le même abonnement que le projet.

Azure Migrer et Moderniser prend en charge les espaces de travail qui se trouvent 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 pour 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.

Quand le projet est supprimé, l’espace de travail ne l’est pas. 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 qu’un paiement ne survient qu’au bout de 180 jours seulement, 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, vous utilisez l’ID et la clé fournis par le projet.

Vous pouvez utiliser l’espace de travail Log Analytics en dehors d’Azure Migrer et Moderniser.

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 Migrer et Moderniser, 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, vous devez installer 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.

Étapes suivantes

Préparez-vous pour l’évaluation des serveurs s’exécutant sur Hyper-V.