Partager via

Switchovers et basculements

  • Article

S’applique à : Exchange Server 2013 SP1

Les permutations et les basculements sont deux formes de panne rencontrées dans Microsoft Exchange Server 2013.

  • Une permutation est une panne planifiée d’une base de données ou d’un serveur qui est initiée explicitement par une cmdlet ou par le système de disponibilité géré dans Exchange 2013. Les permutations sont généralement effectuées pour préparer une opération de maintenance. Les permutations impliquent le déplacement de la copie de base de données de boîtes aux lettres active vers un autre serveur du groupe de disponibilité de base de données (DAG). Si aucune cible saine n’est trouvée pendant une permutation, les administrateurs reçoivent une erreur et la base de données de boîte aux lettres reste en exécution ou montée.

  • Un basculement désigne des événements inattendus qui provoquent l’indisponibilité des services, des données ou des deux. Un basculement suppose que la défaillance du système soit automatiquement réparée en activant une copie de base de données de boîtes aux lettres passive pour la convertir en copie active. Si aucune cible saine n'est trouvée pendant un basculement, la base de données de boîte aux lettres est démontée.

Exchange 2013 est conçu pour gérer les basculements et les basculements.

Souhaitez-vous rechercher des tâches de gestion liées à la haute disponibilité et la résilience de site ? Consultez la rubrique Gestion de la haute disponibilité et de la résilience de site.

Permutations

Il existe trois types de permutation dans Exchange 2013 :

  • Permutation de base de données
  • Permutation de serveur
  • Permutation de centre de données

Permutation de base de données

Une permutation de base de données est le processus par lequel une base de données active individuelle est permutée vers une autre copie de base de données (copie passive), qui est ensuite définie comme nouvelle copie de base de données active. Les permutations de base de données peuvent se produire dans un centre de données et entre plusieurs centres de données. Un basculement de base de données peut être effectué à l’aide du Centre d’administration Exchange (EAC) ou de l’interpréteur de commandes. Quelle que soit l'interface utilisée, le processus de permutation est le suivant :

  1. L'administrateur initie une permutation de base de données pour déplacer la copie de base de données de boîtes aux lettres active vers un autre serveur.

  2. Le client utilisé pour la tâche lance un appel de procédure distante au service de réplication Microsoft Exchange sur un membre du DAG.

  3. Si le membre du DAG ne détient pas le rôle de gestionnaire Active Manager principal (PAM), il redirige la tâche vers le rôle PAM.

  4. La tâche émet un appel de procédure distante (RPC) au service de réplication Microsoft Exchange sur le serveur qui détient le rôle PAM.

  5. Le Gestionnaire Active Manager principal lit et met à jour les informations sur l'emplacement de la base de données qui sont stockées dans la base de données du cluster pour le DAG.

  6. Le Gestionnaire Active Manager principal contacte le service de réplication Microsoft Exchange sur le membre du DAG dont la copie passive est activée en tant que nouvelle copie de base de données de boîtes aux lettres active.

  7. Le service de réplication Microsoft Exchange du serveur cible interroge les services de réplication Microsoft Exchange sur tous les autres membres du DAG pour déterminer la source de journal optimale pour la copie de base de données.

  8. La base de données est démontée du serveur actuel et le service de réplication Microsoft Exchange du serveur cible copie les journaux restants vers ce dernier.

  9. Le service de réplication Microsoft Exchange du serveur cible sollicite le montage d'une base de données.

  10. Le service de banque d'informations Microsoft Exchange sur le serveur cible relit les fichiers journaux et monte la base de données.

  11. Tous les codes d'erreur sont renvoyés vers le service de réplication Microsoft Exchange du serveur cible.

  12. Le Gestionnaire Active Manager principal met à jour les informations sur l'état de la copie de base de données dans la base de données du cluster pour le DAG.

  13. Tous les codes d'erreur sont renvoyés par le service de réplication Microsoft Exchange du serveur cible vers le service de réplication Microsoft Exchange du Gestionnaire Active Manager principal.

  14. Le service de réplication Microsoft Exchange du Gestionnaire Active Manager principal renvoie toutes les erreurs vers l'interface d'administration où la tâche a été appelée.

  15. Remote PowerShell renvoie les résultats de l'opération vers l'interface d'administration appelante.

