WordPress sur Azure

Une fois n’est pas coutume, je vais vous parler d’Azure 🚑😉

J’ai commencé ce blog il y a maintenant plusieurs mois, et je prends toujours du plaisir à écrire des articles sur Azure. Depuis quelques semaines, je rencontre des problèmes de performances rendant l’accès au site très variable, surtout en matinée. OVH n’a pu résoudre mon souci malgré mon changement de formule. 😪

J’ai donc décidé de franchir le pas en rapatriant mon blog sur Azure. Si vous souhaitez aussi créer des ressources Azure sans forcément dépenser un centime, sachez que plusieurs méthodes sont possibles.

Dans mon cas, le statut MCT m’apporte un grand nombre d’avantages de la part de Microsoft, dont justement des crédits Azure, directement disponibles sur la page Visual Studio :

Etape I : Création des ressources Azure

Une fois l’activation des crédits Azure sur un tenant nouveau ou existant, commencez la création de votre site WordPress directement depuis le portail Azure :

Une recherche de WordPress vous affiche un grand nombre de résultats. Il est en effet possible de mettre en place un site web via différents types de service Azure (IaaS, PaaS, …) :

Dans cet article, nous allons nous intéresser au service Azure App Service. Celui-ci crée, déploie et met à l’échelle rapidement des applications Web, mobiles et API de niveau entreprise s’exécutant sur n’importe quelle plate-forme.

Voici une démo assez complète du service :

Merci Adam 😋.

Choisissez donc l’article édité par WordPress :

La création des ressources Azure via ce template WordPress est assez simple et rapide et peu de champs sont à remplir :

  • Souscription Azure : “ligne de crédit” utilisée pour positionner la ressource
  • Groupe de ressources : conteneur logique pour l’organiser les ressources
  • Région : Localisation physique de vos données
  • Nom de l’instance : nom de l’application web, mais aussi URL de base du site créé WordPress créé par Azure

Une fois les champs validés, la synthèse avant création est affichée sur le dernier onglet :

Lancez la création des ressources Azure en cliquant sur Créer.

Moins de 10 minutes plus tard, Azure a fini. Cliquez ici pour afficher votre application web :

Vous retrouvez à droite l’URL de votre site web. Cliquez dessus pour ouvrir un nouvel onglet :

Les habitués reconnaitront tout de suite la page d’installation de WordPress. Finalement, quelques clics seulement suffisent pour installer WordPress sur Azure :

On a déjà terminé la lecture de cet article ? Pas encore 😋

En faisant un tour sur le groupe de ressources, voici ce que le template a créé pour vous :

Les deux premiers sont des éléments de base pour faire fonctionner une application web sur Azure. Le template WordPress a donc aussi créé une base MySQL Database, pour y stocker le contenu de votre site.

C’est assez logique, MySQL est un des choix possibles pour faire fonctionner WordPress. Voici d’ailleurs un exemple des tables contenues dans WordPress :

En ouvrant la ressource MySQL Database, on peut y voir que la configuration attribuée par défaut via ce template n’est pas des moins chères !

Un tour dans les modèles de prix nous permet d’avoir une meilleure idée de son coût mensuel :

Evidemment, la baisse du nombre de cœurs pour MySQL n’ira pas en dessous de 2. De plus il est impossible de repasser sur une édition Basique 😥:

Un petite tour nous permet alors de nous faire une idée du coût de l’ensemble :

  • App Service Plan : P1V2 (Windows) : 35.09 € / mois
  • MySQL : 4 vCore / 100GB (General Purpose) : 263.63 € / mois

Dans mon cas, le besoin n’est pas encore présent pour justifier une telle architecture. Mais comment faire pour partir sur des SKUs MySQL plus petits ?

Pour cela, nans allons réutiliser le template déployé juste avant, le modifier et le relancer pour un nouveau déploiement Azure.

Etape II : Suppression des ressources Azure

Retournez sur le groupe de ressources et cliquez ici :

Cet écran vous affiche l’historique des précédents déploiements passés, réussis ou échoués :

