Déploiement de la haute disponibilité et de la résilience des sites dans Exchange Server

Microsoft Exchange Server utilise le concept de déploiement incrémentiel pour la haute disponibilité et la résilience du site. Il vous suffit d’installer deux ou plusieurs serveurs de boîtes aux lettres Exchange en tant que serveurs autonomes, puis de les configurer de manière incrémentielle et les bases de données de boîtes aux lettres pour une haute disponibilité et une résilience de site, si nécessaire.

Vue d’ensemble du processus de déploiement

Bien que les étapes réelles utilisées par chaque organisation puissent varier légèrement, le processus global de déploiement de Exchange Server dans une configuration hautement disponible ou résiliente au site est généralement le même. 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 :

1. Créer un groupe de disponibilité de base de données. Pour obtenir la procédure détaillée, voir Créer un groupe de disponibilité de base de données. Il est important de noter que tous les serveurs d’un DAG doivent exécuter la même version d’Exchange. Par exemple, vous ne pouvez pas combiner des serveurs Exchange 2013 et Exchange 2016 dans le même DAG.

2. Si nécessaire, préparer l'objet réseau de cluster (CNO). Une préparation de l'objet réseau de cluster est nécessaire lors du déploiement d'un groupe de disponibilité de base de données avec des serveurs de boîtes aux lettres exécutant Windows Server 2012. Si vous déployez un DAG sans point d’accès administratif à l’aide de serveurs de boîtes aux lettres exécutant Windows Server 2012 R2, vous n’avez pas besoin de préphaser un CNO. La préparation est également obligatoire dans les environnements dans lesquels la création du compte d'ordinateur est restreinte ou lorsque les comptes d'ordinateur sont créés dans un conteneur autre que le conteneur d'ordinateurs par défaut. Pour obtenir la procédure détaillée, voir Préinstallation de l'objet nom de cluster pour un groupe de disponibilité de base de données.

3. Ajouter au moins deux serveurs de boîtes aux lettres au groupe de disponibilité de base de données. Pour obtenir la procédure détaillée, voir Gérer l'appartenance au groupe de disponibilité de la base de données.

4. Configurer les propriétés du groupe de disponibilité de base de données selon vos besoins :

5. Configurer éventuellement le chiffrement et la compression pour le groupe de disponibilité de base de données, la réplication de port, les adresses IP du groupe de disponibilité de base de données et d'autres propriétés relatives à ce groupe. Pour obtenir la procédure détaillée, voir Configuration des propriétés du groupe de disponibilité de base de données.

6. Activer le mode de coordination de l'activation du centre de données (DAC) pour le groupe de disponibilité de base de données. Cela permet de protéger le groupe de disponibilité de base de données contre les conditions de Split-Brain au niveau de la base de données lors d'un switchback vers le centre de données principal après un basculement, et active l'utilisation des cmdlets intégrées de récupération de groupe de disponibilité de base de données. Pour plus d'informations, consultez la rubrique Mode de coordination de l'activation du centre de données.

7. Ajouter des copies de base de données de boîtes aux lettres entre les serveurs de boîtes aux lettres du groupe de disponibilité de base de données. Pour obtenir la procédure détaillée, voir Ajout d'une copie de base de données de boîtes aux lettres.

Exemple de déploiement : Groupe de disponibilité de base de données à quatre membres dans deux centres de données

Cet exemple détaille la façon dont une organisation, Contoso, Ltd., configure et déploie un DAG à quatre membres qui sera étendu à deux emplacements physiques : Boston et Oklahoma City.

Infrastructure de base

Chaque emplacement contient les éléments d’infrastructure nécessaires au fonctionnement d’une infrastructure de messagerie basée sur Exchange Server, à savoir :

• Services d'annuaire (Active Directory ou services de domaine Active Directory (AD DS))

• Résolution de noms DNS (Domain Name System)

• Plusieurs serveurs Exchange exécutant des services d’accès au client

• Plusieurs serveurs de boîtes aux lettres Exchange

La figure suivante illustre la configuration de l'organisation Contoso.

Configuration 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 groupe de disponibilité de base de données dispose de deux cartes réseau sur des sous-réseaux distincts. Dans chaque serveur de boîtes aux lettres, une carte réseau est utilisée pour le réseau MAPI (192.168. x. x) et une carte réseau seront utilisés 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 groupe de disponibilité de base de données.

Le tableau suivant présente en détail les paramètres de chaque carte réseau dans chacun des nœuds.

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 de réseau de réplication, Contoso utilise des itinéraires statiques permanents, configurés au moyen de l'outil Netsh.exe.

Pour configurer le routage des cartes de réseau de réplication sur MBX1 et MBX2, la commande suivante a été exécutée sur chaque serveur.

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

Pour configurer le routage des cartes de réseau de réplication sur MBX3 et MBX4, la commande suivante a été exécutée sur chaque serveur.

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

Les paramètres réseau supplémentaires suivants ont également été configurés :

• La case Enregistrer les adresses de cette connexion dans le système DNS est cochée pour la carte réseau de chaque membre du groupe de disponibilité de base de données et désactivée pour chaque carte de réseau de réplication.

