Procédure de dépannage des problèmes de réplication continue en cluster

  • Article

 

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

Dernière rubrique modifiée : 2008-01-14

Cette rubrique décrit le dépannage des problèmes relatifs à la réplication continue en cluster (CCR). Pour plus d'informations sur les outils de résolution des problèmes de CCR, consultez la rubrique Outils de dépannage des problèmes avec les déploiements à disponibilité élevée.

Les procédures de cette rubrique ont trait aux problèmes suivants dans un environnement de CCR :

  • Get-StorageGroupCopyStatus signale que l'état de la base de données est « Échec » et qu'elle n'est pas amorcée.

  • Get-StorageGroupCopyStatus signale que l'état de la base de données est « Échec ». La valeur de FailedMessage indique que la copie du groupe de stockage est différente.

  • Get-StorageGroupCopyStatus signale que l'état de la base de données est « Échec ». La valeur de FailedMessage fournit des informations spécifiques sur la source de l'échec.

  • Des alertes, des compteurs de performance ou Get-StorageGroupCopyStatus indiquent que les files d'attente de copie ou de relecture sont sauvegardées pour une copie de groupe de stockage.

  • Get-StorageGroupCopyStatus signale une heure de péremption pour LastInspectedLogTime.

  • Le basculement ou Move-ClusteredMailboxServer réussit mais les bases de données ne sont pas montées.

  • Le basculement réussit mais certaines bases de données ne sont pas montées automatiquement ou manuellement. De la même façon, Get-ClusteredMailboxServerStatus signale une ou plusieurs bases de données en état d'échec.

  • Le montage d'une base de données au démarrage échoue dans un environnement de CCR.

  • L'événement MSExchangeRepl 2073 est journalisé, avertissant que le service de réplication de Microsoft Exchange ne trouve pas de répertoire.

  • Move-ClusteredMailboxServer ne déclenche pas d'interruption programmée à cause d'un problème de réplication.

  • La réplication n'effectue pas de re-synchronisation après un basculement sur un ou plusieurs groupes de stockage.

  • L'amorçage échoue.

En cas de défaillance autre que celles répertoriées ici, consultez le journal des événements sur les deux noeuds pour déterminer la cause et utilisez les informations des journaux pour déterminer les actions de récupération à exécuter. Après avoir identifié l'heure à laquelle l'échec s'est produit, d'autres journaux des événements peuvent vous aider à mieux comprendre le problème. Si ces informations sont insuffisantes, le fait de connaître l'heure à laquelle le problème s'est produit peut vous aider à affiner l'analyse et la taille de la fenêtre de consultation dans le journal du cluster. Celui-ci fournit des informations de niveau de suivi pour les actions exécutées par le système de gestion du cluster.

Avant de commencer

Pour exécuter cette procédure, vous devez utiliser un compte auquel ont été délégués le rôle Administrateur Exchange Server et le groupe Administrateurs local pour le serveur cible. Pour plus d'informations sur les autorisations, la délégation de rôles et les droits requis pour administrer Microsoft Exchange Server 2007, consultez la rubrique Considérations relatives aux autorisations.

Procédure

Get-StorageGroupCopyStatus signale que l'état de la base de données est « Échec » et qu'elle n'est pas amorcée.

  • Causes possibles   Il y a un problème de configuration ou la copie de réplication n'a pas de base de données de base valide. Ce problème peut être dû au non-amorçage de la copie du groupe de stockage lors de l'ajout du noeud passif.

  • Solution

    • Vérifiez que le stockage pour la copie est correctement configuré et opérationnel. Si vous trouvez une erreur, vous pouvez déclencher un nouveau contrôle de la copie en suspendant, puis en reprenant le groupe de stockage.

    • Vérifiez que les chemins du groupe de stockage et de la base de données sont correctement configurés pour le stockage sur le serveur passif. Vous pouvez le faire en utilisant la cmdlet Get-StorageGroup dans la console de gestion Exchange.

    • La cmdlet Update-StorageGroupCopy permet d'amorcer la copie du groupe de stockage.

Get-StorageGroupCopyStatus signale que l'état de la base de données est « Échec » et que la valeur FailedMessage indique que la copie du groupe de stockage est différente.

  • Causes possibles   Se produit en cas de basculement et lorsque des journaux ont été perdus en nombre suffisant pour que la base de données sur le serveur actif précédent ne puisse pas être re-synchronisée avec la base de données active actuelle sans un réamorçage complet. Cette situation ne peut pas se produire dans une configuration de LCR.

  • Résolution   Utilisez la cmdlet Update-StorageGroupCopy pour amorcer la copie du groupe de stockage.

