Exchange your Mind

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

Archive for the ‘Performance-2010’ Category

Exchange et le Stockage – Partie 14

Posted by Anthony Costeseque le mars 25, 2013


Bonjour à tous,

Update 09/04/2013 : pour répondre à certaines remarques que j’ai pu recevoir :)

1 – Les calculs ne sont pas présents pour la partie JBOD RAID-Less : je vous renvoie à la partie 3 (calcul DB+Logs avec la feuille Excel MBX Exchange)

    2 – Les types de disques détail :

  • Enterprise (ENT)
    • Interface dual port SAS
    • 10K, 15K tours par minutes (TPM)
    • 146, 300, 400, 450, 600GB +
    • Large Form Factor (LFF) & Small Form Factor (SFF)
  • Midline (MDL)
    • SAS – dual port
    • SATA – single port
    • 7200 TPM + LFF & SFF
    • 500GB, 750GB, 1TB, 2TB +
  • Entry (ETY) – Ne convient pas pour ExchangeEntry (ETY) – Ne convient pas pour Exchange

La référence dans la plus part des déploiements est MDL SAS 7200 tr/min, on trouve toujours du DAS pensé pour le JBOD RAID-Less chez HP avec du SATA mais c’est de plus en plus rare (la différence de prix entre le SAS et le SATA est très faible)

    3 – La prise en compte des produits tiers qui ajoute de la charge : BES, etc … -> En effet il faudra adapter en fonction de la charge que vous ajouterai sur vos serveur Mailbox

    4 – Ces calculs théoriques sont à adapter en fonction de ce que vous constaterez pendant les premiers mois de pleine production, important dans le cas du JBOD RAID-Less la charge assumée pour 1 disques 540/550 utilisateurs n’est jamais de 100% (les chances que les 550 utilisateurs sollicitent simultanément leur boite mail est à peu près comme de gagner au loto (oui je sais ça arrive ! mais ça ne m’est encore jamais arrivé :/)

    5- Pour finir ce ne sont pas des règles mais des constats que j’ai pu faire pendant ces années ou j’ai déployé de l’Exchange 2010, beaucoup de composant dans l’infrastructure peuvent influencer le rendu final !

    6 – Ne jamais oublier de valider votre infrastructure avec JetStress cela permet déjà de faire ressortir les grosses anomalies qu’il pourrait y avoir dans le design coté stockage

Je vais reprendre cette série de billets sur le stockage dans Exchange 2010, et je vous propose aujourd’hui les scenarios classiques de dimensionnement que je rencontre le plus souvent.

Direct attachement interne

(DAS)

Storage Area Network

(SAN)

Direct attachement externe

(DAS)

SANS HA

AVEC HA / RAID

AVEC HA / RAID

AVEC HA / JBOD Raid-Less

50 – 100 utilisateurs

100 – 500 utilisateurs

> 500 utilisateurs

> 3000 utilisateurs

1 Copie

2 Copies

2 Copies

>= 3 Copies

Voici le résumé.

Maintenant comment le lire :

Mon expérience dans le design d’infrastructure Exchange (2010) m’a montré que dans la plupart des cas c’est le nombre d’utilisateurs (3eme ligne) qui conditionne le reste de la solution.

Même si ce n’est pas toujours le cas pour une installation inférieur à 100 Utilisateurs le HA ne sera pas pris en charge pas Exchange mais souvent par une autre solution (souvent basé sur la technologie de virtualisation qui la soutient).

Ce tableau montre aussi que pour aller vers du DAS JBOD RAID-Less il faut un nombre d’utilisateurs important pour rentabiliser le fait de devoir avoir au moins 3 Copies pour une base.

Donc ce tableau ce lit à partir du nombre de d’utilisateurs que devra supporter votre solution de messagerie pour ensuite vous montrer le scenario le plus rependu et le plus optimal en terme de cout/fonctionnalité.

Maintenant passons au détail de chaque solution :

 
 

50 – 100 utilisateurs / SANS HA – 1 Copie

Profile I/O : 0,12 IOPS

  • 100 messages (80/20)
  • 100Ko la taille moyenne d’un mail
  • 14 jours de SIR

Bonnes pratiques : Taille de 200Go maximum

Disques de 2To 7200 tr/min

RAID Obligatoire

RAID 1 (1+1)

RAID 5 (2+1)

Building block

En partant du stockage je peux soutenir au maximum 65 IOPS sur un disque de 2To SATA 7200 tr/min mais il ne faut pas oublier la pénalité en écriture.

Maximum IOPS database
65 / (0,6+(2×0,4)) = 46,43 disons 46 IOPS pour du RAID 1

(65×2) / (0,6+(4×0,4)) = 59,09 disons 59 IOPS pour du RAID 5

Nombre maximum d’utilisateurs

(65 / (0,6+(2×0,4))) / (0,12x(1+20%)) = 322,42 disons 322 utilisateurs en RAID 1

((65×2) / (0,6+(4×0,4))) / (0,12x(1+20%)) = 410,35 disons 410 utilisateurs en RAID 5

Bilan (SANS HA)

Type de disque

Niveau de RAID

Pénalité

Nombre d’IOPS supporté

Nombre d’utilisateurs

Quota

Nombre d’utilisateurs par base de 200Go

Nombre de bases nécessaire

Licence Exchange nécessaire

2To
7200 trm

RAID 1 (1+1)

2

46

322

1Go

120

3

standard

2To
7200 trm

RAID 1 (1+1)

2

46

322

2Go

68

5

standard

2To
7200 trm

RAID 5 (2+1)

4

59

410

1Go

120

4

standard

2To
7200 trm

RAID 5 (2+1)

4

59

410

2Go

68

7

enterprise

 
 

100 – 500 utilisateurs / AVEC HA – 2 Copies

Serveurs MBX : 2 minimums

Licences Windows Entreprise (pour supporter le cluster MSCS utilisé par le DAG)

Bonnes pratiques : Taille de 200Go à 2To pour une base de données

profile I/O qui passe de 0,12 à 0,1

Nombre maximum d’utilisateurs

(65 / (0,6+(2×0,4))) / (0,1x(1+20%)) = 386,90 disons 386 utilisateurs en RAID 1

    (contre 322 SANS HA)

((65×2) / (0,6+(4×0,4))) / (0,1x(1+20%)) = 492,42 disons 492 utilisateurs en RAID 5

    (contre 410 SANS HA)

Bilan (Avec HA) (Sur chaque serveur)

Type de disque

Niveau de RAID

Pénalité

Nombre d’IOPS supporté

Nombre d’utilisateurs

Quota maximum

Nombre de bases nécessaire

Licence Exchange nécessaire

2To
7200 trm

RAID 1 (1+1)

2

46

386

2,5Go

1

standard

2To
7200 trm

RAID 5 (2+1)

4

59

492

3Go

2

standard

 
 

> 500 utilisateurs / AVEC HA – 2 Copies / Version SAN


Cache intelligent

Introduction d’une gestion du cache intelligente permettant de minimiser au maximum la pénalité RAID


Base de référence pour vos réflexions :

Exchange 2010 Solution Reviewed Program (ESRP) – Storage v3.0

http://technet.microsoft.com/en-us/exchange/ff182054.aspx

 
 

> 3000 utilisateurs / avec HA – 3 Copies / Version JBOD RAID-Less

Introduction du JBOD RAID-Less (DAS)

Minimum 3 copies (1 active + 2 passives)

Model : 1 LUN pour la base de données et ses logs = 1 disque


Recommandation

Une large variété de type de stockages sont supportés pour Exchange 2010. Toutefois, le mode RAID-less 3 copies ou plus est la recommandation des équipes produits et du consulting Microsoft, donc validé par le support Microsoft dans les revues de supportabilité.

Concernant le taux de panne des disques SATA/SAS 7200tr/min et donc un éventuel cout d’exploitation caché, les équipes produits Exchange ont mené des tests particulièrement avancés avec les principaux constructeurs (HP, Dell, IBM, etc…)

En mode JBOD RAID-Less le « Annual Disk Failure Rate » (AFR) n’excède pas 5%.

Les constructeurs annoncent des résultats identiques et basent leurs prévisions d’intervention et remplacement de disques sur ces métriques.

Pour rappel, la maintenance des disques couvre le remplacement en 4 heures en 24X7.

3 Copies ou 4 ?

La réponse simple est 4, tout simplement car si vous avez 4 serveurs MBX reparties entre 2 salles et que la salle ou vous avez 2 copies crash complètement, vous avez une copie survivante active sur la salle 2.

Maintenant la salle revient et les synchro des copies commencent, si la salle 2 crash pendant la copie il ne reste plus rien de consistant il faut donc repartir du dernier backup !

2 copies sur chaque salle (4 au total) permettent de s’affranchir de ce scenario.

Building block

En partant du stockage je peux soutenir au maximum 65 IOPS sur un disque de 2To SATA 7200 tr/min ici aucune pénalité.

Maximum IOPS database
65 / (0,6+(1×0,4)) = 65 IOPS

Nombre maximum d’utilisateurs

(65 / (0,6+(1×0,4))) / (0,1x(1+20%)) = 540 utilisateurs

Quotas

Je suis clairement limité par les IOPS donc il ne reste plus qu’à maximiser l’espace disponible.

Je peux donc proposer comme quotas :

1,7Go maximum

Avantages/Inconvénients

SAN / RAID

  •     Compliqué à implémenter
  •     Prévoir des disques de Hot Spare (1 / 30 disques)
  •     Besoin de connaissances pour le maintien et l’administration
  •     Couteux (infrastructure Fibre Chanel)

DAS / JBOD RAID-Less

  •     Simple d’implémentation
  •     Pas de besoins de connaissances en SAN
  •     Pas de notion de Hot Spare
  •     Moins couteux (infrastructure SAS/SATA)

 
 

Bonne lecture à tous,

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE

Posted in Exchange Server 2010, Installation-2010, Performance-2010, Stockage-2010 | 1 Comment »

RDM or not RDM

Posted by Anthony Costeseque le juin 29, 2012


Là est la question !

Bonjour à tous,

La question qui revient régulièrement lorsque l’on parle de vitaliser Exchange 2010 et que le choix se porte sur l’hyperviseur de VMware vSphere, c’est quelle enveloppe utiliser pour le stockage.

RDM : Raw Device Mapping (accès direct au stockage présenté)

OU

VMFS : un Datastore formaté avec le système de fichier propriétaire de VMware, le VMFS (celui contiendra des fichiers à plat de disque dur de type .vmdk)

Détruisons tout de suite le mythe qui remonte à VMware 3.5 et précédant ! Et qui est incrusté dans l’inconscient collectif ;)

