Nagios hochverfügbar mit Heartbeat v2

Transkript

1 Nagios hochverfügbar mit Heartbeat v2 Vortrag auf der Netways Nagios Konferenz 08 B1 Systems GmbH

2 Das Linux HA Projekt Das Linux High Availability Project, kurz Linux HA, hat sich das Ziel gesteckt, eine hochverfügbare, redundante und servicefähige Cluster-Software zu entwickeln, die auf jeder Linuxdistribution eingesetzt werden kann.

3 Das Linux HA Projekt Diese generische Software ist in der Lage, sämtliche initskriptgesteuerten Vorgänge auf jedem Knoten des Clusters zu kontrollieren im Bedarfsfall Ressourcen auf andere Knoten auszulagern (Fencing)

4 RAS steht für... Reliability Availability Verwaltung von Ressourcengruppen, Serviceabhängigkeiten, Prioritätssteuerung und Clustermitgliedschaften Serviceability Optimiert für den Einsatz von bis zu 16 Knoten innerhalb des HA Clusters

5 Features von Heartbeat Heartbeat V2 wird nach dem Open Cluster Framework (OpenCF) entwickelt und integriert die Verfügbarkeit sowie die Verwaltung von gemeinsamen Ressourcengruppen, Serviceabhängigkeiten und Prioritätssteuerung. Auch die Clustermitgliedschaft wird über Heartbeat V2 verwaltet. Es sind bis zu 16 Knoten innerhalb eines Linux HA-Clusters möglich.

6 Betriebsarten Heartbeat kann auf zwei Arten oder einer Mischung aus beiden betrieben werden: Aktiv-Aktiv als Loadsharing-Cluster Aktiv-Passiv als Hochverfügbarkeitscluster Bei einer Loadsharing-Installation werden Ressourcen durch Gruppen über mehrere Knoten hinweg zur Lastverteilung platziert.

7 Basiskonfiguration Die Konfiguration geschieht an zwei Punkten: Statische Konfiguration unterhalb von /etc/ha.d/ Dynamische Konfiguration: wird in der Cluster Information Base (kurz CIB) abgelegt

8 CIB Laufzeitreplikation die CIB wird zur Laufzeit auf alle im Cluster befindlichen Knoten repliziert Änderungen an der Konfiguration via Heartbeat GUI werden daher sehr schnell und ohne Neustart wirksam die CIB wird in XML (Extensible Markup Language) verwaltet

9 Basis Konfiguration Die statische Konfiguration wird in den folgenden Dateien unterhalb von /etc/ha.d/ definiert...

10 /etc/ha.d/ha.cf Festlegen der Kommunikationsschnittstelle (/dev/ttyx, ethx etc.) Einstellen der Übertragungsart bei Verwendung von Ethernet (Bcast, Ucast, Mcast)

11 /etc/ha.d/ha.cf Hier werden das Kommunikationsinterface und die Kommunikationsart (Broadcast, Multicast oder Unicast) festgelegt, die für die Übermittlung von Keep-Alive Nachrichten verwendet werden sollen. Man bedenke dass stets redundante Netzwerkpfade zu anderen Knoten genutzt werden um single point of failure -Szenarien zu vermeiden. Es ist sinnvoll, ein separates Interface nur für die Heartbeat-Kommunikation zu verwenden. Dies gewährleistet dass die Kommunikation nicht durch Netzwerklast unterbrochen und eine Inkonsistenz des Clusters riskiert wird.

12 /etc/ha.d/authkeys Schlüssel und dessen Algorithmus festlegen (CRC, MD5, SHA1) Hier wird der Algorithmus für die interne Kommunikation sowie ein Schlüsselwort festgelegt, mit dem sich die Clusterknoten verständigen.

13 /etc/ha.d/authkeys Dieser Datei ist besonders dann Aufmerksamkeit zu schenken, wenn es um DoS-Attacken in produktiven Umgebungen geht. Mögliche Algorithmen bei der Authentifizierung: CRC Einfaches Verfahren für Fehlererkennung MD5 Hashing Algorithmus mit Verschlüsselung (128 bit) SHA1 sinnvollster Algorithmus (160 bit)

