Citrix XenApp Tuning, optimisation de vos serveurs Terminal Server et Citrix XenApp

Citrix XenApp Tuning, optimisation de vos serveurs Terminal Server et Citrix XenApp

Cet article a vocation à être modifié et mis à jour régulièrement dans la mesure du possible.

Dans un premier temps nous allons aborder la gestion de la mémoire en environnement SBC, il sera proposé quelques exemples d’optimisations pour la partie réseau comme système, et autres astuces concernant la performance de manière globale, de vos serveurs TS et Citrix XenApp.

La gestion de la mémoire (RAM et SWAP) est facilement la partie la plus importante de l’infra matérielle de vos serveurs « SBC » (Avec la gestion CPU/GPU). La quantité et qualité (vitesse) de RAM installée sur un serveur affecte directement les performances des autres composants du serveurs (« cpu, hdd & co.. »)

Si votre serveur n’a que 2GO et que votre serveur swap comme un fou, en ajoutant un peu de RAM il ira peut-être un peu mieux. Cela n’est pas toujours évident.

Par exemple si une application est mal codée ou pas optimisée (ce qui arrive trop rarement…joke), il est possible que celle-ci s’alloue beaucoup plus de ressources qu’elle n’a réellement besoin pour fonctionner correctement.

Afin de pouvoir identifier et optimiser les éléments qui vous empêchent de permettre à plus d’utilisateurs de pouvoir utiliser les ressources de vos serveurs TS ..RDS / Citrix XenApp xx existants, il faudra entrer un peu plus dans le détail :


  • Comprendre comment la mémoire fonctionne en environnement Windows Terminal Servers
  • Mettre en avant le fait que vous avez assez de mémoire pour faire tout ce que vous avez prévu de faire avec vos serveurs.
  • Provisionner, optimiser en fonction de la consommation réelle, pensez à la planète et soyez Green.
  • Comment estimer la mémoire dans la vraie vie. (Real-World Memory Estimation)
  • Partitionnement de vos serveurs SBC
  • Optimisations système et réseau

Avant de songer au fait que votre serveur est assez puissant pour supporter le nombre d’utilisateurs souhaité, il serait peut-être une bonne idée de cerner les possibilités réelles de vos serveurs par rapport à vos besoins existants.

La quantité de mémoire à prévoir pour le système de base est d’environ 128 Mo (pour les systèmes Windows 2003 TS).

Pour ce qu’il s’agit de vos utilisateurs consommant beaucoup de ressources (cpu / ram / accès fréquents à des fichiers sur vos disques locaux ou réseau.. etc), il faut dans un premier temps prendre en considération la consommation intrinsèque de l’application lors d’une utilisation classique, puis ne pas oublier les utilisateurs qui peuvent avoir une utilisation plus « gourmande » que d’autres.

Prenons comme exemple des utilisateurs  qui accèdent régulièrement à une application qui traite et calcule des requêtes concernant des volumes d’informations échelonnés sur un an. D’autres catégories d’utilisateurs font des calculs sur un volume de données de 5 à 10 ans régulièrement pour un besoin fonctionnel vital pour une entreprise.

Une application qui effectue des calculs peut consommer une valeur très variable de ressources en fonction de l’utilisation réelle des end users (utilisateurs finaux) et de comment celle-ci a été développée. Il peut-être parfois intéressant de pouvoir identifier et catégoriser vos « power users » afin de prévoir convenablement les montées en charges en fonction du niveau de service que vous souhaitez pour vos serveurs TS / XenApp.

Donc pour les applications comme Outlook, IE, Word, Excell, BO et bien d’autres (comme les apps Java….), il n’est pas toujours facile de donner des valeurs applicables dans tous les cas de figures, il faudra donc faire vos tests de monté en charge  (Voir Cet Article pour la partie Load Testing).

 

Optimisation mémoire en environnement SBC

Voici un récapitulatif du niveau de support concernant la RAM en fonction des différentes versions de Windows 2003 :

2003 HArdware Support

(Fixez la taille de votre SWAP,cela évite au système d’augmenter ou diminuer la taille du fichier dynamiquement)

Améliorez les performances de la mémoire Kernel de vos serveurs Windows 2003 Terminal Server :

Ce paramètre (DisablePagingExecutive) empêche le système de mettre en swap (sur le disque dur) les Drivers en mode Kernel et d’autres instructions système.

Cela peut diminuer les performances de vos serveurs si ce paramètre n’est pas appliqué correctement :

HKLM\System\CurrentControlSet\Control\SessionManager\Memory Management, valeur DWORD pour DisablePagingExecutive à 1.

* Optimisation de la taille de la mémoire paginée « Paged Pool Size ».

Windows alloue de la mémoire dans des ‘pools de mémoire’ pour le système et ses composants, ces process accèdent directement à la mémoire en mode kernel.

Deux types de pools mémoire kernel existent :

* Mémoire paginée « The paged pool memory » Qui est écrite dans le SWAP.
* Mémoire non paginée « The non-paged pool » Qui n’est pas écrite dans le Swap.