Il n’y a plus de différences de performances entre VMFS et RDM, vous ne gagnerez pas en performance en utilisant du RDM !

(Le gain ne sera absolument pas perceptible !)

Maintenant faisons une comparaison entre les deux :

RDM :

  • Mapper 1 LUN vers 1 virtual machine, donc nous avons une isolation des I/O
  • En fonction du nombre de LUNs necessaires, la limite des 256 LUNs sera rapidement atteinte !
  • Permet d’utiliser les outils de backup/réplication fournie par la baie de stockage reposant sur Volume Shadow Copy Service (VSS)
  • Support pour les disques partagés en cluster
  • Support pour l’utilisation avec VMware Site Recovery Manager
  • Support de volumes jusqu’à 64TB (RDM en mode physique)

VMFS :

  • Solution préférée, utilise tous les avantages des fonctionnalités liées au stockage présente (elle celles futures)
  • Un volume (Datastore) peut contenir plusieurs VMs (ou être dédié à une VM)
  • Augmente l’utilisation du stockage, fourni une meilleur flexibilité, une administration et un management plus simple
  • Non supporté pour les disques partagés en cluster
  • Support pour l’utilisation avec VMware Site Recovery Manager
  • Disque virtuel .vmdk limité à 2TB

 

Bilan : VMFS recommandé :)

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE

