Présentation des groupes de disponibilité de base de données

Dernière rubrique modifiée : 2010-01-13

Un groupe de disponibilité de base de données (DAG) est le composant de base de la structure de résilience de site et de haute disponibilité intégrée à Microsoft Exchange Server 2010. Un DAG est composé d'un maximum de 16 serveurs de boîtes aux lettres qui hébergent un ensemble de bases de données. Ces serveurs peuvent ainsi récupérer automatiquement des bases de données à la suite d'une panne d'un serveur ou lorsqu'une base de données n'est plus accessible.

Un DAG tient lieu de cadre pour la réplication de bases de données de boîtes aux lettres, le basculement et la permutation de bases de données et de serveurs et pour un composant interne appelé Active Manager. Active Manager est un composant Exchange 2010 qui gère les basculements et les permutations qui s'exécutent sur chaque serveur dans un DAG. Pour plus d'informations sur Active Manager, voir Présentation du gestionnaire Active Manager.

N'importe quel serveur d'un DAG peut héberger une copie d'une base de données de boîtes aux lettres se trouvant sur un autre serveur du DAG. Lorsqu'un serveur est ajouté à un DAG, il fonctionne avec les autres serveurs de ce dernier pour assurer la récupération automatique des bases de données de boîtes aux lettres à la suite d'une panne d'un disque ou d'un serveur.

Contenu de cette rubrique

Cycle de vie du groupe de disponibilité de base de données

Utilisation d'un groupe de disponibilité de base de données pour une haute disponibilité du système

Utilisation d'un groupe de disponibilité de base de données pour la résilience de site

Cycle de vie du groupe de disponibilité de base de données

Les DAG s'appuient sur une fonctionnalité d'Exchange 2010 appelée déploiement incrémentiel, qui garantit la disponibilité des services et des données pour tous les serveurs et bases de données de boîtes aux lettres après l'installation d'Exchange. Après avoir déployé Exchange 2010, vous pouvez créer un DAG, y ajouter des serveurs de boîtes aux lettres et répliquer des bases de données de boîtes aux lettres entre les membres de ce DAG.

La création d'un DAG s'effectue à l'aide de la cmdlet New-DatabaseAvailabilityGroup. À sa création, le DAG est un objet vide dans Active Directory. Cet objet Active Directory permet de stocker les informations nécessaires ayant trait au DAG, telles que les informations d'appartenance au DAG des serveurs. Lorsqu'un administrateur ajoute le premier serveur à un DAG, un cluster de basculement est automatiquement créé pour celui-ci. En outre, l'infrastructure qui surveille les serveurs pour détecter les pannes du réseau ou de serveurs est exécutée. Le mécanisme de pulsation du cluster de basculement et la base de données du cluster sont alors utilisés pour effectuer le suivi des informations liées au DAG et les gérer. Ces informations, qui peuvent changer rapidement, sont notamment l'état de montage de la base de données, l'état de réplication et le dernier emplacement monté.

Lors de sa création, le DAG reçoit un nom unique et soit une ou plusieurs adresses IP statiques lui sont affectées, soit il est configuré pour utiliser le protocole DHCP. Vous pouvez spécifier une seule adresse IP ou une liste d'adresses IP séparées par une virgule à l'aide du paramètre DatabaseAvailabilityGroupIPAddresses.

Prenons l'exemple d'un DAG comportant trois serveurs ; deux serveurs (EX1 et EX2) sont sur le même sous-réseau (10.0.0.0) et le troisième (EX3) se trouve sur un autre sous-réseau (192.168.0.0). L'administrateur exécute les commandes suivantes :

New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

Remarque :
Si vous configurez le paramètre DatabaseAvailabilityGroupIPAddresses avec la valeur 0.0.0.0, le DAG (cluster) utilisera le protocole DHCP pour ses adresses IP ou ses ressources d'adresses IP.

Le cluster pour DAG1 est créé lorsqu'EX1 est ajouté au groupe de disponibilité de base de données. Au cours de la création du cluster, la cmdlet Add-DatabaseAvailabilityGroupServer récupère les adresses IP configurées pour le DAG et ignore celles qui ne correspondent à aucun des sous-réseaux trouvés sur EX1. Dans cet exemple, le cluster pour DAG1 est créé avec l'adresse IP 10.0.0.5 et l'adresse 192.168.0.5 est ignorée.