Les performances de vos serveurs Terminal Servers / XenApp, ainsi que la Stabilité peut être sérieusement impactée si Windows rencontre des limitations de mémoire et n’est pas capable d’allouer suffisamment de mémoire à ces pools.

Cette quantité de mémoire physique assignée à ces 2 pools est assignée dynamiquement lorsque le système s’initialise. La taille maximum sur des Systèmes Windows 2003 version 32 bits (x86), pour la mémoire paginée c’est de 491 MB, et 256 MB pour la mémoire non paginée. Par défaut, un serveur Windows 2003 n’alloue pas une valeur maximisée appropriée au réel besoin.

La limite architecturale effective est bien plus élevée, la quantité de mémoire paginée est limitée et lockée par défaut à une valeur qui n’est pas suffisante pour les Serveurs Windows Terminal Servers 2003 avec ou sans XenApp installé, sur lesquels il y a beaucoup d’utilisateurs.

La meilleure façon de répartir correctement la mémoire paginée (Paged Pool) et la ‘mémoire système’ (System Pages) est de paramétrer les clef de registre suivantes :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

« PagedPoolSize« =dword:ffffffff

« SystemPages« =dword:ffffffff


Activer le « Large System Cache »
:  la mise en cache des fichiers systèmes améliore les performances en réduisant le nombre d’accès nécessaires aux disques durs de vos serveurs pour les fichiers régulièrement sollicités.

HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management valeur DWORD de LargeSystemCache à 1

Rapide exemple permettant de schématiser l’allocation mémoire :

 

Voir cette présentation pour plus de détails sur la gestion de la mémoire virtuelle

Spécifie le nombre max de mémoire qui peut être lockée (réservée) pour les opérations d’entré / sortie (IO) :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Créer la valeur de type DWORD IoPageLockLimit et affecter la valeur de type (Hexadecimal) correspondante :

pour 64-128 Mo de RAM vous saisirez 1000

pour 256 Mo de RAM vous saisirez 2000

pour 512 Mo de RAM vous saisirez 4000

pour 1024+ Mo de RAM vous saisirez 10000 ..etc —> Sources : Citrix XenApp Platinum Edition Advanced Concepts

 

Forcer le Gestionnaire de mémoire à démarer l’ajustement de la mémoire avant 80 % qui est la valeur par défaut :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management
Valeur DWORD PoolUsageMaximum (Décimale) à 60

Si un seuil de 60 pour cent n’est pas suffisant pour traiter les mines d’activité, réduisez ce paramètre jusqu’à 50 ou 40 pour cent. Sources // Voir aussi le CPU et Memory Management que propose PowerFuse ..

Significations des clés de registre concernant l’optimisations de la gestion mémoire & cpu :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl
Win32PrioritySeparation (REG_DWORD)
24=Background services
26=Programs

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
LargeSystemCache (REG_DWORD)
0=Programs
1=System Cache

 Standardisation et tuning de serveurs Terminal Services

Dans des environnements extrêmement complexes et hétérogènes, il est nécessaire de garantir une homogénéité « parfaite » de vos serveurs afin de garantir un niveau de service équivalent à vos attentes. La façon la plus commune de gérer et forcer ces settings est d’utiliser les GPOs Windows appliquées lors de la phase de post-masterisation de vos serveurs. (Il est important d’avoir des scripts de vérification des configurations personnalisées pour garantir la pérennité de vos paramètres même après l’application de Patchs touchant à vos spécificités / tuning)

Il est important d’accorder une attention particulière à la mémoire, profiles utilisateurs ainsi que la partie réseau afin de permettre une expérience utilisateur optimale et fluide.

Pour ce qui concerne le choix du nombre de processeurs, veuillez lire l’article CTX114844 .

Il y a quelques paramètres qui sont fortement recommandés lorsque l’on souhaite optimiser un serveur Windows 2003 Terminal Server / XenApp :

Les optimisations proposées sur ce blog seront prochainement traduites et ajoutées à cette rubrique.

Ne pas remonter les erreurs en mode console.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows
Passez la clef ErrorMode à 2

Désactiver le « Last-Accessed Time Stamping »-> empêche le système de mettre à jour le nom de l’utilisateur ayant accédé en dernier aux fichiers.
HKLM\System\CurrentControlSet\Control\FileSystem, valeur DWORD pour NtfsDisable LastAccessUpdate à 1.

Accélérez le temps de chargement en pré-cachant les fichiers fréquemment accédés par les utilisateurs en mémoire (Explications sur le Prefetech et +) :

HKLM\System\CurrentControlSet\Control\SessionManager\Memory Management\ PrefetchParameters, valeure DWORD pour EnablePrefetcher à 3.

Désactiver la mise en cache de vos profiles itinérants :
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon, valeur DWORD pour DeleteRoamingCache à 1.

Désactiver l’indexation de ficher. Pour cela décocher l’indexation dans les propriétés de vos disques systèmes et autres disques souhaités.

Ajuster le refresh du Menu :

