ich habe das Problem bei der 1.6.0raw und Enterprise Edition, dass Clustered Services nach einiger Zeit in Stale gehen. Ist das euch auch schon aufgefallen?
Aufbau: zwei Windows Systeme als Cluster; Clustered Ressource => Filesystem; Cluster existiert mit eigener IP Adresse.
Wenn ich cmk -vv MyHost auf dem Cluster ausführe, wird der Service richtig angezeigt.
Es sieht so aus, als würden die Services, wenn sie am Cluster hängen nicht mehr abgefragt und gehen in Stale.
Kann das einer bestätigen?
Hi Christian,
ich habe es gerade eben mal ausprobiert, es scheint zumindest kein allgemeines Problem zu sein in der 1.6, bei mir gehen geclusterte Services nicht auf stale.
Eine Frage: Wir haben gerade zufällig genau das Problem, aber in der 2.0. Deshalb wollte ich fragen, ob das wirklich in der 1.6 aufgetreten ist bei dir.
Viele Grüße
Jörg
Aktuell tritt das Problem bei einer 1.6.0p17 Raw auf. In der 2.0 hab ich jetzt noch nicht getestet,
Ich habe das auch in einer anderen Umgebung gehabt, dort habe ich mir mit einem Cronjob geholfen.
Es sieht für mich so aus, dass wenn ich einen Cluster abfrage, die Service Informationen für die Notes nicht ermittelt werden.
Ich hatte bisher nur Probleme bei einer bestimmten Agent/SNMP Config der beteiligten Nodes und des Cluster Objektes. @ChristianM wie schaut dies in deinem Fall aus?
Die Cluster Resource darf aber nur auf einem Node vorhanden sein.
Filesystem selbst ist glaub ich nicht “Cluster aware” als Check.
Lieber mal einen Dienst ausprobieren welcher nur auf einem Node läuft und auf dem zweiten aus ist.
Der Cluster selbst muss wie die Node auch als CMK Agent konfiguriert sein.
das Filesystem ist schon Cluster aware. Die Konfiguration ist auch so gemacht, dass alle beteiligten System den gleichen Agent Typ haben. Es funktioniert ja auch richtig, wenn der Cluster Rescheduled wird oder du cmk aufrufst. Es sieht für mich aus, als würde einfach die Abfrage der Cluster nicht von Core oder den Helpern gemacht.
Mein großes System hier (mit über 30 Windows Clustern) läuft auf P12 und hat bisher keine dieser Probleme/Effekte.
Das sind eigentlich alles Clusters welche per Overlapping Clusters Rule mit Services versorgt werden. Im Windows gibts ja nix anderes wie Overlapping Clusters in der Regel.
Immerhin für mein 2.0er Testsystem mit build vom 11.11. kann ich den Fehler bestätigen.
Hab auch mal das typische Filesystem Q: (Quorum) geclustert und der Check erhält Daten für das Filesystem C: ist sehr sportlich die Annahme
Hier geht auch nix mit manuell checken da ja falsche Daten geliefert werden für den Cluster Check.
Na wenigstens bin och nich alleine. Das muss irgendwie zwischen 1.6.0p12 und 2.0 hinein gekommen sein. Es mach auch keinen Unterschied zwischen RAW oder EE.
Hallo zusammen,
ich weiß nicht, ob euch die Info hilft, habe das gleiche Verhalten auch mit der 1.6.0p18 Raw festgestellt.
Ebenfalls im Zusammenhang mit Windows File Server Cluster-Diensten.
