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

S’APPLIQUE À :2016 2019

Microsoft Exchange Server utilise le concept de déploiement incrémentiel pour la haute disponibilité et la résilience du site. Vous installez au moins deux serveurs de boîtes aux lettres Exchange en tant que serveurs autonomes, puis vous les configurez de manière incrémentielle et les bases de données de boîtes aux lettres pour la haute disponibilité et la résilience du site, selon les besoins.

Vue d’ensemble du processus de déploiement

Bien que les étapes réelles utilisées par chaque organization puissent varier légèrement, le processus global de déploiement de Exchange Server dans une configuration hautement disponible ou résiliente de 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 :

   1. 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.

   2. Activer le mode de coordination de l'activation du centre de données (DAC) pour le groupe de disponibilité de base de données. Cette action présente les avantages suivants :

      • Protège le DAG contre les conditions de fractionnement du cerveau au niveau de la base de données pendant le basculement vers le centre de données principal après le basculement d’un centre de données.
      • Active l’utilisation des applets de commande de récupération DAG intégrées.

      Pour plus d'informations, consultez la rubrique Mode de coordination de l'activation du centre de données.

5. 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 Contoso, Ltd. configure et déploie un DAG à quatre membres é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 est utilisée pour le réseau de réplication (10.0. x. x). Seul le réseau MAPI fournit une connectivité à Active Directory, aux services DNS, aux autres serveurs Exchange et aux clients. 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.

Nom	Adresse IPv4	Masque de sous-réseau	Passerelle par défaut
MBX1 (MAPI)	192.168.1.4	255.255.255.0	192.168.1.1
MBX2 (MAPI)	192.168.1.5	255.255.255.0	192.168.1.1
MBX3 (MAPI)	192.168.2.4	255.255.255.0	192.168.2.1
MBX4 (MAPI)	192.168.2.5	255.255.255.0	192.168.2.1
MBX1 (réplication)	10.0.1.4	255.255.255.0	Aucun
MBX2 (réplication)	10.0.1.5	255.255.255.0	Aucun
MBX3 (réplication)	10.0.2.4	255.255.255.0	Aucun
MBX4 (réplication)	10.0.2.5	255.255.255.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 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 suivants sont également 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 donc désactivé sur ses serveurs.

Une fois les cartes réseau configurées, Contoso est prêt à créer un DAG et à ajouter les serveurs de boîtes aux lettres au 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 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 pour qu’il agisse en tant que 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 avec les paramètres suivants :

• Utilisez MBX10 comme autre serveur témoin.
• Utilisez un autre répertoire témoin sur MBX10 avec le même chemin que MBX5.

Conseil

L’utilisation du même chemin d’accès n’est pas obligatoire. Contoso utilise le même chemin pour normaliser sa configuration.

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 effectuent les actions suivantes :

• Ajoutez chacun des serveurs de boîtes aux lettres, un par un, au DAG.
• Installez le composant Clustering de basculement Windows sur chaque serveur de boîtes aux lettres (s’il n’est pas déjà installé).
• Créez un cluster de basculement.
• Joignez chaque serveur de boîtes aux lettres au cluster nouvellement 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î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 a un délai de relecture de journal configuré 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 Add-MailboxDatabaseCopy précédents, nous n’avons pas utilisé le paramètre ActivationPreference , car la tâche incrémente automatiquement le numéro de préférence d’activation avec chaque copie ajoutée :

• Le numéro de préférence 1 est toujours attribué à la base de données d'origine.
• La première copie ajoutée reçoit automatiquement un numéro de préférence de 2.
• En supposant qu’aucune copie n’est supprimée, la copie suivante ajoutée se voit automatiquement attribuer un numéro de préférence de 3, et ainsi de suite.

Ainsi, dans les exemples Add-MailboxDatabaseCopy précédents :

• La copie passive dans le même centre de données que la copie active a un nombre de préférence d’activation de 2.
• La copie passive non-décalage dans le centre de données distant a un nombre de préférences d’activation de 3.
• La copie passive en retard dans le centre de données distant a un nombre de préférence d’activation de 4.

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. Contoso utilise la Exchange Server possibilité d’utiliser une copie passive d’une base de données comme source d’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.
• L’administrateur peut suspendre la copie non amorcée.
• À 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.

Remarque

Dans l’exemple précédent, la copie de base de données non-décalage est amorcée sur le wan. Cette copie est utilisée pour amorcer la copie en retard de la base de données dans le même centre de données que la copie non-décalage.

Contoso a configuré l’une des copies passives de chaque base de données de boîtes aux lettres en tant que copie de base de données en retard pour fournir une protection contre le cas extrêmement rare mais catastrophique d’altération 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 . Cette configuration garantit que les copies de base de données en retard ne sont pas activées en cas de basculement de base de données ou de serveur.

Validation de la solution

Une fois la solution déployée et configurée, l’administrateur effectue plusieurs tâches qui valident la préparation de la solution avant de déplacer les boîtes aux lettres de production vers les bases de données du DAG. 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 la status 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 terminées, l’administrateur utilise la même applet de commande pour déplacer les copies de base de données actives 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ébranchez le cordon d’alimentation sur MBX1, ce qui déclenche 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ébranchez le câble réseau de la carte réseau MAPI sur MBX2, ce qui déclenche 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).

• Placez le disque utilisé par la copie active de DB3 hors connexion, ce qui déclenche 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).

Un organization peut tester d’autres scénarios de défaillance, en fonction des besoins de l’entreprise. Après avoir simulé une seule défaillance (comme l’extraction de la prise d’alimentation) et vérifié le comportement de récupération de la solution, l’administrateur peut rétablir la configuration d’origine de la solution. Dans certains cas, la solution peut être testée pour plusieurs échecs simultanés. En fin de compte, votre plan de test de solution détermine si la solution est rétablie à sa configuration d’origine après chaque simulation de défaillance.

En outre, un administrateur peut décider de déconnecter la connexion réseau entre les deux centres de données, ce qui simule 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, elle peut être étendue à l’aide d’un 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.