Exchange Server 2003 : Cluster

La préparation et la configuration du matériel et du logiciel pour des clusters sont
plus complexes que pour des serveurs standard. Les clusters présentent généralement des NIC multiples. Il faut au
moins un NIC pour le réseau public et
un NIC pour la « pulsation » du cluster :
le signal réseau entre des noeuds pour
leur dire que le cluster est opérationnel.
Les clusters utilisent le stockage
partagé au lieu de lecteurs directement
connectés, parce que les services exigent
que l’on puisse déplacer
des données entre des noeuds
quand des problèmes surviennent
– et les services ne
peuvent pas déplacer les données
si celles-ci sont cantonnées
à  un serveur donné.
Gérer des clusters et gérer
des serveurs standard n’est
pas la même chose. Au lieu de
contrôler l’ensemble de services
pour Exchange ou
d’autres applications par l’intermédiaire
de la console
Computer Management, on
les gère par l’intermédiaire de
la console Cluster Administrator,
illustrée figure 1. Dans
c e t e x e m p l e , C l u s t e r
Administrator montre un ensemble
de services Exchange fonctionnant
sur un cluster. La console montre
les ressources supplémentaires qui se
combinent pour constituer un serveur
v i r tuel Exchange, comme l e s
disques, l’adresse IP et le nom du réseau.
Le concept de serveur virtuel est
crucial pour les clusters. Exchange
fonctionne sur un cluster comme un
ou plusieurs serveurs virtuels.
Chacun d’eux représente l’ensemble
des ressources (disques, un nom de réseau,
the Store, par exemple) dont
Exchange a besoin pour offrir des services
aux utilisateurs. Les serveurs virtuels
Exchange fonctionnent sur des
noeuds physiques dans le cluster. Les
serveurs virtuels gèrent les données
dans des stockages de type boîte à 
lettres et public, rassemblés dans des
SG (storage groups). Un SG est l’unité
de stockage de base pour les clusters
Exchange. Si un noeud physique est défaillant
et si le cluster doit déplacer du
travail à  l’intérieur du cluster, celui-ci
distribue les SG à  partir du serveur défaillant
vers les autres noeuds, plutôt
que de déplacer les stockages individuels.
Après le basculement, les SG
sont sous le contrôle du serveur virtuel
Exchange fonctionnant sur ce noeud
physique.
Une fois que l’on connaît les
concepts de base des clusters et la manière
dont Exchange y évolue, il faut
bien admettre que tous les composants
Exchange ne peuvent pas fonctionner
sur un cluster. Pour une raison
simple : dans certains cas, le composant
Exchange est ancien et ne peut
s’accommoder que d’un serveur standard.
Comme le composant est ancien
et peut-être pas nécessaire à  la majorité
des installations Exchange,
Microsoft n’a jamais mis à  niveau le
composant pour qu’il puisse prendre
en charge les clusters. Dans d’autres
cas, le composant n’est utilisé que
dans des cas bien précis (par exemple,
pour l’interopérabilité) entre des serveurs
Exchange 2000 et Exchange 5.5),
donc ce composant n’a pas besoin de
prendre en charge des clusters à  long
terme. Le tableau 1 donne la liste des
composants Exchange facultatifs et le
degré de support du cluster correspondant.
Par le passé, certains ISV (Independent
Software Vendors) ne prenaient
pas en charge les clusters parce
qu’ils préféraient se concentrer sur un
marché plus vaste : le logiciel de support
pour les serveurs Exchange standard.
Le manque de logiciel additionnel
pour les serveurs Exchange en
cluster posait un problème si les entreprises
voulaient déployer les mêmes
logiciels antivirus, antispam et de sauvegarde
et connecteurs de messagerie
sur les serveurs standard et en cluster.
Heureusement, cette situation s’est
beaucoup améliorée depuis la première
apparition d’Exchange 2000. Il
existe désormais un choix raisonnable
d’add-ons pour des serveurs en cluster.