Migration et modernisation : questions courantes

Cet article répond aux questions courantes sur l’outil Migration et modernisation. Si vous avez d’autres questions, consultez les ressources suivantes :

• Obtenez des informations générales sur Azure Migrate.
• Accédez aux questions courantes sur l’appliance Azure Migrate.
• Découvrez la découverte, l’évaluation et la visualisation des dépendances.
• Postez des questions sur le forum Azure Migrate.

Attention

Cet article fait référence à CentOS, une distribution Linux qui arrive en fin de vie. Examinez votre utilisation et votre planification en conséquence. Pour obtenir plus d’informations, consultez l’aide sur la fin du service CentOS.

Questions générales

Quelles sont les options de migration de l’outil Migration et modernisation ?

L’outil Migration et modernisation propose une migration sans agent et une migration par agent pour migrer vos serveurs sources et vos machines virtuelles vers Azure.

Quelle que soit l’option de migration choisie, la première étape pour migrer un serveur via l’outil Migration et modernisation consiste à démarrer la réplication pour le serveur. Ce processus effectue une réplication initiale des données de votre machine virtuelle/serveur vers Azure. Une fois la réplication initiale terminée, une réplication continue (sync-diff) est établie pour migrer les données incrémentielles vers Azure. Lorsque l’opération atteint le stade sync-diff, vous pouvez choisir de migrer à tout moment vers Azure.

Tenez compte des informations suivantes pour choisir l’option de migration à utiliser.

Les migrations sans agent ne nécessitent pas de déployer un logiciel (agent) sur les machines virtuelles/serveurs sources à migrer. L’option sans agent orchestre la réplication en s’intégrant aux fonctionnalités fournies par le fournisseur de virtualisation.

Les options de réplication sans agent sont disponibles pour les machines virtuelles VMware et les machines virtuelles Hyper-V.

Les migrations par agent requièrent d’installer le logiciel Azure Migrate (agent) sur les machines virtuelles/serveurs sources à migrer. La migration par agent n’utilise pas la plateforme de virtualisation pour la fonctionnalité de réplication. Vous pouvez l’utiliser avec n’importe quel serveur exécutant une architecture x86/x64 et une version de système d’exploitation compatible avec la méthode de réplication par agent.

Vous pouvez utiliser la migration par agent pour :

• Machines virtuelles VMware.
• Machines virtuelles Hyper-V.
• Serveurs physiques.
• Les machines virtuelles s’exécutant sur AWS.
• Les machines virtuelles s’exécutant sur GCP.
• Les machines virtuelles s’exécutant sur un autre fournisseur de virtualisation.

La migration par agent traite vos machines comme des serveurs physiques pour la migration.

Avec les machines virtuelles VMware et Hyper-V, la migration sans agent offre plus de commodité et de simplicité que la réplication par agent. Toutefois, vous pouvez envisager d’utiliser la migration par agent dans les cas d’utilisation suivants :

• Environnement dont le nombre d’opérations d’entrée/sortie par seconde (IOPS) est limité : la réplication sans agent utilise des captures instantanées et consomme des IOPS et de la bande passante de stockage. Nous vous recommandons d’utiliser la méthode de migration basée sur un agent en présence de contraintes de stockage/IOPS dans votre environnement.

• Absence de vCenter Server : si vous n’avez pas de vCenter Server, vous pouvez traiter vos machines virtuelles VMware comme des serveurs physiques et utiliser le workflow de migration par agent.

Pour en savoir plus, sélectionnez une option de migration VMware.

Quelles sont les zones géographiques prises en charge pour la migration avec Azure Migrate ?

Passez en revue les zones géographiques prises en charge pour les clouds publics et les clouds du secteur public.

Puis-je utiliser le même projet Azure Migrate pour migrer vers plusieurs régions ?

Même si vous pouvez créer des évaluations pour plusieurs régions d’un projet Azure Migrate, l’utilisation d’un projet Azure Migrate peut uniquement servir à migrer des serveurs vers une seule région Azure. Vous devez créer d’autres projets Azure Migrate pour les autres régions.