EX2 est ensuite ajouté. Là encore, l'applet de commande Add-DatabaseAvailabilityGroupServer récupère les adresses IP configurées pour le DAG. Les adresses IP du cluster ne changent pas, car EX2 se trouve sur le même sous-réseau qu'EX1.

Ex3 est ensuite ajouté. Là encore, l'applet de commande Add-DatabaseAvailabilityGroupServer récupère les adresses IP configurées pour le DAG. Étant donné qu'un sous-réseau correspondant à l'adresse 192.168.0.5 est présent sur EX3, l'adresse 192.168.0.5 est ajoutée en tant que ressource d'adresse IP dans le groupe de clusters. En outre, une dépendance OR pour la ressource Nom du réseau de chaque ressource d'adresse IP est automatiquement configurée. L'adresse 192.168.0.5 sera utilisée par le cluster lorsque le groupe de clusters bascule vers EX3.

La fonctionnalités de clustering avec basculement de Windows enregistre les adresses IP du cluster dans DNS (Domain Name System) lorsque la ressource Nom du réseau est disponible en ligne. En outre, un objet de réseau de cluster est créé dans Active Directory. Le nom, l'adresse IP et l'objet réseau de cluster du cluster sont utilisés en interne par le système uniquement pour sécuriser le DAG et à des fins de communication interne. Les administrateurs et les utilisateurs finaux n'ont pas besoin de communiquer, pour une raison ou une autre, avec le nom du DAG ni avec l'adresse IP ou de s'y connecter.

En plus de disposer d'un nom et d'adresses IP, le DAG est également configuré pour utiliser un serveur témoin et un répertoire témoin. Le serveur témoin et le répertoire témoin sont automatiquement spécifiés par le système mais l'administrateur peut les spécifier manuellement.

Par défaut, un DAG est conçu pour utiliser la fonctionnalité de réplication continue intégrée pour répliquer des bases de données de boîtes de données entre les serveurs qui en sont membres. Si vous utilisez la réplication de données tierce avec l'API de réplication tierce dans Exchange 2010, vous devez créer le DAG en mode réplication tierce à l'aide de la cmdlet New-DatabaseAvailabilityGroup avec le paramètre ThirdPartyReplication. Une fois que ce mode est activé, il ne peut pas être désactivé.

