C.3. Häufige Clusterverhalten: Allgemein

Verbindungsverlust zu einem Stromschalter oder Fehler beim Einzäunen eines Members

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.

Auflösung des Cluster-Quorum

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.

Member verliert teilnehmenden Status im Cluster-Quorum, hängt allerdings nicht

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.

clumembd stürzt ab

Testfall: killall -KILL clumembd

Erwartetes Verhalten: System-Reboot.

clumembd hängt, Watchdog in Verwendung

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.

clumembd hängt, kein Watchdog im Einsatz

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.

cluquorumd stürzt ab

Testfall: killall -KILL cluquorumd

Erwartetes Verhalten: System-Reboot.

clusvcmgrd stürzt ab

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.

clulockd stürzt ab

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.

Unerwarteter System-Reboot ohne sauberes Herunterfahren von Cluster-Services

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.

Verlust des Quorum während einem sauberen Shutdown

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.

Erfolgreiche STONITH Fencing-Operation

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.

Fehlgeschlagene Fencing-Operation auf Cluster-Member

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.

Fehler beim Lesen von einer der gemeinsamen Partitionen

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.

Fehler beim Lesen von beiden gemeinsamen Partitionen

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