Beaucoup d’articles sur ce blog parlent déjà d’Azure Virtual Desktop ????. Au fil des mois, nous avons constaté ses améliorations, la simplification du déploiement, l’augmentation de sa sécurité, de ses performances ou encore une meilleure compatibilité. Un point important n’a pas encore été abordé : l’optimisation des coûts sur AVD.

D’ailleurs, plusieurs articles parlant des coûts sur Azure sont déjà disponibles sur ce blog :

• Comprenez les coûts d’une ressource Azure
• Optimisez votre Azure : 1/4 – Les Coûts

C’est un premier pas vers la compréhension de la facturation de Microsoft selon vos usages. Ce modèle de facturation, basé sur la consommation est la norme pour les principaux fournisseurs de Cloud.

Quels sont les principaux coûts d’Azure Virtual Desktop ?

Avant de parler d’optimisations sur les coûts, il est nécessaire de lister les principales charges d’une architecture Azure Virtual Desktop. Certains coûts sont systématiques, tandis que d’autres sont optionnels :

• Gestion des identités : Azure Virtual Desktop repose sur une gestion des utilisateurs, de même que pour l’OS, les fichiers ou encore certaines applications. Plusieurs options sont disponibles : Azure AD, Active Directory ou le service managé Azure AD DS.
• Machine virtuelle : Que l’environnement AVD soit composé pour des machines individuelles ou partagées, elles représentent toujours un coût important dans l’infrastructure AVD.
• Stockage : Plusieurs types de stockage sont nécessaires dans une architecture AVD. Un premier stockage est déjà présent sur chaque machine virtuelle pour stocker l’OS, les applications, … Un second est créé pour stocker les données et les informations de session des utilisateurs AVD.
• Licence : Que l’environnement AVD fonctionne sur Windows 10/11 ou Windows Server, des licences Microsoft sont nécessaires. Le choix de l’OS pour AVD repose sur les besoins applicatifs ou la méthode de gestion du parc souhaitée.
• Réseau : Toute donnée sortante du Cloud Microsoft est facturée. Chaque utilisateur d’AVD génère un petit coût lorsqu’il ouvre et utilise sa session de bureau à distance. Cette somme varie selon le volume de Gio envoyés en dehors du Cloud, en sachant que le protocole RDP n’est pas réputé comme gourmand en traffic.
• Gestion de la sécurité : Toute infrastructure IT a besoin de mesures de protection. Ces coûts ne sont pas obligatoirement liés à Microsoft, mais ils doivent être pris en compte dans l’enveloppe finale.
• Sauvegarde : La sauvegarde de certaines données est indispensable pour se prémunir d’un accident ou d’une fraude. Le volume de donnée à sauvegarder, la fréquence ou la redondance de la sauvegarde influent sur son prix.
• Plan de reprise d’activité : Le PRA n’est pas un système de sauvegarde au premier sens du terme. Il n’est pas non plus obligatoire. Mais il doit être perçu comme un point majeur dans la protection de services critiques, afin qu’ils continuent à fonctionner. Sur Azure, un doublement de certaines ressources AVD est envisageable dans une seconde région du Cloud.

Et le coût d’un AVD dans tout ça ?

Il n’existe pas de prix fixe pour Azure Virtual Desktop. La liste des éléments précédemment listés vous montre les principaux axes de coûts, mais le choix de chaque composant dépend du projet AVD.

Il existe un objet Azure Virtual Desktop dans le Calculateur de prix Azure, mais je trouve que celui-ci passe très vite sur certains points et oublie d’en mentionner d’autres.

Alors, comment procède-t-on pour estimer le prix d’un projet AVD ?

Aucune baguette magique n’existe ! Comme pour toute infrastructure IT, il est conseillé de récolter quelques métriques sur les besoins utilisateurs pour commencer à composer. Voici quelques exemples de questions qui me paraissent essentielles pour démarrer un projet AVD :

• Nombre d’utilisateurs totaux
• Nombre d’utilisateurs simultanés
• Horaires de travail
• Nature des besoins (Répartition des utilisateurs selon des types de population)
• Exigences OS de l’équipe IT / des applications
• Ont-ils déjà des licences 365 en place ?
• Préférence géographique sur Azure ?
• Volonté d’engagement dans la durée ?
• Perspective de croissance des besoins AVD
• Ressources IT locales à interconnecter

