Présentation du gestionnaire Active Manager

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2015-03-09

Microsoft Exchange Server 2010 inclut un nouveau composant appelé Gestionnaire Active Manager comportant des fonctionnalités qui remplacent les fonctionnalités de gestion des basculements et de modèle de ressources assurées par l'intégration avec le service de cluster dans les versions précédentes d'Exchange. Exchange n'utilise plus le modèle de ressources de cluster pour la haute disponibilité. Toutes les ressources de cluster Exchange fournies par le fichier exres.dll ont été supprimées, y compris la construction appelée « serveur de boîtes aux lettres en cluster ». Un cluster de basculement Windows est utilisé par Exchange, mais il n'existe aucun groupe de clusters pour Exchange, et le cluster ne comprend aucune ressource de stockage. Par conséquent, si vous examinez le cluster à l'aide des outils de gestion du cluster, vous ne pouvez voir que les ressources de cluster essentielles (l'adresse IP et le nom de réseau et, si nécessaire, la ressource quorum). Les réseaux et les nœuds de cluster sont également présents. Ils sont cependant gérés par Exchange, et non par le cluster ou les outils de cluster.

Le gestionnaire Active Manager s’exécute en tant que rôle sur tous les serveurs de boîtes aux lettres. Un rôle Active Manager est disponible sur les serveurs de boîtes aux lettres dont la haute disponibilité n’est pas configurée, à savoir : gestionnaire Active Manager autonome. Deux rôles Active Manager sont disponibles sur les serveurs membres d’un groupe de disponibilité de base de données, à savoir : gestionnaire Active Manager principal (PAM) et gestionnaire Active Manager de secours (SAM). Le gestionnaire Active Manager principal est le gestionnaire dans un groupe de disponibilité de base de données qui détermine les copies qui seront actives et passives. Il est chargé d'obtenir les notifications de modification de topologie et de réagir aux défaillances de serveur. Le membre du groupe de disponibilité de base de données détenant le rôle PAM est toujours le membre qui est actuellement propriétaire de la ressource quorum de cluster (groupe de clusters par défaut). En cas de défaillance du serveur propriétaire de la ressource quorum de cluster, le rôle PAM est automatiquement déplacé vers un serveur opérationnel qui s'approprie la ressource quorum de cluster. De plus, si vous devez procéder à une mise hors connexion du serveur qui héberge la ressource quorum de cluster à des fins de maintenance ou de mise à niveau, vous devez au préalable déplacer le gestionnaire Active Manager principal vers un autre serveur du groupe de disponibilité de base de données. Le gestionnaire Active Manager principal gère tous les déplacements des désignations actives entre les copies d'une base de données (une seule copie peut être active à la fois, et cette copie peut être montée ou démontée). Il prend également en charge les fonctions assurées par le rôle gestionnaire Active Manager de secours (SAM) sur le système local (détection des défaillances des bases de données locales et de la banque d'informations locales).

