Haute disponibilité et résilience des sites dans Exchange Server

  • Article

Vous pouvez protéger vos bases de données de boîte aux lettres Exchange Server et les données qu’elles contiennent en configurant vos serveurs et bases de données Exchange pour la haute disponibilité et la résilience des sites. Exchange Server réduit le coût et la complexité du déploiement d’une solution de messagerie hautement disponible et résiliente, tout en fournissant des niveaux élevés de service et de disponibilité des données et une prise en charge pour les boîtes aux lettres très volumineuses.

Exchange Server permet aux clients de toutes tailles et de tous les segments de déployer économiquement un service de continuité de messagerie dans leur organisation en s’appuyant sur les fonctionnalités de réplication native et l’architecture de haute disponibilité introduites dans Exchange 2010. Pour obtenir la liste des différences depuis Exchange 2010, consultez la rubrique Modifications apportées à la haute disponibilité et la résilience de site par rapport aux versions précédentes.

Terminologie clé

Les termes clés suivants sont importants pour comprendre la haute disponibilité et la résilience de site :

Active Manager

Composant Exchange interne exécuté dans le service de réplication Microsoft Exchange qui est responsable de la surveillance des échecs et de l'action corrective via le basculement au sein d'un groupe de disponibilité de base de données (DAG).

AutoDatabaseMountDial

Paramètre de propriété d'un serveur de boîtes aux lettres qui détermine si une copie de base de données passive sera automatiquement montée en tant que nouvelle copie active, en fonction du nombre de fichiers journaux manquants pour la copie montée.

Mode Réplication continue - blocage

En mode blocage, chaque fois qu'une mise à jour est enregistrée dans le tampon journal actif de la copie de la base de données active, elle est envoyée dans le tampon journal de chacune des copies de base de données de boîtes aux lettres passives. Lorsque le tampon journal est plein, chaque copie de base de données constitue, inspecte et crée le fichier journal suivant dans la séquence de génération.

Mode Réplication continue - fichier

En mode fichier, les fichiers du journal des transactions fermé sont envoyés de la copie de base de données active vers une ou plusieurs copies de base de données passives.

Groupe de disponibilité de base de données

Groupe de 16 serveurs Exchange maximum qui héberge un ensemble de bases de données répliquées.

Mobilité de la base de données

La capacité d’une base de données de boîtes aux lettres Exchange Server à être répliquée et montée sur d’autres serveurs Exchange.

Datacenter

En général, il s'agit d'un site Active Directory, mais il peut aussi s'agir d'un site physique. Dans le cadre de cette documentation, « centre de données » équivaut à « site Active Directory ».

mode de coordination de l'activation du centre de données

Propriété du paramètre DAG qui, s'il est activé, force le service de réplication Microsoft Exchange à obtenir l'autorisation permettant de monter les bases de données au démarrage.

Récupération d’urgence

Tout processus utilisé pour récupérer manuellement suite à une défaillance. Il peut s'agir d'une défaillance qui affecte un seul élément ou un emplacement physique complet.

API de réplication tierce Exchange

API fournie par Exchange qui permet d'utiliser une réplication synchrone tierce pour un groupe de disponibilité de base de données au lieu de la réplication continue.

Disponibilité élevée

