Ich versuche eine Check_MK Instanz mit dem Tool lifedump auf zwei weiteren Rechner bereitstellen, und erzeuge dazu mit eine Script die beiden Dateien config.cfg und den State alle paar Minuten. Die Dateien werden auf die beiden anderen Rechner verteilt und liegen dort bereit, bis der Hauptrechner ausfällt und der Spare PC zB die Config an ihren Ort kopiert und mit cmk -R aktiviert werden soll. Die beiden Spare Rechner sollen den “stop status” behalten, bis sie benötigt werden. Leider klemmt es bereits beim cmk -R mit Fehlermeldungen wie “Could not find any hostgroupe matching…” Kann ich das so nicht umsetzen.?
Ja, die RAW Adition ist das. ich habe auch eben probiert das ganze sites Verzeichnis zu kopieren, aber das sind jetzt schon 2 Gb an Daten. Kann man sicher mit rsync kopieren, aber das ist ja auch so eine Sache mit offenen Dateien, inkonssitenzen usw.
Das Ziel ist ja, das von den drei gleichen Instanzen nur eine aktiv ist, und die anderen beiden sollten gestoppt sein, damit kein Traffic zu den Zielen entsteht.!
Die Dateien, die der Befehl livedump -TC ausgibt für die Config und ohne für den Status. Hatte angenommen, das ich mit dem Dump der Config und dem Status auf einem anderen Check_mk im Havariefall übernehmen kann…
Das ist so nicht gemeint.
Livedump ist dafür vorgesehen um den Status eines Systems regelmäßig auf ein zweites System zu übertragen ohne das dieses zweite System etwas von der Konfiguration kennt oder auch nur Zugriff auf die überwachten Objekte braucht.
Beispiel:
System A überwacht ganz normal seine Systeme.
System B ist erstmal leer, mittels Livedump wird die Config erzeugt. Achtung es werden bei der Config Erzeugung nicht alle möglichen Sachen erzeugt deswegen bei dir auch der Fehler. Manche Sachen müssen manuell erfolgen oder aber das Livedump Script muss erweitert werden. Hab in meinem System die zweite Option gewählt
Danach sollte sich System B starten lassen. Alle Objekte sind dort nun im Status pending. In meinem Fall hole ich mir alle 2 Minuten den aktuellen Status von System A und übertrage diesen mittels Livestatus in System B. Somit sieht man immer den aktuellen Monitoringstatus von System A auch leicht verzögert auch auf System B.
Vorteil gegenüber einem “normalen” verteilten Monitoring ist, dass beide Systeme nix voneinander wissen müssen. Auf System B sehe ich im Falle eines Ausfalls von System A immer den letzten Status da dieser nie mehr aktualisiert werden kann.
System B wird nie Objekte selbst überwachen welche per Livestatus in diesem mit Daten befüllt werden.
Hmm, das nützt mir nichts. Ich möchte System A als Hauptsystem ansehen, und wenn es im Status auf gestoppt steht, soll System B oder C übernehmen. B und C sollen aber auf Stop stehen, wenn sie nicht erforderlich sind. Das Handling (Script) zum erfassen der Statuswerte ist schon fertig… Geht “nur” noch um das Datensparsame transferieren der Daten…
Das wäre der typische Anwendungsfall für einen Failover Cluster.
Also entweder mittels Appliance (Funktion eingebaut) oder aber selbst gebaut als normaler Linux Cluster.
Genau. Die Frage ist jetzt ja, kann man gefahrlos (ohne das Daten korrupt werden können) das Sitesverzeichnis an die beiden anderen Standorte syncen und dann jeweils den CMK “aktivieren”, der den Job machen soll.?? Die Datenmenge ist ja nicht unerheblich. Der Dump schien so schön klein, und ich wollte lieber die CMK Boardmittel zum erzeugen eines Abbilds nehmen, als das hinter seinem “Rücken” zu tun… Es sollte ja auch so sein, das wenn B eine Weile aktiv ist und dort Daten geändert wurden, der A das dann auch erhält, und das ohne bei einem Fehler so nach und nach die CMK Instanzen leer geräumt werden. Muss man ja alles beachten.
Denke grad über DRDB nach. Wenn /omd als repliziertes Device fungiert und CMK das dann so akzeptiert und man mit einem Script nur dafür sorgt, das nur ein Host im Status running ist, dann wäre das ja schon gelöst. Übersehe ich was?
Also einfach so ein DRBD nutzen wird nicht funktionieren
Das sollte machbar sein ist aber nicht schön - immer dran denken die Systemen haben unterschiedliche IPs und deine überwachten Geräte müssen auch mit alle IPs reden welche du verwendest bei den verschiedenen Rechnern?
Kurze Frage - warum 3 Systeme?
Das wird mit deiner manuellen Version gar nicht funktionieren. Bei einem richtigen Failover Cluster ist das kein Thema da funktioniert das.
Ehe du hier zu viel Arbeit investierst solltest dir mal die Preise der virt. Appliance anschauen das dürfte billiger sein wie einige Tage Arbeit verschwenden.
DRDB bietet mir doch an, einen Pfad an mehreren Standorten syncron zu halten. Wenn die Site und damit deren Linux User an allen Standorten bereits angelegt ist, dann klappt es hier in einem kurzen Test, das es so läuft. Muss nur das handling gemacht werden, welcher Rechner der primary ist, was ja davon abhängt, welches CMK grad aktiv ist. Drei wäre das Ziel… zwei geht evtl auch. Und das Routing ist kein Problem. Ich denke, ich muss mich in das Thema verteilte Dateisysteme noch etwas einlesen…
Ja, da bin ich gerade dran. Hab allerdings statt DRBD in einem Testsetup Glusterfs laufen. Bin aber noch nicht fertig. Ist aber vielversprechend… Hab auch die Disk nach /omd gemounted…
GlusterFS wird ab der 1.6 nicht mehr funktionieren, da Linux File Capabilities benutzt werden und diese nicht von einem User Space FS unterstützt werden.
Irgendwas ist doch immer.
Das ist doch, um zu vermeiden das gewissen Prozesse mit root Rechten laufen… Ich habe Gluster in der Version 9 im Test, hab bisher da keine Einschränkungen gefunden diesbezüglich.
Beim Installieren von checkmk auf einem Gluster FS hatten wir folgenden Fehler:
D: create 100750 1 ( 0, 992) 31456 /opt/omd/versions/2.0.0p11.cee/bin/mkeventd_open514;6159945f
Fehler: Entpacken des Archivs fehlgeschlagen bei Datei /opt/omd/versions/2.0.0p11.cee/bin/mkeventd_open514;6159945f: cpio: cap_set_file
Warnung: Es sind Scriptlet- oder andere nicht schwerwiegende Fehler bei der Verarbeitung aufgetreten.
Lass mich wissen wenn Du checkmk auf Gluster FS zum Laufen bekommst.
Generell unterstützt Tribe29 nur Ihre eigene Cluster Lösung. Eine CEE bekommt keinen Support wenn die Software in einer eigenen CLuster Umgebung läuft.
So, also es ist kurios. Es geht noch nicht mal, das die Installation durchläuft, wenn /opt oder /opt/omd auf das verteilte Filesystem gemountet sind. Hab aber nur die Fehlermeldung des dnf Paketmanager in /var/log/dnf.log gesehen. Finde das merkwürdig. Hab schon überlegt, ob ich den Mountpoint weiter “oben” platziere, wo die Configs und Daten liegen, wenn das Sinn macht. Hätte nicht gedacht, das das so kompliziert sein muss. Ist übrigens Rockylinux 8. Hab schon drüber nachgedacht auf Debian zu schwenken.
