Complexité accrue

et l’éditeur a fait de très gros efforts pour que l’administration
des machines Exchange Server en cluster soit identique à  celle des serveurs autonomes.
(La Figure 2 montre la vue du composant logiciel enfichable Exchange System Manager
d’un cluster de quatre noeuds : elle est semblable à  celle d’un serveur autonome).
La dépendance d’Exchange 2000 par rapport à  AD simplifie cette tâche et rend très
intuitive l’administration requise. L’ajout et la suppression des utilisateurs,
la gestion du stockage et d’autres tâches administratives dans un environnement
de cluster ne diffèrent pas de ceux d’un environnement traditionnel. Les permissions
et les droits administratifs sont également les mêmes pour les organisations Exchange
2000, qu’elles soient en cluster ou non. Cependant, malgré les similitudes, plusieurs
aspects du clustering Exchange 2000 viennent compliquer l’administration des systèmes.
Administration des ressources. Les principales différences de
gestion entre les ressources concernent les services Exchange Server. L’administration
des ressources des clusters demande un apprentissage nettement plus consistant
que celle des services et des ressources de machines non clusterisées, mais la
maîtrise de cette compétence est essentielle pour mener à  bien la gestion des
applications clusterisées. Avant de déployer des clusters Exchange 2000, il faut
s’assurer que le personnel d’exploitation et de gestion des systèmes comprend
les particularités des clusters et des services Windows 2000 et comment Exchange
2000 tourne sur cette plate-forme.

Planification de la charge. Un autre problème d’administration
est la planification de la charge d’un cluster. Il existe trois stratégies de
planification de la charge de base. Je les appelle : Tous les noeuds à  charge maximale,
Noeud de secours à  charge maximale (c’est-à -dire bascule en cas d’incident N+1)
et Chargement équilibré du cluster (dont deux variantes : bascule en cascade et
distribuée). La limitation du nombre de groupes de stockage supportés par noeud
atténue un peu le problème en limitant la matrice des possibilités. La stratégie
qui va être sélectionnée dépend de plusieurs facteurs. On sélectionne, par exemple,
la stratégie Noeud de secours pour avoir simplement, à  tout moment, un noeud disponible
pour la bascule en cas d’incident. Le scénario Chargement équilibré du cluster
– la variante en cascade peut tolérer la défaillance de plusieurs noeuds – est
sélectionné pour protéger les serveurs Exchange virtuels contre les défaillances
de plusieurs noeuds. D’autres contraintes, considérations de performances, conceptions
de stockage et facteurs de gestion peuvent aussi influencer le choix. Chaque stratégie
a ses avantages et ses inconvénients. Il faut donc prendre le temps de comprendre
et de tester chacune d’elles pour déterminer celle qui convient le mieux à  un
environnement. La section sur le clustering de la documentation Exchange 2000
décrit les stratégies de planification de la charge.



Un déploiement d’Exchange 2000 doit toujours comporter une solide stratégie
de sauvegarde et de restauration



Sauvegarde et restauration. Un déploiement d’Exchange 2000 doit
toujours comporter une solide stratégie de sauvegarde et de restauration. Dans
un environnement de cluster des considérations de configuration supplémentaires
viennent s’ajouter, lorsqu’il s’agit de choisir une méthode pour répondre aux
impératifs de la haute disponibilité. La plupart de ces considérations sont le
fait de logiciels de sauvegarde sur bande ne reconnaissant pas les clusters et
concernent la possibilité d’effectuer des sauvegardes programmées pendant le fonctionnement
normal du cluster, ainsi que pendant une bascule en cas d’incident. Comme la méthode
recommandée pour Exchange Server consiste à  sauvegarder et à  restaurer en ligne
(le logiciel de sauvegarde communique avec l’IS par le biais d’une API), les scénarios
de reprise en cas d’incident, pour les clusters Exchange Server, peuvent être
plus complexes que pour les machines Exchange Server autonomes. Le fait que le
serveur soit local ou distant par rapport à  l’unité et au logiciel de sauvegarde
ajoute diverses complexités aux environnements de clusters Exchange Server. Il
faut étudier l’effet du clustering sur la solution de sauvegarde et de restauration
; des stratégies et des procédures spécifiques devront être développées, le cas
échéant, pour les machines Exchange Server en clusters, puisqu’il faut planifier
non seulement la récupération des informations de l’OS et d’Exchange Server, mais
également celle du cluster. Pour déterminer le meilleur scénario de reprise après
incident pour l’exécution d’Exchange Server sur le service Cluster, il est préférable
de consulter les éditeurs de logiciels et les constructeurs de matériels sur le
support de la sauvegarde et de la restauration pour le service Cluster associé
à  Exchange 2000.

La complexité du clustering s’accroît proportionnellement au nombre de noeuds du
cluster mais les bénéfices font de même. L’administration, l’allocation du stockage
partagé et la planification de la bascule en cas d’incident des clusters à  quatre
noeuds représentera le scénario le plus critique, mais offrira aussi le retour
sur investissement le plus élevé. Ce défi peut être relevé. Il faut pour cela,
d’une part, une compréhension approfondie du clustering Windows 2000 et d’autre
part, planifier et tester le cluster Exchange 2000 avant sa mise en service.