Migrez votre AD 2012R2 vers Azure

Microsoft nous prévient déjà depuis assez longtemps : la fin du support de Windows Server 2012 R2 et SQL 2012 sont prévues pour le 10 octobre 2023 😖. Après cette date, ces produits ne recevront plus de mise à jour, sécurités incluses ! Trois s’options s’offrent alors à vous :

Migrer vers une nouvelle version Windows ou SQL plus récente.
Acheter les Mises à jour de sécurité étendue (ESU).
Migrer les serveurs vers Azure pour recevoir gratuitement les ESUs.

Pas de panique !

Microsoft vous aide à planifier la fin de support Windows Server 2012/2012 R2 et SQL Server 2012. Plusieurs ressources sont mises à disposition :

En plus de la documentation Microsoft, Dean Cefola de l’Azure Academy nous propose un petit exercice d’upgrade d’un Active Directory, actuellement hébergé sur un serveur Windows 2012R2 vers un Azure en version 2022 :

La vidéo est vraiment bien faite et très explicative, je souhatais donc vous proposer en détail l’explicatif étape par étape en français afin que vous puissiez le tester par vous-même :

Enfin, Microsoft met aussi à disposition un article dédié à ce sujet : Déployer AD DS dans un réseau virtuel Azure

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la migration Active Directory vers Azure, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide
Un environnement Active Directory on-premise (point de départ)

De mon côté, j’ai simulé mon environnement Active Directory on-premise sur Azure. Voici donc les ressources Azure déjà en place :

Machine virtuelle en Windows Server 2012R2
Azure Bastion
Azure VPN Site à Site

En me connectant à mon serveur AD (nous l’appellerons DC2012R2), nous y retrouvons mon domaine on-premise, ainsi que la version de l’OS : Windows Server 2012R2.

Actuellement, mon environnement de test ne comporte qu’un seul serveur en tant que contrôleur de domaine AD :

Nous allons donc maintenant déployer un nouvel environnement sur Azure afin de simuler la transition AD vers le Cloud de Microsoft.

Etape I – Déploiement des ressources Azure :

Pour cela, commencez par déployer une machine virtuelle sur Azure. Rendez-vous sur le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer votre première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

Définissez un compte administrateur local, bloquer les ports entrants (question de sécurité pour un DC), puis cliquez sur Suivant :

Comme le Microsoft le recommande, il est nécessaire de stocker les informations AD (base de données, les journaux et le dossier sysvol) séparées du disque OS.

Pour cela, rajoutez un second disque en cliquant ici :

Cliquez sur OK :

Définissez le paramètre Host Cache sur le disque de données sur None, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Créez un réseau virtuel (différent de celui utilisé pour simuler le réseau on-premise), retirez l’adresse IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources de la VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour vous connecter à la VM :

Cliquez sur le bouton suivant pour déployer le service Azure Bastion :

Inutile d’attendre qu’Azure Bastion soit déployé pour continuer cet exercice.

Modifiez l’adresse IP locale de votre machine virtuelle Azure pour la rendre statique :

Avant d’aller plus loin, il est nécessaire d’établir une liaison réseau entre les deux environnements Azure <> on-premise (Normalement, notre environnement on-premise ne se trouve pas dans Azure).

Une des options est donc pour nous de construire une liaison VPN en connectant 2 passerelles VPN Azure entre elles.

Etape II – Déploiement de la passerelle VPN Azure :

Pour cela, il est nécessaire de commencer par la création d’une nouvelle passerelle VPN dans notre réseau virtuel Azure.

Pour cela, utilisez la barre de recherche :

Cliquez sur le réseau virtuel créé lors de la création de la VM DC2022 d’Azure :

Ajoutez un sous-réseau dédié à la passerelle VPN comme ceci :

Pour créer une passerelle VPN, utilisez à nouveau la barre de recherche :

Cliquez ici pour créer la seconde passerelle que nous connecterons par la suite à la première (on-premise) :

Renseignez les informations de base relatives à votre Passerelle VPN, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 15-45 minutes :

Afin de connecter les deux Passerelles VPNs Azure entre eux, nous avons besoin d’avoir :

deux passerelles de réseau local
deux connexions VPNs

Dans mon cas, la ressources VPNs côté on-premise sont déjà présentes :

Il ne me reste donc qu’à déployer les 2 ressources VPNs suivantes sur mon réseau Azure :

Passerelle de réseau local
Connexion VPN

Pour créer cela, utilisez encore une fois la barre de recherche Azure :

Configurer la passerelle de réseau local dans l’environnement Azure, mais indiquez l’adresse IP publique du VPN on-premise, puis lancez la validation :

Une fois la validation Azure réussie, lancez la création de la ressource :

Continuez en créant la connection entre le VPN Azure et la passerelle de réseau local on-premise, puis cliquez sur Suivant :

Définissez une clef partagée, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la ressource :

Attendez environ 5 minutes afin de constater un changement dans le statut de la connexion VPN.

Le statut de la connexion change bien sur le passerelle VPN Azure :

Le statut de la connexion change également sur le passerelle VPN on-premise :

Afin que la nouvelle machine virtuelle DC2012 d’Azure se connecte à l’Active Directory on-premise DC2012R2, configurez le DNS de votre réseau Azure pour qu’il pointe sur l’adresse IP de votre AD on-premise, puis cliquer sur Sauvegarder :

Notre environnement Azure est maintenant prêt pour configurer l’Active Directory. Pour cela, nous devons d’abord joindre votre machine virtuelle DC2022 au domaine on-premise, puis la promouvoir en tant que contrôleur de domaine.

Etape III – Ajout du second contrôleur de domaine Azure :

Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM DC2022 :

Saisissez la commande suivante afin renouveler les informations DNS de votre VM DC2022 d’Azure afin qu’elle puisse rejoindre votre domaine on-premise :

ipconfig/renew

Sur la console Server Manager, utilisez le menu suivant pour créer une nouvelle partition liées aux données AD DS :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur OK:

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Créer :

Attendez que le traitement se termine :

Cliquez sur Fermer :

Toujours sur Server Manager, cliquez sur WORKGROUP afin de joindre votre domaine on-premise :

Cliquez sur le bouton ci-dessous :

Renseignez le nom de votre domaine on-premise, puis cliquez sur OK :

Renseignez les identifiants d’un compte présent sur le domaine on-premise, puis cliquez sur OK :

Attendez quelques secondes pour voir apparaître le message suivant, puis cliquez sur OK :

Cliquez sur OK :

Cliquez sur Fermer :

Cliquez-ici pour lancer un redémarrage immédiat de la VM DC2022 d’Azure :

Azure Bastion vous informe que la connexion RDP a été perdue. Cliquez sur Fermer :

Retournez sur votre DC2012R2 afin de constater la bonne apparition de notre VM DC2022 d’Azure dans la liste des ordinateurs du domaine Active Directory.

Rouvrez à nouveau une session à distance via le service Azure Bastion en utilisant un compte de domaine sur votre DC2022 :

Cliquez-ici pour installer les rôles AD DS et DNS sur votre VM DC2022 d’Azure :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cochez les deux rôles AD DS et DNS, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez quelques minutes, puis cliquez ici pour promouvoir votre VM DC2022 comme un second serveur AD DS de votre domaine on-premise :

Conservez le premier choix ainsi que le domaine précédemment joint, puis cliquez sur Suivant :

Choisissez si besoin un site différent du premier, renseignez le mot de passe DSRM, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Modifiez les chemins AD DS pour utiliser le nouveau disque, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ 5 minutes que l’installation se termine :

Comme la VM doit redémarrer au niveau OS, Azure Bastion vous informe que la connexion RDP a été perdue. Cliquez sur Fermer :

Retournez sur votre DC2012R2 afin de constater la bonne apparition de notre VM DC2022 d’Azure dans la liste des contrôleurs de domaine.

Afin que la nouvelle machine virtuelle DC2022 Azure puisse résoudre des requêtes DNS du domaine on-premise, configurez le DNS de votre réseau Azure pour qu’il pointe sur l’adresse IP de votre VM DC2022, puis cliquer sur Sauvegarder :

Effectuez la même opération sur le DNS du réseau on-premise :

Notre machine virtuelle est maintenant contrôleur de domaine, nous allons pouvoir préparer le décommissionnement du DC2012R2 sur le réseau on-premise.

Avant cela, nous devons nous occuper des rôles FSMO.

Etape IV – Transfert des 5 rôles FSMO :

Nous allons déplacer les 5 roles FSMO présents sur Active Directory :

Pour cela, ouvrez une session à distance sur votre VM 2012R2 via le service Azure Bastion en utilisant un compte admin de domaine :

Lancez la commande suivante afin de vérifier sur quel contrôleur de domaine se trouve actuellement les 5 rôles FSMO :

netdom /query fsmo

Comme attendu, les 5 rôles sont actuellement gérés par le contrôleur de domaine DC2012R2 :

Depuis la console Server Manager du serveur DC2012R2, ouvrez Windows PowerShell avec le module AD :

Saisissez la commande suivante pour transférer d’un coup les 5 rôles depuis DC2012R2 vers DC2022, en prenant le soin de modifier le nom en gras par le nom de votre VM :

Move-ADDirectoryServerOperationMasterRole -Identity "azure-dc" -OperationMasterRole 0,1,2,3,4

Validez alors chacune des demandes de transfert de rôle :

Relancez la commande suivante afin de vérifier le changement de contrôleur de domaine pour les 5 rôles FSMO :

netdom /query fsmo

Si vous rencontrez le message d’erreur suivant :

Depuis la console Server Manager, ouvrez Active Directory Sites et Services :

Corriger la valeur à vide de l’attribut dNSHostName :

Puis relancez la commande suivante :

Move-ADDirectoryServerOperationMasterRole -Identity "azure-dc" -OperationMasterRole 0,1,2,3,4

Vous pouvez maintenant décommissionnnez votre serveur DC2012R2.

Etape V – Décommissionnement l’Active Directory DC2012R2 :

Pour faire les choses dans l’ordre, cliquez sur la fonction de désinstallation présente dans la console Server Manager se trouvant sur votre serveur DC2012R2 :

Cliquez sur Suivant :

Cliquez sur Suivant :

Décochez les deux rôles AD DS et DNS, puis cliquez sur Suivant :

Cliquez-ici pour confirmer votre choix :

Le message d’erreur suivi est attendu, la d’installation de rôles en activité ne peut que se faire qu’après un premier décommissionnement au niveau du domaine.

Cliquez-ici pour commencer l’opération :

Cliquez sur Suivant :

Cochez la case suivante pour également procéder pour la partie DNS, puis cliquez sur Suivant :

Définissez un nouveau mot de passe pour le compte d’administrateur local Windows :

Cliquez sur Rétrograder :

Attendez quelques minutes que le traitement se termine :

Le serveur DC2012R2 a besoin d’effectuer un redémarrage OS pour terminer la rétrogradation :

Azure Bastion vous informe alors que la connexion RDP a été perdue. Cliquez sur Fermer :

Retournez sur Server Manager de votre DC2022 d’Azure pour ouvrir Active Directory Utilisateurs et Ordinateurs :

Comme attendu, il ne reste que le DC2022 hébergé sous Azure :

Configurez le DNS de votre réseau Azure pour qu’il pointe plus que sur l’adresse IP de votre DC2022, puis cliquez sur Sauvegarder :

