Red Hat Cluster Suite: Konfiguration und Management eines Cluster | ||
---|---|---|
Zurück | Anhang C. Zusätzliche Software Information | Nach vorne |
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.
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.
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.
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.
Zurück | Zum Anfang | Nach vorne |
Häufige Clusterverhalten: Allgemein | Nach oben | Häufige Verhalten: 2-4 Member Cluster mit IP-basiertem Tie-Breaker |