Red Hat Cluster Suite: Konfiguration und Management eines Cluster | ||
---|---|---|
Zurück | Anhang C. Zusätzliche Software Information | Nach vorne |
Häufige Ursachen: Serieller Stromschalter ist vom steuernden Member getrennt. Netzwerk-Stromschalter ist vom Netzwerk getrennt.
Erwartetes Verhalten: Vom Stromschalter gesteuerte Member können weder heruntergefahren, noch neu gestartet werden. In diesem Fall, sollte ein solches Member hängen, werden Services nicht umgelagert (Failover).
Überprüfung: Führen Sie clustat aus, um zu prüfen, dass die Services auf dem anderen Member noch als running markiert sind, auch wenn dieses inactive ist.
Häufige Ursachen: Ein Großteil der Cluster-Member (z.B. 3 bis 5) gehen Offline.
Testfall: In einm 3-Member Cluster, beenden Sie die Cluster-Software auf zwei Membern.
Erwartetes Verhalten: Alle Member, die keine kontrollierenden Stromschalter haben, werden augenblicklich neu starten. Alle Services werden augenblicklich beendet und deren Status wird auf den gemeinsamen Medien nicht aktualisiert (wenn clustat ausgeführt wird, wird der Servicestatus eventuell noch running sein). Service-Managers beenden. Cluster-Locks gehen verloren und werden unverfügbar.
Überprüfung: Führen Sie clustat auf einem der verbleibenden aktiven Membern aus.
Häufige Ursachen: Vollständiger Verbindungsverlust zu anderen Membern.
Testfall: Trennen Sie alle Netzwerkverbindungen zu einem Cluster-Member.
Erwartetes Verhalten: Wenn der Member keine kontrollierenden Stromschalter hat, wird es sofort neustarten. Andernfalls, versucht es die Services so schnell wie möglich anzuhalten. Wenn eine Quorum besteht, wird die Gruppe von Membern, aus der der Cluster besteht, dieses Member auszäunen.
Testfall: killall -KILL clumembd
Erwartetes Verhalten: System-Reboot.
Testfall: killall -STOP clumembd
Erwartetes Verhalten: System-Reboot kann stattfinden, wenn clumembd länger als (failover_time - 1) Sekunden hängt. Extern vom Watchdog-Timer ausgelöst.
Testfall: killall -STOP clumembd
Erwartetes Verhalten: System-Reboot kann stattfinden, wenn clumembd länger als failover_time Sekunden hängt. Intern von clumembd ausgelöst.
Testfall: killall -KILL cluquorumd
Erwartetes Verhalten: System-Reboot.
Testfall: killall -KILL clusvcmgrd
Erwartetes Verhalten: cluquorumd spannt clusvcmgrd erneut auf, der die Stop-Phase aller Services ausführt. Angehaltene Services werden wieder gestartet.
Überprüfung: Sehen Sie die System-Logs für eine Warnung vom cluquorumd.
Testfall: killall -KILL clulockd
Erwartetes Verhalten: cluquorumd spannt clulockd neu auf. Locks werden eventuell für einen kurzen Zeitraum unverfügbar (was Service-Übergänge verhindert).
Überprüfung: Sehen Sie die System-Logs für eine Warnung vom cluquorumd.
Häufige Ursachen: Jegliches Szenario, das einen System-Neustart verursacht.
Testfall: reboot -fn; drücken der Reset-Taste.
Erwartetes Verhalten: Sollte ein Stromschalter den betreffenden Member kontrollieren, wird das System auch dann ausgezäunt (im Allgemeinen wird ein Power-Cycle durchgeführt), wenn ein Cluster-Quorum besteht.
Testfall: Halten Sie Cluster-Services (service clumanager stop) auf allen Membern an.
Erwartetes Verhalten: Alle verbleibenden Services werden unsauber beendet.
Überprüfung: Sehen Sie die System-Logs für Warnungen.
Erwartetes Verhalten: Services auf dem ausgezäunten Member werden an anderer Stelle im Cluster gestartet, falls möglich.
Überprüfung: Prüfen Sie, dass Services wirklich gestartet werden, nachdem der Member ausgezäunt wurde. Dies sollte lediglich Sekunden dauern.
Häufige Ursachen: Stromschalter gibt Fehlerstatus zurück oder ist unereichbar.
Testfall: Trennen Sie die Verbindung zum Stromschalter und führen Sie auf den von diesem kontrollierten Member reboot -fn aus.
Erwartetes Verhalten: Services auf einem Member der nicht ausgezäunt werden kann werden auf keinem anderen Member im Cluster gestartet. Sollte sich das Member erholen, werden die Services neu gestartet. Da es keinen Weg gibt den Status eines Members genau zu bestimmen, wird angenommen, dass dieses weiterhin betriebsbereit ist, auch wenn keine Heartbeats mehr gehört werden können. Deswegen sollten alle Services auf dem ausgefallenen Member als laufend markiert sein.
Überprüfung: Führen Sie clustat aus, um zu prüfen, dass die Services noch als laufend auf dem Member markiert sind, obwohl dieses anhand seines Membership inaktiv ist. Es werden Meldungen in die Log-Datei geschrieben, dass das Member nun den Zustand PANIC hat.
Testfall: Führen Sie dd aus,um Nullen zu der gemeinsamen Partition zu schreiben
dd if=/dev/zero of=/dev/raw/raw1 bs=512 count=1 |
shutil -p /cluster/header |
Erwartetes Verhalten: Ereignis wird protokolliert. Die Daten von der guten gemeinsamen Partition wird zu der Partition kopiert, die den Fehler gemeldet hat
Überprüfung: Ein erneutes Lesen der gleichen Daten sollte diese Fehlermeldung nicht mehr verursachen.
Häufige Ursachen: Gemeinsame Medien sind entweder unerreichbar oder beide Partitions sind korrupt.
Testfall: Ziehen Sie das SCSI- oder Fibre-Channel-Kabel von einem Member.
Erwartetes Verhalten: Das Ereignis wird protokolliert. Konfigurierte Aktionen werden ausgeführt um dem Verlust des Zugriffs auf gemeinsamen Speicher entgegen zu gehen (reboot/halt/stop/ignore). Die Vorgabe ist es ein Neustart auszuführen
Zurück | Zum Anfang | Nach vorne |
Failover und Recovery Szenarios | Nach oben | Häufige Verhalten: Zwei-Member Cluster mit Disk-basiertem Tie-Breaker |