Effectuez la même opération sur le DNS du réseau on-premise, puis cliquez sur Sauvegarder :

Nous environnement Active Directory est maintenant 100% Cloud. Nous allons pouvoir mettre à jour le niveau domaine fonctionnel vers une version plus récente.

Etape VI – Mise à niveau du domaine Active Directory :

Pour cela, retournez sur la console Server Manager de votre DC2022 d’Azure, puis ouvrez Active Directory Domains and Trusts :

Commencez par élever le niveau fonctionnel du domaine sur chaque domaine de votre forêt :

Choisissez la version la plus récente possible, puis cliquez sur Elever :

Cliquez sur OK :

Cliquez sur OK :

Une fois tous les domaines modifiés, effectuez la même opération au niveau de la forêt AD :

Là encore, choisissez la version la plus récente possible, puis cliquez sur Elever :

Cliquez sur OK :

Cliquez sur OK :

Toutes les opérations de transfert ou de mise à jour sont maintenant terminées. Il ne nous reste plus qu’à tester le bon fonctionnement de notre Active Directory dans Azure.

Etape VII – Test de connexion depuis le réseau on-premise :

Pour tester notre AD dans Azure, nous utiliserons une machine virtuelle Windows 11 connectée au réseau on-premise (donc transitant par le lien VPN).

Sur la page de machines virtuelles Azure, éteignez le DC2012R2 afin de ne pas fausser le test de bon fonctionnement :

Confirmez votre choix en cliquant sur Oui :

Attendez l’apparition de la notification Azure suivante :

Ouvrez une session à distance sur votre machine Windows 11 de test via le service Azure Bastion en utilisant un compte de domaine :

Attendez que la session Windows s’ouvre :

Saisissez la commande suivante afin de bien vérifier l’ouverture de session sur un compte du domaine AD :

whoami

Conclusion :

Grâce à cet exercice, nous avons pu parcourir ensemble les principales étapes présentes dans une migration vers Azure d’un Active Directory, et via une version plus récente. Nul doute que le nombre et la répartition des DCs des infrastructures on-premise peut rajouter des tâches et de la complexité.

Azure Migrate – Exercice 1 Création du projet + démarrage de l’estimation :

Notre environnement de départ Hyper-V est prêt et fonctionnel. L’exercice 1 va nous permettre d’en savoir un peu plus sur la phase d’estimation.

Pour qu’Azure Migrate vous propose une architecture cible dans le Cloud, il a besoin de sonder les ressources à migrer. Le but est de connaître l’OS, la puissance utilisée ou encore les interactions réseaux.

Tâche 1 – Créez le projet Azure Migrate :

Nous allons pouvoir démarrer les étapes liées à l’estimation sur Azure Migrate. Pour cela, recherchez le service Azure Migrate grâce à la barre de recherche présente dans votre portail Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-214.png.

Sur la page d’accueil du service Azure Migrate, cliquez sur la première tuile à gauche :

L’attribut alt de cette image est vide, son nom de fichier est image-215.png.

Cliquez-ici pour créer votre Projet de migration. Celui-ci englobera les différentes phases (estimations et migration) de notre atelier :

L’attribut alt de cette image est vide, son nom de fichier est image-216.png.

Remplissez les champs en créant un nouveau groupe de ressources nommé AzureMigrateRG, si possible dans la même géographie Azure que celle dont dépend la région utilisée lors du déploiement :

L’attribut alt de cette image est vide, son nom de fichier est image-217-1024x416.png.

Pour info, la création de ce projet se retrouve bien dans la liste des ressources Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-218-1024x368.png.

La création de ce projet vous ouvre automatiquement celui-ci dans Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-219-1024x510.png.

Note : Remarquez bien la présence deux sections précédemment rappelées dans cet article : Estimation / Migration.

Tâche 2 – Déployez l’appliance d’Azure Migrate :

Pour estimer au mieux l’architecture Azure cible, Azure Migrate propose d’installer sur notre environnement Hyper-V une appliance sous forme de machine virtuelle.

Cette dernière va analyser les données relatives aux autres machines virtuelles sur notre environnement et remontera toutes les informations (métriques) nécessaires au service Azure Migrate via le protocole HTTPS.

Cliquez ici pour démarrer l’installation :

L’attribut alt de cette image est vide, son nom de fichier est image-220.png.

Choisissez Hyper-V, nommez votre appliance Azure Migrate SmartHotelAppl, puis cliquez ici pour générer une clef d’association (entre l’Appliance et votre projet d’Azure Migrate) :

L’attribut alt de cette image est vide, son nom de fichier est image-221-1024x334.png.

Une fois la clef générée, copiez la dans votre bloc-notes sans fermez cet onglet Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-222.png.

Note : Dans cet atelier Microsoft, le téléchargement de l’appliance d’Azure Migrate n’est pas nécessaire car cette dernière est déjà présente sur notre serveur Hyper-V.

Ouvrez un second onglet Azure, puis recherchez la machine virtuelle Hyper-V appelée SmartHotelHost :

L’attribut alt de cette image est vide, son nom de fichier est image-223.png.

Téléchargez le fichier RDP pour démarrer une session de bureau à distance :

L’attribut alt de cette image est vide, son nom de fichier est image-224.png.

Utilisez les identifiants RDP suivants :

L’attribut alt de cette image est vide, son nom de fichier est image-225.png.

Acceptez le risque sécuritaire :

L’attribut alt de cette image est vide, son nom de fichier est image-226.png.

Une fois la session à distance ouverte, ouvrez le gestionnaire Hyper-V :

L’attribut alt de cette image est vide, son nom de fichier est image-227-1024x539.png.

Cliquez ici pour créer l’Appliance d’Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-228.png.

Cliquez sur Suivant, puis choisissez le répertoire suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-229.png.

Cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-230.png.

Cliquez encore sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-231.png.

Cliquez encore sur Suivant en conservant ce choix :

L’attribut alt de cette image est vide, son nom de fichier est image-232.png.

Choisissez la connexion Azure Migrate Switch, puis cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-233.png.

Cliquez sur Finaliser :

L’attribut alt de cette image est vide, son nom de fichier est image-234.png.

Cliquez ici pour démarrer l’appliance d’Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-235-1024x667.png.

Tâche 3 – Configurez l’appliance Azure Migrate :

Cette appliance a maintenant besoin d’une configuration pour remonter toutes les informations au bon projet créé dans Azure Migrate. Pour cela, connectez-vous à celle-ci :

L’attribut alt de cette image est vide, son nom de fichier est image-236-1024x667.png.

Une fois la fenêtre de connexion ouverte, acceptez les Termes et conditions :

L’attribut alt de cette image est vide, son nom de fichier est image-238.png.

Configurez le mot de passe du compte administrateur avec le mot de passe demo!pass123, puis cliquez sur Finaliser :

L’attribut alt de cette image est vide, son nom de fichier est image-240.png.

Note : Attention, bien souvent, cette machine virtuelle utilise un clavier américain. De ce fait le symbole du point d’exclamation est la combinaison MAJ+1.

Cliquez sur Connecter :

L’attribut alt de cette image est vide, son nom de fichier est image-242.png.

Changez le clavier au besoin, puis connectez-vous avec le mot de passe configuré juste avant : demo!pass123

L’attribut alt de cette image est vide, son nom de fichier est image-243-1024x653.png.

Attendez quelques minutes pour voir automatiquement s’ouvrir le navigateur internet suivant, puis acceptez les Termes et conditions :

L’attribut alt de cette image est vide, son nom de fichier est image-244-1024x693.png.

Collez la clef de votre projet Azure Migrate, puis cliquez sur Vérifier :

L’attribut alt de cette image est vide, son nom de fichier est image-245-1024x425.png.

Une fois vérifiée, attendez quelques minutes pour constater d’éventuelles mises à jour de l’appliance :

L’attribut alt de cette image est vide, son nom de fichier est image-246-1024x125.png.

Rafraichissez la page au besoin si le système vous le demande :

L’attribut alt de cette image est vide, son nom de fichier est image-247.png.

Authentifiez-vous avec votre compte Azure utilisé pour la création des ressources de cet atelier :

L’attribut alt de cette image est vide, son nom de fichier est image-248-1024x207.png.

Cliquez ici pour utiliser le mécanisme d’authentification Azure PowerShell pour l’appliance d’Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-249.png.

Collez le code donné précédemment, puis cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-250.png.

Choisissez le compte Azure AD adéquat :

L’attribut alt de cette image est vide, son nom de fichier est image-252.png.

Cliquez sur Continuer pour autoriser l’authentification :

L’attribut alt de cette image est vide, son nom de fichier est image-253.png.

Fermez la fenêtre de navigation :

L’attribut alt de cette image est vide, son nom de fichier est image-254.png.

Attendez quelques minutes le temps de l’enrôlement de l’appliance dans Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-255-1024x153.png.

L’attribut alt de cette image est vide, son nom de fichier est image-256.png.

Afin que l’appliance puisse découvrir les machines virtuelles en fonctionnement sur Hyper-V cliquez ici pour ajouter les informations d’identification locales :

L’attribut alt de cette image est vide, son nom de fichier est image-257-1024x333.png.

Ajoutez l’utilisateur suivant, puis cliquez sur Sauvegarder :

L’attribut alt de cette image est vide, son nom de fichier est image-258.png.

Cliquez ici pour ajouter des informations sur les VMs d’Hyper-V à analyser :

L’attribut alt de cette image est vide, son nom de fichier est image-259-1024x332.png.

Indiquez l’adresse IP locale ou le FQDN de l’hôte Hyper-V ainsi que le nom de l’identifiant sauvegardé précédemment, puis cliquez sur Sauvegarder :

L’attribut alt de cette image est vide, son nom de fichier est image-260.png.

Vérifiez que la validation s’est effectuée avec succès :

L’attribut alt de cette image est vide, son nom de fichier est image-261-1024x259.png.

Comme nous n’avons pas besoin d’effectuer d’analyse d’applications particulières, désactivez cette fonction juste ici :

L’attribut alt de cette image est vide, son nom de fichier est image-262-1024x389.png.

Cliquez ici pour démarrer la découverte des machines virtuelles sur notre Hyper-V :

L’attribut alt de cette image est vide, son nom de fichier est image-263-1024x130.png.

Attendez quelques minutes, puis retournez sur votre projet Azure Migrate et actualisez :

L’attribut alt de cette image est vide, son nom de fichier est image-264-1024x516.png.

Quelques petits rafraichissements plus tard, les serveurs commencent à faire leur apparition :

L’attribut alt de cette image est vide, son nom de fichier est image-265.png. — Notez l’apparition de 5 serveurs.
Oui, l’appliance d’Azure Migrate se découvre elle-même ????.

Note Microsoft : Si le processus de découverte prend un temps excessif ou si les ressources sources ne permettent pas à l’appliance de découvrir les ressources dans un délai approprié, vous pouvez importer manuellement les systèmes via ce fichier CSV :

L’attribut alt de cette image est vide, son nom de fichier est image-266.png.

Tâche 4 – Créez l’estimation de la migration :

Une fois la découverte terminée, cliquez ici pour créer l’estimation des ressources Azure, avec pour cible des machines virtuelles Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-267.png.

Cliquez sur ce bouton pour affiner vos critères cibles des ressources Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-268.png.