Une fois que le DAG est créé, des serveurs de boîtes aux lettres peuvent y être ajoutés. Lorsque le premier serveur est ajouté au DAG, un cluster qui sera utilisé par ce dernier est créé. Les DAG font un usage limité de la technologie de clustering avec basculement de Windows ; il peut s'agir notamment de la pulsation de clusters, de réseaux de clusters et d'une base de données de clusters (pour stocker les données qui changent ou qui peuvent changer rapidement, par exemple lorsque l'état d'une base de données passe d'actif à passif et inversement ou de montée à démontée et inversement). Lorsqu'un serveur est ajouté au DAG, il est ajouté au cluster sous-jacent (et le modèle de quorum du cluster est automatiquement ajusté comme il convient par le système) et à l'objet du DAG dans Active Directory.

Après l'ajout de serveurs de boîtes aux lettres à un DAG, vous pouvez configurer plusieurs propriétés, comme l'utilisation du chiffrement ou de la compression réseau pour la réplication des bases de données au sein du DAG. Vous pouvez également configurer des réseaux de DAG et en créer, le cas échéant.

Une fois que vous avez ajouté des membres à un DAG et configuré celui-ci, vous pouvez répliquer les bases de données de boîtes aux lettres actives se trouvant sur chaque serveur sur les autres membres du DAG. Vous pouvez ensuite surveiller l'intégrité et l'état des copies de ces bases de données à l'aide de différents outils de surveillance intégrés. Le cas échéant, vous pouvez également effectuer des permutations de serveurs et de bases de données.

Pour plus d'informations sur la création d'un DAG, la gestion des serveurs membres d'un DAG, la configuration des propriétés d'un DAG, la création de copies de bases de données de boîtes aux lettres et leur surveillance et sur les permutations de serveurs et de bases de données, voir Gestion de la haute disponibilité et de la résilience de site.

Retour au début

Utilisation d'un groupe de disponibilité de base de données pour une haute disponibilité du système

Pour montrer de quelle manière un DAG permet d'assurer un haut niveau de disponibilité des bases de données de boîtes aux lettres, prenons l'exemple suivant, dans lequel un DAG comporte cinq membres. L'illustration suivante représente ce DAG :

Groupe de disponibilité de base de données

Dans l'illustration précédente, les bases de données vertes sont des copies de bases de données de boîtes aux lettres actives et les bases de données bleues sont des copies de bases de données de boîtes aux lettres passives. Dans cet exemple, les copies de bases de données ne sont pas répliquées de manière identique sur chaque serveur, elles sont réparties sur plusieurs serveurs. Ainsi, deux serveurs ne comportent pas le même ensemble de copies de bases de données, ce qui rend le DAG plus résilient aux pannes, notamment les pannes qui se produisent lorsque d'autres composants sont inactifs pour des raisons de maintenance.

Examinons le scénario suivant, basé sur l'exemple précédent, qui illustre la résilience à plusieurs pannes de base de données et de serveur.

Au départ, tous les serveurs et bases de données sont en bon état de fonctionnement. Un administrateur doit installer certaines mises à jour du système d'exploitation sur EX2. L'administrateur effectue une permutation de serveur, qui active la copie de DB4 sur un autre serveur de boîtes aux lettres. Une permutation de serveur est une tâche qu'effectue un administrateur pour faire passer toutes les copies des bases de données de boîtes aux lettres d'un serveur vers d'autres serveurs du DAG en vue d'une mise hors service programmée de ce serveur. Pour cela, l'administrateur peut exécuter la commande suivante dans l'environnement de ligne de commande Exchange Management Shell.

Move-ActiveMailboxDatabase -Server EX2

Dans cet exemple, une seule base de données de boîtes aux lettres est active sur EX2 (DB4), par conséquent, une seule copie de base de données active est déplacée. Dans ce cas, en omettant le paramètre ActivateOnServer dans la commande précédente, l'administrateur décide de confier au système la sélection de la meilleure nouvelle copie de base de données. Le système choisit la copie sur le serveur EX5 comme le montre l'illustration suivante.

Groupe de disponibilité de base de données avec un serveur déconnecté pour des raisons de maintenance

Lorsque l'administrateur procède à la maintenance du serveur EX2, EX3 subit une panne matérielle catastrophique et est déconnecté. Avant d'être déconnecté, le serveur EX3 hébergeait la copie active de DB2. Pour récupérer la base de données DB2 à la suite de la panne, le système active automatiquement la copie de DB2 qui est hébergée sur EX1 dans un délai de 30 secondes. Cela est montré dans l'illustration suivante.

Groupe de disponibilité de base de données avec un serveur déconnecté pour des raisons de maintenance et un serveur en panne

Une fois que la maintenance d'EX2 est terminé, l'administrateur le reconnecte. Dès qu'EX2 est en ligne, les autres membres du DAG en sont notifiés et les copies de DB1, DB4 et DB5 qui sont hébergées sur EX2 sont automatiquement resynchronisées avec la copie active de chaque base de données. Cela est montré dans l'illustration suivante.

Groupe de disponibilité de base de données avec un serveur restauré resynchronisant ses copies de bases de données

Une fois que le composant matériel tombé en panne dans EX3 a été remplacé par un nouveau composant, EX3 est remis en ligne. Comme avec EX2, dès qu'EX3 est en ligne, les autres membres du DAG en sont notifiés et les copies de DB2, DB3 et DB4 qui sont hébergées sur EX3 sont automatiquement resynchronisées avec la copie active de chaque base de données. Cela est montré dans l'illustration suivante.

Groupe de disponibilité de base de données avec un serveur réparé resynchronisant ses copies de bases de données

Retour au début

Utilisation d'un groupe de disponibilité de base de données pour la résilience de site

En plus d'assurer un haut niveau de disponibilité dans un centre de données, un DAG peut également être étendu à d'autres centres de données dans une configuration qui en garantit la résilience de site. Dans les illustrations des exemples précédent, le DAG est situé dans un seul centre de données et un seul site Active Directory. Le déploiement incrémentiel peut être utilisé pour étendre ce DAG à un deuxième centre de données (et à un deuxième site Active Directory) en déployant un serveur de boîtes aux lettres et les ressources nécessaires à son fonctionnement (notamment, un ou plusieurs serveurs Active Directory et un ou plusieurs serveurs de transport Hub et d'accès au client) et en ajoutant le serveur de boîtes aux lettres au DAG, comme le montre l'illustration ci-dessous.

Groupe de disponibilité de base de données couvrant deux sites Active Directory

Dans cet exemple, une copie passive de chaque base de données active du centre de données de Redmond est configurée sur EX6 dans le centre de données de Dublin.

Retour au début