Ces données sont utiles pour estimer les principaux coûts listés précédemment.

Et si l’on ne souhaite pas réaliser tous ces calculs ?

Azure facture sur la consommation mensuellement. Le but sur Azure n’est pas de produire un coût fixe mensuel. Si cela n’est pas votre souhait, Microsoft a aussi pensé à vous et propose également une solution clef en main, appelé Windows 365 au tarif mensuel fixe.

Windows 365 est proche d’un système de licence comme pour Office 365, pour le provisionnement d’un PC Cloud. La puissance de ce PC dépend du prix de la licence Windows 365 choisie. Un premier article sous la solution est disponible juste ici

Bien que basé sur la même technologie, Windows 365 est un service hautement managé. Cela réduit donc la configuration possible sur certaines fonctionnalités, comme le montre ce tableau ci-dessous :

Êtes-vous êtes toujours là ? ????

Je vous propose de reprendre les 6 principaux coûts Azure Virtual Desktop et d’envisager des économies possibles.

Coût I – Gestion des identités :

Azure Virtual Desktop fonctionne avec les 3 systèmes de gestion identitaire suivants :

• Azure AD
• Azure AD Domain Services
• Active Directory classique

Il ne s’agit pas de solutions 100% équivalentes en termes de fonctionnalités, chacune apporte une plus-value selon le scénario AVD souhaité.

Quelles sont les économies possibles ?

L’économie consiste à prendre la bonne gestion identitaire à votre projet. Voici un classement croissant par ordre de prix et des usages les plus courants :

• Azure AD : Azure AD de base est gratuit ! Évidemment, certaines fonctionnalités sont bridées, mais cela allège déjà un peu la facture. La gestion identitaire par Azure AD est conseillé pour les petits environnements ne disposant pas d’infrastructure IT on-premise.
• Azure AD DS : Solution intermédiaire en termes de coûts, de fonctionnalités et de management. Il s’agit d’un domaine géré par Microsoft et donc partiellement restreint. Azure AD DS est lui aussi conseillé pour les petits environnements ne disposant pas d’infrastructure IT on-premise.
• Active Directory : idéalement utilisé si l’on souhaite avoir la main complète sur les paramétrages du domaine AD, ou si un domaine AD existe déjà en on-premise. Il est alors possible d’étendre l’AD local à Azure via une liaison Azure VPN et une machine ayant le rôle d’AD dans Azure.

Coût II – Machine virtuelle :

Comme annoncé plus haut, les machines virtuelles représentent une part importante du coût total de l’architecture Azure Virtual Desktop. Bien souvent, il est difficile d’estimer au mieux le nombre et la puissance des machines virtuelles AVD. Les métriques de l’environnement actuel, un cahier des charges précis et des phases de POC sont de vrais facilitateurs.

De mon côté, j’essaie d’imaginer, selon mes expériences antérieures, les possibilités de machines virtuelles AVD adaptées aux besoins des utilisateurs. Je compile alors le tout dans un tableau Excel : le nombre d’utilisateurs par population et différents scénarios où les ressources allouées varient :

Quelles sont les économies possibles ?

Trois économies sont possibles sur les coûts des machines virtuelles AVD :

• Adaptez la puissance de vos machines virtuelles : cela risque de ne pas plaire aux utilisateurs AVD, ou pas. Des machines correctement dimensionnées selon les usages diminuent fortement les coûts. Il est important d’analyser le nombre d’utilisateurs maximal que la machine supporte sans que l’expérience utilisateur ne soit dégradée.
• Réservez vos machines virtuelles pendant 1 ou 3 ans : Deux méthodes de facturations sont disponibles sur Azure. Prendre un engagement sur une machine virtuelle est une méthode pratique pour diminuer les coûts quand l’utilisation de la ressource est en 24/7.
• Privilégiez Windows 10/11 quand cela est possible : Une licence Windows Server + CAL RDS coûtent toujours plus cher que des licences ayant des droits d’accès utilisateur, comme Microsoft 365 Business Premium ou Microsoft E3/E5.

Coût III – Stockage :

Il existe deux principaux coûts au stockage sur Azure. La taille du stockage et les transactions influent sur le montant :

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

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

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

