C.4. Häufige Verhalten: Zwei-Member Cluster mit Disk-basiertem Tie-Breaker

Verlust der Netzwerk-Verbindung zu anderen Membern, gemeinsame Medien noch verfügbar

Häufige Ursachen: Netzwerk-Verbindung verloren

Testfall: Trennen Sie alle Netzwerkkabel von einem Member.

Erwartetes Verhalten: Es findet kein Failover statt, ausser wenn Disk-Updates verloren gehen. Services können in den meisten Fällen nicht umgelagert werden, da der Lock-Server ein Netzwerkverbindung benötigt.

Ü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.

Verlust des Zugriffs auf gemeinsame Medien

Häufige Ursachen: Gemeinsame Medien verlieren Stromversorgung, ein verbindendes Kabel von einem Member zu den gemeinsamen Medien ist getrennt.

Testfall: Ziehen Sie das SCSI- oder Fibre-Channel-Kabel von einem Member.

Erwartetes Verhalten: Es wird kein Failover durchgeführt, ausser das Netzwerk ist auch verloren. Konfigurierte Aktionen werden ausgeführt um dem Verlust des Zugriffs auf gemeinsamen Speicher entgegen zu gehen (reboot/halt/stop/ignore). Die Vorgabe ist reboot. Diese Aktion kann dann einen Failover verursachen.

Hängen des Systems oder Absturz (Panic) auf Member X

Testfall: Kill cluquorumd und clumembd Daemons.

killall -STOP cluquorumd clumembd

Erwartetes Verhalten: Hängendes Cluster-Member wird von anderen Cluster-Membern ausgegrenzt. Services werden umgelagert. Konfigurierte Watchdog-Timer werden eventuell aufgerufen.

Starten der Cluster-Services ohne Netzwerkverbindung

Häufige Ursachen: Schlechter Schalter; einer oder beide Member sind vom Netzwerk getrennt

Testfall: Halten Sie Cluster-Services auf allen Membern an. Trennen Sie alle Netzwerkkabel von einem Member. Starten Sie den Cluster-Service auf beiden Membern.

Überprüfung: Es ist nicht gegeben, dass alle Services starten, da Locks eine Netzwerkverbindung benötigen. Da der Cluster-Manager ein vollständig verbundenes Subnet erfordert, wird dieser Fall auf einer so-gut-wie-möglich Basis behandelt, der Cluster ist im technischen Sinne jedoch nicht betriebsbereit.