Étiquette : Vm

Que valent les disques Azure ?

Microsoft vient d’annoncer il y quelques jours la disponibilité générale des disques Ultra dans plusieurs régions Azure, dont Suisse Nord. Depuis quelques mois déjà, un nouveau type de disque, appelé Premium SSD v2, a également fait son apparition sur Azure.

Au total, 5 types de disque managé sont disponibles pour les machines virtuelles Azure. SLA, IOPS, débit, taille, région ou encore sauvegarde sont quelques-uns des paramètres à prendre en compte lors de ce choix.

Dans cet article, nous allons aborder quelques points définissant les différents types de disque Azure, et nous ferons également quelques tests de performances IOPS et Débit. Durant mes tests, j’ai relevé des valeurs de latence très hautes. Je ne pense pas qu’elles représentent la réalité, et c’est pour cela qu’elles vous seront affichées mais pas commentées.

Compte-tenu de mes possibilités, à l’heure où ces lignes sont écrites, les tests ne porteront que sur les 4 types de disque suivants :

  • Premium SSD
  • Standard SSD
  • Standard HDD
  • Ultra disk

A quoi correspondent les IOPS d’un disque ?

IOPS (input/output operations per second en anglais, opérations d’entrée-sortie par seconde) est une unité de mesure commune en informatique. Elle est utilisée dans les tests de performance de supports de stockage tels les disques durs (HDD), solid-state drives (SSD) et réseaux de stockage SAN.

Wikipédia

Une courte vidéo de John vaut mieux qu’un long discours ???? :

A quoi correspond le débit d’un disque ?

Taux de transfert (ou débit) : quantité de données pouvant être lues ou écrites sur le disque par unité de temps. Il s’exprime en bits par seconde.

CommentCaMarche.net

Merci encore une fois à John pour ses vidéos :

Quelles sont les tailles disponibles pour un disque Azure ?

Azure vous propose de créer des disques très petits ou très grands. La plupart des types de disque peuvent aller jusqu’à 64 Tio :

Quels sont les coûts d’un disque Azure ?

Il existe deux principaux coûts aux disques managés d’Azure. La taille du disque et les transactions influent sur le montant mensuel :

  • Taille du disque : Un disque managé Azure est facturé toutes les heures au niveau supérieur le plus proche de sa taille. Autrement dit, un disque de 120 Go coûte autant qu’un disque de 128 Go, que la machine virtuelle soit allumée ou non.
  • Transaction : Sont appelées transaction, les lectures, les écritures, … effectuées par le disque, elles sont facturées par paquet de 10 000 transactions. Certains types de disque, comme les disques Premium ou Ultra, incluent le coût des transactions dans leur tarification les coûts sont alors plus prévisibles et mieux maîtrisés.

Voici une brève comparaison tarifaire pour un disque de 128 Go en Europe de l’Ouest, selon Azure Pricing Calculator :

  • Premium SSD : 20.13 CHF / mois
  • Premium SSD v2 : 11.49 CHF / mois
  • Standard SSD : 12.63 CHF / mois
  • Standard HDD : 6.39 CHF / mois
  • Ultra disk : 88.73 CHF / mois

Pourquoi le type de disque influe sur la SLA d’une machine virtuelle Azure ?

Azure est découpé en centaines de services. Chaque service dispose de sa propre SLA, elle-même calculée selon des paramètres précis.

Certains services proposent différents niveaux de performances et de fonctionnalités. Ces changement influent souvent sur l’architecture ou les composants physiques. Cela joue naturellement sur la SLA. Microsoft met à disposition une liste des SLA par service, régulièrement mise à jour.

Derrière chaque disque d’Azure se trouve une technologie de stockage. Microsoft se base donc sur cette SLA pour calculer la SLA de la machine virtuelle :

Quel scénario pour quel type de disque ?

Le coût du disque reste un facteur important pour une machine virtuelle. Néanmoins, Microsoft conseille un ou plusieurs types de disque, selon le rôle que celle-ci doit jouer :

Pourquoi les machines virtuelles Azure ont-elles un maximum d’IOPS ?

Quand vous sélectionnez une taille de machine virtuelle lors de sa création, une colonne concerne la performance des disques et doit attirer votre attention :

Les machines virtuelles d’Azure ont donc elles aussi un plafond IOPS :

Ce nombre maximal d’IOPS ne garantit en rien la performance de vos disques rattachés, mais agira en goulet d’étranglement si la puissance demandée par vos disques est supérieure à cette limite :

Etape 0 – Rappel des prérequis :

Peu de prérequis sont nécessaires pour réaliser les tests de performances des disques Azure :

  • Un tenant Microsoft
  • Une souscription Azure valide

Dans cet article, nous allons déployer une machine virtuelle Azure, avec différents types de disque. Cela nous permettra de comparer leurs performances.

Etape I : Enregistrement de la souscription Azure :

Tous les types de disque sont accessibles, à l’exception du nouveau type de disque Premium SSD v2. A l’heure où ces lignes sont écrites, un enrôlement de votre souscription Azure est encore nécessaire pour déployer ces derniers.

Cliquez-ici pour accéder au formulaire Microsoft :

Une fois le formulaire rempli, il ne vous restera qu’à attendre un retour de la part de Microsoft pour tester ce nouveau type de disque.

En attendant, rien ne vous empêche de continuer les étapes de cet article pour tester les autres types.

Etape II : Déploiement de la machine virtuelle Azure

Afin de tester différents types de disque, j’ai déployé une seule machine virtuelle sur Windows Server. J’ai choisi une machine virtuelle de type D8s v5 pour disposer de :

  • Une puissance de calcul CPU suffisante
  • Un nombre maximal d’IOPS élevé
  • Une limitation haute pour le nombre maximal de disques de données

Dans l’onglet des disques :

  • Pensez à cocher la case de comptabilité Ultra disque.
  • Pour les tests, tous les disques ont une taille proche pour comparer des performances de même tranche.
  • Quelques gigas seulement les séparent pour les identifier plus facilement par leur taille.
  • J’ai ajouté un second disque type Premium SSD, de plus grande capacité que les autres, pour mesurer l’impact sur les performances selon la taille.
J’ai aussi retiré le cache d’hôte pour ne pas avoir de variation de résultats.

Retirez l’adresse IP publique si vous utilisez comme moi le service Azure Bastion :

