Besonderheiten in der Administration von OMD-Sites
Glückwunsch – wenn Sie bis hier her gekommen sind, kann Sie der Rest auch nicht mehr schocken. Jetzt ist der Moment, an dem wir auf Dinge eingehen müssen, in denen sich unser geclustertes OMD von einer single-server-Installation unterscheidet.
Anlegen neuer Sites
Die OMD-Site “siteA” aus den vorangegangenen Teilen dieses Tutorials funktionierte auf Anhieb auf beiden Nodes. Dies trifft nicht auf zukünftige Sites zu – lesen Sie, warum:
Das Kommando omd create [site] legt nicht nur die Verzeichnisse an, mit denen wir bisher zu tun hatten – pro Site wird auch ein gleichnamiger User incl Gruppe erzeugt und ein tmpfs in /etc/fstab eingetragen. Diese Info zwischen den Nodes zu synchronisieren, wäre eine Fleißaufgabe, um die ich gerne einen Bogen mache – erstens) weil es einfach kein allzu großer Aufwand ist, sich um diese beiden Punkte noch zu kümmern, und zweitens) weil das Erstellen von Sites nun wirklich kein täglich Brot ist.
Lassen Sie uns davon ausgehen, dass Node2 aktiv ist, und wir nun im Durchmarsch eine neue Site erstellen möchten, die auch vom Cluster verwaltet werden soll.
Erstellen Sie die neue Site, starten Sie sie und testen Sie den Zugriff unter http://nagios/siteB/:
Adding /omd/sites/siteB/tmp to /etc/fstab.
Created new site siteB with version 0.46.
Restarting Apache...OK
Creating temporary filesystem...OK
Successfully created site siteB.
root@nagios2:# omd start siteB [enter]
(Preisfrage: warum wird dieser Befehl auf Nagios1 fehlschlagen? Wenn Sie die Antwort nicht wissen, gehen Sie über Los und fangen Sie am besten von vorn an.)
Wir lesen nun die fstab und passwd-Dateien aus – notieren Sie sich die Ausgaben folgender Befehle:
tmpfs /omd/sites/siteB/tmp tmpfs noauto,user,mode=755,uid=siteB,gid=siteB 0 0
siteB:x:1002:1002:OMD site siteB:/omd/sites/siteB:/bin/bash
Zum Erzeugen des tmpfs auf Node1 reicht es, dort die 1. Zeile ans Ende der Datei /etc/fstab anzuhängen.
Den dortigen User erzeugen Sie incl Gruppe wie folgt – ersetzen Sie GID und UID mit den IDs, die Sie auf Node2 ausgelesen haben (User und Gruppe ohne UID/GID anzulegen kann schiefgehen, da Sie sich nicht darauf verlassen können, dass beide Nodes hierfür automatisch die gleichen Werte vergeben):
usermod -aG siteB www-data [enter]
useradd -u [UID] siteB -d '/omd/sites/siteB' -c 'OMD site siteB' -g siteB -G omd -s '/bin/bash' [enter]
Wechseln Sie in die crm-shell und legen Sie die neue Site als primitive an (sie sollten die Site danach bereits in der GUI sehen)…
op monitor interval="10s" timeout="20s" \ [enter]
op start interval="0s" timeout="90s" \ [enter]
op stop interval="0s" timeout="100s" \ [enter]
params site="siteB" [enter]
crm(live)configure# commit [enter]
…erstellen Sie colocation und order für siteB…
crm(live)configure# order ord_omd_before_siteB inf: group_omd:start pri_omd_siteB:start [enter]
crm(live)configure# commit [enter]
…und bewundern Sie das Ergebnis in der GUI:
Schlusswort/Ausblick
Ausgehend vom Endresultat dieses Tutorials lassen sich natürlich noch viele Dinge tunen, dazubauen, überwachen, automatisieren etc. Mein Ziel war es vielmehr, Ihnen einen ersten “Durchstich” zu ermöglichen, um von hier ausgehend selbst weiterzubauen.
Wärmstens empfehlen möchte ich an dieser Stelle das Buch “Linux Hochverfügbarkeit” von Oliver Liebel, erschienen im Verlag “Galileo Computing”, erschienen 2011.
Egal ob Korrekturen oder Verbesserungsvorschläge, ich würde mich sehr über Feedback freuen! Entweder hier über die Kommentarfunktion oder unter office@simon-meggle.de.
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 1
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 2
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 3
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 4
Nagios/OMD-Cluster mit Pacemaker/DRBD – Teil 5
5 Kommentare
So muss ein Tutorial aussehen, klappt bei uns auf Anhieb!
Vielen Dank!
Klasse, freut mich!
Ich hatte letztens noch einen tollen Vorschlag für den Ressource Agent bekommen, den ich bei Gelegenheit einarbeiten werde.
Grüße!
Simon
Gutes und verständliches Tutorial, jedoch kam ich bei der Nutzung dieses Setups auf ein kleines Problem.
Zwar weden die Hostlisten durch die main.mk synchronisiert, wenn man jedoch eigende Checks schreibt oder schon bestehende editieren möchte, wird dies nicht automatisch synchronisiert.
Dann muss man entwerder dafür sorgen, dass der Ordner /versions mitgesyncht wird oder die Änderung auf allen Nodes per Hand machen.
Trotzdem sehr gute Arbeit.
Hallo Philipp,
danke für das Feedback. An den Plugins in lib/nagios/plugins solltest Du nichts verändern. Hierfür ist bereits local/lib/nagios/plugins vorgesehen, wofür auch schon ein eigenes USER2-Macro eingerichtet ist:
Es gibt bestimmt mehrere Wege für einen solchen OMD-Cluster, aber ich habe nach vielen Tests entschieden, dass es besser ist, jedem Node seine “eigene” OMD-Installation (=versions/ ) zu lassen. Ein OMD-Node sollte beim Updaten nicht auf den Sync vom anderen Node angewiesen sein.
Grüße!
Simon
Danke aber es ging mir nicht primär um das Einfügen neuer Checks, sondern um das Editieren der bereits vorhandenen.
Wir nutzen primär check_mk, dessen Checks leider standardmäßig unter [lisa]~/share/check_mk/checks liegen.
Nun kann man manuell die Checks regelmäßig editieren aber ich dachte, dass dass wenn wir schon die Synchronisierung haben, dass wir diese auch für die Standardchecks nutzen können.
Einen Kommentar schreiben