> Tech > Exchange 2000 sur Datacenter

Exchange 2000 sur Datacenter

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Lorsqu'on déploie Exchange 2000 Enterprise Server sur Datacenter, il faut passer à  Exchange 2000 Enterprise Server SP1 pour obtenir un support complet de la part de Microsoft. Avec quel bonheur Exchange 2000 Enterprise Server SP1 tire-t-il parti de chacune des principales fonctions de Datacenter ?

SMP à  32 voies. Microsoft

Exchange 2000 sur Datacenter

et des OEM ont testé Exchange 2000 Enterprise Server SP1 et il fonctionnera sur un système SMP à  32 voies certifié Datacenter. (Pour plus d’informations sur la certification Datacenter, voir le site Web de Microsoft à  l’adresse http://www.microsoft.com/windows2000/upgrade/compat/certified.asp.) Toutefois, les premiers tests indiquent qu’Exchange 2000 n’évolue bien que jusqu’à  un maximum de huit processeurs dans la plupart des cas. En utilisant des objets de contrôle de processus et l’affinité processeur pour régler une implémentation, certains OEM ont pu pousser Exchange 2000 jusqu’à  12 processeurs. Par conséquent, SP1 n’aide pas à  bénéficier de la capacité de Datacenter à  évoluer jusqu’à  32 CPU, parce que SP1 ne modifie en rien l’incapacité d’Exchange 2000 à  dépasser convenablement 8 CPU.

Les OEM envisagent de recommander le partitionnement matériel (une autre fonction Datacenter) à  ceux de leurs clients qui veulent porter Exchange 2000 sur des systèmes de plus de 8 processeurs. Compte tenu des contraintes d’Exchange 2000 et du retour sur investissement (ROI), je préconise une stratégie « scale-out » plutôt que « scale-up » – un système à  32 processeurs est plus coûteux qu’un à  8 processeurs. Pour obtenir le coût total de possession (TCO) le plus bas avec Exchange 2000, le meilleur moyen consiste à  déployer plusieurs systèmes à  8 processeurs (c’est-à -dire, à  pratiquer le « scaling out ») plutôt qu’un nombre inférieur de systèmes 32 processeurs (« scaling up »).

Jusqu’à  64 Go de RAM. Exchange 2000 Enterprise Server SP1 fonctionnera sur des machines de type PAE. Toutefois, Exchange 2000 n’adresse aucun appel aux API WE pour utiliser la mémoire virtuelle au-delà  d’un espace d’adressage de 4 Go.

En reproduisant le comportement d’Exchange 2000 sur Win2K AS, Exchange 2000 Enterprise Server SP1 sur un système Datacenter peut utiliser le switch /3GB en boot.ini pour allouer 3 Go de RAM à  l’usage d’Exchange Application et 1 Go pour l’OS. (Cette fonction existait d’abord dans Exchange Server 5.5 fonctionnant sous Windows NT 4.0, Enterprise Edition.) Cependant, par défaut, Exchange 2000 n’utilisera pas plus d’un Go environ, à  moins que vous ne modifiiez le paramétrage des registres, parce que la cache de base de données STORE d’Exchange 2000 n’allouera que 900 Mo – moins qu’Exchange Server 5.5, qui pourrait allouer la presque totalité des 3 Go au bénéfice de l’application. Je conseille d’utiliser le switch /3GB PAE pour tous les systèmes Exchange Server qui ont 1 Go de RAM ou plus. Ce switch étend simplement l’espace d’adressage des processus applicatifs à  3 Go à  partir des 2 Go par défaut de Win2K et de NT. Ce switch réduit également l’espace d’adressage de l’OS à  1 Go.

Toutefois, si l’on utilise le switch /3GB sur des machines de type PAE, toutes les applications de type PAE et AWE sur le système sont limitées aux 16 premiers Go de mémoire physique adressable, et donc elles ne peuvent pas bénéficier du support de 64 Go de RAM. (Si cette limitation n’affecte pas Exchange, elle touche toute autre application de type PAE comme Microsoft SQL Server, s’exécutant sur l’Exchange 2000 Server.)

Pour qu’Exchange 2000 puisse prendre en charge un vaste espace mémoire, il aurait fallu réécrire profondément l’architecture. Il est probable qu’une telle réécriture attendra la prochaine release d’Exchange 2000, quand l’application devra prendre en charge des OS et des applications à  64 bits.

Objets de contrôle de processus. Exchange 2000 Enterprise Server SP1 passera les tests d’objets de contrôle de processus requis et s’exécutera sur un système qualifié pour de tels objets. (Ces tests déterminent si une application pourra fonctionner sur une machine capable de gérer des objets de contrôle de processus, et pas si l’application utilise de tels objets.) Microsoft n’a pas testé en profondeur Exchange 2000 avec les fonctions objets de contrôle de processus de Datacenter.

Comme je l’ai déjà  indiqué, certains OEM ont utilisé des objets de contrôle de processus pour accroître l’évolutivité des processeurs, mais ce surcroît d’évolutivité ne doit rien aux possibilités d’Exchange 2000. C’est plutôt parce que les objets de contrôle de processus permettent de jouer avec de nombreuses parties de l’OS. Les gains de performances d’Exchange 2000 dus à  l’apport des objets de contrôle de processus ont été strictement manuels et n’ont apporté aucune amélioration majeure à  l’application.

Winsock Direct. Exchange 2000 Enterprise Server SP1 fonctionnera sur des systèmes Datacenter configurés pour utiliser Winsock Direct. Bien qu’Exchange 2000 puisse bénéficier des performances de Winsock Direct dans des configurations SAN, Microsoft n’envisage pas pour l’instant d’effectuer des tests de benchmark. En outre, Exchange 2000 ne tire pas directement parti de l’API Winsock Direct. Une interface haute vitesse pour accélérer la communication de processus distants pourrait bénéficier à  une communication de serveur frontal et d’arrière-plan avec des configurations d’Exchange 2000 multi-niveaux (multi-tier). Toutefois, Microsoft et les OEM Datacenter n’ont pas effectué de tests pour déterminer si la prise en compte de Winsock Direct par Datacenter se traduira par des gains de performances dans Exchange 2000 Enterprise Server SP1 sur Datacenter.

Clustering à  4 noeuds. Exchange 2000 Enterprise Server SP1 bénéficiera du clustering actif/actif à  4 noeuds sur Datacenter. (Il faut donc prendre en compte plusieurs considérations sur la configuration clustering pendant la planification des clusters. Pour plus d’informations sur ces considérations, voir l’article « Clustering Exchange 2000, Part 1 », décembre 2000 et « Clustering Exchange 2000, Part 2 », janvier 2001.) Bien qu’Exchange 2000 Enterprise Server SP1 tire vraiment parti du support du clustering à  4 noeuds de Datacenter, ce support présente certaines lacunes.

Exchange 2000 SP1 doit franchir quelques obstacles avant que les clusters Datacenter et les configurations OEM puissent le supporter. Tout d’abord, Exchange 2000 n’a pas reçu un logo Datacenter. Il faut pour cela que les applications d’ISV (Independent Software Vendors), y compris Microsoft, se soumettent à  une batterie de tests menée par une société tierce, VeriTest. Au moment de l’impression de cet article, cette opération devrait avoir été effectuée pour Exchange 2000 SP1.

Ensuite, les OEM doivent passer le HCT (Hardware Comptability Test) de Win2K Datacenter, le HCT du cluster à  4 noeuds et le HCT de l’application. Toute application qui a des composants en mode kernel (le driver ExIFC.sys d’Exchange 2000 est un composant en mode kernel) doit aussi être certifiée par un OEM. Une fois ces obstacles franchis par un OEM et par Exchange 2000, l’OEM peut assurer les déploiements de Datacenter et d’Exchange 2000 SP1.

En raison de l’architecture et de la mise en oeuvre du clustering Exchange 2000 (par l’intermédiaire de serveurs virtuels ayant des SG (groupes de stockage) avec des bases de données), la crainte de problèmes de failover a conduit Microsoft à  ne recommander que des configurations n+1 pour le clustering Exchange 2000. (n+1 signifie que le cluster contient n noeuds actifs pour un noeud en attente (standby)). Les testeurs de Microsoft ne recommandent que des configurations n+1 parce qu’elles ont toujours un noeud inactif qui a beaucoup de mémoire virtuelle et pas de serveur virtuel en activité. Exchange 2000 Enterprise Server SP1 renforce les limitations de support de cluster en n’autorisant pas de configurations illégales ou en n’installant pas sur des configurations de cluster existantes qui transgressent les règles de configuration.

Je réfute les recommandations de Microsoft pour plusieurs raisons. On peut fort bien gérer l’allocation de mémoire virtuelle en limitant les serveurs virtuels et les SG par noeud ; un modèle de failover de serveur virtuel distribué peut aussi atténuer les problèmes d’allocation et le retour sur investissement (ROI) pour n+1 configurations est très bas et annule une grande partie des avantages tirés du regroupement des serveurs. Toutefois, Microsoft a limité le support sur le clustering pour une bonne raison – faire du clustering Exchange 2000 une solution plus fiable pour les clients. De ce point de vue, je suis d’accord avec les recommandations de Microsoft.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT