Haute disponibilité et résilience de site

S’applique à : Exchange Server 2013

Vous pouvez protéger vos bases de données de boîtes aux lettres Exchange Server 2013 et les données qu'elles contiennent en configurant vos bases de données et serveurs de boîtes aux lettres pour la haute disponibilité et la résilience de site. Exchange 2013 réduit les coûts et la complexité du déploiement d'une solution de messagerie à hautes disponibilité et résilience, tout en fournissant des niveaux de disponibilité de données et de service élevés et en prenant en charge les boîtes aux lettres volumineuses.

Exchange 2013 permet aux clients de toutes tailles et de tous segments de déployer économiquement un service de messagerie en continu dans leur organisation en tirant parti des capacités de réplication natives et de l'architecture à haute disponibilité présentées dans Exchange 2010. Pour obtenir la liste des différences entre Exchange 2010 et Exchange 2007, voir 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 qui s’exécute à l’intérieur du service de réplication Microsoft Exchange responsable de la surveillance des défaillances 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 par la copie en cours de montage.

• Réplication continue - mode bloc : en mode bloc, à mesure que chaque mise à jour est écrite dans la mémoire tampon de journal active de la copie de base de données active, elle est également envoyée à une mémoire tampon de journal sur chacune des copies de boîte aux lettres passives en mode bloc. 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.

• Réplication continue - mode fichier : en mode fichier, les fichiers journaux des transactions fermés sont envoyés de la copie de base de données active à une ou plusieurs copies de base de données passives.

• Groupe de disponibilité de base de données : groupe de 16 serveurs de boîtes aux lettres Exchange 2013 maximum qui héberge un ensemble de bases de données répliquées.

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

• Centre de données : il s’agit généralement d’un site Active Directory. Toutefois, il peut également faire référence à un site physique. Dans le cadre de cette documentation, « centre de données » équivaut à « site Active Directory ».

• Mode coordination de l’activation du centre de données : propriété du paramètre DAG qui, lorsqu’il est activé, force le service de réplication Microsoft Exchange à acquérir l’autorisation de monter des bases de données au démarrage.

• Récupération d’urgence : tout processus utilisé pour récupérer manuellement après 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 l’utilisation de la réplication synchrone tierce pour un DAG au lieu de la réplication continue.

• Haute disponibilité : solution qui fournit la disponibilité du service, la disponibilité des données et la récupération automatique en cas de défaillances affectant le service ou les données (par exemple, une défaillance de réseau, de stockage ou de serveur).

• Déploiement incrémentiel : possibilité de déployer la haute disponibilité et la résilience du site après l’installation d’Exchange 2013.

• Copie de base de données de boîtes aux lettres différée : copie passive de la base de données de boîtes aux lettres dont le délai de relecture du journal est supérieur à zéro.

• Copie de base de données de boîte aux lettres : base de données de boîtes aux lettres (fichier .edb et journaux), qui est 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 2013.

• Disponibilité managée : ensemble de processus internes composés de sondes, de moniteurs et de répondeurs qui intègrent la supervision et la haute disponibilité sur tous les rôles de 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.

• Filet de sécurité : anciennement appelé 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 fantôme : fonctionnalité de serveur de transport qui fournit une redondance pour les messages pendant toute la durée de leur transit.

• Résilience du site : configuration qui étend l’infrastructure de messagerie à plusieurs sites Active Directory pour assurer la continuité opérationnelle du système de messagerie en cas de défaillance 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 2013. Un DAG est un groupe de 16 serveurs de boîtes aux lettres maximum qui hébergent 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 Groupes de disponibilité de base de données (DAG).

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

Les fonctions de haute disponibilité et de résilience de site intégrées pour la première fois dans Exchange 2010 sont utilisées dans Exchange 2013 pour créer et gérer les copies de base de données. Exchange 2013 exploite également le concept de mobilité de base de données, à savoir 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. Lorsqu'un basculement se produit, les autres serveurs Exchange 2013 en sont informés 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 de boîtes aux lettres dans le groupe de disponibilité de base de données. Dans Exchange 2013, la disponibilité gérée ajoute de nouveaux comportements pour récupérer d'une perte d'accès du protocole à une base de données, y compris le recyclage des pools de processus d'application, le redémarrage des services et des serveurs, et le lancement des 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 2013 utilise le composant Active Manager intégré pour la première fois dans Exchange 2010 pour gérer l'intégrité, l'état, la réplication continue de la base de données et de la copie de base de données, ainsi que les autres aspects de la haute disponibilité du serveur de boîtes aux lettres. Pour plus d'informations sur Active Manager, consultez la rubrique Active Manager.

