Architecture d’Azure Virtual Desktop : pools d’hôtes et équilibrage de charge expliqués

By Mirko Peters · 2026-08-27

Bienvenue sur le blog ! Si vous avez déjà regardé sous le capot d’une implémentation cloud à grande échelle, vous savez que lancer des machines virtuelles dans le cloud ne représente que la moitié du travail. Lorsqu’il s’agit de déployer une stratégie de virtualisation de bureaux solide, la vraie magie opère au niveau de l’architecture. Une structure sous-jacente bien conçue détermine si vos utili

Automatically translated with AI from the original post. Read the English original

Cover: Azure Virtual Desktop - Simply Explained

Dans notre dernier épisode de podcast, Azure Virtual Desktop - Simply Explained, nous avons présenté les concepts fondamentaux d’AVD et expliqué pourquoi il est devenu un outil indispensable pour les organisations modernes. Aujourd’hui, nous allons nettement approfondir ce sujet en plongeant dans l’architecture technique. Nous verrons comment choisir entre pools d’hôtes personnels et pools d’hôtes partagés, évaluer les différents algorithmes d’équilibrage de charge, configurer des limites de session précises et, finalement, concevoir un environnement qui concilie expérience utilisateur haute performance et rigueur en matière de coûts.

Introduction à l’architecture d’Azure Virtual Desktop

Lors de la conception d’un environnement Azure Virtual Desktop (AVD), vous construisez un écosystème qui relie les plans de contrôle gérés par Microsoft aux plans de données de votre propre abonnement Azure. Le plan de contrôle assure les tâches essentielles telles que l’accès web, les services de passerelle, la supervision et le courtage des connexions. Le plan de données, où résident réellement vos charges de travail, est constitué de vos machines virtuelles Azure faisant office d’hôtes de session, organisées en pools d’hôtes.

Comprendre cette séparation des responsabilités est essentiel à la réussite de la planification d’une architecture. Comme Microsoft prend en charge l’essentiel de l’infrastructure du plan de contrôle, votre priorité d’architecte porte entièrement sur la manière de provisionner, configurer et faire évoluer vos hôtes de session. Des choix erronés dès la phase de conception peuvent engendrer des goulots d’étranglement, une mauvaise utilisation des ressources et des dépenses d’infrastructure gonflées. En concevant judicieusement vos pools d’hôtes, en choisissant des stratégies d’équilibrage de charge adaptées et en ajustant finement les limites de session, vous pouvez bâtir un environnement qui évolue sans effort avec la croissance de votre organisation.

Pools d’hôtes partagés ou personnels : choisir le bon modèle

L’une des toutes premières décisions d’architecture à prendre lors du déploiement d’AVD consiste à choisir entre pools d’hôtes partagés et pools d’hôtes personnels. Ce choix modifie en profondeur la manière dont vos utilisateurs interagissent avec leurs machines virtuelles et la façon dont votre infrastructure sous-jacente consomme les crédits de calcul Azure.

Pools d’hôtes partagés : efficacité maximale et économies

Dans un pool d’hôtes partagé, plusieurs utilisateurs utilisent simultanément la même machine virtuelle. Par exemple, vous pouvez provisionner une machine virtuelle Azure robuste dotée de plusieurs vCPU et d’une mémoire vive généreuse, et permettre à plusieurs utilisateurs simultanés de se connecter à cette seule machine.

Le principal avantage ici réside dans l’efficacité et la réduction des coûts. Comme les ressources sont partagées, vous avez besoin de moins de machines virtuelles en fonctionnement simultané pour soutenir un effectif important. Ce modèle convient particulièrement aux scénarios standard en entreprise, où les utilisateurs exécutent des applications métier courantes, des navigateurs web et des applications Microsoft 365. Toutefois, comme les utilisateurs partagent les ressources, vous devez gérer les « voisins bruyants », c’est-à-dire la situation où l’application très gourmande d’un utilisateur (comme la compilation de code ou le rendu graphique) dégrade temporairement les performances des autres sessions de la même machine.

Pools d’hôtes personnels : puissance dédiée et contrôle de l’état

À l’inverse, les pools d’hôtes personnels attribuent une machine virtuelle dédiée à un utilisateur précis. Lorsque John se connecte à AVD chaque matin, il accède à sa propre machine virtuelle isolée, que nul autre utilisateur n’utilise.

Ce modèle convient idéalement aux utilisateurs avancés, aux développeurs, aux ingénieurs ou aux cadres qui ont besoin de logiciels spécialisés, de paramètres locaux persistants ou d’une forte puissance de calcul (comme des applications de CAO ou des outils de science des données) difficiles à partager. Si les pools d’hôtes personnels offrent une base de performances prévisible et dédiée, et éliminent les problèmes de « voisins bruyants », leur coût financier est plus élevé. Il est difficile de réduire la capacité des machines virtuelles personnelles lorsque les utilisateurs sont hors ligne, à moins de mettre en place des stratégies de désallocation agressives, ce qui signifie que vous payez une capacité de calcul dédiée en permanence.

Algorithmes d’équilibrage de charge : priorité à la largeur ou à la profondeur

Une fois que vous avez choisi d’utiliser des pools d’hôtes mutualisés, votre prochaine considération d’architecture concerne la manière dont les sessions utilisateur entrantes sont réparties entre les machines virtuelles disponibles dans ce pool. AVD propose deux algorithmes principaux d’équilibrage de charge pour gérer cette répartition : la priorité à la largeur (breadth-first) et la priorité à la profondeur (depth-first).

Équilibrage de charge par priorité à la largeur : privilégier la performance