Quand la validation est réussie, lancez le déploiement de votre machine virtuelle de test :

Une fois le déploiement terminé, cliquez ici pour consulter votre machine virtuelle :

Configurez au besoin les performances de votre Ultra disk :

J’ai configuré ces valeurs pour tester les limites liées à ma machine virtuelles. Attention à la consommation Azure qui peut s’envoler très vite ???????? :

Déployez également le service Azure Bastion pour vous y connecter plus facilement :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, puis connectez-vous à votre machine virtuelle de test avec le compte d’un administrateur local :

Etape III – Configurations des disques de données :

Une fois connecté à votre session à distance, ouvrez le gestionnaire de disque Windows :

Le gestionnaire de disque Windows vous propose automatiquement de lancer l’initialisation des disques de données ajoutés, cliquez sur OK :


Ajoutez un volume simple sur chacun des disques ajoutés :

Conservez toutes les options de bases pour chaque volume créé :

Contrôlez la présence des 5 partitions dans l’explorateur de fichier, renommez-les au besoin :

Etape IV – Installation de l’outil de mesure Diskspd :

DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.

Microsoft Learn

Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.

Windows OS Hub

Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :

Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :

L’exécutable se trouve dans le sous-dossier amd64 :

Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :

  • Deux séries de tests sont conseillées pour exploiter le meilleur des deux caractéristiques :
    • IOPS
    • Débit
  • Le changement entre ces deux séries se fera au niveau de la taille des blocs.

Etape V – Tests des IOPS des disques Azure :

Commencez une première salve de tests pour déterminer les IOPS maximums sur chacun des disques.

Ouvrez le programme de ligne de commande, puis positionnez-vous dans le dossier de l’exécutable Diskspd :

Lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L E:\diskpsdtmp.dat > IOPS-PremiumSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L F:\diskpsdtmp.dat > IOPS-StandardSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L G:\diskpsdtmp.dat > IOPS-StandardHDD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L H:\diskpsdtmp.dat > IOPS-PremiumSSD1024.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L I:\diskpsdtmp.dat > IOPS-UltraDisk.txt

Les arguments utilisés pour diskspd.exe sont les suivants :

  • -c50G : taille du fichier 50 GB (il est préférable d’utiliser une taille de fichier importante pour qu’il ne parte pas dans le cache du contrôleur de stockage)
  • -d120 : durée du test en secondes
  • -r : opérations de lecture/écriture aléatoires
  • -w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
  • -F4 : nombre de threads max
  • -o128 : longueur de la file d’attente
  • -b8K : taille du bloc
  • -Sh : ne pas utiliser le cache
  • -L : mesure de la latence
  • E:\diskpsdtmp.dat : chemin du fichier généré pour le test
  • > IOPS-PremiumSSD.txt : fichier de sortie des résultats

En attendant la fin du traitement, ouvrez Resource Monitor et constatez la charge maximale du disque :

Une fois tous les tests terminés, retrouvez les fichiers des résultats dans le même dossier que l’exécutable :

Ouvrez chacun des fichiers de résultats, puis descendez au paragraphe suivant :

Pour plus de clarté, j’ai synthétisé tous mes résultats IOPS dans le tableau ci-dessous :

Etape VI – Tests débits des disques :

Continuez avec une seconde salve de tests pour mesurer les débits maximums des types de disque Azure.

Ouvrez le programme de ligne de commande si vous l’aviez fermé, puis repositionnez-vous dans le dossier de l’exécutable Diskspd :

Lancez les commandes de tests suivantes, une à une ou à la chaîne, en modifiant leurs paramètres si besoin :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L E:\diskpsdtmp.dat > Throughput-PremiumSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L F:\diskpsdtmp.dat > Throughput-StandardSSD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L G:\diskpsdtmp.dat > Throughput-StandardHDD.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L H:\diskpsdtmp.dat > Throughput-PremiumSSD1024.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L I:\diskpsdtmp.dat > Throughput-UltraDisk.txt

Les deux paramètres ayant changés rapport aux commandes de test IOPS sont :

  • -b8K : taille du bloc
  • > Throughput-PremiumSSD.txt : fichier de sortie des résultats

Une fois les tests débits terminés, retrouvez les fichiers dans le même dossier que les IOPS :

Ouvrez chacun des fichiers de résultats de débits et compilez-les dans un tableau :

Etape VII – Analyse des résultats IOPS / Débits :

Après analyse des résultats de chaque type de disque, comparez-les à la documentation Microsoft : on retrouve bien des valeurs approchantes pour les IOPS et les débits. Voici quelques explications :

Premium SSD :

  • Premium SSD P10 : 3548 IOPS – 162 Mio/sec
  • Premium SSD P30 : 5099 IOPS – 194 Mio/sec

Le nombre d’IOPS et le débit garantit augmentent par parlier, en rapport avec la taille du disque.

  • A partir de 4 Gio et jusqu’à 512 Gio, le mode Burst est disponible et s’active automatiquement selon la charge, comme le montre le test réalisé.
  • A partir de 1024 Gio, les performances de base sont bien meilleures, mais le mode Burst s’active uniquement sur demande.

Voici d’ailleurs l’excellente vidéo de John sur le fonctionnement du mode Burst dans le temps :

Durant le premier test, le disque Premium SSD d’1 Tio n’a pas utilisé le mode Burst et est resté aux alentours de 5000 IOPS et 200 Mio/sec, soit les valeurs provisionnées sur un disque P30.

L’activation du burst à la demande doit se faire sur le disque, uniquement lorsque ce dernier est détaché ou quand la machine virtuelle est désallouée, donc éteinte.

Pour effectuer un test de burst sur le disque P30, éteignez votre machine virtuelle et cochez la case suivante sur le disque, puis rallumez-là :

Voici les résultats IOPS / débits du disque Premium SSD d’un 1 Tio avec le mode burst à la demande :

  • Premium SSD P30 + Burst : 19321 IOPS – 967 Mio/sec

Le test de débit est bon, mais la valeur IOPS aurait dû se rapprocher des 30 000 IOPS. L’écart s’explique à cause de la machine d8s_v5, qui vient limiter les performances du mode burst du disque.

Cela n’empêche pas d’avoir de performances très honorables. Passons maintenant au disques Standard SSD.

Standard SSD :

