Une architecture 64 bits :

leur messagerie. Mais cette consolidation a introduit de nouveaux problèmes :

• Croissance des entrées/sorties par seconde (IOPS) sur les disques : Chaque utilisateur génère des IOPS lorsqu’il est connecté à sa boîte aux lettres. Cette consommation d’IOPS existait déjà sous Exchange 5.5, mais ces serveurs hébergeant largement moins de boîtes aux lettres, les problèmes liés aux IOPS n’étaient que très rares. Lors d’une consolidation sous Echange 2003 où certains serveurs peuvent héberger plus de 6000 BALs, de très nombreux problèmes de performances ont été constatés par les administrateurs. Il est aujourd’hui impensable de concevoir une architecture Exchange sans tenir compte de cette problématique.
Depuis des années, la taille des disques durs ne fait qu’augmenter. Des disques de 300 Go sont déjà disponibles et lors de la sortie d’Exchange 12, il sera possible de trouver des disques de 500 Go voir 1 To. Dans le même temps, les performances d’accès des disques durs n’ont pas connus une croissance comparable. Les disques les plus performantes peuvent aujourd’hui délivrer environ 180 IOPS. Nous arrivons à une limite de la technologie car ces derniers tournent déjà à 15000 t/min. Les disques de 300 ou 500 Go ne tourneront pas plus rapidement et n’apporteront qu’un espace supplémentaire de stockage qui ne sera pas exploitable par Exchange.
Pour bien comprendre le problème, prenons un exemple simple : Imaginez que vous disposez d’un serveur qui héberge 4000 utilisateurs dont l’utilisation génère 1 IOPS par personne. Le système disque doit donc pouvoir délivrer 4000 IOPS. Il faut environ 26 disques pour répondre à cette charge. Si nous utilisons des disques de 136 Go en RAID 10, l’espace disponible pour chaque utilisateur est au maximum de 440 Mo ce qui est déjà une taille de BAL respectable. Si nous utilisons les prochains disques disponibles de 500 Go, l’espace par utilisateur sera de 1,6 Go sans pour autant augmenter les performances d’accès.
Le seul moyen de diminuer le nombre de disques nécessaires et d’utiliser au maximum l’espace disponible est de réduire les IOPS générés par les utilisateurs. Exchange 2003 fonctionne sur un système d’exploitation 32 bits. L’espace mémoire maximum disponible pour les applications est de 3 Go. Exchange utilise une partie de cette mémoire (1 Go) pour mettre en cache (cache JET) certaines informations des utilisateurs comme les règles et les derniers messages reçus. Le cache disponible pour chaque utilisateur est faible. Il faut donc aller souvent chercher des informations sur les disques d’où un nombre d’IOPS important.

• Diminution de la mémoire disponible pour le noyau du système d’exploitation: Le noyau du système d’exploitation Windows server utilise deux zones mémoires importantes : la Page Pool (PPB) et le Non Page Pool (NPPB). Lorsque l’on configure le serveur pour allouer 3 Go de mémoire par application, on place le switch /3Go dans le fichier boot.ini. Or, en plaçant ce paramètre, on diminue la taille du PPB de 349 Mo à 249 Mo et celle du NPPB de 256 Mo à 128 Mo.

• Mémoire NPPB : Exchange utilise la partie de mémoire NPPB qui a tendance à se réduire de plus en plus. En effet, un système faisant fonctionner Exchange 2003 utilise en moyenne 70 Mo de mémoire NPPB. La mise en place d’IPSEC augmente cette utilisation de 10 Mo. Les drivers StorePort utilisés par les cartes HBA nécessaires à la connexion du serveur à un SAN consomment 5 Mo par carte HBA. Comme un serveur Exchange est souvent équipé de deux cartes HBA, la mémoire NPPB utilisée est de 90 Mo. Il ne reste donc plus que 38 Mo disponible pour les autres applications.

