Interruptions programmées et non programmées

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2007-10-29

Les interruptions programmées et non programmées sont les deux formes d'interruptions pouvant survenir dans un environnement de réplication continue en cluster (CCR). Les interruptions programmées sont initiées de façon explicite par un administrateur pour récupérer d'un échec ou pour effectuer une opération de maintenance. Les interruptions non programmées désignent des événements inattendus provoquant l'indisponibilité du service, des données ou les deux. La CCR est conçue pour gérer les deux types d'interruptions.

Interruptions programmées

La CCR permet de planifier une interruption de système étendue d'un noeud spécifique sans interruption étendue du serveur de boîtes aux lettres en cluster (CMS). La fonctionnalité d'interruption programmée de la CCR est conçue pour garantir que toutes les données de journal sur le noeud actif soient copiées avec succès vers le noeud passif. Par conséquent, les interruptions programmées n'entraînent jamais de perte de données, même si la réplication s'effectue de façon asynchrone. Les défaillances et le basculement qui en résulte peuvent occasionner une indisponibilité des données de journal très récentes pour le noeud passif lors de sa mise en ligne.

Dans un environnement de CCR, il n'est possible de déconnecter qu'un seul noeud à la fois. La déconnexion de plus d'un noeud provoque une interruption dans le service. À tout moment, l'ordinateur hébergeant le partage de fichiers pour le quorum jeu de noeud majoritaire (MNS) avec le témoin de partage de fichiers ou le noeud passif dans le cluster avec basculement peut être mis hors connexion pour la maintenance, les mises à jour, ainsi que les réparations matérielles et logicielles. Il est recommandé de vérifier si un noeud est actif ou s'il héberge des ressources avant de l'arrêter. Vous pouvez déterminer s'il héberge des ressources en utilisant l'Administrateur de cluster. Vous pouvez vérifier l'état d'un noeud en exécutant la cmdlet Get-ClusteredMailboxServerStatus dans l'environnement de ligne de commande Exchange Management Shell. Pour plus d'informations sur l'affichage de l'état d'un cluster de boîtes aux lettres en cluster, consultez la rubrique Procédure d'affichage de l'état d'un serveur de boîtes aux lettres en cluster.

Tâches administratives

Les interruptions programmées sont initiées de façon explicite par un administrateur pour récupérer d'un échec ou pour effectuer une opération de maintenance. Une interruption programmée permet au système de déplacer le serveur de boîtes aux lettres en cluster du noeud actif vers le noeud passif (le noeud passif devenant ainsi le nouveau noeud actif) et de monter les bases de données et les groupes de stockage répliqués. Une fois montées, les bases de données sont à l'origine de toutes les mises à jour ultérieures pour les réplications suivantes. Les deux copies échangent les rôles de réplication : une copie produit les modifications des bases de données et l'autre reçoit et applique ces modifications.

Dans la mesure où la CCR utilise la réplication asynchrone, la transition du serveur de boîtes aux lettres en cluster actif d'un noeud du cluster à un autre nécessite une coordination entre le cluster et le support de réplication. Cette coordination est assurée par la CCR. L'administrateur lance une interruption programmée à l'aide de la cmdlet Move-ClusteredMailboxServer dans l'environnement de ligne de commande Exchange Management Shell.

La cmdlet Move-ClusteredMailboxServer vérifie que le noeud passif dispose d'une copie saine et valide. En outre, elle s'assure que la copie est relativement récente. Si tel n'est pas le cas, l'interruption peut être prolongée pendant que la réplication s'exécute. Si ces vérifications s'avèrent positives, la transition est lancée. Si aucune défaillance ne survient pendant le déplacement, la tâche se termine lorsque le serveur de boîtes aux lettres en cluster est exécuté sur le noeud sélectionné et que toutes les bases de données sont montées. Des défaillances peuvent se produire au cours de ce processus et empêcher la transition ou affecter le montage automatique de toutes les bases de données. Dans ce cas, il y a basculement vers le comportement d'interruption non programmée.

Dans certaines circonstances, les interruptions programmées sont utilisées pour récupérer les serveurs partiellement défaillants. Un serveur comportant des fichiers de base de données et des fichiers journaux endommagés est un exemple. Dans ce cas, la logique d'envoi des journaux via le système de réplication bloque la cmdlet Move-ClusteredMailboxServer. L'administrateur dispose d'une option simple pour gérer ce scénario. Il démonte les bases de données posant problème et génère la commande Move-ClusteredMailboxServer avec une option qui tente de copier les journaux associés aux bases de données démontées mais n'arrête pas le déplacement si tous les journaux ne peuvent pas être copiés. Ainsi, la récupération, même d'un groupe de stockage endommagé, est effectuée de façon aisée grâce à la cmdlet Move-ClusteredMailboxServer.