Solution qui fournit la disponibilité du service et des données et qui récupère automatiquement suite à des défaillances affectant le service ou les données (telle qu'une défaillance du réseau, de stockage ou du serveur).

Déploiement incrémentiel

La possibilité de déployer la haute disponibilité et la résilience du site après l’installation de Exchange Server.

Copie retardée de la base de données de boîtes aux lettres

Copie d'une base de données de boîtes aux lettres dont le retard de relecture du journal est supérieur à zéro.

Copie de base de données de boîtes aux lettres

Base de données de boîtes aux lettres (fichier .edb et journaux) active ou passive.

Résilience de boîte aux lettres

Nom d’une solution unifiée de haute disponibilité et de résilience de site dans Exchange Server.

Gestion de la disponibilité

Ensemble de processus internes constitué de sondes, d'analyseurs et de répondeurs qui intègrent la surveillance et la haute disponibilité dans tous les rôles serveur et tous les protocoles.

*over (prononcé « étoile au-dessus »)

Abréviation pour les basculements et les basculements. Un basculement est une activation manuelle d'une ou de plusieurs copies de bases de données. Un failover est une activation automatique d'une ou de plusieurs copies de bases de données.

Safety Net

Anciennement appelée benne à ordures de transport, il s’agit d’une fonctionnalité du service de transport qui stocke une copie de tous les messages pendant X jours. Le paramètre par défaut est 2 jours.

Redondance des clichés instantanés

Fonctionnalité du serveur de transport qui fournit la redondance des messages pendant toute la durée de leur transit.

Résilience de site

Configuration qui étend l'infrastructure de messagerie à plusieurs sites Active Directory pour fournir une continuité opérationnelle au système de messagerie en cas d'échec affectant l'un des sites.

Groupes de disponibilité de base de données

Un DAG est le composant de base de l’infrastructure de haute disponibilité et de résilience de site intégrée à Exchange Server. Un DAG est un groupe de 16 serveurs Exchange maximum qui héberge un ensemble de bases de données et fournit une récupération automatique au niveau de la base de données après des défaillances affectant des bases de données, des réseaux ou des serveurs individuels. 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 du DAG pour assurer la récupération automatique des défaillances qui affectent les bases de données de boîtes aux lettres, telles qu’une défaillance de disque ou une défaillance de serveur. Pour plus d'informations sur les DAG, consultez la rubrique Database availability groups.

Copies de bases de données de boîtes aux lettres

Les fonctionnalités de haute disponibilité et de résilience de site utilisées pour la première fois dans Exchange 2010 sont utilisées dans Exchange Server pour créer et gérer des copies de base de données. Exchange Server tire également parti du concept de mobilité de base de données, qui est les basculements au niveau de la base de données gérés par Exchange.

La mobilité de base de données déconnecte les bases de données des serveurs et ajoute la prise en charge maximale de 16 copies d'une base de données unique. Elle offre également une expérience native pour la création de copies d'une base de données.

La définition d'une copie de base de données en tant que base de données de boîtes aux lettres active est appelée également basculement. Quand une défaillance affectant une base de données ou l'accès à une base de données se produit et qu'une nouvelle base de données devient la copie active, ce processus est appelé basculement. Ce processus fait également référence à une défaillance du serveur dans laquelle un ou plusieurs serveurs mettent en ligne les bases de données précédemment en ligne sur le serveur défaillant. Lors d’un basculement ou d’un basculement, d’autres serveurs Exchange prennent connaissance du basculement presque immédiatement et redirigent le trafic client et de messagerie vers la nouvelle base de données active.

Par exemple, si une base de données active dans un groupe de disponibilité de base de données échoue en raison d'une défaillance de stockage sous-jacente, Active Manager procédera à une récupération automatique en basculant une copie de base de données sur un autre serveur dans le groupe de disponibilité de base de données. Dans Exchange Server, la disponibilité managée fournit des comportements permettant de récupérer après une perte d’accès au protocole à une base de données, notamment le recyclage des pools de workers d’applications, le redémarrage des services et des serveurs et le lancement de basculements de base de données.

Pour plus d'informations sur les copies de base de données de boîtes aux lettres, consultez la rubrique Copies de bases de données de boîtes aux lettres.

Active Manager

Exchange Server utilise Active Manager pour gérer l’intégrité de la copie de base de données et de base de données, l’état, la réplication continue et d’autres aspects de la haute disponibilité. Pour plus d'informations sur Active Manager, consultez la rubrique Active Manager.

Résilience de site

Dans Exchange 2010, vous pouviez déployer un DAG dans deux centres de données et héberger le témoin dans un troisième, puis activer le basculement pour le rôle serveur de boîtes aux lettres pour l'un d'eux. Toutefois, vous n’avez pas obtenu de basculement pour la solution elle-même, car l’espace de noms devait encore être modifié manuellement pour les rôles de serveur non-boîte aux lettres.

Dans Exchange 2016 et Exchange 2019, l’espace de noms n’a pas besoin de se déplacer avec le DAG. Exchange tire parti de la tolérance de panne intégrée à l'espace de noms par le biais de plusieurs adresses IP et de l'équilibrage de charge (et, si nécessaire, de la possibilité de mettre des serveurs en service et hors service). Les clients HTTP modernes fonctionnent automatiquement avec cette redondance. La pile HTTP peut accepter plusieurs adresses IP pour un nom de domaine complet (FQDN), et si la première adresse IP qu’elle tente échoue (autrement dit, elle ne peut pas se connecter), elle essaiera l’adresse IP suivante dans la liste. En cas de défaillance logicielle (la connexion est perdue après l’établissement de la session, peut-être en raison d’une défaillance intermittente du service où, par exemple, un appareil supprime des paquets et doit être retiré du service), l’utilisateur peut avoir besoin d’actualiser son navigateur.

Cela signifie que l'espace de noms n'est plus un point de défaillance unique, comme il l'était dans Exchange 2010. Dans Exchange 2010, le point de défaillance unique le plus important dans le système de messagerie est peut-être le nom de domaine complet (FQDN) que vous donnez aux utilisateurs, car il indique où aller à l'utilisateur. Dans le paradigme Exchange 2010, il n'est pas si simple de changer l'emplacement cible de ce nom de domaine complet (FQDN), car vous devez modifier le DNS, puis gérer la latence DNS, ce qui est problématique dans certaines régions du monde. Et vous avez, dans les navigateurs, des caches de noms qui sont généralement d'environ 30 minutes, voire plus, que vous devez également prendre en compte.

Dans Exchange Server, les clients ont plusieurs endroits où aller. Presque tous les protocoles d’accès client dans Exchange Server sont basés sur HTTP. Par exemple, Outlook, EAS, EWS, Outlook sur le web et CAE. Tous les clients HTTP pris en charge peuvent utiliser plusieurs adresses IP, le basculement est possible côté client. Vous pouvez configurer DNS pour traiter plusieurs adresses IP vers un client lors de la résolution de noms. Le client demande mail.contoso.com et retourne deux adresses IP, ou quatre adresses IP, par exemple. Néanmoins, de nombreuses adresses IP retournées par le client seront utilisées de façon fiable par celui-ci. Cela s'avère bénéfique pour le client, car si l'une des adresses IP échoue, le client peut utiliser une ou plusieurs autres adresses IP pour se connecter. Si un client en essaie une mais qu'elle échoue, il patiente environ 20 secondes, puis essaie la suivante dans la liste. Ainsi, si vous perdez l'adresse IP virtuelle pour le groupe de serveurs d'accès au client, la récupération des clients s'effectue automatiquement et dans un délai d'environ 21 secondes.

Les avantages sont les suivants :

  • Dans Exchange Server, si vous perdez l’équilibreur de charge dans votre site principal, vous le désactivez simplement (ou peut-être désactivez l’adresse IP virtuelle) et réparez-le ou remplacez-le. Les clients qui n'utilisent pas encore l'adresse IP virtuelle du deuxième centre de données basculent automatiquement vers la deuxième adresse IP virtuelle sans aucune modification de l'espace de noms et du DNS. Non seulement cela signifie qu'il n'est plus nécessaire d'effectuer un basculement, mais également que tout le temps normalement associé à une récupération par basculement du centre de données n'est pas gaspillé. Dans Exchange 2010, vous deviez gérer la latence DNS (d'où la recommandation de définir la valeur de durée de vie (TTL) sur 5 minutes et l'introduction de l'URL de restauration automatique). Dans Exchange 2016 et Exchange 2019, vous n’avez pas besoin de le faire, car vous bénéficiez d’un basculement rapide (20 secondes) de l’espace de noms entre les adresses IP virtuelles (centres de données).

  • Comme vous pouvez faire basculer l'espace de noms entre des centres de données, tout ce dont vous avez besoin pour réaliser un basculement du centre de données, c'est d'un mécanisme de basculement du rôle serveur de boîtes aux lettres entre centres de données. Pour bénéficier d'un basculement automatique pour le DAG, vous concevez simplement une solution dans laquelle le DAG est uniformément réparti entre deux centres de données, puis placez le serveur témoin dans un troisième emplacement afin qu'il puisse être arbitré par des membres du DAG dans chaque centre de données, quel que soit l'état du réseau entre les centres de données contenant les membres du DAG. Si vous n'avez que deux centres de données et qu'un troisième emplacement physique n'est pas disponible, vous pouvez placer le serveur témoin sur une machine virtuelle Microsoft Azure. Pour plus d'informations, consultez la rubrique Utilisation d'une machine virtuelle Microsoft Azure comme serveur témoin du groupe de disponibilité de base de données (DAG).

  • Dans ce scénario, les efforts de l'administrateur sont axés sur la simple résolution du problème, non sur la restauration du service. Vous réparez simplement le composant défaillant, tandis que le service a été exécuté et l'intégrité préservée. L'urgence et le niveau de stress ressentis lors de la réparation d'un périphérique défaillant ne aucun commune mesure avec ce que vous ressentez lorsque vous travaillez à la restauration du service. Cela est préférable et pour l'utilisateur final et moins stressant pour l'administrateur.