Je trouve le test de débit un peu faible comparé au tableau Microsoft :

  • Standard SSD E10 : 600 IOPS – 38 Mio/sec

Standard HDD :

Pour celui-ci, les résultats des tests sont cohérents avec la documentation Microsoft :

  • Standard HDD S10 : 543 IOPS – 35 Mio/sec

Rappel important : Pour les disques de type standard HDD, chaque opération a un impact sur la facturation.

Ultra disk :

Ce type de disque apporte le plus de flexibilité car ils sont disponibles à partir de 4 Gio et jusqu’à 64 Tio. De plus, la SLA qui les couvre est très élevée : 99.99 %.

Comme le montre l’écran de paramétrage de notre test, nous pouvons jouer avec les limites débit et IOPS selon des besoins très précis, et cela sans aucun redémarrage de la machine virtuelle.

Les limites maximales des IOPS et des débits sont très hautes, comme le montre le tableau ci-dessous :

Rappel important : Pour les disques Ultra, ces options ont un lourd impact sur la facturation.

Le test d’IOPS sur le disque ultra a plafonné à 20 000 IOPS car nous avons là encore été bridé par la limite d’IOPS de la machine virtuelle d8s_v5. Le tableau ci-dessous nous affiche cette limite et le mode burst possible :

Les machines virtuelles les plus puissantes acceptent jusqu’à 80 000 IOPS, ce qui reste en dessous de la limite maximale des IOPS des plus puissants disques ultra. C’est pour cela que ces derniers peuvent être utilisés en tant que disques partagés, pour prendre en charge plusieurs machines virtuelles.

Conclusion :

Je peux déjà commencer par vous dire que j’aurais bien aimé tester un disque Premium SSD v2 ????. Cela devrait arriver sous peu, je vous ferai alors une mise à jour de cet article.

Cela dit, je pense que les performances et les usages de ces derniers sont proches des disques Ultra. A ce titre, je pense que la stratégie de Microsoft est bien de démocratiser la performance et la customisation des disques selon les besoins, avec un prix bien plus attractif ✌️????

Edit :

Seulement quelques jours après la publication de mon article, j’ai reçu un avis favorable de la part d’un Product Manager de chez Microsoft pour tester les disques Premium SSD v2, sur une souscription Azure de mon tenant, en disponibilité générale depuis octobre 2022.

Je suis parti donc sur un disque Premium SSD v2 avec les caractéristiques suivantes :

Pour rappel, voici quelques caractéristiques maximales pour un disque Premium SDD v2 :

  • Taille maximale : 65 536 Gio
  • IOPS provisionnées : 80 000 IOPS
  • Débit provisionné : 1200 Mio / Sec

Afin d’atteindre les performances maximales de mon disque, j’ai créé une machine virtuelle D32s v5, qui dispose des limites suivantes :

Grâce à Diskspd et aux commandes suivantes :

diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L E:\diskpsdtmp.dat > IOPS-PremiumSSDv2.txt
diskspd.exe –c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L E:\diskpsdtmp.dat > Throughput-PremiumSSDv2.txt

Cela m’a permis de compléter mes tableaux de performances :

Il s’agit sans aucun doute d’un type de disque flexible aux performances incroyables. Voici un rappel du prix bien moins chère qu’un Ultra disk ????

Attention aux limitations encore présentes sur le disques Premium SSD v2.

Configurer l’autorisation multi-utilisateur pour Azure Backup

J’avais déjà écrit un article sur comment sauvegarder de machine virtuelle via Runbook/Snapshot. Cette option est intéressante dans le cas où la sauvegarde native d’Azure ne supporte pas l’OS de la machine virtuelle. Microsoft continue d’apporter des mesures de sécurité sur son service sauvegarde Azure Backup.

Dans cet article, nous allons parler et tester l’autorisation multi-utilisateur (MUA), annoncée il y a seulement quelques jours en disponibilité générale. Dans quel but ? Accroître la protection des sauvegardes de vos ressources Azure.

Mais avant cela, nous allons faire un rappel de quelques mesures de protection de sauvegardes de machines virtuelles disponibles sur Azure.

Par défaut, quelles mesures de protection existent sur mes sauvegardes de VMs ?

Quand vous sauvegardez des machines virtuelles au travers de la sauvegarde native d’Azure, vous utilisez et déployez un coffre de sauvegarde. Ce dernier est directement géré par le service Azure Backup :

Ce schéma nous montre la création de snapshots et le transfert différé vers le coffre de sauvegarde.

La création de snapshots et la rétention de vos sauvegardes sont alors configurées selon une police de sauvegarde, créée dans ce coffre de sauvegarde :

Il est possible de créer plusieurs polices de sauvegardes.
Azure propose maintenant plusieurs sauvegardes par jour.

D’autre part, le nombre et la répartition des copies de vos sauvegardes vont dépendre des propriétés de ce coffre :

La création d’un Recovery Service Vault est paramétré en Geo-redondant par défaut.
Cette option reste modifiable tant qu’aucune sauvegarde n’est paramétrée.

