Partager via


Exemples de création de groupe de disponibilité de base de données

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

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

Les groupes de disponibilité de base de données (DAG) offrent un large éventail de possibilités de création architecturale de par leur capacité à contenir jusqu’à 16 serveurs de boîtes aux lettres, associée à leur capacité d’extension dans plusieurs emplacements physiques et sites Active Directory.

Vous pouvez utiliser des exemples de création de DAG dans une variété d’environnements :

  • un DAG de deux membres, qui est adapté aux déploiements dans les petites entreprises ou les agences ;

  • un DAG à quatre membres qui procure une haute disponibilité au sein d’un centre de données unique en plaçant tous les membres dans un même centre de données ;

  • un DAG à quatre membres qui procure à la fois une haute disponibilité au sein d’un centre de données unique et une résilience de site pour ce centre de données en plaçant deux des membres dans le centre principal et les deux autres dans le deuxième centre.

Le schéma de conception utilisé pour vos groupes de disponibilité de base de données et la distribution des copies de bases de données de boîtes aux lettres seront fonction des contrats SLA de votre organisation et des objectifs de temps et de point de récupération du service de boîte aux lettres et des données tels qu’ils sont définis dans ces contrats SLA.

Contenu de cette rubrique

DAG à deux membres dans un centre de données unique/site Active Directory

DAG à quatre membres dans un centre de données unique/site Active Directory

DAG à quatre membres dans deux centres de données/sites Active Directory

Deux DAG à quatre membres dans deux centres de données/sites Active Directory

Utilisation de serveurs de boîtes aux lettres qui ne contiennent pas de bases de données dans un DAG pour bénéficier de votes supplémentaires

Souhaitez-vous rechercher les tâches de gestion relatives à la haute disponibilité et à la résilience de site ? Voir Gestion de la haute disponibilité et de la résilience de site.

DAG à deux membres dans un centre de données unique/site Active Directory

Un DAG à deux membres est le plus petit groupe de disponibilité de base de données capable de procurer une haute disponibilité. Les DAG à deux membres conviennent aux organisations qui nécessitent une certaine forme de haute disponibilité pour les services et données de boîtes aux lettres, mais n’ont pas besoin de résilience de site. Cette configuration fonctionne particulièrement bien dans les déploiements de petites entreprises et agences car elle autorise la redondance pour les rôles de serveurs d’accès au client, de boîtes aux lettres et de transport Hub en faisant appel seulement à deux serveurs Exchange. La figure suivante illustre cette configuration.

Groupe de disponibilité de base de données à deux membres

Groupe de disponibilité de la base de données pour deux membres

Cette configuration comporte plusieurs aspects qu’il convient de noter :

  • seuls les rôles serveurs d’accès au client, de boîtes aux lettres et de transport Hub occupent le même emplacement. Même si la co-localisation du rôle Serveur de messagerie unifiée est prise en charge, nous ne conseillons pas cette configuration pour des raisons de performances.

  • Afin d’obtenir une haute disponibilité pour les rôles serveurs d’accès au client et de transport Hub, il conviendrait d’utiliser une forme d’équilibrage de charge entre les clients et ces rôles serveurs. Du fait que ces rôles serveur se trouvent au même endroit qu’un serveur de boîtes aux lettres membre d’un groupe de disponibilité de base de données, la fonctionnalité Équilibrage de la charge réseau de Windows ne peut pas être utilisée (car il est impossible de l’installer sur le même serveur que le cluster de basculement de Windows). Par conséquent, vous devez recourir à une solution d’équilibrage de la charge réseau non-Windows (un programme d’équilibrage de la charge matérielle ou un équilibreur de charge logiciel tiers par exemple).

  • Comme c’est le cas pour tous les groupes de disponibilité de base de données contenant un nombre pair de membres, un DAG à deux membres a besoin d’un serveur témoin pour maintenir le quorum. Le serveur témoin (non représenté) est un serveur Windows qui n’est pas, et qui ne sera jamais, membre du DAG. Ainsi, dans les petites organisations qui disposent de cette configuration, un serveur de fichiers ou un serveur d’annuaire peut servir de serveur témoin. Le quorum est maintenu tant que plus de la moitié des votants est disponible et en communication. Un DAG à deux membres doté d’un serveur témoin fournit trois votants. (En effet, chaque membre du DAG et le serveur témoin peuvent voter chaque fois qu’ils sont disponibles et en communication.) Par conséquent, un DAG à deux membres peut survivre à la défaillance ou l’indisponibilité d’un votant (par exemple, l’un ou l’autre des deux membres du DAG ou seulement le serveur témoin). Toutefois, la perte de deux des votants (un membre du DAG et le serveur témoin par exemple) entraîne la perte du quorum, qui provoque à son tour une interruption de service.

Retour au début

DAG à quatre membres dans un centre de données unique/site Active Directory

Un groupe de disponibilité de base de données à quatre membres, déployé dans un seul centre de données, offre une plus grande résilience aux défaillances qu’un DAG à deux ou trois membres. Les DAG plus grands offrent intrinsèquement une plus grande résilience puisqu’ils sont capables de résister à plus de défaillances sans entraîner d’interruption de service. Tandis qu’un DAG à deux ou trois membres ne peut accepter que la perte d’un seul votant pour maintenir le quorum et le service, un DAG à quatre membres, disposant par définition de cinq votants, peut donc supporter la perte de deux votants sans compromettre le quorum et le service.