• Pour les migrations VMware sans agent, la région cible est verrouillée dès que vous activez la première réplication.
• Pour les migrations par agent (VMware, serveurs physiques et serveurs d’autres clouds), la région cible est verrouillée dès que vous sélectionnez le bouton Créer des ressources sur le portail lorsque vous configurez l’appliance de réplication.
• Pour les migrations Hyper-V sans agent, la région cible est verrouillée dès que vous sélectionnez le bouton Créer des ressources sur le portail lorsque vous configurez le fournisseur de réplication Hyper-V.

Puis-je utiliser le même projet Azure Migrate pour migrer vers plusieurs abonnements ?

Oui, vous pouvez utiliser un même projet Azure Migrate pour migrer vers plusieurs abonnements (même locataire Azure) de la même région cible. Vous pouvez sélectionner l’abonnement cible lorsque vous activez la réplication pour une machine ou un ensemble de machines.

La région cible est verrouillée :

• Après la première réplication pour les migrations VMware sans agent.
• Lors de l’installation de l’appliance de réplication pour les migrations par agent.
• Lors de l’installation du fournisseur Hyper-V pour les migrations Hyper-V sans agent.

Azure Migrate prend-il en charge Azure Resource Graph ?

Actuellement, Azure Migrate n’est pas intégré à Azure Resource Graph. Il permet l’exécution de requêtes liées à Azure Resource Graph.

Comment les données sont-elles transmises de l’environnement local à Azure ? Sont-elles chiffrées avant la transmission ?

Avec la réplication sans agent, l’appliance Azure Migrate compresse les données et les chiffre avant de les charger. Les données sont transmises via un canal de communication sécurisé sur HTTPS et utilisent TLS 1.2 ou une version ultérieure. De plus, Stockage Azure chiffre automatiquement vos données quand elles sont conservées dans le cloud (chiffrement au repos).

Puis-je utiliser le coffre Recovery Services créé par Azure Migrate pour les scénarios de récupération d'urgence ?

Nous vous déconseillons d’utiliser le coffre Recovery Services créé par Azure Migrate pour les scénarios de récupération d'urgence. En effet, cela peut faire échouer le démarrage de la réplication dans Azure Migrate.

Quelle est la différence entre les opérations de migration et de migration de test ?

La migration test permet de tester et de valider les migrations avant la migration effective. La migration test vous permet d’utiliser un environnement bac à sable dans Azure pour tester les machines virtuelles avant leur migration effective. Le réseau virtuel test spécifié permet de délimiter l’environnement bac à sable. L’opération de migration test n’engendre pas de perturbations, dans la mesure où le réseau virtuel test est suffisamment isolé. Un réseau virtuel est suffisamment isolé lorsque vous concevez les règles de connexion entrante et sortante de sorte à éviter les connexions indésirables. C’est notamment le cas lorsque vous limitez la connexion aux machines locales.

Les applications peuvent continuer à s’exécuter sur la source alors que vous menez des tests sur une copie clonée dans un environnement bac à sable isolé. Vous pouvez effectuer autant de tests que nécessaire pour valider la migration, effectuer des tests d’applications et résoudre les éventuels problèmes avant la migration proprement dite.

Existe-t-il une option de restauration pour Azure Migrate ?

Vous pouvez utiliser l’option Migration test pour valider les fonctionnalités et les performances de votre application dans Azure. Vous pouvez effectuer autant de migrations tests que nécessaire et exécuter la migration finale après avoir éprouvé l’efficacité de l’opération de migration test.

Une migration test n’a pas d’effet sur la machine locale, qui reste opérationnelle et poursuit la réplication jusqu’à ce que vous effectuiez la migration réelle. Si des erreurs surviennent lors du test d’acceptation utilisateur (UAT) de la migration test, vous pouvez choisir de reporter la migration finale et de laisser la machine virtuelle ou le serveur source fonctionner et se répliquer sur Azure. Vous pouvez retenter la migration finale une fois les erreurs résolues.

Remarque

Lorsque vous avez effectué une migration finale vers Azure et que la machine source locale a été arrêtée, vous ne pouvez plus effectuer de restauration d’Azure vers votre environnement local.

Puis-je sélectionner le réseau virtuel et le sous-réseau à utiliser pour les migrations tests ?

Vous pouvez sélectionner un réseau virtuel pour les migrations tests. Azure Migrate sélectionne automatiquement le sous-réseau selon la logique suivante :