Le rôle gestionnaire Active Manager de secours fournit des informations sur le serveur qui héberge la copie active d'une base de données de boîtes aux lettres aux autres composants d'Exchange qui exécutent un composant client Active Manager (par exemple, le service d'accès au client RPC ou le serveur de transport Hub). Le gestionnaire Active Manager de secours détecte les défaillances des bases de données locales et de la banque d'informations locales. Il réagit aux défaillances en demandant au gestionnaire Active Manager principal d'opérer un basculement (si la base de données est répliquée). Un gestionnaire Active Manager de secours ne détermine pas la cible d'un basculement. Il ne met pas non plus à jour l'état de l'emplacement d'une base de données dans le gestionnaire Active Manager principal. Il accèdera à l'état de l'emplacement de la copie de base de données active pour répondre aux requêtes pour la copie active de la base de données qu'il reçoit.

Remarque :

Exchange 2010 n'est pas une application en cluster. Exchange 2010 utilise les fonctions de la bibliothèque d'API de cluster implémentées dans le fichier clusapi.dll pour les fonctions de cluster, groupe, réseau de cluster (pulsations), gestion des nœuds, Registre de cluster, et quelques fonctions de code de contrôle. Qui plus est, le gestionnaire Active Manager stocke les informations de la base de données de boîtes aux lettres actuelle (par exemple, les données actives et passives, et les données montées) dans la base de données de clusters. Bien que les informations soient stockées directement dans la base de données de clusters, aucun autre composant n'y accède directement.

Dans Exchange 2010, le service de réplication Microsoft Exchange contrôle régulièrement l'intégrité de toutes les bases de données montées. En outre, il analyse le moteur ESE (Extensible Storage Engine) afin de détecter d'éventuelles défaillances ou erreurs d'E/S. Lorsque le service détecte une défaillance, il informe le gestionnaire Active Manager. Ce dernier détermine alors la copie de base de données devant être montée, ainsi que les exigences pour le montage de cette base de données. Qui plus est, le gestionnaire Active Manager suit la copie active d'une base de données de boîtes aux lettres (en fonction de la dernière copie montée de la base de données) et fournit les résultats du suivi au composant d'accès au client RPC sur le serveur d'accès au client auquel le client est connecté.

Sélection de la meilleure copie par le gestionnaire Active Manager

Lorsqu’une panne, qui a une incidence sur une base de données de boîtes aux lettres, se produit, le gestionnaire Active Manager suit une procédure précise pour remédier à la panne, et sélectionne la meilleure copie possible de la base de données en panne qu’il active. Cette procédure est la suivante :

1. Le gestionnaire Active Manager détecte la panne.

2. Le gestionnaire Active Manager principal (PAM) exécute un algorithme interne appelé sélection de la meilleure copie.

3. Un processus appelé tentative de copie des derniers journaux tente de copier les fichiers journaux manquants depuis le serveur qui a hébergé la copie de la base de données active avant que le basculement n’ait lieu.

4. Une fois que le processus de tentative de copie des derniers journaux est arrivé à son terme, le gestionnaire Active Manager principal émet une demande de montage destiné au service de banque d’informations de Microsoft Exchange via un appel de procédure distante. À ce stade, deux cas de figure sont possibles :

   1. la base de donnée est montée et les clients peuvent y accéder ou

   2. la base de données n’est pas montée et le gestionnaire Active Manager principal effectue les étapes 3 et 4 sur la deuxième meilleure copie (si disponible).

Pour rechercher la meilleure copie possible à activer, le gestionnaire Active Manager principal utilise jusqu’à dix ensembles de critères distincts. Une fois la meilleure copie possible localisée, la tentative de copie des derniers journaux s’exécute. Une fois ce processus terminé, si tous les fichiers journaux manquants ont été copiés à partir de la copie active précédente, la base de données est montée sans aucune perte de données. C’est ce que l’on appelle un basculement sans perte. Si le processus de tentative de copie des derniers journaux n'aboutit pas, la valeur configurée pour AutoDatabaseMountDial est consultée. Pour plus d'informations sur AutoDatabaseMountDial, voir Set-MailboxServer. Si le nombre de journaux perdus est inférieur à la valeur configurée pour AutoDatabaseMountDial, la base de données est montée. Si le nombre de journaux perdus est supérieur à la valeur configurée pour AutoDatabaseMountDial, la base de données n'est pas montée tant que les fichiers journaux perdus n'ont pas été récupérés, ou tant qu'un administrateur n'a pas explicitement monté la base de données et accepté la perte de données plus conséquente. Si la base de données n’est pas montée automatiquement, le gestionnaire Active Manager principal sélectionne la deuxième meilleure copie (si disponible). Au moins trois raisons expliquent pourquoi la copie de la base de données initialement sélectionnée n’est pas montée automatiquement :

1. Le nombre de fichiers journaux perdus est supérieur à la valeur configurée pour AutoDatabaseMountDial.

2. Le serveur sur lequel la tentative de montage a eu lieu est configuré avec un nombre maximal de bases de données actives et le nombre maximal de copies de base de données actives a été atteint sur le serveur.

3. La copie de la base de données est suspendue pour activation.

Processus de sélection de la meilleure copie

Le gestionnaire Active Manager commence le processus de sélection de la meilleure copie en créant une liste des copies de base de données pouvant être activées. Les copies de base de données inaccessibles ou dont l’activation est empêchée par l’administrateur (à l’aide de la propriété DatabaseCopyAutoActivationPolicy de la cmdlet Set-MailboxServer) sont ignorées et ne sont pas utilisées au cours du processus de sélection. L’ordre de la liste dépend de la version d’Exchange 2010 :

• Dans la version RTM d’Exchange 2010, le gestionnaire Active Manager trie la liste créée en utilisant la longueur de la file d’attente de copie comme clé primaire. Le calcul est basé sur LastLogInspected (du point de vue de la copie), par conséquent la liste des copies potentielles est triée selon la valeur la plus élevée de LastLogInspected (qui correspond à la copie avec la longueur de file d’attente de copie la plus basse). Puis, le gestionnaire Active Manager trie la liste une seconde fois à partir de la valeur de la préférence d’activation comme clé secondaire. La copie avec la valeur de préférence d’activation la plus basse est prioritaire dans la liste.

• Ce comportement est le même dans Exchange 2010 Service Pack 1 (SP1) que dans la version RTM, sauf pour les serveurs configurés avec la valeur de numérotation de montage automatique de base de données Sans perte. Lorsque la numérotation de montage automatique de base de données est définie sur la valeur Sans perte, le gestionnaire Active Manager trie la liste produite dans l’ordre croissant en utilisant la valeur de la préférence d’activation comme clé primaire. Il s’agit du comportement par défaut. Le déséquilibre au niveau des bases de données sera minimisé par des opérations de mouvement (tels que des basculements ou en exécutant StartDagServerMaintenance.ps1).

Ensuite, le gestionnaire Active Manager tente de trouver dans la liste une copie de base de données de boîtes aux lettres présentant un état Sain, Déconnecté et sain, Déconnecté et resynchronisation ou Source d’amorçage, puis il évalue le potentiel d’activation de chacune des copies dans la liste en utilisant dix ensembles de critères dans un ordre défini. Le gestionnaire Active Manager détermine si l’une des copies pouvant être activées correspond au premier ensemble de critères :

• L'index de contenu présente un état Sain.

• La longueur de la file d'attente de copie est inférieure à 10 fichiers journaux.

• La longueur de la file d'attente de relecture est inférieure à 50 fichiers journaux.

Si aucune des copies de base de données ne correspond au premier ensemble de critères, le gestionnaire Active Manager tente de trouver une copie de base de données correspondant au deuxième ensemble de critères :

• L'index de contenu présente un état Analyse.

• La longueur de la file d'attente de copie est inférieure à 10 fichiers journaux.

• La longueur de la file d'attente de relecture est inférieure à 50 fichiers journaux.

Si aucune des copies de base de données ne correspond au deuxième ensemble de critères, le gestionnaire Active Manager tente de trouver une copie de base de données correspondant au troisième ensemble de critères :

• L'index de contenu présente un état Sain.

• La longueur de la file d'attente de relecture est inférieure à 50 fichiers journaux.

Si aucune des copies de base de données ne correspond au troisième ensemble de critères, le gestionnaire Active Manager tente de trouver une copie de base de données correspondant au quatrième ensemble de critères :

• L'index de contenu présente un état Analyse.

• La longueur de la file d'attente de relecture est inférieure à 50 fichiers journaux.

Si aucune des copies de base de données ne correspond au quatrième ensemble de critères, le gestionnaire Active Manager tente de trouver une copie de base de données correspondant au cinquième ensemble de critères :

• La longueur de la file d'attente de relecture est inférieure à 50 fichiers journaux.

Si aucune des copies de base de données ne correspond au cinquième ensemble de critères, le gestionnaire Active Manager tente de trouver une copie de base de données correspondant au sixième ensemble de critères :

• L'index de contenu présente un état Sain.

• La longueur de la file d'attente de copie est inférieure à 10 fichiers journaux.

Si aucune des copies de base de données ne correspond au sixième ensemble de critères, le gestionnaire Active Manager tente de trouver une copie de base de données correspondant au septième ensemble de critères :

• L’index de contenu présente un état Analyse.

• Sa longueur de file d’attente de copie comporte moins de 10 fichiers journaux.

Si aucune des copies de base de données ne correspond au septième ensemble de critères, le gestionnaire Active Manager tente de trouver une copie de base de données correspondant au huitième ensemble de critères :

• L'index de contenu présente un état Sain.

Si aucune des copies de base de données ne correspond au huitième ensemble de critères, le gestionnaire Active Manager tente de trouver une copie de base de données correspondant au neuvième ensemble de critères :

• L'index de contenu présente un état Analyse.

Si aucune des copies de base de données ne correspond au neuvième ensemble de critères, le gestionnaire Active Manager tente d’activer une copie de base de données qui présente un état Sain, Déconnecté et sain, Déconnecté et resynchronisation ou Source d’amorçage (le dixième ensemble de critères). S’il ne parvient pas à trouver une copie de base de données correspondant au dixième ensemble de critères, il ne peut pas activer automatiquement une copie de base de données.

Une fois que des copies correspondant à un ou à plusieurs ensembles de critères sont trouvées, le processus de tentative de copie des derniers journaux s’exécute pour copier des fichiers journaux de la source d’origine à la nouvelle copie active potentielle. Une fois que ce processus est arrivé à son terme, le gestionnaire Active Manager principal émet une demande de montage. La base de données est alors montée et les clients peuvent y accéder ou bien elle n’est pas montée et le gestionnaire Active Manager principal recherche la deuxième meilleure copie (si disponible).

Exemples de sélection de meilleure copie

La section suivante présente plusieurs exemples du processus de sélection et d’activation d’une meilleure copie par le gestionnaire Active Manager.

Exemple 1 : scénario de base

Dans cet exemple, il existe quatre copies de la base de données de boîtes aux lettres DB1. DB1 est actuellement active sur le serveur 1 qui est en panne. Le tableau suivant montre l’état actuel des copies de la base de données DB1 sur le serveur 2, le serveur 3 et le serveur 4.

Le tri des copies disponibles à partir de leur longueur de file d’attente de copie (en utilisant la préférence d’activation si nécessaire) produit la liste suivante dans l’ordre indiqué :

• Serveur3\DB1

• Serveur2\DB1

• Serveur4\DB1

Dans cette liste, seules deux copies de la base de données correspondent au premier ensemble de critères d’activation :

• La copie sur le serveur 3, dont l’état de base de données est Déconnecté et sain, la longueur de la file d’attente de copie est inférieure à 10 fichiers journaux, la longueur de la file d’attente de relecture est inférieure à 50 fichiers journaux et l’index de contenu est sain.

• La copie sur le serveur 2, dont l’état de base de données est Sain, la longueur de la file d’attente de copie est inférieure à 10 fichiers journaux, la longueur de la file d’attente de relecture est inférieure à 50 fichiers journaux et l’index de contenu est sain.

De ces deux copies, la copie sur le serveur 3 a l’indice de longueur de file d’attente de copie le plus bas ; par conséquent, cette copie est sélectionnée comme la copie à activer, car elle présente une perte de données moindre.

Une fois que la copie sur le serveur 3 est activée, le service de réplication Microsoft Exchange sur le serveur 3 effectue le processus de tentative de copie des derniers journaux et tente de copier les fichiers journaux manquants à partir du serveur actif précédent (dans ce cas, le serveur 1). Une fois que ce processus est arrivé à son terme, ses résultats sont transmis au gestionnaire Active Manager principal. Si tous les journaux sont copiés, la base de données est signalée comme étant la copie active et elle est montée sans perte de données. Si des journaux manquent, la valeur du paramètre AutoDatabaseMountDial est examinée. Si la quantité de données perdues correspond à la valeur définie pour ce paramètre, la base de données est signalée comme étant la copie active et elle est montée avec une perte de données. Les données perdues seront pour la plupart récupérées à partir du conteneur de dépôt de transport.

Si le gestionnaire Active Manager envoie une demande de montage au service de banque d’informations et si l’opération de montage échoue, le gestionnaire Active Manager examine de nouveau la liste triée ci-dessus et tente d’activer la deuxième meilleure copie (dans ce cas, la copie sur le serveur 2).

Exemple 2 : deux copies avec la même longueur de file d’attente de copie

Dans cet exemple, il existe quatre copies de la base de données de boîtes aux lettres DB2. DB2 est actuellement active sur le serveur 1 qui est en panne. Le tableau suivant montre l’état actuel des copies de la base de données DB2 sur le serveur 2, le serveur 3 et le serveur 4.

Le tri des copies disponibles à partir de leur longueur de file d’attente de copie (en utilisant la préférence d’activation si nécessaire) produit la liste suivante dans l’ordre indiqué :

• Serveur2\DB2

• Serveur3\DB2

• Serveur4\DB2

Dans cette liste, seules deux copies de la base de données correspondent au premier ensemble de critères d’activation :

• La copie sur le serveur 2, dont l’état de base de données est Sain, la longueur de la file d’attente de copie est inférieure à 10 fichiers journaux, la longueur de la file d’attente de relecture est inférieure à 50 fichiers journaux et l’index de contenu est sain.

• La copie sur le serveur 3, dont l’état de base de données est Déconnecté et sain, la longueur de la file d’attente de copie est inférieure à 10 fichiers journaux, la longueur de la file d’attente de relecture est inférieure à 50 fichiers journaux et l’index de contenu est sain.

De ces deux copies, la copie sur le serveur 2 a un indice de longueur de file d’attente de copie égal à celui de la copie sur le serveur 3, mais elle a également une valeur de préférence d’activation inférieure ; par conséquent, la copie sur le serveur 2 est en tête de la liste et est sélectionnée comme étant la copie à activer, car elle présente une perte de données moindre et sa valeur de préférence d’activation est la plus basse.

Exemple 3 : copies avec un état de base de données identique et un état d’index de contenu différent

Dans cet exemple, il existe quatre copies de la base de données de boîtes aux lettres DB3. DB3 est actuellement active sur le serveur 1 qui est en panne. Le tableau suivant montre l’état actuel des copies de la base de données DB3 sur le serveur 2, le serveur 3 et le serveur 4.

Le tri des copies disponibles à partir de leur longueur de file d’attente de copie (en utilisant la préférence d’activation si nécessaire) produit la liste suivante dans l’ordre indiqué :

• Serveur2\DB3

• Serveur3\DB3

• Serveur4\DB3

Les trois copies de la base de données hébergées sur les serveurs ci-dessus correspondent aux critères d’activation. Bien que la copie sur le serveur 2 ait une valeur de préférence d’activation plus basse, son état d’index de contenu est Analyse ; par conséquent, lorsque le gestionnaire Active Manager compare la liste au premier ensemble de critères d’activation (qui comprend un index de contenu présentant l’état Sain), la copie de la base de données sur le serveur 3 sera sélectionnée, car son index de contenu présente l’état Sain.

Exemple 4 : effet du paramètre AutoDatabaseMountDial sur la sélection de la meilleure copie

Dans cet exemple, il existe quatre copies de la base de données de boîtes aux lettres DB4. DB4 est active sur le serveur 1, qui tombe en panne et redémarre. Le tableau suivant montre l’état actuel des copies de la base de données DB4 sur le serveur 2, le serveur 3 et le serveur 4. Le paramètre AutoDatabaseMountDial pour tous les serveurs de boîtes aux lettres dans le DAG est défini sur Sans perte (la longueur de la file d’attente de copie est 0).

Étant donné que la numérotation de montage automatique de base de données est définie sur la valeur Sans perte, le gestionnaire Active Manager utilise la préférence d’activation au lieu de la longueur de la file d’attente de copie comme clé de tri primaire. Le tri des copies disponibles à partir de leur préférence d’activation produit la liste suivante dans l’ordre indiqué :

• Serveur2\DB4

• Serveur3\DB4

• Serveur4\DB4

Aucune des bases de données ne correspond au premier, ni au deuxième, ni au troisième ensemble de critères d’activation mais la copie de la base de données sur le serveur 3 correspond en revanche au quatrième (son état d’index de contenu indique Analyse et sa longueur de file d’attente de relecture est inférieure à 50). La longueur de la file d’attente de copie de la copie de la base de données sur le serveur 3 est 100 mais étant donné que le serveur 1 n’a pas fini de redémarrer, le processus de tentative de copie des derniers journaux ne peut pas copier les fichiers journaux manquants sur le serveur 3. Le processus de tentative de copie des derniers journaux indique au gestionnaire Active Manager principal que la quantité de données manquantes ne correspond pas à la valeur du paramètre AutoDatabaseMountDial. Le gestionnaire Active Manager principal doit alors sélectionner la deuxième meilleure copie disponible.

Dans le scénario ci-dessus, les copies de la base de données sur le serveur 2 et le serveur 4 correspondent au sixième ensemble de critères d’activation (elles présentent l’état Sain pour leur état de base de données et leur index de contenu et une longueur de file d’attente de copie inférieure à 10 fichiers journaux). Étant donné qu’elle se trouve plus haut dans la liste des copies disponibles, la copie de la base de données sur le serveur 2 est ensuite essayée. Le processus de tentative de copie des derniers journaux s’exécute sur le serveur 2 mais comme le serveur 1 ne communique toujours pas sur le réseau, le processus de tentative de copie des derniers journaux ne peut pas copier les journaux. Enfin, puisque la longueur de la file d’attente de copie correspond à la valeur définie pour le paramètre AutoDatabaseMountDial, le processus de tentative de copie des derniers journaux envoie un message de réussite au gestionnaire Active Manager principale et celui-ci émet une demande de montage de base de données via un appel de procédure distante.

 © 2010 Microsoft Corporation. Tous droits réservés.