Pour connaître la procédure détaillée d'exécution d'une permutation de base de données, consultez la rubrique Activer une copie de la base de données de boîtes aux lettres.

Permutation de serveur

Une permutation de serveur est le processus par lequel toutes les bases de données actives sur un membre du DAG sont activées sur un ou plusieurs membres du DAG. Comme pour la permutation de base de données, une permutation de serveur peut se produire tant au sein d'un centre de données qu'entre plusieurs centres de données, et peut être lancée par le Centre d'administration Exchange ou l'environnement de ligne de commande Exchange Management Shell. Quelle que soit l'interface utilisée, le processus de permutation de serveur est le suivant :

  1. L'administrateur initie la permutation d'un serveur pour déplacer toutes les copies de base de données de boîtes aux lettres actives vers un ou plusieurs autres serveurs.

  2. L'opération est constituée des mêmes étapes que celles décrites plus haut dans cette rubrique pour les permutations de base de données (étapes 2 à 4), pour chacune des bases de données actives sur le serveur actuel.

  3. Le Gestionnaire Active Manager principal lit et met à jour les informations sur l'emplacement de la base de données qui sont stockées dans la base de données du cluster pour le DAG.

  4. Il contacte le service de réplication Microsoft Exchange de chaque membre du DAG sur lequel une copie passive est activée.

  5. Le service de réplication Microsoft Exchange des serveurs cible interroge les services de réplication Microsoft Exchange de tous les autres membres du DAG pour déterminer la source de journal optimale pour la copie de base de données.

  6. La base de données est démontée du serveur actuel et le service de réplication Microsoft Exchange de chaque serveur cible copie les journaux restants.

  7. Le service de réplication Microsoft Exchange de chaque serveur cible sollicite le montage d'une base de données.

  8. Le service de banque d'informations Microsoft Exchange sur chaque serveur cible relit les fichiers journaux et monte la base de données.

  9. Tous les codes d'erreur sont renvoyés vers le service de réplication Microsoft Exchange du serveur cible.

  10. Le Gestionnaire Active Manager principal met à jour les informations sur l'état de la copie de base de données dans la base de données du cluster pour le DAG.

  11. Tous les codes d'erreur sont renvoyés par le service de réplication Microsoft Exchange du serveur cible vers le service de réplication Microsoft Exchange du Gestionnaire Active Manager principal.

  12. Le service de réplication Microsoft Exchange du Gestionnaire Active Manager principal renvoie toutes les erreurs vers l'interface d'administration où la tâche a été appelée.

  13. Remote PowerShell renvoie les résultats de l'opération vers l'interface d'administration appelante.

Pour connaître la procédure détaillée d'exécution d'une permutation de serveur, consultez la rubrique Effectuer un basculement de serveur.

Permutation de centre de données

Dans une configuration de résilience de site, la récupération automatique suite à une défaillance au niveau du site peut se produire dans un DAG, ce qui permet au système de messagerie de conserver un état fonctionnel. Cette configuration nécessite au moins trois emplacements, car elle nécessite le déploiement de membres du DAG dans deux emplacements et le déploiement du serveur témoin du DAG dans un troisième emplacement.

Si vous n’avez pas trois emplacements, ou même si vous en avez trois, mais que vous souhaitez contrôler les actions de récupération au niveau du centre de données, vous pouvez configurer un DAG pour la récupération manuelle en cas de défaillance au niveau du site. Dans ce cas, vous devez exécuter un processus appelé permutation de centre de données. Comme dans de nombreux scénarios de récupération d’urgence, la planification et la préparation préliminaires d’une permutation de centre de données permettent de simplifier le processus de récupération et de réduire la durée de la panne.