Posted in 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 13

Posted by Anthony Costeseque le juin 11, 2012


Bonjour à tous,

Nous avons vu dans la Partie 11 comment faire sur EMC² VNX

Nous avons vu dans la Partie 12 comment faire sur Hitachi (HDS) !

Aujourd’hui nous allons voir comment déployer au mieux (best practices) votre solution exchange 2010 sur NetApp.

  1. Commençons par le commencement le type de la baie !

Il est évident que le model sera conditionné par la taille de votre future infrastructure : Le nombre d’utilisateurs et la taille des boîtes aux lettres étant les principaux facteurs.

Chez NetApp nous parlerons de Fabric-Attached Storage (FAS).

Le standard sera un FAS3210 et pour les déploiements plus importants on passera sur un FAS3240 (le plus important étant le nombre maximum de disque supporté)

FAS3210 : 240 disks

FAS3240 : 600 disks

FAS3270 : 960 disks


Un exemple d’implémentation (ici un FAS3210 HA pair (2 Contrôleurs : FAS3210-1 / FAS3210-2))

Pour ce type de configuration et pour éviter toute mauvaise surprise je vous conseille d’ajouter 1 carte « Flash Cache » de 256GB sur chaque contrôleur :)

Prenons un exemple de design de solution pour 6000 utilisateurs :

L’idée ici est d’avoir 2 serveurs MBX (3000 utilisateurs par serveur) en DAG

    Sur chaque serveur 4 DBs actives / 4 DBs passives

    Sur chaque DB : 750 users avec 2GB de quota

    Total dans le DAG 8 DBs Actives / 8 DBs Passives

Pour séparer les domaines de risques nous mettons toutes les DBs actives dans 2 Aggregats sur le contrôleur 1 et toutes les DBs passives dans 2 aggregats sur le contrôleur 2

  1. Ensuite vient le type de disque

Le FAS supportent FC/SAS/NL-SAS/SATA

Nous l’avons vu dans les précédents billets, Exchange est optimisé du côté des IO permettant l’utilisation de disque 7200tr/m donc la règle est la suivante :

Faible IOs requis et large capacité de boîtes aux lettres (2Go) -> On utilisera du NL-SAS (ou encore du SATA) 7200 tr/m

Important IOs requis et faible capacité de boites aux lettres (<1Go) -> On utilisera du SAS 10000 tr/m voir 15000 tr/m (si besoin)

Jusqu’à maintenant j’ai toujours vu du NL-SAS 7200 tr/m de 2To ou 1To.

  1. Puis le type de RAID (bien lire le concept de NetApp)

Attention cette étape est très importante.

Concept : Sur les FAS nous utiliserons des « Aggregats » composé de RAID Group en RAID DP (Dual Parity (RAID 6 sauf que disques de partités fixes))

On provisionnera dans les Aggregats des FlexVol lesquelles contiendront des LUNs (sous forme de fichiers plats) (Data ONTAP étant File non Block)

Pour les RAID Group nous n’avons pas le choix c’est du RAID-DP


Avec un schéma ça aide :)

Découpage :


Nous utilisons des disques SATA 1TB 7,2K

