Wer überwacht den Überwacher, oder Nagios hochverfügbar

An die Verlässlichkeit von Nagios gewöhnt man sich schnell und nach der Einführung von Nagios verliert man gerne das Bedürfnis sich aktiv die eigenen Systeme anzusehen. Stattdessen verlässt man sich auf die Alarme durch Nagios. Was passiert nun aber, wenn Nagios oder der Nagios Server selbst ein Problem hat? Wer überwacht den Überwacher? Oder wie stellt man sicher, dass Nagios Ausfälle erkannt werden?
Klar ist, dass das Monitoring von außen und nicht vom Nagios-Server selbst erfolgen muss, ansonsten wird man bei einem Ausfall des Nagios-Servers selbst nicht informiert. Um den Ausfall von Nagios zuverlässig zu erkennen reicht es auf von außen über nrpe oder ssh check_nagios auszuführen. Liefert es kein OK muss man sich um Nagios kümmern. Diese Lösung reicht für einfache Setups sicher aus. Anders ist dies jedoch, wenn die Überwachung Grundlage für das Reporting zu vereinbarten SLAs ist oder man wirklich alle Checkergebnisse möglichst lückenlos benötigt. Dann darf das Protokoll der ermittelten Messwerte, Verfügbarkeit oder die Ergebnisse der Tests keine Lücken aufweisen. So muss Nagios hochverfügbar werden.
Für die Hochverfügbarkeit kennt die Dokumentation von Nagios 2 einface Ansätze, nämlich Redundant Monitoring und Failover Monitoring . Beiden gleich ist, dass nur der primäre Nagios Server Notifications verschickt. Weil beim Failover Monitoring der Server im Standby Mode keine aktiven Servicechecks (jedoch Hostchecks!) ausgeführ, ist dieses Verfahren das bessere Setup. Mit der Ergänzugn von oscp/ohcp wird die Aufzeichnung lückenlose.
Failover Monitoring hat allerdings auch seinen Nachteil. Die Konfiguration und Installation muss synchron gehalten werden! Dieser Nachteil lässt sich natürlich mit einem SAN-System für beide System erschlagen. Stehen beide Nagiosserver nicht am gleichen Standort, so ist dies auch kein Problem. Mit DRBD steht ein “Netzerwerk-RAID1 System” zur Verfügung. Damit lassen sich beide System automatisch synchron halten.
Meiner Ansicht nach ist allerdings eine Lösung mit einem Storage-System nur etwas für wirklich erfahrene Linux Administratoren. Im Echtbetrieb tritt leicht mal eine Splitbrain Situation ein, bei der keiner der beiden Nagios Nodes weiß ob der andere noch lebt. Beide Systeme überwachen, schicken Notifications und schreiben Ihre Logfiles auf Platte. Mit der von SAN/DRBD Lösung erfordert ein Wiederzusammenführen dieser getrennten Systeme allerdings den manuellen Eingriff eines Administrators. Anders ist dies mit der Nagios Failover Lösung aus der Dokumentation. Nachdem Splitbrain schaltet der zweite automatisch wieder zurück. Den Nachteil der Synchronisation der Installation muss man da allerdings in Kauf nehmen. Wobei man meist nach der ersten vollständig Installation den ersten einfach klonen kann. Damit erschlägt man die ersten Probleme. Spätere Änderungen (neue Plugins, neue Software, …) muss man allerdings leider von Hand nachziehen. Rsync kann man verwenden, dass beide mit der gleichen Konfiguration arbeiten.
Mein Fazit
Ich empfehle den meisten die einfache Nagios Failover Methode. Der große Vorteil, dass Nagios nach der Splitbrain Situation wieder normal weiter macht wiegt meiner Ansicht nach den Synchronisationsaufwand auf.
Wie immer freue ich mich auf Feedback 🙂