Migration et modernisation : questions courantes

  • Article

Attention

Cet article fait référence à CentOS, une distribution Linux proche de l’état EOL (End Of Life). Faites le point sur votre utilisation afin de vous organiser en conséquence. Pour plus d’informations, consultez les Conseils sur la fin de vie CentOS.

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

Questions générales

Quelles sont les options de migration dans Migration et modernisation ?

L’outil Migration et modernisation offre deux options pour la migration de vos serveurs source et de vos machines virtuelles vers Azure : la migration sans agent et la migration basée sur un agent.

Quelle que soit l’option de migration choisie, la première étape pour migrer un serveur à l’aide de l’outil Migration et modernisation consiste à démarrer la réplication pour le serveur. Cela 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 continue) est établie pour migrer des données incrémentielles vers Azure. Une fois que l’opération atteint le stade sync-diff, vous pouvez choisir de migrer vers Azure à tout moment.

Voici quelques considérations à prendre en compte lorsque vous décidez de l’option de migration.

Les migrations sans agent ne nécessitent aucun déploiement de logiciels (agents) 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 basées sur des agents requièrent l’installation du logiciel Azure Migrate (agents) sur les machines virtuelles/serveurs sources à migrer. L’option basée sur un agent ne repose pas sur la plateforme de virtualisation pour la fonctionnalité de réplication. Par conséquent, vous pouvez l’utiliser avec n’importe quel serveur exécutant une architecture x86/x64 et une version de système d’exploitation prise en charge par la méthode de réplication basée sur agent.

L’option de migration basée sur des agents peut être utilisée pour les machines virtuelles VMware, les machines virtuelles Hyper-V, les serveurs physiques, les machines virtuelles fonctionnant sous AWS, les machines virtuelles fonctionnant sous GCP ou les machines virtuelles fonctionnant sous un autre fournisseur de virtualisation. La migration basée sur des agents traite vos machines comme des serveurs physiques pour la migration.

Bien que la migration sans agent offre plus de commodité et de simplicité sur les options de réplication basée sur des agents pour les scénarios pris en charge (VMware et Hyper-V), vous pouvez envisager d’utiliser le scénario basé sur un agent pour les cas d’utilisation suivants :

  • Environnement contraint en IOPS : la réplication sans agent utilise des captures instantanées et consomme des IOPS/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.
  • 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 basé sur l’agent.

Pour plus d’informations, consultez cet article pour comparer les options de migration des migrations 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 gouvernementaux.

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

Bien que vous puissiez créer des évaluations pour plusieurs régions dans un projet Azure Migrate, un projet Azure Migrate peut uniquement être utilisé pour migrer des serveurs vers une seule région Azure. Vous pouvez créer des projets Azure Migrate supplémentaires pour chaque région vers laquelle vous devez migrer.

  • Pour les migrations VMware sans agent, la région cible est verrouillée une fois que vous activez la première réplication.
  • Pour les migrations basées sur un agent (VMware, serveurs physiques et serveurs d’autres clouds), la région cible est verrouillée une fois que l’utilisateur sélectionne le bouton « Créer des ressources » sur le portail lors de la configuration de l’appliance de réplication.
  • Pour les migrations Hyper-V sans agent, la région cible est verrouillée une fois que l’utilisateur sélectionne le bouton « Créer des ressources » sur le portail lors de la configuration du fournisseur de réplication Hyper-V.

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

Oui, vous pouvez migrer vers plusieurs abonnements (même locataire Azure) de la même région cible pour un projet Azure Migrate. Vous pouvez sélectionner l’abonnement cible lors de l’activation de 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 et pendant l’installation de l’appliance de réplication et du fournisseur Hyper-V pour les migrations basées sur des agents et les migrations Hyper-V sans agent, respectivement.

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

Dans le cas de la réplication sans agent, l’appliance Azure Migrate compresse les données et les chiffre avant le chargement. 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, le Stockage Azure chiffre automatiquement vos données quand elles sont conservées dans le cloud (chiffrement au repos).

Est-ce que je peux utiliser le coffre Recovery Services créé par Azure Migrate pour les scénarios de reprise d’activité ?

