Exchange Server, gestion de la Haute disponibilité

Ainsi, la fiabilité réseau, matérielle, logicielle doit être surveillée et une redondance doit permettre la perte de n’importe lequel des composants de l’infrastructure sans perte d’accès au service. Pour la partie système, deux technologies permettent la haute disponibilité des machines et des logiciels.

Le Network Load Balancing (NLB – Répartition de charges réseau)

Indépendant de l’application, il permet la répartition de charges des clients sur la ferme de serveur en plus de la haute disponibilité.

Le Failover clustering (WSFC – Cluster de basculement)

Lié à l’application, il permet de maintenir l’intégrité des données utilisées par le logiciel en garantissant que l’accès aux disques stockant les fichiers ne se fait que par une machine à la fois.

Haute disponibilité pour le rôle CAS

Avec Exchange 2010, le CAS devient le point de connexion pour tous les protocoles MAPI, Outlook Anywhere, OWA, ActiveSync, IMAP, POP, EWS, Entourage. Il agit donc comme passerelle pour ces différents protocoles avec pourmission de mettre en forme le contenu des boites aux lettres pour les clients utilisant ces protocoles d’accès au contenu de la boîte.

La haute disponibilité du rôle CAS ne nécessite donc pas de garantir l’intégrité d’une donnée quelconque et s’implémente à l’aide du composant Network Load Balancing. Le Network Balancing est une fonctionnalité disponible nativement sous Windows Server 2008.

Il est à noter dans le cas d’une implémentation sur les mêmes serveurs d’un CAS en
haute disponibilité et d’un DAG (Haute disponibilité du rôle de boîte aux lettres), il est obligatoire d’utiliser un boiîier extérieur assurant la répartition de charges (HLB – Hardware Load Balancer) à la place du composant Windows car il est incompatible avec la fonctionnalité Windows Failover Clustering du DAG.

Il est aussi conseillé d’utiliser un système de répartition de charges matérielles dans le cas d’une ferme de plus de 8 CAS.

Haute disponibilité pour le rôle MBX (DAG)

L’une des nouveautés les plus marquantes d’Exchange Server 2010 est le DAG (Data Availability Group) qui remplace l’ensemble des mécanismes de haute disponibilité que l’on pouvait trouver sur les versions précédentes. Un DAG symbolise la réunion d’un maximum de 16 serveurs qui vont pouvoir répliquer les bases Exchange 2010 pour en assurer la haute disponibilité.

Il utilise la fonctionnalité Windows Failover Clustering de manière transparente afin de faire basculer
automatiquement les composants de l’infrastructure Exchange, sur une copie de la base en état de fonctionnement.

La mise en place du DAG n’utilisant pas d’espace disque partagé, sa mécanique de fonctionnement s’apparente à un cluster à quorum MNS (Majority NodeSet –Jeu de noeud majoritaire). Le Quorum MNS a pour charge de répliquer le Quorum qui contient la configuration du cluster sur l’ensemble des noeuds du cluster. Pour que le cluster soit en ligne, la majorité absolue des noeuds est nécessaire, si ce n’est pas le cas, l’ensemble des noeuds s’arrête. Voir tableau ci-dessous.

Afin d’éviter des clusters bloqués par un partage à égalité parfaite du cluster (coupure réseau entre les noeuds), on peut ajouter une référence supplémentaire sous la forme d’un partage de fichier sur une machine qui n’est pas membre du cluster. Ce partage contiendra un répertoire et des fichiers témoins pour le cluster et permettra d’arbitrer les conflits dans le cas d’une connectivité coupée entre les noeuds.

La mise en place du DAG est très simple car elle peut se faire sans réinstallation du serveur Exchange. Il suffit de créer le DAG dans l’organisation Exchange, d’ajouter des serveurs membres à ce DAG et de spécifier pour chaque base de données sur quel membre du DAG elles doivent être  répliquées. Le principe de réplication s’appuie sur la copie des fichiers de transaction sur l’ensemble des membres du DAG ayant un réplica de la base de données (log shipping). Les fichiers sont ensuite rejoués dans la base de données (log replay). Le contrôle de l’état de synchronisation peut se voir dans la console EMC ou dans l’interface EMS à l’aide de la commande suivante :

Get-MailboxDatabaseCopyStatus EGILIA-DataBase

Il est aussi possible, dans les paramètres de la copie d’une base sur un serveur membre du DAG, de spécifier une durée de latence avant de rejouer les logs dans la base
afin d’avoir une base décalée.

Haute disponibilité pour le rôle HT

Les rôles Hub-Transport et Edge Transport intègrent nativement des fonctionnalités de haute disponibilité par l’intermédiaire de deux technologies.

Transport Redundancy

Le principe consiste à conserver les messages sur le serveur précédent jusqu’à ce qu’il soit délivré plus loin. Lorsqu’une erreur est détectée (timeout), le serveur précédent délivre de nouveau les messages (à un autre HUB par exemple). Pour la mise en place de cette technologie, des extensions SMTP sont utilisées (XSHADOW, XDISCARD) qui génère une légère surcharge réseau et qui nécessite une chaîne de serveurs sous Exchange 2010. Par le biais du Mailbox Server resubmission, ce principe est aussi vrai si le Hub n’émet pas d’avis de réception au rôle Mailbox qui va resoumettre les messages.

Transport Dumpster

Lorsque vous utilisez la technologie du DAG, le transport dumpster reçoit les informations de la file d’attente de réplication entre les bases pour déterminer quels sont les messages qui ont été remis et répliqués. Tant qu’un message n’est pas répliqué sur l’ensemble des bases de données du DAG, un exemplaire est conservé dans la file d’attente du hubtransport qui en assure la remise par sécurité.