silvesterlangen.de

Seite
Menü

+FailOver mit Heartbeat/DRBD

Was ist ein Failover Cluster?

Ein Failover Cluster ist ein Zusammenschluss von mehreren Rechnern, die im Falle eines Ausfalls eines einzelnen Nodes (einzelner Server quasi) dessen Job übernehmen. Das Cluster hat eine einzige öffentliche IP-Adresse worüber es erreicht werden kann.

 

Wie funktioniert das denn?

Machen wir das am Beispiel von zwei Servern. Beide Server haben den Apache2 als Webserver laufen mit statischen Websites. Nehmen wir an, dass die Seiten nie verändert werden und auf beiden Servern absolut identisch sind. Im Klartext: Die Seiten wurden von einem Server auf den zweiten Server einfach rüberkopiert. Die Konfiguration der Server ist absolut identisch! Ein Server, Node1, ist der primäre Server, der immer antwortet, wenn Anfragen auf der öffentlichen IP rein kommen. Der zweite Server, Node2, ist inaktiv und wartet nur darauf, dass Node1 mal ausfällt. Kommt es zum Ausfall von Node1, dann bemerkt das Node2 und übernimmt die IP von Node1. Ab jetzt beantwortet Node2 die Anfragen aus dem Netzwerk. Den Umschaltvorgang nennt man Failover.

Kommt Node1 wieder online, dann übernimmt Node1 auch wieder die IP und Node2 wird wieder inaktiv. Diesen Vorgang nennt man dann Failback. Führt man das aber händisch aus, dann ist das ein Switchover. ;-)

 

Gibt es mögliche Probleme?

Ja, spontan fallen mir gleich zwei Probleme ein. Das erste Problem ist, dass Node2 im Falle eines Failovers möglicherweise nicht über die Informationen verfügt, die Node1 hatte bevor es zum Ausfall kam. Hier müssen wir uns überlegen wie wir dafür Sorge tragen können, dass Daten von Node1 auch auf Node2 verfügbar sind, sodass er einfach den Dienst übernehmen kann. Bei einer statischen Website ist das kein Problem. Man kopiert die Daten einfach rüber. Bei einem Dienst, der fortlaufend Änderungen hat (ein Forum bspw. oder ein Mailserver) ist das schon eine andere Liga. Hier müssen wir entweder mit einem SAN arbeiten oder die Daten permanent auf den anderen Node replizieren.

Problem Nr. 2 ist Splitbrain. Sagen wir, dass aus einem nicht bekannten Grund die Verbindung für die Heartbeat-Kommunikation gestört ist. Nun können die Nodes sich gegenseitig nicht erreichen. Beide Nodes "denken", dass er jeweils andere offline ist. Beide setzen sich "primary", übernehmen die Cluster-IP und versuchen dann zu arbeiten. Dabei haben wir zwei Probleme:

  • Erst mal einen wunderschönen IP-Crash (zwei Server nutzen die selbe IP).
  • Und dann noch ein Split Brain. Beide Datenbestände der replizierten Daten werden inkonsistent, da jeder Node etwas anderes auf die Platte schreibt.

Um einen Splitbrain zu vermeiden gibt es eine Möglichkeit: STONITH.

Das ist die Abkürzung und steht für "Shoot The Other Node In The Head". Dabei wird der erste Node an einen Killswitch gehängt den der zweite Node auslösen kann, wenn er Node1 nicht mehr erreicht. Der Node2 schießt quasi Node1 ab (schaltet ihn ab).

Was ist Heartbeat?

Heartbeat ist eine Software, die Failover und Failback quasi managed. Es übernimmt dabei die Überwachung und kann Dienste die benötigt werden starten und stoppen.

 

Was ist DRBD?

DRBD steht für Distrubuted Replicated Block Device und ist eine Software mit der Datenträger über das Netzwerk repliziert werden können. Sobald es eine Änderung auf einem Datenträger gegeben hat wird diese sofort auf den anderen Datenträger geschrieben. Für unseren Zweck ideal, denn so können wir die aktuellen Daten von Node1 auf Nod2 permanent übertragen und im Falle eines Failovers verfügt Node2 über alle benötigten Daten, die es braucht, um seine Arbeit aufzunehmen.

 

Was brauchen wir alles?

