Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archive for the ‘Performance-2007’ Category

Points de Performance Exchange 2007/2010

Posted by Teruin laurent le décembre 24, 2009


 

Le but de ce document est de présenter les quelques points de contrôle de performance que vous devriez vérifier manuellement si vous n’avez pas la change d’avoir un outil de monitoring spécifique a l’environnement Microsoft Exchange 2007/2010. Ce document ne prétend pas documenter l’ensemble des compteurs fort nombreux d’ailleurs, mais mettre l’accent sur des compteurs spécifiques majeurs au sein d’exchange 2007/2010

 

Surveillance des serveurs Cas Exchange 2007 /2010

Les serveurs client Access supportent la charge de plusieurs services comme les services ActiveSync RpcOverHttp, Owa etc. Mesurer leurs charges est important, surtout en cas de lenteurs constatées, mais également lorsque vous allez, petit à petit migrer les utilisateurs vers la nouvelle plateforme. L’utilitaire de Performance propose une vaste gamme de compteurs et choisir le bon n’est pas forcement chose aisée.Le but de cette section est donc de présenter quelques indicateurs clefs qui vous permettront en un clin d’œil de visualiser la charge de vos processus.

 

Mesure de la performance OWA

 

La première étape est de vérifier dans un premier temps le nombre d’utilisateur connectés. Cette possibilité vous est offerte par le compteur :

MSExchange OWA\Utilisateurs uniques actuels.(
MSExchange OWA\Current Unique Users ) Exchange 2007/2010.
Ce compteur indique le nombre d’utilisateurs uniques actuellement connectés à OWA. Il reprend le nombre d’utilisateur connectés actuel tant que ceux ci ne ce sont pas déconnectés. Si vous avez des serveurs Cas multiples en répartition de charge IP, il est intéressant de créer plusieurs instances de ce compteur depuis un même serveur CAS de façon à mesurer effectivement si votre répartition de charge pour le processus OWA fonctionne. Une fois que vous avez pris en compte le nombre d’utilisateur connectés sur vos serveurs, il est important je pense, de mesurer si les temps d’accès aux ressources OWA sont correctes.

Pour cela Microsoft fourni un compteur intéressant :

 

MSExchange OWA\Temps moyen de réponse : Ce dernier indique le temps moyen en milliseconde qui s’est écoulé entre le début d’une demande et la fin de cette dernière. Ce compteur permet donc d’estimer la latence moyenne des requêtes clients et vous permettra d’estimer le ressenti utilisateur. Pour que cela soit correct, il faut que cette valeur soit inférieure à 100 ms de façon continue. Si cela n’est pas le cas, Examiner le nombre de connexion et la charge processeur.

 

 

Mesure de la performance ActiveSync

 

Un peu moins critique, le service ActiveSync peut également faire l’objet de mesure mais ne possède que peu de compteur en environnement 2007.

 

MSExchange ActiveSync\Durée moyenne de demande indique le temps moyen d’une demande faite au serveur via ActiveSync. Microsoft ne donne pas de valeur critique quand a ce dernier compteur. Dans le cas de plusieurs Cas, je vous conseillerais de les comparer pour vérifier d’une part la répartition de charge et d’autre part pour éventuellement détecter que ces derniers soient homogène.

 

 

Mesure de la performance disques

Les latences disques ont un effet assez direct sur la charge d’un serveur. Plus impactant sur un serveur Mailbox que sur un serveur Cas, le mauvais dimensionnement de IO disques sur un serveur Cas risque de provoquer des ralentissements généraux de l’environnement server. Moins évolué que sur les serveurs de boites aux lettres, deux compteurs existent qui permettent de mesurer la latence disques des serveurs CAS. Le premier est un compteur en lecture uniquement :

 

(LogicalDisk(_Total)\Lectures disque/s), le second en écriture (LogicalDisk(_Total)\Écritures disque/s). Dans les deux cas les valeurs observées cumulées doivent être inférieures à 50

 

Mesures de la performance du service de disponibilité.

 

Le service de disponibilité est typiquement un processus client dont une latence trop importante sera rapidement constatée par les clients Outlook. La vérification de la relative bonne santé de ce service est importante. Concernant cette mesure Microsoft fourni le compteur suivant :

 

MSExchange Availability Service\Délai de traitement moyen d’une requête de disponibilité (MSExchange Availability Service\Average Time to Process a Free Busy Request) qui indique le temps moyen de traitement d’une requête de disponibilité. Le temps est donné en seconde et doit toujours être inférieur à 5.

 

Mesure de la performance du processus ASP.NET

Les processus ASP net jouent un rôle important en tant que processus sous jacent dans l’environnement Exchange. Pour mesurer leurs exécutions correctes utiliser le compteur suivant :

ASP.NET\Durée d’attente de la requête (ASP.NET\Request Wait Time). En environnement Exchange 2007 celle-ci doit inférieure à 1000 ms. En environnement 2010 celle-ci doit être égale à 0.

Indique le nombre de millisecondes attendu par la demande la plus récente dans la file d’attente.

 

 

 

Performance de la couche transport

 

La couche transport est importante car le délai important peut se faire ressentir très rapidement par les clients de messagerie qui ont désormais come habitude de voir les messages délivrés très rapidement. A la différence d’y il a quelques années, nos chers utilisateurs s’inquiètent désormais lorsqu’il constate que les mails n’arrivent pas dans les quelques minutes qui suivent leurs envois. D’autre part, laisser « trainer » des mails en attente n’est pas bon signe car compte tenu de la volumétrie échangée, la saturation d’espace disque n’est souvent pas loin.

 

Une donnée importante à mesurer est donc la longueur des files d’attentes. Quelles files d’attentes me direz-vous. La réponse est : toute. Microsoft fourni un paramètre magique qui permet en un clin d’œil de visualiser l’état des files d’attente. Ce dernier est :

 

\Files d’attentes de MSExchangeTransport(_total)\Longueur globale des files d’attente de remise (toutes les files d’attente) (\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)). Cette dernière comme sont nom l’indique précise la longueur cumulée de toutes les files d’attente sur le serveur en question. La valeur doit être inférieure à 3000 et ne pas dépasser 5000 (Exchange 2003/2010). J’ajouterai que plus cette valeur est petite plus vos serveurs de transport sont en mesure de délivrer rapidement les messages et que aucun point de destination n’est injoignable.

 

Il existe ensuite pas mal de compteur pour toutes les files d’attentes qui en fonction de ce que vous aurez observé dans le premier compteur ci-dessus méritent d’être vérifiées. C’est le cas des files d’attentes suivantes :

 

  • Longueur des files d’attente de remise distante actives
  • Longueur des files d’attente de remise des boîtes aux lettres actives
  • Longueur de la file d’attente de soumission
  • Longueur des files d’attente de remise Non-SMTP actives
  • Longueur des files d’attente de remise des boîtes aux lettres de nouvelle tentative
  • Longueur des files d’attente de remise non-SMTP de nouvelle tentative
  • Longueur des files d’attente de remise distante de nouvelle tentative
  • Longueur des files d’attente inaccessibles
  • Longueur de la file d’attente de remise la plus grande
  • Longueur de la file d’attente de messages incohérents

 

Un compteur cependant doit attirer plus particulièrement votre attention qui est la Longueur de la file d’attente de soumission. Dans le cas ou celle-ci dépasserait 100 allez vérifier vos serveurs de boites aux lettres ainsi que la disponibilité de votre environnement Active Directory.

 

Comme pour l’ensemble des serveurs, les temps de latence disques sont importants. La surveillance des compteurs suivant en lecture écriture demeure donc nécessaire :

 

  • Disque logique/physique(*)\Moyenne disque s/lecture (Logical/Physical Disk(*)\Avg. Disk sec/Read)

 

  • Disque logique/physique(*)\Moyenne disque s/écriture (Logical/Physical Disk(*)\Avg. Disk sec/Write)

 

 

La valeur à ne pas dépasser en environnement de production est de 50 en moyenne (Exchange 2007/2010)

 

 

PERFORMANCE DES SERVEURS DE BOITES AUX LETTRES

 

La performance des serveurs de boites aux lettres est importante car la plupart des clients Outlook sont connectés dessus. Ceci est encore plus vrai si vous avez d’ancien client Outlook qui ne sont pas positionnés en mode cache. Le moindre ralentissement de l’activité de votre serveur de boites aux lettres Exchange aura pour conséquence un ressenti utilisateur.

Dans un environnement de serveur de base de données plusieurs compteurs doivent être inspectés on notera que les aspects disque, latence RPC jouent un rôle important dans le ressenti utilisateurs.

La première chose à vérifier sur un serveur de boites aux lettre en production est le nombre de client Outlook que nous avons de connectés (MSExchangeIS\Nombre d’utilisateurs). C’est important pour la suite car si peu d’utilisateur sont connecté set que vos latences RPC sont trop longues alors … il faut s’inquiéter.

 

Concernant les ressources disques et leurs surveillance, il faut séparer les disques de données contenant les bases et ceux concernant les journaux.

 

CONCERNANT LES DISQUES DE BASES DE DONNEES : vous devrez vérifier les compteurs suivants :

 

Disque logique(*)\Moyenne disque s/lecture &Disque physique(*)\Moyenne disque s/lecture

La valeur moyenne à ne pas dépasser est de 20 Ms. C’est ce seuil que vérifie notamment le produit Jetstress que vous avez ou auriez du passer sur vos volumes pour contrôler la capacité de votre matériel à supporter la charge. Le second compteur est celui en écriture

 

Disque logique(*)\Moyenne disque s/écriture & Disque physique(*)\Moyenne disque s/écriture

Dans ce cas vérifiez qu’il ne dépasse pas 100.