Quelles sont les économies possibles ?

• Le type de disque le moins cher n’est pas forcément le plus économe. Les transactions risquent de faire exploser le coût du stockage des machines virtuelles ou des partages de fichiers.
• Surveillez les consommations d’espace : un espace réservé et inutilisé est facturé par Azure. Ajustez la taille et les performances selon les besoins.

Coût IV – Licence :

Azure Virtual Desktop nécessite des licences adéquates en fonction de l’environnement choisi, Windows 10/11 ou Windows Server :

• Windows 10/11 : On licencie les utilisateurs et non les machines virtuelles.
• Windows Server : On licencie les machines virtuelles (+ CAL RDS) et non les utilisateurs.

Quelles sont les économies possibles ?

Pour moi, la meilleure économie possible est de partir sur une licence Microsoft 365 Business Premium pour chaque utilisateur AVD. Cette dernière comprend entre autres :

• Azure AD Premium P1
• Les droits d’utilisation d’Azure Virtual Desktop sous environnement Windows 10/11
• Les principaux outils de la suite bureautique d’Office 365
• Et encore bien d’autres fonctionnalités de sécurité

Si le choix de partir sur un environnement AVD sous Windows Server est non négociable, privilégiez Azure Hybrid Benefit grâce à l’achat de licences Windows Server et CAL RDS en mode souscription CSP. La rentabilité est atteignable en 1 ou 2 mois seulement !

Coût V – Réseau :

Les services hébergés dans le cloud sont accessibles depuis une architecture on-premise ou pour des utilisateurs simplement connectés à internet. Le schéma réseau ci-dessous montre les étapes de mise en place du bureau à distance AVD pour un utilisateur se connectant depuis internet :

Quelles sont les économies possibles ?

Vous l’avez compris, l’utilisation d’Azure AD et du protocole HTTPS inversé apportent une couche de sécurité dans le transfert de données entre l’infrastructure AVD et l’utilisateur.

Dans beaucoup de scénarios, il n’est pas systématiquement nécessaire d’exiger un accès VPN. Ce service est payant dans Azure, et son prix dépend principalement de son débit.

Enfin, les volumes de bande passante sortante ne sont pas élevés pour un environnement AVD. Il est donc inutile d’acheter un circuit ExpressRoute en formule illimité :

Coût VI – Gestion de la sécurité :

Une série d’articles dédiée à la sécurité est disponible juste ici. Pour éviter de vous endormir lors de longues lectures d’hiver et pour rester focalisé sur Azure Virtual Desktop, je vous conseille ces deux articles là :

• La sécurité de vos identités
• La sécurité de votre Azure

Prenons en exemple la sécurité sur Azure AD :

Azure AD est gratuit ! ???? Azure Active Directory est bien proposé en quatre éditions : Gratuite, Applications Office 365, Premium P1 et Premium P2. Pour des questions de sécurité, je recommande de licencier vos utilisateurs AVD avec une licence Azure AD Premium P1.

Grâce à lui, l’accès conditionnel sur votre AVD apporte des mesures de restriction et bloque les connexions suspectes :

Quelles sont les économies possibles ?

Je pense qu’il n’est pas nécessaire de s’orienter vers une licence Azure AD Premium P2 pour vos utilisateurs AVD. Ses fonctionnalités sont certes très intéressantes, mais ce besoin n’est pas utile pour des « utilisateurs lambda ».

Conclusion :

Aucun doute qu’il existe plein d’autres optimisations possibles pour un environnement AVD. Un exercice que je conseille est de suivre régulièrement les évolutions de Microsoft sur les services Cloud. Le blog officiel et les vidéos disponibles sur YouTube vous donneront toujours des informations et des astuces auxquelles vous n’avez pas pensées.

Enfin n’oubliez pas de suivre et d’analyser la consommation Azure grâce au Cost Management ????????

La maintenance informatique est une fenêtre nécessaire dans laquelle un service est volontairement indisponible et annoncé en amont. Les architectures basées sur des services Azure n’échappent pas à cette règle car il est toujours nécessaire d’effectuer des maintenances régulières pour des sauvegardes, des mises à jour, des refontes, des réplications, …