Nous vous déconseillons d’utiliser le coffre Recovery Services créé par Azure Migrate pour les scénarios de reprise d’activité. Cela peut entraîner des échecs de 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 de test permet de tester et de valider des migrations avant la migration proprement dite. La migration de test vous permet d’utiliser un environnement bac à sable dans Azure pour tester les machines virtuelles avant leur réelle migration. L’environnement bac à sable est délimité par un réseau virtuel de test que vous spécifiez. L’opération de migration de test n’engendre pas de perturbations, dans la mesure où le réseau virtuel de test est suffisamment isolé. Ici, le réseau virtuel isolé signifie que les règles de connexion entrante et sortante sont conçues pour éviter toute connexion indésirable. Par exemple, la connexion aux ordinateurs locaux est limitée.

Les applications peuvent continuer à s’exécuter à la source tout en vous laissant effectuer 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.

Capture d’écran montrant la différence entre la migration test et la migration réelle.

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

Vous pouvez utiliser l’option Migration de test pour valider les fonctionnalités et les performances de votre application dans Azure. Vous pouvez effectuer un nombre quelconque de migrations de test et exécuter la migration finale après avoir établi la confiance dans le cadre de l’opération de migration de test. Une migration de test n’a pas d’effet sur la machine locale, qui reste opérationnelle et continue la réplication jusqu’à ce que vous effectuiez la migration réelle. Si des erreurs se sont produites pendant l’UAT de migration de test, vous pouvez choisir de reporter la migration finale et de laisser votre machine virtuelle/serveur source fonctionner et se répliquer sur Azure. Vous pouvez retenter la migration finale une fois que vous avez résolu les erreurs. Remarque : Une fois que vous avez effectué une migration finale vers Azure et que la machine source locale a été arrêtée, vous ne pouvez pas 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 de test ?

Vous pouvez sélectionner un réseau virtuel pour les migrations de test. Le sous-réseau est automatiquement sélectionné selon la logique suivante :

  • Si un sous-réseau cible (autre que celui par défaut) a été spécifié en entrée lors de l’activation de la réplication, alors Azure Migrate donne la priorité à l’utilisation d’un sous-réseau portant le même nom dans le réseau virtuel sélectionné pour la migration de test.
  • Si le sous-réseau portant le même nom est introuvable, Azure Migrate sélectionne le premier sous-réseau disponible dans l’ordre alphabétique qui n’est pas un sous-réseau de type Passerelle/Application Gateway/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 commencer une migration de test tant qu’une réplication initiale n’a pas été effectuée pour la machine virtuelle. Le bouton Tester la migration sera désactivé jusqu’à ce que le processus de réplication initiale soit terminé. Vous pouvez effectuer un test de migration une fois que votre machine virtuelle est dans une phase sync-diff.
  • Le bouton peut être désactivé si une migration de test a déjà été effectuée, mais qu’aucun nettoyage de la migration de test n’a été effectué 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 de test simule la migration réelle en créant une machine virtuelle Azure de test à l’aide de données répliquées. Le serveur sera déployé avec une copie ponctuelle des données répliquées dans le groupe de ressources cible (sélectionné pendant l’activation de la réplication) avec un suffixe « -test ». Les migrations de test sont destinées à valider les fonctionnalités du serveur afin de minimiser les problèmes post-migration. Si la migration de test n’est pas nettoyée après le test, la machine virtuelle de test continue de s’exécuter dans Azure et entraînera des frais. Pour nettoyer après une migration de test, accédez à la vue des machines répliquées dans l’outil Migration et modernisation, puis utilisez l’action « Nettoyer la migration de test » sur la machine.

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

Une fois que vous avez correctement migré votre machine virtuelle/serveur, vous pouvez afficher et gérer la machine virtuelle à partir de la page 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 recommencez 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 a été créé pour la réplication.

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

Lorsque vous mettez fin à 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 continuerez à être facturé 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 1ère 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 en tant que machines virtuelles de 1re génération Azure uniquement.

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

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 2019, 2016, 2012 R2, 2012 O O O
Windows 10 Professionnel, Windows 10 Entreprise O O O
SUSE Linux Enterprise Server 15 SP1 O O O
SUSE Linux Enterprise Server 12 SP4 O O O
Ubuntu Server 16.04, 18.04, 19.04, 19.10 O O O
RHEL 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x O O O
CentOS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 6.x O O O
Oracle Linux 7.7, 7.7-CI O O O