Pour les DB Actives sur le contrôleur 1

    aggr1 (RAID Group de 14 disques (RAID-DP (12+2)) : 5 premier FlexVol (4 pour les DBs & 1 pour les logs de ces 4 DBs)

    aggr2 (RAID Group de 14 disques (RAID-DP (12+2)) : 5 FlexVol suivant (4 pour les DBs & 1 pour les logs de ces 4 DBs)

On fait la même chose sur le contrôleur 2 pour les DB Passives

Ici nous avons bien une séparation de domaine de Risques pour les DBs et Logs.

Database LUN Size : 1650GB

Logs LUN Size : 100GB

  1. Le type de connexion

Stockage « intelligent » donc SAN en FC ou iSCSI.

Je vous recommande du FC pour les 16Gb/s de bande passante (4 ports FC de 4Gb/s en (2 par contrôleur))
ainsi que la faible latence !

L’iSCSI est bien aussi mais demande tout de même des switch dédiés pour le trafic stockage (optimisés iSCSI si possible) mais le problème vient surtout de la bande passante disponible ! De façon classique nous avons 2Gb/s (2 ports Ethernet de 1Gb/s en roud robin) qui peuvent vite représenter un goulot d’étranglement sur des infrastructures importantes ! (rappelez-vous le background database maintenance (BDM) et son besoin en bande passante !). Les ports iSCSI 10Gb/s existent pour les VNX et peuvent représenter une alternative intéressante mais vos switch Ethernet devront les supporter !

Si vous pensez mettre en place une infrastructure FCoE (10Gb) alors pas de problèmes du moment que toute la chaine est prévue pour ! (switch Nexus etc).

  1. Enfin les recommandations générales
  • Utiliser des FlexVol dédiés pour vos Databases
  • Utiliser des FlexVol dédiés pour vos logs
  • NetApp recommande d’avoir 10% d’espace dispo dans les FlexVol
  • Utiliser SnapDrive pour provisionner vos LUNs :p cela sera plus simple que de le faire à la main !
  • Faire bien attention au nombre d’axe par aggregat (dans notre exemple on utilise des 1To si on passait sur des 2To cela diviserait par 2 le nombre d’axe et la solution de ne serait plus du tout possible (pas assez de nombre d’IOPS pour soutenir la charge))

Reference : Document NetApp TR-3824.pdf

Pour toutes questions n’hésitez pas !

Bonne lecture :)

La prochaine fois nous parlerons de HP.

Anthony COSTESEQUE

Posted in 1-EXCHANGE 2010, Exchange 2010 SP2, Performance-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 12

Posted by Anthony Costeseque le mai 25, 2012


Bonjour à tous,

Apres une longue absence :/ en ce moment (c’est en permanence en fait) mais particulièrement ces 4 derniers mois, le planning était très chaud.

Mais reprenons là où nous avions arrêté, comment déployer au mieux (best practices) votre solution exchange 2010 en fonction des différents constructeurs.

Nous avons vu dans la Partie 11 comment faire EMC² (ce post sera complété dans un proche avenir suite aux différentes annonces faites à l’EMC² Word 2012 qui c’est déroulé cette semaine à Las Vegas).

Nous allons voir aujourd’hui Hitachi (HDS) !

  1. Commençons par le commencement le type de la baie !

Il est évident que le model sera conditionné par la taille de votre future infrastructure : Le nombre d’utilisateurs et la taille des boîtes aux lettres étant les principaux facteurs.

Chez Hitachi (HDS) nous parlerons maintenant de Hitachi Unified Storage 100 Family (HUS (nouvelle baie unifiées)).

Le standard sera une HUS130 et pour les déploiements plus importants on passera sur un HUS150 (le plus important étant le nombre maximum de disque supporté)

HUS110 : 120 disks

HUS130 : 252 disks

HUS150 : 960 disks

En règle générale sur un déploiement d’au moins 10000 utilisateurs on a souvent 2 salles (voir 2 sites) pour la Haute Disponibilité et donc 2 HUS130 font parfaitement l’affaire.


Un exemple d’implémentation (ici sur des HUS 150 mais sur des HUS 130 c’est très bien aussi)

Prenons un exemple de design de solution pour 8000 utilisateurs

  1. Ensuite vient le type de disque

Les HUS supportent SAS/NL-SAS

Nous l’avons vu dans les précédents billets, Exchange est optimisé du côté des IO permettant l’utilisation de disque 7200tr/m donc la règle est la suivante :

Faible IOs requis et large capacité de boîtes aux lettres (2Go) -> On utilisera du NL-SAS (ou encore du SATA) 7200 tr/m

Important IOs requis et faible capacité de boites aux lettres (<1Go) -> On utilisera du SAS 10000 tr/m voir 15000 tr/m (si besoin)

Jusqu’à maintenant j’ai toujours vu du NL-SAS 7200 tr/m de 2To.

  1. Puis le type de RAID (bien lire le concept d’Hitachi)

Attention cette étape est très importante.

Concept : Sur les HUS nous utiliserons « Hitachi Dynamic Provisioning » qui s’appuie sur l’utilisation de Pools (Dynamic Provisioning Pool (DP Pool)) constitués de plusieurs RAID Group.

On provisionnera dans ces DP Pools des Dynamic Provisioning Virtual Volumes (DP-VOLs)

Pour les RAID Group nous utiliserons du RAID 1/0 (2+2) (striping + mirroring)


Avec Schéma ça aide :)

Découpage :


Ici nous avons bien une séparation de domaine de Risques pour les DBs et Logs.

Nous créerons donc 2 Dynamic Provisioning Pools (DP Pools) :

  • DB Pool avec 7 RAID Group 1/0 (2+2)
  • Logs Pool avec 2 RAID Group 1/0 (2+2)

A partir du DB Pool nous créerons 8 Dynamic Provisioning Virtual Volumes (DP-VOLs) de 1200GB chacun pour contenir les 8 DB requises (1000 utilisateurs par DBs)

A partir du Logs Pool nous créerons 8 Dynamic Provisioning Virtual Volumes (DP-VOLs) de 120GB chacun pour contenir les 8 espaces de Logs requis (pour les 8 DBs)

  1. Le type de connexion

Stockage « intelligent » donc pas de DAS que du SAN en FC ou iSCSI.

Je vous recommande du FC pour les 8Gb/s de bande passante (2 ports FC de 4Gb/s en roud robin)
ainsi que la faible latence !

L’iSCSI est bien aussi mais demande tout de même des switch dédiés pour le trafic stockage (optimisés iSCSI si possible) mais le problème vient surtout de la bande passante disponible ! De façon classique nous avons 2Gb/s (2 ports Ethernet de 1Gb/s en roud robin) qui peuvent vite représenter un goulot d’étranglement sur des infrastructures importantes ! (rappelez-vous le background database maintenance (BDM) et son besoin en bande passante !). Les ports iSCSI 10Gb/s existent pour les VNX et peuvent représenter une alternative intéressante mais vos switch Ethernet devront les supporter !

Si vous pensez mettre en place une infrastructure FCoE (10Gb) alors pas de problèmes du moment que toute la chaine est prévue pour ! (switch Nexus etc).

  1. Enfin les recommandations générales

