SOMMAIRE

Introduction.
Réplication continue.
Quorum pour les groupes de disponibilité.
Disponibilité réseau.
Pré-requis

Mise en oeuvre.
Conclusion.
Sources.

INTRODUCTION

Un groupe de disponibilité de base de données (DAG) est le composant de base de la haute disponibilité du serveur de boîtes aux lettres et de l’infrastructure de résilience de site intégrée à Microsoft Exchange Server. Les groupes de disponibilité de base de données sous Microsoft Exchange 2013 sont très similaires à ceux de Microsoft Exchange 2010, mais offrent en plus une série d'améliorations et de nouvelles fonctionnalités aux administrateurs. Dans cet article, je vous propose de découvrir une vue d'ensemble des concepts du groupe de disponibilité de base de données, montrer comment déployer un nouveau groupe de disponibilité de base de données et effectuer certaines des tâches opérationnelles associées à l'exécution et à la maintenance d'un DAG.

Un groupe de disponibilité de base de données comprend jusqu'à 16 serveurs de boîtes aux lettres Microsoft Exchange 2013 et éventuellement un ou plusieurs autres serveurs non Exchange supplémentaires qui peuvent être utilisé afin d’agir en tant que témoins de partage de fichiers.
Les serveurs de boîtes aux lettres d'un DAG sont capables d'héberger une copie d'une base de données de boîtes aux lettres d'un autre membre du DAG jusqu'à la limite maximale que propose Microsoft Exchange 2013 à savoir, 100 bases de données de boîtes aux lettres par serveur. Cela qui inclut les copies de bases de données actives et passives. Un exemple simple d'un groupe de disponibilité de base de données serait le suivant :

Image 001

Schéma de la réplication de la base de données.

Dans l'exemple ci-dessus, le serveur MBX1 héberge la copie active de la base de données DB1 et les autres membres du DAG (MBX2 et MBX3) hébergent des copies passives de cette même base de données. Les membres du DAG travaillent ensemble afin de maintenir la disponibilité de la base de données de boîtes aux lettres.

Si le serveur qui héberge la copie de base de données active rencontre un problème, par exemple une défaillance matérielle, l'un des membres DAG restants, est en mesure de rendre sa copie de la base de données active afin que les clients puissent toujours se connecter à leurs données de boîte aux lettres.

Image 002

Schéma avec serveur ayant une défaillance.

Un serveur de boîtes aux lettres membre d'un DAG peut héberger un mélange de copies de base de données actives et passives pour lesquelles il participe à la réplication.

Image 003

Dans l'exemple ci-dessus, un DAG avec trois membres et trois bases de données de boîtes aux lettres, est affiché avec les copies de base de données actives réparties uniformément entre les membres DAG disponibles.

Retour au sommaire

REPLICATION CONTINUE

Chaque membre du DAG hébergeant une copie d'une base de données de boîtes aux lettres participe à un processus de réplication continue pour maintenir la cohérence des copies. La réplication de la base de données se produit entre les membres DAG d'Exchange Server 2013 en utilisant deux méthodes différentes :

Réplication en mode fichier
Chaque journal des transactions est entièrement écrit (un fichier journal de 1 Mo), puis copié du membre DAG hébergeant la copie de base de données active vers chaque membre DAG qui héberge une copie de base de données passive de cette même base de données. Les autres membres du DAG rejouent ensuite le fichier journal des transactions dans leur propre copie passive de la base de données pour le mettre à jour.

La réplication en mode fichier présente un inconvénient évident en ce sens qu'un journal des transactions qui n'a pas déjà été copié vers les autres membres DAG peut être perdu si le membre DAG hébergeant la copie de base de données active devient indisponible. Bien qu'il existe d'autres mécanismes de récupération pour minimiser l'impact de ce scénario catastrophe, c'est la raison pour laquelle la réplication en mode fichier est utilisée uniquement lors de l'amorçage initial d'une copie de base de données. Une fois l'amorçage terminé, la base de données passera automatiquement en réplication en mode bloc.

Réplication en mode bloc
Chaque transaction de base de données est écrite dans le tampon de journal du serveur actif et également envoyée au tampon de journal des membres du DAG hébergeant des copies passives de la base de données. Lorsque le tampon de journal devient membre à part entière du DAG, il est alors en mesure de créer son propre fichier journal de transactions afin de le relire dans sa copie de base de données passive. La réplication en mode bloc présente des avantages par rapport à la réplication en mode fichier en cas d'échec dans le DAG, car moins de données du journal des transactions sont susceptibles d'être perdues.


Retour au sommaire

QUORUM POUR LES GROUPES DE DISPONIBILITÉ

