Comment calculer les ressources sur un serveur terminal : une méthode de dimensionnement pratique

Un calculateur de serveur terminal n'est rarement un calculateur au sens littéral. Dans la plupart des environnements PME et MSP, c'est une méthode de planification utilisée pour estimer combien de CPU, de RAM, de stockage et de marge un serveur terminal aura besoin avant que les utilisateurs ne commencent à se plaindre. La vraie question derrière le mot-clé est pratique : comment calculez-vous les ressources sur un serveur terminal suffisamment bien pour déployer en toute confiance, éviter de trop dépenser et réduire le risque de goulets d'étranglement de performance ?

Que devrait réellement calculer un calculateur de serveur terminal ?

Un calculateur de serveur terminal utile devrait estimer plus que "utilisateurs par serveur". En tant qu'administrateur, il devrait vous aider à planifier la performance du CPU, de la RAM, du stockage, du stockage de profil et de la marge de capacité sous une utilisation concurrente réaliste. Les recommandations de Microsoft pour les hôtes de session de Bureau à distance encadrent le dimensionnement autour du type de charge de travail et des utilisateurs suggérés par vCPU, et non autour d'une limite de connexion générique unique.

Pourquoi le nombre d'utilisateurs à lui seul n'est-il pas suffisant pour calculer les ressources sur un serveur terminal ?

Utilisation de la session

Gardez à l'esprit que deux environnements avec le même nombre d'utilisateurs peuvent produire des résultats très différents. Nous supposons que vous savez déjà combien d'utilisateurs accéderont à votre infrastructure, donc avoir licences et CALs considérées , le travail pratique peut commencer.

Imaginez comment quinze utilisateurs ouvrant une application métier peuvent exercer une charge modeste sur un hôte. Pendant ce temps, quinze utilisateurs exécutant un bureau à distance complet avec des navigateurs, des applications Office, des outils PDF, l'impression et la synchronisation en arrière-plan peuvent créer une empreinte beaucoup plus lourde. Les modèles de dimensionnement reflètent cette différence en séparant les charges de travail multi-session légères, moyennes et lourdes.

La distinction est importante car "30 utilisateurs" n'est pas un chiffre de capacité en soi. Cela n'a de sens que lorsque vous définissez ce que ces utilisateurs font et utilisent durant les périodes de pointe.

Utilisation du serveur

N'oubliez pas également une distinction importante qui compte énormément : pour des laboratoires ou un petit bureau, vous pourriez prévoir un seul serveur, car il gérera moins de sessions utilisateur simultanées, tandis que pour la production, vous prévoyez probablement un parc. En effet, des rôles séparés sont nécessaires pour améliorer les performances, simplifier le dépannage et renforcer la sécurité, donc une répartition courante serait :

• 1 serveur pour Broker, Web et Licensing
• 1 ou plusieurs serveurs pour l'hôte de session
• 1 passerelle RD sur son propre serveur pour un accès externe.

Pour aller un peu plus loin, vous constaterez également que le type de serveur, la mémoire, etc., entreront en jeu et vous voudrez peut-être inclure SSD dans des configurations plus grandes par exemple. Cependant, ceci n'est qu'une mention pour vous sensibiliser aux possibilités.

Quelles sont les quatre entrées qui façonnent la planification des ressources ?

Ensuite, plus fiable que de sauter directement aux chiffres matériels, voici quatre éléments à rassembler avant de commencer à compter. Ce travail en amont évite les chevauchements avec les questions de licence concernant qui peut se connecter et selon quelles règles de Microsoft. La préoccupation centrale ici est de savoir combien de ressources un hôte de session a besoin pour rester réactif. Notre article précédent a couvert licences et capacité du serveur afin que nous puissions développer ici les aspects pratiques de tout compter méthodiquement pour bien planifier.

Par conséquent, vous devez additionner :

Utilisateurs actifs concurrents