Si votre baie est multi usage (pas uniquement Exchange) :

  • Au moment du formatage de votre LU, mettre l’ALU à 64KB pour les DB et 4KB pour les Logs
  • Pas de problèmes d’alignement des disques avec Windows 2008 R2 (aligné à 1MB)
  • Eviter de mixer les Workload d’Exchange avec d’autres applications (dans les 2 DP Pools que nous avons créé dans notre exemple)
  • Utiliser Hitachi Dynamic Link Manager pour la partie MultiPathing (éviter le soft de multipathing natif à l’OS)
  • Utiliser Hitachi Dynamic Provisioning (HDP) comme nous l’avons vu dans notre exemple
  • Due à la différence des paterns d’IO pour les DB et Logs, séparer les DBs des Logs en utilisant plusieurs DP Pools (comme vu dans notre exemple)
  • Vous pouvez utiliser du RAID-5 ou du RAID-10 pour les DBs et Logs, mais l’utilisation du RAID-10 apporte une pénalité en écriture moindre et des temps de réponses meilleurs ! (et en plus une reconstruction de disque suite à remplacement de disque HS plus rapide !)
  • Les Logs LU doivent être d’au moins 10% la taille du LU des DBs (mais peut être supérieur en fonction du nombre de jours de retentions que vous souhaitez (attention si vous utilisez des Lagged Databases))
  • L’utilisation de LU concaténées n’est pas recommandé
  • L’utilisation des DAGs avec au moins 2 DBs (1 active et 1 passive) est recommandée (pas besoin de mécanisme au niveau du stockage pour la résilience)
  • Isoler la copie active de la copie passive soit entre plusieurs HDP soit entre 2 ou + baies (le cas dans notre exemple (2 baies))
  • Utiliser des LUs plus grande pour réduire le nombre de DBs (Maximum recommandé 2TB pour les DBs)

Pour toutes questions n’hésitez pas !

Bonne lecture :)

La prochaine fois nous parlerons de NetApp.

Anthony COSTESEQUE

Posted in 1-EXCHANGE 2010, Exchange 2010 SP2, Performance-2010, Stockage-2010 | 3 Comments »

Exchange et le Stockage – Partie 11

Posted by Anthony Costeseque le décembre 4, 2011


Bonjour,

Dans la prochaine série de billet sur le stockage dans Exchange, nous verrons les bonnes pratiques chez chaque constructeur de stockage « intelligent ».

Et nous allons commencer aujourd’hui avec EMC².

Chacun d’entre vous pourra trouver les repères dont il a besoin en fonction du constructeur avec qui il travaillera :)

Par conséquent nous n’expliquerons pas ce qui se passe derrière chaque concept (nom technique) des technologies propres à chaque constructeur.

Pour toute questions ou point qui ne vous ne semblerez pas clair n’hésitez pas à laisser des commentaires.

  1. Commençons par le commencement le type de la baie !

Il est évident que le model sera conditionné par la taille de votre future infrastructure : Le nombre d’utilisateurs et la taille des boîtes aux lettres étant les principaux facteurs.

Chez EMC² nous parlerons maintenant de VNX (nouvelle baie unifiées (Block & File)).

Le standard sera une VNX5300 et pour les déploiements plus importants on passera sur un VNX5500 (le plus important étant le nombre maximum de disque supporté)

VNX5300 : 125 disks

VNX5500 : 250 disks

VNX5700 : 500 disks

En règle générale sur un déploiement d’au moins 10000 utilisateurs on a souvent 2 salles (voir 2 sites) pour la Haute Disponibilité et donc 2 VNX5300 font parfaitement l’affaire.

  1. Ensuite vient le type de disque

Les VNX supportent FC/SAS/NL-SAS/SATA/Flash(SSD)

Nous l’avons vu dans les précédents billets, Exchange est optimisé du côté des IO permettant l’utilisation de disque 7200tr/m donc la règle est la suivante :

Faible IOs requis et large capacité de boîtes aux lettres (2Go) -> On utilisera du NL-SAS (ou encore du SATA) 7200 tr/m

Important IOs requis et faible capacité de boites aux lettres (<1Go) -> On utilisera du FC ou du SAS 10000 tr/m voir 15000 tr/m (si besoin)

Jusqu’à maintenant j’ai toujours vu du NL-SAS 7200 tr/m de 2To pour les déploiements que j’ai fait.

Je ne parle pas ici de Flash(SSD) nous en parlerons plus tard :)

  1. Puis le type de RAID

Attention cette étape est très importante.

Sur les VNX nous pouvons choisir entre RAID 1/0 (striping + mirroring), RAID 5 (striping + parity), and RAID 6 (striping + double parity), une fois de plus dans les précédents billets nous en avons déjà parlé (performance/pénalité RAID/Ratio Data utile/Data parité/etc)

Nous choisirons dans 95% des cas du RAID 10 pour éviter une pénalité RAID forte en écriture et fournir les IOs nécessaires pour soutenir les bases de données ainsi que les logs !

  1. Le type de connexion

Stockage « intelligent » donc pas de DAS que du SAN en FC ou iSCSI.

Je vous recommande du FC pour les 8Gb/s de bande passante (2 ports FC de 4Gb/s en roud robin)
ainsi que la faible latence !

L’iSCSI est bien aussi mais demande tout de même des switch dédiés pour le trafic stockage (optimisés iSCSI si possible) mais le problème vient surtout de la bande passante disponible ! De façon classique nous avons 2Gb/s (2 ports Ethernet de 1Gb/s en roud robin) qui peuvent vite représenter un goulot d’étranglement sur des infrastructures importantes ! (rappelez-vous le background database maintenance (BDM) et son besoin en bande passante !). Les ports iSCSI 10Gb/s existent pour les VNX et peuvent représenter une alternative intéressante mais vos switch Ethernet devront les supporter !

Si vous pensez mettre en place une infrastructure FCoE (10Gb) alors pas de problèmes du moment que toute la chaine est prévue pour ! (switch Nexus etc).

  1. Enfin les recommandations générales

Si votre baie est multi usage (pas uniquement Exchange) :

  • Taille des pages du cache 8KB
  • Utiliser un set de disques uniquement pour exchange (pas de mix avec des luns pour d’autres applications)
  • Commencer par vérifier les IOs nécessaires avant la capacité nécessaire
  • Si vous n’utilisez pas de système de réplication, ne placer pas une database et ses logs sur le même set de disques !
    • Le but ici sera de placer des databases avec les logs d’autre databases (de façon croisée)
  • Si vous utiliser un DAG ou autre système de réplication (non recommandé) vous pouvez mettre database et ses logs sur le même set de disques
  • Attention rappel ! sans DAG vous ne pouvez pas utiliser de bases > à 200Go
  • Les copies des databases dans le DAG ne doivent pas être sur le même set de disques (pour une même base)
  • Bien repartir la charge sur les Storage Processor des baies
  • Windows NTFS file système formaté en taille d’unité d’allocation de 64KB
  • Si RAID 5 est utilisé, ne pas utiliser de metaLUNs sur plusieurs RAID Group !!