Un DAG Exchange 2013 utilise le mode cluster de Windows ainsi qu’un modèle de quorum. Ce cluster est géré automatiquement par Exchange. Il n’y a donc pas besoin de s’en préoccuper outre mesure autrement que de connaître le fonctionnement d’un quorum. Si pour vous, le concept de quorum est nouveau, il suffit de le comparer un processus de vote dans lequel une majorité des membres votants doit être présente pour prendre une décision.
La décision dans le cas d'un DAG est essentiellement de savoir si le DAG doit être maintenu en ligne ou hors ligne. Étant donné qu'une majorité de votes est requise pour le quorum, deux modèles de quorum différents sont utilisés selon le nombre de membres du DAG dont vous disposez. Pour un DAG avec un nombre impair de membres, le mode Node Majority Quorum est utilisé.

Image 004

Image 005

Image 006

Dans l'exemple ci-dessus, un DAG à trois membres est capable de maintenir le quorum lors d'une panne de serveur unique, mais le quorum est perdu lorsque deux serveurs ne sont pas disponibles.

Pour un DAG avec un nombre pair de membres, le mode Node and File Share Majority Quorum est utilisé. Ce mode implique un serveur supplémentaire appelé témoin. Il s'agit généralement d'une autre machine sur laquelle est installé Microsoft Windows Serveur situé sur le même site que les membres du DAG.

Image 007
Image 008
Image 009
Image 011

Dans l'exemple ci-dessus, un DAG à quatre membres utilise un serveur supplémentaire comme témoin avec le service de partage de. Le DAG est capable de maintenir le quorum jusqu'à deux pannes de serveur. Le quorum sera perdu lorsque trois serveurs seront en défaillance.
Les DAG déployés sur Windows Server 2012 peuvent être plus résistants aux pannes de plusieurs nœuds grâce à une nouvelle fonctionnalité appelée quorum dynamique. Pour plus d'informations sur le sujet, je vous conseille de lire le chapitre intitulé « Amélioration de la résilience des groupes de disponibilité de base de données Exchange Server 2013 avec le quorum dynamique de cluster Windows Server 2012 ».

Retour au sommaire

DISPONIBILITÉ RESEAU

Un réseau DAG fait référence à un ou plusieurs réseaux IP auxquels les membres DAG sont connectés. Ces réseaux sont utilisés pour le trafic client et le trafic de réplication.

Image 012

Dans l’exemple ci-dessus, le trafic client ainsi que la réplication utilisent un même réseau.

Chaque DAG possède un réseau pour le trafic client, et il peut également éventuellement utiliser un certain nombre de réseaux dédiés au trafic de réplication.

Image 013

Les réseaux de réplication dédiés peuvent aider à réduire l'utilisation de la bande passante sur le réseau client. Cela empêche les problèmes de performances liés au réseau pour les clients.
Microsoft Exchange Server 2013 tentera de configurer automatiquement les réseaux DAG, mais ne pourra pas le faire, si les configurations des cartes réseau ne sont pas correctes.
Les DAG peuvent être déployés afin de fournir à la fois une haute disponibilité et une résilience de site. Un DAG déployé pour la haute disponibilité existe généralement dans un seul site Active Directory.

Retour au sommaire

PRE-REQUIS

Les membres du DAG exécutent normalement le rôle de serveur de boîtes aux lettres. Bien qu'ils puissent également exécuter le rôle serveur d'accès au client, cela est distinct et n'est pas requis pour les opérations DAG.

Microsoft Exchange Server 2013 peut s'exécuter à la fois sur Windows Server 2008 R2 et Windows Server 2012. Cependant, en raison de la dépendance de la mise en cluster, vous devez noter les versions de Microsoft Windows Server suivantes qui peuvent être utilisées :

Windows Server 2008 R2 Enterprise Edition (pour la mise en cluster)
Windows Server 2012 Standard ou Datacenter Edition

Dans cet article, toutes les machines utiliseront Microsoft Windows Server 2012 DataCenter.

Retour au sommaire

MISE EN OEUVRE

Dans cette partie de l'article, je vous spécifie les différents paramètres utilisés pour chaque ordinateur. Il y aura au total 5 ordinateurs nommés (netbios) de la manière suivante :

SRV-ADDC
MBX1
MBX2
CAS
TEMOIN


Image 059

SRV-ADDC.BSALADO.LAN (Contrôleur de domaine)


Image 017
Le contrôleur de domaine dans l'Active Dirextory.

Image 014
Les différents rôles installés sur le contrôleur de domaine.


Image 016
Le pare-feu a été désactivé.

Image 015
L'adressage IP du contrôleur de domaine.


Image 059MBX1.BSALADO.LAN

Seul le rôle « Boite aux lettres » de Microsoft Exchange sera installé sur cette machine.

Image 019
Installation du rôle de boite aux lettres de Microsoft Exchange 2013.

Attention ! Le rôle IIS est installé automatiquement lors de l’installation du rôle de boite aux lettres de Microsoft Exchange 2013.

Image 020
Les différents rôles installés.

Image 018
L'adressage IP.

Image 016
Le pare-feu est désactivé.