• Mémoire PPB : cette partie de la mémoire est celle qui pose le plus de problèmes directement liés à la consolidation. A chaque connexion RPC, un jeton est stocké par le serveur dans la mémoire PPB. La taille du jeton est liée au nombre de groupes de sécurité. Chaque groupe de sécurité occupe 45 octets. Ceci est valable jusqu’à 79 groupes, ce qui correspond à un jeton de 4 Ko. Ensuite, la mémoire est incrémentée par block de 4 Ko tous les 80 groupes (8Ko pour 80 groupes, 12 Ko pour 160 groupes, 16Ko pour 240 groupes…). Sans le mode cache, Outlook 2003 ouvre 2 sessions RPC sur le serveur utilisent Outlook 2003 en mode cache et qu’ils appartiennent à 170 groupes de sécurité (ce chiffre peut vous paraitre énorme, mais détrompez vous, c’est loin d’être un cas exceptionnel).
Les jetons pour chaque utilisateur occupent 72 Ko. Si vous avez 3000 utilisateurs qui se connectent en même temps sur le serveur Exchange, la mémoire PPB est occupée par 216 Mo alors que sa taille maximale est de 249 Mo. Or la mémoire PPB n’est pas uniquement destinée au stockage des jetons, mais également à de nombreux process. Par exemple, chaque ouverture de session Terminal Serveur, occupe 5 Ko de mémoire PPB. De plus, si vos utilisateurs installent des outils comme d’indexation comme MSN search ou autres, ces outils utilisent 2 jetons sur le serveur Exchange. De même, le client Microsoft Communicator utilise un jeton. Si nous reprenons l’exemple précédent et que maintenant, nos utilisateurs utilisent une des barres de recherche, la mémoire PPB nécessaire sera alors de 288 Ko ce qui dépasse la capacité maximale.
Dans cet exemple, le serveur Exchange sera incapable de supporter ces 3000 utilisateurs et s’arrêtera. Il est donc extrêmement important de regarder le modèle de sécurité utilisé dans votre entreprise afin de voir s’il est possible de diminuer le nombre d’appartenance à des groupes de sécurité. La visualisation de la taille occupée par les jetons peut se faire à l’aide des outils POOLMON et POOLSNAP. Le process de gestion des jetons s’appelle : TOKE.  Au jour de rédaction de cet article, les équipes de développements de Microsoft étudient des moyens pour diminuer le nombre de jetons nécessaires à Outlook.

Ces différents problèmes potentiels prouvent que les systèmes d’exploitations 32 bits sont limités lors de consolidations importantes d’Exchange. L’utilisation d’un système 64 bits permet de s’affranchir de ces limites mémoire. Par exemple, des mesures d’IOPS ont été réalisées dans les laboratoires de Microsoft. En prenant un utilisateur dont le profil génère 1 IOPS sous Exchange 2003, le même utilisateur ne génère plus que 0,3 IOPS sous Exchange 12 64 bits.

La version 64 bits d’Exchange 12 sera supportée sur les processeurs Intel Xeon 64 bits et Pentium EM64 ainsi que sur les processeurs AMD 64 bits Opteron, Athlon et Turion. Les processeurs Itanium ne seront pas supportés.

Une version 32 bits d’Exchange 12 sera également disponible mais uniquement pour des tests, formations et évaluations. Cette version 32 bits ne sera pas supportée en production.

En passant à une architecture 64 bits dont les limites mémoires sont matériellement non atteignables à ce jour, Microsoft en a profité pour modifier quelques caractéristiques de la base JET :
• Les pages mémoires passent de 4Ko à 8Ko,
• 2 milliards de fichiers de logs peuvent être créés,
• Exchange 12 supportera un maximum de 50 groupes de stockages et 50 bases avec un maximum de 5 bases pas groupe de stockage.
• Les bases ne seront constituées que d’un fichier EDB. Le fichier STM disparait. Sous Exchange 2003, le fichier STM avait été créé pour éviter une charge de conversion des messages aux formats Internet (STM) et MAPI (EDB). La puissance des processeurs 64 bits peuvent largement absorber cette charge de conversion ce qui explique la disparition de la base STM et une simplification de la structure de base de données. L’autre raison de la suppression des bases STM est que leur cohérence n’est pas vérifiée lors d’un backup utilisant VSS qui va devenir un type de sauvegarde de plus en plus courant dans l’avenir.