Auteur/autrice : Jean-Loup Orgitello

Coûts des stockages Azure

Les récentes et excellentes vidéos postées par Travis Roberts sur sa chaîne YouTube m’ont motivé de faire des tests sur différents espaces de stockages Azure. Le choix de la forme de stockage sur le Cloud est primordial, car il détermine son prix et ses performances selon vos besoins. D’ailleurs, saviez-vous qu’il existe maintenant un compte de stockage provisionné v2 de type de standard ?

Sa première vidéo, visible ci-dessous, montre les 3 modèles de facturation disponibles sur le compte de stockage Azure :

  • Pay-As-You-Go (PAYG)
  • Provisionné V1
  • et le tout nouveau Provisionné V2 :

Sa seconde vidéo, disponible ci-dessous, vous fournit des conseils pratiques pour assurer un fonctionnement sans souci pour FSLogix, tout en mettant en lumière les mauvaises configurations pouvant entraîner des goulots d’étranglement très frustrants au niveau des performances :

Pour rappel, plusieurs articles sur ce blog ont déjà abordé le sujet du stockage sur Azure :

Enfin, Microsoft met à disposition plusieurs pages de documentation très intéressantes sur les stockages Azure et leurs performances, dont voici quelques liens :

Dans cet article, je vous propose donc un petit exercice de test de performances de différents espaces de stockages Azure, comprenant à la fois différents types de disques managés et comptes de stockages :

  • Disques :
    • Premium SSD
    • Standard SSD
    • Standard HDD
    • Premium SSD v2
  • Comptes de stockage :
    • provisionné v2
    • provisionné v1
    • PAYG – Optimisé aux transactions
    • PAYG – Chaud
    • PAYG – Froid

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

Dans cet article, nous allons déployer une machine virtuelle Azure, et différents types de stockage. Cela nous permettra de comparer leurs performances, avec pour socle un environnement de test commun.

Etape I – Déploiement de la machine virtuelle Azure :

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

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle :

Renseignez tous les champs concernant la souscription Azure et la région adéquates :

Choisissez une image, puis taille de machine virtuelle présente dans la liste :

Renseignez les identifiants du compte administrateur local, cochez la case concernant la licence, puis cliquez sur Suivant :

Dans l’onglet dédié au stockage, ajoutez tous les disques que vous souhaitez comparer, puis cliquez sur Suivant :

Retirer l’adresse IP publique de votre machine virtuelle, puis lancez la validation Azure :

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 :

Activez les insights de votre machines virtuelles afin de récupérer quelques métriques de performance :

Configurer le stockage de ces insights sur un LOA :

Déployez également le service Azure Bastion pour vous y connecter plus facilement en RDP de façon sécurisée :

Notre machine virtuelle est maintenant déployée, nous pourrons nous y connecter quand le service Azure Bastion sera entièrement déployé.

En attendant, nous allons pouvoir continuer les déploiements des autres stockages Azure.

Etape II – Déploiement des comptes de stockages Azure :

Depuis le portail Azure, commencez par rechercher le service des comptes de stockage :

Cliquez-ici pour créer votre premier compte de stockage :

Nommez ce dernier, spécifiez le SKU voulu, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre premier compte de stockage :

Comme le montre la copie d’écran ci-dessous, j’ai créé plusieurs compte de stockage afin de comparer les éléments suivants :

  • Les performances IOPS bande passante
  • Les performances de bande passante
  • Les prix

J’ai donc configuré les comptes de stockage Azure selon les caractéristiques suivants :

J’ai souhaité créer autant de comptes de stockage que de partage Azure Files afin de ne pas créer d’interférences dans leurs performances :

Voici le compte de stockage avec un Azure File dont le niveau d’accès est optimisé pour les transactions :

Voici le compte de stockage avec un Azure File standard en provisionnement v2 :

Voici le compte de stockage avec un Azure File de type premium :

Voici le compte de stockage avec un Azure File dont le niveau d’accès est chaud :

Voici le compte de stockage avec un Azure File dont le niveau d’accès est froid :

Pour chacun des comptes de stockage, j’ai récupéré le script de connexion en utilisant leur clef d’accès respective afin de monter les partages en lecteurs réseaux sur ma machine virtuelle de test :

La suite se passe directement sur la machine virtuelle de test.

Etape III – Configurations des stockages :

Connectez-vous à votre machine virtuelle de test avec le compte d’un administrateur local :

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 nouveaux disques de données ajoutés, cliquez sur OK :

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

Nommez au besoin les disques afin de les identifier plus rapidement :

Ouvrez Windows Terminal afin de monter les différents Azure File créés sur les comptes de stockages :

Contrôlez la présence de tous les stockages dans l’explorateur de fichier, encore une fois, 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 deux caractéristiques suivantes :
    • 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 stockages Azure :

Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage.

Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G D:\diskpsdtmp.dat > IOPS-PremiumSSD.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G G:\diskpsdtmp.dat > IOPS-StandardSSD.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G H:\diskpsdtmp.dat > IOPS-StandardHDD.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G F:\diskpsdtmp.dat > IOPS-PremiumSSDv2.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G V:\diskpsdtmp.dat > IOPS-jlostov2std.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G W:\diskpsdtmp.dat > IOPS-jlostov1prm.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G X:\diskpsdtmp.dat > IOPS-jlostopaygopt.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Y:\diskpsdtmp.dat > IOPS-jlostopayghot.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b8K -Sh -L -c50G Z:\diskpsdtmp.dat > IOPS-jlostopaygcool.txt

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

  • -d900 : 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
  • -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)
  • E:\diskpsdtmp.dat : chemin du fichier généré pour le test
  • > IOPS-PremiumSSD.txt : fichier de sortie des résultats

Une fois tous les tests terminés, retrouvez les fichiers des résultats :

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

Continuons avec les tests sur les débits maximums des espaces de stockage Azure.

Etape VI – Tests des débits des stockages Azure :

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

Toujours sur Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :

C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G D:\diskpsdtmp.dat > Throughput-PremiumSSD.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G G:\diskpsdtmp.dat > Throughput-StandardSSD.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G H:\diskpsdtmp.dat > Throughput-StandardHDD.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G F:\diskpsdtmp.dat > Throughput-PremiumSSDv2.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G V:\diskpsdtmp.dat > Throughput-jlostov2std.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G W:\diskpsdtmp.dat > Throughput-jlostov1prm.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G X:\diskpsdtmp.dat > Throughput-jlostopaygopt.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Y:\diskpsdtmp.dat > Throughput-jlostopayghot.txt
C:\SPD\amd64\diskspd.exe -d900 -r -w100 -F4 -o128 -b64K -Sh -L -c50G Z:\diskpsdtmp.dat > Throughput-jlostopaygcool.txt

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

  • -d900 : 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
  • -b64K : taille du bloc
  • -Sh : ne pas utiliser le cache
  • -L : mesure de la latence
  • -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)
  • E:\diskpsdtmp.dat : chemin du fichier généré pour le test
  • > IOPS-PremiumSSD.txt : fichier de sortie des résultats

Une fois tous les tests terminés, retrouvez les fichiers des résultats :

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

Pour plus de clarté, j’ai synthétisé tous mes résultats de IOPS et DEBITS dans l’étape suivante.

Etape VII – Synthèse des résultats :

Voici un tableau synthétique des différentes mesures faites sur 5 essais :

Fichier Excel des résultatsTélécharger
  • v1 premier essai à la chaîne (Les IOPS, puis les DEBITS)
  • v2 second essai à la chaîne (Les IOPS, puis les DEBITS)
  • v3 troisième essai en même temps (Tous les IOPS, puis tous les DEBITS)
  • v4 quatrième essai en même temps (Les IOPS, puis les DEBITS)
  • v5 dernier essai à la chaîne (Les IOPS, puis les DEBITS)

Les performances IOPS et DÉBITS sont différentes, car les configurations des espaces de stockages sont différentes.

J’ai souhaité comparer les chiffres de Diskspd avec ceux donnés par Azure Monitor.

Pour les disques de la machine virtuelles, nous sommes sur les mêmes chiffres entre les 2 sources :

  • IOPS :
  • Débits :

Pour les comptes de stockages, c’est plus difficile à vérifier, car seuls des volumes de transactions sont disponibles en tant que métriques Azure :

Mais le compte de stockage de type v1 (premium) affiche bien les mêmes IOPS :

En revanche, pour les débits sur ce même compte de stockage de type v1 (premium), j’avais obtenu via Diskspd des chiffres correspondant à la moitié de ceux donnés par Azure Monitor :

Etape VIII – Analyse des coûts :

Tous les stockages Azure listés dans cet articles fonctionnent sur différentes grilles tarifaires. Azure Pricing Calculator nous donne malgré tout un premier point de comparaison grossier.

Le tableau ci-dessous reprend toutes les options de base des stockages Azure, sans y inclure de transactions, et en prenant que pour paramètre une taille de 1024 Go :

A titre d’information, le disque Premium SSD v2 semble meilleur marché que le disque Premium SSD quand les performances configurées sont les mêmes :

Enfin, ayant testé Diskspd de façon 100% identique sur tous les stockages testés, je trouvais intéressant de vous montrer l’impact financier via le Gestionnaire des coûts Azure.

Diskspd a donc été lancé au total 10 x 15 minutes sur les 9 espaces de stockage Azure, et cela donne les coûts suivants :

Malgré des performances très honorables, les comptes de stockages de type PAYG sont à proscrire si les opérations d’écriture et de lecture sont très fréquentes :

  • Coûts sur le compte de stockage froid : les opérations d’écritures représentent 99.99% du coût total !
  • Coûts sur le compte de stockage chaud : les opérations d’écritures représentent 99.99% du coût total !
  • Coûts sur le compte de stockage optimisé pour les transactions : les opérations d’écritures représentent 99.90% du coût total !
  • Le tarif élevé du compte de stockage standard v2 s’explique par la configuration très poussée sur ce dernier

Mais Diskspd n’aura pas été capable de les atteindre :

  • Quant aux disques de la machine virtuelles, leurs coûts semblent pour eux très contenus :

Et cela malgré la configuration très performante renseignée sur le disque Premium SSD v2 :

C’est à se demander si les profils FSLogix n’auraient pas leur place sur un disque Premium SSD v2, en lieu et place d’un compte de stockage Premium, mais sans oublier bien sûr d’y ajouter le prix de la machine virtuelle :

Conclusion

En conclusion, les comptes de stockage et les disques managés Azure offrent tous deux des solutions robustes et flexibles pour répondre à divers besoins de performance. Les nouvelles options de SKU permettent de personnaliser les débits et les IOPS, offrant ainsi une adaptabilité précieuse pour des exigences spécifiques. La visualisation des performances via Azure Monitor ajoute une couche de transparence et de contrôle appréciable.

Cependant, au-delà des performances, le coût reste un facteur crucial à considérer. Les frais peuvent rapidement augmenter en fonction du type de stockage et des opérations effectuées. Il est donc essentiel de garder à l’esprit les coûts associés et de toujours se référer aux caractéristiques des disques, aux options de stockage disponibles, ainsi qu’aux fonctionnalités de récupération et de réplication.

Ces éléments sont déterminants pour faire un choix éclairé et optimiser l’utilisation des ressources Azure.

AVD + mise à l’échelle dynamique

Microsoft vient d’annoncer lors de l’Ignite 2024 le plan de mise à l’échelle dynamique pour Azure Virtual Desktop. Mais qu’apporte donc cette nouvelle méthode dite dynamique à cette fonctionnalité déjà existante sur Azure Virtuel Desktop? C’est ce que nous allons voir ensemble dans cet article, encore dans un état de préversion à l’heure où ces lignes sont écrites.

Mais qu’est-ce que le plan de mise à l’échelle ?

La plan de mise à l’échelle, ou autoscaling en anglais, est déjà disponible pour les environnements AVD mutualisés et individuels depuis déjà quelques temps. Deux articles parlant de ce sujet sont déjà disponibles sur ce blog :

La mise à l’échelle automatique vous permet d’effectuer un scale-up ou un scale-down de vos hôtes de session de machines virtuelles dans un pool d’hôtes pour optimiser les coûts de déploiement.

Microsoft Learn

Microsoft a mis à jour sa documentation afin d’expliquer en détail les 4 grandes fonctionnalités de la mise à l’échelle dans le cadre d’un environnement AVD partagé :

Voici d’ailleurs une représentation diapo de trois d’entre elles :

Comme le montre la première animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut allumer progressivement des machines virtuelles quand une certaine limite d’utilisateurs est atteinte.
Comme le montre la seconde animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut éteindre des machines virtuelles éteintes tant celles-ci ne sont pas exploitées.
Comme le montre la troisième animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut forcer des utilisateurs à se déconnecter que si vous avez activé ce paramètre dans la phase de descente en charge uniquement.

Grâce à ces différents mécanismes, le plan de mise à l’échelle vous permet de moduler à la hausse ou à la baisse le nombre de VMs allumées à un moment précis selon les besoins.

Mais quelles sont les 4 phases du plan de mise à l’échelle ?

Vous pouvez établir un plan de mise à l’échelle basé sur :

  • Des créneaux horaires exprimés en heures.
  • Des créneaux journaliers exprimés en jours.