Pour rappel, voici quelques notions de réplication à connaitre, tant elles sont très utilisées sur un grand nombre de ressources Azure :

  • Redondance locale (LRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure.
  • Redondance zonale (ZRS) : La donnée est présente en triple exemplaires, chacun réparti dans les 3 datacenters (Zones) de la même région Azure, si celle-ci le propose.
  • Géo-redondance (GRS) : La donnée est présente en triple exemplaires dans le même datacenter (Zone) de la région Azure, et 3 autres exemplaires dans la région paire Azure de la première.

Note : il existe également d’autres scénarios de réplication Azure : RA-GRS, GZRS, … ????

Enfin, la suppression d’une sauvegarde stockée dans un coffre conserve encore celle-ci pendant 14 jours. Cette fonctionnalité est activée par défaut et est appelée Soft-delete :

Pour information, la donnée maintenue dans cet état de soft-delete ne coûte rien.

Un coffre de sauvegarde contenant encore des sauvegardes en état de soft-delete ne peut être supprimé.

Envi d’en savoir plus sur la sauvegarde de machine virtuelle ?

Voici l’excellente vidéo de Travis Roberts expliquant le service Azure Backup et les étapes de sa mise en place sur différentes ressources Azure :

Pourquoi mettre en place l’autorisation multi-utilisateur sur les sauvegardes Azure ?

L’autorisation multi-utilisateur (MUA) pour la sauvegarde Azure vous permet d’ajouter une couche supplémentaire de protection aux opérations critiques sur vos coffres Recovery Services. Pour MUA, Sauvegarde Azure utilise une autre ressource Azure appelée protection des ressources pour garantir que les opérations critiques sont effectuées uniquement avec l’autorisation applicable.

Microsoft Doc

En y réfléchissant, un scénario apparait effectivement comme non protégé : comment sécuriser les sauvegardes contre un compte administrateur compromis ou contre une suppression accidentelle ?

En effet, un compte utilisateur Azure AD, configuré comme propriétaire ou contributeur de ressources Azure, dispose des droits pour la mise en en place de sauvegardes, mais également de ceux pour les démettre ! Les mesures listées précédemment renforcent la sécurité mais sont toutes réversibles par cet utilisateur.

Est-ce ici qu’entre en scène Azure Resource Guard ?

L’idée générale d’Azure Resource Guard est de faire reposer la répartition des tâches (donc des droits Azure) sur différents utilisateurs. Il s’agit d’un dispositif (SOD) mis en place dans tout processus de contrôle interne : acteur et contrôleur.

Comme le montre le schéma ci-dessous, deux roles sont alors nécessaires pour sécuriser les actions liées aux sauvegardes avec MUA :

  • Administrateur sauvegarde : Propriétaire ou contributeur du coffre de sauvegarde. Ce dernier met en place et gère les sauvegardes de ressources Azure. L’administrateur sauvegarde ne doit pas avoir de droits élevés et permanent sur l’Azure Resource Guard.
  • Administrateur sécurité : Propriétaire du Azure Resource Guard et gardien des opérations critiques sur le coffre de sauvegarde. Par conséquent, l’administrateur sécurité contrôle les permissions dont l’Administrateur sauvegarde a besoin pour effectuer les opérations critiques.

Quelles sont les actions restreintes grâce à Azure Resource Guard ?

L’installation du contrôle d’Azure Resource Guard sur un coffre de sauvegarde bloquera certaines actions si les droits de l’Administrateur sauvegarde sont insuffisants :

Les opérations marquées comme obligatoires ne peuvent pas être exclues de la protection par Azure Resource Guard. Enfin, cette configuration s’appliquera à tous les coffres de sauvegarde associés à celui-ci.

Où doit se trouver Azure Resource Guard ?

Le service Azure Resource Guard doit obligatoirement être sur la même région Azure que le coffre de sauvegarde qu’il protège. De plus, l’Administrateur sauvegarde ne doit pas avoir de droits de contributeur permanent sur Azure Resource Guard. Dans le cas contraire, il n’est jamais bloqué pour aucune action critique sur le coffre de sauvegarde.

Il est alors possible d’envisager différents scénarios :

  • Le coffre de sauvegarde et Azure Resource Guard sont dans la même souscription. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard.
  • Le coffre de sauvegarde et Azure Resource Guard sont dans des souscriptions différentes du même tenant. Mais l’Administrateur sauvegarde n’a pas accès à Azure Resource Guard ou à sa souscription.
  • Le coffre de sauvegarde et Azure Resource Guard sont dans des tenants différents. Mais l’Administrateur de sauvegarde n’a pas accès à Azure Resource Guard, à la souscription ou tenant correspondant.

Etape 0 : Rappel des prérequis

Comme pour beaucoup d’articles sur ce blog, nous allons créer différentes ressources sur Azure pour y parvenir. Comme à chaque fois, des prérequis sont nécessaires pour réaliser cette démonstration :

  • Un tenant Microsoft. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde hébergés sur différents tenants.
  • Une ou plusieurs souscriptions Azure. Comme indiqué plus haut, il est possible de faire interagir un Azure Resource Guard avec un coffre de sauvegarde sur différentes souscriptions Azure.
  • Une machine virtuelle déjà déployée sur un tenant accessible à l’Administrateur de sauvegarde .

Dans mon cas, j’ai utilisé deux tenants différents, différenciés dans cet article par la couleur du portail Azure pour plus de simplicité :

  • Le tenant A, noir pour l’Administrateur de sauvegarde, contient la machine virtuelle à sauvegarder et le coffre de sauvegarde.
  • Le tenant B, blanc pour l’Administrateur sécurité, contient Azure Ressource Guard.

Nous avons donc les deux environnements Azure suivants :

Tenant A.

Etape I : Création d’Azure Resource Guard

Sur le tenant B, commencez la création du service Azure Resource Guard :

Renseignez les différents champs, puis cliquez sur Suivant :

Si l’erreur suivante apparaît, retournez sur la page de la souscription Azure concernée :

Cliquez comme ceci pour constater le statut du resource provider Microsoft.DataProtection :

Cliquez alors sur celui-ci puis sur Enregistrer :

Attendez quelques minutes que le traitement se termine :

Contrôler le nouveau statut du resource provider :

Retournez dans la création de votre Azure Resource Guard pour constater la disparition du message d’erreur sur le second onglet.

Sélectionnez les opérations dont vous avez besoin de protéger et cliquez comme ceci pour les valider :

Vous pourrez toujours modifier cette liste après la création dans les propriétés d’Azure Resource Guard.

Lancez la création de votre Azure Resource Guard :

Etape I : Assignation du rôle de lecteur pour l’administrateur de sauvegarde

Afin de pouvoir interroger le service Azure Resource Guard, l’Administrateur sauvegarde doit disposer d’un rôle de lecteur sur ce dernier.

Sur le tenant B, retournez sur l’Azure Resource Guard et cliquez comme-ci pour rajouter le rôle de lecteur à l’administrateur sauvegarde :

Choisissez le rôle de lecteur puis cliquez sur Suivant :

Ajoutez votre Administrateur sauvegarde :

Cliquez pour valider :

Etape II : Création du coffre de sauvegarde

De retour sur le tenant A, recherchez le service Recovery Service Vault pour le créer :

Renseignez les champs et lancez la création du coffre de sauvegarde :

Etape III : Protégez votre coffre de sauvegarder

Retournez sur le tenant B, puis copiez la valeur suivante de votre Azure Resource Guard :

Sur le tenant A, retournez sur votre coffre de sauvegarde et cliquez ici pour mettre en place la MUA :

Effectuez les opérations suivantes et collez votre Resource Guard ID dans le champ suivant :

Contrôlez la cohérence des informations de votre Azure Resource Guard :

Sauvegardez la configuration MUA de votre coffre de sauvegarde :

Votre coffre de sauvegarde est maintenant protégé, continuez sur l’étape suivante pour vérifier le blocage des opérations pour l’Administrateur sauvegarde.

Etape IV : Contrôlez le blocage pour l’administrateur sauvegarde

Restez dans les propriétés de votre coffre de sauvegarde et cliquez sur les options de sécurité :

Vous êtes immédiatement averti de la couche de protection supplémentaire grâce au service Azure Resource Guard :

Essayez de désactiver la fonctionnalité Soft Delete et sauvegardez la nouvelle configuration :

L’action de sauvegarde échoue bien et affiche la notification d’erreur suivante :

La même opération, avec un autre compte, disposant lui de droits de contributeur sur Azure Resource Guard, dans mon exemple grâce à Azure Lighthouse, ne pose aucun souci :

Etape IV : Sauvegardez votre la machine virtuelle avec MUA

La mise en place de MUA ne bloque pas l’Administrateur sauvegarde de mettre en place de nouvelles protections pour des ressources Azure.

Pour cela, retournez sur la page principale de votre coffre de sauvegarde et cliquez comme-ceci :

Continuez la configuration avec la famille de ressources Machine virtuelle :

Ajoutez votre machine virtuelle à sauvegarder :

Cochez la case correspondante pour prendre la machine virtuelle désirée et cliquez sur OK

Activez la mise en place de la sauvegarde :

Une fois le traitement terminé, retournez sur le coffre de sauvegarde comme-ci :

Cliquez ici pour afficher les détails :

Lancez une sauvegarde immédiate :

La mise en place de la sauvegarde et la première sauvegarde n’ont pas provoqué d’erreur MUA pour l’Administrateur sauvegarde.

Contrôler l’avancement des travaux de la première sauvegarde et affichez les détails pour vérifier quand celui-ci est entièrement terminé :

Après quelques minutes et plusieurs rafraichissements, la sauvegarde est complète et correctement envoyée dans le coffre de sauvegarde.

Que peut-on encore mettre en place ?

Dans certains cas, vous devrez peut-être effectuer des opérations critiques sur vos sauvegardes et MUA peut vous aider à vous assurer qu’elles sont exécutées uniquement lorsque les approbations ou les autorisations appropriées existent. Comme nous l’avons vu précédemment, l’administrateur de sauvegarde doit avoir un rôle Collaborateur sur le service de protection des ressources pour effectuer des opérations critiques qui se trouvent dans l’étendue de la protection des ressources. L’une des façons d’autoriser l’exécution juste-à-temps pour ces opérations consiste à utiliser Azure Active Directory (Azure AD) Privileged Identity Management.

Microsoft Doc

Les étapes suivantes de cet article sont facultatives, mais peuvent simplifier le processus d’élévations des droits grâce à la combinaison de plusieurs services Azure :

  • Azure Gestion des identités privilégiées (PIM)
  • Azure Resource Guard

La Gestion des identités privilégiées Azure AD, présente dans la licence Azure AD Premium P2, apporte de la souplesse dans les autorisations de droits temporaires sur des ressources Azure.

Dans le cadre de PIM et d’Azure Resource Guard, nous aurions la cinématique suivante :

  • Etape 0 : Demande d’élévation des droits par l’Administrateur sauvegarde
  • Etape I : Validation de la demande par Administrateur sécurité pour une durée donnée
  • Etape 2 : Intervention sur les sauvegardes par l’Administrateur sauvegarde
  • Etape 3 : Fin de l’élévation des privilèges d‘Administrateur sauvegarde
Le schéma ci-dessus est un exemple de scénario possible grâce à PIM.

Etape V : Intégration de PIM sur Azure Resource Guard

Sur le tenant B, recherchez le service Azure suivant :

Cliquez sur Ressources Azure puis sur la souscription ou le groupe de ressources contenant Azure Resource Guard :

Si aucune souscription n’apparait, cliquer « Découvrir les ressources » et laissez-vous guider.

Ajoutez un nouvel assignement :

Choisissez le rôle Contributeur et reprenez l’utilisateur Administrateur sauvegarde et cliquez sur Suivant :

Conservez bien la notion d’éligibilité et cliquez sur Assigner :

Etape VI : Mise en place du processus de validation

Notre utilisateur Administrateur sauvegarde est maintenant éligible pour devenir Contributeur sur Azure Resource Guard. Seulement, il est nécessaire de mettre en place un processus de validation pour l’élévation de ses droits. Sans cela et par défaut, toutes ses demandes seront automatiquement approuvées.

Sur le tenant B et au même niveau que précédemment, cliquez comme ceci dans Azure AD PIM pour modifier les paramétrages de validation :

Cliquez sur le rôle Contributeur :

Cliquez sur Modifier :

Modifiez vos paramétrages pour intégrer l’Administrateur sécurité dans l’activation et cliquez sur Mettre à jour :

Etape VII : Test de la fonctionnalité PIM sur Azure Resource Guard

Avant d’activer le rôle Contributeur sur Azure Resource Guard via Azure AD PIM, nous allons vérifier que l’action sur la sauvegarde de la machine virtuelle n’est pas autorisée dans les conditions de base.

Sur le tenant A, retourner sur le coffre de sauvegarde et cliquez comme ceci :

Cliquez ici pour arrêter le mécanisme de sauvegarde :

Arrêtez complètement le backup et supprimer les données :

Le message d’erreur suivant devrait alors apparaître :

Il est donc bien nécessaire de faire une élévation temporaire des droits sur Azure Resource Guard. Positionnez-vous sur le tenant contenant Azure Resource Guard et lancez Azure AD PIM :

Cliquez sur Mes Rôles :

Cliquez sur Ressources Azure puis sur Activer :

Entrez une justification et une période puis cliquez sur Activer :

La notification Azure suivante doit apparaître :

Sur le tenant B, cliquez sur Approuver les demandes dans Azure AD PIM :

Cliquez sur Ressources Azure et approuvez la demande :

Confirmez la demande d’approbation :

Sur le tenant A, un contrôle sur Azure AD PIM nous montre que le rôle de Contributeur est bien actif :

Retentez alors l’opération de suppression de la sauvegarde de la machine virtuelle :

Si l’erreur suivante arrive en notification, refaite un test dans quelques minutes :

Conclusion

L’ajout de cette fonctionnalité sur un coffre de sauvegarde est un vrai plus en termes de protection des ressources Azure. Il est vrai que la situation antérieure, avec des propriétaires et des contributeurs au plein pouvoirs pouvaient inquiéter en cas de scénarios d’attaque.

Il parait indispensable de sécuriser les opérations critiques liées aux sauvegardes, bien prises en compte avec Azure Resource Guard :

MUA apporte une vraie réponse pour protéger encore plus les sauvegardes et sans surcoût, sauf si Azure AD PIM est présent dans votre architecture. Nul doute qu’Azure Resource Guard va apporter encore plus de protection sur d’autres services au fil de ses évolutions.

Machine virtuelle : changez de taille !

Il arrive qu’une machine virtuelle ne corresponde plus aux besoins initialement définis avec sa taille. Pas de panique ! Un changement est toujours possible après coup. L’un des grands avantages d’Azure est la possibilité de modifier la taille des machines virtuelles, à la volée, des besoins en termes de performances du processeur, du réseau ou de disques.

Dans cet article, nous allons démontrer ensemble la simplicité de changer la taille d’une machine virtuelle, mais également les étapes additionnelles pour un changement particulier.

Dans quel cas redimensionner ?

Lorsque l’on examine le redimensionnement de machines virtuelles sous Azure, trois axes définissent ce processus de changement de taille :

  • Localisation : votre région Azure ne contient pas le matériel nécessaire pour prendre en charge la taille de machine virtuelle souhaitée.
  • Interruption : vous devrez dans certains cas désallouer la machine virtuelle. Cela peut se produire si la nouvelle taille n’est pas disponible sur le cluster matériel qui l’héberge actuellement.
  • Restriction : Si votre machine virtuelle utilise le stockage Premium, assurez-vous que vous choisissez une version s de la taille pour obtenir le support du stockage Premium.

Tailles des machines virtuelles dans Azure

Avant de basculer sur le portail Azure pour effectuer les étapes de modification de taille, voici un rappel de l’offre des machines virtuelles Azure. Afin d’y voir plus clair, Microsoft a segmenté son offre de machines virtuelles par famille, correspondant à des scénarios de besoin utilisateur :

En exemple, voici la définition donnée par Microsoft pour des besoins GPU :

Les tailles de machine virtuelle au GPU optimisé sont des machines virtuelles spécialisées disponibles avec des GPU uniques, multiples ou fractionnaires. Ces tailles sont conçues pour des charges de travail de visualisation, mais également de calcul et d’affichage graphique intensifs.

Microsoft Doc

Les familles sont généralement couvertes par plusieurs séries. Une série est une combinaison CPU + RAM + Autre critères. Les séries sont régulièrement mis à jour par Microsoft via des versions. Voici en exemple le détail de la composition pour la série NCv3 :

Les machines virtuelles de série NCv3 sont optimisées par les GPU NVIDIA Tesla V100. Ces GPU peuvent fournir des performances de calcul une fois et demie supérieure à celles de la série NCv2… les machines virtuelles de la série NCv3 sont également pilotées par des processeurs Intel Xeon E5-2690 v4 (Broadwell).

Microsoft Doc

Enfin, chaque série dispose plusieurs SKUs pour proposer différentes puissances. Toujours en exemple, la série graphique NCv3 :

La taille de la machine virtuelle influe également sur le prix de celle-ci. Toujours en exemple, la série graphique NCv3 :

Les instances réservées, d’un ou trois ans, diminuent fortement le prix des machines virtuelles.

Codification Azure

Cette large découpe propose aux utilisateurs un très grand nombre de machines virtuelles possibles. Dans cette jungle de SKUs, Microsoft a mis en place une codification précise dans la dénomination.

[Famille] + [Sous-famille]* + [nombre de processeurs virtuels] + [Processeurs virtuels avec contraintes]* + [Fonctionnalités supplémentaires] + [Type d’accélérateur]* + [Version]
ValeurExplication
FamilleIndique la série de la famille de machines virtuelles
*Sous-familleUtilisé uniquement pour différencier des machines virtuelles spécialisées
Nombre de processeurs virtuelsIndique le nombre de processeurs virtuels de la machine virtuelle
*Processeurs virtuels avec contraintesUtilisé pour certaines tailles de machine virtuelle uniquement. Indique le nombre de processeurs virtuels pour la taille des processeurs virtuels avec contraintes
Fonctionnalités supplémentairesUne ou plusieurs lettres minuscules indiquent des fonctionnalités supplémentaires, telles que :
a = processeur basé sur AMD
b = bloquer les performances de stockage
d = diskfull (c.-à-d., un disque temporaire local présent) ; ceci concerne les nouvelles machines virtuelles Azure, consultez Séries Ddv4 et Ddsv4
i = taille isolée
l = mémoire insuffisante ; une quantité de mémoire inférieure à la taille d’utilisation intensive de la mémoire
m = utilisation intensive de la mémoire ; la plus grande quantité de mémoire dans une taille particulière
t = très petite mémoire ; la plus petite quantité de mémoire dans une taille particulière
s = capacité de stockage Premium, y compris l’utilisation possible de SSD Ultra (Remarque : certaines tailles plus récentes sans l’attribut de s peuvent toujours prendre en charge le stockage Premium, par exemple M128, M64, etc.)
*Type d’accélérateurIndique le type d’accélérateur matériel dans les références (SKU) spécialisées/GPU. Seules les nouvelles références (SKU) spécialisées/GPU lancées à partir du troisième trimestre 2020 auront l’accélérateur matériel dans leur nom.
VersionIndique la version de la série de machines virtuelles

Voici un exemple de dénomination pour la machine virtuelle graphique NC4as_T4_v3 :

ValeurExplication
FamilleN
Sous-familleC
Nombre de processeurs virtuels4
Fonctionnalités supplémentairesa = processeur basé sur AMD
s = capacité de stockage Premium
Type d’accélérateurT4
Versionv3

Avec toutes ces informations, nous allons pouvoir nous intéresser au changement de SKU sur une machine virtuelle existante.

Etape 0 : Rappel des prérequis

Pour cela, nous allons créer différentes ressources sur Azure pour y parvenir. Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une machine virtuelle déployée et démarrée

Comme le montre la copie d’écran ci-dessous, ma machine virtuelle dispose actuellement de la taille D4ds v4

Afin de mesurer les impacts d’un changement de taille sur une machine virtuelle démarrée, j’ai également ouvert une connexion RDP à celle-ci

Test I : Changement d’une taille dans la même série

Le changement de taille de la machine virtuelle s’effectue depuis le portail Azure via la section Taille.

Azure y regroupe différentes tailles, accessibles ou non :

  • Tailles de machine virtuelle les plus populaires
  • Autres séries disponibles
  • Anciennes séries toujours disponibles
  • Tailles indisponibles car problème de quota
  • Tailles indisponibles car disque incompatible
  • Tailles indisponibles car image incompatible

Jouez avec les filtres suivants pour trouver la taille adaptée

Certaines tailles ne sont même pas visibles.

Sélectionnez la taille et cliquez sur redimensionner

Une fois déclenché, une notification de traitement apparait dans votre portail Azure

La session RDP est-elle aussi coupée

Après traitement (30 secondes environ), la machine virtuelle retrouve son status démarré. La nouvelle taille se retrouve alors sur la page principale de la machine virtuelle Azure

La réouverture manuelle de la session RDP montre bien la nouvelle puissance

Test II : Changement d’une taille dans une série disponible

Continuez vos tests en effectuant un changement de taille vers une autre famille de machine virtuelle

Là encore, la session RDP se ferme et la notification de changement apparaît sur le portail Azure. Moins d’une minute plus tard, la machine virtuelle repart avec sa dernière taille

Test III : Changement d’une taille dans une série disponible

Dans certains cas, il est nécessaire de partir sur une taille de machine virtuelle ayant des propriétés différentes. Ma machine virtuelle, actuellement en Standard F8s v2, dispose d’un stockage temporaire.

Le disque temporaire est très utile pour les données qui, vous l’aurez deviné, sont de nature temporaire. Un excellent exemple de ce type de données pour Windows est le pagefile. Lorsqu’une nouvelle machine virtuelle Windows est provisionnée à partir d’une image dans Azure, le pagefile est configuré si cela est possible pour qu’il soit situé sur ce disque temporaire.

Ce stockage temporaire se retrouve alors sur le disque D

Pour la plupart des machines virtuelles Windows, le volume sur le disque temporaire à la lettre de lecteur D:.
Il a également l’étiquette de lecteur « Temporary Storage ».

Les clients ne doivent pas utiliser le disque temporaire pour des données qui doivent être persistantes.

Un retour dans la liste des tailles disponibles pour ma machine virtuelle vm001 ne permet pas de choisir une machine virtuelle dépourvue de disque temporaire.

Dans ce cas, pas le choix, la recréation d’une nouvelle machine virtuelle est un passage obligatoire.

Etape I : Créer une sauvegarde du ou des disques présents

Allez sur la page des disques de la machine virtuelle et cliquez sur chacun d’eux

Créez une sauvegarde de chaque disque (OS et Data)

Vérifiez les champs et lancez la création

Une fois terminé, cliquez ici pour accéder au snapshot

Etape II : Créez un ou des disques depuis la ou les sauvegardes

Lancez la création du ou des nouveaux disques depuis le ou les snapshots créés

Une fois terminé, cliquez ici pour accéder au disque créé

Etape III : Création de la nouvelle machine virtuelle

Il ne reste plus qu’à rattacher ce ou ces disques à une nouvelle machine virtuelle

Renseignez tous les champs nécessaires et la nouvelle taille de machine désirée

Lancez la création de la machine virtuelle

Cliquez ici pour retrouver les propriétés de votre nouvelle machine virtuelle

Constatez la bonne taille de votre machine virtuelle Standard D4s v4

Rouvrez une session RDP sur cette nouvelle machine virtuelle pour finaliser les réglages de pagefile. Un message d’avertissement apparaît à l’ouverture de la session

Sélectionnez les paramétrages automatiques Windows

Redémarrez la machine virtuelle pour appliquer les modifications pagefile

Et vous voilà avec la nouvelle taille ????

Conclusion

Azure apporte beaucoup de flexibilité avec le changement de taille pour les machines virtuelles. Il est même possible de scripter le changement de taille selon les besoins ou les pics de charges.

Comme toujours John nous propose une vidéo pour aller plus loin sur ce sujet ????

Sauvegarde des disques de VM via Runbook/Snapshot

Sauvegarder ou ne pas sauvegarder ? Telle est la question ! Évidemment, la sauvegarde n’est pas un choix mais bien une nécessité ! Dans cet article, nous allons prendre le temps de nous intéresser aux sauvegardes de machines virtuelles dans un cas très particulier.

Cet article n’a pas pour but de vous parler de la sauvegarde native des machines virtuelles sous Azure, via le service Azure Recovery Service Vault. Cette fonctionnalité est à la portée de tous et fonctionne sans souci.

Mais il arrive dans certains cas que ce service ne fonctionne pas pour certaines machines virtuelles… Voici par exemple le déploiement d’un firewall Fortigate, disponible sur la marketplace d’Azure

Une fois cette machine virtuelle déployée, j’ai rajouté des disques de données supplémentaires à cette dernière

J’ai ensuite créé un Recovery Service Vault pour mettre en place une sauvegarde habituelle

J’ai continué avec la configuration de la police de sauvegarde avec ma machine virtuelle

Seulement l’activation de la sauvegarde Azure me pose quelques soucis

Voici le détail du message d’erreur

{
    "status": "Failed",
    "error": {
        "code": "UserErrorUnSupportedDistribution",
        "message": "Unsupported OS version for virtual machine backup."
    }
}

Ce problème est visiblement connu sur la toile depuis plusieurs années, mais pour l’instant aucune alternative n’a été proposée par Microsoft. Inutile de penser aux agents MARS ou MABS…

Que faire dans ce cas ?

Il est bien possible de faire des snapshots réguliers … à la main !

En quête d’automatisation, je suis tombé sur plusieurs articles intéressants, assez proche sur la solution apportée :

Qu’est-ce qu’Azure Automation ?

Azure Automation est un service d’automatisation et de configuration basé sur le cloud qui prend en charge la gestion cohérente de vos environnements Azure et non-Azure. Il comprend l’automatisation des processus, la gestion des configurations, la gestion des mises à jour, les capacités partagées et les fonctionnalités hétérogènes. L’automatisation vous donne un contrôle total pendant le déploiement, l’exploitation et la mise hors service des charges de travail et des ressources.

Yst@IT
Merci Travis !

Dans notre déploiement, nous allons utiliser un compte Azure Automation pour stocker et lancer notre script PowerShell. Ce script prend en compte les disques rattachés à la machine virtuelle afin d’en faire des snapshots pour chacun d’eux.

Etape 0 : Rappel des prérequis

Passé cette rapide explication, nous allons créer différentes ressources sur Azure pour y parvenir. Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une machine virtuelle déployée

Etape I : Affectation d’un tag sur la machine virtuelle

Le script va effectuer une recherche sur les machines virtuelles à sauvegarder. Il est nécessaire de marquer celles qui nous intéresse. Rendez-vous sur la machine virtuelle concernée et ajoutez-y le tag suivant :

  • Nom : Snapshot
  • Valeur : True

Etape II : Création du compte Azure Automation

Tout commence par la création d’un compte Azure Automation pour héberger notre script PowerShell. Utilisez la barre de recherche du portail Azure pour commencer éa création

Renseignez les éléments de base sur le premier onglet du compte puis lancez directement la création de celui-ci :

Cherchez la section Paramétrages du compte, puis cliquez sur Identité et enfin assignez les rôles Azure

Ajoutez le rôle de Contributeur sur le groupe de ressources contenant la machine virtuelle, puis sauvegardez

Quelques minutes plus tard, constatez la présence de ce dernier dans le tableau précédent

Etape III : Création du Runbook

Continuez avec la création de votre runbook

Renseignez les champs pour valider sa création

La création vous ouvre ensuite l’éditeur de code

Collez le script suivant dans l’éditeur, ou également disponible sur mon GitHub

# Use Managed Identity
Connect-AzAccount -Identity

# Get VMs with snapshot tag
$tagResList = Get-AzResource -TagName "Snapshot" -TagValue "True" | foreach {
Get-AzResource -ResourceId $_.resourceid
}

foreach($tagRes in $tagResList) {
if($tagRes.ResourceId -match "Microsoft.Compute")
{
$vm = Get-AzVM -ResourceGroupName $tagRes.ResourceId.Split("//")[4] -Name $tagRes.ResourceId.Split("//")[8]
#Set local variables
$location = $vm.Location
$resourceGroupName = $vm.ResourceGroupName
$vmname = $vm.Name

# Generate OS snapshot configuration
$snapshotName = $vm.StorageProfile.OsDisk.Name + $(get-date -Format 'yyyy-MM-dd-m')
$snapshot =  New-AzSnapshotConfig `
-SourceUri $vm.StorageProfile.OsDisk.ManagedDisk.Id `
-Location $location `
-CreateOption copy

# Create OS snapshot
New-AzSnapshot `
-Snapshot $snapshot `
-SnapshotName $snapshotName `
-ResourceGroupName $resourceGroupName

# Add SnapshotTags
$tags = (Get-AzResource -ResourceGroupName $resourceGroupName -Name $snapshotName).Tags
$tags += @{Location="$location"; Vm="$vmname"; SnapshotDate="$(get-date -Format 'yyyy-MM-dd-m')"; Script="JLOScript"}
Set-AzResource `
-ResourceGroupName $resourceGroupName `
-Name $snapshotName `
-ResourceType "Microsoft.Compute/snapshots" `
-Tag $tags `
-Force

# Generate DATA snapshot configuration
if($vm.StorageProfile.DataDisks.Count -ge 1){

#Condition with more than one data disks
for($i=0; $i -le $vm.StorageProfile.DataDisks.Count - 1; $i++){

# Generate snapshot configuration
$snapshotName = $vm.StorageProfile.DataDisks[$i].Name + $(get-date -Format 'yyyy-MM-dd-m')
$snapshot =  New-AzSnapshotConfig `
-SourceUri $vm.StorageProfile.DataDisks[$i].ManagedDisk.Id `
-Location $location `
-CreateOption copy

# Create snapshot
New-AzSnapshot `
-Snapshot $snapshot `
-SnapshotName $snapshotName `
-ResourceGroupName $resourceGroupName

# Add SnapshotTags
$tags = (Get-AzResource -ResourceGroupName $resourceGroupName -Name $snapshotName).Tags
$tags += @{Location="$location"; Vm="$vmname"; SnapshotDate="$(get-date -Format 'yyyy-MM-dd-m')"; Script="JLOScript"}
Set-AzResource `
-ResourceGroupName $resourceGroupName `
-Name $snapshotName `
-ResourceType "Microsoft.Compute/snapshots" `
-Tag $tags `
-Force
}
}

else{
Write-Host $vmInfo.Name + " doesn't have any additional data disk."
}
}

else{
$tagRes.ResourceId + " is not a compute instance"
}
}

Etape IV : Test du Runbook

Sauvegardez votre code et lancez un test

Cliquez sur le bouton ci-dessous pour démarrer le test

Attendez un peu

Constatez le succès ou l’échec de votre runbook

Retournez sur le groupe de ressources pour y voir apparaître les snapshots des disques

Cliquez sur l’un d’eux et constatez les tags

Etape V : Mise en place de l’automatisation

Une fois constaté le succès de votre script, il ne vous reste qu’à le publier et à le programmer périodiquement. Retournez sur votre runbook et cliquez sur Publier

Ajoutez une programmation périodique sur votre runbook

Cliquez sur le premier lien

Cliquez sur ajouter une programmation

Renseignez les champs selon votre besoin

Confirmez la bonne création de votre programmation

Contrôlez au prochain lancement de la programmation dans le groupe de ressources

Contrôlez également l’historique des lancements du runbook

Conclusion

Et voilà ! Une tâche manuelle de moins… Cette petite opération nous a permis de bien comprendre l’utilité et la puissance des automatismes possibles sur Azure. Celui-ci est bien évidemment très simple, d’autres sont sans doute très intéressants à mettre en oeuvre ????.

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 ????