Dans cet article, nous allons nous intéresser une nouvelle fonctionnalité disponible sous Azure Virtual Desktop. Encore en préversion à l’heure où ces lignes sont écrites, elle permet de gérer les périodes de mise à jour des agents AVD sur les machines virtuelles qui composent votre pool d’hôtes.

Qu’est qu’un agent AVD ?

Un environnement Azure Virtual Desktop est composée d’une ou plusieurs machines virtuelles. Pour que la communication entre le contrôleur de structure Azure et ces dernières soit assurée, un agent est présent sur chaque machine virtuelle. Un tour dans les programmes installés nous montre tout cela :

L’installation de ces agents est entièrement transparente si la création de la machine virtuelle est réalisée depuis le portail Azure. Si vous créez la machine virtuelle via un script PowerShell, vous devrez alors télécharger et installer manuellement les fichiers MSI.

Quand est-ce que l’agent AVD est mis à jour ?

Avant l’apparition de cette nouvelle fonctionnalité, l’agent AVD se mettait à jour à son rythme sans logique particulière. A ce ceci près qu’il existait une option ayant un impact sur le rythme de mise à jour : environnement de validation.

Qu’est-ce que l’environnement de validation ?

Nous (Microsoft) vous recommandons vivement de créer un pool d’hôtes de validation dans lequel les mises à jour de service seront appliquées en premier. Les pools d’hôtes de validation vous permettent de superviser les mises à jour de service avant que celui-ci ne les applique à votre environnement standard ou de non-validation. Sans pool d’hôtes de validation, vous risquez de ne pas détecter les modifications qui génèrent des erreurs, ce qui peut entraîner des temps d’arrêt pour les utilisateurs de votre environnement standard.

Microsoft Doc

Autrement dit, la mise à jour est orientée en premier lieu vers les pools d’hôtes marqués comme environnement de validation. Une fois la mise à jour déployée avec succès en grand nombre sur des environnements de validation, elle est aussi installée sur les machines virtuelles d’environnements AVD de production.

De manière générale, un environnement de validation a tout son sens dans une solution de bureau à distance car il apporte une couche supplémentaire de tests via des utilisateurs spécifiques et évite ainsi un déploiement pouvant provoquer un blocage massif.

Mises à jour planifiées de l’agent

Toujours dans la volonté d’apporter une meilleure maîtrise de l’environnement Azure Virtual Desktop, Microsoft introduit la fonctionnalité de planification. Celle-ci ne concerne que la mise à jour de l’agent AVD présent sur les machines virtuelles du pool d’hôtes.

Comme vous allez le voir dans les écrans ci-dessous, cette option se configure au niveau du pool d’hôtes et impacte alors toutes les machines virtuelles rattachées de la même manière.

Via le portail Azure, rendez-vous sur votre pool d’hôtes et cliquez sur Mises à jour programmées des agents :

Cliquez sur la case ci-dessous pour activer la gestion manuelle des mises à jour :

Il vous est alors possible de définir une ou deux fenêtres de maintenance. Comme indiqué sur la page, 4 tentatives de mise à jour seront effectuées avant que celle-ci soit reportée la prochaine fois que les hôtes de session seront allumés.

Commencez par définir le fuseau horaire. Vous avez le choix entre celui employé par la machine virtuelle ou un parmi la liste déroulante :

Définissez le jour et l’heure de la première fenêtre de mise à jour :

Ajoutez au besoin une seconde fenêtre de mise à jour :

Enfin cliquez pour appliquer la configuration :

Et c’est tout ! ????

Conclusion

Azure Virtual Desktop continue son chemin et évolue en permanence ????. Pour rester sur ce sujet, retrouvez la vidéo très bien expliquée faite par Dean de l’Azure Academy. Dean y aborde également la possibilité de consulter l’historique des mises à jour installées via l’utilisation du Log Analytics Workspace d’Azure :

Microsoft continue d’apporter des fonctionnalités directement intégrées à Azure Virtual Desktop. Après le démarrage machines des virtuelles à la demande ou encore leur intégration directe avec Azure AD sans domaine AD, Microsoft permet encore une fois d’optimiser l’architecture AVD en l’adaptant à la demande.

Cela est toujours bienvenu pour l’optimisation des coûts.