Vous pouvez permettre le basculement sans devoir effectuer de switchbacks (parfois appelés par erreur « restaurations automatiques »). Si vous perdez les serveurs dans votre centre de données principal et qu'il en résulte une interruption de 20 secondes pour les clients, vous ne devez peut-être même pas effectuer de restauration automatique. À ce stade, votre première préoccupation doit être de résoudre le problème principal (par exemple, remplacer l'équilibrage de charge défaillant). Une fois que tout fonctionne à nouveau, certains clients commencent à utiliser le centre de données, tandis que d'autres restent opérationnels via le deuxième centre de données.

Exchange Server fournit également des fonctionnalités qui permettent aux administrateurs de gérer les défaillances intermittentes. Une défaillance intermittente est, par exemple, une situation où la connexion TCP initiale peut être établie, mais où ne se passe par la suite. Une défaillance intermittente nécessite une sorte d'action administrative supplémentaire, car elle peut résulter de la mise en service d'un appareil de rechange. Au cours de ce processus de réparation, l'appareil peut être allumé et accepter certaines demandes, mais ne pas être vraiment prêt à servir des clients tant que la procédure de configuration nécessaire n'a pas été réalisée. Dans ce scénario, l'administrateur peut procéder à un basculement de l'espace de noms en supprimant simplement le VIP pour l'appareil remplacé dans le DNS. Ainsi, au cours de cette période de maintenance, aucun client ne tentera de s'y connecter. Une fois le processus de remplacement terminé, l'administrateur peut rajouter l'adresse IP virtuelle au DNS, et les clients commencent à l'utiliser.