Si votre baie est à usage unique pour Exchange :

  • Taille des pages du cache 16KB
  • Le reste pareil
  1. Un exemple de découpage


10000 utilisateurs à 1,5Go de boîte aux lettres (principe de séparation des bases de données et des logs)

  1. Considérations particulière VNX

Parlons un peu du Flash (SSD), EMC² utilise le Flash avec 2 concepts : FAST Cache & FAST VP

Est-ce que FAST Cache améliore les performances pour Exchange 2010 ?

Et bien non ! FAST Cache n’a pas d’impacts sur Exchange (ni bonne ni mauvaise)

Si vous voulez tout de même l’utiliser, activer le uniquement sur les LUNs des bases de données (pas sur les logs).

De plus ça n’aidera pas sur le passage des tests Jetstress ! :p

Et maintenant est ce que FAST VP a un intérêt pour Exchange ?

Et bien non aussi ! Et même qu’ici il a un mauvais effet sur la technologie ! tout cela à cause de background database maintenance (BDM) (encore lui ;) ) qui fausse les statiques pour le déplacement des chunk de 1Go dans le pool.

Donc à éviter !!

Est-ce que les Thin LUNs peuvent être utilisées ?

Ce n’est pas recommandé pour le moment (les thin LUN ne sont pas recommandés lorsque l’on recherche des performances !)

Si vous voulez des informations sur le design dans des baies VMAX ou encore VPLEX, envoyez moi un mail.

Documents de références disponibles sur PowerLink :

h8127-deployment-exchange-unified-wp.pdf

h8888-Exchange2010-EMC-storage-best-practices-wp.pdf

h8849-VNX5300-20Kusers-Exchange2010.pdf

Bonne lecture

Anthony COSTESEQUE

Posted in Exchange 2010 Service Pack 1, Exchange Server 2010, Performance-2010, Stockage-2010 | 1 Comment »

Exchange et le Stockage – Partie 10

Posted by Anthony Costeseque le novembre 20, 2011


Bonjour,

Déjà 10 parties ! Ça passe vite !! Si ce sujet (le stockage et Exchange) vous intéresse n’hésitez pas à laisser des commentaires (vous pouvez me proposer des thèmes que vous souhaiteriez approfondir).

Exchange et le Stockage – Partie 1

Exchange et le Stockage – Partie 2

Exchange et le Stockage – Partie 3

Exchange et le Stockage – Partie 4

Exchange et le Stockage – Partie 5

Exchange et le Stockage – Partie 6

Exchange et le Stockage – Partie 7

Exchange et le Stockage – Partie 8

Exchange et le Stockage – Partie 9

Nous allons parler aujourd’hui de « background database maintenance (BDM) ou encore Checksumming (contrôle de parité) ».

Mais quelle est donc cette fonctionnalité ? Pour les personnes qui font du design coté stockage pour les bases de données, ce terme n’est pas inconnu il est présent dans la feuille de calcul au niveau des résultats de l’onglet « Role Requirements » tout en bas …


Si on fait un tour sur Technet on trouve sur cette page http://technet.microsoft.com/fr-fr/library/ee832791.aspx on trouve la définition de la fonctionnalité :

Les E/S de maintenance de la base de données en arrière-plan sont des E/S de fichier de bases de données séquentielles associées au contrôle de parité des copies de base de données actives et passives. La maintenance de base de données en arrière-plan présente les caractéristiques suivantes :

  • Sur les bases de données actives, elle peut être configurée pour s’exécuter 24 × 7 ou pendant la fenêtre de maintenance en ligne. La maintenance de base de données en arrière-plan (contrôle de parité) s’exécute sur les copies de base de données passives 24 × 7. Pour en savoir plus, voir « Analyse de bases de données en ligne » dans la rubrique Nouvelles fonctionnalités de banque d’informations principales dans Exchange.
  • Lit environ 5 Mo par seconde pour chaque base de données à analyse active (copies actives et passives). Les E/S sont séquentielles à 100 %, ce qui permet au sous-système de stockage de traiter les E/S de manière efficace.
  • Arrête d’analyser la base de données si le contrôle de parité s’effectue en moins de 24 heures.
  • Émet un événement d’avertissement si l’analyse ne se termine pas dans un délai de 3 jours (non configurable).

L’analyse de base de données en ligne (également appelée Contrôle de parité de la base de données) a également été modifiée. Dans Exchange 2007 Service Pack 1 (SP1), vous pouviez utiliser la moitié du délai de défragmentation en ligne pour ce processus d’analyse de base de données (pour s’assurer qu’Exchange lisait chaque page de votre base de données dans un délai donné afin de détecter toute corruption). Cette E/S est séquentielle à 100 % (et donc facile sur le disque) et revient sur la plupart des systèmes à un taux de parité d’environ 5 mégaoctets (Mo)/s.