Nous devons toujours inclure ce nombre essentiel, car le nombre de sessions exécutées en parallèle affectera certainement les performances du serveur. Notez que le nombre concurrent peut être indépendant du nombre total.

Classe de charge de travail par groupe d'utilisateurs

Évaluer combien un utilisateur ou un ensemble d'utilisateurs va puiser dans les ressources est le premier test de réalité. Certains groupes ou individus utiliseront inévitablement plus les tâches qu'ils effectuent. C'est pourquoi il est nécessaire d'identifier les utilisateurs intensifs.

Type d'application et de session

Il est également très utile de cibler des applications spécifiques, car certains utilisateurs monopoliseront de grandes quantités de ressources en fonction de celles qu'ils exécutent.

Pic, marge de croissance et de basculement

Rassemblez cette liste d'entrées en tenant compte de l'utilisation maximale, en laissant de la place pour une croissance à court terme attendue et en intégrant une marge de sécurité pour les pannes.

Comment calculez-vous les ressources sur les serveurs de terminal ?

Voici une méthode de calcul pratique que nous espérons sera utile dans l'administration des PME ainsi que dans d'autres contextes. Elle vise à simplifier au moins la planification et la structure de la montée en charge. Ensuite, elle devrait se prêter à un perfectionnement afin que vous puissiez compter dessus pendant la période pilote et au-delà.

Étape 1 : Comptez les utilisateurs concurrents, pas le nombre total d'utilisateurs

Commencez par le nombre d'utilisateurs qui sont actifs en même temps. C'est ce nombre qui détermine la charge du serveur. Une entreprise avec 50 utilisateurs nommés peut n'avoir que 18 à 25 connectés simultanément pendant les heures de pointe. Lors de la dimensionnement d'un hôte de session, le nombre de sessions simultanées est beaucoup plus utile que le nombre total d'employés.

Avant de tester la capacité durable du monde réel sous charge, la planification doit remettre en question les estimations.

Étape 2 : Classifiez les charges de travail comme légères, moyennes ou lourdes

Ensuite, triez les utilisateurs du groupe par charge de travail. Microsoft’s guidance de l'hôte de session actuelle suggère les plages de densité de base suivantes pour les environnements multi-session et HP et d'autres sources sont d'accord :

• jusqu'à 6 utilisateurs légers par vCPU,
• 4 utilisateurs moyens par vCPU et
• 2 utilisateurs intensifs par vCPU,

avec respectivement un exemple de VM minimum de 8 vCPU, 16 Go de RAM, 32 Go de stockage dans ces bandes de charge de travail. Les recommandations incluent également de maintenir les tailles de VM multi-session entre 4 et 24 vCPUs pour de meilleurs rendements de capacité.

Une simple carte de charge de travail pour la planification des PME guiderait donc le tri :

• Lumière : une application professionnelle, utilisation limitée du navigateur, sessions courtes
• Moyen : Applications de bureau, onglets de navigateur, outils PDF, multitâche modéré
• Lourd : ERP, fichiers Excel plus volumineux, utilisation constante du navigateur, impression, plusieurs applications ouvertes toute la journée

Ce sont des bandes de planification de base, pas des garanties. L'objectif est de choisir un point de départ basé sur le comportement de la charge de travail.

Étape 3 : Estimer la capacité du CPU

Une fois que les utilisateurs sont regroupés, estimez le CPU avec une approche utilisateurs par vCPU. Par exemple, si 24 utilisateurs simultanés sont principalement des utilisateurs moyens, la référence de Microsoft d'environ 4 utilisateurs par vCPU suggère de commencer autour de 6 vCPUs, puis d'arrondir à une taille d'hôte pratique avec une marge de manœuvre pour les pics. Si vous souhaitez offrir une meilleure capacité de pointe pendant les pics de demande CPU à court terme, prévoyez des ratios utilisateurs par cœur inférieurs à ceux que vous pourriez envisager autrement.

