Denn seien wir doch mal ehrlich: viele Cluster werden installiert und dann sich selbst überlassen. Man verlässt sich auf die vermeintliche Hochverfügbarkeit nur um festzustellen, das der zweite Knoten nicht funktioniert wie er soll wenn es darauf ankommt. Es ist tiefe Nacht, kurz vor Heiligabend und niemand ist zu erreichen.

Sicherlich kann es bei Routineschwenk zu Probleme kommen, aber dafür weiss man wann dieser passiert und man hat (hoffentlich) das benötigte Personal an Bord. Gefahr erkannt, Gefahr gebannt. Als Lohn gibt es die Gewissheit, das der nächste Schwenk ohne Probleme verläuft und wenn nicht sammelt man genug Erfahrungen um damit umzugehen.

So denke ich, das sich ein VMWare HA Cluster nur bedingt mit einen konventionellen HA-Cluster vergleichen lässt. Jörg Möllenkamp geht es wohl ähnlich. Zwar beschäftigt sich sein Posting vordergründig mit dem Widerlegen von Aussagen rund um VMware und Oracle, aber er zeigt ein paar Punkte auf die ich für vollkommen richtig halte.

Für mich noch viel Wichtiger: ein HA N+1 Cluster besteht aus N+1 mal Hardware sowie Betriebssystem, während man bei VMware zwar N+1 mal ‘Hardware’ hat, aber nur ein Betriebssystem. Deutlicher gesprochen: ein normales HA-Cluster macht einen Dienst hochverfügbar, VMware tut dieses aber nur für die Hardware. Geht in der VM das OS kaputt – Pech gehabt, beim HA-Cluster schwenkt man auf den nächsten Node. Bestimmt kann man mit Cloning und Scripting immer dafür sorgen eine (mehrere) Kopie(n) zur Hand zu haben, nur bietet das keine Garantie im Falle eines Falles eine funktionierende und getestete Umgebung vorzufinden, ob man sich darauf verlassen möchte muss jeder selbst wissen

Dabei gibt es hierfür keinen Grund, denn in der IT wird auch nur mit Wasser gekocht und das beste Mittel gegen Ehrfurcht und Berührungsängste ist es immer noch sich damit auseinander zu setzen.

Wer also einen Einstieg haben möchte kann recht problemlos mit dem Redhat Cluster beginnen, welches es auch von CentOS gibt. Besondere Hardware ist nicht nötig, das folgende Beispiel, auf Basis von CentOS 4.6, läuft zum Beispiel in einem VMWare Server.

Los gehts

Zum Starten benötigt man also zwei CentOS 4.x Installationen in der Minimal-Installation. Zuerst muss man das CSGFS-Repository auf beiden hinzufügen:

root@zap:~# cat /etc/yum.repos.d/CentOS-csgfs.repo
[csgfs]
name=CentOS-4 - CSGFS
baseurl=http://mirror.centos.org/centos/$releasever/csgfs/$basearch/
gpgcheck=1
enabled=1

Nach einem yum check-update kann die benötigte Software installiert werden:

yum install rgmanager system-config-cluster ccsd magma magma-plugins cman cman-kernel dlm dlm-kernel fence gulm iddev

Bevor es nun ans Cluster selbst geht, muss die Namesauflösung stimmen. Am besten man trägt die IP-Adressen der Cluster-Knoten und deren Hostnamen in die /etc/hosts ein. Ist eine Cluster-IP im Einsatz auch diese mit Hostnamen eintragen.

Funktionsweise

Der Redhat 4 Cluster besteht im Prinzip aus drei Teilen:

• cman – Der Cluster-Manager. Macht via Heartbeat eine Überwachung, ob alle Knoten da sind
• fenced – Verhindert das eine Rescource mehrfach benutzt wird. Dazu später mehr
• rgmanager – Der Service-Manager. Verwaltet die Rescourcen im Cluster

Alle drei werden über die XML-Datei /etc/cluster/cluster.conf gesteuert, welche man mit dem GUI system-config-cluster erstellen kann. Mit ihm ist es möglich die Cluster-Nodes, das Fencing, Cluster-Resourcen und letztlich die Cluster-Services zu definieren. Zusätzlich verfügt es noch über recht einfache Möglichkeiten das laufende Cluster zu überwachen und zu steuern. Im Alltag ist es allerdings nicht immmer brauchbar, da es manchmal nicht-validierenden XML-Code erzeugt oder es nicht möglich ist einen Cluster-Schwenk damit zu initiieren.