Dans Exchange 2010, l’analyse de base de données en ligne contrôle simplement la parité de la base de données et exécute des opérations de blocage de banque Exchange 2010. L’espace peut être perdu en raison des blocages, l’analyse de base de données en ligne recherche et récupère l’espace perdu. Le système présent dans Exchange 2010 est conçu en considérant que chaque base de données est intégralement analysée une fois tous les trois jours. Un événement d’avertissement est déclenché si les bases de données ne sont pas analysées. Dans Exchange 2010, il existe désormais deux nœuds pour exécuter l’analyse de base de données en ligne sur les copies de base de données actives :

  • Exécuter en tant que dernière tâche dans le processus de maintenance de la base de données de boîtes aux lettres. Vous pouvez configurer la durée d’exécution en modifiant la planification de la maintenance de la base de données de boîtes aux lettres. Cette option fonctionne mieux pour les plus petites bases de données dont la taille ne dépasse pas 1 téraoctet (To).
  • Exécuter en arrière-plan 24h/24 et 7j/7, comportement par défaut. Cette option fonctionne bien pour les bases de données volumineuses, jusqu’à 2 To, où vous avez besoin de plus de temps pour contrôler la parité des bases de données. Exchange analyse la base de données une seule fois par jour et déclenche un événement d’avertissement si l’analyse ne se termine pas dans un délai de sept jours.

Vous pouvez configurer l’analyse de la base de données en ligne afin qu’elle ne s’exécute pas 24h/24 et 7j/7 en désactivant la case à cocher (si vous ne voulez pas de surcharge d’E/S pendant une période de pointe). Dans ce cas, la dernière partie de la fenêtre d’analyse de la base de données en ligne sert à contrôler la parité de la base de données et à récupérer l’espace perdu.

Pour plus d’informations sur la configuration de la maintenance de base de données, consultez la rubrique Gérer des bases de données de boîtes aux lettres.

 

Que faut-il retenir ? Et bien :

  1. Le process peut être ajusté (la plage d’exécution) sur les bases de données actives.
  2. Le process ne peut pas être ajusté sur les bases de données passives !!
  3. Ce sont uniquement des IOs séquentielles en lecture d’une taille supérieure à ceux des bases de données ! ils font 256KB contre 32KB pour les databases.
  4. Chaque base (active ou passive) doit être intégralement vérifiée tous les 3 jours
  5. Il faut compter 5MB/s par bases de données dans les calculs de bande passante entre les serveurs et le stockage
  6. On en déduit que plus les bases sont grandes plus on réduit le nombre de bases et donc moins on est touché par le background database maintenance !
  7. Si on est pas en mode HA pour utiliser des bases de 2To on est obligé d’utiliser des bases de 200Go max, on voit vite que le nombre de bases va augmenter et donc on sera beaucoup plus touché par le background database maintenance !!

 

Passons à un exemple, dans mon billet Partie 9 nous avons vu un design pour 22000 utilisateurs.

En version JBOD RAID-Less nous avions calculé 40 bases de données actives et 120 bases de données passives pour un total de 160 bases de données (sur 4 serveurs)

Le calcul est simple … 160*5=800MB/s ce n’est pas négligeable … !! Vous voyez maintenant l’importance de cette fonctionnalité en termes de charge !

Pour être sur que tout le monde voit bien, on parle ici de MB, Mega Byte, pas de Mega bite ! En Mb cela nous donne environ 8000Mb/s (soit environ 8Gb/s).

Maintenant je pense que tout le monde se pose des questions ;) comment est-ce possible ?

Tout d’abord il faut ramener le ration à « par serveur » donc /4, ce qui nous donne 200MB/s soit environ 2Gb/s

Dans notre scenario JBOD RAID-Less nous aurions pu utiliser des baies de stockage HP MDS600 en attachement SAS 6Gb/s.

Un serveur est double attaché (à un switch SAS) à 1 MDS600 donc il a potentiellement 2x6Gb/s soit 12Gb/s de bande passante possible.

Donc tout va bien :) nous avons 4 serveurs avec chacun 1 MDS600 donc la charge est supportée ! (nous sommes en attachement directe SAS (l’idée du JBOD RAID-Less))

Maintenant passons à la version RAID ! Nous avions calculé 28 bases de données actives et 28 bases de données passives pour un total de 56 bases de données (sur 4 serveurs)

Le calcul reste le même 56*5=280MB/s soit environ 2800Mb/s (environ 2,8Gb/s)

Ramenons le à « par serveur » donc /4, nous avons par serveur 70MB/s donc environ 700Mb/s à soutenir.

Nos serveurs sont double attachés en fibre à des switch FC, en règle général les équipements fibres sont en 4Gb/s (le 8Gb/ est chère et moins rependu) nous avons donc 2x4Gb/s soit 8Gb/s de disponible.

Jusqu’ici tout va bien on soutien largement la charge ! Mais attention, en règle générale dans ce type de configuration, nous ne ciblons qu’une seul baie de stockage ! Souvent reliée à 2 fabric SAN par 4 fibres 4Gb/s (2 Chemins par fabric).

Donc nos 4 serveurs vont charger les 4 ports de la baie. Si vous avez bien designez votre infra (bien reparti les LUN sur les 2 contrôleurs, etc) les 2,8Gb/s ne vous poserons pas de problèmes !

 

Vous ferez donc plus attention à l’avenir lors de vos design sur la partie bande passante à soutenir :p

Pour toutes questions n’hésitez pas !

Bon calculs :)

Anthony COSTESEQUE

Posted in Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 2 Comments »

Exchange et le Stockage – Partie 8

Posted by Anthony Costeseque le octobre 9, 2011


Les précédents billets sur le stockage dans Exchange :

Exchange et le Stockage – Partie 1

Exchange et le Stockage – Partie 2

Exchange et le Stockage – Partie 3

Exchange et le Stockage – Partie 4

Exchange et le Stockage – Partie 5

Exchange et le Stockage – Partie 6

Exchange et le Stockage – Partie 7

 

Comment Microsoft fait pour supporter plus d’un billion d’emails par jour ?

C’est que nous allons voir aujourd’hui.

 

Le 22 septembre Chris Jones SVP Windows Live écrit un billet sur "A petabyte per week"

http://windowsteamblog.com/windows_live/b/windowslive/archive/2011/09/22/a-petabyte-per-week.aspx