Comme cela peut être devenu évident, le dimensionnement du CPU ne devrait pas s'arrêter au minimum mathématique. Il devrait tenir compte des pics de connexion, de l'activité antivirus, des tâches de reporting et des courtes périodes de lancements d'applications simultanés.

Étape 4 : Estimer les besoins en RAM

La RAM doit couvrir les besoins du système d'exploitation, des services de base, de la surcharge de session et de l'utilisation de la mémoire des applications par utilisateur. Comme décrit ci-dessus, la base de référence multi-session actuelle de Microsoft associe ses exemples de charges de travail légères, moyennes et lourdes à un minimum de 16 Go de RAM pour un point de départ de 8 vCPU. Bien qu'il ne s'agisse que d'une base de référence, cela fournit néanmoins un point de départ tangible pour l'estimation.

Une méthode pratique dans une petite ou moyenne entreprise est de :

1. réserver de la mémoire pour le système d'exploitation et les services de plateforme.
2. estimation de la mémoire par session par classe d'utilisateur,
3. multiplier par des sessions concurrentes,
4. puis ajoutez une marge de sécurité.

PeteNetLive donne un règle générale délibérément large de 2 à 8 Go par utilisateur pour la planification de la RAM du serveur de session RD. Cela est utile comme avertissement contre la sous-estimation des sessions lourdes, même si le nombre exact doit être affiné lors des tests.

Étape 5 : Vérifiez le stockage et la surcharge de profil

Le stockage est souvent sous-estimé dans la planification des serveurs terminaux. Un stockage lent et encombré peut nuire aux connexions, au chargement des profils, aux fichiers temporaires, aux lancements d'applications et à la mise en mémoire tampon des impressions, même lorsque le CPU et la RAM semblent encore acceptables.

• stockage de profil
• stockage OS
• journaux : à des fins de sécurité et autres telles

Cette dernière catégorie mérite d'être estimée car elle peut rapidement gonfler en fonction de la taille de votre infrastructure et du type de surveillance et de protection dont vous avez besoin.

La présentation rôle par rôle de PeteNetLive sert de rappel utile que l'hôte de session est généralement l'endroit où la pression sur les ressources apparaît en premier, tandis que d'autres rôles RDS ont souvent des empreintes relativement plus petites. Gardez cela à l'esprit lorsque vous recherchez des indicateurs de la capacité d'utilisation de votre entreprise, car cela peut soutenir l'évaluation des plans.

Étape 6 : Ajoutez une marge pour les pics, la croissance et la bascule

Aucun calculateur de serveur terminal ne devrait se terminer par le nombre « juste suffisant ». Ajoutez une marge de manœuvre pour :

• pics de connexion du matin
• mise à jour et analyses antivirus
• les pics de reporting mensuel
• croissance attendue des utilisateurs
• échec d'hôte dans une conception multi-serveur

En conclusion, un bon conseil opérationnel pour tout environnement dépassant un hôte unique est de prendre en compte des hôtes supplémentaires en cas de perte de serveur ou d'hyperviseur.

Méthode simple de calculateur de serveur terminal pour les PME et les MSP

Cette logique de calcul est intentionnellement simple. Elle est destinée à produire une première estimation défendable, et non un point de référence final, et pour que vous puissiez l'adapter en conséquence.

Une formule de planification rapide

Utilisez cette séquence :

1. Compter utilisateurs concurrents .
2. Triez-les en léger, moyen et lourd groupes.
3. Estimation CPU en utilisant un ratio d'utilisateurs par vCPU de référence.
4. Estimation RAM de la surcharge du système d'exploitation plus la demande par session.
5. Vérifier stockage pour le profil, la température et les performances de lancement.
6. Ajouter 20 à 30 pour cent de marge , puis examinez les besoins de basculement.