Get-StorageGroupCopyStatus signale que l'état de la base de données est « Échec » et que la valeur FailedMessage fournit des informations spécifiques sur la source de l'échec.

  • Causes possibles   Un grand nombre de causes peuvent avoir pour effet qu'une copie de groupe de stockage soit identifiée comme étant dans l'état « Échec ». Les cas précédents, de non-amorçage et de divergence, sont deux exemples. La valeur FailedMessage identifie spécifiquement le problème détecté.

  • Résolution   Exécutez la cmdlet Get-StorageGroupCopyStatus pour obtenir la valeur de FailedMessage complète, qui identifie le problème spécifique détecté. Analysez les informations fournies par la valeur FailedMessage et résolvez la condition signalée. Si la condition signalée est un journal endommagé ou manquant, tentez de trouver un journal non endommagé avec le numéro de génération approprié. Si le journal correct est introuvable, utilisez la cmdlet Update-StorageGroupCopy pour effectuer un réamorçage. Si le message implique que les journaux sur la source ne sont pas disponibles, supprimez le partage sur le répertoire des journaux de la source et redémarrez le service de réplication sur ce noeud.

Des alertes, des compteurs de performance ou Get-StorageGroupCopyStatus indiquent que les files d'attente de copie ou de relecture sont sauvegardées pour une copie de groupe de stockage.

  • Causes possibles   Un retard de copie ou de relecture de journal peut indiquer soit un problème, soit une situation transitoire dans un processus de récupération. Une situation transitoire se produit quand un noeud passif précédemment hors ligne est mis en ligne ou quand une copie de groupe de stockage vient d'être reprise après avoir été suspendue pendant une période importante. L'arrêt du service de réplication de Microsoft Exchange sur le noeud passif a un effet similaire à la suspension de toutes les copies du groupe de stockage sur le noeud. Si la situation n'est pas transitoire, elle peut être due à l'une des causes suivantes :

    • problème de configuration ;

    • suspension de la copie de stockage ;

    • arrêt du service de relecture :

    • échec du stockage ou stockage hors connexion ;

    • noeud passif hors ligne.

  • Résolution   Déterminez s'il y a un problème réel ou s'il s'agit d'une situation transitoire :

    • Déterminez si le service de réplication de Microsoft Exchange est en cours d'exécution sur les noeuds. Pour ce faire, utilisez le composant logiciel enfichable Services. Si le service est arrêté sur l'un des noeuds, vous devez le démarrer.

    • Exécutez la cmdlet Get-StorageGroupCopyStatus de l'environnement de ligne de commande Exchange Management Shell avec l'option fl (liste mise en forme) et déterminez si la copie passive est suspendue. Si elle est suspendue, vérifiez que les fichiers de la copie passive sont présents, puis reprenez la copie du groupe de stockage à l'aide de la cmdlet Resume-StorageGroupCopy.

    • Exécutez la cmdlet Get-StorageGroupCopyStatus avec l'option fl, puis déterminez si la copie est « Saine ». Si l'état de la copie est « Échec », consultez la liste des champs d'état pour déterminer l'action corrective nécessaire.

    • Observez les compteurs de performance de réplication pendant quelques minutes pour déterminer si l'opération est en cours. Plus particulièrement, observez le numéro de génération de relecture et le numéro de génération d'inspection. Si la longueur de la file d'attente de copie continue à augmenter alors que la longueur de la file d'attente de relecture est faible ou décroissante, il y a peut-être un problème de partage de fichiers réseau sur le serveur actif ou de serveur actif proprement dit. Vérifiez que le répertoire des journaux de la copie de groupe de stockage active dispose d'un partage de fichiers réseau défini à l'aide de la commande « net share », de l'Explorateur Windows ou du composant logiciel enfichable Gestion de l'ordinateur. Vous pouvez identifier le GUID du groupe de stockage à l'aide de la cmdlet Get-StorageGroup avec l'option fl dans l'environnement de ligne de commande Exchange Management Shell.