En raison des nombreuses modifications architecturales dans Exchange 2013, notamment la consolidation des rôles serveur, il est plus facile d’effectuer un basculement de centre de données dans Exchange 2013 que dans Exchange 2010. Pour obtenir des instructions détaillées sur les étapes d'exécution d'une permutation de centre de données, voir Switchovers de centre de données.

Basculements

Le basculement est un processus d’activation automatique qui peut se produire au niveau de la base de données, du serveur ou du centre de données. Les basculements ont lieu suite à la défaillance d'une base de données spécifique (perte de stockage isolé, par exemple), d'un serveur complet (défaut de la carte mère ou coupure de courant, par exemple) ou d'un site complet (perte de tous les membres du DAG d'un site, par exemple).

Les DAG et les copies de base de données de boîte aux lettres offrent une redondance complète et une récupération rapide des données et des services qui fournissent l’accès aux données. Le tableau suivant répertorie les actions de récupération attendues pour diverses défaillances. Certaines défaillances nécessitent que l’administrateur lance la récupération, et d’autres défaillances sont gérées automatiquement par le système.

Description Activation automatique Action de réparation automatique État lors de la réparation : Actif État lors de la réparation : Passif Actions de réparation Comments
Erreur logicielle de la base de données Extensible Storage Engine (ESE) : Les lecteurs de stockage de la base de données renvoient des erreurs lors de certaines opérations de lecture (par exemple, erreur -1018). Brève interruption possible.

Basculement automatique possible.		 Correction automatique d'une page incorrecte. Permutation manuelle, basculement automatique ou réparation en ligne. Échec Reconstruction RAID, réparation de la base de données et de la copie de base de données, restauration et exécution de la récupération, puis correction de la page ou correction de la page à partir de la copie. Il existe d'autres codes d'erreur logicielle de base de données.

N'inclut pas les erreurs de bloc du système de fichiers NTFS.

Si une opération de basculement ou de permutation est effectuée, le serveur hôte est mis à jour.
Erreur de base de données « semi-logicielle » ESE : Les lecteurs de stockage de la base de données renvoient des erreurs lors de certaines opérations d’écriture. Brève interruption pendant le basculement automatique. Reconstruction automatique du volume/disque après un éventuel remplacement du lecteur. Démonté s’il ne peut pas être récupéré. Échec La reconstruction RAID peut remédier au problème.

Copie et réparation, restauration et exécution de la récupération, ou reconstruction du volume/disque après un éventuel remplacement.		 Le terme « erreur d'écriture semi-logicielle ESE » signifie que certaines opérations d'écriture aboutissent.

N'inclut pas une erreur de bloc NTFS.
Erreur de journal « semi-logicielle » ESE : Les lecteurs de stockage des données du journal renvoient des erreurs non résolues lors de certaines opérations de lecture ou d'écriture. Brève interruption pendant le basculement automatique. Reconstruction automatique du volume/disque après un éventuel remplacement du lecteur. Démonté s’il ne peut pas être récupéré. Échec La reconstruction RAID peut remédier au problème.

Copie et réparation, restauration et exécution de la récupération, ou reconstruction du volume/disque après un éventuel remplacement.		 Le terme « erreur de lecture/écriture semi-logicielle ESE » signifie que certaines opérations de lecture/écriture aboutissent.