Avant d’en relancer un nouveau, supprimez les ressources existantes créées par ce template WordPress. Validez la suppression des ressources Azure comme ceci :

Note : relancer un template sur des ressources existantes ne posent pas de souci en soi. Les ressources existantes sont alors “modifiées” selon le nouveau template.

Etape III : Relancez le déploiement du template

Une fois les ressources Azure supprimées, retournez sur l’écran précédent et cliquez sur le déploiement :

Cliquez sur Redéployer :

Vous retrouvez alors ici toutes les informations SKUs des ressources créées :

Dans mon cas, je n’ai modifié que les informations de la base de données MySQL. Pour cela, j’ai donc rectifié les valeurs suivantes :

  • vmName : B_Gen5_1
  • serverEdition : Basic
  • vCores : 1

Voici donc le bas de page de ma configuration :

Cliquez pour valider le template et lancer le déploiement :

Quelques minutes plus tard, vous retrouvez toutes les ressources Azure dont toujours une base de données MySQL, mais avec un SKU bien moins cher 😋 :

Etape IV : Configuration WordPress

Retournez alors sur votre application web afin de terminer l’installation de WordPress. Choisissez la langue qui vous convient puis cliquez sur Continuer :

Terminez en renseignant les derniers champs pour finaliser l’installation :

Une fois authentifié avec votre nouveau compte administrateur, vous voici sur votre console d’administration WordPress :

Etape V : Ajout d’un nom de domaine personnalisé

Toujours en rapport avec Azure, il me parait important d’ajouter un nom de domaine personnalisé et de sécuriser les connexions. Pour cela, retournez sur votre application web Azure, puis cliquez ici :

Vous ne pouvez acheter des domaines directement depuis Azure. Des sites comme GoDaddy ou encore Domain.com proposent ce type de service. Pour ma part, j’utilise régulièrement le site Freenom pour acheter des domaines gratuits dans le but de tests.

Une fois le domaine acheté, pensez à ajouter le domaine sur votre application web Azure pour ensuite ajoutez les enregistrements DNS nécessaires :

Les informations ci-dessus sont nécessaires pour configurer les enregistrements DNS sur mon nouveau domaine. Quelques minutes d’attente et une validation plus tard, le nouveau domaine passe au vert. Finalisez l’ajout de ce dernier :

Etape VI : Ajout d’un certificat TLS

Ce nouveau domaine ne dispose pas encore de certificat TLS comme l’indique la copie d’écran ci-dessous. Cliquez sur les paramétrages TLS/SSL pour corriger cela :

Cliquez alors sur la seconde section, puis sur Créer un certificat managé et choisissez le domaine ajouté puis cliquez sur Créer :

Ce processus prend plusieurs minutes. Une fois terminé, retournez dans vos Domaines personnalisés, puis cliquez ici :

Sélectionnez les éléments dans la liste pour les associer entre eux. Le choix du type pourra se faire selon cet article Microsoft. Cliquez ici pour valider le lien :

Votre nouveau domaine gère bien maintenant la sécurité TLS. Profitez-en alors pour activer cette option :

Autant rester sur le sujet TLS/SSL en activant aussi cette exigence sur votre base de données MySQL :

En retournant sur l’application web, on remarque que l’URL présente sur la page principale reprend maintenant le domaine personnalisé avec le protocole HTTPS. Une fois sur votre site, consultez les détails du certificat généré par GeoTrust :

Etape VI : Activation d’Azure Backup

Toujours dans la configuration, profitez-en pour activer la sauvegarde via Azure Backup :

La sauvegarde de vos données va alors se faire sur une compte de stockage Blob :

Vous pouvez le créer directement ici si nécessaire en cliquant ici. Le nom de celui-ci doit être unique sur Azure :

Sélectionnez ce nouveau compte de stockage pour créer après coup un nouveau conteneur, puis validez :

Définissez votre police de sauvegarde, puis validez là :

Vous pouvez cliquer dès à présent ici pour effectuer votre première sauvegarde manuelle. Les autres suivront automatiquement, en fonction de votre police de sauvegarde :

