Rehéberger avec Azure Migrate (Lift and Shift)

Le réhébergement, généralement appelé transfert sans modification, est une stratégie de migration qui consiste à déplacer une VM du site local vers Azure sans modifier le système d’exploitation, les fichiers binaires de l’application ni les données. L’outil Migration et modernisation d’Azure Migrate (anciennement Server Migration) automatise ce processus en répliquant les données des disques vers Azure, puis en effectuant la bascule avec un temps d’arrêt minimal. Le transfert sans modification convient particulièrement aux applications difficiles à remanier ou soumises à des délais de migration serrés.

Avant de commencer la réplication, vous devez : terminer la découverte et l’évaluation afin de disposer de recommandations de références de VM cibles, créer les ressources Azure cibles (groupe de ressources, réseau virtuel et sous-réseau), et vérifier que l’appliance Azure Migrate est saine. Pour les sources VMware, l’appliance doit disposer d’autorisations de lecture sur vCenter et la VM invitée doit être accessible sur le réseau depuis l’appliance. Téléchargez et inscrivez le logiciel fournisseur de réplication si vous migrez depuis Hyper-V ou des serveurs physiques.

La réplication copie toutes les données des disques de la VM source vers un compte de stockage de cache géré par Azure, puis prépare les données de manière asynchrone dans Azure. Dans le portail Azure Migrate, accédez à Répliquer, sélectionnez vos VM sources, associez-les à la référence de VM Azure recommandée et choisissez le réseau virtuel cible. La durée de la réplication initiale dépend de la taille des disques et de la bande passante : la synchronisation initiale d’un disque de 100 Go via une connexion à 100 Mbit/s prend environ 2 heures.

Une fois l’image initiale du disque copiée, Azure Migrate passe à la réplication différentielle : seuls les blocs de disque modifiés sont envoyés, ce qui maintient la copie Azure presque en temps réel avec la source sur site. La VM continue de fonctionner sur site pendant cette phase. Vous pouvez surveiller l’état de la réplication, le retard du RPO et les taux de transfert des données dans le portail. La réplication différentielle se stabilise généralement avec un retard de quelques minutes seulement dans les 24 heures suivant la fin de la synchronisation initiale.

Avant de basculer le trafic de production, exécutez toujours une migration de test. Celle-ci démarre la VM répliquée dans Azure sur un réseau virtuel de test isolé, sans connectivité aux systèmes de production. Vous vérifiez que le système d’exploitation démarre, que les services se lancent et que les fonctionnalités de l’application fonctionnent comme prévu. Les migrations de test n’interrompent pas la réplication sur site : la VM source continue de fonctionner. Après le test, supprimez les ressources de test dans le portail afin d’éviter des frais inutiles.

La bascule est l’étape finale qui transfère le trafic de production du site local vers Azure. Lors de la bascule, la VM source est mise au repos (ou vous l’arrêtez manuellement), les dernières modifications différentielles sont appliquées au réplica Azure, puis la nouvelle VM Azure est démarrée. Comme il s’agit d’une migration au niveau du stockage, la bascule est généralement très rapide : moins de 10 minutes pour la plupart des VM. Planifiez-la pendant une fenêtre de maintenance et informez à l’avance les parties prenantes de l’application.

Dans le portail Azure Migrate, cliquez sur Migrer pour le serveur sélectionné. Le portail vous demande si vous souhaitez arrêter la VM sur site avant la migration (ce qui est recommandé pour éviter toute perte de données). Azure applique les dernières modifications différentielles, crée la VM Azure et marque la migration comme terminée. Vous devez ensuite mettre à jour les enregistrements DNS, les serveurs principaux de l’équilibreur de charge ou les chaînes de connexion de l’application afin de pointer vers l’adresse IP privée ou le FQDN Azure, pour que les clients commencent à utiliser la VM Azure.

Après la bascule, effectuez les vérifications suivantes : état de l’application (chargez toutes les pages de l’application et exécutez des tests de fumée), connectivité (vérifiez que la VM Azure peut accéder aux bases de données et services dépendants), supervision (installez l’agent Azure Monitor et activez les diagnostics), et sauvegarde (inscrivez la VM dans Azure Backup). Si des problèmes sont détectés, la VM source sur site peut être redémarrée : elle reste intacte tant que vous ne l’avez pas explicitement mise hors service.

Une fois que la VM migrée est stable dans Azure et que les parties prenantes ont donné leur accord, vous pouvez mettre hors service la VM source sur site. Dans Azure Migrate, sélectionnez Terminer la migration pour fermer la réplication. Cette action n’arrête pas automatiquement la VM sur site : vous devez l’éteindre et récupérer le matériel dans le cadre de votre processus habituel de gestion des actifs informatiques. La mise hors service réduit les coûts de l’infrastructure sur site et vous rapproche d’un modèle opérationnel entièrement cloud.

Pour les migrations importantes impliquant des centaines de VM, Azure Migrate prend en charge les opérations en masse via l’importation CSV. Vous préparez un CSV répertoriant chaque VM source, sa référence cible, son groupe de ressources cible et son réseau virtuel, puis vous le chargez afin de démarrer simultanément la réplication de toutes les VM. Les groupes de migration vous permettent d’ordonner la réplication et la bascule afin que les niveaux d’application dépendants (base de données, application, web) migrent dans le bon ordre au cours de la même fenêtre de maintenance.

Surveillez les problèmes courants suivants liés au transfert sans modification : le chiffrement du disque de démarrage des VM Linux peut empêcher leur démarrage dans Azure (utilisez Azure Disk Encryption après la migration) ; les adresses IP statiques codées en dur dans les configurations des applications doivent être remplacées par les adresses IP privées ou les noms DNS Azure ; les règles de pare-feu sur site qui font référence à l’adresse IP du serveur devront peut-être être reproduites dans un NSG Azure ; et les paramètres de fuseau horaire des VM Windows peuvent modifier le comportement des applications dans l’environnement UTC d’Azure.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que le processus de migration par réhébergement va de la réplication à la synchronisation différentielle, puis à la migration de test et à la bascule, que la migration de test valide la VM sur un réseau isolé avant sa mise en production, et que les étapes postérieures à la migration (supervision, sauvegarde, mise à jour DNS) sont essentielles avant la mise hors service des ressources sur site. Nous allons maintenant aborder les meilleures pratiques pour migrer des bases de données vers Azure.