Wir freuen uns, mit der Clever Elements GmbH unseren neuesten Kunden im Bereich Managed Service begrüßen zu dürfen. Clever Elements ist ein kleines Unternehmen unweit vom Moritzplatz direkt im Herzen Berlins. Namhaften Kunden wie z.B. Siemens, BMW und IBM bietet es eine Online-Software für E-Mail-Marketing, welche die Erstellung und Versendung von Newslettern so einfach und intuitiv wie nur möglich macht.
In den letzen Tagen haben wir die bestehenden Services auf ein neues HA-Cluster in unserem Rechenzentrum umgezogen. Ab sofort profitieren die Kunden von Clever Elements von der damit verbunden Leistungssteigerung und können sich auf die hochverfügbare Umgebung 24×7 verlassen. Die vorhandene Architektur erlaubt zudem ein flexibles Wachstum in der Zukunft ohne Downtime.
Die Arbeit von Clever Elements kann man im Social Media-Zeitalter natürlich auch auf Facebook verfolgen.
Wir freuen uns auf eine weiterhin gute Zusammenarbeit mit der Clever Elements GmbH.
NETWAYS Blog
Die etwas andere Clusterlösung
Für gewöhnlich laufen HA-Cluster im hot standby. Doch sowohl aus ökologischem Blickwinkel betrachtet, als auch aus technischen Beweggründen, muss das nicht in jeden Fall die beste Vorgehensweise sein.
Schon auf der NETWAYS Nagios Konferenz 2007 hielt Gerd Müller einen Vortrag über die Möglichkeiten des Monitoring IPMI Konformer Systeme. Dieser hat unseren langjährigen Kunden iwis motorsysteme GmbH & Co. KG in München angeregt IPMI als Lösungsmöglichkeit für Ihren Einsatzfall in Betracht zu ziehen.
Dort haben wir daraufhin eine auf IPMI basierende cold standby HA-Cluster-Lösung implementiert.
Ein Nagios Eventhandler übernimmt im Notfall die Koordination der zwei identisch konfigurierten Server. Zuerst wird versucht die Applikation neu zu starten und erst wenn dies nicht erfolgreich war, zwischen den Servern umgeschaltet. Das bedeutet in diesem Fall, dass Server1 letztlich komplett abgeschaltet, und Server2 hochgefahren wird, wenn sich die Anwendung auf dem ersten Server nicht mehr aktivieren lässt. Mittels eines via Fibre Channel angeschlossenen SAN-Systems werden dafür die Daten hochverfügbar vorgehalten.
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 🙂