HKU\.DEFAULT\Control Panel\Desktop, valeur MenuShowDelay (de type REG_SZ) à 10 (source)

 

Afin d’obtenir des performances optimales il faut décorréler le SWAP sur un ou des disques dédiés (Raid 0 ou Raid 1) en dépendant du niveau de haute disponibilité souhaité.

Déplacer les profiles utilisateurs sur des disques dur dédiés sur le même principe que le SWAP.

Il est souhaitable de redémarrer vos serveurs assez régulièrement (1 fois par semaine ou toute les 2 semaines si possible). D’autres vous diront que ce n’est pas nécessaire de le faire aussi fréquemment (c’est vrai mais discutable en fonction des applications publiées sur vos serveurs et comment (SoftGrid ? AIE ? ThinApp ?.)

Pour la partie Terminal Services Licencing lisez cet article de Brian Madden.

 

Partitionnement des disques de vos Serveurs Windows 2003 Terminal Services

Pour obtenir des performances optimales et une répartition logique il faut au moins 3 partitions (ou plusieurs disques répartis sur différents contrôleurs) :

1- La « Partition Système » sur laquelle vous avez votre système et le SWAP si vous n’avez pas de disques dédiés pour ce dernier.

2- Partition prévue pour les profiles utilisateurs. (cela évite de faire imploser bêtement votre Système si bcp de profiles volumineux sont rapatriés sur la partition système.)

3- « Partition Applicative » sur laquelle vous aurez toutes les données liées aux installations de vos applications.

Optez pour une Quatrième partition pour le SWAP (ou + tôt un disque dédié), puis idéalement, isolez le répertoire Spool de vos serveurs sur un volume différent que celui choisi pour héberger votre OS (Voir CTX115139 pour les préconisations officielles)

 

 Optimisation Réseau de vos serveurs Windows 2003 TS / XenAPP

Dans la plus part des environnements SBC (Terminal Servers & Citrix XenApp) un grand nombre d’utilisateurs se connectent via des liens réseaux à latences élevées et/ou faibles débits.

Il est conseillé d’optimiser les paramètres réseaux de vos serveurs afin de rendre l’expérience utilisateur aussi fluide et transparente que possible pour les connexions depuis le WAN (il est préférable de vérifier les paramètres en fonction de vos environnements.)

Articles intéressants sur les échanges de flux réseaux dans une Infrastructure Citrix XenApp : CTX115079 , CTX115075

Nombre de retransmissions TCP

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Nombre de retransmissions TCP (pipe)

Créer la valeur DWORD TcpMaxConnectRetransmissions avec la valeur 6

Nombre de retransmissions TCP (données)

Créer la valeur DWORD TcpMaxDataRetransmissions avec la valeur a

Voir http://www.redbooks.ibm.com/redpapers/pdfs/redp3943.pdf pour plus d’infos.

Optimisation des buffers réseau

Dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Configurez les entrées suivantes (ici ce sont les valeurs conseillées sur le kb Microsoft sauf pour les deux valeures dont la source est citée à coté) :

MaxWorkItems Type de données : REG_DWORD Données de la valeur : 8196 (decimal)
MaxMpxCt Type de données : REG_DWORD Données de la valeur : 1024 (decimal) —> Sources : Citrix XenApp Platinum Edition Advanced Concepts
MaxRawWorkItems Type de données : REG_DWORD valeur : 4096 (decimal)—> Sources : Citrix XenApp Platinum Edition Advanced Concepts
MaxFreeConnections Type de données : REG_DWORD Données de la valeur : 100 (decimal)
MinFreeConnections Type de données : REG_DWORD Données de la valeur : 32 (decimal)

Dans la sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters, configurez l’entrée suivante :

Nom : MaxCmds Type de données : REG_DWORD Données de la valeur : 2048 (décimal)

 

Par défaut, votre Registre ne dispose pas de la sous-clé Configuration Manager. Pour créer la clé, recherchez la sous-clé suivante et cliquez dessus avec le bouton droit de la souris :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
Pointez sur Nouveau, puis cliquez sur Clé. Tapez Configuration Manager, puis appuyez sur ENTRÉE.

Dans la nouvelle sous-clé HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Configuration Manager, configurez l’entrée suivante :
•    Nom : RegistryLazyFlushInterval Type de données : REG_DWORD Données de la valeur : 60 (décimal)
Voir http://support.microsoft.com/kb/324446/fr pour plus d’infos.

Nous contacter pour proposer des améliorations ou signaler d’éventuelles erreurs.

Sources de cet article :  Introduction inspiré de Brian Madden, merci Julien pour les explications sur la gestion de mémoire Kernel.

Voici un Article très intéressant à visiter sur le sujet ! (à ne pas manquer…)

No Comments Yet.

Leave a reply

You must be logged in to post a comment.

Sign in
classic
Forgot password?
×
Sign up

(*) Required fields

I agree with Net2sys Consulting Terms & Privacy Policy

Security Code * Time limit is exhausted. Please reload the CAPTCHA.


×
Visit Us On YoutubeVisit Us On FacebookVisit Us On Twitter