Puis-je migrer des contrôleurs de domaine Active Directory à l’aide d’Azure Migrate ?

L’outil Migration et modernisation est indépendant des applications et fonctionne pour la plupart d’entre elles. Lorsque vous migrez un serveur à l’aide de 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, différente de Migration et modernisation, peuvent être mieux adaptées à la migration de certaines applications. Pour Active Directory, si des environnements hybrides où 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. Si vous effectuez une migration vers un environnement isolé dans Azure nécessitant ses propres contrôleurs de domaine (ou si vous testez des applications dans un environnement de bac à sable), vous pouvez migrer des serveurs à l’aide de l’outil Migration et modernisation.

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

L’outil Migration et modernisation prend uniquement en charge les migrations similaires pour le moment. L’outil ne prend pas en charge la mise à niveau de la version du système d’exploitation pendant la migration. La machine migrée aura le même système d’exploitation que la machine source.

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

Pour migrer des machines virtuelles VMware à l’aide d’une migration sans agent ou basée sur un agent VMware, les hôtes ESXi sur lesquels résident les machines virtuelles doivent être managés par vCenter Server. Si vous n’avez pas vCenter Server, vous pouvez migrer des machines virtuelles VMware en les migrant en tant que serveurs physiques. Plus d’informations

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

Les capacités de Migration et modernisation prennent actuellement en charge les migrations similaires. Nous ne prenons pas en charge la consolidation des serveurs ni la mise à niveau du système d’exploitation dans le cadre 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-delà du 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 qui concernent 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. La migration de vos applications vers des instances Azure exécutant une version plus récente de Windows Server est l’approche recommandée pour garantir que vous tirez pleinement parti de la flexibilité et de la fiabilité du cloud Azure.

Toutefois, si vous choisissez de migrer votre instance Windows Server 2003 vers Azure, vous pouvez utiliser l’outil Migration et modernisation si votre serveur Windows est une machine virtuelle fonctionnant sous VMware ou Hyper-V. Consultez cet article pour 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 des machines virtuelles Hyper-V fonctionnant sous Windows ou Linux. L’outil fournit également une option de réplication supplémentaire basée sur des agents pour les serveurs Windows et Linux qui peut être utilisée pour migrer des serveurs physiques, ainsi que des machines virtuelles x86/x64 sur VMware, Hyper-V, AWS, GCP, etc. L’option de réplication basée sur des agents nécessite l’installation d’un logiciel agent sur le serveur/la machine virtuelle en cours de migration, tandis que dans l’option sans agent, aucun logiciel n’a besoin d’être installé sur les machines virtuelles elles-mêmes, ce qui offre davantage de commodité et de simplicité par rapport à l’option de réplication basée sur des agents.

L’option de réplication sans agent fonctionne à l’aide de mécanismes fournis par le fournisseur de virtualisation (VMware, Hyper-V). Dans le cas des machines virtuelles VMware, le mécanisme de réplication sans agent utilise des instantanés VMware et la technologie Changed Block Tracking de VMware pour répliquer des données à partir de disques de machines virtuelles. Ce mécanisme est similaire à celui utilisé par de nombreux produits de sauvegarde. Dans le cas des machines virtuelles Hyper-V, le mécanisme de réplication sans agent utilise des instantanés de machine virtuelle et la capacité de suivi des modifications du réplica Hyper-V pour répliquer des données à partir de disques de machines virtuelles.

Lorsque la réplication est configurée pour une machine virtuelle, elle passe tout d’abord par une phase de réplication initiale. Pendant la réplication initiale, un instantané de machine virtuelle est pris et une copie complète des données des disques d’instantanés est répliquée 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). Dans la phase de réplication incrémentielle, les modifications de données qui se sont produites depuis le dernier cycle de réplication sont périodiquement répliquées et appliquées aux disques managés du réplica, ce qui permet de synchroniser la réplication avec les modifications apportées à la machine virtuelle. Dans le cas des machines virtuelles VMware, la technologie Changed Block Tracking de VMware est utilisée pour effectuer le suivi des modifications entre les cycles de réplication. Au début du cycle de réplication, un instantané de machine virtuelle est pris et Changed Block Tracking est utilisée pour obtenir les modifications entre l’instantané actuel et le dernier instantané répliqué avec succès. Ainsi, seules les données qui ont été modifiées depuis le dernier cycle de réplication doivent être répliquées pour maintenir la réplication de la machine virtuelle synchronisée. À la fin de chaque cycle de réplication, l’instantané est publié, et la consolidation de l’instantané est effectuée pour la machine virtuelle. De même, dans le cas des machines virtuelles Hyper-V, le moteur de suivi des modifications du réplica Hyper-V est utilisé pour effectuer le suivi des modifications entre les cycles de réplication consécutifs.