Konfiguration

Startet man system-config-cluster zu erstenmal wird man darauf hingewiesen, das der Cluster noch keine Konfiguration hat und ob man nicht eine Neue erstellen möchte. Folgt man dem, landet man in einem Fenster zu Konfiguration des Cluster-Managers. Ist man Unerfahren reicht es einfach Ok zu klicken, für die Fortgeschrittenen der Hinweis, das es keine Quorum-Disk benötigt um einen Redhat-Cluster zu betreiben. Wer es unbedingt möchte findet hier eine Anleitung.

Nun kann man die Cluster-Knoten hinzufügen. Dazu genügt es auf Cluster Nodes zu klicken, dann unten rechts Add a Cluster Node und im folgenden Feld den Hostnamen des Knotens anzugeben. Angaben zum Quorum kann man sich sparen.

Bild 1

Fencing

Einer der Knackpunkte beim Redhat Cluster ist das Fencing. Ein leicht beschönigender Name wie ich finde, das Linux-HA Projekt nennt eine ähnliche Funktionalität treffender Stonith (Shot the other node in the head) und genau das macht auch das Fencing im Redhat Cluster: Es verhindert das sich ein oder mehrere Knoten um eine Rescource prügeln und damit Datensalat erzeugen. Dabei geht es mitunter rabiat zu, indem einfach der betreffende Knoten abgeschaltet wird.

Welche Fence Device Typen es gibt und wie man sie konfiguriert findet man hier . Dabei dürften die schaltbaren Powerleisten von APC und WTI, sowie das Abschalten per OpenIPMI die am einfachsten zu nutzenden Devices sein. Letzteres ist bei neueren Server-Systemen, wie z.B. Sun X4200, schon oft vorhanden. Für das Beispiel hier reicht das Manual Fencing, welches logischerweise nicht für den produktiven Einsatz gedacht ist.

Ist nun für jeden Cluster-Knoten ein Fence Device erstellt muss es den betreffenden Knoten zugeordnet werden. Dazu geht man auf den betreffenden Knoten und klickt Manage Fencing for this Node, dann Add a new Fence Level und wählt den Level aus. Klickt man Add a Fence to this Level öffnet sich ein Fenster mit einem Dropdown-Menü, aus dem man das Fence-Device auswählen kann. Wichtig: Man ordnet jedem Server sein eigenes Fence-Device zu. Alles andere führt zu Tod und Chaos.

Failover Domänen

Beim Erstellen einer Failover-Domäne gibt es nicht viel zu beachten, ausser man gibt ihr einen Namen und ordnet beide Knoten zu. Natürlich ist dieses Feature sehr viel mächtiger, denn das Redhat Cluster ermöglicht nicht nur zwei Knoten-Cluster, sondern quasi eine unbegrenzte Anzahl von Knoten. Die Failover-Domäne gibt in solchen Fällen vor wohin, also auf welche Knoten, ein Cluster Service wandern kann.

Rescourcen

Nun wird es langsam spannend, denn spätestens jetzt muss man sich Gedanken über die Dienste im Cluster und woher sie kommen Gedanken machen. Links sieht man, welche Möglichkeiten vorgegeben sind. Spannend sind sie sicherlich alle, wobei Script natürlich die mächtigste Option ist, weil man hier tun und lassen kann was man will. Einige haben auch implizierte Abhängigkeiten, wie z.B. der Typ Filesystem. Hierzu muss das Device an allen Knoten sichtbar sein, ob es sich dabei um eine SAN-LUN (Multipathing ist dabei kein Problem) handelt oder Shared-SCSI (benutzt jemand noch soetwas?!) ist dabei zweitranging. Um beim Beispiel zu bleiben nehmen wir mal das einfachste, die IP-Adresse und tragen dort die geplante Adresse ein.

Initialisieren des Clusters

Damit ist ein wichtiger Teil abgeschlossen, denn nun kann man diese Konfiguration abspeichern und die Cluster-Dienste starten:

service ccsd start
service fenced start
service rgmanager start

Dabei lohnt es sich das Syslog im Auge zu behalten, denn dieses ist sehr auskunftsfreudig und zudem gut lesbar:

clnode1 kernel: CMAN 2.6.9-50.2.0.6 (built Nov  3 2007 07:57:09) installed
clnode1 kernel: NET: Registered protocol family 30
clnode1 kernel: DLM 2.6.9-46.16.0.12 (built Nov 13 2007 07:54:37) installed
clnode1 kernel: CMAN: Waiting to join or form a Linux-cluster
clnode1 kernel: CMAN: forming a new cluster
clnode1 kernel: CMAN: quorum regained, resuming activity
clnode1 ccsd[2809]: Cluster is quorate.  Allowing connections.
clnode1 cman: startup succeeded
clnode1 lock_gulmd: no <gulm> section detected in /etc/cluster/cluster.conf succeeded
clnode1 fenced: startup succeeded
clnode1 clurgmgrd[3157]: <notice> Resource Group Manager Starting
clnode1 clurgmgrd[3157]: <info> Loading Service Data
clnode1 clurgmgrd[3157]: <info> Services Initialized
clnode1 clurgmgrd[3157]: <info> Logged in SG "usrm::manager"
clnode1 clurgmgrd[3157]: <info> Magma Event: Membership Change
clnode1 clurgmgrd[3157]: <info> State change: Local UP
clnode1 rgmanager: Starten von clurgmgrd succeeded
clnode1 clurgmgrd[3157]: <notice> Starting stopped service web
clnode1 clurgmgrd: [3157]: <info> Adding IPv4 address 192.168.0.200 to eth0
clnode1 clurgmgrd[3157]: <notice> Service web started

Damit funktioniert der erste Cluster-Knoten. Nun noch die /etc/cluster/cluster.conf auf den anderen Knoten kopieren und die Dienste starten. Im Syslog sieht man es so:

clnode1 clurgmgrd[3157]: <info> Magma Event: Membership Change
clnode1 clurgmgrd[3157]: <info> State change: clnode2 UP

Startet man nun system-config-cluster sieht man einen zweiten Reiter (siehe Bild 1) für das Cluster Management. Änderungen an der Cluster Konfiguration sind nun über den Send to Cluster Button oben rechts möglich.

Cluster Services

Nun fügt sich alles zusammen, denn aus den Einzelteilen der Resourcen kann man sich einen Cluster Service zusammenbauen. Dazu klickt man auf Create a Service und gibt ihn einen Namen. Dann den Service-Namen auswählen, dann Edit Service Properties und man landet im Service Management (Bild 2).

Bild 2

Rechts oben die Failover-Domäne für diesen Dienst auswählen und darunter, wenn man möchte, die Recovery Policy. Im unteren Drittel geht es nun um die Rescourcen. Die erste Reihe entspricht der bereits bekannten Resourcen Konfiguration. Man könnte sich hiermit seine Dienste zusammenstellen, sie hätten aber keinerlei Abhängigkeiten zueinander. Die Dienste würden in loser Reihenfolge gestartet werden und bei Problemen könnte es ein ziemliches Durcheinander geben. In Bild 2 sieht man einen Cluster Dienst mit Abhängigkeiten. Zuerst die IP-Adresse, dann das File System und dann der Apache-Server. Erreicht wird dies durch klicken von Add a Shared Rescource to this Service und der Auswahl der Rescource im folgenden Fenster. Anschließend wählt man diese Rescource aus und klickt auf Attach a Shared Recource to this Selection. Genauso verfährt man beim letzten Service.

Unser Beispiel beschränkt sich ja nur auf eine IP-Adresse, also einmal Add a Shared Rescource to this Service, auswählen – fertig. Nach dem Abschicken der Konfiguration mit Send to Cluster sieht man im Cluster Management den Dienst starten. Fertig ist der Cluster Dienst (siehe Bild 3)

Bild 3

Cluster Management

Nun läuft er also. Allerdings sind die Informationen in system-config-cluster etwas dürftig und Scripten für eine Überwachung lässt es sich auch nicht. Da hilft zum einen clustat:

[root@clnode1 ~]# clustat
Member Status: Quorate

  Member Name                              Status
  ------ ----                              ------
  clnode1                                  Online, Local, rgmanager
  clnode2                                  Online, rgmanager

  Service Name         Owner (Last)                   State
  ------- ----         ----- ------                   -----
  web                  clnode1                        started

Zum anderen gibt es clusvcadm, welches den Cluster Management Teil der GUI beherrscht und auch den Cluster-Schwenk auf den zweiten Node:

clusvcadm -r web -m clnode2

Und die IP-Adresse? Tja, die sieht man nicht mit ifconfig, dafür benötigt es ip addr list.

Links

Zum Abschluß noch zwei weiterführende Links:

Red Hat Cluster Suite: Configuring and Managing a Cluster
Redhat FAQ