14 /etc/logd.conf Hier werden loglevel-spezifische Optionen wie zum Beispiel die zu verwendende syslog facility und der Pfad zur Logdatei eingetragen. Beispiel: debugfile /var/log/ha-debug logfacility local0

15 Watchdog Damit sichergestellt ist, dass die Prozesskommunikation auf dem Knoten auch einwandfrei funktioniert, bedarf es einer zusätzlichen Komponente: Watchdog bei einer zu hohen Systemlast wird das System neu gestartet / heruntergefahren

16 Watchdog softdog der am meisten genutzte Watchdog unter Linux ist softdog eine auf Software basierende Implementation eines Watchdogs im Linux-Kernel diese Erweiterung ist in produktiven Umgebungen erforderlich, um jeden Knoten vor eigenen Fehlern zu schützen, die eine zu hohe Systemlast erzeugen

17 Heartbeat-Tools Die gängigsten Tools, die Heartbeat bereitstellt, im Überblick: crm_resource: modifiziert Clusterressourcen crm_standby: ändert den Status von Knoten crm_uuid: empfängt und ändert eindeutige Clusteridentifikationen crm_verify: verifiziert Einträge der CIB cl_status: zeigt Knoten-Verbindungsstatus

18 Heartbeat Tools hb_gui hb_gui die grafische Heartbeat Administrationskonsole Das grafische Administrationsinterface kann von jedem Knoten des Clusters aus aufgerufen werden. Um dieses Feature jedoch nutzen zu können, muss auf jedem Knoten, von dem diese Konsole erreichbar sein soll, das Passwort für den hacluster-benutzer gesetzt sein! Um bei mehren Clustern eine zentrale Verteilung der Benutzerdaten/Kennwörter zu ermöglichen, bieten sich NIS oder LDAP an.

19 Screenshot hb_gui

20 Ressourcen Dienste werden nicht mehr durch Runlevel sondern durch Heartbeat selbst organisiert Innerhalb von Heartbeat werden Dienste als Ressourcen behandelt, welche unter Konten hin- und hergeschoben werden können. Für jede Ressource bedarf es eines passenden Initskripts unterhalb /etc/ha.d/resource.d/, mit dem Heartbeat die gewünschten Operationen auf den Knoten verwalten/ansprechen kann.

21 Arten von Ressourcen LSB Linux Standard Base Resource LSB-Ressourcen sind normale Initialisierungsskripte wie zum Beispiel die von Nagios und Apache2 unterhalb von /etc/init.d/. Sie unterstützen keine Übergabe von zusätzlichen Attributen und sind daher recht unflexibel.

22 Arten von Ressourcen OCFR Open Cluster Framework Ressource Open Cluster Framework Ressourcen sind flexibler, jedoch können diese nicht ohne Cluster Information Base (CIB) eingesetzt werden.

23 Vorteil OCF Ressourcen Falls vorhanden, immer OCF Ressourcen verwenden, da diese flexibler konfigurierbar sind.

24 Live Konfiguration Aufzeigen der Clusterkonfiguration Erläuterung zu den Konfigurationsdateien / GUI Simulation eines Ausfalls des ersten Knoten Es wird ein simpler Aktiv-Passiv Cluster für die Hochverfügbarkeit von DRBD, Nagios und Apache2 eingerichtet. Danach wird ein Ausfall des ersten Knoten simuliert.

25 Knotenkonfiguration (Xen) Beide Knoten werden identisch eingerichtet, angefangen bei der Partitionierung bis hin zu den Netzwerkgeräten. Die Hostsysteme, auf denen die Knoten abgebildet sind, werden mittels Xen als dessen Gäste virtualisiert. Konfigurationsübersicht: Partitionierung Netzwerkgeräte & Netzwerksetup Softwareversionen