Allez dans le compte de stockage pour constater l’apparition des fichiers de sauvegarde :

L’architecture est maintenant en place, il ne vous reste plus qu’à utiliser votre console WordPress 😎

Conclusion

Cette mise en œuvre d’un site WordPress sur Azure n’est pas des plus compliquée. Microsoft vous simplifie grandement le travail. D’autres articles vont suivre sur le sujet car je souhaite aussi aborder la migration des données ou encore l’optimisation de l’architecture et la mise en place d’autres métriques.

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éographiePaire régionale APaire régionale B
Asie-PacifiqueAsie Est (Hong Kong, R.A.S.)Asie Sud-Est (Singapour)
AustralieAustralie EstSud-Australie Est
AustralieCentre de l’AustralieAustralie Centre 2*
BrésilBrésil SudÉtats-Unis – partie centrale méridionale
BrésilBrésil Sud-Est*Brésil Sud
CanadaCentre du CanadaEst du Canada
ChineChine du NordChine orientale
ChineChine Nord 2Chine orientale 2
EuropeEurope Nord (Irlande)Europe Ouest (Pays-Bas)
FranceFrance CentreFrance Sud*
AllemagneAllemagne Centre-OuestAllemagne Nord*
IndeInde centraleInde Sud
IndeInde OuestInde Sud
JaponJapon EstJapon Ouest
Corée du SudCentre de la CoréeCorée du Sud
Amérique du NordUSA EstUSA Ouest
Amérique du NordUSA Est 2USA Centre
Amérique du NordCentre-Nord des États-UnisÉtats-Unis – partie centrale méridionale
Amérique du NordUSA Ouest 2Centre-USA Ouest
NorvègeNorvège EstNorvège Ouest*
Afrique du SudAfrique du Sud NordAfrique du Sud-Ouest*
SuisseSuisse NordSuisse Ouest*
Royaume-UniOuest du Royaume-UniSud du Royaume-Uni
Émirats Arabes UnisÉmirats arabes unis NordÉmirats arabes unis Centre*
Ministère de la défense des États-UnisUS DoD Est*US DoD Centre*
Gouvernement américainUS Gov Arizona*US Gov Texas*
Gouvernement américainUS Gov Iowa*US Gov Virginie*
Gouvernement américainUS 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 instanceTarif Sauvegarde Azure par mois
Instance inférieure ou égale à 50 GoCHF 7,3808 + stockage utilisé
Instance supérieure à 50 Go mais inférieure ou égale à 500 GoCHF 14,7615 + stockage utilisé
Instance supérieure à > 500 GoCHF 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 StandardNiveau Archive
LRSCHF 0,0331 par GoCHF 0,0043 par Go
ZRSPréversionCHF 0,0414 par GoS.O.
GRSCHF 0,0662 par GoCHF 0,0085 par Go
RA-GRSCHF 0,0840 par GoCHF 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 :

Ce processus est rapide 🙂

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 manuellement, 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 applicationsLes 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 fichiersLes 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’incidentDes 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 :

  1. Création du projet de migration
  2. Configuration des ressources de destination
  3. Validation des dépendances
  4. Migration (Préparation / Initiation / Confirmation)
  5. 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 😋

Changer la taille du disque OS sur une machine virtuelle via [smalldisk] / Resize

Azure VM | Microsoft Power Automate

Des machines virtuelles sont créées en permanence sur Azure, et très régulièrement sur Windows Serveur. Sans se poser de question, le choix de l’image présélectionne sans votre avis la taille du disque OS, sans aucun pouvoir de modification.

Mais comment faire si l’on souhaite autre chose que la taille par défaut de 128GB pour notre lecteur C ?

Nous allons voir ensemble dans cet article les différentes possibilités, avant et après la création d’une machine virtuelle, pour changer très facilement la taille du disque OS.

Cas classique : Image Windows Server

Commençons par le cas standard, la création d’une machine virtuelle avec Windows Serveur entraîne la création d’un disque OS.

Sélectionnons ici par exemple une image source Windows Server 2019.

Dans le second onglet de création de la machine virtuelle, je n’ai pas de choix concernant la taille de mon disque OS :

