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 :

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

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.
Le lecteur C est bien la cible, donc le numéro de partition est bien le 2.

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 🙂

Mettre en place un Disaster Recovery sur Suisse Ouest

Carte représentant les régions Microsoft Azure à travers le monde
(Crédits : Microsoft)

Un des plus grands atouts de Microsoft Azure est bien le nombre de régions disponibles à travers le monde. A l’heure j’écris ce billet, nous pouvons déjà compter sur plus de 65 régions disponibles. Par région, j’entends que chacune d’entre elle dispose d’un ou plusieurs centres de données, appelés également zone de disponibilité.

Quoi de neuf en 2021 ?

L’année 2021 va continuer sur cette forte progression puisqu’il a été annoncé lors de l’Ignite 2021, que chaque région Azure aura droit à des zones de disponibilités en son sein. Aucun calendrier précis n’a été communiqué pour l’heure.

En revanche, chaque région Azure disponible se retrouve liée à une région paire au sein de la même zone géographique. Ces deux régions sont donc spécéfiquement reliées pour obtenir une faible latence mais aussi des services supplémentaires, comme de la continuité d’activité en cas de grand sinistre.

Les régions paires ne sont jamais mises à jour en même temps. La région paire va servir de stockage de secours pour les ressources configurées en GRS (Geo-redundant storage)

Pour tout comprendre sur les principes de régions et de disponibilités, je ne peux que vous conseiller l’excellente vidéo de Travis Roberts :

Et la Suisse dans tout ça ?

Microsoft Azure est implanté sur le territoire Suisse depuis 2019. Cela rend possible la mise en place d’un nouveau tenant 365 dans le pays helvétique, mais aussi le placement de ressources Azure. Il s’agit ici d’une évolution importante pour les entreprises et les organisations ayant des besoins en matière de résidence, de sécurité et de conformité des données.

Azure est présent sur Suisse dans deux régions distinctes: la Suisse occidentale située à Genève et la Suisse du Nord située à Zurich.

Deux régions Azure sont donc disponibles sur Suisse, mais cela ne veut pas dire que les deux sont accessibles pour tous. En effet, la région Suisse Nord reste à ce jour la région principale pour cette zone géographique. Il est malgré tout possible de faire une demande auprès de Microsoft pour installer des environnements de production sur Suisse Ouest, mais cette demande devra être motivée par son caractère stratégique et/ou critique.

Et si l’on souhaite mettre un disaster recovery sur la région paire ?

Pour rappel, un disaster recovery est une solution de réplication vers un lieu géographique éloigné pour assurer une continuité de service. L’intérêt de ce type de service est de limiter certains coûts liés à l’infrastructure secondaire. En effet, Azure propose un service appelé Azure Site Recovery, qui va se charger de répliquer les données en continu. Les ressources ne sont créées qu’en cas de failover (bascule). On ne paye donc que pour le stockage répliqué sur la seconde région. Ce schéma ci-dessous montre bien l’effort d’architecture pour assurer une continuité pour les 3 couches de service en cas de grand sinistre :

Azure Site Recovery | Microsoft Azure
Exemple de réplication d’architecture entre deux régions Azure. Traffic manager sera en mesure de détecter tout seul que la première région ne répond plus aux requêtes et pourra donc rediriger tous les flux vers la seconde région.

Pour installer notre Azure Site Recovery en Suisse Ouest, nous aurons donc besoin au préalable de faire une demande auprès des services de Support Microsoft. Un processus de demande d’accès aux régions Azure est disponible ici. A noter qu’en cas d’achat des ressources Azure par un Cloud Service Provider (CSP), cette demande devra être faite directement auprès de leurs services afin d’être correctement traitée. Une fois la demande validée par Microsoft, vous pourrez donc avoir “Suisse Ouest” dans la liste des régions disponible lors de la création de votre Azure Site Recovery.

Microsoft Azure Regions in Switzerland now available - Thomas Maurer

Vous voilà prêt à mettre tout ça en place !

Quelques conseils :

  • La création du groupe de ressource devra aussi faire sur la région paire (Suisse Ouest). Vous pourrez rencontrer un blocage lors de la configuration de la réplication avec Azure Site Recovery si ce dernier se trouve également dans un groupe de ressource créé sur Suisse Nord. Après réflexion, cela semble logique car le sinistre risquerait d’empêcher d’accéder à votre ressource, située dans une autre région non impactée, mais dont son groupe de ressource l’est potentiellement.
  • Comme toujours, avant toute mise en place de ressource Azure, vérifier la disponibilité de tous les services nécessaires dans ladite région, afin de vous retrouver bloqué en milieu de déploiement.