En cas d'échec de la base de données, la récupération automatique se produira avant le début du traitement de la récupération des données du journal.
Erreur logicielle ou épuisement des ressources ESE : Erreur d'interruption de l'instance par ESE (par exemple, ID d'événement 1022, profondeur excessive du point de contrôle). Brève interruption pendant le basculement automatique. Aucun. Démonté s’il ne peut pas être récupéré. Échec Remédiez au problème de ressource sous-jacent. Cette erreur peut dissimuler d'autres problèmes.
Erreurs de bloc NTFS : Les lecteurs de stockage de la base de données ou des journaux détectent une erreur de lecture ou d'écriture sur une structure de contrôle NTFS. Brève interruption pendant le basculement automatique. Volume reconstruit après remplacement possible du lecteur. Démonté s’il ne peut pas être récupéré. Échec La reconstruction RAID peut remédier au problème. Les utilitaires NTFS peuvent résoudre les problèmes NTFS. Une récupération Exchange peut s'avérer nécessaire. Cet événement est plus susceptible de se produire lorsque RAID n’est pas utilisé. Si cet événement affecte le volume de journal actif, certains fichiers journaux récents sont perdus.

N'inclut pas les erreurs automatiquement résolues par NTFS ni sa pile logicielle ou matérielle sous-jacente.
Échec de la base de données ou du lecteur de journal : un lecteur stockant la base de données ou les journaux a échoué et est inaccessible. Brève interruption pendant le basculement automatique. Reformatage ou remplacement du lecteur, suivi d'une reconstruction du volume complet. Démonté s’il ne peut pas être récupéré. Échec Remplacement du lecteur suivi d'une éventuelle reconstruction RAID.

Remplacement du lecteur suivi d'une reconstruction du volume complet.

Reconstruction du volume complet.		 Non applicable
Échec du volume de base de données ou de journal : le volume échoue en raison de problèmes de volume NTFS ou de niveau inférieur. Brève interruption pendant le basculement automatique. Reformatage ou remplacement du lecteur. Démonté s’il ne peut pas être récupéré. Échec Remplacement du lecteur suivi d'une éventuelle reconstruction RAID.

Remplacement du lecteur suivi d'une reconstruction du volume complet.

Reconstruction du volume complet.		 Non applicable.
Espace du volume de base de données ou de journal insuffisant : L'espace du système de fichiers NTFS, ainsi que des fichiers de base de données ou journaux est saturé. Basculement automatique si une autre copie ne se trouve pas dans un état similaire. Aucun. Démontée. Failed Exécution de sauvegardes complètes ou incrémentielles, suppression manuelle des journaux, attente de l'expiration du délai, reprise de la copie de la base de donnés ou réparation de la copie de base de données défaillante. Non applicable.
L'administrateur démonte la base de données incorrecte. Si le basculement automatique n'est pas bloqué par l'administrateur, une brève interruption se produira.

Si le basculement automatique est évité, une panne se produira jusqu'à ce que la base de données soit montée.		 Aucun. Démontée. Non applicable L'administrateur corrige l'erreur. Non applicable.
L'administrateur suspend la copie de base de données incorrecte. Selon la configuration et la copie affectée, la récupération automatique peut être évitée. Aucun. Non applicable. Suspendu L'administrateur corrige l'erreur. Non applicable.
L'administrateur démonte une base de données pour le stockage, NTFS ou la maintenance du volume. Si le basculement automatique n'est pas bloqué par l'administrateur, une brève interruption se produira.

Si le basculement automatique est bloqué, une panne se produira jusqu'à ce que l'administrateur termine la tâche.		 Aucun. Démontée. Non applicable L'administrateur termine la tâche. Non applicable.
L'administrateur suspend une copie de base de données pour le stockage, NTFS ou la maintenance du volume. Selon la configuration et la copie affectée, la récupération automatique peut être évitée. Aucun. Non applicable. Suspended L'administrateur termine les opérations. Non applicable.
L'administrateur démonte une base de données en vue de sa maintenance hors connexion. Panne nécessitant une réparation. Aucun. Démontée. Suspended L'administrateur termine les opérations. Les copies de base de données actives et passives sont différentes.

L'administrateur doit suspendre les copies.
Défaillance du réseau de stockage (SAN), du disque ou du contrôleur de stockage. Brève interruption pendant le basculement automatique. Aucun. Démontée. N'importe lequel Réparation du matériel. Une copie de base de données passive sera à l'état dans lequel elle se trouvait avant la panne du système.
Maintenance du matériel de serveur. Brève interruption pendant le basculement automatique (sauf en cas de blocage par un administrateur). Aucun. Démontée. N'importe lequel Achèvement des actions. Une copie de base de données passive sera à l'état dans lequel elle se trouvait avant l'arrêt du système.
Maintenance du logiciel de serveur. Brève interruption pendant le basculement automatique (sauf en cas de blocage par un administrateur). Aucun. Démontée. N'importe lequel Achèvement des actions. Une copie de base de données passive sera à l'état dans lequel elle se trouvait avant l'arrêt du système.
Le service de banque d'informations Microsoft Exchange est arrêté ou a été interrompu par un administrateur. Brève interruption pendant le basculement automatique. Aucun. Démontée. N'importe lequel Redémarrage du service de banque d'informations Microsoft Exchange. Non applicable.
Échec du service de banque d'informations Microsoft Exchange ; le système d'exploitation fonctionne toujours. Brève interruption pendant le basculement automatique. Le Gestionnaire de contrôle des services redémarre le service de banque d'informations Microsoft Exchange. Démontée. N'importe lequel Redémarrage manuel ou automatique du service de banque d'informations Microsoft Exchange. Une copie de base de données passive sera à l'état dans lequel elle se trouvait avant l'échec du service de banque d'informations Exchange.
Échec partiel du service banque d’informations Microsoft Exchange ; une partie de la banque Exchange cesse de fonctionner, mais elle n’est pas identifiée comme ayant échoué. Brève interruption possible pendant le basculement automatique. Aucun. Montée et partiellement fonctionnelle. N'importe lequel, mais peut ne fonctionner que partiellement Redémarrage du système d'exploitation ou du service de banque d'informations Microsoft Exchange. Non applicable.
Échec du serveur : Le serveur échoue pour l'une des raisons suivantes :
  • Panne de courant totale
  • Défaillance Échec non résolu du processeur, de la carte mère ou de la carte d'insertion
  • Erreur d'arrêt du système d'exploitation
  • Le système d'exploitation ne répond plus
  • Échec total de la communication
 Brève interruption pendant le basculement automatique. Redémarrage de l'ordinateur. Démontée. N'importe lequel Rétablissement de l'alimentation, modification des paramètres du système d'exploitation, modification des paramètres du matériel, remplacement du matériel, redémarrage du système d'exploitation, réparation du système d'exploitation, réparation du matériel ou résolution des problèmes de communication. Non applicable.
Le DAG détecte une défaillance du quorum. Panne nécessitant une réparation. Aucun. Démontée. N'importe lequel Réparation du quorum défaillant, affectation d'un nouveau quorum ou restauration du réseau responsable de la défaillance du quorum. Une copie de base de données passive sera à l'état dans lequel elle se trouvait avant la panne du système.
Échec de communication du réseau MAPI : Le serveur n'est plus disponible sur le réseau MAPI. Brève interruption pendant le basculement automatique ; doit être sans perte. Aucun. Tentatives de communication répétées. Démontée. N'importe lequel Résolution du problème de communication en remédiant aux problèmes matériels ou logiciels. Non applicable.
Échec de communication du réseau de réplication : Le serveur ne peut pas recevoir de pulsations, journaliser les copies ni s'amorcer sur le réseau de réplication défaillant. Brève interruption possible de la copie ou de l'amorçage lorsque la charge de travail est permutée vers un autre réseau. Aucun. Tentatives de communication répétées. Aucun. N'importe lequel Résolution du problème de communication en remédiant aux problèmes matériels ou logiciels. Résilience affectée par une défaillance.
Échecs de communication réseau multiples : le serveur ne peut pas recevoir de pulsations, de copies de journaux ou d’amorçage via plusieurs réseaux. Brève interruption pendant le basculement automatique ; doit être sans perte. Aucun. Tentatives de communication répétées. Démontée. N'importe lequel Résolution du problème de communication en remédiant aux problèmes matériels ou logiciels. Au moins un réseau fonctionne toujours.
Échec partiel d'un ou de plusieurs réseaux : Les réseaux rencontrent un nombre d'erreurs élevé. Échec non détecté ; aucune action. Aucun. Montée, mais problèmes de performances possibles. N'importe lequel Résolution du problème de communication en remédiant aux problèmes matériels ou logiciels. Le réseau rencontre un nombre d'erreurs anormalement élevé.
Blocage des systèmes d’exploitation non détectés : le système d’exploitation cesse de répondre, mais il n’est pas détecté par la surveillance ou le clustering. Aucun. Aucun. N'importe lequel. N'importe lequel Redémarrage ou arrêt des ressources qui ne répondent pas. Le blocage n'est pas détecté. Par conséquent, aucune action n'est effectuée.

Certaines fonctionnalités peuvent être opérationnelles.
Le lecteur du système d'exploitation détecte une erreur. Brève interruption pendant le basculement automatique. Aucun. Démontée. N'importe lequel Remplacement du lecteur et reconstruction du serveur ou du volume via RAID. Non applicable.
Espace du lecteur de système d'exploitation insuffisant. Brève interruption pendant le basculement automatique. Aucun. Démontée. N'importe lequel Libération manuelle d'espace sur le volume. Non applicable
Les lecteurs contenant des fichiers binaires Exchange rencontrent une défaillance de volume ou de lecteur. Brève interruption pendant le basculement automatique. Aucun. Démontée. N'importe lequel Remplacement du lecteur et réinstallation de l'application ou reconstruction du volume via RAID. Non applicable.
Espace du lecteur contenant les fichiers binaires Exchange insuffisant. Brève interruption pendant le basculement automatique. Aucun. Démontée. N'importe lequel Libération manuelle d'espace sur le volume. Non applicable.
Nouveau journal non valide détecté : La séquence du journal est entravée par un fichier existant. Brève interruption pendant le basculement automatique ; problème interprété comme un événement isolé ne concernant pas les autres copies. Aucun. Démontée. Failed Suppression des journaux gênants après détermination de la source. Les journaux gênants ne doivent pas être répliqués.
La fonctionnalité de réplication continue détecte un journal non valide : La fonctionnalité de relecture détecte un journal inapproprié pendant la copie ou la relecture. Non applicable. Suppression du journal. Non applicable. Failed Suppression du journal non valide ; déplacement du flux de journaux à l'origine du problème. Non applicable.

Basculement de base de données

Un basculement de base de données se produit lorsqu’une copie de base de données qui était active ne peut plus l’être. Les occurrences suivantes font partie d’un basculement de base de données :

  1. La défaillance de la base de données est détectée par le service de banque d'informations Microsoft Exchange.

  2. Le service de banque d'informations Microsoft Exchange écrit les événements d'erreur d'écriture dans le journal des événements du canal Crimson.

  3. Le Gestionnaire Active Manager sur le serveur qui contient la base de données défaillante détecte les événements d'échec.

  4. Le Gestionnaire Active Manager demande l'état de la copie de base de données aux autres serveurs qui contiennent une copie de la base de données.

  5. Les autres serveurs renvoient l'état de la copie de base de données au Gestionnaire Active Manager.

  6. Le Gestionnaire Active Manager principal initie un déplacement de la base de données active vers un autre serveur du groupe de disponibilité de base de données en utilisant un algorithme de sélection de la meilleure copie.

  7. Le Gestionnaire Active Manager principal met l'emplacement de montage de la base de données à jour dans la base de données du cluster pour refléter le serveur sélectionné.

  8. Le Gestionnaire Active Manager principal envoie une requête au Gestionnaire Active Manager sur le serveur sélectionné afin de devenir maître de la base de données.

  9. Le Gestionnaire Active Manager sur le serveur sélectionné demande au service de réplication Microsoft Exchange d'essayer de copier les derniers journaux du serveur précédent et de définir l'indicateur montable pour la base de données.

  10. Le service de réplication Microsoft Exchange copie les journaux du serveur qui contenait précédemment la copie active de la base de données.

  11. Le Gestionnaire Active Manager lit le nombre maximal de journaux générés dans la base de données du cluster.

  12. Le service de banque d'informations Microsoft Exchange monte la nouvelle copie de base de données active.

Basculement de serveur

Un basculement de serveur se produit lorsque le membre du DAG ne parvient plus à réparer le réseau MAPI, ou lorsque le service de cluster sur un membre du DAG ne peut plus contacter les autres membres du DAG. Les occurrences suivantes font partie d’un basculement de serveur :

  1. Le service de cluster envoie une notification au Gestionnaire Active Manager principal dans l'un des deux cas :

    1. Nœud arrêté : le serveur est accessible, mais ne peut pas participer aux opérations DAG.
    2. Réseau MAPI arrêté : le serveur ne peut pas être contacté sur le réseau MAPI et ne peut donc pas participer aux opérations DAG.

  2. Si le serveur est accessible, le Gestionnaire Active Manager principal contacte Active Manager sur le serveur affecté et demande le démontage immédiat de toutes les bases de données.

  3. Pour chacune des copies de base de données affectées :

    1. Le Gestionnaire Active Manager principal demande l'état de la copie de base de données à tous les serveurs du DAG.
    2. Le Gestionnaire Active Manager principal reçoit une réponse de tous les membres du DAG accessibles et actifs.
    3. Le Gestionnaire Active Manager principal tente de déterminer la source de journal optimale parmi tous les serveurs chargés de répondre en demandant à chacun des répondeurs le numéro de génération de journaux le plus récent.
    4. Chacun des serveurs répond par le numéro de génération de journaux.

  4. Le Gestionnaire Active Manager principal récupère l'état du catalogue d'indexation de recherche actuel dans la base de données du cluster.

  5. Selon le numéro de génération de journaux et l'intégrité du catalogue de chaque copie de base de données, le Gestionnaire Active Manager principal sélectionne les meilleures copies à activer.

  6. Le Gestionnaire Active Manager principal met l'emplacement monté de la base de données à jour dans la base de données du cluster.

  7. Le Gestionnaire Active Manager principal lance le basculement de la base de données en communiquant avec Active Manager sur un ou plusieurs serveurs.

  8. Le Gestionnaire Active Manager sur les serveurs sélectionné demande au service de réplication Microsoft Exchange d'essayer de copier les derniers journaux du serveur précédent et de définir l'indicateur montable.

  9. Lorsque la base de données peut être montée, le Gestionnaire Active Manager sur les serveurs monte les bases de données.

Pour plus d'informations sur le processus de sélection de la meilleure copie par le Gestionnaire Active Manager, consultez la rubrique Active Manager.

Basculements de centres de données

Des modifications importantes ont été apportées dans Exchange 2013 ; elles permettent de relever les défis d’une configuration de résilience de site Exchange 2010. Grâce à la simplification de l'espace de noms, la consolidation des rôles serveur, la séparation de serveur d'accès au client et de récupération de DAG (dans Exchange 2013, il n'est pas nécessaire que l'espace de noms soit déplacé avec le DAG), et les changements concernant l'équilibrage de charge, Exchange 2013 fournit de nouvelles options de résilience de site, telles que la possibilité d'utiliser un seul espace de noms global. En outre, si vous avez plus de deux emplacements dans lesquels déployer des composants de service de messagerie, Exchange 2013 active également la configuration du service de messagerie pour le basculement automatique en réponse aux défaillances nécessitant une intervention manuelle dans Exchange 2010.

La résilience de site a été simplifiée sur le plan opérationnel dans Exchange 2013. Exchange applique la tolérance de panne intégrée à l’espace de noms via plusieurs adresses IP, l’équilibrage de charge (et, le cas échéant, la possibilité de prendre des serveurs en service et hors service). L’une des modifications les plus importantes que nous avons apportées dans Exchange 2013 a été d’utiliser la capacité des clients à mettre en cache plusieurs adresses IP retournées par un serveur DNS en réponse à une demande de résolution de noms. Si l'on suppose que le client a la capacité de mettre en cache plusieurs adresses IP (ce qui est le cas pour presque tous les clients HTTP et puisque presque tous les protocoles d'accès au client dans Exchange 2013 sont basés sur HTTP (Outlook, Outlook Anywhere, EAS, EWS, OWA, EAC, RPS, etc.), tous les clients HTTP pris en charge peuvent utiliser plusieurs adresses IP), le basculement est de ce fait possible côté client. Vous pouvez configurer DNS pour remettre plusieurs adresses IP à 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. Toutefois, de nombreuses adresses IP que le client récupère seront utilisées de manière fiable par le client. Cette utilisation optimale améliore considérablement le client, car en cas d’échec de l’une des adresses IP, le client a une ou plusieurs autres adresses à laquelle se connecter. Si un client en essaie une mais qu'elle échoue, il attend environ 20 secondes puis essaie la suivante dans la liste. Ainsi, si vous perdez la connectivité à votre tableau de serveur d'accès au client (CAS) principal, et que vous disposez d'une deuxième adresse IP publiée pour un deuxième tableau CAS, la récupération pour les clients se fait automatiquement (et en 21 secondes environ).