Cet onglet me propose de choisir les performances du disque OS, mais pas sa taille. La taille est par contre bien un choix disponible sur les disques de données ajoutés.

Rappel : les performances du disque vont influer sur la SLA de la machine virtuelle, que vous pouvez retrouver en pourcentages ici.

Une fois la machine virtuelle créée, je ne peux que constater la taille de mon disque OS, assez facilement depuis la section des disques :

Un clique sur le disque OS vous amène sur sa page dédiée.

Redimensionnement du disque OS sur une machine virtuelle existante

Une alerte est mentionnée en haut de page : la taille d’un disque ne peut se faire que si ce dernier est détaché de la machine virtuelle ou que si cette dernière est éteinte :

Cas A : Redimensionnement à la baisse

Une fois la machine virtuelle arrêtée, un redimensionnement à la baisse va obligatoirement échouer, dans le but de prévenir la perte de données :

Erreur remontée par Azure au moment du redimensionnement à la baisse.

Cas B : Redimensionnement à la hausse

Cela ne sera pas le cas dans le cas d’un redimensionnement à la hausse, comme vous pouvez le voir en dessous :

La taille du disque OS a bien été augmentée. Notez que le nombre max d’IOPS a aussi fait un bon.

Dernière chose à faire, agrandir la partition du lecteur C directement depuis la machine virtuelle :

Comment faire donc pour effectuer pour disposer d’un lecteur C plus petite taille ? Sachant que l’OS est loin de remplir le lecteur C, plusieurs options s’offrent à nous :

  • Création d’une machine virtuelle avec une image portant la mention [smalldisk]
  • Redimensionnement du disque OS, après déploiement de la machine virtuelle

Remarque importante : Prenez garde avec la taille des disques, un disque trop réduit vous apportera peu d’IOPS et donc des performances disques insuffisantes :

Néanmoins, cette démarche peut être utile dans certains cas et donc générer une économie de coûts.

1er cas : Image Windows Server 2019 [smalldisk]

Si, avant la création de la machine virtuelle, vous savez déjà que votre disque C peut être plus réduit, vous pouvez alors partir sur des images spécifiques. Voici par exemple la liste des [smalldisk] disponibles pour Windows Serveur :

Si vous avez des difficultés de visualisation du nom complet des images, un passage du curseur sur un choix vous donnera son nom complet.

Une fois la machine provisionnée sur votre souscription Azure, vous constaterez que la taille du disque OS est de 30GB. Cette taille est donc plus réduite que la précédente. Vous pourrez toujours changer celle-ci à la hausse simplement en éteignant votre machine virtuelle.

Notez qu’une taille custom du disque entraine toujours une facturation égale à la taille supérieure : ici 32GB.

2ème cas : Redimensionnement du lecteur C puis du disque OS

Il arrive dans certains cas que la machine virtuelle existe déjà. Il va donc falloir commencer le processus par redimensionner le lecteur C. Je suis donc tombé sur cet excellent article (en anglais) et écrit par Jack Rudlin. Les étapes nécessaires pour y parvenir sont :

  • Réduction de la partition de l’OS dans Windows
  • Redimensionnement du disque OS dans Azure
  • Lancement du script sous PowerShell
  • Extension de la partition du système d’exploitation

Je recréé donc une nouvelle machine virtuelle, afin de faire avec vous cette opération de réduction “à chaud” :

Comme indiqué ici, la taille custom de mon disque OS est de 127GB.

Important : comme indiqué dans l’article de Jack et dans la source Microsoft, il est fortement recommandé de faire un snapshot du disque avant toute opération pour sauvegarder les données.

Dans un premier temps, nous nous connectons en RDP sur la machine virtuelle. Cet accès nous permet de changer la taille du lecteur C via un une première requête PowerShell, disposants des droits d’administration :

Get-Partition -DiskNumber 0

Cette requête nous donne le numéro de partition, utilisé après pour le redimensionnement.
La requête ci-dessus prend en compte le numéro du disque pour nous présenter les partitions associées.

