Windows Server 2012 / 2012 R2 - RDS - Améliorer les performances du serveur RDS en gérant au mieux les sessions et ses ressources

Page 1 / 1

Même si vous tentez de créer une infrastructure RDS hautement disponible, il arrivera toujours un moment où votre serveur ralentira (à cause d'un utilisateur ou d'un processus trop gourmand, par exemple) ou tout simplement parce qu'il reste plusieurs sessions inactives sur vos serveurs hôtes de sessions.
Dans ces sessions, il y a peut-être des programmes qui tournent pour rien depuis plusieurs heures et qui auraient pu être fermés automatiquement par votre serveur si vous aviez spécifié des délais d'inactivité pour les sessions de vos utilisateurs.

  1. Gestion des sessions et des ressources de l'infrastructure RDS
  2. Alertes de performances
  3. Limiter les connexions simultanées à la passerelle RDS

1. Gestion des sessions et des ressources de l'infrastructure RDS

Dans les propriétés de chaque collection RDS, vous trouverez un onglet "Session" qui vous permettra de :

  • mettre fin à une session déconnectée : une session peut être statut "Déconnecté" lorsqu'un utilisateur ferme par exemple la fenêtre du bureau à distance via la croix en haut à droite au lieu de se déconnecter proprement
  • limiter une session active : cette option est utile uniquement si vous savez que vos utilisateurs n'utiliseront leurs sessions qu'un certain temps (si l'utilisateur travaille 8 heures par jour), vous savez que vous pouvez indiquer une limite un peu supérieure à cette durée.
  • limite de session inactive : lorsqu'un utilisateur réduit par exemple la fenêtre "Bureau à distance" et qu'il n'y travaille plus pendant un certain temps, la session est considérée comme inactive

Ensuite, dans le cas d'une déconnexion ou lorsqu'une des limites est atteinte, vous pourrez choisir de :

  • déconnecter la session : l'utilisateur distant perdra l'affichage, mais les programmes resteront ouverts sur le serveur pour éviter de faire perdre leur travail non enregistré (on ne sait jamais)
  • mettre fin à la session : la session de l'utilisateur sera fermée et tous les programmes, ainsi que les documents ouverts par cet utilisateur seront fermés. Cela permettra de libérer des ressources sur le serveur, mais si l'utilisateur a oublié de sauvegarder son travail, celui-ci sera en général perdu.
    A l'exception de Microsoft Word, par exemple, qui effectue une sauvegarde automatiquement par défaut de ce que l'utilisateur modifie dans le document et qui proposera de le restaurer au redémarrage du programme (UNIQUEMENT SI l'utilisateur a sauvegardé au moins une fois son document).

Si vous utilisez plusieurs serveurs hôtes de session par collection, vous pourrez gérer l'équilibrage de charge sur ceux-ci dans les propriétés de la collection souhaitée.
Dans l'onglet "Equilibrage de la charge", vous verrez la liste des serveurs hôtes de session attribués à cette collection et vous pourrez spécifier :

  • la pondération relative : c'est un "poids" qui définit comment seront répartis vos utilisateurs (en admettant qu'ils utilisent tous la même quantité de mémoire et de ressources CPU)
  • la limite de session : qui permet limiter le nombre de sessions sur un serveur hôte de session (ce qui peut permet de ne pas saturer un serveur et d'offrir une certaine fluidité à vos utilisateurs)

Pour faire simple, si le 1er serveur RDS a une pondération relative à 1000 et le 2ème à 100, le 1er supportera 10 fois plus de sessions que le 2ème serveur.+

Source : Aide sur paramétrage RDS Equilibrage de charges - Pondération Relative & Limite de session (Technet Microsoft)

Pour limiter simplement l'utilisation des ressources sur votre serveur, vous pouvez aussi vérifier et limitez la redirection des ressources client pour enlever ce qui n'est pas nécessaire dans votre cas.
Par exemple : en fonction des besoins de vos utilisateurs, il est possible que la redirection de la lecture audio/vidéo et des lecteurs de cartes à puces ne soit pas nécessaire.

En désactivant ces redirections, vous éviterez donc à votre serveur d'utiliser des ressources inutilement pour chaque utilisateur connecté.
Ce qui peut devenir très significatif si vous possédez de nombreux utilisateurs.

2. Alertes de performances

Pour savoir si un serveur sature, vous pouvez activer des alertes de performances.
Dans le cas où un programme consommerait beaucoup de ressources ou que la quasi-totalité des ressources du serveur serait utilisée, vous pourriez être averti et pouvoir fermer les processus concernés sur les sessions utilisateurs concernées avant qu'il ne soit trop tard.

Pour cela, allez dans "Services Bureau à distance -> Serveurs" et sélectionnez votre serveur RDS.

Ensuite, descendez jusqu'à la section "Performances" où vous verrez votre serveur RDS apparaitre.
Cliquez sur "Tâches -> Configurer des alertes de performances".

Notez que le serveur affiché ici est celui sélectionné plus haut, d'où l'utilité de l'avoir sélectionné précédemment.

Indiquez à partir de quand vous souhaitez être alerté :

  • taux d'utilisation du processeur
  • quantité de mémoire utilisée

Pour que cela fonctionne, n'oubliez pas d'activer les compteurs de performances en faisant un clic droit "Démarrer les compteurs de performances".

Windows Server vous avertira que vous devrez patienter au moins 30 minutes pour commencer à voir des informations ici.
De plus, l'état du compteur sera : Activé - Attente de données.

3. Limiter les connexions simultanées à la passerelle RDS

Pour finir, si vous avez installé une passerelle RDS pour fournir un accès sécurisé depuis l'extérieur à votre infrastructure RDS, sachez qu'il est aussi possible de limiter le nombre de connexions simultanées à cette passerelle.
Pour cela, ouvrez le gestionnaire de passerelle des services Bureau à distance et faites un clic droit "Propriétés" sur celle-ci.

Ensuite, dans l'onglet "Général", vous pourrez gérer le nombre maximal de connexions à autoriser pour cette passerelle RDS.

Un autre moyen qui peut être complémentaire consiste à créer une batterie de serveurs de passerelles RDS pour répartir les connexions (via NLB) sur les différents serveurs et ainsi répartir la charge de travail sur ces différents serveurs.