Get-StorageGroupCopyStatus signale une heure de péremption pour LastInspectedLogTime

  • Causes possibles   Il y a trois causes possibles à ce problème :

    • La base de données de la copie du groupe de stockage active est démontée.

    • La copie du groupe de stockage active est montée mais elle ne change pas à une vitesse significative. C'est pourquoi, les journaux ne sont pas produits par la copie du groupe de stockage active.

    • Le service de réplication de Microsoft Exchange n'est pas en cours d'exécution sur le noeud passif.

  • Résolution   Déterminez laquelle des trois causes est rencontrée en procédant comme suit :

    • Déterminez si la base de données est démontée en utilisant la console de gestion Exchange ou en exécutant la cmdlet Get-StorageGroupStatus dans l'environnement de ligne de commande Exchange Management Shell. Si elle est démontée, vous devez monter la base de données et y apporter des modifications (par exemple, activité à l'intérieur de la base de données) avant le changement de LastInspectedLogTime.

    • Vérifiez que le service de réplication de Microsoft Exchange est en cours d'exécution sur le noeud passif. S'il est arrêté, vous devez le démarrer.

    • Après avoir vérifié que la base de données est montée, vérifiez si elle génère des journaux. Consultez le répertoire des journaux de la base de données active et identifiez le fichier journal dont le numéro de génération est le plus élevé. Vérifiez l'horodateur de ce journal ; il doit correspondre à la valeur de LastInspectedLogTime.

Le basculement ou Move-ClusteredMailboxServer réussit mais les bases de données ne sont pas montées

  • Causes possibles   La cause habituelle de ce problème est que le compte de service de cluster n'a pas l'autorité requise pour monter la base de données. De la même façon, le basculement a entraîné une perte de journaux plus importante que ne l'autorisent les paramètres de configuration du montage automatique. L'autre cause habituelle en cas de basculement est que les copies passives n'étaient pas saines au moment de la défaillance.

  • Résolution   Les problèmes d'autorisation en relation avec le compte de service de cluster se produisent généralement en cours d'installation. Si les bases de données ne sont pas montées à la fin de l'installation, cela indique en général que le compte de service de cluster ne dispose pas des autorisations appropriées. Pour résoudre le problème, affectez les autorisations appropriées au compte de service de cluster, puis effectuez un arrêt ordonné et redémarrez le cluster. Pour ce faire, (1) déconnectez le serveur de boîtes aux lettres en cluster, (2) arrêtez le noeud passif, (3) arrêtez le noeud actif, (4) démarrez le noeud actif, (5) démarrez le noeud passif et (6) mettez en ligne le serveur de boîtes aux lettres en cluster.

    • Consultez le journal des événements pour déterminer si le basculement a perdu plus de journaux que ne l'autorisent les paramètres de configuration du montage automatique. Après avoir déterminé l'état de la base de données de la copie du groupe de stockage, vous pouvez la monter de façon explicité en exécutant la cmdlet Restore-StorageGroupCopy dans l'environnement de ligne de commande Exchange Management Shell. Enfin exécutez la cmdlet Get-StorageGroupCopy et examinez la valeur SummaryCopyStatus pour déterminer s'il y a des problèmes avec la copie active précédente qui empêchent son montage. S'il y a un problème, consultez le journal des événements pour en identifier la cause, puis prenez les mesures nécessaires pour résoudre le problème.

Le basculement réussit mais certaines bases de données ne sont pas montées automatiquement ou manuellement. De la même façon, Get-ClusteredMailboxServerStatus signale une ou plusieurs bases de données en état d'échec.

  • Causes possibles   Un basculement récent a entraîné une perte de journaux plus importante que ne l'autorisent les paramètres de configuration du montage automatique. L'autre cause habituelle en cas de basculement est que la copie passive n'était pas saine au moment de la défaillance.

    Notes

    Des bases de données peuvent être brièvement marquées comme étant en état d'échec ou hors ligne durant une interruption programmée ou non. Cet état est transitoire et se produit lorsque le service de réplication tente d'effectuer une copie finale des journaux disponibles.

  • Résolution   Consultez le journal des événements pour déterminer pourquoi le montage de la base de données a échoué. Le montage de la base de données peut échouer en raison d'un endommagement de journaux ou de fichiers de base de données. Si les événements indiquent cela, restaurez l'accès à la base de données en déplaçant le serveur actif vers l'autre noeud. Vous pouvez déterminer si la base de données est en état d'échec en consultant le journal des événements. Après avoir déterminé l'état de la base de données de la copie du groupe de stockage, vous pouvez la monter de façon explicité en exécutant la cmdlet Restore-StorageGroupCopy dans l'environnement de ligne de commande Exchange Management Shell. Puis, exécutez la cmdlet Get-StorageGroupCopyStatus et examinez la valeur SummaryCopyStatus pour déterminer s'il y a des problèmes avec la copie active précédente, qui empêchent son montage. Si l'état indique que la copie du groupe de stockage est trop ancienne pour pouvoir l'activer, il est possible de restaurer la base de données lorsque le noeud défaillant est de nouveau en service et que davantage de journaux sont disponibles. Les journaux sont automatiquement copiés sans que vous deviez exécuter d'action.