• Si vous avez spécifié un sous-réseau cible (autre que celui par défaut) en tant qu’entrée lorsque vous avez activé la réplication, Azure Migrate donne la priorité au sous-réseau du même nom sur le réseau virtuel sélectionné pour la migration test.
• Lorsqu’il ne trouve aucun sous-réseau portant ce nom, Azure Migrate sélectionne dans l’ordre alphabétique le premier sous-réseau disponible qui ne soit pas de type passerelle/passerelle applicative/pare-feu/bastion.

Pourquoi le bouton « Tester la migration » est-il désactivé pour mon serveur ?

Le bouton Tester la migration peut être désactivé dans les scénarios suivants :

• Vous ne pouvez pas lancer de migration test tant qu’une réplication initiale n’est pas terminée pour la machine virtuelle. Le bouton Tester la migration est désactivé jusqu’à ce que le processus de réplication initiale soit terminé. Vous pouvez effectuer une migration test dès que votre machine virtuelle se trouve en phase sync-diff.
• Le bouton peut être désactivé si vous avez déjà effectué une migration test sans avoir réalisé de nettoyage de la migration test pour cette machine virtuelle. Effectuez un nettoyage de la migration de test et retentez l’opération.

Que se passe-t-il si je ne nettoie pas ma migration de test ?

La migration test simule la migration effective en créant une machine virtuelle Azure de test à partir de données répliquées. Le serveur est déployé avec une copie ponctuelle des données répliquées dans le groupe de ressources cibles (sélectionné lorsque vous avez activé la réplication) avec un suffixe -test. Les migrations tests sont destinées à valider les fonctionnalités du serveur de sorte à réduire les problèmes post-migration.

Si la migration test n’est pas nettoyée à l’issue du test, la machine virtuelle test continue à s’exécuter dans Azure, ce qui génère des frais. Pour procéder au nettoyage à l’issue d’une migration test, accédez à la vue Machines répliquées dans l’outil Migration et modernisation, puis utilisez l’action Nettoyer la migration de test sur la machine.

Comment savoir si la migration de ma machine virtuelle s’est correctement effectuée ?

Lorsque vous avez correctement migré votre machine virtuelle/serveur, vous pouvez afficher et gérer la machine virtuelle depuis le volet Machines virtuelles. Connectez-vous à la machine virtuelle migrée pour le vérifier.

Vous pouvez également examiner l’état de la tâche pour que l’opération vérifie si la migration a abouti. Si vous constatez des erreurs, résolvez-les, puis relancez l’opération de migration.

Que se passe-t-il si je n’arrête pas la réplication après la migration ?

Lorsque vous arrêtez la réplication, l’outil Migration et modernisation nettoie les disques managés de l’abonnement qui ont été créés pour la réplication.

Que se passe-t-il si je ne mets pas fin à la réplication après la migration ?

Lorsque vous sélectionnez Terminer la réplication, l’outil Migration et modernisation nettoie les disques managés de l’abonnement qui ont été créés pour la réplication. Si vous ne sélectionnez pas Terminer la migration après une migration, vous continuez d’être facturé·e pour ces disques. L’option Terminer la migration n’affecte pas les disques attachés à des machines qui ont déjà été migrées.

Comment migrer des machines UEFI vers Azure en tant que machines virtuelles de 1ère génération Azure ?

L’outil Migration et modernisation migre les machines UEFI vers Azure en tant que machines virtuelles de 2e génération Azure. Si vous souhaitez les migrer vers des machines virtuelles de 1re génération Azure, convertissez le type de démarrage en BIOS avant de commencer la réplication, puis utilisez l’outil Migration et modernisation pour migrer vers Azure.

Azure Migrate convertit-il les machines UEFI en machines BIOS et les migre-t-il vers Azure en tant que machines virtuelles de 1ère génération Azure ?

L’outil Migration et modernisation migre toutes les machines UEFI vers Azure en tant que machines virtuelles de 2e génération Azure. Nous ne prenons plus en charge la conversion de machines virtuelles UEFI en machines virtuelles BIOS. Toutes les machines BIOS sont migrées vers Azure uniquement en tant que machines virtuelles de 1re génération Azure.

Quels sont les systèmes d’exploitation pris en charge pour la migration de machines UEFI vers Azure ?

Remarque