La figure suivante illustre un DAG à quatre membres avec l’ensemble des membres placés dans un seul centre de données.

Groupe de disponibilité de base de données à quatre membres

Groupe de disponibilité de la base de données pour quatre membres

En utilisant un groupe de disponibilité de base de données comportant quatre membres, vous pouvez créer jusqu’à quatre copies de chaque base de données. Le nombre de copies de bases de données est donc suffisant pour permettre l’utilisation d’autres scénarios de protection des données, tels qu’une protection flexible des boîtes aux lettres. Ce scénario vous permet d’associer les fonctionnalités de haute disponibilité et de résilience du moteur ESE (Extensible Storage Engine) de Microsoft Exchange Server 2010 à d’autres fonctionnalités de protection intégrées, telles que la copie différée de la base de données de boîtes aux lettres, les stratégies de rétention, et le dossier Éléments récupérables, pour créer une solution capable de minimiser le besoin de recourir à des protections supplémentaires, comme la technologie RAID (Redundant Array of Independent Disks) ou les sauvegardes. Pour plus d’informations sur la protection flexible des boîtes aux lettres, consultez la rubrique Présentation de la sauvegarde, de la restauration et de la récupération d'urgence. Pour plus d’informations sur l’utilisation de la réplication pour vos sauvegardes et d’un système JBOD (Just a Bunch Of Disks), consultez la rubriqueConception du stockage de serveur de boîtes aux lettres.

Retour au début

DAG à quatre membres dans deux centres de données/sites Active Directory

Un DAG à quatre membres étendu sur deux centres de données procure la haute disponibilité de deux centres de données et la résilience de site pour les services et données de boîtes aux lettres. Cette configuration est illustrée dans la figure suivante :

Groupe de disponibilité de base de données à quatre membres étendu sur deux sites

Groupe de disponibilité de la base de données sur deux sites

Cette configuration comporte plusieurs aspects qu’il convient de noter :

  • Le serveur témoin du DAG doit être placé dans le centre de données principal. Le centre de données principal est généralement le centre de données contenant la majorité de la population d’utilisateurs. L’utilisation d’un serveur témoin dans le centre de données principal autorise une fonctionnalité continue pour la majorité de la population d’utilisateurs en cas d’interruption de service d’un réseau étendu (WAN). Vous pouvez utiliser plusieurs DAG afin d’éviter que le WAN représente un point de défaillance unique, et de permettre la continuité de service et d’accès aux données pour de multiples centres de données en cas de panne du WAN. Pour plus d’informations, reportez-vous à l’exemple suivant.

  • Il n’y a pas de routage direct permettant le trafic du réseau de réplication sur un serveur membre du DAG vers le réseau MAPI sur un autre serveur membre du DAG, ou l’inverse, ou entre plusieurs réseaux de réplication au sein du DAG. Supposons par exemple que vous souhaitiez bloquer le trafic entre le réseau MAPI sur chaque membre du DAG et les réseaux de réplication sur chacun des autres réseaux de groupe de disponibilité de base de données. (Dans l’illustration précédente, le réseau MAPI sur MBX1A ne devrait pas avoir de connectivité réseau avec les réseaux de réplication sur MBX1B ou MBX2B.) Pour ce faire, vous pouvez utiliser des listes de contrôle d’accès (ACL) de routeur. En outre, si le protocole DHCP est utilisé pour le réseau de réplication, vous pouvez l’utiliser également pour configurer des routes statiques pour les membres du DAG.

  • L’objectif de cette configuration de DAG étant d’assurer la résilience d’un site, la valeur de durée de vie (TTL) des espaces de noms d’accès au client Exchange (Microsoft Office Outlook Web App, Autodiscover, Microsoft Exchange ActiveSync, Outlook Anywhere, POP3, IMAP4, SMTP et le groupe d’accès au client RPC) doit être configurée sur 5 minutes dans les zones DNS internes et externes.

  • Dans cet exemple, les rôles serveurs d’ Exchange sont déployés sur du matériel dédié. Les rôles serveurs d’accès au client et de transport Hub ne se trouvant pas au même endroit que le serveur de boîte aux lettres dans le DAG, la fonctionnalité d’équilibrage de la charge réseau de Windows est utilisée pour équilibrer la charge de ces deux rôles serveurs.

Retour au début

Deux DAG à quatre membres dans deux centres de données/sites Active Directory

Comme le montre l’exemple précédent, l’utilisation d’un DAG à quatre membres unique couvrant deux centres de données permet d’assurer une haute disponibilité et une résilience de site pour les services et les données de boîtes aux lettres. Toutefois si une panne de WAN survient, le service est maintenu seulement dans le centre de données principal, car ce dernier contient la majorité des votants. Le centre de données dont les votants sont en minorité perd la majorité, et les membres du DAG de ce centre de données perdent le quorum et sont mis hors connexion.