La cmdlet Move-ClusteredMailboxServer permet à l'administrateur d'enregistrer le motif pour lequel le déplacement a été effectué. Cette raison est enregistrée dans le journal des événements. La commande oblige également l'administrateur à spécifier le noeud qui hébergera le serveur de boîtes aux lettres en cluster. Cela empêche les administrateurs de déplacer le serveur de boîtes aux lettres en cluster de façon erronée quand celui-ci est déjà correctement hébergé.

L'interface de gestion de ligne de commande Cluster.exe et l'interface utilisateur graphique (GUI) Administrateur de cluster permettent toutes deux de déplacer un serveur de boîtes aux lettres en cluster. L'utilisation de ces méthodes déclenche la logique de purge de la réplication. Toutefois, il n'est pas recommandé d'utiliser ces méthodes pour les raisons suivantes :

• Ces méthodes ne valident pas l'intégrité ou l'état de la copie passive. Aussi leur utilisation peut-elle entraîner une interruption prolongée pendant que le noeud exécute les opérations nécessaires pour rendre la base de données montable.

• Ces méthodes permettent à une base de données de rester hors connexion indéfiniment, la réplication se trouvant dans une condition interrompue.

Restauration d'une activité de réplication après une interruption programmée

Le processus de restauration d'un environnement de CCR après l'interruption programmée d'un noeud actif est le redémarrage du noeud. La réplication est automatiquement reprise au redémarrage du système. Deux cas doivent être pris en compte :

• L'interruption programmée a été réalisée avec succès, aucune défaillance n'ayant été détectée au cours de la transition associée avec l'interruption programmée, et toutes les bases de données ont été mises en ligne automatiquement. Dans ce cas, l'administrateur a exécuté l'interruption programmée de manière à ce que les deux noeuds aient des groupes de stockage et des bases de données cohérents. Le noeud peut alors se connecter et poursuivre immédiatement la réplication. La copie peut être actualisée en relisant les journaux. Aucune action spéciale n'est requise.

• L'interruption programmée a été partiellement réalisée avec succès ou certaines bases de données ont été endommagées avant l'interruption programmée. Dans ce cas, l'interruption programmée était incapable de s'assurer que tous les journaux à la source ont été mis à la disposition de la cible avant le montage de ses bases de données. En général, cette situation se produit suite à un échec antérieur à l'interruption programmée ou plus tard lors de l'exécution de l'interruption programmée. Par conséquent, les bases de données cible et source diffèrent. Dans certains cas, la CCR peut récupérer certaines incohérences de façon automatique. Si tel est le cas, la réplication démarre et traite tous les journaux disponibles. Si la réplication n'est pas en mesure d'effectuer une récupération automatique, elle marque la copie comme interrompue et génère un événement signalant le problème. En supposant que le stockage soit viable, l'action de récupération principale consiste à réamorcer la copie. Pour plus d'informations sur la procédure de résolution de ces problèmes, consultez la rubrique Procédure d'amorçage de la copie de réplication continue en cluster.

Interruptions non programmées

Les interruptions non programmées surviennent comme réponse automatique du système à divers types de défaillances. La récupération automatique de la CCR concerne les défaillances pour lesquelles il y a une probabilité élevée que la disponibilité soit améliorée et que la plupart des environnements bénéficieraient d'une telle opération.

Une interruption non programmée permet au système d'activer le serveur de boîtes aux lettres sur le noeud passif, le rendant ainsi actif, et de monter les bases de données et les groupes de stockage répliqués. Une fois montées, les bases de données sont à l'origine de toutes les mises à jour ultérieures pour les réplications suivantes. Les deux copies échangent les rôles de réplication : une copie produit les modifications des bases de données et l'autre reçoit et applique ces modifications.

Dans la mesure où la CCR utilise la réplication asynchrone, une interruption non programmée implique quelques pertes de données. Au minimum, les journaux en cours d'écriture par le serveur actif ne sont pas disponibles pour les activités de récupération. La CCR résout ce problème en incluant un contrôle administratif du comportement de basculement et une fonction permettant de récupérer les données qui seront probablement affectées.