Personnalisez tous les critères admissibles pour l’architecture cible sur Azure, puis sauvegardez les :

L’attribut alt de cette image est vide, son nom de fichier est image-269-1024x567.png.

Cliquez sur Suivant pour continuer sur la partie Serveur :

L’attribut alt de cette image est vide, son nom de fichier est image-270.png.

Donnez les noms SmartHotelAssessment et SmartHotel VMs, puis sélectionnez uniquement les 3 machines virtuelles suivantes :

L’attribut alt de cette image est vide, son nom de fichier est image-271.png. — La machine virtuelle **smarthotelSQL1** ne sera migrée sur Azure.
Le serveur SQL sera migré vers le service PaaS SQL Database.

Terminez la création de l’estimation :

L’attribut alt de cette image est vide, son nom de fichier est image-272.png.

Relancez un rafraîchissement du projet Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-273.png.

Assez rapidement, constatez l’apparition de l’estimation de machines virtuelles Azure :

L’attribut alt de cette image est vide, son nom de fichier est image-274.png.

Cliquez dessus et constatez le premier niveau de détail d’informations :

L’attribut alt de cette image est vide, son nom de fichier est image-275-1024x292.png. — *Le taux de confiance d’Azure Migrate est faible au début de l’estimation.*

L’attribut alt de cette image est vide, son nom de fichier est image-276-1024x265.png.

L’attribut alt de cette image est vide, son nom de fichier est image-277-1024x339.png.

Tâche 5 – Configurez les dépendances :

La transition vers un nouveau système nécessite des contrôles poussés pour éviter les oublis. C’est aussi le cas pour la partie réseau des infrastructures IT. Bien souvent, plein de connexions entre les services existent et il impératif de ne pas les oublier.

Azure Migrate permet de visualiser ces dépendances afin de les appréhender et de trouver une solution dans la future architecture Azure.

Pour que ces dépendances soient visibles, il est nécessaire de déployer un Azure Log Analytics workspace et des agents sur les machines virtuelles à migrer.

Cliquez sur le groupe présent dans l’estimation Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-278-1024x436.png.

Puis cliquez sur son nom SmartHotel VMs :

L’attribut alt de cette image est vide, son nom de fichier est image-279-1024x289.png.

Avant toute action, les 3 machines virtuelles intégrées à ce groupe sont encore en attente d’installation de l’agent pour afficher leurs dépendances :

L’attribut alt de cette image est vide, son nom de fichier est image-280.png.

Cliquez sur l’une d’entre elle, puis cliquez ici pour créer l’Azure Log Analytics workspace :

L’attribut alt de cette image est vide, son nom de fichier est image-281-1024x261.png.

Donnez-lui un nom unique et une région Azure, puis cliquez sur Configurer :

L’attribut alt de cette image est vide, son nom de fichier est image-282.png.

Attendez quelques minutes que Log Analytics workspace d’Azure se déploie, puis ouvrez un nouvel onglet Azure sur ce dernier pour récupérer plusieurs informations utiles à la configuration des agents de dépendances :

L’attribut alt de cette image est vide, son nom de fichier est image-283-1024x578.png.

Ces informations sont également disponibles sur la page des dépendances d’Azure Migrate :

L’attribut alt de cette image est vide, son nom de fichier est image-284-1024x357.png.

Copiez les 4 liens disponibles (agents + dépendances) :

Microsoft Monitoring Agent :
- Windows
- Linux
Agent de dépendance :
- Windows
- Linux

Sur la connection RDP de votre machine Hyper-V, connectez-vous au serveur smarthotelweb1 via la console Hyper-V :

L’attribut alt de cette image est vide, son nom de fichier est image-285-1024x667.png.

Cliquez sur Connecter :

L’attribut alt de cette image est vide, son nom de fichier est image-286.png.

Renseignez le mot de passe administrateur demo!pass123 :

L’attribut alt de cette image est vide, son nom de fichier est image-287-1024x685.png.

Ouvrez Internet Explorer, puis copiez le premier lien pour installer Microsoft Monitoring Agent (Windows) :

L’attribut alt de cette image est vide, son nom de fichier est image-288.png.

Lancez l’installation, puis validez tous les écrans en cochant cette case :

L’attribut alt de cette image est vide, son nom de fichier est image-289.png.

Renseignez le Workspace ID et la clef qui lui est associée, puis cliquez sur Suivant :

L’attribut alt de cette image est vide, son nom de fichier est image-290.png.

Laissez cette option comme ceci, puis cliquez sur Suivant et lancez l’installation :

L’attribut alt de cette image est vide, son nom de fichier est image-291.png.

Une fois l’installation terminée, copiez le second lien pour installer l’agent de dépendance (Windows) :

L’attribut alt de cette image est vide, son nom de fichier est image-292.png.

Effectuez les mêmes opérations que précédemment sur la machine virtuelle nommée smarthotelweb2.

Pour la machine Linux appelée UbuntuWAF, l’installation des agents peut s’effectuer via une connexion SSH.

Depuis la machine Hyper-V, ouvrez l’exécuteur de commande Windows, puis saisissez celle-ci :

ssh demouser@192.168.0.8

L’attribut alt de cette image est vide, son nom de fichier est image-293.png.

Saisissez le mot de passe demo!pass123, puis Valider :

L’attribut alt de cette image est vide, son nom de fichier est image-295-1024x582.png.

Obtenez une élévation des privilèges par la commande suivante :

sudo -s

Saisissez le mot de passe demo!pass123, puis Validez :

L’attribut alt de cette image est vide, son nom de fichier est image-296-1024x582.png.

Saisissez la commande suivante pour télécharger l’agent Microsoft Monitoring Agent (Linux) en prenant soin de modifier au prélable les deux variables suivantes :

<Workspace ID>
<Workspace Key>

wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w f4fda077-1c65-4680-93d4-e884d4164427 -s 4DFqRZKoi94QSe3piXhvr0vyIYk12n5zGiBJ4VDOoaWU9d4M0dBniKENBJBjyT6vgN/S8v23lXk/RYFxKDzsrw==

L’attribut alt de cette image est vide, son nom de fichier est image-298-1024x582.png.

A cette question, répondez Oui :

L’attribut alt de cette image est vide, son nom de fichier est image-297-1024x582.png.

L’attribut alt de cette image est vide, son nom de fichier est image-299-1024x582.png.

Redémarrer le service en prenant soin de modifier au prélable la variable suivante :

<Workspace ID>

/opt/microsoft/omsagent/bin/service_control restart f4fda077-1c65-4680-93d4-e884d4164427

L’attribut alt de cette image est vide, son nom de fichier est image-300-1024x582.png.

Entrez la commande suivante pour lancer le téléchargement de l’agent de dépendance :

wget --content-disposition https://aka.ms/dependencyagentlinux -O InstallDependencyAgent-Linux64.bin

L’attribut alt de cette image est vide, son nom de fichier est image-302-1024x582.png.

Lancez l’installation de l’agent de dépendance :

sh InstallDependencyAgent-Linux64.bin -s

L’attribut alt de cette image est vide, son nom de fichier est image-303-1024x582.png.

L’installation de tous les agents est maintenant terminée, retournez sur le projet d’Azure Migrate et constatez la disparition de l’alerte, après quelques minutes et plusieurs rafraîchissements :

L’attribut alt de cette image est vide, son nom de fichier est image-304.png.

Cliquez ici pour afficher les dépendances dans un rendu graphique :

L’attribut alt de cette image est vide, son nom de fichier est image-305-1024x104.png.

L’attribut alt de cette image est vide, son nom de fichier est image-306-1024x627.png.

Toujours avec moi ? Super !

Nous avons fini de mettre en place la partie Estimation d’Azure Migrate utilisée pour notre atelier.

Nous allons maintenant commencer la partie migration de la base de données SQL. Là encore, nous allons effectuer les mêmes deux phases :

Evaluation : analyse de la base SQL.
Migration : migration des schémas et des données à froid.

La seconde partie de cet atelier consistera à migrer la base de données SQL vers Azure SQL Database. Il s’agit donc de l’exercice 2, accessible juste ici.

Pour rappel, voici quelques liens utiles pour ne pas vous perdre :

Atelier Azure Migrate :
- Lien GitHub pour les consignes de l’atelier
- Lien GitHub pour le déploiement des ressources
Articles du blog sur l’atelier d’Azure Migrate :

Azure Migrate vous aide à … migrer 😁

C’est décidé, la migration vers le Cloud Azure est validée. Il ne vous reste plus qu’à tout migrer. Oui, mais comment faire ? Rassurez-vous ! Azure Migrate est un service qui va vous faciliter la vie dans le transfert de données et de ressources IT.

Bien évidemment, ce n’est pas la seule solution sur le marché. D’autres outils très spécialisés sont également très performants, et apporte une estimation plus poussée de l’infrastructure en place. Mais Azure Migrate est un outil gratuit et entièrement intégré à l’écosystème Azure. Rien que pour ces deux raisons, je le trouve très bien dans beaucoup de scénarios.

Dans cet article, nous allons répondre à quelques questions sur Azure Migrate, puis nous suivrons un atelier technique, proposé par Microsoft via leur plateforme GitHub, et dédié à ce service.

Concernant la migration vers le Cloud, beaucoup de vidéos sont déjà disponibles sur YouTube. Je vous en ai sélectionné 3, dont une en français :

Seyfallah Tagrerout

Que fait exactement Azure Migrate ?

En deux mots, Azure Migrate travaille sur deux phase, l’estimation et la migration.

Azure Migrate vous aide à découvrir, à évaluer et à migrer des applications, une infrastructure et des données de vos environnements locaux vers Azure. Vous pouvez suivre de manière centralisée la progression de votre migration grâce à plusieurs outils de Microsoft et de fournisseurs de logiciels indépendants (ISV).
Microsoft

John Savill

Comme son nom l’indique, Azure Migrate va vous accompagner dans le transfert de données à travers les différentes phases que compose une migration d’architecture IT.

Car oui, il ne s’agit pas uniquement d’un copier-coller de données vers Azure, et tout est terminé.

Il s’agit avant tout de recréer des ressources correctement configurées et fonctionnant avec des liaisons réseaux adaptées, de les protéger an niveaux des accès, et de les sauvegarder.

Vous l’avez compris, Azure Migrate vous aide pour un grand nombre d’actions dans le processus de migration IT. Mais certaines tâches sont toujours à prévoir en post-migration.

Comme annoncée plus haut, Azure Migrate décompose en deux principales actions :

Evaluation : analyse de l’environnement actuel et préparation des besoins Cloud.
Migration : migration des systèmes et des données, à froid ou à chaud.

Combien coûte Azure Migrate ?

Azure Migrate est disponible gratuitement sur Azure. Toutefois, des frais peuvent être facturés dans l’utilisation d’outils développés par des ISV tiers, comme par exemple :

Thomas Maurer

Pour vous faire une meilleure idée, rentrons dans le vif du sujet avec un atelier dédié à la migration vers Azure. Celui a été conçu par Microsoft et est sous la forme de 3 exercices liés, et sont disponibles sur GitHub.

Le but de cet atelier est de vous faire découvrir les différentes actions d’Azure Migrate par l’utilisation dans un cas réel de migration d’architecture IT.

Comme le montre le schéma ci-dessous, l’objectif est de migrer plusieurs serveurs virtuels actuellement gérés sous un serveur Hyper-V vers le Cloud Azure :

