Les calculateurs de charge Citrix

Le fonctionnement des calculateurs de charge sous Citrix est un des points un peu obscurs de Citrix XenApp. Afin de répondre aux questions les plus fréquemment posées, voici un petit article à ce sujet.

 

I. Fonctionnement

Le calculateur de charge est un rôle détenu par le data-collector d’une ferme. Lors de l’ouverture d’une application, il va indiquer au client le serveur sur lequel celui-ci doit se connecter.

 

Le choix de ce serveur est déterminé par plusieurs facteurs :

  • Est-ce que l’utilisateur dispose déjà d’une session ICA active ?
  • Sur quels serveurs l’application est-elle publiée ?
  • Quel est le serveur le moins chargé disposant de cette application ?

 

Le dernier paramètre est celui déterminé par le calculateur de charge. Afin d’obtenir cette information, le data collector reçoit régulièrement des rapports de charge de la part des différents serveurs de la zone. Au final, celui-ci peut déterminer une charge en % pour chaque serveur.

 

Il est possible de consulter cette charge (depuis n’importe quel citrix de la ferme) grâce à la commande QFARM /load :


La valeur obtenue doit être divisée par 100 pour obtenir une information en %. Une valeur de 20000 indique que le serveur rencontre un problème (licence, service IMA…).

Si le service IMA n’est pas démarré sur l’un des serveurs, celui-ci n’apparaitra pas dans la liste.

 

II. Les règles de calcul

La charge d’un serveur est déterminée par une règle de calculateur de charge, associée à ce serveur. L’assignation d’une règle à un serveur peut ensuite être réalisée dans la console Citrix Delivery Services, ou via des policies Citrix (selon la version de XenApp).

Remarque : Il est également possible d’associer des calculateurs de charge sur les applications. Cependant, cela complexifie énormément le calcul de charge, qui doit rester compréhensible.

 

Une règle permet d’obtenir une valeur de charge en fonction d’un ou plusieurs paramètres. Le paramétrage de base consiste à prendre en compte le nombre d’utilisateurs connectés sur le serveur. Si on ajoute plusieurs règles, l’équilibrage entre les règles est équivalent (elles ont toutes la même importance dans le calcul).

 

 

La règle ci-dessus utilise les calculs suivants :

  • Charge serveur en utilisateurs : Le nombre maximum d’utilisateurs par serveur. Ainsi s’il y a 4 utilisateurs, la charge reportée est de 10 % (1000 sous QFARM /load).
  • Optimisation de la charge : Ce paramètre définit l’impact des ouvertures de session sur la charge. Sur un nombre de serveur importants, et lorsque le processus d’ouverture de session est consommateur de ressources, cela permet des répartir les nouveaux utilisateurs sur des serveurs différents (et à charge équivalente).
    Sur des petites fermes (moins de 10 serveurs), il vaut mieux désactiver ce paramètre, sous peine de voir des ouvertures de sessions refusée chaque matin…
  • Utilisation de l’UC : Cette règle permet de prendre en compte la charge CPU dans le calcul. Une valeur élevée (90 %) indique une charge pleine.
  • Utilisation de la mémoire : Ce dernier paramètre permet de prendre en compte la charge mémoire dans le calcul. Tout comme le CPU, la charge maximale est définie à une valeur élevée.

 

III. Quels paramètres choisir ?

D’une manière générale, il faut préférer des règles simples, car elles sont souvent les plus efficaces, particulièrement sur des fermes de petites taille.

 

Sur une plateforme où tous les utilisateurs consomment des ressources identiques,  limiter le nombre d’utilisateurs connectés va permettre d’obtenir une répartition de charge efficace, et il est souvent inutile de rajouter des règles de calcul. Cela permettra d’avoir le même nombre d’utilisateurs sur chaque serveur, et de comprendre la répartition de charge.

 

Les autres paramètres peuvent être utilisés s’ils sont pertinents dans le calcul de la charge : Par exemple, si une application génère beaucoup d’IOPS disque, il sera intéressant d’ajouter une règle concernant le stockage pour répartir les utilisateurs sur les serveurs hébergeant cette application.

La charge du CPU et de la mémoire peuvent être prises en compte au cas où les utilisateurs réalisent des activités différentes, avec des applications qui ne consomment pas les mêmes ressources.

Finalement, on peut utiliser la fonction optimisation de la charge (Load Throttling) pour éviter que de nombreux utilisateurs ouvrent des sessions simultanément sur un même serveur. Il faut cependant utiliser ce paramètre seulement si le nombre de serveurs de la ferme est suffisant pour encaisser les ouvertures de session.

 

Chaque silo de serveur peut utiliser un calculateur de charge différent (selon les applications ou le sizing des serveurs), mais les serveurs identiques doivent utiliser le même calculateur de charge.

 

Pour plus d’informations sur ce sujet peuvent être trouvés sur eDocs, en choisissant votre version de XenApp, et sur l’article Load Manager Rules Explained.

 

par .

Laisser un commentaire

*