Tous les plannings de mise à l’échelle AVD comprennent les 4 phases suivantes :

  1. Montée en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se connecter aux hôtes de session. Par exemple, si votre bureau ouvre à 9h, vous pouvez prévoir que les utilisateurs commencent à se connecter entre 8h30 et 9h.
  2. Période de pointe : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de connexion stable. Par exemple, entre 09h et 17h, la plupart des utilisateurs sont connectés et travaillent activement. De nouveaux utilisateurs peuvent se connecter, mais à un rythme plus lent que pendant la montée en charge.
  3. Descente en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se déconnecter et à terminer leurs sessions pour la journée de travail. Par exemple, entre 17h et 18h, les utilisateurs commencent à se déconnecter. Dans cette phase, vous pouvez définir un pourcentage minimum plus bas d’hôtes actifs et une taille minimale de pool d’hôtes pour réduire le nombre de VM d’hôtes de session en état de fonctionnement ou arrêtées.
  4. Hors-période : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de déconnexion stable. Par exemple, après 20h, la plupart des utilisateurs sont déconnectés. De nouveaux utilisateurs peuvent se connecter pour des scénarios d’urgence, mais ces cas peuvent être rares.

Azure Virtual Desktop propose également des graphiques afin de comprendre le gain et l’efficacité du mécanisme :

Mais qu’apporte la méthode dynamique du plan de mise à l’échelle ?

Peu importe la méthode choisie, les phases et les fonctionnalités d’un plan de mise à l’échelle restent les mêmes. Mais ce qui change concerne directement les machines virtuelles AVD :

  • Dans la méthode dite Gestion de l’énergie : la plan de mise à l’échelle peut allumer et éteindre des machines virtuelles AVD selon les usages et la programmation mise en place.
  • Dans la méthode dite dynamique : la plan de mise à l’échelle peut créer ou supprimer des machines virtuelles AVD selon les usages et la programmation mise en place.

La méthode dynamique du plan de mise à l’échelle s’appuie également sur la toute nouvelle fonctionnalité AVD, appelée Mise à jour de l’hôte de session pour Azure Virtual Desktop, pour recréer les machines virtuelles.

La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session. La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour. Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.

Voici les modifications que vous pouvez apporter lors d’une mise à jour :

  • Image de machine virtuelle
  • Taille de la machine virtuelle
  • Type de disque de machine virtuelle
  • Type de sécurité de la machine virtuelle
  • Informations d’identification de jonction de domaine Active Directory
  • Inscription à Microsoft Intune
  • Informations d’identification de l’administrateur local
  • Exécutez un script PowerShell de configuration personnalisé

Microsoft Learn

Cette approche de création / suppression intégrée permet donc de réduire encore plus les coûts.

Couplée avec la mise à jour de l’hôte de session, la création et la suppression de machines virtuelles AVD devient d’autant plus simple, et assure de toujours disposer de ressources Azure Virtual Desktop dans leur dernière version.

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la méthode dynamique du plan de mise à l’échelle d’Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un environnement AVD configuré avec la mise à jour de l’hôte de session

Il ne faut pas oublier que certaines contraintes AVD sont de rigueur :

  • Ne fonctionne pas pour les pool d’hôtes AVD individuels
  • Ne fonctionne pas pour le moment sur un environnement AVD joint uniquement à Entra ID
  • Ne fonctionne pas sur un AVD hébergé sur Azure Local
  • Nécessite également de disposer d’un AVD déjà configuré avec la mise à jour de l’hôte de session

Cette information est disponible ici :

Il est également nécessaire de renseigner un nombre maximal de sessions AVD :

Commençons par ajouter des permissions RBAC nécessaires à la gestion des VMs AVD.

Etape I – Ajout des permissions RBAC :

Le traitement de création/suppression des machines virtuelles AVD a besoin de lire la configuration gérée par le nouvelle orchestrateur en chargement de votre pool d’hôtes. Il est pour l’instant nécessaire créer un rôle Azure personnalisé afin de pouvoir récupérer ces informations.

Pour cela, rendez-vous dans le portail Azure, puis commencez sa création depuis le groupe de ressources contenant votre environnement AVD :

Nommez votre nouveau rôle personnalisé, puis cliquez sur Suivant :

Recherchez la permission suivante, puis cliquez sur lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre rôle Azure personnalisé :

Toujours sur votre groupe de ressources AVD, assignez à l’application Azure Virtual Desktop les 3 rôles suivant, en plus de votre nouveau rôle personnalisé :

  • Contributeur de mise sous et hors tension de la virtualisation du Bureau
  • Contributeur à la machine virtuelle de la virtualisation des postes de travail
  • Utilisateur de Key Vault Secrets

Une fois les droits en place, il ne reste qu’à rajouter la mise à l’échelle dynamique sur notre environnement Azure Virtual Desktop.

Etape II – Création du plan de mise à l’échelle dynamique :

Comme avant, la création d’un plan de mise à l’échelle dynamique AVD apporte les avantages / restrictions suivants :

  • Le plan de mise à l’échelle dynamique est utilisable pour un ou plusieurs environnement Azure Virtual Desktop, à la condition que ces derniers nécessitent une gestion horaire identique
  • Ne pas associer le plan de mise à l’échelle dynamique avec d’autres solutions tierces de gestion des ressources Azure
  • Il n’est pas possible d’associer plusieurs plans de mise à l’échelle dynamique sur un seul environnement AVD
  • Le plan de mise à l’échelle dynamique est dépendant d’un seul fuseau horaire
  • Le plan de mise à l’échelle dynamique est configurable sur plusieurs périodes distinctes
  • Le plan de mise à l’échelle dynamique est opérationnel dès sa configuration terminée

Avant cela, prenez le temps de vérifier la configuration de l’hôte de session AVD déjà en place :

La création du plan de mise à l’échelle dynamique se fait directement sur la page d’Azure Virtual Desktop, cliquez ici pour démarrer sa création :

Remplissez le premier onglet avec vos informations de base et indiquez que votre environnement AVD est partagé :

Choisissez l’option le plan de mise à l’échelle dynamique, puis cliquez sur Suivant :

L’onglet suivant vous permet de définir quand le plan de mise à l’échelle dynamique s’active pour suivre les besoins de montée / descente en puissance tout au long de la journée.

Cliquez comme ceci pour ajouter votre première période :

Choisissez un Nom, puis sélectionnez les Jours adéquats (les valeurs par défaut qui s’affichent lorsque vous créez une planification sont les valeurs suggérées pour les jours de la semaine, mais vous pouvez les modifier selon vos besoins) :

Les informations ci-dessous de l’onglet Général ne servent qu’à définir les valeurs reprises dans les autres onglets :

  • Pourcentage minimum d’hôtes actifs : exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée :
Par exemple, si le pourcentage minimum d’hôtes actifs (%) est fixé à 10 et que la taille minimum du pool d’hôtes est fixée à 10, le plan de mise à l’échelle dynamique veillera à ce qu’un hôte de session soit toujours disponible pour accepter les connexions des utilisateurs.
  • Nombre min de VMs : nombre de machines virtuelles hôtes de session devant toujours faire partie du pool d’hôtes. Ces dernières peuvent être active ou à l’arrêt niveau OS.
  • Nombre max de VMs : nombre de machines virtuelles hôtes de session que le plan de mise à l’échelle dynamique ne dépassera pas. Ces dernières peuvent être active ou à l’arrêt niveau OS.

Puis cliquez sur Suivant :

Montée en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se connecter aux hôtes de session.

  • Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
  • Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
  • Seuil de capacité : pourcentage de la capacité disponible du pool d’hôtes qui déclenchera une action de mise à l’échelle.

Puis cliquez sur Suivant :

Dans mon exemple, je n’ai pas modifié les 49% indiqués sur mon environnement avec un minimum 1 et maximum de 2 machines virtuelles. Cela force AVD a :

  • Si le nombre d’utilisateurs AVD reste sous la limite du nombres de sessions par VM :
    • Conserver une seule machine virtuelle créée et allumée
  • Si le nombre d’utilisateurs AVD dépasse la limite du nombres de sessions par VM :
    • Créer et allumer la seconde machine virtuelle

Période de pointe : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de connexion stable. Il n’est possible que de modifier :

  • Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
  • Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.

Puis cliquez sur Suivant :

Descente en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se déconnecter et à terminer leurs sessions pour la journée de travail. Il vous est possible de modifier les champs suivant :

  • Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
  • Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
  • Seuil de capacité : pourcentage de la capacité disponible du pool d’hôtes qui déclenchera une action de mise à l’échelle.
  • Forcer la déconnexion des utilisateurs : Oui / non
  • Pourcentage minimum d’hôtes actifs : exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée :
  • Limite du nombre de machines virtuelles actives : exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée.
  • Nombre min de VMs : nombre de machines virtuelles hôtes de session devant toujours faire partie du pool d’hôtes. Ces dernières peuvent être active ou à l’arrêt niveau OS.
  • Nombre max de VMs : nombre de machines virtuelles hôtes de session que le plan de mise à l’échelle dynamique ne dépassera pas. Ces dernières peuvent être active ou à l’arrêt niveau OS.

Puis cliquez sur Suivant :

Hors-période : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de déconnexion stable. Il n’est possible que de modifier :

  • Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
  • Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.

Puis cliquez sur Ajouter :

Il est possible d’ajouter une second planning si besoin, mais uniquement sur les autres jours restants, sinon cliquez sur Suivant :

Sélectionnez le pool d’hôtes concerné et lancez la validation Azure :

Une fois la validation Azure réussie, lancez la Création :

Consultez le plan de mise à l’échelle dynamique :

Avant l’application du plan de mise à l’échelle dynamique, je retrouve bien 3 en nombre de machines virtuelles AVD :

Etape III – Test de suppression de VM :

Après l’application du plan de mise à l’échelle dynamique, je retrouve bien une seule machine virtuelle AVD :

Seule une machine virtuelle est bien encore présente dans mon environnement Azure :

Grâce à Azure Monitor, il est possible de consulter les actions faites par le plan de mise l’échelle dynamique :

Du côté des insights AVD, un nouvel onglet dédié au plan de mise à l’échelle a fait son apparition :

Etape IV – Test de création de VM :

Afin de vérifier la création automatique des machines virtuelles AVD, je décide de connecter un utilisateur à mon environnement afin de dépasser le seuil de capacité :

L’utilisateur est bien référencé comme connecté :

Un nouvel événement est alors visible dans la table et indiquant la création d’une seconde machine virtuelle :

Ce même événement est également visible depuis les insights AVD avec son explication textuelle :

Dans la liste des machines virtuelles de mon environnement, je retrouve bien la seconde VM en cours de création :

Azure Virtual Desktop met à jour au besoin les agents AVD sur la nouvelle machine rajoutée au pool d’hôtes :

La nouvelle machine virtuelle contient bien la dernière version disponible et son nom confirme la bonne jointure au domaine AD :

La nouvelle machine virtuelle devient alors disponible et prête à recevoir des utilisateurs AVD :

Etape V – Second test de création de VM :

Toujours dans la même phase je décide de connecter un second utilisateur AVD :

Ayant configuré un algorithme de répartition de la charge en Depth-first, le second utilisateur se retrouve sur la même machine virtuelle que le premier utilisateur :

Rien ne se passe malgré le dépassement de 50% du total car j’ai configuré un plafond de 2 machines virtuelles durant cette phase de mon plan de mise à l’échelle :

Cette analyse est confirmée ici par le 3ème événement :

Je décide néanmoins de modifier dans mon plan de mise à l’échelle dynamique les 2 valeurs suivantes :

La validation du plan de mise à l’échelle dynamique entraîne, comme attendu, la création immédiate d’une 3ème machine virtuelle AVD :

Cette analyse est confirmée par le 4ème événement :

La 3ème machine virtuelle AVD apparaît bien dans le pool d’hôtes avec un statut disponible :

Etape VI – Second test de suppression de VM :

Pour mon dernier test, je décide de déconnecter mes 2 utilisateurs de test AVD :

Les sessions Azure Virtual Desktop ouvertes disparaissent bien de la console Azure :

Et il ne reste plus aucune machine virtuelle Azure :

Cette analyse est confirmée par le 5ème événement :

A noter qu’un minimum de 0 sessions actives entraîne le message d’erreur suivant pour l’utilisateur :

Conclusion

En conclusion, nous avons découvert que ce plan permet une gestion flexible et efficace des ressources, assurant ainsi une optimisation des coûts et une disponibilité continue des services.

L’activation automatique d’une machine virtuelle supplémentaire en réponse à une demande accrue, ainsi que la réduction rapide du nombre de machines en cas de baisse d’activité, illustrent la capacité de ce service à s’ajuster en temps réel aux besoins des utilisateurs.

En somme, Azure Virtual Desktop, grâce à son plan de mise à l’échelle dynamique, propose une solution robuste pour la gestion des environnements de travail virtuels.

Microsoft Ignite 2024

La semaine dernière, j’ai eu l’incroyable opportunité de participer à l’événement Ignite 2024 organisé par Microsoft, et organisé cette année à Chicago. Cela fut pour moi une expérience très enrichissante et passionnante, tant par le contenu que par les rencontres. Je suis ravi de partager avec vous quelques moments forts de ce voyage et certaines de mes impressions.

