Exchange Server 2010

Article
08/24/2016

Garantie de la haute disponibilité dans Microsoft Exchange Server 2010

William R. Stanek

Fonctionnalités de haute disponibilité dans Exchange Server 2010
Étude des groupes de disponibilité de base de données

Les bases de données de boîtes aux lettres et les données qu'elles contiennent sont critiques pour toute organisation Exchange. Pour garantir la haute disponibilité des bases de données de boîtes aux lettres, Exchange 2007 proposait différentes options de clustering et de réplication, parmi lesquelles la réplication continue locale, les clusters à copie unique et les serveurs de boîtes aux lettres en cluster. Même si ces fonctionnalités représentaient des améliorations par rapport aux offres précédentes, elles soulevaient de nombreux défis en matière d'implémentation. Pour commencer, chaque approche de la haute disponibilité était gérée d'une manière différente. Avec les clusters à copie unique, tous les serveurs de boîtes aux lettres dans un cluster utilisaient le stockage partagé. L'implémentation du clustering signifiait que les administrateurs Exchange devaient configurer le Clustering avec basculement Windows, qui est assez complexe et requiert de nombreux efforts de la part des administrateurs afin d'obtenir un niveau élevé de temps d'activité. Avec la réplication continue, Exchange 2007 utilisait la réplication asynchrone intégrée pour créer des copies des données, puis conservait ces copies à l'aide de la copie et de la relecture des journaux de transactions. On utilisait la réplication continue locale pour créer des copies locales dans un environnement non cluster, mais la réplication continue en cluster ou la réplication continue en attente dans un environnement de cluster, et chaque type de réplication continue était géré différemment.

Exchange Server 2010 adopte une approche radicalement différente envers la haute disponibilité, car celle-ci est intégrée dans son architecture fondamentale, créant une solution de bout en bout qui procure la disponibilité de service, la disponibilité des données et la récupération automatique. Il en découle qu'une solution unique de haute disponibilité remplace les nombreuses solutions différentes utilisées auparavant. Cette solution est le groupe de disponibilité de base de données.

