7. Opérations de basculement

respecter les contrats de niveau de service (SLA). Pour réduire l’incidence des basculements, vous pouvez déployer des clients Outlook 2003 qui s’exécutent en mode de mise en cache, ce qui permet aux utilisateurs de travailler à partir d’un cache local si aucune connexion réseau n’est disponible. Le mode de mise en cache d’Outlook 2003 gère la perte de connectivité réseau de manière nettement plus efficace que les versions antérieures d’Outlook, lesquelles doivent être redémarrées afin de prendre en compte les changements de connectivité réseau. Le mode de mise en cache d’Outlook 2003 peut détecter si le serveur Exchange est accessible et est capable de se reconnecter et de se synchroniser de manière transparente, sans intervention de l’utilisateur.

Les délais de basculement avec Exchange 2003 sont nettement meilleurs qu’avec Exchange 2000 car Microsoft a amélioré le modèle de ressources en aplanissant l’arborescence des dépendances Exchange. La figure Web 1 (http:// www.itpro.fr, Club abonnés) présente le modèle de ressources de cluster pour Exchange 2000 ; les ressources de protocole, telles que HTTP, peuvent être mises en ligne uniquement après le démarrage de la ressource Store (Banque d’informations) Exchange. La figure Web 2 montre le modèle de ressources pour Exchange 2003 ; les ressources de protocole dépendent uniquement de la ressource System Attendant (Surveillance du système). Cette modification accélère les temps de basculement car il est possible de démarrer les ressources du cluster en parallèle. Dans Exchange 2003, Microsoft a mis en oeuvre un délai de 3 minutes au bout duquel, s’il n’y a pas eu basculement, le processus Store est arrêté. Cela permet d’accélérer le basculement et par rapport à ce que proposait Exchange 2000.

Il existe deux types de basculement : planifié et non planifié. Examinons les deux situations et voyons comment les gérer au mieux et comment la surveillance des basculements non planifiés peut améliorer votre déploiement.
Basculements planifiés. Ce type de basculement fait souvent partie des tâches de maintenance planifiées du système, par exemple lors d’une mise à jour tournante d’un Service Pack (que j’expliquerai un peu plus loin). Sur un cluster à deux noeuds, cette tâche requiert l’installation du Service Pack sur le noeud passif (noeud 2) et le redémarrage éventuel de celui-ci. Une fois la maintenance terminée sur ce noeud, vous utilisez la console Cluster Administrator pour déplacer les serveurs virtuels Exchange (EVS) du noeud actif (noeud 1) vers le noeud passif, puis vous effectuez la mise à jour sur le noeud 1. Si ce dernier est le noeud préféré du cluster, il conviendra également de restaurer les EVS sur celui-ci (opération appelée failback). Au cours du processus de basculement planifié, la DLL de ressources Exchange (exres.dll) place hors ligne les composants Exchange du groupe de cluster, elle démonte les groupes de stockage, arrête les protocoles tels que IMAP, POP et HTTP, puis place hors ligne les ressources de nom réseau et d’adresse IP d’EVS. Exres.dll place alors en ligne les ressources de nom réseau et d’adresse IP d’EVS, puis les ressources Exchange sur l’autre noeud. Cluster Service met également à jour la base de données quorum.

Vous pouvez réduire la durée du basculement planifié en effectuant cette opération en dehors des heures de travail. En effet, un serveur Exchange fortement sollicité peut en journée héberger jusqu’à 3 000 connexions MAPI, chacune devant être arrêtée pour le basculement. En dehors des heures de travail, ce nombre diminue. Le mode de mise en cache d’Outlook 2003, lequel améliore l’utilisation du réseau, peut également contribuer à réduire les délais de basculement.

Après une mise à jour par Service Pack Windows, le processus Store recrée les index, ce qui peut allonger de plusieurs minutes la durée du basculement. Celle-ci dépend de la taille de vos bases de données Exchange. L’ID d’événement 611 consigné dans le journal des événements Application indique un processus de recréation d’index en cours.

Basculements non planifiés. Ce type d’événement se produit en cas de défaillance ou de coupure d’alimentation du noeud hébergeant les EVS. Lorsque le noeud actif (noeud 1) est arrêté, Cluster Service détecte l’indisponibilité de la connexion de pulsation, et donc du noeud actif, et il bascule les ressources de nom réseau et d’adresse IP EVS sur le noeud passif (noeud 2). Les disques associés aux EVS sont placés en ligne sur le deuxième noeud. Exres.dll met les ressources de cluster Exchange en ligne. La ressource Store monte les groupes de stockage et effectue les tâches de récupération. La base de données quorum est mise à jour. Si vous avez désigné le noeud 1 en tant que propriétaire préféré du cluster, la restauration sera exécutée afin de rebasculer les EVS vers le noeud 1, dès que celui-ci sera remis en ligne. Vous ne pouvez pas faire grand-chose pour réduire la durée des basculements non planifiés. Toutefois, si vous avez désigné un noeud préféré et qu’il y a basculement du cluster, vous pouvez au moins faire en sorte que la restauration s’effectue en dehors des heures de travail. Pour définir les heures de restauration, cliquez avec le bouton droit de la souris sur Exchange Group dans la console Cluster Administrator, sélectionnez Properties, puis cliquez sur l’onglet Failback. Sélectionnez l’option Allow failback (Autoriser la restauration automatique) et spécifiez la fenêtre de restauration autorisée (sur 24 h) dans les zones de liste déroulantes de l’option Failback between __ and __ hours (Restauration entre ___ et ___). Sélectionnez une heure qui n’entre pas en conflit avec d’autres événements tels que les sauvegardes et les défragmentations de base de données en ligne. Le processus de restauration, lequel démonte et remonte les bases de données Exchange, viendrait interrompre ces tâches. Si votre cluster fait office de back-end dans votre organisation de messagerie, vous pouvez réduire le délai nécessaire aux basculements non planifiés. L’article Microsoft « How to Configure IPSec on an Exchange Server 2003 Back-End Server That Is Running on a Windows Server 2003 Server Cluster » (http://support.microsoft.com/?kbid=821839 ) décrit les procédures d’amélioration des délais de basculement non planifié pour les serveurs virtuels de back-end s’exécutant sur des clusters Windows 2003 avec Exchange 2003 et utilisant IPSec pour sécuriser le trafic entre les serveurs front-end et back-end.

Surveillance. L’un des meilleurs moyens de réduire la fréquence et la durée des basculements non planifiés consiste à surveiller et à analyser en continu les données relatives aux performances. Comme l’explique l’article « Monitoring Exchange 2000 », www.itpro.fr Club abonnés, Windows et Exchange incluent tous deux des outils de surveillance. (Pour les déploiements de production à grande échelle, une infrastructure de gestion, telle que Microsoft Operations Manager (MOM) peut simplifier la surveillance.) Avant une défaillance ou un arrêt, Windows et Exchange peuvent journaliser des événements signalant un problème matériel ou logiciel. Par exemple, le problème de fragmentation de la mémoire virtuelle, décrit dans l’article « Monitoring Virtual Memory », www.itpro.fr Club abonnés), est consigné dans le journal Application en tant qu’événement 9582. Grâce à une surveillance active des journaux d’événements, des performances disque et de l’utilisation de la mémoire, vous pouvez prévenir nombre d’arrêts, ou au moins les décaler à un moment de la journée où ils gêneront moins d’utilisateurs.