Windows | Windows Server | Active directory | Exchange | SharePoint | SCCM | SCOM | Hyper-V | App-V
ACCUEIL Facebook Twitter Linked In Viadeo Flux RSS
Chapitres
12.1 Composants de la haute disponibilité Exchange
12.2 Haute disponibilité pour le rôle CAS (NLB)
12.3 Haute disponibilité pour le rôle MBX (DAG)
12.4 Haute disponibilité pour le rôle HT

Articles suivants

Articles précédents
Nouveautés de Windows Server 2016 CTP2
Histoire de Microsoft et chronologie
Windows 10: Découvrez les nouveautés !
System Center 2012 Orchestrator: Présentation
Optimisation des performances d'un environnement Hyper-V


Publié le : 15/08/2011 02:27:34
Mise à jour le : 08/10/2011 00:23:30
Catégories :


Version imprimable

Auteur(s)

Loïc THOBOIS (Membre depuis le 04/09/2007 17:50:01)
Société : AVAEDOS
Fonction : Consultant / Formateur
Contactez cet auteur - Affichez les ressources de cet auteur

[Exchange 2010] 12 Gestion de la haute disponibilité


12.3 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 Node Set –Jeu de nœud majoritaire).

Le Quorum MNS a pour charge de répliquer le Quorum qui contient la configuration du cluster sur l’ensemble des nœuds du cluster.

Pour que le cluster soit en ligne, la majorité absolue des nœuds est nécessaire, si ce n’est pas le cas, l’ensemble des nœuds s’arrête.

Exemple:

Nombre de nœuds du cluster
Majorité atteinte à
Pannes possibles
2 nœuds
2 nœuds
0
3 nœuds
2 nœuds
1
4 nœuds
3 nœuds
1
5 nœuds
3 nœuds
2
6 nœuds
4 nœuds
2
7 nœuds
4 nœuds
3
8 nœuds
5 nœuds
3

Afin d’éviter des clusters bloqués par un partage à égalité parfaite du cluster (coupure réseau entre les nœuds dans le cas d'un cluster deux noeuds par exemple), 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 nœuds.

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.