Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article récapitule les prérequis et les exigences de prise en charge lorsque vous découvrez et évaluez les serveurs locaux s’exécutant dans un environnement Hyper-V pour la migration vers Azure à l’aide de l’outil Azure Migrate : découverte et évaluation. Si vous souhaitez migrer des serveurs s’exécutant sur Hyper-V vers Azure, consultez la matrice de prise en charge migration.
Pour configurer la découverte et l’évaluation des serveurs s’exécutant sur Hyper-V, vous créez un projet et ajoutez l’outil Azure Migrate : découverte et évaluation au projet. Une fois l’outil ajouté, vous déployez l’appliance Azure Migrate. L’appliance découvre en permanence les serveurs locaux et envoie des métadonnées de serveur et des données de performances à Azure. Une fois la découverte terminée, vous rassemblez les serveurs découverts dans des groupes, puis vous effectuez une évaluation pour chaque groupe.
Limites
| Soutien | 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 des 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
| Soutien | 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 les serveurs situés sur Hyper-V hôtes exécutant Windows Server 2012. |
| Autorisations | Vous avez besoin d’autorisations d’administrateur sur l’hôte Hyper-V. Si vous ne souhaitez pas attribuer d'autorisations d'administrateur, créez un compte d'utilisateur local ou de domaine et ajoutez le compte d'utilisateur à ces groupes : Utilisateurs de gestion à distance, administrateurs Hyper-V et utilisateurs Analyseur de performances. |
| Communication à distance PowerShell | PowerShell remoting doit être activé sur chaque hôte Hyper-V. |
| réplica Hyper-V | Si vous utilisez Hyper-V réplica (ou si vous avez plusieurs serveurs avec les mêmes identificateurs de serveur), et que vous découvrez les serveurs d'origine et répliqués à l'aide de Azure Migrate et moderniser, l'évaluation générée par Azure Migrate et Moderniser peut ne pas être exacte. |
Configuration requise au niveau du serveur
| Soutien | Détails |
|---|---|
| Système d’exploitation | Tous les systèmes d’exploitation peuvent être évalués dans une optique de migration. |
| Services d'intégration | Hyper-V Integration Services doit s’exécuter sur des 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. |
configuration requise de l’appliance Azure Migrate
Azure Migrate et Moderniser utilise l’appliance Azure Migrate pour la découverte et l’évaluation. Vous pouvez déployer l’appliance à l’aide d’un disque dur virtuel compressé Hyper-V que vous téléchargez à partir du portail ou à l’aide d’un script PowerShell. Pour plus d'informations :
- Découvrez les exigences relatives aux appliances pour Hyper-V.
- En savoir plus sur les URL auxquelles l’appliance doit accéder dans les clouds publics et gouvernementaux.
- Utilisez le script pour déployer l’appliance dans Azure Government.
Accès au port
Le tableau suivant résume les exigences du port pour l’évaluation.
| Appareil | Connexion |
|---|---|
| Appareil | 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>:44368Connexions sortantes sur les ports 443 (HTTPS) pour envoyer des métadonnées de découverte et de performance à Azure Migrate et Modernize. |
| hôte/cluster Hyper-V | La connexion entrante utilise le port WinRM 5986 (HTTPS) par défaut. Si les prérequis HTTPS ne sont pas configurés sur les serveurs cibles, la communication revient au port WinRM 5985 (HTTP) pour collecter des métadonnées et des données de performances pour les serveurs Hyper-V à l’aide d’une session CIM (Common Information Model). |
| Serveurs | Windows serveurs doivent accéder au port 5986 (HTTPS) ou au 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
En plus de découvrir des serveurs, Azure Migrate : la découverte et l’évaluation peuvent effectuer un inventaire logiciel sur des serveurs. L’inventaire logiciel fournit la liste des applications, des rôles et des fonctionnalités s’exécutant sur des serveurs Windows et Linux découverts à l’aide de Azure Migrate et moderniser. Il vous aide à identifier et à planifier un chemin de migration adapté à vos charges de travail locales.
| Soutien | Détails |
|---|---|
| Serveurs pris en charge | Vous pouvez effectuer un inventaire logiciel sur jusqu’à 5 000 serveurs exécutés sur des hôtes/clusters Hyper-V ajoutés à chaque appliance Azure Migrate. |
| Systèmes d’exploitation | Toutes les versions Windows et Linux avec Hyper-V services d’intégration activés. |
| Configuration requise au niveau du serveur | Les serveurs Windows doivent avoir le service de gestion à distance PowerShell activé et la version 2.0 ou supérieure de PowerShell installée. WMI doit être activé et disponible sur Windows serveurs pour collecter 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 domaines et informations d’identification non-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 Windows serveurs et d’un compte d’utilisateur standard (accès non sudo) pour tous les serveurs Linux. |
| Accès au port | Windows serveurs doivent accéder au port 5986 (HTTPS) ou au 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 modification 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 collecte les informations sur l’inventaire logiciel à partir de serveurs Windows à l’aide de la communication à distance PowerShell et des serveurs Linux à l’aide de la connexion SSH. L’inventaire de logiciels est sans agent. Aucun agent n’est installé sur les serveurs. |
Exigences pour la découverte des instances et des bases de données SQL Server
Inventaire des logiciels identifie les instances SQL Server. L’appliance utilise ces informations et tente de se connecter à des instances de SQL Server respectives via le Authentification Windows ou les informations d’identification d’authentification SQL Server fournies dans le gestionnaire de configuration de l’appliance. L’appliance ne peut se connecter qu’aux instances SQL Server auxquelles 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 l’appliance connectée, elle collecte les données de configuration et de performances pour SQL Server instances et bases de données. SQL Server données de configuration sont mises à jour une fois toutes les 24 heures. Les données de performances sont capturées toutes les 30 secondes.
| Soutien | Détails |
|---|---|
| Serveurs pris en charge | Pris en charge uniquement pour les serveurs exécutant des SQL Server dans vos environnements VMware, Microsoft Hyper-V et les environnements physiques/nus et les serveurs IaaS (Infrastructure as a Service) d’autres clouds publics, tels que Azure Services Web et Google Cloud Platform. Vous pouvez découvrir jusqu’à 750 instances SQL Server ou 15 000 bases de données SQL, selon ce qui est inférieur, à 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 versions ultérieures sont prises en charge. |
| Serveurs Linux | Actuellement non pris en charge |
| Mécanisme d’authentification | Les authentifications Windows et SQL Server sont 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 les instances et les bases de données SQL Server, le compte Windows/domaine ou le compte SQL Server requiert ces autorisations de lecture à privilège faible pour chaque instance de SQL Server. Vous pouvez utiliser l’utilitaire d’approvisionnement de compte à faible privilège pour créer des comptes personnalisés ou utiliser n’importe quel compte existant membre du rôle serveur sysadmin pour plus de simplicité. |
| versions de SQL Server | SQL Server 2008 et versions ultérieures sont prises en charge. |
| éditions de SQL Server | Les éditions Enterprise, Standard, Développeur et Express sont prises en charge. |
| Configuration 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 | Seule Moteur de base de données SQL Server est prise 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 Migrate et Moderniser utilisent le moyen le plus sécurisé de se connecter à des instances SQL. Autrement dit, Azure Migrate et Moderniser chiffre la communication entre l’appliance Azure Migrate et les instances de SQL Server source 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.
Toutefois, vous pouvez modifier les paramètres de connexion en sélectionnant Edit SQL Server propriétés de connexion 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 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 de 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 est trouvé sur lequel un serveur web est installé, Azure Migrate et Moderniser découvre les applications web sur le serveur.
Vous pouvez ajouter les informations d’identification de domaine et non liées au domaine sur l’appliance. Assurez-vous que le compte utilisé dispose de privilèges Administrateur local sur les serveurs sources. Azure Migrate et moderniser mappe automatiquement les informations d'identification aux serveurs respectifs. Vous n'avez donc pas besoin de les mapper manuellement. Ces informations d’identification ne sont jamais envoyées à Microsoft et restent sur l’appliance en cours d’exécution dans l’environnement source.
Une fois l’appliance connectée, elle collecte des 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.
| Soutien | applications web ASP.NET | applications web en Java |
|---|---|---|
| Pile | Serveurs VMware, Hyper-V et physiques. | Serveurs VMware, Hyper-V et physiques. |
| serveurs Windows | Windows Server 2008 R2 et versions ultérieures sont prises en charge. | Non pris en charge. |
| Serveurs Linux | Non prise en charge | Serveurs qui répondent aux exigences. |
| Versions de serveur web | IIS 7.5 et versions ultérieures | Tomcat 8 ou version ultérieure |
| Protocole | Le port WinRM 5986 (HTTPS) par défaut, si les prérequis HTTPS ne sont pas configurés sur les serveurs cibles, la communication revient au port WinRM 5985 (HTTP) | Port SSH 22 (TCP) |
| Privilèges requis | L’utilisateur le moins privilégié doit faire partie des deux groupes d’utilisateurs 1. Utilisateurs de gestion à distance 2. IIS_IUSRS. Les utilisateurs doivent disposer d'autorisations de lecture aux emplacements suivants : C :\Windows\system32\inetsrv\config, C :\Windows\system32\inetsrv\config\applicationHost.config et C :\Windows\system32\inetsrv\config\redirection.config. Ajouter l'utilisateur à « se connecter en tant que travail par lots » à l'aide de secpol.msc et vérifier que l'utilisateur ne fait pas partie de « refuser l'ouverture de session en tant que travail par lots ». |
Les autorisations Read (r) et Execute (x) de manière récursive sur tous les répertoires CATALINA_HOME. |
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.
| Soutien | Détails |
|---|---|
| Serveurs pris en charge | Vous pouvez activer l’analyse des dépendances sans agent sur jusqu’à 1 000 serveurs (sur plusieurs hôtes/clusters Hyper-V) détectés par appliance. |
| Systèmes d’exploitation | Toutes les versions Windows et Linux avec Hyper-V services d’intégration activés. |
| Configuration requise au niveau du serveur | Les serveurs Windows doivent avoir le service de gestion à distance PowerShell activé et la version 2.0 ou supérieure de PowerShell installée. 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 | 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. |
| Accès au port | Windows serveurs doivent accéder au port 5986 (HTTPS) ou au 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 collecte les informations de dépendance à partir de serveurs Windows à l’aide de la communication à distance PowerShell; pour les serveurs Linux, elle utilise 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
Analyse de la dépendance vous permet d’identifier les dépendances entre les serveurs locaux 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ée sur l’agent.
| Condition requise | Détails |
|---|---|
| Avant le déploiement | Vous devez avoir un projet en place avec l’outil de découverte et d’évaluation Azure Migrate 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 de découverte et d'évaluation Azure Migrate à un projet existant. Découvrez comment configurer l’appliance pour la découverte et l’évaluation de servers sur Hyper-V. |
| Azure Government | La visualisation des dépendances n'est pas disponible dans Azure Government. |
| Log Analytics | Azure Migrate et Modernize utilise la solution Service Map dans Azure Monitor logs pour la visualisation des dépendances. Vous associez un espace de travail Log Analytics nouveau ou 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 Azure machines virtuelles dans n’importe quelle région. Les machines virtuelles elles-mêmes 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 et Modernize est étiqueté avec la clé de 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 celles-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 Migrate et Moderniser prennent en charge les espaces de travail résidant 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 Azure machines virtuelles dans n’importe quelle région. Les machines virtuelles elles-mêmes 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 nombre commence à partir du jour où vous associez l’espace de travail Log Analytics au projet. Après 180 jours, les frais standard Log Analytics s’appliquent. L’utilisation d’une solution autre que Service Map dans l’espace de travail Log Analytics associé entraîne des frais standard pour 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 des projets que vous avez créés avant la disponibilité générale d'Azure Migrate (GA le 28 février 2018), vous pourriez encourir d’autres frais de 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 de Azure Migrate 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 Migrate et moderniser, sauf si vous supprimez le projet. Si vous le faites, la fonctionnalité de visualisation des dépendances ne fonctionne pas comme prévu. |
| Connectivité Internet | Si les serveurs ne sont pas connectés à Internet, vous devez installer la passerelle Log Analytics sur celles-ci. |
| Azure Government | L'analyse des dépendances basée sur un agent n'est pas prise en charge. |
Étapes suivantes
Préparez-vous à la découverte des serveurs fonctionnant sous Hyper-V.