Avant tout, je tiens à remercier TD SYNNEX pour m’avoir donné l’expérience unique qu’est le Microsoft Ignite. Cet événement fut l’occasion pour moi de rencontrer mes collègues venus de différents pays d’Europe, d’EMEA et Worldwide :

Mais ce fut également l’opportunité pour TD SYNNEX de montrer comment devenir le partenaire du futur avec le programme de partenariat Microsoft AI Cloud :

Mon arrivée à Chicago

Je suis donc arrivé (un poil fatigué) à Chicago lundi vers midi via un vol direct depuis Zurich, mais quand même après un premier voyage en train depuis Genève. Le trajet complet fut donc :

  • 3h50 pour le train
  • 10h30 pour l’avion
  • Une heure de taxi à Chicago

A notre arrivée sous une fine pluie, nous effectué le check-in dans un des nombreux hôtels référencés et recommandés par Microsoft.

Quel que soit l’hôtel choisi, nous y étions très nombreux. Pour cela, un grand nombre de navettes Microsoft étaient prévues toutes les 15 minutes environ afin de se rendre au Centre McCormick du lundi au vendredi sans encombre, ni surcoût, ni traffic.

Une fois les chambres d’hôtel récupérées, nous sommes dirigés en direction du centre McCormick afin de récupérer nos badges d’entrée pour assister aux différentes sessions prévues dès le lendemain, dont la fameuse Keynote prévue le matin à 08h pile.

L’excitation était visiblement palpable dès le week-end précédent, grâce aux nombreux participants venus du monde entier pour y découvrir les dernières innovations présentées par Microsoft.

La première journée : Rencontre avec la communauté MVP

Dès le lundi soir, j’ai eu la chance de participer à la soirée MVP Connect dans un bar réservé pour l’occasion. Ce fut une excellente occasion de rencontrer d’autres MVP, mais également certaines personnes du programme MVP très impliquées chez Microsoft, avec qui j’échange déjà régulièrement.

Au cours de cette soirée, j’ai donc pu discuter avec quelqu’un des responsables du programme MVP chez Microsoft, comme Chloe, mais également échanger des idées et des expériences amusantes lors de précédents Ignite avec d’autres MVP (merci Seyfallah, Deniz, Clément, Hakim, Michel et Jean-François) autour d’un verre et d’une « excellente » pizza 🤣🤣

Cette soirée a été très enrichissante et m’a donc permis de nouer de nouveaux contacts, tout en renforçant les liens avec la communauté MVP francophone.

La Keynote de mardi

Le mardi matin, j’ai souhaité comme beaucoup assister à la Keynote, certainement le moment le plus attendu de l’événement. En tant que MVP, nous avions des sièges qui nous étaient réservés, mais dont le nombre était restreint.

Pour cela, il fallait arriver très tôt pour être 100% sûr d’avoir une place. Je me suis donc levé après une très courte nuit vers 05h30, afin de pouvoir prendre la première navette de 06h00 pour s’y rendre dès l’ouverture du centre McCormick prévue à 06h30.

Encore une fois, l’accueil Microsoft fut excellent et la team MVP francophone était déjà regroupée 😎💪

La Keynote a abordé des sujets passionnants comme l’intelligence artificielle, les évolutions matérielles, la sécurité dans tous ses domaines chez Microsoft et bien d’autres encore.

Voici la version complète :

Les nouveautés

Comme à chaque Ignite, Microsoft publie en ligne un Book of News. Il s’agit d’un guide complet des annonces clefs faites lors de l’événement. Il sert de ressource centralisée pour accéder aux mises à jour les plus récentes et aux informations essentielles sur les sujets les plus intéressants pour les participants :

Et que ferait-on sans une vidéo spéciale de John Savill consacrée aux nouveautés Azure de ce Microsoft Ignite :

Les sessions et les rencontres

Durant l’événement, j’ai assisté à plusieurs sessions sur des sujets variés comme l’infrastructure Azure, Copilot, la sécurité, Microsoft (Loop / Pages), Copilot Studio… Malheureusement, certaines sessions étaient complètes malgré ma pré-inscription, ce qui m’a empêché d’y assister 😥.

Petit passage obligé sur le stand et la session Nerdio, dont les dernières évolutions combinant l’IA pour l’optimisation des coûts et l’automatisation de l’infrastructure AVD / Windows 365 sont vraiment bluffantes !

La communauté et les stands

J’ai également exploré les différents stands présents dans le hub, notamment ceux liés à la sécurité et à Azure Virtual Desktop. J’ai pu poser des questions et obtenir des informations sur les prochaines fonctionnalités prévues.

Toutes ces discussions ont été particulièrement enrichissantes, car elles m’ont permis de mieux comprendre les nouvelles fonctionnalités et les améliorations prévues par Microsoft.

Durant toutes les journées de l’Ignite, l’organisation Microsoft et les efforts déployés pour la communauté MVP a été au rendez-vous.

J’ai pu rencontrer des personnes très impliquées avec les MVP comme Megan, Christian ou Claus. J’ai pu échanger avec eux sur Azure Virtual Desktop ou encore Windows 365.

J’ai même pu retrouver mon nom sur le mur des MVP (avoir un prénom commençant par la lettre J facilite la prise de photo 🥳).

Windows 365 Link

L’annonce qui m’a particulièrement marqué est celle du Windows 365 Link, un dispositif permettant d’accéder aux services de Windows 365 sans avoir besoin d’un ordinateur physique.

Ce petit boîtier, qui sera commercialisé vers avril l’année prochaine. Il semble très prometteur et pourrait devenir une alternative au Thin Client :

Important : Selon la FAQ actuellement en vigueur, Windows 365 Link ne serait pas possible pour dans le cadre d’un environnement Azure Virtual Desktop 🫥

Aucune nouvelle de vient pour l’instant changer ou contredire cette information…

Azure Virtual Desktop

L’un des points forts de Microsoft Ignite 2024 a été la présentation des nouvelles fonctionnalités d’Azure Virtual Desktop et de Windows 365. Azure Virtual Desktop a introduit

  • Une gestion améliorée des pools d’hôtes, permettant aux administrateurs de déployer et d’optimiser les hôtes de session de manière plus efficace. (article du blog)
  • L’utilisation de disques éphémères, pour plus de performances et des coûts réduits. (article du blog)
  • Une gestion de mise à l’échelle encore plus aboutie avec la création et la suppression de VMs AVD. (article du blog en préparation)

Toutes ces nouvelles fonctionnalités améliorent l’optimisation et donc les coûts d’Azure Virtual Desktop.

Azure Local

Le Cloud hybride fait également partie des grandes annonces de Microsoft.

Azure Local est une nouvelle solution qui prend la place d’Azure Stack HCI et permettra aux entreprises de déployer des services cloud Azure sur des sites physiques pour diverses raisons, qu’il s’agisse d’exigences pour conserver les données localement, de besoins de sécurité renforcés ou de conformité.

Voici une excellente vidéo en français qui en parle :

Et voici une liste non exhaustive des fonctionnalités présentées dans le cadre de la nouvelle offre Azure Local de Microsoft. A ce jour, beaucoup de ces fonctionnalités sont en toujours en préversion.

Migration depuis VMware (Préversion)

Ce sujet est d’importance, surtout en ce moment, et Microsoft ne le sait que très bien : la migration depuis VMware est déjà en préversion depuis le 1er octobre 2024. Pour l’avoir testé, l’outil et le processus de migration ne sont pas encore facile (article du blog), mais cela va bientôt venir :

Le nouvel outil Azure Migrate inclut donc un processus de migration depuis VMware. Il copie et converti les VMDK en machines virtuelles Azure Local.

Cette nouvelle fonctionnalité d’Azure Migrate permet donc aux organisations de transférer leurs charges de travail sur site vers une infrastructure Azure Local tout en minimisant les interruptions.

Options matérielles à plus faibles spécifications

Azure Local ne nécessite plus de matériel astronomique. Ils prennent en charge des options matérielles comme le micro, la tour et le matériel robuste pour répondre aux besoins des environnements de périphérie avec une configuration réseau simple.

Opérations déconnectées (Préversion)

Azure Local propose des opérations déconnectées qui permettent de gérer toute la pile localement. Avec cette option, vous avez la même API pour interagir et vous n’avez pas besoin de connecter la pile à Azure.

Groupes de sécurité réseau (Préversion)

Vous avez maintenant la possibilité d’utiliser des groupes de sécurité réseau pour filtrer le trafic. Avec cette option, vous pouvez contrôler le trafic réseau de manière granulaire. Cela aidera les clients d’Azure Local à améliorer la sécurité dans leurs environnements.

Trusted Launch (Préversion)

La fonctionnalité Trusted Launch protège contre des menaces comme les rootkits, les boot kits et autres malwares. Elle utilise des technologies comme Secure Boot et vTPM (virtual Trusted Platform Module), ainsi que des technologies de chiffrement comme BitLocker.

Avec Trusted Launch, les machines virtuelles Azure Local bénéficient d’une protection renforcée contre les rootkits et les boot kits. Des fonctionnalités comme Secure Boot, vTPM et l’intégration de BitLocker assurent une sécurité robuste.

Azure Local applique certains paramètres de sécurité par défaut et utilise les technologies Secured Core Server pour ce faire.

Chalet Azure Romandie

C’est pour moi LA grande nouvelle de cet Ignite 2024 😎 dont l’inspiration trouve des origines dans le Silicon Chalet (meetup Franco-Romand pour tous les passionnés de la Tech !)

Fraîchement née d’une idée partagée entre Seyfallah, Eric et moi, l’Ignite 2024 a donc marqué le lancement du Chalet Azure Romandie. Celui-ci devient un vecteur de partage d’une communauté francophone autour du Cloud Microsoft en Suisse romande, et au-delà !

Les enregistrements des 2 premières séances réalisées en live entre Genève et Chicago seront disponibles sous peu, grâce à la chaîne YouTube @MSCloudZeroTrustTV.

Stay tuned !

Clap de fin

Comme toutes les bonnes choses, le Microsoft Ignite de 2024 a une fin. En quelques mots de conclusion, ce voyage à Microsoft Ignite 2024 a été pour moi une expérience inoubliable. Malgré la fatigue du voyage et le décalage horaire (toujours pas récupéré 🤣), les interactions avec Microsoft, les partenaires, les clients et les autres MVP ont été extrêmement enrichissantes.

Pour en apprendre un peu plus, venez donc nous rejoindre au Chalet Azure Romandie ( CAR pour les intimes !)

Je tiens à remercier encore une fois TD SYNNEX, ainsi que Microsoft pour l’organisation de cet événement extraordinaire par son contenu et par sa taille. La participation à cet événement mondial renforce mon souhait de partager encore plus de mes expériences et de mes connaissances avec vous tous.

Et pour finir, on connaît maintenant le lieu et la date de la prochaine cuvée 2025 de Microsoft Ignite !

de VMware à Azure Local

La migration des machines virtuelles depuis VMware vers Azure Local via l’outil Azure Migrate a récemment été annoncée en préversion. Cette nouveauté chez Microsoft représente une avancée significative dans les migrations automatisées vers le cloud hybride. Cette nouvelle fonctionnalité d’Azure Migrate permet donc aux organisations de transférer leurs charges de travail sur site vers une infrastructure Azure Local tout en minimisant les interruptions.

Depuis quelques déjà, il existe sur le marché d’autres solutions externes qui proposent la migration de machines virtuelles hébergées sur VMware vers un cluster Azure Local :

Azure nous facilite donc la chose en l’intégrant dans Azure Migrate. En parlant d’Azure Migrate, un premier article sous forme d’exercice est disponible juste ici. Il vous permet de tester la migration de machines virtuelles Hyper-V vers Azure :

De façon générale, voici quelqu’un des principaux avantages à utiliser Azure Migrate :

  • Aucune préparation requise : La migration ne nécessite pas l’installation d’agents sur les machines virtuelles hébergés sous Hyper-V ou VMware.
  • Contrôle via le portail Azure : Les utilisateurs peuvent gérer et suivre toutes les étapes de leur migration directement depuis le portail Azure.
  • Flux de données local : Les données restent sur site pendant la migration, ce qui réduit les risques de latence.
  • Temps d’arrêt minimal : La solution permet de migrer les VMs avec un impact minimal sur les opérations en cours.

Aujourd’hui, nous sommes ravis d’annoncer l’avant-première publique de la fonctionnalité Azure Migrate permettant de migrer des machines virtuelles de VMware vers Azure Local, une amélioration significative de nos capacités de migration vers le cloud qui s’étend de manière transparente jusqu’à la périphérie, conformément à notre approche du cloud adaptatif.

Microsoft Tech Community

L’écran ci-dessous nous montre la section dédiée à la migration de ressources vers Azure Local :

Comment se passe la migration VMware -> Azure Local ?

Les grandes étapes d’une migration vers Azure Local sont très proches de celles vers Azure. Quelques étapes et composants nécessaires différent légèrement :

  • Un projet doit toujours être créé via Azure Migrate depuis le portail Azure
  • 2 appliances (VMware et Azure Local) doivent être créées et configurées
    • Une appliance virtuelle s’exécutant sur les serveurs VMware
    • Une seconde appliance virtuelle s’exécutant sur le cluster Azure Local

Voici les principales phases du processus de migration Azure Migrate :