Il est même question de :

Convertir la machine virtuelle dédiée à la base de données SQL en un service PaaS (Platform-As-A-Service), appelé Azure SQL Database.
Convertir le serveur frontal Ubuntu en Application Gateway.

Comptez environ 3-4 heures pour réaliser la totalité des actions décrites dans le manuel. Comme les manipulations sont nombreuses, cet atelier a été découpé en exercices :

Exercice 0 : Déploiement des ressources de l’atelier
Exercice 1 : Création du projet + démarrage de l’estimation
Exercice 2 : Migration de la base de données SQL
Exercice 3 : Migration des serveurs et finalisation de la configuration Azure

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet atelier dédié à Azure Migrate. En effet, la première étape est de simuler un environnement on-premise sur Azure. Ensuite, migrer celles-ci vers nouvelles ressources Azure. Pour tout cela, il nous faut :

Un tenant Microsoft
Une souscription Azure active

Exercice 0 – Déploiement des ressources de l’atelier Azure Migrate :

Tâche 1 – Déployer l’environnement de l’atelier :

Cette page GitHub est notre point de départ. Cliquez sur le lien de la page GitHub, ou sur le bouton de déploiement Azure ci-dessous pour créer des ressources simulant notre environnement on-premise et quelques ressources pour l’architecture cible Azure :

Vérifiez que tous les champs suivants sont renseignés. Je vous conseille de ne pas les changer (région ou mot de passe) car cela pourrait vous déranger par la suite.

Une fois la validation terminée, lancez la création des ressources :

Comme indiqué dans le document Microsoft, le déploiement de ces ressources de simulation on-premise est assez rapide : environ 6 à 7 minutes.

Deux groupes de ressources méritent votre attention :

Note : le déploiement de l’application est toujours sur la machine virtuelle Hyper-V via des scripts. Prévoyez au moins une bonne heure, le temps que le tout se termine.

Tâche 2 – Vérifiez l’environnement on-premise :

Une fois le déploiement et les scripts internes terminés, il est facile de contrôler le bon déploiement de l’application on-premise.

Rendez-vous pour cela dans le groupe de ressources SmartHotelHostRG, puis cliquez sur la machine virtuelle Hyper-V appelée SmartHotelHost :

Copiez l’adresse IP publique de la machine virtuelle Hyper-V :

Ouvrez votre navigateur internet, puis collez l’adresse IP publique dans la barre d’adresse. Un site web en HTTP doit s’ouvrir en affichant des réservations fictives d’hôtel :

Note : Les données affichées varient selon le jour ou la période, le tableau peut même être vide.

Tâche 3 – Vérifiez l’environnement cible sur Azure :

Un second tour rapide dans l’autre groupe de ressources Azure SmartHotelRG vous affiche quelques futures ressources exploitées par la suite, dont la base SQL utilisée comme service PaaS :

Si tout est bon pour vous, bravo, vous pouvez continuer sur le prochain exercice (Exercice 1) juste ici????. Pour rappel, voici quelques liens utiles pour ne pas vous perdre :

Atelier Azure Migrate :
- Lien GitHub pour les consignes de l’atelier
- Lien GitHub pour le déploiement des ressources
Articles du blog sur l’atelier d’Azure Migrate :

Azure Migrate – Exercice 3 Migration des serveurs + finalisation

Nous voilà dans la dernière ligne droite de cet atelier. Il ne nous reste qu’à migrer les machines virtuelles restantes vers Azure, grâce à Azure Migrate.

Comme dit plus haut, nous devons donc encore migrer les machines virtuelles suivantes, déjà estimées par Azure Migrate :

SmartHotelWeb1
SmartHotelWeb2
UbuntuWAF

Tâche 1 – Créer un compte de stockage :

La transition des données des 3 machines virtuelles passe par un compte de stockage Azure. Pour cela, cliquez sur l’icône suivant dans la barre latérale gauche du portail Azure :

Cliquez-ici pour créer un compte de stockage Azure :

Renseignez tous les champs en prenant soin de reprendre la même région Azure que votre base de données SQL récemment migrée, puis cliquez sur Suivant :

Retirer la fonction de Soft Delete pour le stockage objet, puis passez directement à la validation :

Lancez la création de votre compte de stockage :

Attendez quelques secondes, puis constatez sa création :

Tâche 2 – Créer un point de terminaison privé :

Afin que l’application communique entre les serveurs et la base de données Azure SQL, nous avons besoin d’établir une seconde communication via un point privé.

Nous pourrions utiliser le point d’accès public à Azure SQL, mais le but est aussi d’apporter une couche de sécurité supplémentaire.

Dans le portail Azure, recherchez votre base de données SQL :

Cliquez sur le nom de votre serveur Azure SQL :

Comme pour la précédente tâche 4 de l’exercice 2, créez un point de terminaison privé :

Nommez-le différemment du premier point de terminaison privé, puis cliquez sur Suivant :

Validez les champs ci-dessous, puis cliquez sur Suivant :

Indiquez les éléments du futur réseau de votre application, puis cliquez sur Suivant :

Laissez à Oui la création d’une zone de DNS privée, puis cliquez sur Suivant :

Lancez la création du point de terminaison privé, puis attendez :

Cliquez ici pour voir les caractéristiques du nouveau point de terminaison privé :

Cliquez comme ceci pour retrouver le FQDN de ce point de terminaison privé :

Tâche 3 – Enregistrez l’hôte Hyper-V sur Azure Migrate :

Retournez sur votre projet d’Azure Migrate pour entamer les premières étapes de migration des serveurs. Cliquez ici pour ajouter le serveur Hyper-V dans le processus de migration :

Sélectionnez le type Hyper-V, puis choisissez la région de votre choix :

Cette étape créée les ressources Azure suivantes :

Copiez l’URL disponible juste ici :

Sur le même écran, cliquez-ici pour télécharger la clef de registre utilisée pour l’enrôlement.

Retournez sur la session de bureau à distance sur le serveur Hyper-V, lancez le navigateur Google Chrome, puis coller l’URL précédemment copiée :

Lancez l’installation de l’application Azure Site Recovery :

Lancez l’installation d’Azure Site Recovery :

Cliquez pour enregistrer le serveur Hyper-V :

Collez le fichier contenant la clef de registre d’Azure Site Recovery sur le bureau de la session Hyper-V :

Recherchez le fichier de clef de registre, puis cliquez sur Suivant :

Cliquez sur Suivant :

Attendez quelques minutes :

Une fois terminé, retournez sur le portail Azure, actualisez la page suivante plusieurs fois si nécessaire, puis finalisez l’enregistrement du serveur Hyper-V :

Attendez quelques minutes que le traitement se termine :

Retournez sur la page principale de votre projet d’Azure Migrate, puis constatez l’apparition des serveurs virtuels hébergés sur votre machine Hyper-V :

Tâche 4 – Activez la réplication de Hyper-V :

Les machines virtuelles présentes dans le serveur Hyper-V sont bien remontées dans Azure Migrate. Elles ont maintenant besoin d’être répliquées via Azure Site Recovery.

Pour démarrer la configuration, cliquez sur Répliquer :

Continuez la démarche :

Choisissez Hyper-V, puis cliquez sur Suivant :

Renseignez les champs, cochez les 3 machines virtuelles remontées depuis l’estimation Azure Migrate, puis cliquez sur Suivant :

Complétez tous les champs comme indiqué ici, puis cliquez sur Suivant :

Complétez les informations attendues des 3 machines virtuelles, dont la taille selon vos souhaits ou l’estimation d’Azure Migrate, puis cliquez sur Suivant :

Conservez tous les disques des 3 machines virtuelles, puis cliquez sur Suivant :

Cliquez sur Répliquer pour démarrer le processus :

La page d’accueil de votre projet d’Azure Migrate doit vous indiquer le démarrage de la réplication de 3 machines virtuelles :

Cliquez ici pour afficher plus d’informations sur la réplication :

Comme le status ci-dessous l’indique, le premier point de réplication est toujours en cours :

En attendant que cela se termine, une consultation dans le service Azure Site Recovery créé par Azure Migrate montre bien le démarrage de réplications des 3 machines virtuelles :

Le compte de stockage créé précédemment contient bien 3 contenaires, un par machine virtuelle, pour assurer le tampon dans la réplication :

Retournez sur Azure Migrate, puis attendez que le statut de réplication de vos 3 machines virtuelles change :

Tâche 5 – Configurez des adresses IP locale s des VMs Azure :

L’affectation d’adresses IP locales sur les machines virtuelles Azure est nécessaire pour maitriser les liaisons réseaux entre les composants de notre architecture cible.

Cliquez sur la machine virtuelle smarthotelweb1 :

Cliquez ici pour éditer la configuration réseau :

Cliquez sur la carte réseau de la machine virtuelle :

Renseignez l’adresse IP locale 192.168.0.4, cliquez sur OK, puis sauvegardez la configuration :

Répétez ces étapes pour configurer les adresses IP privées des 2 autres machines virtuelles :

smarthotelweb2 : utilisez l’adresse IP privée 192.168.0.5
UbuntuWAF : utilisez l’adresse IP privée 192.168.0.8

Tâche 6 – Migration des 3 serveurs :

L’heure est maintenant venue de faire la migration des 3 machines virtuelles Hyper-V vers des machines virtuelles sur Azure.

Cliquez sur Migrer depuis votre projet Azure Migrate :

Sélectionnez les 3 machines virtuelles, puis cliquez sur Migrer :

Le portail Azure vous affiche 3 nouvelles notifications en relation avec votre action :

Un tour dans le journal des travaux d’Azure Migrate nous montre la mise en route de la migration :

L’ordre d’arrêt donné par Azure Migrate a bien été respecté par Hyper-V :

Un peu moins de 10 minutes plus tard, le journal des évènements d’Azure Migrate nous indique le succès de la migration Azure :

L’affichage des machines virtuelles montre les 3 nouvelles VMs Azure selon les configurations établies dans Azure Migrate :

Il ne nous reste qu’à modifier la configuration de l’application pour envoyer les requêtes vers la nouvelle adresse IP locale de la base de données SQL.

Tâche 7 – Configurez la connexion à la base de données :

Dans le cadre de notre atelier, la modification de l’adresse IP mémorisée pour la base de données SQL se fait directement sur la machine web. Il vous faut donc s’y connecter.

L’atelier Azure Migrate contient le déploiement du service Azure Bastion. Pour rappel, voici l’utilisé de ce service pour se connecter à une machine virtuelle Windows ou Linux :

Avant de s’y connecter, récupérez les éléments de connexion de la base de données Azure SQL :

Copiez la chaîne de connexion :

Retournez sur la liste des machines virtuelles, puis cliquez sur smarthotelweb2 pour vous y connecter via Azure Bastion :

Une fois connecté dans la session de bureau à distance sur la machine virtuelle smarthotelweb2, ouvrez l’explorateur de fichier dans le dossier suivant :

C:\inetpub\SmartHotel.Registration.Wcf

Ouvrez le fichier Web.config avec Notepad, puis remplacer comme ceci sans oublier de modifier le mot de passe demo!pass123 :

Avant :

Après :

Sauvegardez le fichier de configuration Web.config :

Inutile d’effectuer la même opération sur la machine smarthotelweb1.

