Réussir la migration d’une infrastructure IT nécessite un objectif clair, un plan d’action, des moyens humains et matériels, et …. , du temps devant soi. Mais il arrive que la migration ne soit pas un parcours de santé, mais plutôt jonché de contraintes impactant les stratégies décidés avant. Par exemple, que doit-on faire si la migration de VMs doit se faire finalement sans aucun accès au niveau hyperviseur ?
Différentes approches de migration ?
Lors d’une migration vers le cloud, plusieurs approches coexistent : le « lift-and-shift » (reprise à l’identique), la replatforming ou refactoring (adaptation partielle) et la reconstruction totale accompagnée de modernisation.
Si le lift-and-shift est souvent privilégié pour sa rapidité de mise en œuvre, il n’exploite pas pleinement les services cloud-native et peut engendrer un surcoût opérationnel à long terme.
À l’inverse, la refonte ou la reconstruction des applications, en recourant par exemple aux microservices, au serverless ou aux bases de données managées, permet d’améliorer la scalabilité, la résilience et l’agilité, tout en optimisant les coûts à terme.
Azure Migrate ?
Bien entendu, dans certains scénarios, notamment lorsqu’on fait face à des délais serrés, à des contraintes budgétaires ou à un manque de compétences, il est nécessaire de migrer en priorité les machines virtuelles existantes « telles quelles ».
On opte alors pour un lift-and-shift à l’aide d’outils comme Azure Migrate ou Azure Site Recovery, qui répliquent les VM sans toucher au code ni à l’architecture.
Pour vous donner un peu de matière, un ancien article parlant d’Azure Migrate vous détaille toutes les grandes étapes.
Mais que faire si l’accès à l’hyperviseur est restreint ?
Toutefois, si aucun niveau d’accès la couche hyperviseur n’est possible, la migration vers Azure s’en trouve alors un peu plus compliquée.
Dans le cadre d’Azure Migrate (et plus précisément du service de réplication Azure Site Recovery), on rencontre 2 rôles clés au sein de l’appliance de réplication déployée :
- Serveur de traitement :
- Installé par défaut sur le serveur de configuration, il reçoit les données de réplication envoyées par le Mobility Service installé sur vos machines sources.
- Il optimise ces flux en effectuant de la mise en cache, de la compression et du chiffrement, puis les transmet vers votre compte de stockage Azure.
- Serveur de cible principale :
- N’est utilisé que lors du failback (reprise sur site) des machines dès lors qu’elles ont été basculées vers Azure.
- Il reçoit alors les données répliquées en provenance d’Azure, reconstitue les disques (VHD/VMDK) et les écrit sur votre infrastructure on-premises pour restaurer les VM sur site.
En synthèse, le Process Server gère l’envoi optimisé des données vers Azure, tandis que le Master Target Server gère la réception et la restauration de ces mêmes données lors d’un retour en local.
En voyant cette excellente vidéo en mode tutoriel, je trouvais intéressant de tester par moi-même ce cas de figure, en partant d’un environnement VMware vers Azure, sans pouvoir utiliser l’accès hyperviseur.
Cet article est donc divisé en 2 démonstrations quasi-identiques :
- Test I – Appliance de réplication sur VMware : se déroule dans un environnement où une nouvelle VM est installée sur VMware pour jouer le rôle d’appliance de réplication.
- Test II – Appliance de réplication sur Azure : l’appliance de réplication déployée directement sur Azure, car non déployable sur VMware.
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de réaliser nos 2 tests de migration, nous allons avoir besoin de :
- Un tenant Microsoft actif
- Une souscription Azure valide
- Un environnement hypervisé (Hyper-V ou VMware)
Commençons par effectuer l’exercice de migration en partant du principe que nous pouvons déployer une machine virtuelle jouant le rôle de d’appliance de réplication sur VMware.
Test I – Appliance de réplication VMware :
Sur votre console hyperviseur, créez une machine virtuelle de type Windows Serveur afin d’y installer par la suite notre appliance de réplication :
Connectez-vous à celle-ci avec un compte administrateur local :
Si besoin, installez un navigateur internet récent :
Connectez-vous au portail Azure, puis recherchez le service Azure Migrate :
Cliquez-ici pour commencer un nouveau projet de migration :
Cliquez-ici pour créer le projet de migration :
Renseignez les toutes informations demandées, puis cliquez sur Créer :
Cliquez sur Découvrir afin d’installer l’appliance de réplication :
Renseignez tous les champs, puis cliquez sur Créer les ressources :
Conservez les options suivantes :
Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :
Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :
Lancez l’installeur de l’appliance de réplication :
Attendez quelques minutes la fin de la décompression :
Conservez ce choix, puis cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Rechercher le fichier clef, puis cliquez sur Suivant :
Conservez ce choix, puis cliquez sur Suivant :
Attendez que tous les contrôles soit effectués, puis cliquez sur Suivant :
Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :
Si cela est votre cas, cochez cette case, puis cliquez sur Suivant :
Cliquez sur Suivant :
Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :
Cliquez sur Installer :
Attendez environ 10 minutes la fin de l’installation de l’appliance de réplication :
Cliquez sur Oui :
Collez cette passphrase dans un fichier texte, puis sauvegardez-le :
Une fois l’installation réussie, cliquez sur Terminer :
L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur de vos machines devant être migrées dans le cloud Azure :
Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’appliance de réplication :
Attendez le succès de l’opération via la notification suivante :
Constatez la création de ressources dans le groupe de ressources précédemment défini :
Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez l’exécutable ci-dessous :
C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository
Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y l’exécutable précédemment copié ainsi que le fichier texte contenant la passphrase :
Retournez sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée vers Azure :
Sur cette machine virtuelle à migrer, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :
$PSversiontable
Toujours depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication :
Toujours depuis votre machine virtuelle à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :
Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :
Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :
cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted
UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent /CSType CSLegacy
cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :
Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :
Exécutez cette commande pour installer l’agent :
Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :
Avant de continuer, vérifiez le succès des opérations :
Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :
Cliquez ensuite sur Répliquer :
Renseignez toutes les champs, puis cliquez sur Continuer :
Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :
Sélectionner les machines à migrer, puis cliquez sur Suivant :
Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :
Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :
Sélectionnez le type de disque à utiliser pour les machines à migrée, puis cliquez sur Suivant :
Lancez la réplication en cliquant sur Répliquer :
Les notifications suivantes apparaissent alors :
Des ressources Azure liées au projet de migration sont alors créées :
Le compte de stockage commence à recevoir les premières données liées à la réplication :
Dans le coffre Recovery, la réplication commence elle-aussi à être visible :
Environ 1 heure plus tard, celle-ci est terminée :
Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :
Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :
Définissez la destination cible, puis cliquez sur Continuer :
Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :
La notification suivante apparaît :
Quelques secondes plus tard, celle-ci affiche le succès du déclenchement de la migration :
Cette migration est visible sur notre projet Azure Migrate :
Le coffre Recovery nous indique que la migration est terminée :
Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :
Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :
# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
-Name 'fDenyTSConnections' -Value 0
# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force
Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor GreenCollez ces commandes, puis lancez celles-ci :
Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :
Constatez l’ouverture de session Windows sur votre machine virtuelle migrée :
La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.
Continuons l’exercice de migration en partant cette fois du principe que nous ne pouvons pas créer une machine virtuelle jouant le rôle d’appliance de réplication sur l’hyperviseur, et que celle-ci doit donc alors être obligatoirement déployée sur Azure.
Test II – Appliance de réplication sur Azure :
Pour cette approche, commencez par créer un réseau virtuel Azure comprenant plusieurs sous-réseaux virtuels :
- Un sous-réseau dédié à l’appliance de réplication.
- Un sous-réseau dédié à Azure Bastion.
- Un sous-réseau dédié à la passerelle VPN, pour connecter notre machine virtuelle à migrer à notre appliance de réplication hébergée sur Azure.
Créez une machine virtuelle ayant pour futur rôle l’appliance de réplication :
Connectez-vous à celle-ci via Azure Bastion :
Afin de connecter par la suite la machine virtuelle à migrer à l’appliance de réplication Azure, via une connexion Point à Site, des certificats sont nécessaires pour l’authentification IKEv2.
Pour cela, depuis l’appliance de réplication Azure, générez et exportez les certificats :
- Un certificat racine auto-signé (à exporter en
.cerpour Azure) - Un certificat client signé par ce root (à exporter en
.pfxpour votre machine cliente)
Sur votre appliance de réplication Azure, ouvrez une fenêtre PowerShell, puis lancez le script suivant pour générer le certificat racine :
$rootCert = New-SelfSignedCertificate `
-Type Custom `
-KeySpec Signature `
-Subject "CN=AzureP2SRootCA" `
-KeyExportPolicy Exportable `
-KeyLength 2048 `
-CertStoreLocation "Cert:\LocalMachine\My" `
-FriendlyName "Azure P2S Root CA" `
-NotAfter (Get-Date).AddYears(10) `
-HashAlgorithm sha256 `
-KeyUsageProperty Sign `
-KeyUsage CertSignExportez le certificat public au format CER :
Export-Certificate `
-Cert $rootCert `
-FilePath "C:\Certs\AzureP2SRootCA.cer"Ouvrez le gestionnaire des certificats machines afin de constater sa présence :
Créer et exporter le certificat client signé par le certificat root :
$clientCert = New-SelfSignedCertificate `
-Type Custom `
-Subject "CN=AzureP2SClientCert" `
-KeySpec Signature `
-KeyExportPolicy Exportable `
-KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $rootCert `
-FriendlyName "Azure P2S Client Cert" `
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2") `
-NotAfter (Get-Date).AddYears(2)Exportez la clef privée au format PFX :
$pwd = ConvertTo-SecureString -String "VotreMotDePasseComplexe!" -Force -AsPlainText
Export-PfxCertificate `
-Cert $clientCert `
-FilePath "C:\Certs\AzureP2SClientCert.pfx" `
-Password $pwdOuvrez le gestionnaire des certificats utilisateurs afin de constater sa présence :
Afin d’enregistrer les données du certificat public dans Azure, exportez ce dernier depuis le gestionnaire des certificats utilisateurs :
Choisissez Non, puis cliquez sur Suivant :
Sélectionnez Format Base-64 encodé X.509 (.CER), puis cliquez sur Suivant :
Indiquez le chemin de sauvegarde, puis cliquez sur Suivant :
Ouvrez le fichier en base-64 avec un éditeur, puis copiez tout le texte (sauf -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----) :
Dans le portail Azure, rendez-vous sur la page de votre passerelle VPN, puis démarrez la configuration Point à Site :
Définissez un espace d’adressage, le type de tunnel en IKEv2, collez le texte en Base-64 que vous venez de copier dans Données du certificat racine, puis cliquez sur Enregistrer.
Après quelques instants, constatez la notification Azure suivante :
Télécharger le client VPN afin de configurer plus tard le client VPN Windows natif sur la machine virtuelle à migrer :
Toujours sur appliance de réplication Azure, recherchez le service Azure Migrate :
Cliquez-ici pour commencer un projet de migration :
Cliquez-ici pour créer un projet de migration :
Renseignez toutes les informations demandées, puis cliquez sur Créer :
Cliquez sur Découvrir afin d’installer l’appliance de réplication :
Renseignez tous les champs, puis cliquez sur Créer les ressources :
Conservez les options suivantes :
Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :
Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :
Une fois téléchargé, lancez l’installeur :
Attendez quelques minutes la fin de la décompression :
Conservez ce choix, puis cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Rechercher le fichier clef, puis cliquez sur Suivant :
Conservez ce choix, puis cliquez sur Suivant :
Attendez que les contrôles soit effectués, puis cliquez sur Suivant :
Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :
Si cela n’est pas votre cas, cochez cette case, puis cliquez sur Suivant :
Cliquez sur Suivant :
Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :
Cliquez sur Installer :
Attendez environ 10 minutes la fin de l’installation :
Cliquez sur Oui :
Collez cette passphrase dans un fichier texte, puis sauvegardez-le :
Une fois l’installation réussie, cliquez sur Terminer :
L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur des machines devant être migrées dans le cloud Azure :
Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’application de réplication :
Attendez le succès de l’opération avec la notification suivante :
Constatez la création de nouvelles ressources dans le groupe de ressources précédemment défini :
Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez seulement l’exécutable ci-dessous :
C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository
Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y :
- L’exécutable précédemment copié
- Le fichier texte contenant la passphrase
Rendez-vous sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée sur Azure :
Sur cette machine virtuelle, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :
Installez le certificat root dans le magasin Trusted Root Certification Authorities du gestionnaire des certificats machines :
Installez le certificat client dans le magasin Personal du certificats utilisateurs :
Installez la configuration VPN Windows précédemment téléchargée depuis la page Azure de la passerelle VPN :
Lancez la connexion VPN :
Cliquez sur Connecter :
Vérifiez le statut de la connexion VPN :
Depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication Azure :
Toujours depuis cette VM à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :
Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :
Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :
cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted
UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent /CSType CSLegacy
cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :
Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :
Exécutez cette commande pour installer l’agent :
Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :
Avant de continuer, vérifiez le succès des opérations :
Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :
Cliquez ensuite sur Répliquer :
Renseignez toutes les champs, puis cliquez sur Continuer :
Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :
Sélectionner les machines à migrer, puis cliquez sur Suivant :
Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :
Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :
Sélectionnez le type de disque à utiliser pour les machines à migrer, puis cliquez sur Suivant :
Lancez la réplication en cliquant sur Répliquer :
Les notifications suivantes apparaissent alors :
Le compte de stockage commence à recevoir les premières données liées à la réplication :
Dans le coffre Recovery, la réplication commence elle-aussi à être visible :
Environ 1 heure plus tard, celle-ci est terminée :
Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :
Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :
Définissez la destination cible, puis cliquez sur Continuer :
Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :
Quelques secondes plus tard, la notification suivante affiche le succès de déclenchement de la migration :
Cette migration est visible sur notre projet :
Le coffre Recovery nous indique que la migration est terminée :
Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :
Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :
# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
-Name 'fDenyTSConnections' -Value 0
# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force
Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor GreenCollez ces commandes, puis lancez celles-ci :
Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :
Constatez l’ouverture de session Windows sur votre machine virtuelle migrée sur Azure :
La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.
Conclusion
En définitive, migrer vos VMs vers Azure sans droits d’infra reste une solution de « seconde main » qui dépanne en cas de contraintes fortes, mais elle ne doit pas devenir la norme.
Pour tirer pleinement parti du cloud, il sera toujours préférable de recréer vos ressources selon les principes cloud-native : refactoring des applications, adoption de services managés et optimisation des coûts.
À long terme, cette approche garantit une meilleure scalabilité, une résilience accrue et une plus grande agilité opérationnelle, tout en maîtrisant vos dépenses. Gardez donc cette méthode de contournement sous le coude, mais visez toujours la modernisation et l’optimisation complètes de votre stack dans Azure.