Si une version majeure d’un système d’exploitation est prise en charge dans la migration sans agent, toutes les versions et noyaux mineurs sont automatiquement pris en charge.

Systèmes d’exploitation pris en charge pour les machines UEFI	VMware sans agent vers Azure	Hyper-V sans agent vers Azure	VMware avec agent, supports physiques et autres clouds vers Azure
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012	A	O	A
Windows 11 Professionnel, Windows 11 Entreprise	A	O	O
Windows 10 Professionnel, Windows 10 Entreprise	O	O	A
SUSE Linux Enterprise Server 15 SP1, SP2, SP3, SP4, SP5, SP6	A	O	O
SUSE Linux Enterprise Server 12 SP4	O	O	A
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS	A	O	A
RHEL 9.x, 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x	A	O	A
CentOS Stream	A	O	A
Oracle Linux 9, 8, 7.7-CI	A	O	A

Puis-je utiliser Azure Migrate pour migrer des contrôleurs de domaine Active Directory ?

L’outil Migration et modernisation est indépendant des applications et fonctionne avec la plupart d’entre elles. Lorsque vous migrez un serveur avec l’outil Migration et modernisation, toutes les applications installées sur le serveur sont migrées avec lui. Toutefois, d’autres méthodes de migration se révèlent plus adaptées à la migration de certaines applications.

Pour Active Directory, le type d’environnement peut constituer un facteur. Avec un environnement hybride dont le site local est connecté à votre environnement Azure, vous pouvez étendre votre répertoire dans Azure en ajoutant des contrôleurs de domaine supplémentaires dans Azure et en configurant la réplication d’Active Directory. Vous pouvez ajouter l’outil Migration et modernisation si :

• vous migrez vers un environnement isolé dans Azure qui a besoin de ses propres contrôleurs de domaine.
• vous testez des applications dans un environnement bac à sable.

Puis-je mettre à niveau mon système d’exploitation pendant la migration ?

L’outil Migration et modernisation permet désormais de mettre à niveau le système d’exploitation Windows pendant la migration. Actuellement, cette option n’est pas disponible avec Linux. Pour plus d’informations, consultez Mise à niveau du système d’exploitation Windows.

Ai-je besoin de VMware vCenter pour migrer des machines virtuelles VMware ?

Pour migrer des machines virtuelles VMware via la migration sans agent ou par agent VMware, vCenter Server doit gérer les hôtes ESXi sur lesquels résident les machines virtuelles. Si vous n’avez pas vCenter Server, vous pouvez migrer des machines virtuelles VMware en tant que serveurs physiques. Plus d’informations

Puis-je consolider plusieurs machines virtuelles sources en une seule machine virtuelle pendant la migration ?

Pour le moment, l’outil Migration et modernisation permet de réaliser uniquement des migrations similaires. Nous ne prenons pas en charge la consolidation des serveurs lors de la migration.

Windows Server 2008 et 2008 R2 seront-ils pris en charge dans Azure après la migration ?

Vous pouvez migrer vos serveurs Windows Server 2008 et 2008 R2 locaux vers des machines virtuelles Azure et obtenir des correctifs de sécurité étendus pendant trois ans après la fin du support, sans frais supplémentaires au coût d’exécution de la machine virtuelle. Vous pouvez utiliser l’outil Migration et modernisation pour migrer vos charges de travail Windows Server 2008 et 2008 R2.

Comment migrer Windows Server 2003 s’exécutant sous VMware/Hyper-V vers Azure ?

Le support étendu de Windows Server 2003 a pris fin le 14 juillet 2015. L’équipe du support Azure continue de vous aider à résoudre les problèmes liés à l’exécution de Windows Server 2003 sur Azure. Toutefois, ce support est limité aux problèmes qui ne nécessitent pas de dépannage ou de patchs au niveau du système d’exploitation.

Nous vous invitons à migrer vos applications vers des instances Azure exécutant une version plus récente de Windows Server afin de vous assurer de tirer tirez pleinement parti de la flexibilité et de la fiabilité du cloud Azure.

Si vous choisissez de migrer votre instance Windows Server 2003 vers Azure, vous pouvez utiliser l’outil Migration et modernisation si votre déploiement Windows Server est une machine virtuelle s’exécutant sur VMware ou Hyper-V. Pour plus d'informations, consultez Préparer vos machines Windows Server 2003 pour la migration.