Résilience de site

Même si Exchange 2013 continue à utiliser les DAG et le clustering avec basculement Windows pour la haute disponibilité et la résilience de site du rôle serveur de boîtes aux lettres, la résilience de site n'est pas identique dans Exchange 2013. La résilience de site est bien meilleure dans Exchange 2013, car elle a été simplifiée. Les changements architecturaux sous-jacents qui ont été effectués dans Exchange 2013 ont un impact significatif sur les éléments de récupération d'une configuration de résilience de site.

Dans Exchange 2010, la récupération de boîte aux lettres (DAG) et d'accès au client (groupe de serveurs d'accès au client) étaient liés. Si vous perdiez tous vos serveurs d'accès au client ou l'adresse IP virtuelle pour le groupe, ou si vous perdiez une partie importante de votre DAG, vous étiez dans l'obligation de procéder à un basculement de centre de données. Il s'agit d'un processus bien documenté et généralement bien compris, même si sa réalisation prend du temps et qu'une intervention humaine est nécessaire pour lancer le processus.

Dans Exchange 2013, si vous perdez votre groupe de serveurs d'accès au client pour une raison quelconque (par exemple, suite à un échec de l'équilibrage de charge), vous ne devez pas effectuer de basculement de centre de données. Si la configuration est correcte, le basculement s'effectue au niveau du client et les clients sont automatiquement redirigés vers un deuxième centre de données comportant des serveurs d'accès au client opérationnels, lesquels renvoient par proxy les communications vers le serveur de boîtes aux lettres de l'utilisateur, qui n'est pas touché par l'interruption (car vous n'effectuez aucun basculement). Vous n'avez pas besoin de travailler à la récupération du service, car le service se restaure lui-même de façon à ce que vous puissiez vous concentrer sur la résolution de l'erreur principale (par exemple, le remplacement de l'équilibrage de charge défaillant).

De plus, avec la simplification de l'espace de noms, la consolidation des rôles serveur, la dissociation des conditions requises du rôle serveur de site Active Directory, la séparation de la récupération du DAG et du groupe de serveurs d'accès au client, mais aussi avec les modifications apportées à l'équilibrage de charge, les changements apportés à Exchange 2013 permettent désormais de récupérer le groupe de serveurs d'accès au client et le DAG séparément et automatiquement sur tous les sites, offrant de ce fait des scénarios de basculement de centre de données si vous avez trois emplacements.

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'obteniez pas le basculement de la solution proprement dite, car l'espace de noms devait toujours être manuellement modifié pour les rôles autres que serveur de boîtes aux lettres.

Dans Exchange 2013, 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.

L'une des modifications apportées à Exchange 2013 est de permettre aux clients d'accéder à plusieurs emplacements. Si l'on suppose que le client peut accéder à plusieurs emplacements (presque tous les protocoles d'accès au client dans Exchange 2013 sont basés sur HTTP -par exemple, Outlook, Outlook Anywhere, EAS, EWS, OWA et CAE- et 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 en 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 2010, si vous perdiez l'équilibrage de charge dans votre centre de données principal et n'en aviez pas d'autre sur ce site, vous deviez effectuer un basculement de centre de données. Dans Exchange 2013, si vous perdez l'équilibrage de charge dans votre site principal, il suffit de le désactiver (ou de désactiver l'adresse IP virtuelle), puis de le réparer ou le remplacer. 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 2013, cette opération n'est pas nécessaire, 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 d'accès au client 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 2013 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 de détails sur la planification et le déploiement de la résilience de site, consultez les rubriques Planification d'une haute disponibilité et d'une résilience de site et Déploiement de haute disponibilité et de résilience de site.

API de réplication tierce

Exchange 2013 comprend également une API de réplication tierce qui permet aux organisations d'utiliser des solutions de réplication synchrone tierces à la place de la fonctionnalité intégrée de réplication continue. 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 les liens vers les rubriques qui vous aideront à comprendre le fonctionnement et la gestion des DAG, des copies de base de données de boîtes aux lettres, mais aussi de la sauvegarde et de la restauration pour Exchange 2013.