Lorsque vous effectuez l’opération de migration sur une machine virtuelle de réplication, vous avez la possibilité d’arrêter la machine virtuelle locale et d’effectuer une réplication incrémentielle finale pour garantir l’absence de perte de données. Lors de l’exécution de la migration, les disques managés de réplica correspondant à la machine virtuelle sont utilisés pour créer la machine virtuelle dans Azure.

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

Comment évaluer la bande passante requise pour mes migrations ?

La bande passante requise pour la réplication des données sur Azure dépend d’une série de facteurs et 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, des cycles de réplication incrémentielle (cycles différentiels) sont planifiés régulièrement pour transférer les modifications qui se sont produites depuis le cycle de réplication précédent.

Vous pouvez déterminer les besoins en bande passante en fonction du volume de données à déplacer au niveau de la vague et de la durée d’exécution de la réplication initiale que vous souhaitez : idéalement, la réplication initiale doit être terminée au moins 3 à 4 jours avant la fenêtre de migration réelle pour vous donner suffisamment de temps pour effectuer une migration test avant la fenêtre réelle et pour réduire au minimum les temps d’arrêt pendant la fenêtre.

Vous pouvez estimer la bande passante ou le temps nécessaire pour la migration de machines virtuelles VMware sans agent à l’aide de 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 lors de l’utilisation de l’appliance Azure Migrate pour une réplication VMware sans agent ?

Vous pouvez limiter l’utilisation de NetQosPolicy. Notez que cette limitation s’applique uniquement aux connexions sortant de l’appliance Azure Migrate. Par exemple :

Le préfixe AppNamePrefix à utiliser dans 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

Afin d’augmenter et de réduire la bande passante de réplication selon une planification, vous pouvez tirer parti des tâches planifiées Windows pour adapter la bande passante en fonction des besoins. Une tâche sera utilisée pour réduire la bande passante et une autre servira à l’augmenter. Remarque : Vous devez créer la NetQosPolicy, décrite ci-dessus, avant d’exécuter les commandes ci-dessous.

#Replace with an account 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) will be 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 nous réduisons au minimum la quantité de données que nous transférons, nous autorisons la réduction des données autant que possible avant de planifier le cycle suivant.

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

La formule pour planifier le prochain cycle de réplication est (durée du cycle précédente / 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 plusieurs appliances sont configurées, il est indispensable qu’il n’y ait pas de 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 vous avez des contraintes de stockage ou d’IOPS dans votre environnement.

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 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 l’article pour découvrir, évaluer et migrer vos instances AWS EC2 vers Azure.

Comment fonctionne la migration basée sur agent ?

En plus des options de migration sans agent pour les machines virtuelles VMware et Hyper-V, l’outil Migration et modernisation fournit une option de migration basée sur des agents pour migrer les serveurs Windows et Linux exécutés sur des serveurs physiques ou fonctionnant en tant que machines virtuelles x86/x64 sur VMware, Hyper-V, AWS, Google Cloud Platform, etc.

La méthode de migration basée sur des agents utilise le logiciel de l’agent installé sur le serveur à migrer pour répliquer les données du serveur sur Azure. 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). En savoir plus sur le fonctionnement de l’option de migration basée sur des agents.

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 ?

L’appliance de réplication doit être installée sur un ordinateur dédié. L’appliance de réplication ne doit pas être installée sur une machine source que vous souhaitez répliquer, ou sur l’appliance Azure Migrate (utilisée pour la découverte et l’évaluation) que vous avez peut-être déjà installée. Suivez notre tutoriel pour plus d’informations.

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