Encore en préversion, vous pouvez déjà tester cette fonctionnalité depuis plusieurs jours en suivant la documentation Microsoft. Dans cet article, je vais mettre en place cette fonctionnalité étape par étape. Nous allons voir ensemble son impact sur un environnement AVD.

La fonction de mise à l’échelle automatique (ou plan d’autoscaling) vous permet de mettre en route des machines virtuelles (VM) Azure Virtual Desktop, en modulant à la hausse ou à la baisse leur nombre.

Cela permet d’optimiser les coûts de déploiement en fonction de vos besoins. Vous pouvez établir un plan d’autoscaling basé sur :

• Créneaux horaires
• Jours de la semaine
• Plafond du nombre de sessions utilisateurs

Etape 0 : Rappel des prérequis

Cette fonctionnalité AVD nécessite de disposer d’un environnement Azure Virtual Desktop déjà en place. Voici donc la liste des composants déjà présents sur mon tenant Azure :

• Domaine Active Directory Domain Services (AD DS)
• Pool d’hôtes Azure Virtual Desktop
• Espace de travail AVD
• Groupe d’applications AVD
• 5 machines virtuelles D4s_v4, déjà jointes à AVD

Point important : Il est nécessaire de définir un nombre maximal de sessions utilisateurs par VM dans la configuration de votre pool d’hôtes :

Etape I : Création d’un nouveau rôle RBAC

Comme l’indique la documentation Microsoft, il est nécessaire de créer un nouveau rôle RBAC pour assurer la gestion automatique des VMs.

Besoin d’en savoir un peu plus sur les rôles Azure ? Voici une vidéo en français qui devrait vous aider :

Vous pouvez suivre la création du rôle personnalisé via cette aide Microsoft, ou en répétant les étapes suivantes :Copiez le code JSON suivant et enregistrez le dans un fichier (ex. AVD-custom-role.json) sur votre PC :

{
 "properties": {
 "roleName": "Autoscale",
 "description": "Friendly description.",
 "assignableScopes": [
 "/subscriptions/<SubscriptionID>"
 ],
  "permissions": [
   {
   "actions": [
"Microsoft.Insights/eventtypes/values/read",
"Microsoft.Compute/virtualMachines/deallocate/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/powerOff/action",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/read",
"Microsoft.DesktopVirtualization/hostpools/read",
"Microsoft.DesktopVirtualization/hostpools/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read",                   "Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read"
],
  "notActions": [],
  "dataActions": [],
  "notDataActions": []
  }
 ]
}
}

• Positionnez-vous au niveau de votre souscription Azure et cliquez sur le bouton d’Ajout d’un rôle personnalisé :

• Selectionnez la fonction JSON et cherchez votre fichier précédement créé, puis cliquez sur Suivant :

• Contrôlez la bonne présence des permissions suivantes, puis cliquez sur Suivant :

"Microsoft.Compute/virtualMachines/deallocate/action", 
"Microsoft.Compute/virtualMachines/restart/action", 
"Microsoft.Compute/virtualMachines/powerOff/action", 
"Microsoft.Compute/virtualMachines/start/action", 
"Microsoft.Compute/virtualMachines/read",
"Microsoft.DesktopVirtualization/hostpools/read",
"Microsoft.DesktopVirtualization/hostpools/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read",

• Supprimez le permiètre par défaut :

• Cliquez ici pour ajouter un nouveau périmètre :

• Selectionnez le type Souscription puis choisissez celle voulue, puis cliquez sur Suivant :

• Contrôlez cet onglet et cliquez sur Suivant :

• Lancez la création de votre rôle personnalisé :

Etape II : Création d’un nouveau rôle RBAC

Une fois le nouveau rôle créé, il ne nous reste qu’à assigner le service Azure Virtual Desktop à celui-ci. Cela s’effectue directement sur le périmètre, qu’on souhaite lui assigner.

• Cherchez donc ici la Souscription Azure de votre AVD puis cliquez ici :

• Utilisez la barre de recherche pour retrouver plus facilement votre rôle personnalisé :

• Cliquez ici pour ajouter le service Azure Virtual Desktop :

• Utilisez encore une fois la barre de recherche pour retrouver le service AVD sous son ancien nom et Sélectionnez-le :

• Cliquez sur Suivant :