Cela reflète l'essence de la manière dont la taille est définie en général : charge de travail d'abord, ratios ensuite, perfectionnement après observation. Et maintenant, pourquoi ne pas avoir un aperçu de quelle forme cela pourrait-il prendre , obtenez une estimation précise et planifiez votre infrastructure potentielle ? Un outil clé lors de la planification de votre budget.

Exemple 1 : 15 utilisateurs légers de bureau

Supposons que 15 utilisateurs simultanés accèdent à une application professionnelle publiée, en plus d'une utilisation légère du navigateur.

En utilisant des bases légères recommandées, l'estimation brute du CPU est d'environ 3 vCPUs. En pratique, cela est trop serré pour la capacité de pointe, donc un planificateur opterait pour un profil d'hôte plus pratique plutôt que de construire à la limite. Vous trouverez que les conseils favorisent une plage de dimensionnement plus large de 4 à 24 vCPUs avec 8 vCPUs et 16 Go de RAM comme profil de base standard pour les charges de travail multi-session.

Pour la RAM, réservez de la capacité pour le système d'exploitation et les services, puis ajoutez de la mémoire de session pour chaque utilisateur. Si l'environnement est stable et que l'utilisation des applications est limitée, cela pourrait tenir confortablement sur un hôte modeste, mais cela doit tout de même être validé lors de l'utilisation pilote.

Exemple 2 : 30 utilisateurs de bureau et ERP mixtes

Supposer :

• 18 utilisateurs moyens
• 12 utilisateurs lourds

Un raccourci de planification traiterait le groupe moyen à environ 4 utilisateurs par vCPU et le groupe lourd à environ 2 utilisateurs par vCPU. Cela implique environ 4,5 vCPUs pour le groupe moyen et 6 vCPUs pour le groupe lourd, avant les frais généraux et la marge de manœuvre. En pratique, cela indique déjà de s'éloigner d'un seul hôte de taille légère et de se diriger soit vers un hôte plus grand avec une marge, soit vers une répartition entre plusieurs hôtes de session.

C'est ici que le conseil "prévoir des ressources serveur" prend tout son sens. Avec un ERP tout comme dans tout contexte d'entreprise, l'objectif n'est pas seulement de placer les utilisateurs quelque part. L'objectif n'est pas seulement de placer les utilisateurs quelque part. L'objectif est de maintenir des temps de réponse acceptables pendant les périodes les plus chargées de la journée.

Exemple 3 : Quand diviser les utilisateurs sur plusieurs hôtes

Une fois que le calcul produit un hôte dense avec une capacité de pointe limitée, la meilleure réponse peut être architecturale plutôt que le redimensionnement vertical. Les hôtes de session peuvent être configurés pour effectuer le travail lourd, tandis que des rôles tels que RD Connection Broker, Gateway et Licensing peuvent se voir attribuer différents profils de ressources. Répartir la charge des utilisateurs sur plusieurs hôtes est susceptible d'améliorer la résilience, la flexibilité de maintenance et la planification de la reprise après sinistre.

Pour les MSP, c'est souvent le point de basculement où un calculateur de serveur terminal devient une discussion sur la taille de la ferme au lieu d'une discussion sur un serveur unique.

Quelles erreurs de dimensionnement courantes compromettent généralement les performances du serveur terminal ?

Les erreurs de dimensionnement ne sont généralement pas causées par les mathématiques seules. Elles proviennent d'hypothèses incorrectes.

Confondre la licence avec la capacité de performance

La gestion des licences vous indique comment l'accès est attribué et configuré. Elle ne vous indique pas combien d'utilisateurs simultanés un serveur pourra supporter avec des performances acceptables.

Ignorer les sessions lourdes en navigateur et en impression

De nombreux environnements sous-estiment encore combien l'utilisation moderne des navigateurs, la gestion des PDF et l'impression peuvent ajouter à un hôte de session. Ces activités peuvent faire passer un groupe d'utilisateurs de léger à moyen, ou de moyen à lourd, même lorsque l'application métier elle-même est modeste.