L’algorithme breadth-first est conçu pour répartir uniformément les nouvelles sessions utilisateur entre tous les hôtes de session disponibles dans un pool d’hôtes. Si votre pool compte quatre machines virtuelles, la première session utilisateur est dirigée vers la VM 1, la deuxième vers la VM 2, la troisième vers la VM 3, la quatrième vers la VM 4, et la cinquième session revient à la VM 1.

Pourquoi choisir la priorité à la largeur ? Cette approche maximise les ressources matérielles disponibles par utilisateur. Comme les sessions sont réparties, chaque utilisateur dispose d’une part plus importante du processeur, de la mémoire vive et des IOPS disque de sa machine, ce qui se traduit par une expérience utilisateur fluide et très réactive. C’est le choix privilégié des organisations pour lesquelles la performance des utilisateurs est primordiale et dont les charges applicatives sont imprévisibles.

Équilibrage de charge par priorité à la profondeur : privilégier le coût

L’algorithme depth-first adopte l’approche exactement inverse. Il remplit un hôte de session jusqu’à atteindre sa limite maximale de sessions préconfigurée, avant d’orienter toute nouvelle connexion utilisateur vers la machine virtuelle suivante du pool.

Pourquoi choisir la priorité à la profondeur ? Cette méthode vise avant tout l’optimisation des coûts et l’alignement sur la mise à l’échelle automatique. En regroupant les utilisateurs sur un nombre réduit de machines virtuelles actives, les autres VM restent totalement inactives. Dans un environnement cloud, ces VM inactives peuvent être arrêtées ou désallouées en toute sécurité à l’aide de scripts d’automatisation Azure ou de plans de mise à l’échelle intégrés. Vous évitez ainsi de payer des ressources de calcul en cours d’exécution dont vous n’avez pas besoin en dehors des heures de pointe.

Configurer les limites de sessions pour la performance et le coût

Choisir votre algorithme d’équilibrage de charge ne représente que la moitié du problème : vous devez également configurer le nombre maximal de sessions pour vos hôtes de session. Définir le bon seuil exige un équilibre mathématique précis, fondé sur le dimensionnement de vos VM (vCPU et RAM).

Pour les charges de travail bureautiques standard, une règle empirique courante consiste à viser environ 4 à 6 sessions utilisateur par vCPU, même si ce nombre varie fortement selon le mix d’applications. Par exemple :

Utilisateurs légers : les utilisateurs qui travaillent principalement avec des navigateurs web, la messagerie et l’édition simple de documents peuvent souvent supporter des densités de sessions plus élevées.
Utilisateurs intensifs : les utilisateurs qui exécutent des analyses de données complexes, plusieurs applications de bureau lourdes ou des visioconférences persistantes nécessitent des limites de sessions strictes pour éviter la saturation des ressources.

Si vous fixez une limite de sessions maximale trop élevée dans une configuration depth-first, les utilisateurs subiront une dégradation importante des performances lorsque la VM atteindra son plafond de ressources. Si elle est trop basse, vous perdez les économies liées à la mutualisation des ressources. Les outils de surveillance comme Azure Monitor sont essentiels ici : analysez le processeur, la mémoire et la longueur des files d’attente disque sur un cycle d’activité professionnelle typique pour affiner votre seuil exact.

Optimiser l’utilisation des ressources et l’efficacité des coûts

L’architecture ne consiste pas seulement à assurer le bon fonctionnement au quotidien ; il s’agit de garantir la viabilité financière de votre déploiement cloud sur toute sa durée de vie. Pour atteindre une réelle efficacité des coûts dans AVD, vous devez tirer parti de la mise à l’échelle dynamique et de la gestion moderne des profils.

La mise en œuvre de la mise à l’échelle automatique native d’Azure Virtual Desktop vous permet de démarrer automatiquement les hôtes de session lorsque la demande des utilisateurs augmente le matin, et de les arrêter en toute sécurité au fur et à mesure que les utilisateurs se déconnectent le soir. Combinée à l’équilibrage de charge par priorité à la profondeur, la mise à l’échelle automatique vous garantit de ne jamais payer une capacité fantôme.

Par ailleurs, la mise en œuvre de conteneurs de profils FSLogix est indispensable à un environnement mutualisé bien conçu. FSLogix redirige les profils utilisateur vers un partage de fichiers centralisé (tel qu'Azure Files ou Azure NetApp Files) à l'ouverture de session. Ainsi, quel que soit l'hôte de session sur lequel un utilisateur est orienté par l'algorithme en largeur d'abord, ses paramètres de bureau, ses fichiers OST Outlook et ses personnalisations le suivent de manière transparente. Cela garantit une expérience utilisateur cohérente tout en maintenant des disques de VM locaux légers et rapides.

Conclusion et prochaines étapes pour la planification de l'architecture

Concevoir une architecture Azure Virtual Desktop est un exercice exigeant, qui impose de trouver le juste équilibre entre expérience utilisateur, prévisibilité des performances et dépenses cloud. En évaluant avec discernement les pools d'hôtes mutualisés et personnels, en choisissant judicieusement entre les algorithmes d'équilibrage en largeur d'abord et en profondeur d'abord, et en ajustant précisément les limites de session ainsi que FSLogix et la mise à l'échelle automatique, vous pouvez bâtir une infrastructure de bureaux virtuels résiliente et performante.

Si vous souhaitez porter votre stratégie de virtualisation à un niveau supérieur et découvrir d'autres analyses d'experts sur les technologies Microsoft modernes, écoutez l'épisode complémentaire, Azure Virtual Desktop - Simply Explained. Il vous apporte les repères fondamentaux nécessaires pour prendre des décisions d'architecture éclairées et stratégiques au sein de votre organisation.

Bonne architecture, et à bientôt dans le cloud !