Il y a quelques jours, Microsoft vient d’annoncer une nouvelle fonctionnalité de migration très intéressante pour les machines virtuelles déjà en place : la possibilité de déplacer une machine virtuelle, actuellement non zonée, vers une zone précise de la région Azure.
Pourquoi faire ? Pour accroitre la résilience de l’infrastructure 🙏
Annoncé le 12 décembre dernier sur blog Azure, cette fonctionnalité dédié aux machines virtuelles vient compléter la récente annonce datée d’octobre sur l’Expansion zonale des Azure VMSS.
Voici d’ailleurs un schéma montrant l’intégration de 3 zones au sein d’une seule région Azure :
Microsoft a déjà mis à disposition la documentation sur ce nouveau type de migration :
En revanche, la possibilité d’utiliser ce type de migration dépendra de votre scénario actuel :
| Scénario | Assistance technique | Détails |
|---|---|---|
| Machine virtuelle à instance unique | Prise en charge | Le déplacement régional vers zonal de machines virtuelles à instance unique est pris en charge. |
| Machines virtuelles au sein d’un groupe à haute disponibilité | Non pris en charge | |
| Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration uniforme | Non pris en charge | |
| Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexible | Non pris en charge | |
| Régions prises en charge | Prise en charge | Seules les régions prises en charge par la zone de disponibilité sont prises en charge. En savoir plus sur les détails de la région. |
| Machines virtuelles déjà situées dans une zone de disponibilité | Non pris en charge | Le déplacement interzone n’est pas pris en charge. Seules les machines virtuelles qui se trouvent dans la même région peuvent être déplacées vers une autre zone de disponibilité. |
| Extensions de machine virtuelle | Non pris en charge | Le déplacement de machine virtuelle est pris en charge, mais les extensions ne sont pas copiées sur une machine virtuelle zonale cible. |
| Machines virtuelles avec lancement fiable | Prise en charge | Réactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement. |
| Machines virtuelles confidentielles | Prise en charge | Réactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement. |
| Machines virtuelles de 2e génération (démarrage UEFI) | Prise en charge | |
| Machines virtuelles dans des groupes de placement de proximité | Prise en charge | Le groupe de placement de proximité source (PPG) n’est pas conservé dans la configuration zonale. |
| VM spot (machines virtuelles de basse priorité) | Prise en charge | |
| Machines virtuelles avec hôtes dédiés | Prise en charge | L’hôte dédié de machine virtuelle source ne sera pas conservé. |
| Machines virtuelles avec mise en cache de l’hôte activée | Prise en charge | |
| Machines virtuelles créées à partir d’images de la Place de marché | Prise en charge | |
| Machines virtuelles créées à partir d’images personnalisées | Prise en charge | |
| Machine virtuelle avec licence HUB (Hybrid Use Benefit) | Prise en charge | |
| Stratégies RBAC de machine virtuelle | Non pris en charge | Le déplacement de machine virtuelle est pris en charge, mais les RBAC ne sont pas copiés sur une machine virtuelle zonale cible. |
| Machines virtuelles utilisant l’accélération réseau | Prise en charge |
Pourquoi migrer dans une Zone de disponibilité Azure ?
Les avantages à utiliser les zones de disponibilité Azure sont les suivants:
- Pour des raisons de besoins de fiabilité et de performance.
- Pour une reprise après sinistre sans compromettre la résidence des données.
Pour rappel, la SLA sera différente si la VM est toute seule, ou si elle est accouplée à une autre VM dans une Availability Set ou Availability Zone :
Afin de se faire une meilleure idée sur cette migration, je vous propose de réaliser un petit exercice, dont les tâches seront les suivantes :
- Etape 0 – Rappel des prérequis
- Etape I – Préparation de la VM Régionale
- Etape II – Déplacement de la VM Régionale dans une Zone
- Etape III – Contrôle de la VM zonée
- Etape IV – Nettoyage des ressources non zonées
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice sur la bascule d’une VM dans une zone d’Azure, il vous faudra disposer des éléments suivants :
- Un tenant Microsoft
- Une souscription Azure valide
Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle non Zonée (ou Régionale).
Etape I – Préparation de la VM Régionale :
Pour cela, rechercher le service Machines virtuelles sur le portail Azure :
Cliquez-ici pour commencer la création de la première machine virtuelle :
Renseignez les informations de base relatives à votre VM en choisissant aucune redondance :
Choisissez la taille de votre VM, définissez un compte administrateur local, bloquer les ports entrants, puis cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, 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 de la première VM, puis attendez environ 2 minutes :
Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :
Cliquez-ici pour déclencher le déploiement du service Azure Bastion :
Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :
Ouvrez une ou plusieurs applications en enregistrant le travail effectué :
Notre première machine virtuelle non-zonée ou régionale est maintenant opérationnelle. Nous pouvons dès à présent lancer le processus de migration vers la zone souhaitée.
Etape II – Déplacement de la VM Régionale dans une Zone :
Pour commencer ce processus, rendez-vous dans l’un des 2 menus suivants :
- Cliquez sur le menu à gauche appelé Disponibilité + dimensionnement.
- Cliquez sur le bouton d’édition à droite pour modifier la Zone de disponibilité.
Cliquez-ici pour démarrer le processus de migration :
Choisissez la zone cible pour la migration :
Attendez environ 2-3 minutes afin qu’Azure mette en place les droits RBAC nécessaires pour procéder à la migration :
Une notification Azure apparaît également :
Un nouveau groupe de ressources est créé par cette même occasion :
Des droits RBAC sont également générés au niveau de la souscription Azure concernée :
Une fois le traitement terminé, l’écran suivant apparait, modifiez les champs au besoin :
Dans mon cas, j’ai modifié les valeurs suivantes, puis j’ai cliqué sur Valider :
- Création d’un nouveau groupe de ressources
- Création de nouvelles ressources pour tous les objets existants
- Modification des noms des ressources
La validation entraine une seconde vérification des paramètres modifiés :
Une nouvelle notification Azure apparait indiquant que le traitement est en cours :
Environ 30 secondes plus tard, le traitement de validation se termine :
Lancez le déplacement des ressources en cochant la case ci-dessous, puis en cliquant sur Déplacer :
Le traitement démarre et vous informe que celui-ci durera plusieurs minutes :
Le nouveau groupe de ressources Azure se créé avec les ressources commencent également à y apparaître :
La session de bureau à distance ouverte via Azure Bastion sur la première machine virtuelle se ferme, comme attendu :
Un rapide contrôle du statut de la première machine virtuelle nous montre que cette dernière s’est bien arrêtée :
Le groupe de ressource créé par le service de déplacement nous montre la présence d’une collection de points de restauration :
Celle-ci contient bien un point de restauration lié au traitement de migration de la VM :
Environ 5 minutes plus tard, l’écran nous indique que le traitement est terminé. On y apprend également plusieurs choses :
- La première machine virtuelle a bien été arrêtée, mais n’a pas été supprimée
- La seconde machine virtuelle est bien démarrée et est localisée dans la zone 3
Des consignes post-déploiement sont même affichées afin de vous guider sur la suite :
Le nouveau groupe de ressources créé par la migration montre bien toutes les ressources configurées selon les options renseignées :
De retour dans le groupe de ressources précédent, la collection des points de restauration a disparu après la migration :
Etape III – Contrôle de la VM zonée :
Les deux machines virtuelles sont bien présentes et visibles, cliquez sur la nouvelle VM :
Vérifiez la présence de la zone 3, puis cliquez sur le Editer :
Microsoft vous indique qu’il n’est pas encore possible de déplacer des ressources entre les zones dans une région Azure :
Cette information de zone de notre machine virtuelle est aussi disponible ici :
Comme un nouveau réseau virtuel a été recréé dans mon exemple, pour me connecter en RDP, je dois effectuer une des actions suivantes :
- Redéployer un service Azure Bastion
- Utiliser l’adresse IP publique
- Appairer les 2 réseaux virtuels entre eux
Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la première VM :
Vérifiez la présence du travail effectué précédemment :
Etape IV – Nettoyage des ressources non zonées :
Important : l’infrastructure existante telle que les VNET, les sous-réseaux, les NSG, les LB, … tirent déjà parti d’une configuration zonale, nous aurions pu les garder au lieu d’en recréer.
Si tout est OK pour vous, il ne vous restera qu’à supprimer les deux groupes de ressources suivants :
- Groupe de ressources contenant l’ancienne machine virtuelle
- Groupe de ressource contenant les composants liés à la migration
La suppression d’un groupe de ressources Azure s’effectue très simplement :
Confirmez l’ordre de suppression :
Conclusion
Microsoft automatise tous les jours un peu plus certaines tâches manuelle au fil des améliorations faites à Azure. Tous les gains d’efficacité doivent également profiter aux ressources déjà déployées.
On pourra peut-être bientôt voir le même type de processus automatisé intégrer des machines virtuelles existantes dans des Availability Sets ou des Proximity placement groups 😎
