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é.