Dimensionnement uniquement pour une charge moyenne

La charge moyenne est rarement le moment où les utilisateurs se plaignent. Les plaintes surviennent lors des tempêtes de connexion, des ouvertures de fichiers simultanées, des exécutions de rapports ou des pics matinaux. Microsoft note qu'une meilleure capacité de pointe est importante à des ratios utilisateurs par cœur plus faibles car cela permet de laisser de la place au lieu de viser une densité maximale.

Oublier le reste de la pile RDS

L'hôte de session est le principal consommateur de ressources, mais ce n'est pas le seul rôle dans l'environnement. La répartition des rôles de PeteNetLive est un rappel utile pour tenir compte du Broker de connexion, du Gateway, de l'accès Web et de la licence séparément lorsque le déploiement dépasse une petite configuration à hôte unique.

Pourquoi la surveillance devrait-elle valider vos estimations de taille ?

Un calculateur de serveur terminal vous donne une base de planification. Il ne vous donne pas de preuve. Pour avoir une preuve, vous devez surveiller l'utilisation.

De la ligne de base à la preuve : la surveillance comme un élément essentiel

Dans notre article précédent, nous expliquons pourquoi la capacité utilisateur durable est une question de surveillance pratique. Ici, l'objectif a été de montrer comment estimer la première version de cette capacité avant le déploiement. La surveillance vous fournira de nombreux comptes que nous avons mentionnés. Nous vous recommandons de tester dans un contexte de laboratoire pour évaluer vos besoins envisagés.

Où TSplus Server Monitoring fait-il la différence ?

Surveillance du serveur TSplus s'adapte après le déploiement de l'estimation de dimensionnement. Cela aide à vérifier si la saturation du CPU, la pression de la mémoire, les goulets d'étranglement de stockage ou les pics d'utilisation correspondent aux hypothèses utilisées dans la planification. Cela est particulièrement utile pour les administrateurs informatiques de PME et les MSP qui ont besoin de preuves avant de redimensionner un hôte, de redistribuer des utilisateurs ou d'ajouter un autre serveur.

Au-delà de savoir comment projeter des ressources, comment pouvez-vous savoir si le calcul était correct autrement qu'en utilisant des systèmes de surveillance ? La surveillance des serveurs vous offre une surveillance en temps réel et des alertes pour vous tenir informé chaque fois que des indicateurs atteignent vos seuils définis. .

TSplus logiciel pour la livraison sécurisée et durable d'applications et de bureaux

TSplus Remote Access appartient en tant que couche de livraison dans l'histoire plus large tandis qu'Advanced Security est conçu sur mesure pour protéger les serveurs d'applications. De plus, TSplus Remote Support fournit un kit d'essentiels pour le dépannage et la maintenance de ces serveurs et plus encore depuis n'importe quel endroit. Une fois que l'environnement est correctement dimensionné, TSplus Remote Access publiera des bureaux et des applications plus simplement que Citrix et sans dépasser votre budget. Tester des fonctionnalités telles que l'accès web et la livraison centralisée vous donnera un aperçu de la façon dont vous pouvez aller au-delà de l'accès RDP ad hoc.

Conclusion

Un calculateur de serveur terminal ne devrait pas promettre une réponse magique. Il est maintenant temps de calculer les ressources du serveur terminal par étapes : commencez par les utilisateurs simultanés, classez l'intensité de la charge de travail, estimez le CPU et la RAM en fonction du comportement réaliste des sessions, vérifiez le stockage, puis ajoutez une marge pour les pics, la croissance et la redondance.

En tant qu'administrateur système, les administrateurs informatiques des PME ou les MSP, cela vous donnera une première estimation pratique. À partir de là, la véritable discipline est la validation. Planifiez soigneusement, déployez de manière conservatrice et utilisez ensuite les données de surveillance pour confirmer si l'hôte, ou ferme hôte peut soutenir l'expérience utilisateur que vous envisagez.