Dans le cas ou les valeurs constatées sont supérieures il faudra vérifier l’ensemble de la chaine de liaison de votre sous systèmes disques. A savoir les pilotes de disque (drivers HBA par exemple) , l’organisation des modules raid etc..

 

CONCERNANT LES DISQUES DE JOURNAUX vous devrez vérifier les compteurs suivants :

 

Disque logique(*)\Moyenne disque s/lecture La valeur moyenne a ne pas dépasser est de 20 Ms. C’est ce seuil que vérifie notamment le produit Jetstress que vous avez ou auriez du passer sur vos volumes pour contrôler la capacité de votre matériel à supporter la charge.

 

Disque logique(*)\Moyenne disque s/écriture

Dans ce cas vérifier qu’il ne dépasse pas 10.

 

Le second compteur clef que vous devez vérifier concerne la latence RPC de votre serveur de boites aux lettres. Ce dernier est le suivant :

 

MSExchangeIS\Latence RPC moyenne (MSExchangeIS\RPC Averaged Latency).


Il indique la latence RPC moyenne, exprimée en millisecondes, de toutes les opérations des 1 024 derniers paquets. Cette valeur doit être inférieure à 25 ms en moyenne en Exchange 2007 et 10 ms en Exchange 2010 (En moyenne)

 

Autre point de contrôle

 

Vérifier si votre serveur Exchange a assez de mémoire.

Exchange 2007 est pourvu d’un cache de base de données sans limitations connues. La consommation de la mémoire par le processus store est supérieure à l’environnement Exchange 2003. L’allocation de mémoire concernant le cache est dynamique et le moteur jet va utiliser toute la mémoire disponible du système et en redonner si besoins. Dans le cas d’un environnement serveur de 20 Go le cache de base de données va utiliser environ 18 Go et laisser environ 2Go pour le système. L’allocation dynamique de buffer va en fait faire grandir le cache en comparant les Entrées Sorties des bases de données avec les totalités des entrées sortie du système qui génère des défauts de pages matériel (voir rappel) . En gros, si le serveur Exchange génère plus d’E/S et surtout plus de défaut de pages, le cache va s’agrandir, ce qui est logique. Dans le cas contraire le cache va diminuer. Lors des opérations de maintenance, il faut également prendre en compte que lors des opérations de maintenance la mémoire nécessaire supplémentaire peut avoisiner les 4GB. Sur des serveurs en production équipés de 32 Go de mémoire vive et Windows 2008 SP2, abritant environ 4500 boites aux lettres nous avons observé ce phénomène. Entre 30 et 28 Go de mémoire allouées sur les serveurs actifs.

 

Rappel : Défaut de page (Technet): Si un processus demande une page en mémoire et ne peut pas la trouver à l’emplacement requis, un défaut de page se produit. C’est ce qu’on appelle un défaut de page matériel (ou disque). Si une page est trouvée ailleurs dans la mémoire, le défaut est appelé défaut de page logiciel (mémoire)

 


 

Pour savoir si votre serveur dispose de suffisamment de mémoire, vérifier la valeur du compteur suivant :

Mémoire\Pages de lecture/s (Memory\Page Reads/sec) : Indique que les données doivent être lues à partir du disque plutôt que de la mémoire. Indique que la mémoire est insuffisante et que la pagination commence. Une valeur supérieure à 30 par seconde signifie que le serveur ne peut plus supporter la charge. (Exchange 2007/2010)

 

Vérifier la disponibilité de votre environnement AD

Le serveur Exchange 2007/2010 va effectuer des requêtes LDAP sur les serveurs contrôleur de domaine. Si ces derniers sont trop sollicités des ralentissements ce feront ressentir.

Microsoft fourni certains compteur qui vont vous permettre de mesurer les temps de réponses de vos serveurs Active Directory vis-à-vis des demandes Exchange. Pour cela utiliser les compteurs suivants :

 

Contrôleurs de domaine MSExchange ADAccess(*)\Durée de lecture LDAP : Indique le temps, exprimé en millisecondes (ms), pour envoyer une demande de lecture LDAP au contrôleur de domaine spécifié et recevoir une réponse.

 

Contrôleurs de domaine MSExchange ADAccess(*)\Durée de recherche LDAP

Indique le temps (en ms) pour envoyer une demande de recherche LDAP et recevoir une réponse.

 

Ces valeurs doivent être inférieures à 50 ms en moyenne. Les pics (valeurs maximales) de doivent pas être supérieurs à 100 ms.

 

Bien sur il existe bon nombre de compteur à commencer par ceux de la carte réseau, mais l’objectif de l’article était d’en dégager quelque uns qui convient de surveiller plus particulièrement surtout si vous ne disposez pas d’outils de supervision tels que Scom.

 

Pour information les valeurs données pour Exchange 2010 ne sont pas encore totalement figée dans le marbre car non publiées pour l’instant mais ne devraient pas évoluer énormément.

 

Bonne fêtes
Laurent Teruin

 


 

Posted in Performance-2007, Performance-2010 | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 221 autres abonnés