Pour un déploiement de serveurs de boîtes aux lettres hautement disponibles dans un environnement de centres de données multiples, où chaque centre de données prend activement en charge une population d’utilisateurs en local, nous vous recommandons de déployer plusieurs DAG, chacun d’eux devant disposer d’une majorité de votants dans un autre centre de données, comme le montre l’illustration suivante.

Deux DAG à quatre membres étendus à deux sites

Deux groupes de disponibilité de base de données dans deux centres de données actifs

Du fait que DAG1 et DAG2 contiennent le même nombre de membres, ils utilisent un serveur témoin. Même si plusieurs DAG peuvent utiliser le même serveur témoin, de multiples serveurs témoin basés dans des centres de données distincts sont utilisés pour garantir la continuité de service à la population locale d’utilisateurs de chaque centre de données en cas de panne d’un WAN.

Les utilisateurs qui se trouvent à Portland ont leur base de données de boîtes aux lettres active sur PDXMBX3 et/ou PDXMBX4, avec des copies de base de données passive sur REDMBX3 et/ou REDMBX4. Quant aux utilisateurs situés à Redmond, leur base de données de boîtes aux lettres active est sur REDMBX1 et/ou REDMBX2, avec des copies de base de données passive sur PDXMBX1 et/ou PDXMBX2. Si la perte de connectivité réseau est totale entre Redmond et Portland, la situation est la suivante :

  • Pour DAG1, les membres REDMBX1 et REDMBX2 restent dans la majorité et continuent la prise en charge des utilisateurs dans le centre de données de Redmond car ils peuvent communiquer avec le serveur témoin de DAG1, HUB1.

  • Pour DAG1, les membres PDXMBX3 et PDXMBX4 restent dans la majorité et continuent la prise en charge des utilisateurs dans le centre de données de Portland car ils peuvent communiquer avec le serveur témoin de DAG2, HUB2.

Retour au début

Utilisation de serveurs de boîtes aux lettres qui ne contiennent pas de bases de données dans un DAG pour bénéficier de votes supplémentaires

Comme mentionné précédemment, les DAG de plus grande taille assurent une meilleure résilience car ils supportent un plus grand nombre d’erreurs sans pour autant générer d’interruption de service. Afin d’augmenter la résilience pour la prise en charge des erreurs de membre d’un DAG, une stratégie consiste à exploiter les serveurs de transport Hub existants dans le centre de données principal du DAG. Cette stratégie implique l’ajout du rôle Serveur de boîte aux lettres (sans base de données ni copie de base de données) sur le serveur de transport Hub, puis l’ajout de ce serveur au DAG. Dans ce scénario, le rôle Serveur de boîte aux lettres n’est utilisé qu’à des fins de vote et de quorum. À mesure que le nombre de votants augmente dans un DAG, le nombre d’erreurs qu’il peut supporter croît en parallèle (mais le quorum est maintenu).

Prenons par exemple un DAG à quatre membres qui couvre deux centres de données. Le centre de données principal contient deux membres du DAG ainsi que le serveur témoin, et un second centre de données contient également deux membres du DAG. Comme représenté dans la figure suivante, il y a cinq votants. Par conséquent, ce DAG peut perdre deux votants tout en maintenant le quorum. Si le DAG perd un troisième votant, il perd le quorum et nécessite l’intervention (manuelle) d’un administrateur pour restaurer le service.

DAG à quatre membres avec un serveur témoin

Groupe de disponibilité de la base de données de 4 membres avec 5 votants

En utilisant les mêmes serveurs dans cet exemple, vous pouvez ajouter le rôle Serveur de boîtes aux lettres aux serveurs de transport Hub REDHUB1, REDHUB2 et PDXHUB1, puis ajouter ces serveurs au groupe de disponibilité DAG1 (dans la mesure où ils sont capables d’exécuter le cluster de basculement Windows).

DAG à sept membres utilisant trois serveurs de boîtes aux lettres qui ne contiennent pas de bases de données

Groupe de disponibilité de la base de données de 7 membres avec 7 votants

À ce stade, vous ne créez pas de base de données de boîtes aux lettres de production sur ces serveurs. Vous ne répliquez pas non plus de copies de base de données sur ces serveurs. Dans cette configuration, il est possible de supprimer la base de données de boîtes aux lettres par défaut et d’interrompre le service de banque d’informations Microsoft Exchange (vous pouvez aussi le désactiver).

RemarqueRemarque :
Même si le service de banque d’informations de Microsoft Exchange n’est pas nécessaire pour un serveur de boîtes aux lettres qui ne contient pas de base de données participant à un vote avec quorum, le service de réplication de Microsoft Exchange doit s’exécuter pour que le serveur de boîtes aux lettres participe aux fonctions de quorum et du DAG.

Une fois que les serveurs de boîtes aux lettres ne contenant pas de bases de données sont ajoutés en tant que membres du DAG, ils participent au quorum pour ce même DAG. Dans cette configuration, DAG1 possède maintenant sept votants. Cela implique qu’il peut perdre trois serveurs tout en maintenant le quorum.

Retour au début

 © 2010 Microsoft Corporation. Tous droits réservés.