Le montage d'une base de données au démarrage échoue dans un environnement de CCR

  • Causes possibles   L'échec du montage de la base de données peut résulter d'une action explicite de l'administrateur. Si une base de données est démontée de façon explicite, puis que le serveur de boîtes aux lettres en cluster est mis hors ligne, la base de données n'est pas mise en ligne au prochain démarrage. Une autre cause possible peut être que le nombre de journaux perdus au cours du basculement est supérieur à ce qui est acceptable.

  • Résolution   Vous pouvez exécuter la cmdlet Get-ClusteredMailboxServerStatus dans l'environnement de ligne de commande Exchange Management Shell pour vérifier que la banque est opérationnelle sur le noeud. La console de gestion Exchange ou l'environnement de ligne de commande Exchange Management Shell permet de tenter une opération de montage de la copie de base de données affectée. Pour plus d'informations sur le montage de la copie de base de données, consultez la rubrique Procédure de montage d'une base de données dans un environnement de réplication continue en cluster. Consultez le journal des événements après l'opération de montage pour déterminer si des erreurs ont été signalées.

L'événement de cluster MSExchangeRepl 2073, qui indique que le service de réplication de Microsoft Exchange ne parvient pas à trouver un répertoire spécifié, est enregistré.

  • Causes possibles   L'événement d'erreur indique que le service de réplication de Microsoft Exchange n'a pas pu créer le répertoire spécifié par l'événement. Le service de réplication de Microsoft Exchange tente de créer plusieurs répertoires requis s'ils n'existent pas déjà. Cela inclut les chemins d'accès au répertoire pour les fichiers journaux sources, les fichiers journaux de destination, les fichiers système de destination et le chemin d'accès de l'inspecteur de fichiers journaux.

    Le service de réplication de Microsoft Exchange ne parvient peut-être pas à créer le répertoire spécifié en raison d'un problème d'autorisation, d'un échec matériel ou d'un échec de configuration.

  • Résolution   Examinez le code d'erreur renvoyé par l'événement. Vérifiez que l'emplacement du répertoire est disponible et accessible. Vérifiez les autorisations du système de fichiers. Assurez-vous que le stockage est correctement configuré et que le matériel fonctionne correctement.

Move-ClusteredMailboxServer ne déclenche pas d'interruption programmée à cause d'un problème de réplication

  • Causes possible   La cmdlet Move-ClusteredMailboxServer de l'environnement de ligne de commande Exchange Management Shell inclut des contrôles de validation pour empêcher une interruption programmée d'un noeud passif si la réplication n'est pas totalement saine sur toutes les copies du groupe de stockage. Ce comportement garantit que les interruptions programmées ne s'étendent pas sur une période d'une longueur inappropriée.

  • Résolution   Identifiez les groupes de stockage présentant ce problème et corrigez-le. Le message d'erreur de la cmdlet Move-ClusteredMailboxServer identifie la copie du groupe de stockage problématique. Si vous voulez effectuer le déplacement et ignorer le contrôle de validation, assurez-vous que seule la base de données de la copie du groupe de stockage défaillante est démontée. Tentez de nouveau l'opération de déplacement, puis utilisez le paramètre -IgnoreDismounted. Le paramètre IgnoreDismounted indique que les groupes de stockage démontés doivent être ignorés à des fins de vérifications de la réplication.

La réplication n'effectue pas de re-synchronisation après un basculement sur un ou plusieurs groupes de stockage

  • Causes possibles   Le message d'échec renvoyé par la cmdlet Get-StorageGroupCopyStatus indique que la base de données est différente. Cette situation est due au fait qu'un basculement est intervenu lorsque le nombre de journaux répliqués de l'ancien serveur actif était insuffisant.

  • Résolution   Réamorcez la base de données à l'aide de la cmdlet Update-StorageGroupCopy dans l'environnement de ligne de commande Exchange Management Shell.

Échec de l'amorçage

  • Causes possibles   Une sauvegarde est en cours sur le serveur actif ou un problème de communication est survenu.

  • Résolution   Vérifiez qu'une sauvegarde de la copie du groupe de stockage affectée ou de la base de données n'est pas en cours. Assurez-vous que le noeud actif est en ligne.

Pour plus d'informations

Pour plus d'informations sur les cmdlets de l'environnement de ligne de commande Exchange Management Shell décrites dans cette rubrique, consultez les rubriques suivantes :

Pour plus d'informations sur la résolution des problèmes relatifs à la réplication continue locale, consultez la rubrique Procédure de dépannage des problèmes de réplication locale en continu.