Il n’est pas possible de migrer en l’état des machines virtuelles qui exécutent Amazon Linux, car ce système d’exploitation n’est pris en charge que sur AWS. Pour migrer des charges de travail s’exécutant sur Amazon Linux, vous pouvez créer une machine virtuelle CentOS/RHEL dans Azure et migrer la charge de travail s’exécutant sur la machine Linux AWS suivant une approche appropriée de migration des charges de travail. Pour certaines charges de travail, il peut exister des outils propres à la charge de travail qui facilitent la migration, par exemple pour les bases de données ou les outils de déploiement dans le cas de serveurs web.

Comment évaluer la bande passante requise pour mes migrations ?

La bande passante requise pour la réplication des données sur Azure dépend d’une série de facteurs et 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, des cycles de réplication incrémentielle (cycles différentiels) sont planifiés régulièrement pour transférer les modifications qui se sont produites depuis le cycle de réplication précédent.

Pour une méthode de réplication basée sur un agent, le planificateur de déploiement peut aider à profiler l’environnement en fonction de l’évolution des données et à prédire les besoins nécessaires en bande passante. Pour plus d’informations, consultez cet article

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 des machines virtuelles Hyper-V fonctionnant sous Windows ou Linux. L’outil fournit également une option de réplication supplémentaire basée sur des agents pour les serveurs Windows et Linux qui peut être utilisée pour migrer des serveurs physiques, ainsi que des machines virtuelles x86/x64 sur VMware, Hyper-V, AWS, GCP, etc. L’option de réplication basée sur des agents nécessite l’installation d’un logiciel agent sur le serveur/la machine virtuelle en cours de migration, tandis que dans l’option sans agent, aucun logiciel n’a besoin d’être installé sur les machines virtuelles elles-mêmes, ce qui offre davantage de commodité et de simplicité par rapport à l’option de réplication basée sur des agents.

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

Lorsque la réplication est configurée pour une machine virtuelle, elle passe tout d’abord par une phase de réplication initiale. Pendant la réplication initiale, un instantané de machine virtuelle est pris et une copie complète des données des disques d’instantanés est répliquée 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). Dans la phase de réplication incrémentielle, les modifications de données qui se sont produites depuis le dernier cycle de réplication sont périodiquement répliquées et appliquées aux disques managés du réplica, ce qui permet de synchroniser la réplication avec les modifications apportées à la machine virtuelle. Dans le cas des machines virtuelles VMware, la technologie Changed Block Tracking de VMware est utilisée pour effectuer le suivi des modifications entre les cycles de réplication. Au début du cycle de réplication, un instantané de machine virtuelle est pris et Changed Block Tracking est utilisée pour obtenir les modifications entre l’instantané actuel et le dernier instantané répliqué avec succès. Ainsi, seules les données qui ont été modifiées depuis le dernier cycle de réplication doivent être répliquées pour maintenir la réplication de la machine virtuelle synchronisée. À la fin de chaque cycle de réplication, l’instantané est publié, et la consolidation de l’instantané est effectuée pour la machine virtuelle. De même, dans le cas des machines virtuelles Hyper-V, le moteur de suivi des modifications du réplica Hyper-V est utilisé pour effectuer le suivi des modifications entre les cycles de réplication consécutifs.

Lorsque vous effectuez l’opération de migration sur une machine virtuelle de réplication, vous avez la possibilité d’arrêter la machine virtuelle locale et d’effectuer une réplication incrémentielle finale pour garantir l’absence de perte de données. Lors de l’exécution de la migration, les disques managés de réplica correspondant à la machine virtuelle sont utilisés pour créer la machine virtuelle dans Azure.

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

Comment évaluer la bande passante requise pour mes migrations ?

La bande passante requise pour la réplication des données sur Azure dépend d’une série de facteurs et 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, des cycles de réplication incrémentielle (cycles différentiels) sont planifiés régulièrement pour transférer les modifications qui se sont produites depuis le cycle de réplication précédent.

Vous pouvez déterminer les besoins en bande passante en fonction du volume de données à déplacer au niveau de la vague et de la durée d’exécution de la réplication initiale que vous souhaitez : idéalement, la réplication initiale doit être terminée au moins 3 à 4 jours avant la fenêtre de migration réelle pour vous donner suffisamment de temps pour effectuer une migration test avant la fenêtre réelle et pour réduire au minimum les temps d’arrêt pendant la fenêtre.

Étapes suivantes

Consultez la vue d’ensemble d’Azure Migrate.