Mindestens zwei Server, die möglichst gleich sind. Also kein Xeon irgendwas und ein P166. ;-) Dann benötigen wir eine Grundinstallation der Lieblingsdistribution. Ich für meinen Teil greife gerne auf Debian oder CentOS zurück. Es reicht eine absolute Minimalinstallation. Auf Schnickschnack wie KDE etc. verzichten wir hier. Ein Server braucht sowas nicht.

Beide Server müssen sich gegenseitig erreichen können. Am besten einen Eintrag in die /etc/hosts machen oder entsprechend im DNS Einträge vornehmen. Das war die Hardwareseite. Zur Softwarseite gehören Heartbeat, DRBD und Pacemaker.

 

Installation und Konfiguration von Heartbeat

Am einfachsten ist die Installation per Paketmanagement wie apt oder yum. In diesem Beispiel verwende ich Debian, also wird mit apt gearbeitet.

apt-get - y install heartbeat

Danach wechseln wir in das Verzeichnis /etc/ha.d und erstellen eine Datei mit Namen ha.cf. Dort tragen wir folgendes ein:
node node1 node2 # Die Nodes, die am Cluster beteiligt sind.
ucast eth0 192.168.2.44 # Der Eintrag für die IP von Node1 wird von Node2 ignoriert.
ucast eth0 192.168.2.45 # Der Eintrag für die IP von Node2 wird von Node1 ignoriert.
ping 192.168.2.50 # Die öffentliche IP worüber das Cluster erreichbar sein soll.
debugfile /var/log/ha-debug.log # Das Debugfile.
logfile /var/log/heartbeat.log # Das Logfile.
deadtime 5 # Die Zeit die ein Node ausgefällt bis es zum FO kommt.

Die Datei abspeichern und die nächste Datei erstellen. Die Datei heißt: /etc/ha.d/haresources

node1 192.168.2.50

Das ist nur diese eine Zeile. In ihr legen wir fest welcher Node der primäre Node ist. Gefolgt von der Cluster-IP und dahinter kann man weitere Einträge machen womit man die Dienste (Apache2, Postfix, Speicherdienste etc). steuern kann. Im Falle eines Failovers könnte der Apache gestartet werden und der Zugriff auf ein Filesystem (SAN/NAS) wo die Daten liegen. Hier allerdings spielt es jetzt gerade mal keine Rolle. Das können wir später mal machen.

Jetzt fehlt noch eine weitere Datei, die erstellt/editiert werden muss. Das ist die /etc/ha.d/authkeys. In ihr wird ein gemeinsamer Schlüssel definiert, den beide Nodes verwenden. Dabei gibt es drei Möglichkeiten: Ohne Auth-key, SHA1 und MD5. Die Datei füllen wir mit folgendem Inhalt:

auth 1
1 crc # keine sicherheit
#2 sha1 HI! # oder ein gemeinsamer sha1-hash
#3 md5 Hello! # oder md5-hash

Wir machen das jetzt für die Testumgebung mit CRC. Allerdings darf sowas niemals im Produktivbetrieb laufen. Dann immer einen secured String generieren.

So, jetzt sollten wir alles zusammen haben. Die Datei authkeys die Rechte mit chmod 600 ausstatten und Heartbeat ein mal neu starten mit:

/etc/init.d/heartbeat restart

Vergisst man die Rechte, dann bekommt man eine Fehlermeldung und Heartbeat lässt sich nicht starten.

 

Failover testen

Für unseren Zweck installieren wir mal flott den Apache2 auf beiden Nodes. Zur besseren Erkennung dann die index.html in /var/www/html/ ändern, dass man sieht, wenn es einen Failover gegeben hat.

Möglichkeit 1 (brutal) :

Den Node1 einfach mal herunterfahren oder falls es eine VM ist einfach pausieren.

Man kann aber auch den Netzwerkstecker ziehen, wenn es eine physische Maschine ist.

Möglichkeit (umschalten) 2:

Einen Switchover ausführen mit hb_takeover oder hb_standby.

hb_takeover - Auf dem Node2 ausführen. Entreißt Node1 quasi die Aufgabe und wir primär.

hb_standby - Auf dem Node1 ausführen. Übergibt die Aufgabe an Node2.

 

Das war jetzt nur die halbe Miete. Wir müssen noch für die Replikation der Daten sorgen UND einen vernünftigen Ressourcen-Manager installieren.

weiter zu:

« vorige Seite Seitenanfang nächste Seite »
Seite
Menü
Earned Certificates:
LPIC-1 LPIC-1 LPIC-1
Powered by CMSimple | Template by CMSimple | Login