• Lancez l’Assignation du rôle :

• Vérifiez la présence de l’assignation d’AVD sur la souscription, puis cliquez sur le rôle :

• Vous retrouvez ici toutes les permissions nécessaire à la fonctionnalité d’Autoscale :

Microsoft.Compute/virtualMachines/deallocate/action
Microsoft.Compute/virtualMachines/restart/action
Microsoft.Compute/virtualMachines/powerOff/action
Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/read
Microsoft.DesktopVirtualization/hostpools/read
Microsoft.DesktopVirtualization/hostpools/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/read
Microsoft.DesktopVirtualization/hostpools/sessionhosts/write
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action
Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read

Etape III : Création du plan d’autoscaling

La création d’un plan d’autoscaling AVD apporte les avantages / restrictions suivants :

• Le plan d’autoscaling 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 d’autoscaling avec d’autres solutions tierces de gestion des ressources Azure
• Il n’est pas possible d’associer plusieurs plans d’autoscaling sur un seul environnement AVD
• Le plan d’autoscaling est dépendant d’un seul fuseau horaire
• Le plan d’autoscaling est configurable sur plusieurs périodes distinctes
• Le plan d’autoscaling est opérationnel dès sa configuration terminée
• Le plan d’autoscaling ne tient pas compte du « Drain mode » activé sur les VMs si aucun TAG n’est pas renseigné
• Le plan d’autoscaling n’est pas en interaction avec la méthode de répartition des utilisateurs configuré sur votre pool d’hôtes

La création du plan d’autoscaling 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 puis cliquez sur Suivant :

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

Dans chaque phase de la planification, autoscale n’éteint les machines virtuelles que lorsqu’un hôte de session n’a plus de sessions actives.

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.

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

• Choisissez un Nom, sélectionnez les Jours adéquats puis cliquez sur Suivant :

L’onglet de charge reprend le fuseau horaire du premier onglet et vous demande de renseigner les champs et de cliquer sur Suivant :

• Heure de début : Sélectionnez une heure dans le menu déroulant pour commencer à préparer les VM pour les heures de charge
• Algorithme d’équilibrage de charge : Microsoft recommande de choisir l’algorithme Breadth-first. Cela répartira les utilisateurs sur les VM existantes afin de maintenir des temps d’accès rapides
• Pourcentage minimum de VM hôtes : Entrez ici le pourcentage d’hôtes de session que vous souhaitez conserver au minimum pendant les heures de montée et de pointe. Par exemple, si vous choisissez 10 % et que votre pool d’hôtes compte 10 hôtes de session, plan d’autoscaling gardera une hôte de session disponible pour les prochaines connexions utilisateur
• Seuil de capacité : Saisissez ici le pourcentage d’utilisation du pool d’hôtes qui déclenchera le début des phases de charge et de pic. Par exemple, si vous choisissez 60 % pour un pool d’hôtes pouvant gérer 10 sessions à l’instant T, le plan d’autoscaling n’activera des hôtes supplémentaires que lorsque le pool d’hôtes dépassera 6 sessions

L’onglet de pic de charge reprend aussi le fuseau horaire du premier onglet et vous demande de renseigner les champs puis de cliquer sur Suivant :

• Heure de début : Entrez une heure correspondante au moment où votre taux d’utilisation est le plus élevé pendant la journée. Cette heure sera également l’heure de fin de votre phase de charge
• Equilibrage de charge : Sélectionnez Breadth-first ou Depth-first. Le premier distribue les nouvelles sessions utilisateur sur toutes les sessions disponibles dans le pool d’hôtes. Le second distribue les nouvelles sessions à l’ôte de session disponible ayant le plus grand nombre de connexions et n’ayant pas encore atteint sa limite de session.
• Seuil de capacité : Valeur non modifiable

L’onglet de décharge vous demande de renseigner les mêmes champs que pour ceux des périodes de charge et de pic :

• Heure de début
• Equilibrage de charge
• Pourcentage minimum d’hôtes (%)
• Seuil de capacité (%)
• Forcer la déconnexion des utilisateurs

Pour finir, l’onglet heures creuses vous demande de renseigner les mêmes champs suivants :

• Heure de début
• Equilibrage de charge
• Seuil de capacité

