Summary: Un basculement ou un arrêt inattendu et non planifié de la grappe peut avoir pour conséquence que vous ne puissiez plus accéder à vos boîtes aux lettres. Dans cet article, nous discuterons du problème de déconnexion et de reconnexion du gestionnaire de cluster de basculement avec les ID d'événement 1146 et 1265 et des solutions possibles pour résoudre de tels problèmes. En plus, vous en apprendrez plus sur un outil de réparation Exchange que vous pouvez utiliser pour remettre les boîtes aux lettres et d'autres données à partir d'une base de données endommagée.
Exchange Server dispose d’un excellent système de haute disponibilité avec le Database Availability Group (DAG). Dans cet article, nous parlerons de deux événements dans l’Observateur d’événements – ID d’événement 1146 et ID d’événement 1265, tous deux liés au Service de cluster Windows qui contrôle le groupe de disponibilité d’Exchange Server.
Examinons en détail les événements mentionnés.
ID d’événement 1146 – Microsoft Windows Failover Clustering
L’événement ID 1146 s‘affiche avec les informations suivantes :
"Le sous-système d’hôte de ressources du cluster (RHS) a été arrêté de manière inattendue. Une tentative de redémarrage est en cours. Cela est généralement dû à un problème dans une DLL de ressource. Veuillez identifier la DLL de ressource à l'origine du problème et signaler le problème au fournisseur de ressources."
Ce message indique qu’un élément lié au sous-système d’hôte de ressources de cluster (RHS) ne fonctionne plus. Pour résoudre le problème, vous devez d’abord vérifier quel fichier DLL est à l’origine du problème, en plus de le signaler à votre expert ou fournisseur Exchange Server. Pour comprendre la cause du problème, vous devrez mener une enquête plus approfondie.
Le message d’erreur indique que le sous-système s’est bloqué et qu’une tentative de redémarrage du sous-système est en cours. Cela se produit généralement lors de la récupération des données ou lorsque la ressource est en situation de blocage.
Si le délai de blocage (qui est de 20 minutes par défaut) s’écoule dans le service de cluster, le sous-système d’hôte de ressources de cluster (RHS) considère que le serveur a échoué et force un processus de basculement. Si l’un des nœuds est défaillant (avec un seul nœud dans la grappe), la grappe est arrêtée pour des raisons de sécurité.
ID d’événement 1265 – Microsoft Windows Failover Clustering
Cet ID d’événement apparaît en cas de blocage dans le sous-système hôte de ressources de cluster (RHS) ou en cas de panne de la DLL. Le processus est annulé à ce stade. Il s’agit d’une notification indiquant que le processus s’est arrêté et l’ID d’événement 1146 arrêtera le cluster.
Résolution du problème
Examinons la procédure à suivre pour remédier à ce problème.
- Tout d’abord, vous devez ouvrir le visualiseur d’événements et trouver l’entrée avec l’ID d’événement 1265. Notez la date et l’heure exactes ainsi que le nom et le type de la ressource. Cela vous aidera à résoudre le problème.
- Exécutez ensuite la commande Get-ClusterLog dans une fenêtre PowerShell en tant qu’administrateur et extrayez le journal du cluster.
- Cette opération crée le journal, que vous trouverez dans le fichier Cluster.log, sous C:\NWindows\NCluster\NReports.
- Vérifiez la date et l’heure exactes dans l’affichage de l’événement et recherchez-les dans le journal du cluster.
- Vous trouverez un événement similaire à celui ci-dessous.
ERR [RHS] RhsCall::DeadlockMonitor : L'appel ISALIVE a été annulé pour la ressource 'resource name'.
INFO [RHS] Activation du chien de garde de terminaison de l'ERS avec timeout 1200000 et récupération des données 3.
ERR [RHS] La ressource ResourceName gère un blocage. Nettoyage de l'opération en cours et arrêt du processus de l'ERS
Sur la base de l’erreur, vous pouvez reconnaître exactement quelle ressource est à l’origine du problème. Il peut s’agir de problèmes d’E/S ou de performances de la mémoire. Vous pouvez examiner l’utilisation des disques durs. Vous pouvez également vérifier s’il y a un disque défectueux dans le RAID ou si un disque dur défectueux a été remplacé mais que la reconstruction du RAID affecte les performances du serveur.
Pour conclure
Il se peut que vous ayez des problèmes avec les serveurs Exchange qui font partie du cluster. Après un redémarrage brutal, les services ne démarrent plus ou les bases de données ne peuvent plus être montées en raison de journaux de transactions ou de bases de données corrompus. La solution consiste à remettre en état la base de données des boîtes aux lettres Exchange . Cependant, cela signifie un travail supplémentaire pour le service et une perte de données pour l’entreprise.
Vous pouvez reconstruire le serveur Exchange et utiliser le mode de récupération pour remettre toutes les configurations du serveur Exchange, en préservant le nom de l’ordinateur et l’adresse IP. La partie récupération des données d’Exchange Server peut être effectuée avecStellar Data Recovery . Avec cette application, vous pouvez ouvrir des fichiers EDB corrompus à partir de n’importe quelle version d’Exchange Server, sans limitation de capacité. Vous pouvez parcourir les magasins de données et exporter la base de données récupérée de manière granulaire vers PST, directement vers une base de données Exchange Server en direct ou un locataire Office 365. L’application n’est pas limitée aux boîtes aux lettres des utilisateurs. Elle peut également récupérer les archives des utilisateurs, les boîtes aux lettres désactivées, les boîtes aux lettres partagées et même les dossiers publics. Stellar Repair for Exchange permet de réduire le RPO et le RTO. Il réduit également le risque de perte de données et le temps nécessaire à la récupération des données.