Pour que la résolution du nom de la base de données SQL se fasse bien, retournez sur la zone DNS privée créée par le point de terminaison privé, puis ajoutez le réseau virtuel contenant les 3 machines virtuelles :

Configurez le lien comme ceci, puis cliquez sur OK :

Tâche 8 – Configurez l’adresse IP publique et testez l’application SmartHotel :

La tâche 8 de l’atelier Azure Migrate vous propose de remplacer le serveur Linux par un service PaaS d’Azure : Application Gateway avec Web Application Firewall (WAF) juste ici.

Pour ma part, je vous propose de conserver le serveur Linux et de lui rajouter une adresse IP publique.

Pour cela, rendez-vous dans la configuration réseau de votre machine virtuelle Linux UbuntuWAF, puis cliquez sur sa carte réseau :

Cliquez sur la configuration IP de la carte réseau :

Ajoutez une adresse IP publique, cliquez sur OK, puis sauvegardez :

Retournez sur la page de la machine virtuelle UbuntuWAF, puis copier l’adresse IP publique :

Ouvrez un nouvel onglet de votre navigateur internet, puis constatez le bon fonctionnement de l’application :

L’application est bien fonctionnelle et les liaisons entre les composants Azure sont bien établies.

Tâche 9 – Étapes post-migration :

Un certain nombre d’étapes de post-migration doivent être réalisées avant que les services migrés soient prêts à être utilisés en production. Ces étapes comprennent :

L’installation de l’agent Azure VM
Nettoyage des ressources de migration
Activation de la sauvegarde et de la reprise après sinistre
Le chiffrement des disques de la VM
S’assurer que le réseau est correctement sécurisé
S’assurer que la bonne gouvernance des abonnements est en place, comme le contrôle d’accès basé sur les rôles et la politique Azure.
Examiner les recommandations d’Azure Advisor et du Security Center.

Conclusion

Cet atelier est un bon moyen de tester et comprendre le service Azure Migrate avec une architecture IT simple via un exercice facilement réalisable par tous.

Ayant réalisé celui-ci plusieurs fois, je vous conseille d’en faire de même afin de bien comprendre comment Azure Migrate opère par le biais de plusieurs services, compte le compte de stockage ou Azure Site Recovery.

Tâche 10 : Nettoyer les ressources Azure

Si vous ne supprimez pas les ressources créées pendant l’atelier, la facturation se poursuivra.

Pour cela, supprimez les groupes de ressources suivants :

SmartHotelHostRG contenant le SmartHotelHost.
BastionRG contenant le Bastion Azure.
SmartHotelRG contenant les VM migrées
AzureMigrateRG contenant les ressources Azure Migrate

Azure Migrate – Exercice 2 Migration de la base de données SQL

La seconde partie de cet atelier consiste à basculer la base de données SQL vers Azure. Il s’agit donc de l’exercice 2.

Nous aurions pu migrer la machine virtuelle contenant le serveur SQL vers Azure en utilisant une machine virtuelle Azure (IaaS). Mais l’atelier se veut innovant et vous propose une migration vers le service PaaS, Azure SQL Database.

Il existe de nombreux avantages à l’utilisation d’un service managé par Microsoft, comme

Réduction possible de certains coûts.
Gestion par Microsoft des mises à jour du serveur SQL.

Par contre, certaines fonctionnalités sont inaccessibles dans un service PaaS. Prenez le temps de comparer les solutions disponibles avec vos besoins.

Pour réaliser la migration de données vers Azure, nous allons utiliser le service Azure Database Migration Service. Celui-ci propose deux niveaux de tarification :

Standard : prend en charge les migrations hors connexion (également appelées « migrations uniques »). Le niveau tarifaire Standard, qui offre des options à 1, 2 et 4 vCores, est généralement disponible gratuitement pour les clients.
Premium : prend en charge les migrations hors connexion et en ligne (également appelées « migrations continues ») pour les charges de travail critiques pour l’entreprise nécessitant un temps d’arrêt minimal.

Tâche 1 : Enregistrez le fournisseur de ressources Microsoft.DataMigration

Avant de pouvoir effectuer la migration de la base de données, il est nécessaire de vérifier l’enregistrement du fournisseur de ressources adéquat.

En effet, Azure Database Migration Service fonctionne avec le fournisseur de services Microsoft.DataMigration.

Allez sur la page de votre souscription Azure, recherchez le menu Fournisseurs de ressources et enregistrez Microsoft.DataMigration si cela n’est pas déjà fait :

Note : Cela peut également être fait par une commande Power Shell via Azure Cloud Shell :

Register-AzResourceProvider -ProviderNamespace Microsoft.DataMigration

Attendez quelques minutes, puis réactualisez la page :

Tâche 2 – Créez le service Database Migration Service :

Les fournisseurs de services sont eux aussi divisés en plusieurs ressources. L’activation antérieure d’un fournisseur de ressources n’active pas systématiquement tous leurs nouveaux services. C’est pour cela que les fonctions Désenregistrer / Enregistrer existent.

Dans le doute, vous pouvez le Désenregistrer :

Puis l’Enregistrer à nouveau :

Ce contrôle d’enregistrement des services d’un fournisseur de ressources est possible via une commande PowerShell :

Get-AzResourceProvider -ProviderNamespace Microsoft.DataMigration | Select-Object ProviderNamespace, RegistrationState, ResourceTypes

Ensuite, utilisez la base de recherche du portail Azure pour retrouver le service Azure Database Migration Service :

Cliquez sur Créer :

Pour cet atelier, utilisez le Service de migration de base de données classique :

Remplissez les champs suivants en lui donnant le nom SmartHotelDBMigration, puis allez sur l’onglet Réseaux :

Sélectionnez le réseau / sous réseau suivant, puis pour lancer la création :

Attendez quelques minutes que la création se termine :

Une fois le service créé sous Azure, nous allons avoir besoin d’un outil pour gérer la partie migration au niveau des serveurs on-premise. La tâche 3 va vous montrer cela.

Tâche 3 – Evaluez la base de données à l’aide de Data Migration Assistant :

Data Migration Assistant (DMA) est lui aussi un outil d’estimation, mais dédié aux bases de données.

Retournez sur le service Azure Migrate, puis cliquez-ici pour ajouter l’outil DMA :

Sélectionnez-le, puis cliquez sur Ajoutez l’outil :

Celui-ci apparaît alors dans la section base de données sous votre projet Azure Migrate :

Faites-en de même pour l’outil DMA dans la partie Migration :

Retournez sur la connexion RDP de la machine virtuelle Hyper-V on-premise SmartHotelHost, puis ouvrez le menu Démarrer pour lancer Google Chrome :

Allez sur la page web suivante, puis téléchargez la version Runtime .NET v4.8 :

Ouvrez l’exécutable d’installation :

Attendez que la décompression se termine :

Acceptez les Termes et Conditions, puis lancez l’installation :

Attendez quelques minutes :

Terminez l’installation, puis acceptez le redémarrage de la machine Hyper-V :

Retournez dans le menu Bases de données d’Azure Migrate, puis cliquez sur Estimer :

Copiez l’URL de téléchargement de DMA :

Attendez deux minutes environ, puis reconnectez-vous à la machine Hyper-V en RDP :

Réouvrez Google Chrome, puis rentrez l’URL de DMA précédemment copiée pour lancer son téléchargement :

Lancez l’installation de DMA, puis cliquez sur Suivant :

Acceptez les Termes et conditions :

Lancez l’installation de DMA :

Terminez l’installation sans cocher la case de lancement de DMA :

Toujours depuis la machine virtuelle Hyper-V, ouvrez l’explorateur de fichiers, puis rendez-vous dans le dossier suivant :

C:\Program Files\Microsoft Data Migration Assistant

Ouvrez le fichier Dma.exe.config avec Notepad :

Recherchez la chaîne de texte Azure Migrate :

Retirez les commentaires sur la clef EnableAssessmentUploadToAzureMigrate comme ceci, puis sauvegardez le fichier Dma.exe.config :

Avant :

<!-- <add key="EnableAssessmentUploadToAzureMigrate" value="true"/> -->

Après :

<add key="EnableAssessmentUploadToAzureMigrate" value="true"/>

Toujours sur votre session RDP de la machine Hyper-V, lancez le programme DMA depuis l’icône ajouté automatiquement sur le bureau :

Cliquez-ici pour démarrer un nouveau projet DMA :

Nommez le projet SmartHotelAssessment, puis configurez-le comme ceci :

Cliquez sur Suivant :

Créez une connexion au serveur SQL avec le mot de passe demo!pass123 :

Cochez les deux cases, puis cliquez sur Ajouter :

Démarrez l’estimation de la base de données SQL on-premise :

Attendez que le traitement se termine :

Quelques secondes plus tard, car la base de données de l’atelier est très petite, l’estimation est terminée, cliquez sur Téléverser dans Azure Migrate :

Cliquez sur Connecter dans la section Azure :

Renseignez votre identifiant Azure utilisé pour cet atelier :

Remplissez les champs, puis cliquez sur Téléverser :

Retournez sur Azure Migrate, puis lancez un rafraîchissement de la page :

Constatez l’apparition de l’estimation de la base de données SQL :

L’estimation de la base de données SQL est bien incorporé à notre projet Azure Migrate. Fort de ce résultat, il nous est maintenant possible de la migrer grâce à DMS.

Tâche 4 : Créez un projet de migration DMS

Ayant créé le service Azure Database Migration Service (DMS) en Tâche 2, nous allons pouvoir migrer notre base de données SQL grâce à lui. Avant cela, nous avons besoin d’établir une connexion réseau entre le futur serveur SQL (Azure SQL) et Azure DMS.

Pour cela, depuis le portail Azure, rendez-vous dans le groupe de ressources SmartHotelRG, puis sélectionnez votre serveur SQL :

Dans la section Réseaux, cliquez sur Accès privé pour en ajouter un nouveau :

Donnez-lui le nom SmartHotel-DB-for-DMS, puis cliquez sur l’onglet Ressource :

Remplissez les champs comme ci-dessous, puis cliquez sur l’onglet Réseau virtuel :

Sélectionnez le réseau virtuel DMSvnet, puis cliquez sur l’onglet DNS :

Créez une nouvelle Zone DNS privée, puis continuez :

Lancez la création :

Une fois la création terminée, vérifiez dans la zone DNS privée que le serveur de la base de données Azure SQL a bien l’adresse IP privée 10.1.0.5 :

Pour des questions de sécurité, retirez l’accès publique au serveur Azure SQL, que l’on n’utilisera pas dans notre atelier :

Retournez sur le service Azure Database Migration Service (DMS), puis cliquez sur Nouveau projet de migration :

Renseignez les champs du projet comme ceci, puis cliquez sur Créer :

Renseignez les informations sur la source SQL avec le mot de mot de passe demo!pass123 :

*Le service DMS se connecte à l’hôte Hyper-V, qui a été préconfiguré avec une règle NAT pour transmettre les demandes SQL entrantes (port TCP 1433) à la VM SQL Server.*

Choisissez la seule base de données disponible :

Renseignez le nom unique votre serveur Azure SQL avec le mot de passe demo!pass123 :

Cliquez sur Sauvegarder le projet :

La création du projet dans DMS est maintenant terminée, il nous reste plus qu’à passer à l’action pour la migration de données.

Cette opération va s’effectuer sur deux tâches :