Migration VMware sans agent

Comment fonctionne la migration sans agent ?

L’outil Migration et modernisation fournit des options de réplication sans agent pour la migration des machines virtuelles VMware et Hyper-V fonctionnant sous Windows ou Linux. L’outil fournit une autre option de réplication par agent pour les serveurs Windows et Linux. Cette autre option permet de migrer des serveurs physiques et des machines virtuelles x86/x64 sur des fournisseurs comme VMware, Hyper-V, AWS et GCP.

La réplication par agent nécessite d’installer un logiciel d’agent sur la machine virtuelle ou le serveur à migrer. L’option sans agent ne nécessite aucune installation de logiciel sur les machines virtuelles, gage de commodité et de simplicité.

L’option de réplication sans agent repose sur des mécanismes apportés par le fournisseur de virtualisation (VMware, Hyper-V). Avec les machines virtuelles VMware, le mécanisme de réplication sans agent utilise les instantanés VMware et la technologie Changed Block Tracking de VMware pour répliquer les données des disques de machines virtuelles. De nombreux produits de sauvegarde utilisent un mécanisme similaire. Avec les machines virtuelles Hyper-V, le mécanisme de réplication sans agent utilise les instantanés de machine virtuelle et la fonctionnalité de suivi des modifications du réplica Hyper-V pour répliquer les données des disques de machines virtuelles.

Lorsque la réplication est configurée pour une machine virtuelle, cette dernière passe d’abord par une phase de réplication initiale. Pendant la réplication initiale, le système prend un instantané de machine virtuelle et réplique une copie complète des données des disques d’instantanés sur les disques managés dans votre abonnement. Une fois la réplication initiale de la machine virtuelle terminée, le processus de réplication passe à une phase de réplication incrémentielle (réplication différentielle).

La phase de réplication incrémentielle traite les modifications de données survenues depuis le dernier cycle de réplication terminé. Ces modifications sont régulièrement répliquées et appliquées sur les disques managés par le réplica. Ce processus garantit que la réplication est synchronisée avec les modifications apportées à la machine virtuelle.

La technologie Changed Block Tracking (CBT) de VMware permet de suivre les modifications entre les cycles de réplication. Au début du cycle de réplication, le système prend un instantané de machine virtuelle et utilise la technologie Changed Block Tracking pour compiler les modifications entre l’instantané actuel et le dernier instantané répliqué avec succès. Ainsi, seules les données modifiées depuis le dernier cycle de réplication doivent être répliquées pour garantir que la réplication de la machine virtuelle est bien synchronisée.

À la fin de chaque cycle de réplication, l’instantané est publié et consolidé pour la machine virtuelle. De même, avec les machines virtuelles Hyper-V, le moteur de suivi des modifications du réplica Hyper-V permet de suivre les modifications entre les cycles de réplication consécutifs.

Lorsque vous effectuez l’opération Migrate sur une machine virtuelle de réplication, vous pouvez arrêter la machine virtuelle locale et d’effectuer une réplication incrémentielle finale pour garantir l’absence de perte de données. Lorsque la réplication est effectuée, les disques managés par le réplica qui correspondent à la machine virtuelle sont utilisés pour créer la machine virtuelle dans Azure.

Pour commencer, reportez-vous aux didacticiels Migration VMware sans agent et Migration Hyper-V sans agent.

Comment évaluer la bande passante requise pour mes migrations ?

Plusieurs facteurs peuvent affecter le volume de bande passante dont vous avez besoin pour répliquer des données sur Azure. Les besoins en bande passante dépendent de la vitesse à laquelle l’appliance Azure Migrate locale peut lire et répliquer les données sur Azure. La réplication comporte deux phases : la réplication initiale et la réplication différentielle.

Lorsque la réplication commence pour une machine virtuelle, un premier cycle de réplication se produit, dans lequel des copies complètes des disques sont répliquées. Une fois la réplication initiale terminée, le système planifie régulièrement des cycles de réplication incrémentielle (cycles différentiels) afin de transférer les modifications apportées depuis le cycle de réplication précédent.

Vous pouvez définir les besoins en bande passante en fonction des éléments suivants :