Les groupes de disponibilité de base de données fournissent un basculement et une récupération automatiques au niveau de la base de données (plutôt qu'au niveau du serveur) sans nécessiter de clusters lorsque vous déployez plusieurs serveurs de boîtes aux lettres avec plusieurs copies de bases de données de boîtes aux lettres. Grâce à ces modifications, la création d'une solution de serveur de boîte aux lettres à haute disponibilité ne requiert plus de matériel de cluster ni de configuration de cluster avancée. Au lieu de cela, les groupes de disponibilité de base de données constituent le composant de base pour la haute disponibilité et le basculement est automatique pour les bases de données de boîtes aux lettres qui font partie du même groupe de disponibilité de base de données. Les groupes de disponibilité de base de données peuvent être étendus à plusieurs sites Active Directory, et les modifications architecturales associées apportées aux serveurs de boîtes aux lettres permettent à une base de données de boîte aux lettres d'être déplacée d'un site Active Directory à un autre. En conséquence, une base de données de boîte aux lettres dans un site Active Directory peut basculer vers un autre site Active Directory.

Il faut se souvenir que les copies de bases de données concernent uniquement les bases de données de boîtes aux lettres. Pour la redondance et la haute disponibilité des bases de données de dossiers publics, vous devez utiliser la réplication des dossiers publics. Contrairement à la réplication continue en cluster, dans laquelle plusieurs copies d'une base de données de dossiers publics ne peuvent pas exister dans le même cluster, il est possible de répliquer des bases de données de dossiers publics entre les serveurs d'un groupe de disponibilité de base de données.

Avant de rentrer dans les détails des groupes de disponibilité de base de données, examinons les autres modifications apportées aux options de haute disponibilité dans Exchange 2010.

Visite guidée des fonctionnalités de haute disponibilité dans Exchange Server 2010

Dans les versions précédentes, Exchange assumait la fonction d'application en cluster utilisant le modèle de gestion des ressources de cluster. Avec cette approche, on implémentait la haute disponibilité pour les serveurs de boîtes aux lettres en créant tout d'abord un cluster de basculement Windows, puis en exécutant le programme d'installation d'Exchange en mode cluster. Dans le cadre du processus d'installation, la DLL de ressource de cluster d'Exchange (exres.dll) était enregistrée, ce qui autorisait la création d'un serveur de boîte aux lettres en cluster. Par contraste, Exchange 2010 ne fonctionne pas en tant qu'application cluster, et le modèle de gestion des ressources de cluster n'est plus utilisé pour la haute disponibilité. La DLL de ressource de cluster d'Exchange et toutes les ressources de cluster qu'elle fournissait n'existent plus. Au lieu de cela, Exchange 2010 utilise son propre modèle de haute disponibilité interne. Bien que certains composants du Clustering avec basculement Windows soient encore utilisés dans ce modèle, ils sont désormais gérés exclusivement par Exchange 2010.

Chose intéressante, une grande partie des technologies de réplication sous-jacentes demeurent ; elles ont simplement évolué et opère maintenant d'une manière sensiblement différente. Les groupes de stockage ayant été supprimés d'Exchange 2010, la réplication continue s'exécute au niveau de la base de données. Au lieu d'utiliser Server Message Block (SMB) pour l'amorçage et la copie des journaux de transactions, Exchange 2010 utilise un port TCP unique défini par l'administrateur pour le transfert de données. Plutôt que de faire en sorte que des copies passives extraient un fichier journal fermé d'une copie active, la copie active pousse les fichiers journaux vers les copies passives et le flux de données est sécurisé à l'aide du chiffrement ou compressé de façon à réduire la taille des données répliquées. Bien qu'il ait été possible d'utiliser une copie active d'une base de données dans les versions antérieures d'Exchange uniquement pour l'amorçage et le réamorçage, dans Exchange Server 2010 les copies actives et passives des bases de données de boîtes aux lettres peuvent être spécifiées comme sources pour l'amorçage et le réamorçage, ce qui vous permet d'ajouter facilement une copie d'une base de données à un autre serveur de boîte aux lettres.

Un autre changement important concerne la manière dont les données sont répliquées. Dans Exchange 2007, le service de réplication Microsoft Exchange relisait les journaux dans des copies de bases de données passives et créait un cache d'opérations de lecture/écriture qui servait à réduire les opérations d'E/S. Lorsque la copie passive de la base de données était activée, le cache de base de données était perdu car le service Banque d'informations Microsoft Exchange ayant monté la base de données n'avait pas ce cache à sa disposition. En conséquence, la copie passive était activée et mise à disposition dans un état à froid sans cache disponible. L'état à froid correspond à celui dans lequel le cache de base de données aurait été suite à un redémarrage du serveur ou des services effectuant la mise en cache. À cause de cet état à froid, le serveur n'avait pas d'opérations de lecture/écriture en cache, condition qui augmentait généralement le nombre d'opérations d'E/S requises jusqu'à ce que la taille du cache ait augmenté suffisamment pour réduire les E/S disque sur le serveur. Dans Exchange 2010, le service Banque d'informations Microsoft Exchange relit les journaux et gère les opérations de montage, s'assurant que le cache est disponible lorsqu'une copie passive est activée et mise à disposition. En conséquence, le serveur a davantage de chance de pouvoir utiliser le cache pour réduire les opérations d'E/S de lecture après un basculement.

Avec les serveurs de boîtes aux lettres à haute disponibilité, les messages électroniques sont en sécurité une fois arrivés dans une boîte aux lettres ; la sécurité du courrier électronique en transit, en revanche, est un tout autre problème. En cas de défaillance irrécupérable d'un serveur de transport Hub lors du traitement de messages, ceux-ci risquent d'être perdus. En guise de protection contre la perte de données, Exchange 2007 a introduit la fonctionnalité benne de transport, qui garantissait que les serveurs de transport Hub maintenaient une file d'attente des messages remis récemment aux destinataires dont les boîtes aux lettres étaient protégées par la réplication continue locale ou la réplication continue en cluster. Les messages étaient conservés dans la benne de transport jusqu'à ce qu'une limite de temps ou de taille définie par l'administrateur soit atteinte. En cas de basculement, un serveur de boîte aux lettres en cluster demandait automatiquement à chaque serveur de transport Hub du site Active Directory de resoumettre le courrier à partir de la file d'attente de benne de transport. Ce mécanisme empêchait la perte de données durant la période nécessaire au basculement du cluster. Bien qu'il fonctionne parfaitement bien, il est disponible uniquement pour la remise de messages dans un environnement de réplication continue et ne permet pas de faire face aux risques de perte de messages lorsque ceux-ci sont en transit entre le serveur de transport Hub et le serveur de transport Edge.

Exchange 2010 aborde ces problèmes de différentes manières. La benne de transport reçoit désormais des informations en retour afin de déterminer quels messages ont été remis et répliqués. Les serveurs de transport Hub maintiennent une copie des messages envoyés à une base de données de boîte aux lettres répliquée dans un groupe de disponibilité de base de données. Cette copie est conservée dans la file d'attente de transport (mail.que) jusqu'à ce que le serveur de transport Hub ait été informé de la réplication correcte des journaux de transactions représentant le message et de leur inspection par toutes les copies de la base de données de boîtes aux lettres. Les journaux sont ensuite tronqués de la benne de transport, ce qui permet de garantir que la file d'attente de benne de transport est utilisée uniquement pour maintenir les copies des messages dont les journaux de transactions n'ont pas encore été répliqués. De plus, lorsqu'une base de données de boîte aux lettres dans un site Active Directory bascule vers un autre site Active Directory, les demandes de nouvelle remise de benne de transport sont envoyées à la fois au site d'origine et au nouveau site.

Afin de fournir une redondance pour les messages durant l'intégralité de leur période de transit, Exchange 2010 ajoute la fonctionnalité de redondance cachée. Celle-ci utilise une approche semblable à la benne de transport, hormis le fait que la suppression des messages des bases de données de transport est différée jusqu'à ce que le serveur de transport ait vérifié que tous les sauts suivants pour ce message ont achevé la remise. Si le serveur de transport n'est pas en mesure de vérifier la remise du saut suivant, le message est soumis de nouveau pour la remise au saut suivant. Cette approche consomme moins de bande passante réseau que la création de copies dupliquées des messages sur plusieurs serveurs. Ici, le seul trafic réseau supplémentaire généré est l'échange de messages d'état de suppression entre les serveurs de transport. Les messages d'état de suppression sont générés par le Gestionnaire de redondance cachée et indiquent quand un message électronique est prêt à être supprimé de la base de données de transport.

La redondance cachée est une extension du service SMTP (Simple Mail Transfer Protocol) utilisée à condition que les deux serveurs de la connexion SMTP prennent en charge cette fonctionnalité. Lorsque vous avez des chemins d'accès de messages redondants dans votre topologie de routage, la redondance cachée rend n'importe quel serveur de transport supprimable en éliminant la dépendance envers l'état d'un serveur de transport Hub ou Edge spécifique. Dans ce cas, si un serveur de transport subit une défaillance ou si vous souhaitez le placer en mode hors connexion à des fins de maintenance, vous pouvez le faire à tout moment en le supprimant, en le remplaçant ou en le mettant à niveau sans avoir à vider ses files d'attente ni à vous soucier de la risque de perte de messages.

Le Gestionnaire de redondance cachée utilise une approche basée sur des pulsations afin de déterminer la disponibilité des serveurs pour lesquels des messages cachés sont en file d'attente. Le serveur initiateur émet un message XQUERYDISCARD et en réponse le serveur cible retourne des notifications de suppression. Cet échange de notification constitue la pulsation.

Si un serveur ne parvient pas à établir de connexion à un serveur principal durant l'intervalle de délai d'attente de pulsation, qui par défaut est de 300 secondes, le serveur réinitialise la minuterie et réessaie jusqu'à trois fois (valeur par défaut du nombre de nouvelles tentatives de pulsation). Si à l'issue du nombre de nouvelles tentatives un serveur principal n'a toujours pas répondu, le serveur considère que le serveur principal a subit une défaillance, et il assume la propriété des messages cachés et les resoumet. Les messages sont alors remis à leurs destinations appropriées. Dans certains scénarios, par exemple lorsque le serveur d'origine rebascule en ligne avec sa base de données d'origine, on peut constater une remise dupliquée des messages. Grâce à la fonctionnalité de détection des messages dupliqués intégrée à Exchange, les utilisateurs de boîtes aux lettres Exchange ne voient pas les messages en double. En revanche, les destinataires sur les serveurs de boîtes aux lettres non-Exchange risquent de recevoir des copies dupliquées.

Étude des groupes de disponibilité de base de données

Bien que les nombreuses améliorations en matière de haute disponibilité que j'ai décrites jusqu'à maintenant soient importantes, aucune d'entre elles n'a un impact aussi fort sur la façon dont vous gérez Exchange 2010 que les groupes de disponibilité de base de données. Les groupes de disponibilité de base de données constituent le composant de base de la haute disponibilité dans Exchange 2010. Les règles sont simples. Chaque groupe de disponibilité de base de données peut avoir jusqu'à 16 serveurs de boîtes aux lettres comme membres. Chaque serveur de boîtes aux lettres peut être membre d'un seul groupe de disponibilité de base de données et peut héberger une seule copie d'une base de données. La copie hébergée peut être active ou passive. Une copie active diffère d'une copie passive dans le sens où elle est utilisée et accédée par les utilisateurs, plutôt que hors connexion. Il est impossible de créer deux copies de la même base de données sur le même serveur. Il en découle que tout serveur appartenant à un groupe de disponibilité de base de données peut héberger une copie de toute base de données de boîtes aux lettres de tout autre serveur du groupe de disponibilité de base de données. Bien que plusieurs bases de données puissent être actives simultanément, une seule copie d'une base de données spécifique peut être active à tout moment et jusqu'à 15 copies passives de cette base de données peuvent se trouver sur d'autres serveurs dans un groupe de disponibilité de base de données.

Lorsque vous créez votre premier groupe de disponibilité de base de données dans une organisation Exchange, Exchange crée un cluster de basculement Windows, mais il n'y a aucun groupe de cluster pour Exchange et aucune ressource de stockage dans le cluster. Le groupe de disponibilité de base de données utilise uniquement les fonctionnalités de pulsation de cluster, de réseaux de cluster et de base de données de cluster des clusters de basculement Windows. La pulsation de cluster sert à détecter les défaillances. Chaque groupe de disponibilité de base de données requiert au moins un réseau pour le trafic de réplication et au moins un réseau pour le trafic MAPI et autre. La base de données de cluster contient les modifications apportées à l'état de base de données et d'autres informations importantes. À mesure que vous ajoutez d'autres serveurs au groupe de disponibilité de base de données, les serveurs sont joints au cluster sous-jacent et le modèle de quorum de cluster est modifié automatiquement selon les besoins en fonction du nombre de serveurs membres.

Le Gestionnaire actif est le composant Exchange 2010 qui fournit le modèle de ressource et les fonctionnalités de gestion de basculement. Il s'exécute sur tous les serveurs de boîtes aux lettres membres d'un groupe de disponibilité de base de données et assume la fonction de détenteur de rôle principal (Gestionnaire actif principal) ou de détenteur de rôle secondaire de secours (Gestionnaire actif de secours) d'une base de données spécifique. Le détenteur de rôle principal détermine quelles copies de bases de données seront actives et quelles copies activer. Il reçoit les notifications de modifications de topologie et réagit suite aux défaillances de serveurs. Il est également propriétaire de la ressource de quorum de cluster. Si le serveur détenant le rôle principal subit une défaillance, ce rôle passe automatiquement à un autre serveur appartenant au groupe de disponibilité de base de données, qui assume alors la propriété de la ressource de quorum de cluster.

Le serveur secondaire détecte les défaillances des bases de données locales répliquées et de la banque d'informations locale, et il envoie des notifications de défaillances au serveur principal afin d'initier un basculement. Le serveur secondaire ne détermine pas le serveur qui assume le contrôle, et il ne met pas non plus à jour l'état d'emplacement de la base de données. Ces tâches sont effectuées par le serveur principal. En cas de défaillance d'une base de données active, le Gestionnaire actif utilise un algorithme de sélection de meilleure copie afin de sélectionner une copie de base de données à activer. Cet algorithme identifie la meilleure copie de base de données à activer en fonction de l'état de la base de données, de l'état de l'index de contenu, de la longueur de la file d'attente de copie et de la longueur de la file d'attente de relecture de la copie de base de données. Si plusieurs copies de base de données remplissent les critères de sélection, la valeur de préférence d'activation est utilisée et la base de données ayant la valeur de préférence la plus faible est activée et montée.

Une fois que vous avez ajouté des serveurs à un groupe de disponibilité de base de données, les bases de données actives sur chaque serveur peuvent être répliquées sur d'autres serveurs du groupe de disponibilité de base de données et vous pouvez configurer d'autres propriétés du groupe, telles que le chiffrement réseau ou la compression réseau pour la réplication de base de données. Au sein d'un groupe de disponibilité de base de données, les journaux de transactions sont répliqués sur chaque serveur membre qui possède une copie d'une base de données de boîtes aux lettres et relus dans la copie de la base de données de boîtes aux lettres. Après avoir créé plusieurs copies de bases de données, vous pouvez utiliser Exchange Management Console et Exchange Management Shell pour contrôler et l'état de réplication et d'intégrité de vos groupes de disponibilité de base de données. Le basculement de base de données peut se produire automatiquement en cas de coupure de courant, ou vous pouvez l'initier manuellement. Durant un basculement, la copie active est démontée et une copie passive sur un autre serveur membre du groupe de disponibilité de base de données est montée et promue en copie active.

Une réelle simplification

Comme je l'ai expliqué dans cet article, Exchange 2010 procure de nombreuses améliorations en matière de disponibilité, parmi lesquelles l'intégration de fonctionnalités de haute disponibilité dans le noyau, des modifications architecturales qui améliorent la disponibilité, et bien d'autres choses encore. Parmi toutes les fonctionnalités nouvelles et modifiées, les groupes de disponibilité de base de données ont ma préférence. Ils simplifient réellement les implémentations de clusters et vous permettent de vous concentrer sur ce qui est le plus important : les données. J'espère que cet article vous aura été utile vous aura donné envie de découvrir mes nouveaux ouvrages, « Exchange Server 2010 Administrator’s Pocket Consultant », « Windows 7 Administrator's Pocket Consultant » et « Windows Server 2008 Administrator's Pocket Consultant, 2nd Edition ».

William R. Stanek (williamstanek.com) est un expert en technologie, un excellent formateur et un auteur reconnu et récompensé de plus de 100 ouvrages. Parmi ses ouvrages récents et à venir, citons « Active Directory Administrator’s Pocket Consultant », « Group Policy Administrator’s Pocket Consultant », « Windows 7 Administrator’s Pocket Consultant », « Exchange Server 2010 Administrator’s Pocket Consultant » et « Windows Server 2008 Inside Out ». Rejoignez Stanek sur Twitter à l'adresse https://twitter.com/WilliamStanek.