Les clients HTTP modernes (systèmes d’exploitation et navigateurs Web qui ont dix ans ou moins) fonctionnent automatiquement avec cette redondance. La pile HTTP peut accepter plusieurs adresses IP pour un nom de domaine complet, et si la première adresse IP qu’elle tente échoue (par exemple, ne peut pas se connecter), elle essaiera l’adresse IP suivante dans la liste. En cas de défaillance logicielle (connexion perdue après l’établissement de la session, 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.

Si la configuration est correcte, le basculement peut s'effectuer au niveau du client et les clients sont automatiquement redirigés vers un second centre de données comportant des serveurs d'accès au client en fonctionnement, et ces serveurs d'accès au client en fonctionnement envoient par proxy la communication vers le serveur de boîtes aux lettres de l'utilisateur, qui n'est pas touché par la panne (car vous ne procédez à aucune permutation). Au lieu de travailler à la récupération du service, le service récupère lui-même et vous pouvez vous concentrer sur la résolution du problème principal (par exemple, le remplacement d’un équilibreur de charge défaillant).

Étant donné que vous pouvez basculer l’espace de noms entre les centres de données, tout ce qui est nécessaire pour effectuer un basculement de centre de données est un mécanisme de basculement du rôle de boîte aux lettres entre les centres de données. Pour obtenir un basculement automatique pour le DAG, vous concevez une solution où le DAG est réparti uniformément entre deux centres de données, puis placez le serveur témoin dans un troisième emplacement afin qu’il puisse être arbitré par les membres du DAG dans l’un ou l’autre centre de données, quel que soit l’état du réseau entre les centres de données qui contiennent les membres du DAG. L'essentiel est que le troisième emplacement soit isolé des défaillances réseau susceptibles de se produire dans les emplacements contenant les membres du DAG.

Si vous n'avez que deux centres de données et que vous souhaitez pouvoir configurer un basculement automatique, vous pouvez utiliser Microsoft Azure comme troisième emplacement. Vous devez créer un réseau virtuel Azure et le connecter à vos deux centres de données à l'aide d'un VPN multi-points. Vous pourrez ensuite placer votre serveur témoin sur une machine virtuelle Microsoft Azure. Pour plus d'informations, voir Utilisation d'une machine virtuelle Microsoft Azure comme serveur témoin du groupe de disponibilité de base de données (DAG).