• Volume de données à déplacer dans la vague.
• Heure à laquelle allouer le processus de réplication initial.

Dans l’idéal, prévoyez de terminer la réplication initiale au moins 3 à 4 jours avant la fenêtre de migration effective. Cette chronologie vous donne suffisamment de temps pour effectuer une migration test avant la fenêtre effective et limiter au maximum les temps d’arrêt durant cette dernière.

Pour estimer la bande passante ou le temps nécessaire pour la migration de machines virtuelles VMware sans agent, utilisez la formule suivante :

• Durée d’exécution de la réplication initiale = {taille des disques (ou taille utilisée si elle est disponible) * 0,7 (en supposant une compression moyenne de 30 % – estimation prudente)}/bande passante disponible pour la réplication.

Comment faire pour limiter la réplication lorsque j’utilise l’appliance Azure Migrate pour effectuer une réplication VMware sans agent ?

Vous pouvez limiter la réplication avec NetQosPolicy. Cette limitation s’applique uniquement aux connexions sortantes de l’appliance Azure Migrate.

Par exemple, la valeur AppNamePrefix avec utiliser avec NetQosPolicy est GatewayWindowsService.exe. Vous pouvez créer une stratégie sur l’appliance Azure Migrate pour limiter le trafic de réplication de l’appliance en créant une stratégie telle que celle-ci :

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Pour augmenter ou réduire la bande passante de réplication en fonction d’un programme, utilisez les tâches planifiées Windows pour l’adapter à vos besoins. La où une tâche peut diminuer la bande passante, une autre tâche peut l’augmenter.

Remarque

Vous devez créer la NetQosPolicy précédemment mentionnée avant d’exécuter les commandes suivantes.

#Replace with an account that's part of the local Administrators group
$User = "localVmName\userName"

#Set the task names
$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"

#Create a directory to host PowerShell scaling scripts
if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
 New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}

#Set your minimum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 10MB'
$ThrottleBandwidthScript = "C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"

#Set your maximum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 1000MB'
$IncreaseBandwidthScript = "C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"

#Timezone set on the Azure Migrate Appliance (VM) is used; change the frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm

#Setting the task action to execute the scripts
$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $IncreaseBandwidthScript"

#Creating the scheduled tasks
Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger $ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger $IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -RunLevel Highest -Force

Dans quelle mesure le taux de variation affecte-t-il la réplication sans agent ?

La réplication sans agent opérant un repli des données, le modèle de variation est plus important que le taux de variation. Quand un fichier est écrit à plusieurs reprises, le taux n’a pas un impact important. Toutefois, un modèle dans lequel un secteur sur deux est écrit entraîne une variation élevée lors du cycle suivant. Comme vous réduisez au minimum la quantité de données que vous transférez, vous autorisez la réduction des données autant que possible avant de programmer le cycle suivant.

À quelle fréquence un cycle de réplication est-il planifié ?

La formule pour programmer le prochain cycle de réplication est (durée du cycle précédent/2) ou une heure (la valeur la plus élevée s’applique).

Par exemple, si une machine virtuelle prend quatre heures pour un cycle delta, le cycle suivant est planifié en deux heures, et non dans l’heure suivante. Le processus diffère immédiatement après la réplication initiale, quand le premier cycle delta est planifié immédiatement.

J’ai déployé deux appliances (ou plus) pour découvrir des machines virtuelles dans vCenter Server. Cependant, lorsque j’essaie de migrer les machines virtuelles, je ne vois que celles qui correspondent à l’une des appliances.

Si vous avez configuré plusieurs appliances, il ne doit exister aucun chevauchement entre les machines virtuelles sur les comptes vCenter fournis. Une découverte avec un tel chevauchement n’est pas un scénario pris en charge.

Dans quelle mesure la réplication sans agent affecte les serveurs VMware ?

La réplication sans agent a un impact sur les performances du serveur VMware vCenter et des hôtes VMware ESXi. La réplication sans agent utilisant des instantanés, elle consomme des IOPS en matière de stockage. Une bande passante de stockage IOPS est donc requise. Nous vous déconseillons d’utiliser la réplication sans agent si votre environnement est associé à des contraintes de stockage ou d’IOPS.

Les machines virtuelles hors tension peuvent-elles être répliquées ?