Lorsqu'un basculement survient, la CCR active toujours le serveur de boîtes aux lettres sur le noeud passif restant. Les contrôles système dépendent du montage des bases de données sur ce noeud désormais actif. La CCR offre des contrôles administratifs permettant d'indiquer si les bases de données sont montées. La position par défaut est Best availability. Dans cette position, le système monte automatiquement toutes les bases de données synchronisées avec la base de données de production précédemment active. La valeur Best availability autorise davantage d'incohérences entre les deux copies. La valeur Good availability met une base de données en ligne si, pendant le délai nécessaire à la génération du nouveau journal, le dernier journal généré a été répliqué. La valeur Lossless garantit que la copie n'est pas mise en ligne à moins d'être en mesure de confirmer qu'aucune perte de données ne surviendra. Si la valeur Lossless est utilisée, la récupération automatique survient uniquement lorsque le serveur original est de nouveau opérationnel et que toutes les données des journaux sont disponibles et non endommagées.

Si une ou plusieurs bases de données sont dans une condition dans laquelle le paramètre ne les monte pas automatiquement, l'administrateur peut toujours décider de façon explicite de monter la copie avec son contenu disponible. L'administrateur doit vérifier l'état de la copie, puis exécuter deux commandes. La première commande informe le moteur de réplication que cette copie doit devenir une source de réplication (source de modifications) ; autrement dit, la copie doit être montable. La deuxième commande monte la base de données.

Pour plus d'informations sur la récupération suite à un endommagement ou des défaillances lorsque la CCR est activée, consultez la rubrique Gestion de la réplication continue en cluster.

Contrôles administratifs

Des contrôles administratifs assurent la surveillance du fonctionnement dans le cas d’une interruption non planifiée. La CCR fournit un attribut pour les serveurs de boîtes aux lettres que vous pouvez utiliser pour surveiller le comportement de récupération d'interruption non programmée. L'attribut AutoDatabaseMountDial peut prendre trois valeurs : Lossless, Good Availability et Best Availability.

• Lossless   Lossless indique qu'aucun journal n'a été perdu. Lorsque l'attribut est défini sur Lossless, le système attend généralement la remise en ligne du noeud défaillant avant de monter les bases de données. Le système défaillant doit être rétabli avec tous les journaux accessibles et non endommagés. Après la défaillance, le noeud passif est activé et le service de banque d'informations Microsoft Exchange est mis en ligne. Elle vérifie que les bases de données peuvent être montées sans entraîner de perte de données. Si tel est le cas, les bases de données sont montées. Sinon, le système tente régulièrement de copier les journaux. Si le serveur est rétabli avec ses journaux intacts, cette tentative sera finalement fructueuse et les bases de données seront montées. Si le serveur est rétabli avec ses journaux endommagés, les journaux restants ne seront pas disponibles et les bases de données affectées ne seront pas montées.

  Notes

  À tout moment après la fin du basculement, un administrateur peut intervenir et décider d'effectuer l'opération de montage à l'aide des bases de données et journaux disponibles sur le noeud auparavant passif. Cette tâche est effectuée via un processus simple en deux étapes. Il est probable que la décision de l'administrateur d'intervenir soit basée sur l'analyse du délai nécessaire pour rendre opérationnel le serveur d'origine. La cohérence de la réplication entre les deux noeuds au moment de la défaillance et le besoin urgent d'accéder à leur serveur pour les clients sont quelques-uns des facteurs intervenant dans cette analyse.

• Good availability   Good availability indique la perte de trois journaux. La valeur Good availability permet une récupération totalement automatique lorsque la réplication fonctionne normalement et que les journaux sont répliqués à mesure qu'ils sont générés.

• Best availability   Best availability indique la perte de six journaux. Il s'agit du paramètre par défaut. La valeur Best availability fonctionne de façon similaire à la valeur Good availability, mais elle permet une récupération automatique lorsque la réplication rencontre une latence légèrement plus élevée. Aussi, le nouveau noeud actif peut être légèrement décalé par rapport à l'état de l'ancien noeud actif après le basculement, ce qui augmente la probabilité que des divergences se produisent. Pour y remédier, un réamorçage complet est nécessaire.

Pour plus d'informations sur le comportement de gestion des interruptions, consultez la rubrique Procédure de réglage des paramètres de basculement et de montage pour la réplication continue en cluster.