Pour plus d’informations sur la planification et le déploiement de la résilience des sites, consultez Planifier la haute disponibilité et la résilience du site et Déploiement de la haute disponibilité et de la résilience du site.

API de réplication tierce

Exchange Server inclut une API de réplication tierce qui permet aux organisations d’utiliser des solutions de réplication synchrone tierces au lieu de la fonctionnalité de réplication continue intégrée. Microsoft prend en charge des solutions tierces qui utilisent cette API pour autant qu'elles fournissent les fonctionnalités nécessaires pour remplacer toutes les fonctionnalités de réplication continue natives désactivées à cause de l'utilisation de l'API. Ces solutions sont uniquement prises en charge lorsque l'API est utilisée au sein d'un groupe de disponibilité de base de données pour gérer et activer les copies de bases de données de boîtes aux lettres. L'utilisation de l'API en dehors de ces limites n'est pas prise en charge. En outre, la solution doit satisfaire aux conditions de prise en charge du matériel Windows applicables. (aucune validation par test n'est requise pour la prise en charge.)

Lors du déploiement d'une solution qui utilise l'API de réplication tierce intégrée, sachez que le fournisseur de la solution est responsable du support technique principal de cette solution. Microsoft prend en charge les données Exchange à la fois pour les solutions répliquées et non répliquées. Les solutions qui utilisent la réplication de données doivent respecter la stratégie de support Microsoft pour la réplication des données. De plus, les solutions qui utilisent le modèle de ressources Cluster de basculement Windows doivent satisfaire aux exigences en matière de capacités de prise en charge des clusters Windows, telles que décrites dans l'article 943984 de la Base de connaissances Microsoft intitulé Stratégie de support Microsoft pour les clusters à basculement Windows Server 2008 ou dans l'article Politique de support Microsoft pour les clusters de basculement Windows Server 2012.

La stratégie de support de Microsoft en matière de sauvegarde et de restauration pour les déploiements qui utilisent des solutions API de réplication tierces est la même que pour les déploiements de réplication continue natifs.

Si vous êtes un partenaire à la recherche d'informations sur l'API tierce, contactez votre représentant Microsoft.

Documentation relative à la haute disponibilité et à la résilience de site

Le tableau suivant contient des liens vers des rubriques qui vous aideront à découvrir et à gérer les DAG, les copies de base de données de boîtes aux lettres, ainsi que la sauvegarde et la restauration pour Exchange Server.

Rubrique Description
Groupes de disponibilité de base de données En savoir plus sur les DAG, Active Manager, le mode Datacenter Activation Coordination (DAC) et les copies de base de données de boîtes aux lettres.
Planifier la haute disponibilité et la résilience des sites En savoir plus sur le fonctionnement général, le matériel, le logiciel, le serveur témoin et les autres exigences et meilleures pratiques pour les DAG.
Déploiement de haute disponibilité et de résilience de site Découvrez un exemple de scénario de déploiement pour le déploiement et la configuration des DAG.
Gestion de la haute disponibilité et de la résilience de site En savoir plus sur les tâches de gestion de DAG, les basculements, ainsi que le mode maintenance.
Surveiller les groupes de disponibilité de base de données En savoir plus sur les cmdlets et les scripts intégrés pour la surveillance des DAG et des copies de base de données.
Sauvegarde, restauration et récupération d'urgence En savoir plus sur la sauvegarde et la restauration des bases de données Exchange, les bases de données de récupération et la récupération de serveur.