Phase de migrationDescription
1. PréparationPréparez-vous à migrer en complétant les prérequis. Déployez et configurez votre cluster Azure Local. Créez un projet Azure Migrate et un compte de stockage Azure.
2. DécouverteCréez et configurez une appliance source Azure Migrate sur VMware pour découvrir vos serveurs.
3. RéplicationConfigurez l’appliance cible sur Azure Local et sélectionnez les VMs à répliquer.
4. Migration et vérificationMigrez les VMs vers Azure Local et vérifiez leur bon fonctionnement après la migration.

Quels sont les systèmes d’exploitation pris en charge ?

Pour que cette migration puisse fonctionner, seulement certaines versions d’OS sont actuellement prises en charge :

ComposantSystèmes d’exploitation pris en charge
Environnement VMware sourceVMware vCenter Server version 8.0
VMware vCenter Server version 7.0
VMware vCenter Server version 6.7

VMware vCenter Server version 6.5
Appliance VMware Windows Server 2022
Environnement Azure Local cibleAzure Local, version 23H2
Appliance Azure LocalWindows Server 2022
Machine virtuelle invitée (Windows)Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2008 R2*
Machine virtuelle invitée (Linux)Red Hat Linux 6.x, 7.x
Ubuntu Server et Pro. 18.x
CentOS 7.x
SUSE Linux Enterprise 12.x
Debian 9.x

Microsoft liste toutes les conditions requises pour envisager cette migration juste ici.

Puis-je créer mon projet Azure Migrate dans toutes les géographies Azure ?

Pour le moment, les métadonnées de votre projet Azure Migrate peuvent être uniquement stockées dans une des géographies Azure suivantes pour les migrations vers Azure Local :

GéographiesRégions
Asie-PacifiqueAsie Sud-Est, Asie Est
EuropeEurope Nord – Europe Ouest
États-UnisUSA Centre, USA Ouest2

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Des prérequis sont nécessaires pour réaliser cet exercice dédié à la migration d’une machine virtuelle hébergée sur VMware vers Azure Local via Azure Migrate. Pour tout cela, il nous faut :

  • Un tenant Microsoft
  • Une souscription Azure active
  • Un environnement Azure Local opérationnel
  • Un environnement VMware opérationnel

Commençons par la création du projet sur Azure Migrate, puis la configuration de l’appliance sur l’environnement VMware.

Etape I – Configuration VMware :

Pour cela, recherchez le service Azure Migrate grâce à la barre de recherche présente dans votre portail Azure :

Sélectionnez le menu suivant, puis cliquez-ici pour créer votre projet de migration :

Renseignez les différentes informations de votre projet en prenant en compte les géographies supportant ce scénario de migration, puis cliquez sur Créer :

Une fois le projet créé, cliquez-ici afin d’installer une appliance sur l’environnement VMware :

Définissez la cible de migration comme étant sur Azure Local, puis la source comme étant VMware :

Nommez votre appliance VMware, puis cliquez ici pour générer une clef d’association (entre l’appliance et votre projet d’Azure Migrate) :

Une fois la clef générée, copiez la dans votre bloc-notes :

Lancez le téléchargement de votre appliance afin de pouvoir en disposer par la suite sur votre environnement VMware :

Afin d’y accéder plus facilement sur vSphere, vous pouvez créer un compte de stockage publique :

Dans ce compte de stockage, créez un conteneur blob :

Une fois l’image de l’appliance téléchargée localement, utilisez l’outil azcopy afin de déposer votre image OVA sur votre compte de stockage blob :

Vérifiez la présence de l’image OVA sur votre compte de stockage, puis cliquez dessus :

Récupérez l’URL blob de votre image OVA accessible publiquement :

Depuis votre console vSphere, cliquez-ici pour créer une nouvelle machine virtuelle via la fonction de template OVF :

Collez l’URL de votre image OVA, puis cliquez sur Suivant :

Confirmez votre confiance en cliquant sur Oui :

Nommez votre machine virtuelle appliance, ainsi que son dossier, puis cliquez sur Suivant :

Sélectionnez la ressource de calcul VMware adéquate, cochez la case de démarrage après création, puis cliquez sur Suivant :

Vérifiez toutes les informations dont l’OS utilisé par l’appliance VMware, puis cliquez sur Suivant :

Définissez la ressource de stockage VMware adéquate, puis cliquez sur Suivant :

Choisissez le réseau virtuel VMware adéquat, puis cliquez sur Suivant :

Vérifiez toutes les informations avant la création de la machine virtuelle, puis cliquez sur Finir :

Constatez la création de 2 tâches, puis attendez quelques minutes :

  • vSphere VMware rapatrie l’image OVA,
  • vSphere créé la machine virtuelle appliance

Une fois la VM créée, installez-y les outils VMware :

Cliquez sur Mettre à jour :

Une fois la VM démarrée, ouvrez la console web de celle-ci :

Attendez la finalisation de la préparation de Windows Server :

Acceptez les Termes et conditions :

Configurez le mot de passe du compte administrateur (clavier US), puis cliquez sur Finaliser :

Connectez-vous avec le mot de passe configuré juste avant :

Attendez quelques minutes pour voir automatiquement s’ouvrir le navigateur internet :

Acceptez les Termes et conditions d’Azure Migrate :

Laissez faire la connexion entre votre appliance VMware et Azure :

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

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

Rafraîchissez la page au besoin si le système vous le demande :

Authentifiez-vous avec votre compte Azure :

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

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

Choisissez le compte Azure aux droits RBAC adéquats :

Cliquez sur Continuer pour autoriser l’authentification Azure :

Fermez la fenêtre de navigation internet :

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

Comme indiqué récupérez l’applicatif VMware Virtual Disk Developpement Kit depuis une source internet, copiez le dossier, puis cliquez sur Vérifier :

Afin que l’appliance VMware puisse découvrir les machines virtuelles en fonctionnement sur vCenter, cliquez-ici pour ajouter les informations d’identification :

Cliquez ici pour ajouter des informations sur les VMs hébergées sur VMware à analyser :

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

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

Cliquez ici pour démarrer la découverte des machines virtuelles sur VMware :

Mais, avant de retourner sur Azure, n’oubliez pas de renseigner et de valider les informations d’identification de votre cluster Azure Local :

La découverte est terminée et les résultats sont disponibles sur Azure :

Retournez sur le portail Azure afin de rafraîchir la page de votre projet Azure Migrate :

Quelques rafraîchissements plus tard, les serveurs VMware commencent à faire leur apparition :

La configuration VMware est maintenant terminée, nous allons pouvoir nous concentrer sur la seconde partie de la configuration dédiée à Azure Local.

Etape II – Configuration Azure Local :

Toujours sur votre projet Azure Migrate, cliquez alors sur le bouton Répliquer :

Renseignez les informations suivantes, puis cliquez sur Continuer :

  • Sélectionnez le type de service : Serveurs ou machines virtuelles (VM)
  • Sélectionnez la destination : Azure Local
  • Sélectionnez la source : VMware vSphere
  • Pour l’appliance Azure Migrate : l’appliance créée sur votre vCenter

Renseignez les informations de votre cluster Azure Local, puis cliquez sur Suivant :

Indiquez un nom pour l’appliance Azure Local, générez la clé, puis copiez cette dernière dans un bloc note :

Télécharger le fichier ZIP de votre appliance Azure Local :

À l’aide d’Hyper-V Manager, créez une nouvelle VM sous Windows Server 2022, avec 80 Go (min) de stockage sur disque, 16 Go (min) de mémoire et 8 processeurs virtuels sur un de vos nœuds Azure Local, puis démarrez celle-ci :

Une fois authentifié en mode administrateur sur cette appliance Azure Local, copiez et collez le fichier zip téléchargé.

En tant qu’administrateur, exécutez le script PowerShell suivant à partir des fichiers extraits pour installer l’appliance Azure Local :

Set-ExecutionPolicy -ExecutionPolicy Unrestricted
.\AzureMigrateInstaller.ps1

Choisissez l’option 4 :

Choisissez l’option 1 :

Choisissez l’option 1 :

Confirmez votre action avec Y :

Attendez quelques minutes la fin du traitement :

Confirmez votre action avec l’option A :

Confirmez votre action avec N :

Redémarrez la VM, reconnectez-vous avec le même compte administrateur, ouvrez Azure Migrate Target Appliance Configuration Manager à partir du raccourci du bureau, puis collez la clef précédemment copiée :

Attendez quelques minutes le temps de l’enrôlement de l’appliance Azure Local dans votre projet Azure Migrate, puis authentifiez-vous via Azure PowerShell :

Une fois l’appliance Azure Local enregistrée, sous Gérer les informations du cluster Azure Local, sélectionnez Ajouter des informations de cluster, puis cliquez sur Configurer :

Attendez quelques minutes la fin de la configuration :

Retournez sur le projet Azure Migrate depuis le portail Azure, puis cliquez-ici :

Constatez l’apparition l’appliance Azure Local, puis cliquez sur Suivant :

Choisissez la machine virtuelle à migrer sur votre cluster Azure Local, puis cliquez sur Suivant :

Définissez la configuration réseau et stockage de votre machine virtuelle migrée, puis cliquez sur Suivant :

Configurez le nombre de vCPU et la RAM, puis cliquez sur Suivant :

Sélectionnez les disques que vous souhaitez répliquer, puis cliquez sur Suivant :

Dans ce dernier onglet, assurez-vous que toutes les valeurs sont correctes, puis sélectionnez Répliquer :

Restez sur cette page jusqu’à la fin du processus (cela peut prendre 5 à 10 minutes). Si vous quittez cette page, les objets liés à la réplication ne seront pas entièrement créés, ce qui entraînera un échec de la réplication et, par la suite, de la migration.

Les 2 notifications Azure suivantes devraient alors s’afficher :

De retour sur votre projet Azure Migrate, vous pouvez suivre votre réplication depuis le menu suivant :

Une section dédiée à Azure Local est disponibles et affiche les réplications, les opérations et les événements, cliquez-ici pour avoir plus de détail sur la réplication en cours :

Les différentes étapes de réplication se suivent :

La progression via un pourcentage est même visible :

La phase finale de synchronisation des données arrive par la suite :

La prochaine étape consistera justement à faire la migration pour basculer notre VM vers Azure Local.

Etape III – Migration VMware -> Azure Local :

Une fois la réplication terminée, la machine virtuelle répliquée sur Azure Local est visible en cliquant ici :

Cliquez alors sur le statut de la machine virtuelle vous indiquant que la migration est prête :

Déclenchez la migration vers Azure Local en cliquant ici :

La notification Azure suivante apparaît alors :

Le travail de bascule planifiée est visible dans le menu suivant :

Les différentes étapes de migration vers Azure Local se suivent :

Rafraîchissez cette fenêtre plusieurs fois afin de constater le succès du processus :

Constatez l’apparition de la machine virtuelle migrée sur la page Azure de votre cluster Azure Local, puis cliquez dessus :

Copiez l’adresse IP privée de cette nouvelle machine virtuelle créée sous Azure Local :

Etape IV – Actions post-migration :

Dans mon scénario, j’ai utilisé une connexion Azure Virtual Desktop hébergé sur mon cluster Azure Local :

Une fois sur le réseau de votre Azure Local, ouvrez une connexion RDP vers l’adresse IP de votre machine virtuelle migrée :

Rentrez les identifiants de l’administrateur local, puis cliquez sur OK :

Constatez la bonne ouverture de session Windows sur votre machine virtuelle migrée :

Si la migration vous semble réussie, retournez sur votre projet Azure Migrate afin de déclarer la migration vers Azure Local comme étant complète :

Confirmez votre choix d’arrêt de réplication en cliquant sur Oui :

La notification Azure suivante apparaît alors :

L’action de Terminer la migration ne fera que nettoyer la réplication en supprimant le travail de suppression de l’élément protégé – cela n’affectera pas votre VM migrée.

Une fois la ressource migrée supprimée, elle est également supprimée de la vue Réplications. Vous verrez également le travail de migration de la VM disparaître de la vue Réplications :

Retournez sur la machine virtuelle sous Azure Local afin de finaliser l’intégration de cette VM dans l’hyperviseur Azure Local :

Il nous faut donc activer la gestion des invités pour la machines virtuelle migrée en y attachant l’ISO.

Pour cela, connectez-vous à un serveur Azure Local, puis exécutez la commande CLI suivante dans une fenêtre PowerShell sur la VM migrée pour laquelle l’agent invité doit être activé :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-vm-config-agent true

Affichez les informations de l’installeur de l’agent :

Installez l’ISO de l’agent invité sur la VM migrée comme suit :