Image 059MBX2.BSALADO.LAN

Seul le rôle « Boite aux lettres » de Microsoft Exchange sera installé sur cette machine.

Image 019
Installation du rôle de boite aux lettres de Microsoft Exchange 2013.

Attention ! Le rôle IIS est installé automatiquement lors de l’installation du rôle de boite aux lettres de Microsoft Exchange 2013.

Image 020
Les différents rôles installés.

Image 021
L'adressage IP.

Image 016
Le pare-feu est désactivé.

Image 059CAS.BSALADO.LAN

Image 023
Le rôle d'accès au client de Microsoft Exchange 2013.


Image 020
Les différents rôles installés.

Image 016
Le pare-feu est désactivé.

Image 022
L'adressage IP.

Image 059TEMOIN.BSALADO.LAN

Image 016
Le pare-feu est désactivé.

Image 024
L'adressage IP.

En résumé, nous avons 4 machines nommées SRV-ADDC, MBX1, MBX2, CAS, TEMOIN. On retrouve donc ces machines dans l’Active Directory ainsi que dans le serveur DNS.

Image 025
Les ordinateurs présents dans l’Active Directory.

Image 026
Les ordinateurs enregistrés dans le serveur DNS.

On prépare l’ordinateur TEMOIN.BSALADO.LAN

Image 027
La fenêtre des outils d’administration.

Image 028

Image 029Image 030

Image 031

Image 032
Affectation de Exchange Trusted Subsystem.

On crée maintenant un nouveau dossier sur lequel le partage sera activé. Il est préférable d’utiliser un disque différent du système. Dans notre cas, j’utiliserai le deuxième disque de l’ordinateur.

Image 033
Le dossier sur un disque dur indépendant du système d’exploitation.

Image 034
L’activation du partage.

On prépare maintenant le DAG sur le contrôleur de domaine SRV-ADDC.BSALADO.LAN. On commence par créer un nouveau compte d’ordinateur. Ce dernier sera nommé DAG01.

Image 035
Création d’un compte d’ordinateur dans l’Active Directory.

On désactive ensuite cet ordinateur.

Image 036
Désactivation de l'ordinateur.

Image 037
Validation de la désactivation de l'ordinateur.

On affiche les fonctionnalités avancées de la console.

Image 038
Affichage des fonctionnalités avancées de la console.

On ajoute les deux serveurs MBX (MBX1 et MBX2) au DAG.


Image 039


Image 040Image 041

Image 042

On affecte ensuite le contrôle total à MBX1 et MBX2.

Image 043Image 044
Affectation du contrôle total à MBX1 et MNX2.

On crée maintenant le cluster dans Microsoft Exchange Server 2013. Pour cela on se connecte à la console ECP.

Image 045
Connexion à la console ECP.

Image 046

Image 047
Configuration du DAG.

Image 048
Le DAG est créé.

On ajoute les membres du DAG.

Image 049


Image 050
Ajout des membre au DAG.

Image 051
Création du cluster en cours.

Image 052
La création du cluster est terminé.

On peut maintenant choisir les bases de données à répliquer. Je fais le choix de répliquer la base de données de boite aux lettres située sur le serveur MBX1 sur le serveur MBX2. Pour cela, je vérifie le nom de ma base de données à partir du serveur MBX1.

Image 053
Le nom de la base de données sur le serveur MBX1.

Image 054
Mise en place de la réplication.

Image 055
Enregistrement de la réplication.

Image 057
La mise en réplication de la base de données est terminée.

Image 058

Avec la mise en oeuvre dugroupe de disponibilité de bases de données, on vient de combler un point unique de défaillance. Cela est appelé SPOF ( Single Point Of Failure) pour la disponibilité des bases de données Exchange. On dispose maintenant d'une base de données de boite aux lettres hautement disponible. Afin de parfaire cette installation, il est possible de mettre en oeuvre un serveur CAS supplémentaire et de configurer un Load Balancing entre ces deux serveurs. Cela fera l'objet d'un prochain article.

Retour au sommaire

CONCLUSION

Le groupe de disponibilité de la base de données peut être un ensemble de 16 serveurs Exchange Server 2013 maximum avec le rôle de boîte aux lettres installé. Le serveur peut également héberger le rôle CAS. La base de données de boîtes aux lettres située sur l'un de ces serveurs peut être répliquée sur un ou plusieurs autres serveurs restants. La compréhension du DAG, est une exigence des professionnels de l'informatique dans la mise en oeuvre de Microsoft Exchange Server et cela quel que soit la version utilisée.

Retour au sommaire

SOURCES


https://jenny.bourdiol.org/frar/install-exchange-server-2013-step-step-dag
https://pixelabs.fr/haute-disponibilite-exchange-2016-dag/
https://docs.microsoft.com/fr-fr/exchange/database-availability-groups-dags-exchange-2013-help
https://practical365.com/exchange-server/exchange-server-2013-database-availability-groups/