Décrivant les changements qui vont se mettre en place chez Microsoft autour du stockage de la messagerie Hotmail.

 

Historiquement Hotmail repose sur du RAID, à l’heure ou Microsoft prône le JBOD/RAID-Less avec Exchange 2010 il était temps qu’ils montrent l’exemple :)

 

On quitte le RAID


 

Jusqu’à maintenant un mail d’un utilisateur se trouve sur plusieurs RAID Group, ce qui permet dans le cas de la perte d’une grappe complète (pire scenario) de ne pas perdre ce mail.

Cela était intéressant jusqu’à l’arrivé des disques de grande capacité (supérieur à 1To).

 

On passe au JBOD (Just a Bunch of Disks)


L’unité n’est plus la LUN (Logical Unit) compose de X Disques mais le disque.

Les problèmes doivent maintenant être traité par le software, là ou avant c’était le contrôleur qui s’en chargé.

Sur tout du côté des erreurs sur les disques qui corrompt les données ! Avec du RAID, grâce à la parité (sur du RAID5 par exemple) la donnée peut être reconstruite. Sans RAID il faut que la partie software soit captable de corriger ce type de problèmes.

Tout comme Exchange 2010 le code pour Hotmail scan en permanence les disques pour vérifier qu’il n’y a pas de corruptions et le cas échéant, les corrige.

Maintenant que l’intelligence est dans le software, à tout moment on sait combien de copie d’un mail sont disponibles, s’il est trop faible des copies sont créées ailleurs, etc.

Il y a aussi la partie metadata du mail (l’état lu/non lu, classement dans un répertoire, etc) qui sont-elles stockées séparément du mail.

 

Le problème du JBOD se situe surtout sur la rapidité et le nombre d’actions (IOPS) dont il est capable.

Dans le contexte d’Hotmail cela représente un vrai goulot d’étranglement !

D’out l’ajout d’une partie SSD (Solid State Drive) ou encore Flash Storage pour limiter cette effet.

Etant donnée le prix de ces disques encore très élevé, ils ne servent qu’à aider et ne peuvent remplacer le JBOD.

 

En fait ce qui représente le plus de charge sur les disques sont la metadata lié aux mails ! L’état d’un mail lu / non lu, son classement dans les répertoires, les conversations (position des mails dans une conversation), synchronisation des téléphones mobiles, etc

Ces données représentent une quantité minime par rapport aux mails eux-mêmes.

 

Le but sera donc de mettre les metadatas sur du SSD et les mails sur du JBOD.

 


La migration a déjà commencé, il y a environ 30 Millions de personnes sur le JBOD et 100 Millions qui vont être migrées dans les prochains mois.

 

Anthony COSTESEQUE.

Posted in 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 3 Comments »

Exchange 2010: BPA Warning “Current processor speed is less than the maximum possible speed”

Posted by Teruin laurent le octobre 4, 2011


Lorsque vous utilisez l’Exchange Best Practice Analyser vous aurez peut-être le message d’erreur suivant « "Current processor speed on server mrsexc01.fqdn is less than the maximum possible speed. Maximum clock speed is 2533. Current clock speed is 1595"

Ceci provient du fait que votre environnement est fait pour faire des économies d’énergies. Pour supprimer ce warning positionnez High Performance dans les options comme le montre la figure suivante. Cependant … ce n’est pas très Green ;-))


Cordialement

Laurent Teruin

Posted in 1-EXCHANGE 2010, Performance-2010 | Leave a Comment »

Exchange et le Stockage – Partie 6

Posted by Anthony Costeseque le août 21, 2011


Aujourd’hui nous allons aller plus loin sur les I/Os dans Exchange 2010.

Nous avons dit qu’une application avait un profil de charge (workload) défini par :

I/O size (La taille des requêtes I/O)

Access pattern (Sequential ou Random ou encore entre les deux)

Footprint (La quantité totale de données disponible accédée dans le disque)

Command type (Read ou Write ou encore les deux)

 

Nous avons déjà vu la partie Command type (Read ou Write ou encore les deux)

Database : 60% Read / 40% Write

Logs : 50% Read / 50% Write

 

La partie Footprint depend de beaucoup de facteurs, ce n’est pas le but de ce billet.

 

La partie Access pattern (Sequential ou Random ou encore entre les deux) est intéressante :

Avec exchange 2010 les I/O séquentiels ont été augmenté grâce à de nouvelles fonctionnalités comme la défragmentation Online et les scans des databases Online.

Toutes les données sont stockées dans les bases de données qui sont constituées de B-trees, qui sont à leur tour composées de pages (la plus petite unité).

Ces pages sont défragmentées en ligne régulièrement, ce qui permet de réaliser des lectures séquentielles plus longues !

 

Et maintenant le plus intéressant, l’I/O size (La taille des requêtes I/O)

Nous avons définie dans la Partie 1, ce qu’est un I/O

Un I/O correspond à la plus petite quantité de données transférées depuis ou vers une application.

Sa taille peut être de 8/16/32/64/128/256KB

Et nous venons de voir plus haut que la plus petite unité dans une base de données est la "page".

Nous pouvons donc en déduire la taille de nos I/O pour les bases de données Exchange 2010 :

1 I/O = 1 page = 32Ko

Cette taille a été augmentée dans la version 2010 pour améliorer les performances.

Pour historique :

En 2003 la taille d’un page été de 4Ko

En 2007 la taille est passée à 8Ko

 

Donc dans Exchange 2010 la lecture ou l’écriture de données dans une base de données se fait par morceau de 32Ko.

 

Pour toutes questions n’hésitez pas.

Anthony COSTESEQUE.

Posted in 1-EXCHANGE 2010, Exchange 2010 Service Pack 1, Performance-2010, Stockage-2010 | 1 Comment »

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 223 autres abonnés