• Cliquez sur Ajouter une fois ce premier planning terminé :

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

• Sélectionnez-le ou les pools d’hôtes concernés et cliquez sur Suivant :

• Renseignez les TAGs et lancez la Création :

• Consultez la ressource Azure créée et dédiée au plan d’autoscaling d’Azure Virtual Desktop :

Etape IV : Test de la solution

Avant que mon script soit validé et en place, j’ai pris le soin d’éteindre l’ensemble des VMs (5) de mon pool d’hôtes AVD. Voici donc mon environnement de test :

• Limite d’utilisateurs AVD par VM : 2 utilisateurs
• Nombre de VMs AVD : 5 VMs
• Nombre total de sessions AVD disponibles : 20 sessions, soit 4 par VM

• Période A : Hors période du plan d’autoscaling
• Période B : Charge : Algorithme : Breadth-first / Min : 25 % / Max : 60 %
• Période C : Pic : Algorithme : Depth-first / Max : 60 %
• Période D : Décharge : Algorithme : Depth-first / Min : 10 % / Max : 90 %
• Période E : Creux : Algorithme : Depth-first / Max : 90 %

Période A – Hors période :

Seule une machine virtuelle s’allume après la validation du script car celui-ci est directement opérationnel :

Période B – Période de charge :

Nous entrons dans la période de charge de mon environnement Azure Virtual Desktop. Ayant paramétré le Pourcentage minimum de VM hôtes à 25% et disposant de 5 VMs AVD , une seconde VM s’allume automatiquement allumée à l’entrée dans cette phase :

25% x 5 (max nbr VMs) = 1 VM

Sans attendre la période de pic, je décide alors de connecter un premier utilisateur AVD, sachant que mon Seuil de capacité est de 60% et que le nombre d’utilisateurs AVD par VM est de 4.

De façon assez logique, aucune machine nouvelle virtuelle ne s’allume. Cela fait sens car deux VMs sont déjà opérationnelles. Je décide donc de connecter un second utilisateur. Même constat au niveau de VMs, toujours à cause de la règle des 60 % :

Je connecte donc un 3ème utilisateur AVD et ne constate toujours aucun allumage d’une nouvelle machine virtuelle. En effet la règle des 60 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :

60% x 4 (max nbr users) x 2 (VMs allumées) = 4.8 sessions utilisateurs

Je décide donc de continuer mon test et de rajouter un quatrième utilisateur. Toujours le même constat :

On finit avec la connexion du 5ème utilisateur. Cette fois-ci, cet ajout provoquera bien le démarrage d’une nouvelle et 3ème machine virtuelle AVD :

Curieusement, la connexion du 6ème utilisateur se ne retrouve pas sur cette nouvelle machine virtuelle sans utilisateur, mais bien sur la seconde, en contradiction avec l’algorithme de la période de charge :

Afin de tester toutes les caractéristiques de la période de charge, je décide de déconnecter l’ensemble des utilisateurs AVD. Aucune VM ne s’éteindra malgré 0 utilisateur connecté sur AVD :

Période C – Période de pic :

Nous quittons la période de charge pour entrer dans la période de pic d’AVD. Le but ici est de constater le changement d’algorithme Depth-first agissant sur la répartition des utilisateurs.

Aucune session utilisateur AVD n’est ouverte, 2 VMs restent allumées, même sans utilisateur :

Je connecte alors 4 utilisateurs AVD et je ne constate aucun démarrage de machines virtuelles AVD. L’assignation des utilisateurs se fait bien en Depth-first :

On continue avec la connexion du 5ème utilisateur. Cette fois-ci, cet ajout provoquera bien le démarrage d’une nouvelle et 3ème machine virtuelle AVD :

En effet la règle des 60 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :

60% x 4 (max nbr users) x 2 (VM allumée) = 4.8 sessions utilisateurs

Je décide de finir en connectant un 6ème utilisateur. L’algorithme Depth-first continue de bien s’appliquer bien comme précédement :

Au final, la période de pic se distingue de la période de charge par la présence systématique d’une machine virtuelle « d’avance », vide d’utilisateurs pour encaisser leur arrivée massive.

D’ailleurs, la déconnexion de l’ensemble des utilisateurs AVD nous ramène à deux machines virtuelles allumées :