• Au moins une adresse de serveur DNS est configurée pour la carte de réseau MAPI de chaque membre de groupe de disponibilité de base de données ; aucune adresse n'est configurée pour les cartes de réseau de réplication. À des fins de redondance, Contoso utilise plusieurs adresses de serveur DNS pour leurs cartes de réseau MAPI.

• 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 groupe de disponibilité de base de données et à y ajouter les serveurs de boîtes aux lettres.

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 groupe de disponibilité de base de données. Étant donné que BOSTON 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, à savoir MBX5.

• 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 centre de données s'avérait nécessaire.

• Il utilise la cmdlet Add-DatabaseAvailabilityGroupServer pour ajouter chacun des quatre serveurs de boîtes aux lettres au groupe de disponibilité de base de données.

• 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, voir Mode de coordination de l'activation du centre de données.

Les commandes utilisées dans le script sont les suivantes :

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer MBX5 -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

La commande précédente crée le DAG DAG1, configure MBX5 comme serveur témoin, configure un répertoire témoin spécifique (C:\DAGWitness\DAG1.contoso.com) et configure deux adresses IP pour le DAG (une pour chaque sous-réseau sur le réseau MAPI).

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer MBX10

La commande précédente configure DAG1 pour utiliser un autre serveur témoin MBX10 et un autre répertoire témoin sur MBX10 qui utilise le même chemin que celui configuré sur MBX5.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX3
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX4

Les commandes précédentes ajoutent chaque serveur de boîtes aux lettres au groupe de disponibilité de base de données, un par un. Elles installent également le composant Clustering avec basculement Windows sur chaque serveur de boîtes aux lettres (s'il n'est pas encore installé), créent un cluster de basculement et rattachent chaque serveur de boîtes aux lettres au nouveau cluster.

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îtes aux lettres et copies de bases de données de boîtes aux lettres

Lorsque le groupe de disponibilité de base de données a été créé et que les serveurs de boîtes aux lettres ont été ajoutés à ce groupe, 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 réexécution 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. Par conséquent, la solution Contoso contient 16 copies de base de données au total.

Comme l'illustre la figure suivante, Contoso adopte une approche équilibrée pour l'agencement de ses bases de données.

Agencement des copies de bases 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 MBX1, exécutez les commandes suivantes :

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -SuspendComment "Seed from MBX4" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX3 -SourceServer MBX4
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -ActivationOnly

Sur MBX2, exécutez les commandes suivantes :

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX4 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -SuspendComment "Seed from MBX3" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX4 -SourceServer MBX3
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -ActivationOnly

Sur MBX3, exécutez les commandes suivantes :

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -SuspendComment "Seed from MBX2" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1 -SourceServer MBX2
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -ActivationOnly

Sur MBX4, exécutez les commandes suivantes :

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -SuspendComment "Seed from MBX1" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2 -SourceServer MBX1
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -ActivationOnly

Dans les exemples précédents pour l’applet de commande Add-MailboxDatabaseCopy , le paramètre ActivationPreference n’a pas été spécifié. La tâche incrémente automatiquement 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 tire parti de la capacité Exchange Server d’utiliser une copie passive d’une base de données comme source pour l’amorçage. L’utilisation de l’applet de commande Add-MailboxDatabaseCopy avec le paramètre SeedingPostponed empêche la tâche d’amorcer automatiquement la nouvelle copie de base de données en cours de création. Ensuite, l’administrateur peut suspendre la copie non amorcée et, à l’aide de l’applet de commande Update-MailboxDatabaseCopy avec le paramètre SourceServer , l’administrateur peut spécifier 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 de données ajoutée à chaque emplacement se déroule au niveau local et non sur le réseau étendu.

Contoso a configuré une des copies passives de chaque base de données de boîtes aux lettres en tant que copie retardée pour qu'elle serve de protection dans l'éventualité, rare mais catastrophique, d'une corruption logique de la base de données. Par conséquent, l’administrateur configure les copies en retard comme bloquées pour l’activation à l’aide de l’applet de commande Suspend-MailboxDatabaseCopy avec le paramètre ActivationOnly . 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 réexécution 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 réexécution, 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 sur 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 de l’état des bases de données répliquées dans un DAG, consultez Surveiller les groupes de disponibilité de base de données.

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, il utilise la même cmdlet pour déplacer les copies actives de bases de données vers leur emplacement 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 MBX1, 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 MBX2, sur la base des numéros de préférence d'activation).

• Débrancher le câble réseau de la carte réseau MAPI sur MBX2, 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 MBX1, sur la base des numéros de préférence d'activation).

• Mettre hors connexion le disque utilisé par la copie active de la base de données (DB3), 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 MBX4, sur la base des numéros de préférence d'activation).

Une organisation peut aussi tester d'autres scénarios de défaillance en fonction de ses besoins. À 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 s'il faut rétablir la configuration d'origine de la solution 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.

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. À 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îtes aux lettres. Pour plus d’informations, consultez Surveiller les groupes de disponibilité de base de données.

• Effectuer les basculements de base de données si cela est nécessaire. Pour connaître la procédure détaillée d'exécution d'un basculement de base de données, voir Activer une copie de la base de données de boîtes aux lettres.

Pour plus d'informations sur la gestion de la solution, voir Gestion de la haute disponibilité et de la résilience de site.