$d=Get-Volume -FileSystemLabel mocguestagentprov;$p=Join-Path ($d.DriveLetter+':\') 'install.ps1';powershell $p

Activez la gestion de l’invité après que l’agent de l’invité a été installé de la manière suivante :

az stack-hci-vm update --name $vmName --resource-group $rgName --enable-agent true

Cette dernière étape n’a malheureusement pas fonctionné chez moi, comme l’indique encore le statut du management invité :

Le sujet est encore en discussion sur le forum Tech Community de Microsoft :

Nul doute que le souci va être corrigé sous peu ! Une page de résolution des problèmes a aussi été créée par Microsoft juste ici, ainsi qu’une FAQ.

Conclusion

En choisissant de migrer de VMware vers Azure Local, les entreprises s’engagent dans une transformation stratégique qui allie flexibilité et modernité.

Cette transition permet non seulement de consolider les ressources locales avec la puissance d’Azure, mais aussi de réduire les coûts opérationnels et de simplifier la gestion des infrastructures hybrides.

Promptez votre base de données SQL !

En combinant les capacités de l’IA et des bases de données SQL, vous pouvez optimiser l’utilisation des ressources informatiques et humaines. Les utilisateurs peuvent obtenir des informations pertinentes plus rapidement et plus facilement, améliorant ainsi leur expérience globale. Enfin, l’intégration de l’IA permet d’explorer de nouvelles façons d’utiliser les données pour innover et rester compétitif.

Pourquoi établir une communication DB -> IA ?

Mettre en place une connexion entre une application, une base de données et un modèle d’IA présente plusieurs avantages :

Automatisation et Efficacité

  • Automatisation des tâches répétitives : L’IA peut automatiser des requêtes complexes et des analyses de données, réduisant ainsi le temps et les efforts nécessaires pour obtenir des informations pertinentes.
  • Réponses rapides et précises : En utilisant l’IA pour interroger la base de données, vous pouvez obtenir des réponses rapides et précises à des questions spécifiques sans avoir à écrire des requêtes SQL complexes.

Amélioration de la Prise de Décision

  • Analyses avancées : L’IA peut analyser de grandes quantités de données et identifier des tendances ou des anomalies que les humains pourraient manquer.
  • Prédictions et recommandations : Les modèles d’IA peuvent fournir des prédictions basées sur les données historiques et offrir des recommandations pour des actions futures.

Accessibilité et Utilisabilité

  • Interface utilisateur simplifiée : Les utilisateurs peuvent interagir avec la base de données via des prompts en langage naturel, rendant l’accès aux données plus intuitif et accessible même pour ceux qui ne maîtrisent pas le langage de base de données.
  • Support multilingue : Azure OpenAI peut comprendre et répondre dans plusieurs langues, ce qui est utile pour les entreprises internationales.

Sécurité et Conformité

  • Contrôle d’accès : Vous pouvez définir des niveaux d’accès pour différents utilisateurs, garantissant que seules les personnes autorisées peuvent interroger certaines parties de la base de données.
  • Surveillance et audit : Les interactions avec la base de données peuvent être surveillées et auditées pour assurer la conformité avec les régulations et les politiques internes.

Flexibilité et Évolutivité

  • Scalabilité : Azure offre des solutions évolutives qui peuvent gérer des volumes de données croissants sans compromettre les performances.
  • Intégration facile : Les services Azure sont conçus pour s’intégrer facilement avec d’autres outils et plateformes, facilitant ainsi l’expansion et l’adaptation aux besoins changeants de l’entreprise.

Mais comment y parvenir ?

Bien que la mise en place de cette interface puisse sembler complexe, elle est tout à fait réalisable avec une planification adéquate et les bonnes compétences.

Si vous avez une équipe technique compétente ou si vous pouvez faire appel à des experts, cela facilitera grandement le processus.

Configuration de la Base de Données

  • Création et gestion de la base de données : Assurez-vous que votre base de données est bien structurée et optimisée pour les requêtes que vous souhaitez exécuter.
  • Sécurité et accès : Configurez les permissions et les accès pour garantir la sécurité des données.

Intégration de l’Application

  • Développement de l’application : Utilisez un langage de programmation compatible (comme Python, C#, etc.) pour développer l’application qui interagira avec la base de données et l’IA.
  • API et connecteurs : Utilisez des API et des connecteurs pour permettre à l’application de communiquer avec la base de données SQL et les services Azure.

Configuration du Modèle d’IA

  • Choix du modèle : Sélectionnez le modèle d’IA approprié sur Azure OpenAI en fonction de vos besoins (par exemple, GPT-4).
  • Entraînement et ajustement : Si nécessaire, entraînez le modèle avec des données spécifiques à votre domaine pour améliorer sa précision.

Développement de l’Interface Utilisateur

  • Interface utilisateur : Créez une interface utilisateur intuitive qui permet aux utilisateurs de saisir des prompts en langage naturel.
  • Traitement des requêtes : Développez des mécanismes pour convertir les prompts en requêtes SQL et pour afficher les résultats de manière compréhensible.

Considérations Techniques

  • Compétences requises : Vous aurez besoin de compétences en développement logiciel, en gestion de bases de données et en IA.
  • Ressources : Assurez-vous d’avoir les ressources nécessaires, y compris le temps, le budget et l’infrastructure.
  • Maintenance : Préparez-vous à effectuer une maintenance régulière pour assurer la sécurité et la performance de l’application.

Outils et Services Utiles disponibles sur Azure

  • Azure SQL Database : Pour la gestion de la base de données.
  • Azure OpenAI Service : Pour l’intégration du modèle d’IA.

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de tester la mise en place d’une application entre Azure OpenIA et une base de données Azure SQL, nous allons avoir besoin de :

Etape I – Préparation du poste local :

Installez Visual Studio Code ou un éditeur de code similaire :

Téléchargez puis installez la version 6.0 de .NET, disponible via ce lien officiel :

Téléchargez et installez SQL Server Management Studio (SSMS) depuis cette page :

Afin de publier les 2 applications sur une URL publique, téléchargez ngrok, puis inscrivez-vous chez eux avec un compte gratuit :

Sur leur site, téléchargez l’installateur de ngrok :

Copiez la commande suivante affichée sous l’installateur pour configurer votre ngrok :

Depuis le dossier de téléchargement, ouvrez une invite de commande, puis lancez celle-ci afin de préparer votre configuration ngrok :

Le poste local est maintenant correctement configuré, la prochaine étape consiste à créer une base de données SQL avec de la données fictives sur notre souscription Azure.

Etape II – Création de la base de données Azure SQL :

Pour cela, rendez-vous sur la page du portail Azure afin de rechercher le service Azure SQL Database :

Cliquez-ici pour créer votre base de données SQL :

Nommez votre base de données Azure SQL, puis cliquez-ici pour créer une serveur de base de données Azure pour héberger notre base :

Nommez votre serveur Azure SQL, choisissez sa région, puis renseignez des identifiants SQL pour simplifier notre test :

Conservez votre environnement en Développement, réduisez la redondance de votre base de données SQL, puis cliquez sur Suivant :

Conservez les caractéristiques réseaux d’origine, puis cliquez sur Suivant :

Conservez les caractéristiques de sécurités d’origine, puis cliquez sur Suivant :

Ne configurez pas de source de données particulière, puis lancez la validation Azure :

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

Attendez environ 5 minutes, puis cliquez-ici pour accéder à votre base de données Azure SQL :

Copiez les informations de connexion à votre base de données SQL, celles-ci seront nécessaire par la suite :

Retournez sur la page principale de votre base de données SQL, puis cliquez sur votre serveur Azure SQL :

Dans la section réseau, activez l’option suivante, puis rajoutez votre adresse IP publique en exception Firewall afin de pouvoir connecter votre poste à la base de données SQL, puis cliquez sur Sauvegarder :

Rendez-vous sur la page GitHub suivante afin de récupérer le script de chargement d’une base de données SQL (Northwind) en exemple, puis cliquez-ici :

Téléchargez le script de chargement en cliquant sur le bouton suivant :

Une fois le script téléchargé, ouvrez SQL Server Management Studio sur votre poste :

Renseignez les informations reprises sur votre serveur Azure SQL créé précédemment, puis cliquez sur Connecter :

Cliquez-ici pour rechercher votre script SQL téléchargé précédemment :

Choisissez le script SQL, puis cliquez sur Ouvrir :

Une fois le script affiché dans une nouvelle fenêtre, cliquez sur Exécuter pour démarrer ce dernier :

Attendez environ 30 secondes que celui-ci se termine avec le message suivant :

Contrôlez dans la base de données Azure SQL créés en premier que les différentes tables sont présentes et que des données y sont stockées :

Nos données sont maintenant stockées dans notre base Azure SQL. Nous pouvoir maintenant mettre en place notre LLM grâce au service Azure OpenAI.

Etape III – Création du modèle Azure OpenAI :

Pour cela, retournez sur la page du portail Azure afin de rechercher le service Azure OpenAI :

Cliquez-ici pour créer votre service Azure Open AI ;

Renseignez les informations de base de ce dernier, puis cliquez sur Suivant :

Conservez les caractéristiques réseaux d’origine, puis cliquez sur Suivant :

Ajoutez au besoin des étiquettes, puis cliquez sur Suivant :

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

Attendez environ 1 minutes puis cliquez-ici pour accéder à votre service Azure OpenAI :

Copiez les 2 informations suivantes pour ouvrir un accès auprès de votre service Azure OpenAI :

Cliquez-ici pour ouvrir le portail Azure OpenAI Studio :

Cliquez-ici pour déployer un nouveau model :

Choisissez le type gpt-4, puis cliquez sur Confirmer :

Nommez votre déploiement, définissez une limite de tokens par minute qui convient, puis cliquez sur Déployer :

Attendez environ 1 minute le temps de déploiement de votre modèle :

L’infrastructure sur Azure est maintenant en place. Il nous nous reste qu’à configurer les applications web sur notre poste afin que celle-ci travaille avec le schéma de votre base de données et votre modèle AI.

Commençons par la version 1 proposée par Alex Wolf.

Etape IV – Configuration de l’application v1 :

Voici un lien vers son excellente vidéo présentant l’application v1, sa configuration, son code ainsi qu’une comparaison intéressante faite avec les services Search basés sur l’IA :

Rendez-vous sur un fork de la page GitHub d’Alex Wolf afin de télécharger l’application v1 sous format ZIP :

Un fois l’archive ZIP téléchargée, décompressez celle-ci dans le dossier local de votre choix :

Ouvrez votre éditeur de code local, puis cliquez-ici pour ouvrir le dossier de l’application v1 :

Ouvrez le dossier correspondant au dossier suivant :

Dans le dossier SchemaLoader\SchemaLoader ouvrez le fichier Program.cs, puis renseignez la connexion à votre base de données Azure SQL copiée précédemment :

N’oubliez pas de de modifier le mot de passe de votre compte SQL, puis sauvegardez :

Ouvrez une première fenêtre Windows Terminal, positionnez-vous dans le dossier suivant, puis saisissez la commande ci-dessous :

dotnet build ".\SchemaLoader.csproj" -c Debug -o .\bin\Debug\net6.

Une fois la compilation terminée, démarrez votre application via la commande ci-dessous :

dotnet run

Une fois l’application démarrée, copiez le texte généré par celle-ci et contenant le schéma de votre base de données Azure SQL :

Retournez sur votre éditeur de code, puis allez dans le dossier dbchatui, ouvrez le fichier DataService.cs, renseignez à nouveau la connexion à votre base de données Azure SQL, puis sauvegardez le fichier :

Allez dans le dossier dbchatui\Pages, ouvrez le fichier Index.cshtml.cs, copiez le schéma de votre base de données Azure SQL :

Cela donne la présentation suivante :

Toujours dans le fichier Index.cshtml.cs, renseignez les 3 informations suivantes pour connecter votre application à votre modèle Azure OpenAI, puis sauvegardez :

Rouvrez la fenêtre Windows Terminal, positionnez-vous dans le dossier suivant, puis saisissez la commande ci-dessous :

dotnet build ".\YourOwnData.csproj" -c Debug -o .\bin\Debug\net6.

Une fois la compilation terminée, démarrez votre application via la commande ci-dessous :

dotnet run

Votre application v1 est maintenant démarrée. Copiez le numéro du port local ouvert pour cette application :

Ouvrez une seconde fenêtre Windows Terminal, puis saisissez la commande suivante afin d’exposer votre application locale au travers de ngrok :

Copiez l’URL publique générée par ngrok ci-dessous :

Tout l’environnement de test est maintenant en place, il nous reste qu’à tester le fonctionnement de l’application v1. Ouvrez un navigateur web, collez l’URL ngrok précédemment copiée, puis confirmez la navigation en cliquant ici :

Commencez par tester une requête SQL simple en promptant une question basique :

L’application vous retourne d’abord sa compréhension de votre demande, et la transpose en une requête SQL correspondante :

Juste en dessous est affiché les enregistrement correspondants au résultat de la requête exécutée sur votre serveur de base de données Azure SQL :

Continuez en testant des prompts incluant des filtres, des classements, … :

Continuez en testant des prompts incluant des relations de tables et des filtres basés sur un raisonnement :

Tous ces prompts nous montrent l’immense potentiel de pouvoir prompter une IA qui a une connaissance du schéma de toute la base de données source, sans pour autant avoir la données en elles-mêmes.

Etape V – Configuration de l’application v2 :

Il existe une nouvelle application toujours développée par Alex Wolf dont la vidéo est juste là :

Le principe est le même, rendez-vous sur un fork de la page GitHub d’Alex Wolf afin de télécharger l’application v2 sous format ZIP :

Un fois l’archive ZIP téléchargée, décompressez celle-ci dans le dossier local de votre choix :

Ouvrez votre éditeur de code local, cliquez-ici pour ouvrir le dossier de l’application v2, renseignez les 3 informations suivantes pour connecter votre application à votre modèle Azure OpenAI, puis sauvegardez :

Ouvrez une première fenêtre Windows Terminal, positionnez-vous dans le dossier suivant, puis saisissez la commande ci-dessous :

dotnet build ".\DBChatPro.csproj" -c Debug -o .\bin\Debug\net6.

Une fois la compilation terminée, démarrez votre application via la commande ci-dessous :

dotnet run

Votre application v2 est maintenant démarrée. Copiez le numéro du port local ouvert pour cette application :

Ouvrez une seconde fenêtre Windows Terminal, puis saisissez la commande suivante afin d’exposer votre application locale au travers de ngrok :

Copiez l’URL publique générée par ngrok ci-dessous :

Tout l’environnement de test est maintenant en place, il nous reste qu’à tester le fonctionnement de l’application v1. Ouvrez un navigateur web, collez l’URL ngrok précédemment copiée, puis confirmez la navigation en cliquant ici :

Renseignez la connexion à votre base de données Azure SQL copiée précédemment, puis cliquez-ici pour le schéma :

Cliquez sur Sauvegarder :

La connexion apparaît alors dans la liste des connexions existantes :

Retournez sur le premier onglet, puis commencez par tester une requête SQL simple en promptant une question basique :

L’application v2 vous retourne les enregistrement correspondants au résultat de la requête exécutée sur votre serveur de base de données Azure SQL :

Le second onglet affiche une requête SQL correspondante :

Le troisième onglet vous retourne la compréhension de votre demande comprise par le modèle IA :

Un historique des précédentes prompts est également disponible :

Il également possible de mettre des prompts en favoris :

Conclusion

En conclusion, l’utilisation de prompts pour interagir avec les bases de données représente une avancée importante, simplifiant l’accès aux informations et permettant une utilisation plus intuitive de SQL.

En expérimentant avec cette méthode, les utilisateurs peuvent améliorer leur efficacité et mieux exploiter leurs données.

Avec l’évolution rapide de ces technologies, maîtriser le langage des prompts pourrait devenir une compétence clé pour les professionnels de la donnée, ouvrant la voie à de nouvelles façons de gérer et analyser des volumes d’informations toujours croissants.

Orchestrez votre AVD

Avec la toute nouvelle fonctionnalité appelée Session host update d’Azure Virtual Desktop, Microsoft vient de lâcher une petite bombe dans la gestion des VMs AVD. Imaginez Azure Virtual Desktop remplaçant comme un grand des VMs obsolètes pour les remplacer par d’autres basées sur votre toute dernière image ? Vous ne rêvez pas, tout cela est maintenant disponible en préversion !

Comment faisait-on avant pour mettre à jour son AVD ?

Avant l’introduction de cette nouvelle fonctionnalité, la mise à jour des hôtes de session Azure Virtual Desktop (AVD) nécessitait une gestion manuelle plus intensive. Ce processus impliquait souvent plusieurs étapes, telles que :

  1. Planification des mises à jour : Identifier les hôtes de session nécessitant des mises à jour et planifier les fenêtres de maintenance.
  2. Exécution des mises à jour : Utiliser des scripts ou des outils pour appliquer les mises à jour sur chaque hôte de session.
  3. Vérification et validation : S’assurer que les mises à jour ont été appliquées correctement et que les hôtes de session fonctionnent comme prévu.

Ces étapes pouvaient être chronophages et nécessitaient une surveillance constante pour minimiser les interruptions de service et garantir la conformité des systèmes.

Qu’est ce que les nouvelles Mises à jour AVD ?

La nouvelle fonctionnalité simplifie ce processus en automatisant la gestion des mises à jour, réduisant ainsi la charge administrative et améliorant l’efficacité opérationnelle.

Microsoft nous décrit cette toute nouvelle fonctionnalité AVD en seulement quelques phrases :

La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session.

La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour.

Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.

Microsoft Learn

Que peut-on modifier dans une mise à jour AVD ?

Beaucoup de paramètres sont déjà modifiables d’une version à l’autre de votre environnement AVD :

  • Image de machine virtuelle
  • Taille de la machine virtuelle
  • Type de disque de machine virtuelle
  • Type de sécurité de la machine virtuelle
  • Informations d’identification de jonction de domaine Active Directory
  • Inscription à Microsoft Intune
  • Informations d’identification de l’administrateur local
  • Script PowerShell de configuration personnalisé

Quid des machines virtuelles AVD éteintes ou avec le mode de drainage ?

L’état d’alimentation et le mode de drainage existants des hôtes de session sont respectés. Vous pouvez effectuer une mise à jour sur un pool d’hôtes où tous les hôtes de session sont désalloués pour réduire les coûts.

Existe-t-il des limitations ?

Encore en préversion Microsoft nous liste les principales limitations juste ici :

  • La mise à jour de l’hôte de session est uniquement disponible dans le cloud Azure global. Il n’est pas disponible dans d’autres clouds, tels qu’Azure US Government ou Azure exploité par 21Vianet.
  • Pour les hôtes de session créés à partir d’une image partagée Azure Compute Gallery disposant d’un plan d’achat, le plan n’est pas conservé lorsque les hôtes de session sont mis à jour. Pour vérifier si l’image que vous utilisez pour vos hôtes de session dispose d’un plan d’achat, vous pouvez utiliser Azure PowerShell ou Azure CLI.
  • La taille du disque du système d’exploitation ne peut pas être modifiée pendant une mise à jour. Le service de mise à jour utilise par défaut la même taille que celle définie par l’image de la galerie.
  • Lors d’une mise à jour, vous ne pouvez pas ajouter d’autres hôtes de session au pool d’hôtes.
  • Si une mise à jour échoue, le pool d’hôtes ne peut pas être supprimé tant que la mise à jour n’est pas annulée.
  • Si vous décidez de créer une image extraite d’un hôte de session existant que vous utilisez ensuite comme image source pour la mise à jour de votre hôte de session, vous devez supprimer le dossier C:\packages\plugin avant de créer l’image. Dans le cas contraire, ce dossier empêche l’exécution de l’extension DSC qui joint les machines virtuelles mises à jour au pool d’hôtes.
  • Si vous utilisez Azure Virtual Desktop Insights, l’agent Azure Monitor ou l’agent Log Analytics n’est pas automatiquement installé sur les hôtes de session mis à jour. Pour installer l’agent automatiquement, voici quelques options :
  • Évitez de modifier une configuration d’hôte de session dans un pool d’hôtes sans hôtes de session en même temps qu’un hôte de session est créé, car cela peut entraîner un pool d’hôtes avec des propriétés d’hôte de session incohérentes.

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de mise à jour de l’hôte de session pour Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire d’effectuer une demande à Microsoft via le formulaire suivant, dont le point le plus important à retenir est :

Please note, the session hosts and host pools in this preview cannot be used for any type of production workload.

Autrement dit : pas de tests sur un environnement de production 😎

Etape I – Préparation du domaine AD :

Avant tout, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création par la barre de recherche :

Nommez celui-ci, puis cliquez sur Suivant :

Considérer au besoin les différents services de sécurité, puis cliquez sur Suivant :

Validez le plan d’adressage réseau et sous-réseau, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Une fois le réseau virtuel déployé, recherchez le service Microsoft Entra Domain Services depuis la barre de recherche Azure :

Cliquez-ici pour créer ce service d’AD managé sur votre tenant :

Renseignez ses informations de base dont son nom et le SKU de type Standard, puis cliquez sur Suivant :

Validez les propriétés réseaux, puis cliquez sur Suivant :

Adaptez au besoin les membres du groupe d’administrateurs créé par défaut à votre domaine managé, puis cliquez sur Suivant :

Définissez le périmètre de synchronisation, puis cliquez sur Suivant :

Parcourez les options liées à la sécurité de votre domaine managé, puis lancez la validation Azure :

Cliquez sur Créer pour lancez sa création :

Lisez l’avertissement sur le blocage de modifications après sa création, puis cliquez sur OK :

Attendez environ 30 minutes la première phase de déploiement des ressources Azure :

Environ 30 minutes plus tard, cliquez-ici pour parcourir les ressources Azure liées à votre domaine managé :

Comme vous le constatez, une phase de post-déploiement prend le relai pendant encore 25 minutes environ :

Approximativement 25 minutes plus tard, la phase de post déploiement est maintenant terminée. Cliquez-sur le message ci-dessous pour corriger le problème lié aux enregistrements DNS de votre réseau virtuel :

Lancez-le diagnostique en cliquant sur Lancer :

Corrigez l’adressage DNS de votre réseau virtuel en cliquant sur Réparer :

Confirmez votre choix en cliquant à nouveau sur Réparer :

Vérifiez la disparition de la notification d’alerte sur votre domaine managé :

Retournez sur le réseau virtuel afin de vérifiez les adresses IP de votre service Entra Domain Services :

Le domaine AD managé est maintenant en place.

La nouvelle méthode de déploiement AVD exige le stockage des informations d’identification dans un Azure Key Vault. Avant de déployer notre environnement AVD de test, nous aurons donc besoin d’un coffre.

Etape II – Création du coffre Azure Key Vault :

Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Renseignez les informations de base, puis cliquez sur Suivant :

Activez les 2 options suivantes, puis lancez la validation Azure :

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

Attendez environ 2 minutes, puis cliquez-ici une fois le déploiement terminé :

Ajoutez les rôles RBAC suivants afin de pouvoir accéder à votre coffre ainsi qu’au service Azure Virtual Desktop via son application 9cdead84-a844-4324-93f2-b2e6bb768d07 :

Ajoutez également le rôle RBAC suivant pour l’application Azure Virtual Desktop (9cdead84-a844-4324-93f2-b2e6bb768d07) afin que cette dernière puisse créer et supprimer de nouvelles machines virtuelles :

Retournez dans votre coffre, puis cliquez sur le bouton suivant pour créer les différents secrets :

Créez les 4 secrets suivants un par un :

  • Compte de domaine (sous la forme admindomain@jlou.local)
  • Mot de passe du compte de domaine
  • Compte admin local VM
  • Mot de passe du compte admin local VM

Cela donne alors la liste de secrets suivante :

Tous les prérequis au déploiement sont maintenant en place. Nous allons pouvoir déployer un nouveau type d’AVD ayant un management automatisé.

Etape III – Déploiement de l’environnement AVD :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :

Choisissez un pool d’hôtes de type partagé ainsi que le management automatisé, puis cliquez sur Suivant :

Définissez le nombre de machines virtuelles créées ainsi que la région Azure :

Choisissez l’image OS et les caractéristiques techniques de vos machines virtuelles AVD :

Spécifiez le réseau virtuel adéquat :

Reprenez les informations du Key Vault contenant les informations d’identification du compte de domaine :

Reprenez les informations du Key Vault contenant les informations d’identification du compte administrateur local, puis cliquez sur Suivant :

Définissez un nouvel espace de travail AVD, puis lancez la validation Azure :

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

Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer l’assignation des utilisateurs :

Assignez les utilisateurs de test AVD à votre groupe d’application créé :

Vérifiez le bon statut de disponibilité de vos hôtes de session créées :

Afin de s’assurer du bon fonctionnement de notre environnement AVD, connectez-vous à l’URL web d’Azure Virtual Desktop, authentifiez-vous avec un utilisateur de test, puis ouvrez une session AVD :

Cliquez sur Autoriser :

Renseignez les informations de compte de votre utilisateur AVD :

Vérifiez la bonne ouverture de session Windows :

Constatez la présence d’une session AVD ouverte sur une des VM présentes à votre pool d’hôtes :

L’environnement Azure Virtual Desktop est maintenant fonctionnel. La prochaine étape consiste à créer une mise à jour de l’image et donc de déclencher le processus de création de VM et le suppression des anciennes.

Etape IV – Déploiement d’une mise à jour AVD :

Tout commence par la création d’une nouvelle mise à jour AVD, pour cela cliquez-ici :

Définissez ici les options d’Azure Virtual Desktop sur les machines virtuelles :

  • La case à cocher détermine si AVD doit supprimer les anciennes machines virtuelles une fois ces dernières correctement substituées par de nouvelles.
  • Le pas de travail par AVD sur les machines virtuelles. Dans mon exemple :
    • AVD commencera par tester la mise à jour sur 1 seule machine virtuelle.
    • Si la mise à jour a fonctionné, AVD continuera par mettre à jour 2 VMs.
    • AVD terminera par mettre à jour les 2 dernière VMs

Définissez vos paramètres, puis cliquez sur Suivant :

Apportez les modifications de taille, d’image ou d’autres paramètres sur votre template AVD, puis cliquez sur Suivant :

Planifiez la mise à jour AVD immédiatement ou programmée par la suite, puis cliquez sur Suivant :

Personnalisez au besoin le message d’information reçu par les utilisateurs encore connectés, puis lancez la validation Azure :

Une fois la validation Azure réussie, retrouvez en gras les modifications apportées, puis lancez la mise à jour AVD :

Une fois la mise à jour enclenchée, l’écran des machines virtuelles AVD vous affiche 2 informations sur le traitement en-cours :

  • Le processus de mise à jour vient de démarrer, aucune VM n’a encore été remplacée, le pourcentage de progression est donc de 0.00 %.
  • La version actuellement en place sur les machine virtuelle AVD n’est plus la plus récente.

Après un rafraîchissement de la page, Azure Virtual Desktop commence sa mise à jour sur une première machine virtuelle AVD. Cela est visible par l’activation du mode de drainage sur une seule VM :

A ce même moment, une nouvelle machine virtuelle, dont la racine du nom reprend celle qui sera remplacée, fait son apparition et est en cours de création :

Une fois la nouvelle machine virtuelle créée, AVD nous informe que la VM déjà en place est en cours d’arrêt:

Cette information est confirmée dans la liste des machines virtuelles Azure :

Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle du pool d’hôtes AVD et du domaine Active Directory :

Juste après, Azure Virtual Desktop ajoute la nouvelle machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :

Azure Virtual Desktop met à jour au besoin les agents AVD sur la nouvelle machine rajoutée au pool d’hôtes :

La nouvelle machine virtuelle contient bien la dernière version disponible et son nom confirme la bonne jointure au domaine AD :

L’ancienne machine virtuelle est alors supprimée, comme demandé dans la configuration de la mise à jour AVD :

Le pourcentage de progression passe alors à 20.00 %, en adéquation avec le fait qu’1 machine virtuelle sur 5 est correctement mise à jour. AVD continue le traitement activant le mode de drainage sur 2 machines virtuelles :

A ce même moment, 2 nouvelles machine virtuelles, dont la racine du nom reprend celles qui seront remplacées, font leur apparition en cours de création :

Une fois les nouvelles machines virtuelles créés, AVD nous informe que les 2 VMs déjà en place sont en cours d’arrêt :

Cette information est confirmée dans la liste des machines virtuelles Azure :

Après cela, Azure Virtual Desktop retirent les 2 anciennes machines virtuelles du pool d’hôtes AVD et du domaine Active Directory :

Juste après, Azure Virtual Desktop ajoute les 2 nouvelles machines virtuelles au pool d’hôtes AVD et au domaine Active Directory :

Le pourcentage de progression passe alors à 60.00 %, en adéquation avec le fait que 3 machine virtuelle sur 5 sont correctement mises à jour. AVD continue le traitement activant le mode de drainage sur les 2 dernières machines virtuelles :

A ce même moment, 2 nouvelles VMs sont créées, l’ancienne VM sans session utilisateur est en cours d’arrêt, tandis que celle contenant une session utilisateur reste encore active :

Après cela, Azure Virtual Desktop retire l’ancienne machine virtuelle sans session du pool d’hôtes AVD, tandis que celle contenant une session utilisateur reste encore présente :

Un message d’information apparaît dans la session encore ouverte de l’utilisateur AVD :

Quelques minutes plus tard, la session AVD est terminée sans action de l’utilisateur :

Le pourcentage de progression passe alors à 80.00 %, en adéquation avec le fait qu’une seule machine virtuelle sur cinq n’est pas encore mise à jour :

Azure Virtual Desktop force la déconnexion afin de déclencher l’arrêt de la machine virtuelle AVD :

Après cela, Azure Virtual Desktop retire la dernière machine virtuelle du pool d’hôtes AVD :

Juste après, Azure Virtual Desktop ajoute la dernière machine virtuelle au pool d’hôtes AVD et au domaine Active Directory :

Toutes les anciennes machines virtuelles AVD ont bien été supprimées :

La mise à jour est maintenant terminée car toutes les machines virtuelles ont maintenant et correctement été mise à jour :

L’utilisateur déconnecté peut alors tenter une reconnexion à AVD :

L’utilisateur constate alors le passage à une nouvelle version de son OS :

AVD ouvre la nouvelle session Windows sur 1 des 5 machines virtuelles du pool d’hôtes :

Conclusion

Cette fonctionnalité vous permet de maximiser l’efficacité et la flexibilité de votre infrastructure virtuelle. Grâce à des outils avancés et des stratégies éprouvées, vous pouvez améliorer la gestion de vos ressources, réduire les coûts opérationnels et offrir une expérience utilisateur optimisée. Découvrez par vous-même comment l’orchestration de votre AVD peut transformer votre environnement de travail virtuel.

AVD : Enfin les 60 FPS !

Azure Virtual Desktop propose depuis longtemps la possibilité d’exploiter des machines virtuelles avec GPU pour des traitements graphiques plus ou moins gourmands. Mais des limitations persistaient, et notamment le nombre de FPS que l’utilisateur pouvait obtenir via sa connexion en bureau à distance. Et tout cela vient de changer avec une nouvelle préversion proposée par Microsoft !

H.265 vs H.264 ?

HEVC (High Efficiency Video Coding), également appelé H.265. Cela permet une compression de données de 25 à 50 % par rapport à AVC/H.264, pour la même qualité vidéo ou une meilleure qualité avec la même vitesse de transmission que si la vidéo était encodée avec AVC/H.264.

Microsoft Learn

L’accélération GPU dans Azure Virtual Desktop améliore l’expérience utilisateur pour trois composants :

  1. Rendu d’application accéléré par GPU : Le GPU aide à afficher des graphismes plus rapidement dans une session à distance. Par exemple, si vous utilisez une application de dessin, les images se dessineront plus vite et seront plus fluides.
  2. Encodage d’images accéléré par GPU : Le protocole RDP (Remote Desktop Protocol) encode les graphismes pour les envoyer à votre appareil. Par exemple, si une partie de l’écran change souvent, comme une vidéo, elle est encodée avec le codec AVC (H.264) pour une transmission plus efficace.
  3. Encodage de vidéos plein écran : Pour des applications exigeantes comme la modélisation 3D, le CAD/CAM, ou l’édition vidéo, un profil vidéo plein écran offre une meilleure qualité d’image et une fréquence d’images plus élevée. Cela utilise plus de bande passante et de ressources. Vous pouvez choisir d’encoder avec :
    • AVC/H.264 : Un codec standard pour la vidéo.
    • HEVC/H.265 : Un codec plus efficace qui compresse les données de 25 à 50 % mieux que l’AVC/H.264, offrant la même qualité vidéo avec moins de bande passante.
CaractéristiqueH.264 (AVC)H.265 (HEVC)
Efficacité de compressionUtilise des macroblocs (16×16 pixels)Utilise des unités de codage (CTU) jusqu’à 64×64 pixels
Taille des fichiersPlus volumineuxRéduit la taille des fichiers jusqu’à 50%
CompatibilitéLargement pris en charge par de nombreux appareils et plateformesMoins largement pris en charge, mais le support est en croissance
Puissance de traitementNécessite moins de puissance de calcul pour le codage et le décodageNécessite plus de puissance de calcul pour le codage et le décodage
Cas d’utilisationStreaming, disques Blu-ray, diffusions HDTVVidéos haute résolution (4K, 8K), scénarios avec bande passante et stockage limités
Qualité vidéoBonne qualité vidéoMeilleure qualité vidéo au même débit binaire
Bande passanteNécessite plus de bande passanteNécessite moins de bande passante
AdoptionUniversellement adoptéGagne en popularité, mais fait face à des obstacles de licence

En résumé, si vous avez besoin d’une meilleure compression et travaillez avec des vidéos haute résolution, H.265 est la meilleure option. Cependant, pour une compatibilité plus large et des exigences de traitement plus faibles, H.264 reste un choix logique.

Quelles machines virtuelles Azure sont compatibles ?

La bonne nouvelle est que si vous activez l’accélération matérielle HEVC/H.265 et AVC/H.264, mais que HEVC/H.265 n’est pas disponible sur l’appareil local, alors AVC/H.264 sera alors utilisé à la place.

Microsoft vous liste sur son site les familles de machines virtuelles Azure supportant partiellement ou totalement H.265 :

Taille de la machine virtuelle AzureAccélération GPU pour le rendu d’applicationAccélération GPU pour le codage d’imagesEncodage vidéo plein écran
Série NVv3Pris en chargeAVC/H.264HEVC/H.265
AVC/H.264
Série NVv4Pris en chargeNon disponiblePris en charge
NVadsA10 v5-seriesPris en chargeAVC/H.264HEVC/H.265
AVC/H.264
NCasT4_v3-seriesPris en chargeAVC/H.264HEVC/H.265
AVC/H.264

Contraintes importantes :

  • Contraintes AVD :
    • Compatible uniquement Windows 10 et Windows 11
    • Les machines virtuelles Azure des séries NC, NCv2, NCv3, ND et NDv2 ne sont généralement pas appropriées comme hôtes de session. Ces tailles de machine virtuelle sont adaptées aux outils de calcul ou de Machine Learning hautes performances spécialisés, comme ceux créés avec NVIDIA CUDA. Elles ne prennent pas en charge l’accélération GPU pour la plupart des applications ni pour l’interface utilisateur Windows.
    • Désactivation obligatoire de la redirection multimédia sur vos hôtes de session.
    • Groupe d’applications de bureau RemoteApp non pas pris en charge.
  • Contraintes sur le poste local :
    • GPU compatible HEVC (H.265)
    • Code Microsoft HEVC installé (inclus à partir de Windows 11 22H2)
    • Windows App, version 1.3.278.0 ou ultérieure.
    • Application Bureau à distance, version 1.2.4671.0 ou ultérieure.

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de FPS sur Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Commençons d’abord par vérifier en premier la compatibilité H.265 du poste local.

Etape I – Vérifications H.265 du poste local :

Sur votre poste, ouvrez Windows PowerShell, puis exécutez la commande suivante pour vérifier la présence du codec HEVC :

get-appxpackage *hevc*

Ouvrez maintenant au choix votre application Remote Desktop ou Windows App afin de vérifier les versions :

La configuration locale semble bonne, continuons maintenant sur Azure afin de mettre en place un environnement de test avec GPU.

Etape II – Création de l’environnement Azure Virtual Desktop :

Voici un rappel des familles de machines virtuelles dont les GPUs NVIDIA sont compatibles :

Avant de pouvoir déployer un environnement GPU pour Azure Virtual Desktop, nous avons donc besoin de disposer de quotas sur notre souscription. Pour cela, rendez-vous dans le portail Azure :

Pour mon exemple, j’ai choisi de créer mon environnement AVD sur une machine virtuelle de la familles NCasT4_v3, dont j’ai précédemment augmenté les quotas :

Une fois les quotas en place, nous avons besoin d’avoir un réseau virtuel Azure.

Nommez votre réseau virtuel, puis cliquez sur Vérifier:

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :

Configurez-le comme ceci, puis cliquez sur Suivant :

Choisissez une image OS sous Windows 11 :

Choisissez une taille de VM GPU :

Joignez votre VM à votre réseau virtuel et à Microsoft Entra ID :

Définissez un administrateur local, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

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

Une fois le déploiement d’Azure Virtual Desktop terminé, cliquez-ici :

Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Définissez sur le groupe de ressources les droits RBAC suivants pour votre utilisateur de test AVD :

Notre environnement Azure Virtual Desktop GPU est maintenant en place. La prochaine étape consiste à installer la configuration graphique de base, afin que la carte NVIDIA soit reconnue par Windows et pleinement exploitée.

Etape III – Configuration GPU de l’environnement AVD :

Important :

  • Pour les tailles des machines virtuelles avec un GPU NVIDIA, seuls les pilotes NVIDIA GRID prennent en charge l’accélération GPU pour la plupart des applications et l’interface utilisateur Windows. Les pilotes NVIDIA CUDA ne prennent pas en charge l’accélération GPU pour ces tailles de machine virtuelle. Si vous souhaitez télécharger et découvrir comment installer le pilote, consultez Installer les pilotes GPU NVIDIA sur les machines virtuelles de série N exécutant Windows et n’oubliez pas d’installer le pilote GRID. Si vous installez le pilote en utilisant l’Extension de pilote GPU NVIDIA, le pilote GRID est automatiquement installé pour ces tailles de machine virtuelle. Pour l’accélération matérielle HEVC/H.265, vous devez utiliser le pilote GPU NVIDIA GRID 16.2 (537.13) ou version ultérieure.
  • Pour les tailles des machines virtuelles avec un GPU AMD, installez les pilotes AMD fournis par Azure. Si vous souhaitez télécharger et découvrir comment installer le pilote, consultez Installer les pilotes GPU AMD sur les machines virtuelles de série N exécutant Windows.

Microsoft Learn

Ouvrez la page de votre machine virtuelle AVD de test afin de déployer le service Azure Bastion sur votre réseau virtuel :

Une fois Azure Bastion correctement déployé, ouvrez une session via ce dernier avec le compte administrateur local de la machine virtuelle :

Sur votre VM AVD, ouvrez la page suivante de la documentation Microsoft proposant l’installation de pilotes GRID :

Une fois l’installeur GRID téléchargé sur votre VM GPU, ouvrez ce dernier, puis confirmez le dossier de décompression au niveau local :

Après une rapide vérification du système, cliquez sur Accepter et Continuer :

Cliquez sur Suivant :

Attendez environ 2 minutes que l’installation se termine :

Une fois l’installation terminée avec succès, cliquez sur Fermer :

Ouvrez l’exécuteur de commande Windows pour ouvrir l’éditeur de stratégie de groupe locale :

Naviguez dans l’arborescence suivante :

  • Administrative Templates
    • Windows Components
      • Remote Desktop Services
        • Remote Desktop Session Host
          • Remote Session Environnment

Afin de profiter de la performance du GPU de notre machine virtuelle, activez les polices locales suivantes :

Afin de tester le nombre de FPS, installez FurMark 2. Pour cela, rendez-vous sur la page web suivante afin de télécharger l’installeur :

Lancez l’installation de FurMark 2, cochez la première case, puis cliquez sur Suivant :

Renseignez le répertoire d’installation, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Cliquez sur Suivant :

Cliquez sur Terminer :

La configuration GPU de base est maintenant en place. Nous allons pouvoir tester l’impact sans et avec la configuration additionnelle.

Etape IV – Test utilisateur SANS :

Si besoin, téléchargez le client Remote Desktop depuis cette page officielle Microsoft.

Ouvrez l’application avec votre utilisateur de test AVD, puis lancez l’application de bureau à distance :

Acceptez la demande d’autorisation pour autoriser les connexion RDP vers la VM GPU AVD :

Depuis le menu Démarrer, ouvrez l’application FurMark 2 :

Démarrez le test GPU :

Pendant que FurMark 2 poursuit son test, contrôlez le protocole, l’utilisation du GPU, la bande passante disponible ainsi que le nombre de FPS :

La configuration actuelle limite actuellement le nombre de FPS à 30. Testons maintenant avec la configuration additionnelle.

Etape V – Test utilisateur AVEC :

Pour s’assurer que la fonction débridant les 60 FPS est correctement activée, les clés de registre suivantes doivent être définies sur chaque VM hôte de session.

Ouvrez Windows PowerShell, puis exécutez les commandes suivantes :

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v HEVCModePreferred /t REG_DWORD /d 1

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v bEnumerateHWBeforeSW /t REG_DWORD /d 1

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations" /v DisplayRefreshRate /t REG_DWORD /d 60

Ouvrez l’observateur d’événements Windows et accédez au journal suivant :

  • Journaux des applications et services
    • Microsoft
      • Windows
        • RemoteDesktopServices-RdpCoreCDV
          • Operational

Recherchez l’ID d’événement 162. Si vous voyez Initial Profile avec la valeur 32768, Alors la connexion de bureau à distance utilise HEVC, ce qui n’est pas encore le cas ici :

Fermez la session utilisateur d’Azure Virtual Desktop :

Relancez la session de bureau à distance :

Réouvrez l’observateur d’événements Windows, puis accédez au journal suivant :

  • Journaux des applications et services
    • Microsoft
      • Windows
      • RemoteDesktopServices-RdpCoreCDV
        • Operational

Recherchez à nouveau l’ID d’événement 162. Si vous voyez Initial Profile avec la valeur 32768, Alors la connexion de bureau à distance utilise bien HEVC, ce qui maintenant le cas ici :

Rouvrez l’application FurMark 2, et recontrôlez le protocole, l’utilisation du GPU, la bande passante disponible ainsi que le nombre de FPS :

Bravo ! Le nombre de FPS a fait un sacré bon !

Conclusion

Grâce à l’accélération GPU et à l’utilisation des codecs HEVC/H.265 et AVC/H.264, les utilisateurs peuvent désormais bénéficier d’une expérience graphique fluide et de haute qualité, même pour des applications exigeantes comme la modélisation 3D ou l’édition vidéo.

Cette mise à jour d’Azure Virtual Desktop marque un tournant pour les utilisateurs nécessitant des performances graphiques élevées, tout en offrant une meilleure compression et une utilisation plus efficace de la bande passante 😎💪

💪Bastion Premium 💪

Comme tous les services Cloud, Azure Bastion continue d’évoluer et s’améliorer via l’ajout de nouvelles fonctionnalités très pratiques. Au travers de cet article, nous prendrons le temps de refaire un tour du service et de ses changements dans sa gamme et ses fonctionnalités, comme l’enregistrement automatique ou l’accès 100% privé.

Cet article n’est pas le premier à parler d’Azure Bastion sur ce blog, voici un lien vers celui écrit en 2023. Depuis cette date, le produit a subi quelques changements que nous aborderons ici.

Qu’est-ce qu’Azure Bastion ?

Côté Microsoft, le but de ce service de jump n’est pas changé :

Azure Bastion est un service PaaS entièrement managé que vous approvisionnez pour vous connecter en toute sécurité aux machines virtuelles via une adresse IP privée. Il fournit une connectivité RDP/SSH sécurisée et fluide à vos machines virtuelles, directement au travers du protocole TLS depuis le Portail Azure ou via un SSH natif ou un client RDP déjà installé sur votre ordinateur local. Quand vous vous connectez via Azure Bastion, vos machines virtuelles n’ont pas besoin d’adresse IP publique, d’agent ou de logiciel client spécial.

Microsoft Learn

Azure Bastion est donc toujours un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient sous Windows ou Linux.

Le schéma ci-dessous nous montre le tunnel d’accès créé entre Azure Bastion et l’utilisateur initiateur (via une connexion inversée) grâce au protocole TLS :

Bastion fournit une connectivité RDP et SSH sécurisée à toutes les machines virtuelles du réseau virtuel pour lequel il est approvisionné. Azure Bastion protège vos machines virtuelles contre l’exposition des ports RDP/SSH au monde extérieur, tout en fournissant un accès sécurisé à l’aide de RDP/SSH.

Microsoft Learn

J’ai également reposté la vidéo dédiée à Azure Bastion en français juste ici :

Quel est le principal point fort d’Azure Bastion ?

Un seul mot me vient tout de suite en tête : SECURITE.

Comme tout service de jump, Azure Bastion devient de facto la ressource exposée de votre infrastructure Cloud. Dans les faits, ce dernier intègre des fonctions de pare-feu et des mesures périmétriques de sécurité.

De plus, l’accès au service depuis le portail Azure apporte la couche de pré-authentification d’Azure AD. Celui-ci profite alors de toutes ses mesures de sécurité, comme l’Accès conditionnel, la gestion des droits RBAC, etc …

L’approche d’une connexion sécurisée via TLS permet de s’affranchir de règles sécurités lourdes.

Enfin, Azure Bastion mettra tout le monde d’accord grâce au retrait des adresses IP publiques sur vos VMs Azure, car la connexion RDP/SSH entre Bastion et votre machine virtuelle se fera via le réseau virtuel privé Azure, donc grâce et uniquement par son adresse IP privée.

Pour y voir plus clair, Microsoft met à disposition un tableau de ses principaux avantages :

AvantageDescription
RDP et SSH par le biais du portail AzureVous pouvez accéder directement à la session RDP et SSH directement dans le portail Azure via une expérience fluide en un seul clic.
Session à distance sur TLS et traversée de pare-feu pour RDP/SSHAzure Bastion utilise un client web basé sur HTML5 qui est automatiquement diffusé sur votre appareil local. Votre session RDP/SSH utilise TLS sur le port 443. Le trafic peut ainsi traverser les pare-feu de façon plus sécurisée. Bastion prend en charge TLS 1.2. Les versions antérieures de TLS ne sont pas prises en charge.
Aucune adresse IP publique n’est nécessaire sur la machine virtuelle Azure.Azure Bastion ouvre la connexion RDP/SSH à votre machine virtuelle Azure en utilisant l’adresse IP privée sur votre machine virtuelle. Vous n’avez pas besoin d’une adresse IP publique sur votre machine virtuelle.
Aucune contrainte liée à la gestion des groupes de sécurité réseau (NSG)Vous n’avez pas besoin d’appliquer des groupes de sécurité réseau sur le sous-réseau Azure Bastion. Comme Azure Bastion se connecte à vos machines virtuelles par le biais d’une adresse IP privée, vous pouvez configurer vos groupes de sécurité réseau pour autoriser RDP/SSH depuis Azure Bastion uniquement. Vous n’avez plus à gérer les groupes de sécurité réseau chaque fois que vous devez vous connecter de manière sécurisée à vos machines virtuelles. Pour plus d’informations sur les groupes de sécurité réseau, consultez Groupes de sécurité réseau.
Vous n’avez pas besoin de gérer un hôte Bastion distinct sur une machine virtuelleAzure Bastion est un service PaaS de plateforme entièrement géré d’Azure, renforcé en interne pour vous fournir une connectivité RDP/SSH sécurisée.
Protection contre l’analyse des portsVos machines virtuelles sont protégées contre l’analyse des ports par des utilisateurs malveillants, car vous n’avez pas besoin de les exposer à Internet.
Renforcement de la sécurité à un seul endroitAzure Bastion résidant au périmètre de votre réseau virtuel, vous n’avez pas à vous soucier du durcissement de la sécurité de chacune des machines virtuelles de votre réseau virtuel.
Protection contre les exploits zéro-dayLa plateforme Azure protège contre les exploits du jour zéro en assurant une sécurité durcie permanente et à jour pour Azure Bastion.

Mais combien coûte Azure Bastion ?

C’est à partir d’ici que les choses ont changé depuis mon dernier article. Il existe maintenant 4 SKUs disponibles pour Azure Bastion :

  • Développeur
  • Basic
  • Standard
  • Premium

Côté tarif, Microsoft met à disposition une table des tarif d’Azure Bastion sur cette page :

Pour bien se rendre compte des écarts de prix, cela donne les tarifs mensuels suivants :

Comme indiqué au-dessus, Azure Bastion en version Développeur est gratuit, mais votre accès unique repose alors sur une instance partagée d’Azure Bastion :

Pour les autres SKUs, Microsoft le dit et je vous le confirme : Azure Bastion est facturé dès que ce dernier est déployé peu importe son utilisation :

Azure Bastion est facturée toutes les heures à partir du moment où la ressource est déployée jusqu’à sa suppression, quelle que soit l’utilisation des données sortantes. La tarification horaire est basée sur la référence SKU sélectionnée, le nombre d’unités d’échelle configurées et les taux de transfert de données.

Tarification Microsoft

Quel SKU choisir pour Azure Bastion ?

Les fonctionnalités détermineront le SKU le plus adapté à votre besoin :

FonctionnalitéRéférence SKU DéveloppeurRéférence De baseRéférence StandardSKU Premium
Se connecter pour cibler les machines virtuelles dans les mêmes réseaux virtuelsOuiOuiOuiOui
Se connecter pour cibler les machines virtuelles dans les réseaux virtuels appairésNonOuiOuiOui
Prise en charge de connexions simultanéesNonOuiOuiOui
Accéder aux clés privées des machines virtuelles Linux dans Azure Key Vault (AKV)NonOuiOuiOui
Se connecter à une machine virtuelle Linux avec SSHOuiOuiOuiOui
Se connecter à une machine virtuelle Windows avec RDPOuiOuiOuiOui
Se connecter à une machine virtuelle Linux avec RDPNoNonOuiOui
Se connecter à une machine virtuelle Windows avec SSHNoNonOuiOui
Spécifier le port d’entrée personnaliséNoNonOuiOui
Se connecter à des machines virtuelles à l’aide de Azure CLINoNonOuiOui
Mise à l’échelle de l’hôteNoNonOuiOui
Charger ou télécharger des fichiersNoNonOuiOui
Authentification KerberosNonOuiOuiOui
Lien partageableNoNonOuiOui
Se connecter aux machines virtuelles via une adresse IPNoNonOuiOui

Note : Gardez en tête que pour vous pouvez monter en gamme le SKU de votre Azure Bastion, mais descendre vous sera impossible.

Comment mettre en place Azure Bastion ?

Rien de plus simple, quelques clics suffisent pour déployer Azure Bastion.

Dans cet article, nous allons déployer Azure Bastion, puis tester quelques fonctionnalités des 4 SKUs d’Azure Bastion. Bref, ne perdons pas de temps :

Etape 0 – Rappel des prérequis :

Pour réaliser ce nouvel exercice sur Azure Bastion, dont certaines fonctionnalités sont encore en préversion, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Mon environnement Azure de départ contient déjà 3 machines virtuelles :

Ces 3 machines virtuelles sont réparties sur 2 réseaux virtuels déployés dans 2 régions Azure :

Un appairage entre ces 2 réseaux virtuels est déjà en place :

Pour information, un déploiement rapide d’Azure Bastion est possible depuis une machine virtuelle :

Une autre méthode de déploiement rapide d’Azure Bastion est également disponible depuis un réseau virtuel :

Dans notre cas, nous allons personnaliser le déploiement d’Azure Bastion afin de pouvoir sélectionner le SKU Développeur.

Etape I – Déploiement d’Azure Bastion Développeur :

Comme indiqué en introduction, ce SKU gratuit fonctionne via une ressource Azure Bastion partagée et sécurisée :

L’intérêt principal d’utiliser ce SKU d’Azure Bastion est évidemment son prix, si aucune de ses limitations n’est bloquante pour vous :

  • Connexion impossible sur les réseaux virtuels appairée
  • Connexions simultanées impossibles
  • Authentification Kerberos impossible

Si cela vous convient, recherchez le service Bastion dans la barre de recherche du portail Azure :

Cliquez-ici pour créer votre Azure Bastion :

Renseignez les champs suivants :

Sélectionnez le SKU Développeur :

Constatez la liste réduite des régions Azure disponibles pour ce SKU :

Choisissez votre réseau virtuel déjà en place, puis cliquez sur Suivant :

Constatez que toutes les fonctionnalités annexes sont indisponibles avec ce SKU, puis lancez la validation Azure :

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