Période D : Période de décharge :

Nous continuons l’analyse du plan d’autoscaling avec la période de décharge de mon environnement AVD. Aucune session AVD n’est active à ce moment précis. Comme la période de charge, seule une seule VM reste allumée :

Comme à chaque période, je connecte alors 3 utilisateurs AVD et je ne constate aucun démarrage de machines virtuelles AVD. L’assignation des utilisateurs se fait toujours en Depth-first :

Quand je connecte le 4ème utilisateur, je constate bien le démarrage d’une seconde machine virtuelle :

En effet la règle des 90 % se calcule sur le nombre de sessions possibles en fonction des hôtes allumées. Ici donc :

90% x 4 (max nbr users) x 1 (VM allumée) = 3.6 sessions utilisateurs

Dès que je connecte les utilisateurs 5, 6 et 7, aucune nouvelle machine virtuelle ne s’allume :

Dès que j’arrive à l’utilisateur 8, les choses changent :

Cela s’explique encore par la règle des 90% ci-dessous :

90% x 4 (max nbr users) x 2 (VMs allumées) = 7.2 sessions utilisateurs

A noter que l’inactivité des utilisateurs AVD provoque le message d’alerte suivant :

D’ailleurs, la déconnexion de l’ensemble des utilisateurs AVD nous ramène à une machine virtuelle allumée :

Période E : Période de creux :

Nous sommes maintenant dans la dernière période, appelée aussi période creuse. Le but de celle-ci est de fonctionner en économie maximale. Notre point de départ est donc une seule session AVD d’ouverte et donc une seule machine virtuelle reste active :

On recommence donc par connecter 3 utilisateurs Azure Virtual Desktop. Aucune autre machine virtuelle ne s’allume :

90% x 4 (max nbr users) x 1 (VM allumée) = 3.6 sessions utilisateurs

De ce fait, la connexion du 4ème utilisateur ajoute une seconde machine virtuelle :

On continue par connecter les utilisateurs 5, 6 et 7. Aucun changement au niveau du nombre de VMs :

En effet et comme pour le cas du 4ème utilisateur, la règle des 90% qui s’applique ici n’est réalisée que si le nombre d’utilisateurs connectés dépasse l’entier supérieur :

90% x 4 (max nbr users) x 2 (VMs allumées) = 7.2 sessions utilisateurs

La connexion du 8ème utilisateur vérifie et valide cette théorie :

Pour finir la déconnexion de tous les utilisateurs entraîne l’arrêt des machines virtuelles AVD allumées, sauf une :

Fonctionnalités et annexes

Modification

Le plan d’autoscaling est pleinement modifiable après sa création en cliquant ici :

Désactivation

Si votre pool d’hôtes a besoin de repasser en fonctionnement manuel, rien de plus simple par la désactivation temporaire du plan d’autoscaling :

Sauvegarde des logs

Comme un grand nombre de ressources Azure, vous pouvez sauvegarder les logs pour une analyse plus fine :

Dans mon cas, je fais le choix d’utiliser Log Analytics Workspace :

Erreur rencontrées

Au fil de mes différents tests, j’ai reçu une ou deux fois des messages d’erreur lors de la connexion d’un nouvel utilisateur sur une machine virtuelle fraîchement démarrée.

Un nouvel essai de connexion a résolu le souci à chaque fois.

Conclusion

Disons-le tout de suite, cette fonctionnalité était déjà disponible depuis plusieurs mois via une la solution script proposée par Microsoft et basée sur Azure Logic Apps.

La nouvelle solution choisie par Microsoft d’intégrer une fonctionnalité d’autoscaling dans Azure Virtual Desktop est riche de sens et est plus que bienvenue. Pour ma part je trouve qu’elle remplace la fonctionnalité Démarrage des VMs à la demande, déjà existante mais qui ne permettait pas de tenir des plannings de charges et de décharges.

Malgré tout, le plan d’autoscaling manque encore de clarté sur son fonctionnement dans le besoin de démarrage de machines virtuelles. Je me suis en effet retrouvé à plusieurs reprises avec plusieurs VMs allumées malgré qu’elles soient vides d’utilisateurs.

Pour finir, un aperçu graphique du mode et des indices de charges actuels aurait été apprécié.