26 Partitionierung Das Partitionierungsschema für die Umgebung ist recht simpel gehalten: Erstes Laufwerk mit 4GB für swap & root Partition Zweites Laufwerk mit 1GB für den DRBD-Netzwerkspiegel (/etc/nagios/)

27 Netzwerkgeräte & Netzwerksetup Es werden zwei (para-)virtualisierte Netzwerkadapter für jeden Knoten bereitgestellt. Der erste Adapter eth0 wird für die öffentliche Anbindung und den DRBD Datentransfer benutzt. Der sekundäre Adapter eth1 wird lediglich für die Cluster Kommunikation unter den Knoten verwendet. Die Hostnamen werden in der aufgelisteten Reihenfolge in die /etc/hosts eingetragen (knoten*-intern für Heartbeat-Kommunikation) hostname knoten1: eth /24 hostname knoten1-intern: eth /24 hostname knoten2: eth /24 hostname knoten2-intern: eth /24

28 Verwendete Software Für die Knoten werden die in SLES10 SP2 mitgelieferten Software Versionen verwendet. heartbeat nagios nagios-www apache apache2-prefork

29 Live Demonstration Live demo

30 Bevor es losgehen kann... müssen die Voraussetzungen für den Cluster geschaffen werden. Zeitabgleich via NTP (entfällt bei Xen Gästen da Synchronisation über Dom0) Eindeutige Knoten Namen mit IP Zuordnung in der Datei /etc/hosts für intern/extern Im Produktivbetrieb die DNS Konfiguration sicherstellen um externe Erreichbarkeit zu gewährleisten

31 Live Demonstration Nun wird folgendes demonstriert: Backup des Ordners /etc/nagios/ nach /etc/nagios_backup/ Eintragen des /dev/drbd0 Geräts in die /etc/fstab (einhängen auf /etc/nagios/)

32 Live Demonstration Nun wird folgendes demonstriert: Konfiguration von DRBD auf beiden Knoten Heartbeat-Konfiguration

33 Live Demonstration Nun wird folgendes demonstriert: Synchronisation der Konfigurationsdateien zwischen beiden Nodes Runlevel für heartbeat, nagios, apache2 und drbd anpassen

34 Live Demonstration Nun wird folgendes demonstriert: Ressourcen Konfiguration mittels Heartbeat GUI nach erfolgreicher Konfiguration Ausfall des ersten Knoten simulieren

35 Erläuterung zu den Konfigurationsdateien Und nun einen ausführlichen Blick auf die Konfigurationsdateien: /etc/hosts /etc/fstab /etc/drbd.conf /etc/ha.d/ha.cf /etc/ha.d/authkeys Nagios und Apache2 behalten ihre Standardeinstellungen bei da es hier lediglich darum geht, die Erreichbarkeit des Nagios Web Interface zu demonstrieren.

36 Abschließende Hinweise zu Heartbeat Beim Durchstarten des Clusters sollte immer der Knoten zuerst gestartet werden der zuletzt als aktiver am Netz war und den aktuellen Nutzdaten Bestand hat. Bei einem Neustart des Systems wird von DRBD gefragt welchen Status der nun gestartete Knoten haben soll. In aller Regel wird diese Frage auf dem zuletzt primären Knoten mit Yes beantwortet.

37 Abschließende Hinweise zu Heartbeat STONITH ist ein Akronym für Shoot The Other Node In The Head Hardware Varianten können Stromleisten (APC) mit Ethernet Schnittstelle oder Netzwerk Switches mit verwaltbarer Stromzufuhr sein

38 Abschließende Hinweise zu Heartbeat STONITH Geräte können auch durch eine SSH Verbindung nachgebildet werden welche den defekten Knoten im Ernstfall herunterfährt (Nicht für produktive Umgebung geeignet!) externe Hardware Variante ist sicherer da diese im Ernstfall dem Knoten den Saft abdreht und somit auch Nutzdaten schützt, da der Knoten nicht mehr mit anderen Knoten kommunizieren kann

39 The end... Vielen Dank für Ihre Aufmerksamkeit ;-)