La réplication des machines virtuelles VMware lorsqu’elles sont désactivées est possible (uniquement avec l’option sans agent).

Important

Nous ne pouvons pas garantir le bon démarrage d’une machine virtuelle hors tension, car nous ne pouvons pas vérifier son état de fonctionnement avant la réplication.

Par conséquent, nous vous invitons vivement à exécuter une migration test pour garantir la bonne exécution du processus lors de la migration effective. Cette méthode peut s’avérer utile lorsque le processus de réplication initial est long ou que les machines virtuelles enregistrent une forte activité (serveurs de base de données ou autres charges de travail gourmandes en disque, par exemple).

Puis-je utiliser Azure Migrate pour migrer mes applications web vers Azure App Service ?

Vous pouvez effectuer une migration sans agent à grande échelle d’applications web ASP.NET s’exécutant sur des serveurs web IIS qui sont hébergés sur un système d’exploitation Windows dans un environnement VMware. Plus d’informations

Migration basée sur agent

Comment puis-je migrer mes instances AWS EC2 vers Azure ?

Consultez Découvrir, évaluer et migrer des machines virtuelles Amazon Web Services (AWS) vers Azure.

Comment fonctionne la migration basée sur agent ?

L’outil Migration et modernisation fournit une option de migration par agent pour migrer des serveurs Windows et Linux s’exécutant sur des serveurs physiques ou en tant que machines virtuelles x86/x64 sur des fournisseurs comme VMware, Hyper-V, AWS et GCP.

La méthode de migration par agents utilise un logiciel d’agent pour répliquer les données du serveur sur Azure. Vous devez installer le logiciel sur le serveur à migrer. Le processus de réplication utilise une architecture de déchargement dans laquelle l’agent relaie les données de réplication vers un serveur de réplication dédié, appelé appliance de réplication ou serveur de configuration (ou vers un serveur de traitement en scale-out). Pour plus d’informations, consultez Architecture de la migration par agent.

Remarque

L’appliance de réplication est différente de l’appliance de détection Azure Migrate et doit être installée sur une machine distincte/dédiée.

Où dois-je installer l’appliance de réplication pour les migrations basées sur des agents ?

Vous devez installer l’appliance de réplication sur une machine dédiée. Vous ne devez pas installer l’appliance de réplication sur une machine source à répliquer ni sur l’appliance Azure Migrate utilisée pour la découverte et l’évaluation. Pour plus d’informations, consultez Migrer des machines en tant que serveurs physiques vers Azure.

Puis-je migrer des machines virtuelles AWS exécutant le système d’exploitation Amazon Linux ?

Vous ne pouvez pas migrer de machines virtuelles qui exécutent Amazon Linux en l’état, car ce système d’exploitation est uniquement compatible avec AWS.

Pour migrer des charges de travail exécutées sur Amazon Linux, vous pouvez faire tourner une machine virtuelle CentOS/RHEL dans Azure. Vous pouvez ensuite migrer la charge de travail exécutée sur la machine AWS Linux via une approche de migration de charge de travail appropriée. Pour certaines charges de travail, il peut exister des outils spécifiques qui facilitent la migration pour les bases de données ou les outils de déploiement pour serveurs web, par exemple.

Comment évaluer la bande passante requise pour mes migrations ?

Plusieurs facteurs peuvent affecter le volume de bande passante dont vous avez besoin pour répliquer des données sur Azure. Les besoins en bande passante dépendent de la vitesse à laquelle l’appliance Azure Migrate locale peut lire et répliquer les données sur Azure. La réplication comporte deux phases : la réplication initiale et la réplication différentielle.

Lorsque la réplication commence pour une machine virtuelle, un premier cycle de réplication se produit, dans lequel des copies complètes des disques sont répliquées. Une fois la réplication initiale terminée, le système planifie régulièrement des cycles de réplication incrémentielle (cycles différentiels) afin de transférer les modifications apportées depuis le cycle de réplication précédent.

Pour une méthode de réplication par agent, le planificateur de déploiement Azure Site Recovery peut aider à profiler l’environnement en fonction de l’évolution des données et à prédire les besoins en bande passante. Pour plus d’informations, consultez Planifier un déploiement VMware.

Migration Hyper-V sans agent

Comment fonctionne la migration sans agent ?

