Déploiement de haute disponibilité et de résilience de site
S'applique à : Exchange Server 2010
Dernière rubrique modifiée : 2009-12-04
Pour créer un serveur de boîtes aux lettres à haut niveau de disponibilité dans les versions antérieures d’Exchange, il fallait installer Exchange sur un serveur qui avait été configuré comme membre d’un basculement de cluster Windows. Pour disposer d’un serveur de boîtes aux lettres à haut niveau de disponibilité, il fallait former et configurer le cluster avant d’exécuter le programme d’installation d’Exchange. Le programme d’installation d’ Exchange (ainsi que d’autres composants Exchange, tels que la banque d’informations Exchange et le service Surveillance du système d’Microsoft Exchange) prenait en charge les clusters et avait donc un comportement différent que s’il était exécuté sur un serveur autonome. Si Exchange était déjà installé sur un serveur autonome Windows, la configuration de la haute disponibilité sur ce serveur exigeait de commencer par supprimer Exchange, puis de former un cluster et de réinstaller Exchange en utilisant la version du programme d’installation prenant en charge les clusters.
Microsoft Exchange Server 2010 utilise le concept de « déploiement incrémentiel » aussi bien pour la haute disponibilité que pour la résilience de site. Contrairement aux versions antérieures, Exchange 2010 n’utilise plus le modèle de ressources de cluster pour la haute disponibilité et ne constitue pas une application prenant en charge les clusters (ou configurée en cluster). A la suite de ce changement d’architecture, il n’existe plus de version du programme d’installation prenant en charge les clusters et il n’est plus possible de configurer la haute disponibilité au moment de l’installation. Il suffit maintenant d’installer tous les serveurs Exchange 2010 comme des serveurs autonomes et de procéder à un déploiement incrémentiel de la haute disponibilité et de la résilience de site en fonction des besoins.
Présentation du processus de déploiement
Bien que la procédure puisse varier légèrement d’une organisation à l’autre, le processus global de déploiement d’Exchange 2010 dans une configuration présentant une haute disponibilité ou une résilience de site est généralement identique. Après avoir réalisé les tâches de planification et de conception nécessaires à l’établissement et au déploiement d’un groupe de disponibilité de base de données (DAG) et à la création de copies de bases de données de boîtes aux lettres, vous pouvez également effectuer les opérations suivantes :
- Créer un DAG. Pour obtenir la procédure détaillée, voir Créer un groupe de disponibilité de la base de données.
- Ajouter deux ou plusieurs serveurs de boîtes aux lettres au DAG. Pour obtenir la procédure détaillée, voir Gérer l’appartenance au groupe de disponibilité de la base de données.
- Configurer les propriétés du DAG selon vos besoins :
- Configurer en option le chiffrement et la compression pour le groupe de disponibilité de base de données, la réplication de port, les adresses IP du DAG et d’autres propriétés relatives au DAG. Pour obtenir la procédure détaillée, voir Configurer les propriétés du groupe de disponibilité de la base de données.
- Si le DAG contient au moins trois serveurs de boîtes aux lettres déployés sur plusieurs sites Active Directory, il est recommandé d’activer le mode DAC de coordination de l’activation du centre de données. Pour plus d’informations, voir Présentation du mode d'activation et de coordination de centre de données.
- Pour obtenir la procédure détaillée de création d’un réseau DAG, consultez la rubrique Créer un réseau de groupe de disponibilité de la base de données. Pour gérer un réseau DAG, consultez la rubrique Configurer les propriétés du réseau de groupe de disponibilité de la base de données.
- Ajouter des copies de base de données de boîte aux lettres entre les serveurs de boîtes aux lettres du DAG. Pour obtenir la procédure détaillée, voir Ajouter une copie de base de données de boîtes aux lettres.
Exemple de déploiement : DAG à quatre membres dans les deux centres de données
Cet exemple explique en détail comment l’organisation appelée « Contoso, Ltd » configure et déploie un groupe de disponibilité de base de données à quatre membres qui couvrira deux emplacements physiques : un centre de données principal nommé « Active Directory SITEA » et un centre de données secondaire nommé « Active Directory SITEB ». SITEA est situé à Redmond dans l’État de Washington, et SITEB est situé à Dublin en Irlande.
Infrastructure de base
Chaque emplacement contient les éléments d’infrastructure nécessaires à l’exploitation d’une infrastructure de messagerie Exchange 2010, à savoir :
- Services d’annuaire (Active Directory ou services de domaine Active Directory (AD DS))
- Résolution de noms DNS (Domain Name System)
- Un ou plusieurs serveurs d’accès client Exchange 2010
- Un ou plusieurs serveurs de transport Hub Exchange 2010
- Un ou plusieurs serveurs de boîtes aux lettres Exchange 2010
.gif "Dd638129.note(fr-fr,EXCHG.140).gif") Remarque : |
|---|
| Les rôles serveur d’accès client, de transport Hub et de boîtes aux lettres peuvent être placés conjointement sur un seul ordinateur. Dans cet exemple de déploiement, les rôles serveur sont installés sur des ordinateurs distincts. |
La figure suivante illustre la configuration de l’organisation Contoso.
Groupe de disponibilité de base de données couvrant deux sites
.gif "Groupe de disponibilité de la base de données sur deux sites")
A l’exception des serveurs de boîtes aux lettres, tous les serveurs de l’environnement Contoso fonctionnent avec le système d’exploitation Windows Server 2008 R2 Standard. Les serveurs de boîtes aux lettres, planifiés pour prendre en charge un DAG, fonctionnent avec le système Windows Server 2008 R2 Enterprise.
En plus des éléments d’infrastructure précédents, chaque emplacement contient d’autres éléments de messagerie, tels que des serveurs de transport Edge et de messagerie unifiée.
Configuration du réseau
Comme l’illustrait la figure précédente, la solution implique l’utilisation de plusieurs sous-réseaux et de plusieurs réseaux. Chaque serveur de boîtes aux lettres du DAG dispose de deux cartes réseau sur des sous-réseaux distincts. Dans chaque serveur de boîtes aux lettres, une carte réseau sera utilisée pour le réseau MAPI (192.168.x.x) et une carte réseau pour le réseau de réplication (10.0.x.x). Seul le réseau MAPI fournit la connectivité à Active Directory, aux services DNS et autres serveurs et clients Exchange. La carte utilisée pour le réseau de réplication de chaque membre fournit la connectivité uniquement aux cartes du réseau de réplication des autres membres du DAG.
Le tableau suivant présente en détail les paramètres de chaque carte réseau dans chacun des nœuds.
| Nom | Adresse IPv4 | Masque de sous-réseau | Passerelle par défaut |
|---|---|---|---|
MBX1A (MAPI) |
192.168.1.4 |
255.255.255.0 |
192.168.1.1 |
MBX2A (MAPI) |
192.168.1.5 |
255.255.255.0 |
192.168.1.1 |
MBX1B (MAPI) |
192.168.2.4 |
255.255.255.0 |
192.168.2.1 |
MBX2B (MAPI) |
192.168.2.5 |
255.255.255.0 |
192.168.2.1 |
MBX1A (réplication) |
10.0.1.4 |
255.255.0.0 |
Aucun |
MBX2A (réplication) |
10.0.1.5 |
255.255.0.0 |
Aucun |
MBX1B (réplication) |
10.0.2.4 |
255.255.0.0 |
Aucun |
MBX2B (réplication) |
10.0.2.5 |
255.255.0.0 |
Aucun |
Comme le montrait le tableau précédent, les cartes des réseaux de réplication n’utilisent pas de passerelles par défaut. Pour assurer la connectivité réseau entre chacune des cartes du réseau de réplication, l’organisation Contoso utilise des itinéraires statiques persistants.
Pour configurer le routage des cartes de réseau de réplication MBX1A et MBX2A, la commande suivante a été exécutée sur chaque serveur.
Route add 10.0.2.0 mask 255.255.0.0 10.0.1.254 -p
Pour configurer le routage des cartes de réseau de réplication MBX1B et MBX2B, la commande suivante a été exécutée sur chaque serveur.
Route add 10.0.1.0 mask 255.255.0.0 10.0.2.254 -p
| Remarque : |
|---|
| Le commutateur –p sert à rendre ces itinéraires persistants (par exemple, en les maintenant après un redémarrage). Si vous n’utilisez pas le commutateur –p, les itinéraires disparaîtront après un redémarrage et la connectivité sera perdue. |
Les paramètres réseau supplémentaires suivants ont également été configurés :
- La case à cocher Enregistrer les adresses de cette connexion dans le système DNS est activé pour chaque carte de réseau MAPI et désactivée pour chaque carte du réseau de réplication.
- Au moins une adresse de serveur DNS est configurée pour chaque carte de réseau MAPI et aucune n’est configurée pour les cartes du réseau de réplication. Aux fins de redondance, Contoso utilise plusieurs adresses de serveur DNS pour leurs cartes de réseau MAPI.
- Contoso n’utilise pas le protocole IPv6 et l’a désactivé sur ses serveurs.
- Contoso n’utilise pas le Pare-feu Windows et l’a désactivé sur ses serveurs.
Lorsque les cartes réseau ont été configurées, Contoso est prêt à créer un DAG et à ajouter les serveurs de boîtes aux lettres à ce DAG.
Création et configuration du groupe de disponibilité de base de données
L’administrateur a décidé de créer un script d’interface de ligne de commande Windows PowerShell qui effectue plusieurs tâches :
- Il utilise la cmdlet New-DatabaseAvailabilityGroup pour créer le DAG. Comme SITEA est considéré comme le centre de données principal, Contoso a choisi d’utiliser un serveur témoin dans le même centre de données : HUB-A.
- Il utilise la cmdlet Set-DatabaseAvailabilityGroup pour préconfigurer un serveur témoin et un répertoire témoin de remplacement si un basculement de site s’avérait nécessaire.
- Il utilise la cmdlet Add-DatabaseAvailabilityGroupServer pour ajouter chacun des quatre serveurs de boîtes aux lettres au DAG.
- Il utilise la cmdlet Set-DatabaseAvailabilityGroup pour configurer le groupe de disponibilité de base de données en mode DAC. Pour plus d’informations sur le mode DAC, consultez la rubrique Présentation du mode d'activation et de coordination de centre de données.
Les commandes utilisées dans le script sont les suivantes :
New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer HUB-A -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8
La commande précédente crée un groupe de disponibilité de base de données nommé DAG1, configure Hub-A comme serveur témoin, configure un répertoire témoin spécifique (C:\DAGWitness\DAG1.contoso.com), puis configure deux adresses IP pour le DAG (une pour chaque sous-réseau du réseau MAPI).
Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer HUB-B
La commande précédente configure DAG1 pour qu’il utilise un serveur témoin de remplacement de Hub-B ainsi qu’un répertoire témoin de remplacement sur Hub-B qui utilise le même chemin d’accès que celui configuré sur Hub-A.
| Remarque : |
|---|
| L’utilisation d’un chemin d’accès identique n’est pas obligatoire ; Contoso a choisi cette option pour standardiser la configuration de son organisation. |
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1B
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2B
Les commandes précédentes ajoutent chaque serveur de boîtes aux lettres au DAG, un par un. Les commandes installent également le composant Clustering avec basculement Windows sur chaque serveur de boîtes aux lettres (s’il n’est pas déjà installé), créent un cluster et rattachent chaque serveur de boîtes aux lettres au cluster qui vient d’être créé.
Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly
La commande précédente active le mode DAC pour le groupe de disponibilité de base de données.
Bases de données de boîte aux lettres et copies de base de données de boîtes aux lettres
Lorsque le DAG a été créé et les serveurs de boîtes aux lettres ajoutés à ce DAG, Contoso prépare la création des bases de données de boîtes aux lettres et de leurs copies. Pour répondre aux critères de tolérance aux pannes, Contoso prévoit de configurer chaque base de données de boîtes aux lettres avec trois copies non retardées et une copie retardée. La copie retardée sera configurée avec un délai de relecture de journal de trois jours.
Cette configuration fournit au total quatre copies de chaque base de données (une active, deux passives non retardées et une passive retardée). Contoso prévoit d’avoir quatre bases de données actives par serveur. Avec quatre bases de données actives par serveur et trois copies passives de chaque base de données, la solution Contoso contient en tout 16 copies de base de données.
Comme l’illustre la figure suivante, Contoso adopte une approche équilibrée de l’agencement de ses bases de données.
Agencement des copies de bases de données pour Contoso, Ltd
.gif "Disposition de la copie de la base de données pour Contoso, Ltd")
Chaque serveur de boîtes aux lettres héberge une copie active de base de données de boîtes aux lettres, deux copies passives non retardées et une copie passive retardée. La copie retardée de chaque base de données de boîtes aux lettres active est hébergée sur un serveur de boîtes aux lettres dans l’autre site.
Pour créer cette configuration, l’administrateur exécute plusieurs commandes.
Sur MBX1A, exécutez les commandes suivantes.
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -SuspendComment "Seed from MBX2B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX1B -SourceServer MBX2B
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -ActivationOnly
Sur MBX2A, exécutez les commandes suivantes.
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX2B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -SuspendComment "Seed from MBX1B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX2B -SourceServer MBX1B
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -ActivationOnly
Sur MBX1B, exécutez les commandes suivantes.
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -SuspendComment "Seed from MBX2A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1A -SourceServer MBX2A
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -ActivationOnly
Sur MBX2B, exécutez les commandes suivantes.
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -SuspendComment "Seed from MBX1A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2A -SourceServer MBX1A
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -ActivationOnly
Dans les exemples précédents de la cmdlet Add-MailboxDatabaseCopy, le paramètre ActivationPreference n’était pas spécifié. La tâche incrémente automatique le numéro de préférences d’activation à chaque copie ajoutée. Le numéro de préférence 1 est toujours attribué à la base de données d’origine. Le numéro de préférence 2 est attribué automatiquement à la première copie ajoutée par la cmdlet Add-MailboxDatabaseCopy. Si aucune copie n’est supprimée, le numéro de préférence 3 est automatiquement attribué à la prochaine copie ajoutée, et ainsi de suite. Dans les exemples précédents, le numéro de préférence 2 est donc attribué à la copie passive dans le même centre de données que la copie active, le numéro de préférence 3 est attribué à la copie passive non retardée dans le centre de données distant et le numéro de préférence 4 est attribué à la copie passive retardée dans le centre de données distant.
Bien qu’il existe deux copies de chaque base de données active sur le réseau étendu de l’autre emplacement, l’amorçage sur le réseau étendu n’a été réalisé qu’une seule fois. Cela est dû au fait que Contoso exploite la capacité d’Exchange 2010 d’utiliser une copie passive de la base de données comme source d’amorçage. Le fait d’utiliser la cmdlet Add-MailboxDatabaseCopy avec le paramètre SeedingPostponed évite l’amorçage automatique de la nouvelle copie de base de données en cours de création. L’administrateur peut ensuite suspendre la copie non amorcée et, en utilisant la cmdlet Update-MailboxDatabaseCopy avec le paramètre SourceServer, il peut désigner la copie locale de la base de données comme source de l’opération d’amorçage. Il en résulte que l’amorçage de la deuxième copie de base données ajoutée à chaque emplacement se déroule au niveau local et non pas sur le réseau étendu.
| Remarque : |
|---|
| Dans l’exemple précédent, la copie de base de données non retardée est amorcée sur le réseau étendu et cette copie est ensuite utilisée pour amorcer la copie retardée de la base de données située dans le même centre de données que la copie non retardée. |
Contoso a configuré une des copies passives de chaque base de données de boîtes aux lettres pour qu’elle serve de protection contre l’éventualité, rare mais catastrophique, d’une corruption logique de la base de données. Par conséquent, l’administrateur utilise la cmdlet Suspend-MailboxDatabaseCopy et le paramètre ActivationOnly pour configurer les copies retardées comme étant bloquées pour l’activation. Ceci garantit que les copies de bases de données retardées ne seront pas activées si un basculement de base de données ou de serveur devait se produire.
Validation de la solution
Une fois la solution déployée et configurée, l’administrateur effectue plusieurs tâches validant l’état de préparation de la solution avant de déplacer les boîtes aux lettres de production vers les bases de données du groupe de disponibilité de base de données. La solution doit être soumise à des tests et des inspections, en faisant appel à plusieurs méthodes et notamment des simulations de défaillance. Pour valider la solution, l’administrateur effectue plusieurs tâches.
Pour vérifier l’intégrité globale du groupe de disponibilité de base de données, l’administrateur exécute la cmdlet Test-ReplicationHealth. Cette cmdlet vérifie plusieurs aspects de l’état de réplication et de relecture pour fournir des informations sur chaque serveur de boîtes aux lettres et chaque copie de base de données du groupe de disponibilité de base de données.
Pour vérifier l’activité de réplication et de relecture, l’administrateur exécute la cmdlet Get-MailboxDatabaseCopyStatus. Cette cmdlet peut fournir des informations en temps réel sur l’état d’une copie spécifique de base de données de boîtes aux lettres ou de l’ensemble des copies de bases de données de boîtes aux lettres sur un serveur précis. Pour plus d’informations sur la surveillance de l’intégrité et l’état des bases de données répliquées dans DAG, consultez la rubrique Analyse de la haute disponibilité et de la résilience de site.
Pour vérifier que les basculements fonctionnent comme prévu, l’administrateur utilise la cmdlet Move-ActiveMailboxDatabase pour exécuter une série de basculements de bases de données et de serveurs. Une fois ces tâches réalisées avec succès, l’administrateur utilise la même cmdlet pour déplacer les copies actives de bases de données vers leurs emplacements d’origine.
Pour vérifier les comportements attendus dans divers scénarios de défaillance, l’administrateur effectue plusieurs tâches destinées à simuler une défaillance ou à provoquer une véritable défaillance. Par exemple :
- Débrancher le cordon d’alimentation sur MBX1A, déclenchant ainsi un basculement de serveur. L’administrateur vérifie alors que la base de données DB1 s’active sur un autre serveur (de préférence MBX2A, sur la base des numéros des préférences d’activation).
- Débrancher le câble réseau de la carte réseau MAPI sur MBX2A, déclenchant ainsi un basculement de serveur. L’administrateur vérifie alors que la base de données DB2 s’active sur un autre serveur (de préférence MBX1A, sur la base des numéros des préférences d’activation).
- Mettre hors connexion le disque utilisé par la copie active de la base de données, déclenchant ainsi un basculement de base de données. L’administrateur vérifie alors que la base de données DB3 s’active sur un autre serveur (de préférence MBX2B, sur la base des numéros des préférences d’activation).
Une organisation peut aussi tester d’autres scénarios de défaillance en fonction de ses besoins. A la suite de la simulation d’une seule défaillance (par exemple, débrancher le cordon d’alimentation) et de l’observation de la capacité de récupération de la solution, l’administrateur peut opter pour un retour à la configuration d’origine. Dans certains cas, la solution peut être testée pour résister à plusieurs défaillances simultanées. En fin de compte, votre plan de tests vous indiquera si la solution doit revenir à sa configuration d’origine après avoir réalisé chaque simulation de défaillance.
En outre, un administrateur peut décider de débrancher la connexion réseau entre deux centres de données pour simuler une défaillance de site. La réalisation d’un basculement de centre de données est une opération plus complexe exigeant une plus grande coordination, mais elle est recommandée si la solution en cours de déploiement doit apporter la résilience de site aux services et données de messagerie. Pour plus d’informations sur les basculements de centres de données, consultez la rubrique Switchovers de centre de données.
Transition vers le mode d’exploitation
Une fois la solution déployée, son extension peut être poursuivie au moyen du déploiement incrémentiel. A ce stade, la gestion de la solution doit se tourner vers des processus d’exploitation impliquant l’exécution des tâches suivantes :
- Surveiller l’intégrité et l’état des groupes de disponibilité de base de données et des copies de bases de données de boîte aux lettres. Pour plus d’informations, voir Analyse de la haute disponibilité et de la résilience de site.
- Procéder à des basculements de bases de données et de serveurs en fonction des besoins. Pour obtenir des instructions détaillées sur le basculement de base de données, consultez la rubrique Activer une copie de la base de données de boîtes aux lettres. Pour obtenir des instructions détaillées sur le basculement de serveur, consultez la rubrique Effectuer un basculement de serveur. Le cas échéant, initiez un basculement de centre de données. Pour plus d’informations sur les basculements de centres de données, consultez la rubrique Switchovers de centre de données.
Pour plus d’informations sur la gestion de la solution, consultez la rubrique Gestion de la haute disponibilité et de la résilience de site.