Get-Partition -DiskNumber 0 -PartitionNumber 2 | Resize-Partition -Size 31GB

Cette simple commande redimensionne la partition du lecteur C.
L’effet de la requête est immédiatement visible 🙂
Existing Volumes
Comme indiqué sur le blog de Jack, vous pouvez rencontrer une erreur si la taille visée est trop petite.

La suite va se faire en dehors de la machine virtuelle. Il faut commencer par éteindre la machine virtuelle pour effectuer la copie des données :

Machine virtuelle arrêtée et dont les ressources ne sont plus allouées. Rappel : une désallocation des ressources entraînent un forte disque de perte des données disque D : temporaire.

Il donc falloir ici utiliser le module AZ sur votre poste via PowerShell pour continuer la suite des opérations. Voici une vidéo qui explique bien comment y arriver facilement :

Merci à David Lamb 🙂

La suite se fait avec le lancement du script donné par Jack, disponible depuis son GitHub via ce lien.

Aussi je vous conseille de passer par PowerShell ISE pour modifier facilement le script, car plusieurs variables vont devoir être modifiées :

  • Ressource ID du disque OS à modifier, que vous pouvez retrouver dans les propriétés du disque OS
  • Nom de la VM, que vous pouvez retrouver sur la page de la machine virtuelle
  • Nom de la souscription Azure, que vous pouvez retrouver sur la page de la machine virtuelle
Ressource ID du disque OS que vous pouvez retrouver dans les propriétés du disque OS.
Nom de la VM que vous pouvez retrouver sur la page de la machine virtuelle.
Nom de la souscription Azure que vous pouvez retrouver sur la page de la machine virtuelle.

Avant de lancer le script :

  • Celui-ci demande de posséder un certains nombres de droits pour effectuer toutes les tâches
  • Dans mon exemple (généralement non recommandé), j’ai utilisé un utilisateur avec le profil d’administrateur global du tenant Azure
  • A minima, vous devez disposer au moins des rôles de contributeur VM et de contributeur de compte de stockage dans Azure

Dans le détail, le script de Jack effectue les actions suivantes :

  • Création d’un compte de stockage temporaire
  • Création d’un container temporaire dans le nouveau compte de stockage
  • Copie du disque OS dans le compte de stockage temporaire sous forme de page blob
  • Modification la taille du page blob pour que le disque d’OS soit réduit
  • Reconversion du disque non managé en disque managé
  • Remplacement du disque OS actuel de la VM par le nouveau disque OS plus petit
  • Redémarrage de la machine virtuelle
  • Nettoyage du compte de stockage temporaire et de l’ancien disque managé

Le processus peut également être suivi depuis le portail Azure en constatant l’évolution du compte de stockage créé par le script de Jack :

Compte de stockage temporaire créé par le script.
Copie du disque OS en disque non managé (page blob).
Copie du disque non managé sur un second avec une taille réduite.
Suppression du page blob ayant la taille originale.
Un nouveau disque managé est créé à partir du dernier page blob et porte la mention “-new”.
Suppression du dernier page blob une fois la transformation faite en disque managé.
Comme on le constate sur la machine virtuelle utilisée dans mon exemple, le script détache l’ancien disque OS et rattache aussi le disque OS à taille réduite.
La machine virtuelle est redémarrée automatiquement par le script.
Suppression du compte de stockage temporaire en fin de script.

Il faut compter une bonne quinzaine de minutes pour que le script arrive à sa fin. Une connexion en RDP à cette dernière permet de réaliser la dernière étape du processus.

Compte tenu des volumes renseignés dans notre exemple, un reliquat d’espace est disponible sur le disque OS (522MB) :

Ce surplus peut être réintégré sur le lecteur C, comme indiqué sur cette image.
Fin de l’opération 🙂

Il faut donc compter au total une bonne vingtaine de minutes pour effectuer ce processus.

Conclusion

Il est donc bien possible de redimensionner un disque OS à plusieurs moments. Pensez toujours à faire des sauvegardes avant ce type d’opération ! Pensez à partager dans les commentaires vos autres sources d’apprentissage 😋