Utiliser Exchange 2000 dans des clusters

déployer pleinement sur un cluster.
Pendant le fonctionnement d’Exchange 2000, Windows
alloue et désalloue la mémoire virtuelle au Store, pour associer
les boîtes à  lettres et autres structures. La mémoire virtuelle
est parfois allouée en tranches contiguà«s, comme les
quelque 10 Mo de mémoire qui sont nécessaires pour monter
une base de données. Cependant, au fil du temps, il devient
difficile de fournir au Store suffisamment de mémoire
virtuelle contiguà«, parce que la mémoire se fragmente. Sur
un plan conceptuel, cette fragmentation est semblable à  celle
des disques et elle ne cause généralement pas trop de difficultés,
sauf pour les transitions d’état du cluster.
Pendant une transition d’état du cluster, celui-ci doit déplacer
les SG qui étaient actifs sur un noeud défaillant, vers un
ou plusieurs autres noeuds du cluster. Les SG sont constitués
d’ensembles de bases de données, donc le Store doit initialiser
les SG puis monter les bases de données afin que les utilisateurs
puissent accéder à  leurs boîtes à  lettres. Vous pouvez
suivre cette activité par l’event ID 1133 dans le journal
d’événements Application. Sur un cluster lourdement
chargé, le Store risque de ne pas pouvoir monter les bases de
données par manque de mémoire virtuelle contiguà« disponible,
auquel cas on verra un événement tel que event ID
2065. On est donc dans une situation où la transition d’état
du cluster se produit certes, mais le Store ne réagit pas parce
que les bases de données sont indisponibles. Ce genre de situation
ne touche que des systèmes lourdement chargés.
Mais dès lors que l’on envisage des clusters, il faut consolider
les serveurs et construire de gros systèmes à  haute résilience.
Après réception de comptes rendus de problèmes,
Microsoft a analysé la situation et constaté qu’un problème
survenait quand on fonctionnait en mode actif-actif.
Microsoft a commencé par conseiller aux clients de limiter
les modèles de clusters et de limiter
aussi le nombre de clients pris en
charge simultanément : 1 000 dans
Exchange 2000, 1 500 dans Exchange
2000 Service Pack 1 (SP1), et 1
900 dans Exchange 2000 SP3 et SP2.
Les nombres de clients que
Microsoft recommande se fondent
sur les charges MAPI (Messaging
API). Comme MAPI est le protocole
le plus fonctionnel et le plus riche,
les clients MAPI engendrent généralement
la charge de travail la plus
lourde pour Exchange. Les clients
Microsoft OWA (Outlook Web
Access) génèrent pratiquement le
même type de demande que les
clients MAPI. Toutefois, d’autres
protocoles client (IMAP4, POP3) engendrent
généralement une demande
système moindre et peuvent de ce fait moins solliciter
le serveur. Par conséquent, l’entreprise devrait pouvoir
prendre en charge plus de connexions client que le nombre
de clients que Microsoft recommande, avant que le problème
de mémoire virtuelle ne se manifeste.
Exchange 2000 SP3 possède un nouveau schéma d’allocation
de mémoire virtuelle pour le Store. Il change la manière
par laquelle Windows alloue et désalloue la mémoire. A
ce jour, l’expérience a démontré que les serveurs sous SP3
rencontrent moins de problèmes de mémoire sur des clusters
haut de gamme. Partant de ce constat, Microsoft
conseille aux possesseurs de grands clusters de passer à 
Exchange 2000 SP3 ou, mieux encore, de faire passer l’OS à 
Windows 2003 et de déployer Exchange 2003, qui gère mieux
la mémoire.
Face aux problèmes de gestion de mémoire virtuelle,
Microsoft a dû se prononcer sur les modalités de mise en
place de clusters actifs. Pour l’essentiel, Microsoft conseille
de garder un noeud passif disponible chaque fois que c’est
possible. Par conséquent, un cluster à  deux noeuds doit fonctionner
en mode actif-passif et un cluster à  quatre noeuds doit avoir trois noeuds actifs et un noeud passif.
Lorsque la charge d’un cluster augmente, la mémoire virtuelle
commence à  décliner. Exchange journalise l’event ID
9582 quand il y a moins de 30 Mo de mémoire disponible
présente, puis repère le même événement quand il n’existe
aucun bloc contigu de mémoire virtuelle supérieur à  16 Mo
dans le Store. Une fois qu’Exchange a atteint ce seuil, le cluster
peut devenir instable et cesser de répondre aux requêtes
des clients, vous contraignant à  réinitialiser. L’event ID 9582
peut aussi se manifester dans deux autres situations :

• Event ID 9582 peut suivre immédiatement un basculement
  sur un noeud passif si celui-ci a précédemment hébergé le
  même serveur virtuel. Chaque noeud maintient un processus
  store.exe souche, et les structures à  l’intérieur du processus
  ont peut-être déjà  été fragmentées, provoquant l’erreur.
  Face à  cette erreur, vous pouvez transférer le serveur
  virtuel sur un autre noeud du cluster puis redémarrer le
  serveur qui a la mémoire fragmentée. S’il n’existe pas de
  noeud passif, il faut redémarrer
  le noeud actif. Les problèmes de
  cette nature sont bien moins
  nombreux sur Exchange 2000
  SP3 ; par conséquent, il y a peu
  de risque de voir l’event ID
  9582 déclenché sauf sous une
  charge extrême.

• L’utilisation incorrecte du commutateur
  /3GB dans le fichier
  boot.ini peut générer l’event ID
  9582. Si Exchange 2003 se
  trouve sur un serveur Windows
  2003 ayant plus de 1 Go de mémoire
  physique, vous devriez
  définir le commutateur /3GB et
  son commutateur /Userva= associé
  dans le fichier boot.ini de
  telle sorte que Windows 2003
  équilibre mieux son allocation
  de ressources entre la mémoire
  en mode kernel et en mode utilisateur.
  Pour plus d’informations
  sur ces commutateurs,
  voir l’article Microsoft « XADM: Event Viewer Log Entries
  Cite Virtual-Memory Fragmentation on an Exchange 2000
  Server » (http://support.microsoft.com/ ?kbid=314736) et
  « XADM: Using the /Userva Switch on Windows 2003
  Server-Based Exchange Servers » (http://support. microsoft.
  com/ ?kbid=810371).

A noter que certains produits tierce partie, particulièrement
les vérificateurs de virus, peuvent affecter l’utilisation
de la mémoire virtuelle. L’encadré intitulé « Superviser la mémoire
virtuelle », explique comment déterminer la quantité
de mémoire virtuelle qu’un produit tierce partie utilise et
comment superviser la quantité de mémoire virtuelle disponible
dans un cluster.