migration du schéma des tables de la base de données, puis migration des données en elles-mêmes.

Il est donc bien possible d’effectuer les deux actions en une, ou aussi d’espacer ces deux tâches dans le temps, pour migrer les données définitive le jour J.

Tâche 5 – Migrez le schéma de la base de données SQL :

Comme indiqué précédemment, cette étape est nécessaire pour le transfert de données. Pour cela, cliquez-ici pour créer et démarrer cette nouvelle activité :

La configuration étant déjà faite lors de la création du projet, il ne vous reste qu’à remettre le mot de passe de l’utilisateur sa du serveur SQL demo!pass123, puis cliquez sur Suivant :

Pour la base de données cible, même mot de passe de l’utilisateur sa du serveur SQL demo!pass123, puis cliquez sur Suivant :

Sélectionnez la base de données cible et reprenez le schéma de la source, puis cliquez sur Suivant :

Nommez l’activité SchemaMigration, puis lancez le démarrage de celle-ci :

Suivrez l’évolution de celle-ci, cliquez sur Rafraîchir :

Environ une minute plus tard, vérifiez que le statut de l’activité change en Complété :

Sur la base de données Azure SQL Database, vous pouvez voir le tout petit pic provoqué par cette activité :

Il nous reste maintenant qu’à migrer les données vers la base de données Azure SQL Database. Comme rappelé plus haut, la version gratuite d’Azure Database Migration Service ne nous autorise que des migrations à froid. Ce qui ira très bien dans le cadre de notre atelier.

Tâche 6 – Migrez les données sur site :

Toujours dans Azure Database Migration Service, cliquez-ici pour démarrer la seconde activité de migration des données :

De la même façon que lors de la première activité, la configuration est déjà faite, il ne vous reste qu’à remettre le mot de passe de l’utilisateur sa du serveur SQL demo!pass123, puis cliquez sur Suivant :

Pour la base de données cible, toujours le même mot de passe de l’utilisateur sa du serveur SQL demo!pass123, puis cliquez sur Suivant :

Vérifiez que la base de données de notre application d’hôtellerie est bien cochée, puis cliquez sur Suivant :

Pour la base de données cible, même mot de passe que pour l’utilisateur sa : demo!pass123, puis cliquez sur Suivant :

Sélectionnez la base de données cible, puis cliquez sur Suivant :

Ne cochez qu’une seule table sur deux car seule celle-ci contient les réservations d’hôtels :

Nommez l’activité DataMigration, puis lancez le démarrage de celle-ci :

Environ une minute plus tard, vérifiez que le statut de l’activité change en Complété :

Si tout s’est bien passé, les données de notre application sont maintenant chargées dans Azure SQL Database. Il ne nous reste qu’à retirer la connection privée établie entre DMS et Azure SQL Database.

Retournez sur le serveur Azure SQL et retirer cette liaison comme ceci :

La migration des données est la première véritable étape de transfert de notre architecture dans Azure.

Pourquoi avoir transféré les données avant les autres serveurs ?

Car le transfert de serveur sera directement précédé de la bascule de notre application. Et comme l’application a besoin des données pour fonctionner, c’est pour cela que les opérations sont ordonnées dans cet ordre.

Nous voilà dans la dernière ligne droite de cet atelier. Il ne nous reste qu’à migrer les machines virtuelles restantes vers Azure, toujours grâce à Azure Migrate : Exercice 3.

Pour rappel, voici un rappel des liens de cet atelier pour ne pas vous perdre :

Atelier Azure Migrate :
- Lien GitHub pour les consignes de l’atelier
- Lien GitHub pour le déploiement des ressources
Articles du blog sur l’atelier d’Azure Migrate :

Changez la résidence de vos données 365

Bonne nouvelle en ce début du mois de novembre, Microsoft a réouvert le processus gratuit de migration de données 365 pour les tenants existants. De quoi parle-t-on exactement ? En quelques mots, ces dernières années, Microsoft a ouvert de plus en plus de centres de données, et cela allonge donc automatiquement la liste des pays. Cet avantage permet aux entreprises de choisir dans quel pays les données 365 seront stockées.

Qu’est-ce que la résidence des données 365 ?

Avant toute chose, Microsoft liste leurs termes et définitions en relation avec la résidence de données 365 juste ici.

Important : les services 365 s’exécutent sur l’ensemble des centres de données Microsoft. A ce titre, les données peuvent donc être stockées dans plusieurs centres de données dans le cadre de transit :

La résidence des données fait ici donc référence à l’emplacement géographique où les données 365 sont stockées au repos.

Pourquoi s’intéresser à la résidence des données 365 ?

La résidence des données est cruciale pour les gouvernements, les entreprises du secteur public, les organismes d’éducation ou encore les entreprises travaillant dans des secteurs réglementés. Cette exigence est alors indispensable afin d’accroître la protection des informations personnelles et/ou sensibles.

Quelle est la résidence des données 365 par défaut ?

Lorsqu’on créé un nouveau tenant, il vous est systématiquement demandé de spécifier un pays durant le processus de création.

Important : Une fois le tenant créé, la zone géographique par défaut ne peut plus être modifiée.

Pourquoi changer la résidence des données ?

De plus, de nombreux pays exigent de leurs entreprises afin qu’elles se conforment aux lois, aux réglementations ou aux normes de secteur qui régissent explicitement l’emplacement du stockage des données.

Changer la résidence des données 365 est alors utile pour se conformer à ces règles, mais offre une également proximité entre le stockage des données et les utilisateurs finaux.

Qu’est-ce que le programme de déplacement hérité Data Residency ?

Coïncidant avec le lancement du module complémentaire Microsoft 365 Advanced Data Residency, le programme de déplacement n’est plus proposé lors du lancement de nouvelles régions de centre de données locales.
Microsoft Learn

Cette ouverture permettait donc de pouvoir migrer gratuitement les données de la région macro vers une région de centre de données locale qui correspond au pays d’inscription initial.

Autrement dit, de l’Europe vers la Suisse, la France, …

Comment activait-on cette demande de migration ?

Les clients éligibles voyaient cette option dans leur Centre d’administration Microsoft 365. Cocher cette case permettra de demander que leurs données applicables soient déplacées vers leur nouvelle région de centre de données :

Quand est-ce que la migration allait être opérée ?

Comme le monde la copie d’écran du tenant ci-dessus, la migration du tenant pouvait prendre jusqu’à 24 mois, à partir de la date d’échéance de la demande. La bonne nouvelle est que Microsoft a réouvert ce service gratuit, et ce pour une dernière fois !

Pendant combien de temps je peux activer cette option ?

Le tableau ci-dessous affiche la liste des pays éligibles et les dates associées. Il faut donc cocher la case précédente avant la fin de la période du pays qui vous concerne :

Important : Il s’agit de la dernière fenêtre de migration gratuite possible !!! Après ces dates, ce service existera toujours, mais sera payant ????

Et si j’ai d’autres questions concernant la migration ?

Microsoft met à disposition une FAQ concernant ce service et peut déjà répondre à certaines de vos interrogations ????

Bonne migration !

Restaurez-vous dans une seconde région grâce au Cross Region Restore

Qui a dit que le Cloud était sans aucun danger ? Qui a dit que tout était sauvegardé nativement dans le Cloud ? De plus, on n’imagine pas non plus perdre une région entière d’Azure. Malgré tout, des contre-mesures doivent être mises en place pour prévenir le risque. Plusieurs méthodes existent déjà pour augmenter la résilience d’une infrastructure IT. Dans cet article, nous allons prendre le temps de nous intéresser à une fonctionnalité spécifique du backup d’Azure, appelée Cross Region Restore.

Comme l’indique Microsoft dans sa documentation, l’option de Restauration inter-région (Cross Region Restore) permet de restaurer des données dans la région jumelée Azure à votre site de production. Ce service est donc disponible via Azure Backup. Une coffre de sauvegarde est donc déployé dans la région de production pour gérer la passerelle des données. A l’heure où ces lignes sont écrites, cette fonctionnalité supporte les sources de données suivantes :

Machines virtuelles Azure (disponibilité générale)
Bases de données SQL, hébergées sur des machines virtuelles Azure (préversion)
Bases de données SAP HANA, hébergées sur des machines virtuelles Azure (préversion)

*Célèbre Viaduc de Millau en France, au-dessus des nuages.*

Régions paires d’Azure

Comme indiqué par Microsoft, une région Azure comporte un ensemble d’un ou plusieurs datacenters connectés via un réseau dédié à faible latence :

Le nombre de datacenters au sein d’une région Azure est variable.

Liste des régions Azure :

Géographie	Paire régionale A	Paire régionale B
Asie-Pacifique	Asie Est (Hong Kong, R.A.S.)	Asie Sud-Est (Singapour)
Australie	Australie Est	Sud-Australie Est
Australie	Centre de l’Australie	Australie Centre 2*
Brésil	Brésil Sud	États-Unis – partie centrale méridionale
Brésil	Brésil Sud-Est*	Brésil Sud
Canada	Centre du Canada	Est du Canada
Chine	Chine du Nord	Chine orientale
Chine	Chine Nord 2	Chine orientale 2
Europe	Europe Nord (Irlande)	Europe Ouest (Pays-Bas)
France	France Centre	France Sud*
Allemagne	Allemagne Centre-Ouest	Allemagne Nord*
Inde	Inde centrale	Inde Sud
Inde	Inde Ouest	Inde Sud
Japon	Japon Est	Japon Ouest
Corée du Sud	Centre de la Corée	Corée du Sud
Amérique du Nord	USA Est	USA Ouest
Amérique du Nord	USA Est 2	USA Centre
Amérique du Nord	Centre-Nord des États-Unis	États-Unis – partie centrale méridionale
Amérique du Nord	USA Ouest 2	Centre-USA Ouest
Norvège	Norvège Est	Norvège Ouest*
Afrique du Sud	Afrique du Sud Nord	Afrique du Sud-Ouest*
Suisse	Suisse Nord	Suisse Ouest*
Royaume-Uni	Ouest du Royaume-Uni	Sud du Royaume-Uni
Émirats Arabes Unis	Émirats arabes unis Nord	Émirats arabes unis Centre*
Ministère de la défense des États-Unis	US DoD Est*	US DoD Centre*
Gouvernement américain	US Gov Arizona*	US Gov Texas*
Gouvernement américain	US Gov Iowa*	US Gov Virginie*
Gouvernement américain	US Gov Virginie*	US Gov Texas*

Note : Comme indiqué dans un précédent billet sur la région Azure Suisse Ouest, certaines régions offrent un accès restreint pour la prise en charge de scénarios client spécifiques : par exemple la récupération d’urgence. Ces régions ne sont disponibles que sur demande en créant une demande de support dans le portail Azure.

Tarification de la sauvegarde Azure et de la fonctionnalité CRR

Dans le cadre de sauvegarde de machines virtuelles Azure, Microsoft indique clairement dans sa brochure tarifaire que l’activation de la fonctionnalité CRR entraine une évolution du SKU du compte de stockage, pour permettre la sauvegarde et la lecture de vos données dans les deux régions. Pour vous aider à y voir plus clair, voici la décomposition tarifaire de la sauvegarde faite via le service Azure Backup.

Azure facture en premier lieu l’instance sauvegardée, en fonction de sa taille :

Taille de chaque instance	Tarif Sauvegarde Azure par mois
Instance inférieure ou égale à 50 Go	CHF 7,3808 + stockage utilisé
Instance supérieure à 50 Go mais inférieure ou égale à 500 Go	CHF 14,7615 + stockage utilisé
Instance supérieure à > 500 Go	CHF 14,7615 pour chaque incrément de 500 Go + stockage utilisé

L’exemple de calcul donné par Microsoft est assez clair :

Exemple : si vous avez 1,2 To de données dans une instance spécifique, le coût correspond à CHF 44,29 (+ le stockage consommé, voir plus bas). Vous êtes alors facturé CHF 14,77 pour chacun des 2 incréments de 500 Go et CHF 14,77 pour les 200 Go de données restants.
44.29 CHF = 14.76 x 3 (3 incréments de 500 Go)

Est donc également facturé le volume de données sauvegardées. On ne parle plus ici de la taille de l’instance sauvegardée, mais bien de la taille totale prise par l’ensemble des sauvegardes journalières, hebdomadaires, mensuelles et annuelles. Le volume total va alors dépendre de différents facteurs comme :

La fréquence des sauvegardes
La durée de rétention des sauvegardes
Le facteur de compression des données brutes

Selon le niveau de protection désiré, le coût du stockage au Go peut lui aussi varier :

	Niveau Standard	Niveau Archive
LRS	CHF 0,0331 par Go	CHF 0,0043 par Go
ZRS^Préversion	CHF 0,0414 par Go	S.O.
GRS	CHF 0,0662 par Go	CHF 0,0085 par Go
RA-GRS	CHF 0,0840 par Go	CHF 0,0085 par Go

Si vous activez l’option CRR sur votre coffre de sauvegarde, le coût au Go sera obligatoirement en RA-GRS.

Activation de Cross Region Restore

Vous êtes maintenant décidé à activer cette fonctionnalité ? Nous allons donc voir le processus d’activation de cette dernière, étape par étape, puis nous finirons par un test.

Etape I : Création d’une machine virtuelle de départ

Notre point de départ une machine virtuelle sur la région North Europe. Si vous n’avez jamais déployé de machine virtuelle dans Azure, je vous conseille de suivre le Quickstart, mis à disposition par Microsoft.

*Comme indiqué dans cette copie d’écran, j’ai déployé une VM dans la région Azure « North Europe ».*

Etape II : Création et configuration d’un coffre de sauvegarde Recovery Services Vault

Ce coffre de sauvegarde va nous servir pour piloter la sauvegarde de la machine virtuelle initiale. Ce coffre de sauvegarde doit être créé dans la même région Azure que la machine virtuelle, à l’inverse d’un coffre dédié à une solution de Disaster Recovery. Voici le processus de création de celui-ci étape par étape :

*Utilisez la barre de recherche pour créer cette nouvelle ressource.*

Renseignez les champs ci-dessous pour terminer la création de votre coffre de sauvegarde :

*Pensez donc à positionner votre coffre dans la même région Azure que votre machine virtuelle.*

Une fois que votre coffre de sauvegarde est créé, vous allez pouvoir activer la fonctionnalité de Cross Region Restore via le propriété de configuration de ce dernier :

*Cette opération est à faire avant la mise en place de sauvegarde.*

Deux options sont ici présentes dans la configuration du coffre de sauvegarde :

Type de réplication (LRS / ZRS / GRS) : nous parlons ici du nombre total de copies des sauvegardes et de leur localisation géographique sur l’infrastructure Azure
Cross Region Restore : Oui / Non

**Important** : ces options sont uniquement modifiables avant le démarrage de la première sauvegarde. Cela n’est plus possible de les changer après.

Etape III : Activation et démarrage de la sauvegarde

Une fois les options paramétrées, nous allons activer la sauvegarde de la machine virtuelle initiale. L’opération peut se faire depuis le coffre de sauvegarde ou directement sur la machine virtuelle :

L’écran suivant commence par détailler la police de sauvegarde à appliquer pour cette machine virtuelle. Il est question ici de définir le nombre de sauvegardes à faire et de leur rétention. Aucune police n’est créée à l’origine, vous pouvez donc la configurer directement via ce processus :

*Par défaut, seule une sauvegarde journalière est définie.*
*Elle sera conservée pendant 30 jours.*

L’ajout de sauvegardes aura un impact sur le coût total de la sauvegarde.
Une rétention plus longue augmente le coût.

Une fois la police créée, il est maintenant temps de sélectionner la machine virtuelle initiale pour continuer pour votre test :

*Seules les machines virtuelles créées dans la région North Europe seront présentées dans cette liste de choix.*

L’activation de la sauvegarde provoque la création automatique de ressources Azure :

Un retour dans le coffre de sauvegarde indique les objets sauvegardés et donc la bonne prise en compte de notre machine virtuelle initiale.

Note : Vous pouvez déjà apercevoir ici un filtre sur l’affichage de la première ou de la seconde région Azure.

Un clique sur la ligne « Azure Virtual Machine » affiche la machine virtuelle sauvegardée et le statut actuel de l’état de sauvegarde de cette dernière :

*Un avertissement est présent car la première sauvegarde journalière n’a pas encore été faite.*
Cette sauvegarde sera déclenchée selon la police de sauvegarde.

Afin d’aller plus loin dans notre démonstration de la fonctionnalité CRR, nous allons devoir déclencher la première sauvegarde manuellement :

*Cette sauvegarde est déclenchée manuelle*ment, la durée de rétention est modifiable.

*Le schéma ci-dessous nous montre l’étape de création du snapshot, faite au moment de la sauvegarde.*
*Celui-ci reste à « proximité » des disques de la machine virtuelle.*
*Les données seront transférées au coffre de sauvegarde ultérieurement.*

Vous pouvez suivre l’avancement de la sauvegarde en consultant les jobs de sauvegarde. Le processus de sauvegarde initial est rapide, mais le transfert de données vers le coffre prend un peu de temps :

Une heure plus tard, la première sauvegarde de ma machine virtuelle est entièrement terminée et transférée vers le coffre de sauvegarde :

*Le snapshot est fait et les données de sauvegarde ont bien été transférées au coffre de sauvegarde.*

L’écran ci-dessous indique que l’avertissement précédent a disparu et que la sauvegarde faite manuellement est de type « Application consistent ».

Au passage, voici un rappel des différents types de cohérence de sauvegarde :

Instantané	Détails
Cohérence des applications	Les sauvegardes cohérentes dans les applications capturent le contenu et les opérations d’E/S en attente de la mémoire. Les instantanés de cohérence d’application utilisent l’enregistreur VSS (ou un pré/post-script pour Linux) pour vérifier la cohérence des données d’application avant une sauvegarde.
Cohérence du système de fichiers	Les sauvegardes cohérentes de système de fichiers assurent la cohérence en prenant une capture instantanée de tous les fichiers au même moment.
Cohérence en cas d’incident	Des instantanés de cohérence des incidents sont pris généralement si une machine virtuelle Azure s’arrête au moment de la sauvegarde. Seules les données déjà présentes sur le disque au moment de la sauvegarde sont capturées et sauvegardées.

Un retour dans le coffre de sauvegarde nous montre un premier travail effectué dans la seconde région Azure :

Un clic sur l’objet donne toutes les informations relatives aux sauvegardes :

La sauvegarde étant faite ce matin, le point de sauvegarde n’est pas encore transposé sur la seconde région Azure. Il va falloir faire preuve de patience pour finir la restauration de la machine virtuelle sur la seconde région Azure :

Etape IV : Préparation à la restauration de la machine virtuelle

L’objectif de ce Cross Region Restore est bien de créer une nouvelle machine virtuelle dans la seconde région Azure. Vous trouverez toutes les informations relatives à restauration ici. En attendant de pouvoir avancer sur la restauration, j’en profite pour créer un compte de stockage, nécessaire à la future restauration.

Afin de faciliter la lecture ultérieure au travers du portail Azure, je vous conseille de créer les prochaines ressources dans un nouveau groupe de ressources, lui-même placé dans la seconde région Azure. Ce compte de stockage doit donc être créé de la façon suivante :

*Le compte stockage doit être sur la **seconde** région Azure, de performance **Standard** et en redondance **LRS**.*

Etape V : Restauration de la machine virtuelle sur la seconde région Azure

Quelques heures plus tard, je suis enfin en mesure de continuer l’opération de restauration. Je retourne donc sur le coffre de sauvegarde pour constater que la seconde région comporte bien le premier point de restauration :

*Un nouveau clique sur l’item « **Azure Virtual Machine** » montre le premier point de restauration transféré entre les deux régions.*

*L’opération de transfert entre les régions aura donc pris plusieurs heures, mais s’est fait de manière transparente.*

Note : La restauration ne peut se faire que si certaines ressources sont déjà en place dans la région de destination. Nous avions déjà vu dans l’étape précédente la création d’un compte stockage, utilisé en tampon. A celui-ci, il faudra également créer un réseau virtuel, pour relier la nouvelle machine virtuelle :

*Pensez donc à créer le VNet au préalable pour terminer cette restauration.*

Afin de suivre l’avancement de la restauration, un tour dans les travaux du coffre de sauvegarde permet d’obtenir plus d’informations :

*Les jobs de **CRR** ne se trouvent pas dans la page principale, mais dans la liste de travaux de la région secondaire.*

*Cette opération prend quelques dizaines de minutes.*

*Ce processus n’est pas aussi rapide qu’un failover déclenché par Azure Site Recovery.*
*Son objectif est lui aussi différent.*

*Le processus de restauration aura donc pris une peu moins de 30 minutes.*

Afin de constater la création des nouvelles ressources Azure, je retourne sur le nouveau groupe de ressources créé sur « West Europe ». J’y constate la présence d’une nouvelle machine virtuelle et de toutes ses ressources associées :

*Toutes les ressources présentes ici sont bien positionnées sur la seconde région Azure.*

*La nouvelle machine virtuelle est bien opérationnelle.*

Un essai de connexion RDP est possible :

Les codes d’administration sont les mêmes que ceux renseignés sur la machine virtuelle initiale.

*Je retrouve bien la session d’administration ????*.

Conclusion

Au final, la fonctionnalité Cross Region Restore d’Azure Backup fonctionne très bien entre région Azure. C’est une solution pour repartir en cas de désastre. A ne pas confondre avec une véritable solution de Disaster Recovery, elle permet par contre de conserver une meilleur contrôle des sauvegardes faites par Azure Backup.

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Backup ????

Vous déménagez de région ? Utilisez Azure Resource Mover

Dans cet article, nous allons détailler l’outil appelé Azure Resource Mover et regarder les étapes nécessaires à la migration de ressources Azure d’une région A à une région B.

Qu’est-ce qu’Azure Resource Mover ?

Microsoft a mis à disposition un outil très pratique, appelé Azure Resource Mover. Cet outil vous sera utile si vous souhaitez déplacer des ressources d’une région Azure à une autre. Vous trouverez l’article de documentation Microsoft via ce lien.

Voici également un petit rappel sur « Qu’est-ce qu’une région Azure ?«

Région Azure : Une région Azure est un ensemble de centres de données, déployés dans un périmètre défini par la latence et reliés par un réseau régional dédié. Avec plus de régions mondiales que tout autre fournisseur de cloud, Azure offre à ses clients la flexibilité de déployer des applications là où ils en ont besoin. Une région Azure a une tarification et une disponibilité de service distinctes.
Source Microsoft