L’outil Migration et modernisation fournit des options de réplication sans agent pour la migration des machines virtuelles VMware et Hyper-V fonctionnant sous Windows ou Linux. L’outil fournit une autre option de réplication par agent pour les serveurs Windows et Linux. Cette autre option permet de migrer des serveurs physiques et des machines virtuelles x86/x64 sur des fournisseurs comme VMware, Hyper-V, AWS et GCP.

L’option de réplication par agent nécessite d’installer un logiciel d’agent sur la machine virtuelle ou le serveur à migrer. L’option sans agent ne nécessite aucune installation de logiciel sur les machines virtuelles, gage de commodité et de simplicité.

L’option de réplication sans agent fonctionne à l’aide de mécanismes fournis par le fournisseur de virtualisation (VMware ou Hyper-V). Avec les machines virtuelles Hyper-V, le mécanisme de réplication sans agent utilise les instantanés de machine virtuelle et la fonctionnalité de suivi des modifications du réplica Hyper-V pour répliquer les données des disques de machines virtuelles.

Lorsque la réplication est configurée pour une machine virtuelle, cette dernière passe d’abord par une phase de réplication initiale. Pendant la réplication initiale, le système prend un instantané de machine virtuelle et réplique une copie complète des données des disques d’instantanés sur les disques managés dans votre abonnement. Une fois la réplication initiale de la machine virtuelle terminée, le processus de réplication passe à une phase de réplication incrémentielle (réplication différentielle).

La phase de réplication incrémentielle traite les modifications de données survenues depuis le dernier cycle de réplication terminé. Ces modifications sont régulièrement répliquées et appliquées sur les disques managés par le réplica. Ce processus garantit que la réplication est synchronisée avec les modifications apportées à la machine virtuelle.

La technologie Changed Block Tracking (CBT) de VMware permet de suivre les modifications entre les cycles de réplication. Au début du cycle de réplication, le système prend un instantané de machine virtuelle et utilise la technologie Changed Block Tracking pour obtenir les modifications entre l’instantané actuel et le dernier instantané répliqué avec succès. Ainsi, seules les données modifiées depuis le dernier cycle de réplication doivent être répliquées pour garantir que la réplication de la machine virtuelle est bien synchronisée.

À la fin de chaque cycle de réplication, l’instantané est publié et consolidé pour la machine virtuelle. De même, avec les machines virtuelles Hyper-V, le moteur de suivi des modifications du réplica Hyper-V permet de suivre les modifications entre les cycles de réplication consécutifs.

Lorsque vous effectuez l’opération Migrate sur une machine virtuelle de réplication, vous pouvez arrêter la machine virtuelle locale et d’effectuer une réplication incrémentielle finale pour garantir l’absence de perte de données. Les disques managés par le réplica qui correspondent à la machine virtuelle sont utilisés pour créer la machine virtuelle dans Azure.

Pour commencer, consultez le didacticiel Migration sans agent Hyper-V.

Comment évaluer la bande passante requise pour mes migrations ?

Plusieurs facteurs peuvent affecter le volume de bande passante dont vous avez besoin pour répliquer des données sur Azure. Les besoins en bande passante dépendent de la vitesse à laquelle l’appliance Azure Migrate locale peut lire et répliquer les données sur Azure. La réplication comporte deux phases : la réplication initiale et la réplication différentielle.

Lorsque la réplication commence pour une machine virtuelle, un premier cycle de réplication se produit, dans lequel des copies complètes des disques sont répliquées. Une fois la réplication initiale terminée, le système planifie régulièrement des cycles de réplication incrémentielle (cycles différentiels) afin de transférer les modifications apportées depuis le cycle de réplication précédent.

Vous pouvez définir les besoins en bande passante en fonction des éléments suivants :

• Volume de données à déplacer dans la vague.
• Heure à laquelle allouer le processus de réplication initial.

Dans l’idéal, prévoyez de terminer la réplication initiale au moins 3 à 4 jours avant la fenêtre de migration effective. Cette chronologie vous donne suffisamment de temps pour effectuer une migration test avant la fenêtre effective et limiter au maximum les temps d’arrêt durant cette dernière.

Contenu connexe

• En savoir plus sur la migration des machines virtuelles VMware, des machines virtuelles Hyper-V et des serveurs physiques.