*Carte des régions Azure à travers le monde. Cette carte évolue très régulièrement.*

Qu’apporte Azure Resource Mover dans un processus de migration intra-région ?

Ce nouvel outil facilite grandement le processus de migration puisqu’il fournit une interface unique avec un système d’étapes et de contrôle des dépendances. Cela permet donc de :

Réduire la complexité et le temps de migration
Identifier les dépendances des ressources Azure
Déplacer les ressources de manière groupée
Nettoyer automatiquement les ressources dans la région initiale
Fonctionner en mode Test : vous pouvez encore annuler si vous ne souhaitez pas effectuer la migration

Les autres types de migration sur Azure

Il existe des besoins autres que la migration sur une autre région. Microsoft met donc à disposition deux autres types de migration :

Déplacement de ressources Azure sur un autre groupe de ressources
Déplacement de ressources Azure sur une autre souscription Azure

Ce dernier cas peut s’avérer intéressant si l’on souhaite justement abandonner le paiement PAYG (Pay-As-You-Go ou encore appelé paiement à la demande par carte bancaire) pour s’orienter vers d’autres canaux de distribution, tels que le CSP ou encore EA.

Grandes étapes

Voici la liste des grandes étapes que vous allez déclencher dans Azure Resource Mover :

Création du projet de migration
Configuration des ressources de destination
Validation des dépendances
Migration (Préparation / Initiation / Confirmation)
Suppression des ressources initiales

Dans certains cas et également dans mon exemple plus bas, il est possible de relancer l’étape 4 à plusieurs reprises sous forme de cycle. Azure Resource Mover apporte donc une excellente visibilité sur les étapes et les cycles restants et leur ordonnancement.

Liste des ressources migrables avec Azure Resource Mover

À l’aide de Resource Mover, vous pouvez actuellement déplacer les ressources suivantes d’une région à une autre :

Machines virtuelles Azure et disques associés
Cartes réseau
Groupes à haute disponibilité
Réseaux virtuels Azure
Adresses IP publiques
Groupes de sécurité réseau
Équilibreurs de charge internes et publics
Bases de données Azure SQL et pools élastiques

Note : Vous ne pouvez pas sélectionner des disques managés comme ressources à déplacer entre des régions. Les disques sont cependant copiés lors d’un déplacement d’une machine virtuelle. Vous pourrez retrouver la liste complète avec tous les types de ressources Azure ici, accompagnés des 3 possibilités de migration.

*Processus de migration via Azure Resource Mover.*

Etape I : Création du projet de migration

Cette étape s’effectue directement dans le groupe contenant des ressources Azure à migrer. Il suffit alors de sélectionner les ressources et d’utiliser la fonction correspondante dans la barre d’action.

*Pour simplifier les étapes, il est préférable de regrouper au préalable toutes les ressources à migrer dans un seul et même groupe de ressources.*

L’écran suivant nous présente les informations de base sur les ressources sélectionnées et nous demande également de choisir la région de destination.

Il est indiqué dans les annotations que la migration des ressources sur une autre souscription peut être faite dans un second temps. Prenez donc le temps de la réflexion sur votre meilleur « itinéraire de migration ».

L’écran ci-dessous reprend la liste des ressources précédemment sélectionnées dans le groupe de ressources :

Dans mon exemple, une ressource est manquante dans cette liste, je peux cliquer sur le lien pour avoir plus d’informations.

Un encadré s’ouvre à droite et liste les ressources exclues par Azure Resource Mover. Cette information est précieuse car elle vous permet directement d’écarter ou de repenser certains projets de migration.

*Pas d’inquiétude dans mon cas puisque le disque rattaché à ma machine virtuelle sera bien copié.*

La confirmation sur l’écran suivant va lancer le projet et de vous proposer le démarrage de la phase suivante, déclenchée elle aussi à votre demande :

*Ce bouton ne déclenche aucun traitement irréversible 🙂*

Une fois ce traitement validé, l’étape II va pouvoir être déclenchée dans Azure Resource Mover.

Etape II : Configuration des ressources de destination

Cette étape est facultative. Elle permet néanmoins d’effectuer des modifications aux ressources créées. Dans mon exemple, je dispose d’une machine n’ayant pas de zone de disponibilité. Je veux migrer cette machine virtuelle en lui précisant sur quelle zone de disponibilité je la souhaite : Région « North Europe Zone 3 ».

*Un clique sur la configuration de la machine virtuelle m’ouvre l’écran ci-dessous.*

*Je spécifie ici la zone 3 au sein de la région North Europe.*

Je profite également pour faire une modification sur l’adresse IP publique rattachée à ma machine virtuelle. Souhaitant mettre en place cette VM dans une de zone de disponibilité, je dois changer le SKU de cette dernière en Standard pour que la migration se fasse sans souci :

Changement de SKU pour l’adresse IP publique en standard.

Etape III : Validation des dépendances

Comme dans beaucoup de cas, les ressources Azure sont interconnectées entre elles. L’exemple le plus évident est bien la machine virtuelle. De base, une machine virtuelle créé les ressources Azure suivantes :

Machine virtuelle
Disque OS
Carte réseau
Disque de données (facultatif)
Groupe de sécurité réseau (facultatif)
Adresse IP publique (facultative)

Le processus de validation des dépendances va donc vérifier que rien n’est oublié dans ce projet de migration.

*A partir de cet écran et comme indiqué en haut à gauche, nous sommes bien dans Azure Resource Mover.*

Une fois la validation des dépendances effectuée, il arrive que certaines erreurs remontent afin d’être résolues avant la migration. Un clique sur le lien vous donne toutes les informations nécessaires pour les comprendre.

*Dans le cas présent, cette erreur est considérée comme « normale » puisque cette alerte concerne le disque OS. Le processus va se donc régler de lui-même cette erreur par la suite.*

*D’autres erreurs peuvent aussi remonter. Ici par exemple une migration vers l’Asie m’est bloquée à cause de la taille de ma machine virtuelle.*

Etape IV : Migration

Comme vous le voyez dans la colonne Status sur toutes mes ressources Azure, il est indiqué que ces dernières sont en attente de la préparation au déplacement. Dans mon exemple de machine virtuelle, je dois effectuer la migration en deux cycles pour palier l’erreur du disque managé :

Cycle A : migration du groupe de ressources uniquement
Cycle B : migration des autres ressources

Cycle A – Préparation à la migration

Il s’agit de la première étape de la migration à proprement parlé.

Je commence donc mon cycle A avec uniquement mon groupe de ressources et clique sur **Prépare**.

Pour continuer, je clique sur **Prépare**.

A ce moment-là et après un court traitement de la part d’Azure, je constate que le statut de mon groupe de ressources a changé :

*Le statut est passé de **Prépare** à **Initialisation de la migration**.*

Cycle A – Initialisation de la migration

Je continue donc le processus de migration du groupe de ressources en le sélectionnant à nouveau et en cliquant sur Initier la migration :

*L’erreur sur la machine est toujours présente mais cela ne gêne pas en soi.*

*Peu de choix sont possibles sur les écrans de confirmation 🙂*.

Une fois l’initialisation lancée, je peux déjà constater la création d’un nouveau groupe de ressources sur ma région de destination :

*La présence d’un second groupe de ressources est aussi constatée sur la région de destination.*

*Le statut est passé d’**Initialisation de la migration** à **Confirmation de la migration**.*

Cycle A – Confirmation de la migration

Cette dernière étape est nécessaire pour valider la migration des ressources sélectionnées. Je reste donc sur mon groupe de ressources et la déclenche dans la foulée :

Azure Resource Mover créé dans cette étape de nouvelles ressources. On retrouve dans le groupe de ressources de destination le disque qui sera utilisé pour la nouvelle machine virtuelle :

*Le disque de la machine virtuelle est lui aussi créé dans le futur groupe de ressources.*

De plus, d’autres ressources sont créées dans le second groupe vu précédemment. Ce groupe de ressources va donc servir à la transition des données de la machine virtuelle :

*Est présent dans ce groupe un coffre et un compte de stockage pour le cache de transition.*

*Le groupe de ressources a encore changé de statut. L’erreur sur la machine virtuelle a disparu.*

Je vais pouvoir attaquer le cycle B avec les autres ressources à migrer. J’effectuerai la suppression de toutes les ressources sur la région initiale une fois que la migration sera entièrement terminée.

Cycle B – Préparation à la migration

Comme pour le premier cycle, nous répétons les mêmes étapes avec les autres ressources Azure que nous souhaitons migrer.

*Vous ne pouvez pas vous tromper dans les étapes à suivre.*

*L’étape de préparation prendra plus de temps que lors du cycle A.*

Cycle B – Initialisation de la migration

En seconde étape, je continue le processus de migration en sélectionnant les ressources et en cliquant sur Initier la migration :

Une fois cette étape terminée, un tour dans le nouveau groupe de ressources montre que les autres ressources sont venues se rajouter au disque. A noter que la copie d’écran ci-dessous nous montre maintenant deux disques dont un appelé réplica :

*La présence de 2 disques nous rappelle le fonctionnement d’Azure Site Recovery dans le cadre d’un DR.*

Cycle B – Confirmation de la migration

Nous lançons donc la dernière étape encore une fois pour valider la migration des ressources sélectionnées :

Un rapide contrôle dans la liste des machines virtuelles nous montre que la VM de la première région a bien été éteinte, tandis que celle dans la seconde région est maintenant allumée :

Point important : L’adresse IP publique de la seconde machine virtuelle dans la seconde région ne sera jamais identique à la première. Les adresses IP publiques ne se transfèrent pas entre régions. Il s’agit ici d’une nouvelle adresse IP publique.

*Un second contrôle sur la machine virtuelle de la seconde région indique bien la zone 3, comme paramétré dans Azure Resource Mover.*

Etape V : Suppression des ressources

La dernière étape de ce processus de migration comprend la suppression des anciennes ressources encore présentes dans la première région. Elle peut être faite via Azure Ressource Mover ou directement via le groupe de ressource en lui-même :

A ce point, toutes les ressources présentes ici se retrouve dans le même status final.

Le message d’erreur vous indique que le groupe de ressources initial ne peut être supprimé via Azure Ressources Mover :

*Vous pouvez malgré tout continuer cette étape de suppression avec les autres ressources.*

Les ressources sélectionnées précédemment ont donc terminé le processus d’Azure Resource Mover :

*Il ne reste plus qu’à s’occuper du groupe de ressources.*

Une suppression manuelle reste donc à faire dans la première région Azure :

*Le groupe de ressources non supprimé contient encore la dépendance de la machine virtuelle pris en compte par Azure Resource Mover.*

Une seconde suppression est également à faire pour entièrement terminer le processus. il s’agit ici du projet créé par Azure Resource Mover, mais aussi du compte de stockage et du coffre créé pour assurer la copie des données du disque de la machine virtuelle entre les deux régions.

A noter que la suppression de l’ensemble ne peut se faire qu’après le retrait des verrous posés sur les ressources :

Conclusion

Au final, Azure Resource Mover est un très bon outil de migration entre différentes régions Azure. Gardez encore en tête que certaines limitations subsistent et que les migrations très complexes à étapes sensibles seront peut-être gérées en dehors de cet outil.

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Resource Mover ????