Hochvef�gbarkeitssysteme mit Linux

ArticleCategory: [Choose a category for your article]

System Administration

AuthorImage:[Here we need a little image from you]

TranslationInfo:[Author and translation history]

AboutTheAuthor:[A small biography about the author]

Atif ist ein Cham�leon. Er ver�ndert seine Rollen von Systemadministrator zu Programmierer, zu Lehrer, zu Projektmanager oder was immer in seinem Beruf ben�tigt wird.
Gelegentlich findet man ihn sogar auf der Toilette mit seinem Laptop wie er gerade dabei ist, Dokumentation zu schreiben. Atif glaubt da� er Linux und der Open-Source Gemeinde sehr viel verdankt. Mehr �ber ihn findet man auf seiner Homepage

Abstract:[Here you write a little summary]

W�hrend der Entwicklung eines f�r sein Unternehmen extrem wichtigen Systems wird man sich follgende Fragen stellen:

Wie wichtig sind die Dienste, die auf diesen Computern laufen f�r das Unternehmen?
Wie viele andere Dienste sind von diesem einzelnen Dienst, der auf dem neuen Computer laufen soll abh�ngig (denk an NIS/NFS/DB/LDAP Server)
Was passiert, wenn ein Teil der Maschine versagt? (Stromversorgung, Netzwerk, Festplatte ...)
Was passiert, wenn die Maschine v�llig ausf�llt?

Wenn ich mir selbst diese Fragen stelle, dann ist die Antwort fast immer :
Man wird mich feuern:)

Andererseits, wenn ich mir die Frage stelle "wird das Betriebssystem versagen?" dann ist die Antwort
Nein. Weil ich keine 32 Bit Erweiterung f�r einen 16 bit Patch auf einem 8 bit Betriebssystem benutze, da� urspr�nglich f�r einen 4 bit Microprozessor von einer 2 bit Firma entwickelt wurde, die nicht ein bit (bi�chen) Konkurrenz ausstehen kann.
Der Spruch war von einer .signature Datei

Nun zu einer ernsthafen Diskussion

ArticleIllustration:[This is the title picture for your article]

High Availability Systeme under Linux -- Image borrowed from http://lwn.net/Gallery/i/suits.gif

ArticleBody:[The article body]

Warum HA?

Ha steht f�r High Availability, zu Deutsch Hochverf�gbarkeit. Ich habe gro�es Vertrauen in Linux, aber ich habe wenig Vertrauen in die Firmen, die die Hardware entwickeln. Bei einem Server der Tag und Nacht l�uft, wird eines Tages die Stromversorgung, die Netzwerkkarte, das Motherboard, u.s.w... versagen. Dadurch wird mein Server zusammenbrechen. Weil dieser Server versagt, werden unter Umst�nden weite Teile des Firmennetzes versagen. Z.B:

Ein Service, von dem ich nicht wu�te, da� er existierte, funktioniert pl�tzlich nicht mehr, weil er die Domain billingSys106.company.com nicht mehr finden kann. Hmmm, was k�nnte der Grund sein. Oh, ja, auf meinem Server l�uft der DNS Server, der den Domainnamen aufl�sen sollte.
Jemand kann das SAP System nicht benutzen, weil der LDAP Server nicht antwortet. Oh, Moment mal. Habe ich nicht 3 Monate lang gek�mpft, um SAP Autentifizierung auf den LDAP Server zu verlegen?
... oder niemand kann sich in die Windows Rechner einloggen. Nur eine Unixkiste funktioniert nicht. Warum sollte NT davon beeinflu�t werden. Ja, der NT domain controller l�uft auf Linux+Samba mit Autentifizierung durch LDAP.

Dasselbe kann nat�rlich mit einem Windows Server passieren. Das wird jedoch nicht viel Geschrei verursachen, weil dieser Server ohnehin oft nicht funktioniert und sich die Leute daran gew�hnt haben. Ich warne Dich, wenn dann eines Tages mal der Linux Server versagt, dann wird das Management sagen "wie konnten wir das einem Linux Server anvertrauen?"

In einer der Firmen, f�r die ich gearbeitet habe, stellte der NFS Server Dateien f�r den Webserver, den Intranetserver, den Datebankserver und einige andere Applicationen zur Verf�gung. Ein Problem mit dem NFS Server w�rde die Firma praktisch zum Stillstand bringen.
Nat�rlich ist es keine gute Wahl NFS f�r all diese Dinge zu benutzen, aber benuzten wir diese Firma einfach mal als Beispiel. Der NFS Server wurde als HA Server mit Sun's Clusterl�sung ausgestattet. Eine extrem teure Sache.

La� uns im folgenden dieses Konzept etwas genauer untersuchen

Was ist HA?

HA (High Availability oder Hochverf�gbarkeit) ist, wie der Name sagt, ein System, das immer verf�gbar ist.
Das kann wichtig sein f�r Dienste, die das Funktionieren der Firma garantieren: Beispiel:

intranet web server
File server
Mail server
DNS service

Diese Dienste k�nnen im Prinzip aus zwei Gr�nden versagen.

Softwarefehler
Hardwarefehler

Um Hardwarefehlverhalten zu verhindern, trifft man normalerweise etliche Vorsichtsma�nahmen schon beim Bestellen der Hardware. Redundante Stromversorgung, Raid 5, etc.
Was oft �bersehen wird, ist Fehlverhalten der Software. Ob Du es glaubst oder nicht, ich habe Linuxrechner wegen einer fehlerhaften Netzwerkkarte versagen sehen.
Der Chef ist normalerwiese nicht daran interessiert zu wissen, ob das System abgest�rzt ist, weil die Stromversorgung versagt hat oder weil die Netzwerkkarte fehlerhaft war.
Was interessiert, ist die Verf�gbarkeit des "Dienstes" , den ein Rechner zur Verf�gung stellt. Nat�rlich l�uft der "Dienst" auf einem Rechner und das Umlenken der Anfragen f�r diesen "Dienst" auf einen intakten Rechner ist die Kunst der Hochverf�gbarkeit.

Ein Beispiel einer HA Implementierung

In diesem Beispiel entwickeln wir ein Rechnercluster, auf dem der Apache Webserver l�uft. F�r diese Cluster benutzen wir eine gute Maschine mit starker CPU und viel Speicher. Eine zweite Maschine hat gerade genug CPU Leistung und Speicher, um den Dienst alleine laufen zu lassen.
Der erste Rechner wird der Hauptrechner sein (master) und der zweite der Ersatzrechner (backup). Die Aufgabe des backup Rechners ist es, dem master den Dienst wegzunehmen, sobald er denkt, da� der Master nicht mehr richtig antwortet.

Wie man das macht

Wie greifen die Benutzer auf den Webserver zu? Sie tippen http://intranet/ in ihren Browser und der DNS Server lenkt das auf die IP Adresse 10.0.0.100 (z.B) um.

Wie w�re es, wenn wir einfach im Falle des Versagens eines Rechners den Eintrag im DNS Server so �ndern, da� er auf einen Rechner mit einer anderen IP Adresse geht?
Sicher, das ist eine M�glichkeit, aber DNS wird auf der Client-Seite in einem Zwischenspeicher gehalten (DNS cache) und was ist, wenn wir DNS mit HA laufen lassen wollen?
Eine bessere M�glichkeit ist, da� der backup die IP Adresse des masters �bernimmt, falls der master versagt. Diese Methode nennt man IP takeover. All Webbrowser werden weiterhin Anfragen an 10.0.0.100 schicken, aber dabei auf den backup zugreifen.

Wie Cluster miteinander reden

Wie wei� der master/backup, da� der jeweils andere versagt hat?
Sie unterhalten sich sowohl �ber die serielle Schnitstelle als auch �ber ein Crossover Ethernetkabel. Man benutzt beides, Ethernetkabel und serielles Kabel aus Redundanzgr�nden. Sie �berpr�fen ihren Herzschlag. Ja, wie beim Menschen. Wenn das Herz nicht mehr schl�gt, ist der Mensch vermutlich tot. Die beiden Rechner schicken sich in regelm��igen Abst�nden kurze Nachrichten zu. Wenn diese Nachrichten ausfallen (Herzschlag), dann ist der Rechner ausgefallen. Das Programm, das man dazu braucht, nennt sich, rate mal ..., heartbeat (Herzschlag).
heartbeat gibt es unter www.linux-ha.org/download/.

Das Programm zur �bernahme der IP Adresse nennt sich fake und ist in heartbeat enthalten.

Vorbereiten der Cluster Knoten

Wie schon gesagt werden wir zwei Rechner verwenden, einen leistungsstarken und einen weniger leistungsstarken. Beide Maschinen haben zwei Netzwerkkarten und jeweils eine serielle Schnittstelle. Wir brauchen auch ein crossover cat 5 RJ45 Ethernetkabel und ein null modem Kabel (cross over serial cable)

Das erste Ethernet Interface (eth0) benutzen wir auf beiden Maschinen zum Anschlu� an das Netzwerk. Das zweite Ethernet Interface (eth1) wird f�r das private Heartbeat Netz benutzt, �ber das wir UDP Pakete schicken.

Hier die Adressen f�r eth0 auf beiden Rechnern:
clustnode1 ip Adresse 10.0.0.1
clustnode2 ip Adresse 10.0.0.2

Nun reservieren wir eine weitere ip Adresse als eigentliche Serviceadresse. Diese ist 10.0.0.100. Im Augenblick brauchen wir diese Adresse noch keiner von beiden Machine zuzuweisen.

Als n�chstes konfigurieren wir die zweite Netzwerkkarte und geben ihnen Adressen aus einem Bereich, der noch frei ist. Z.B:
clustnode1 ip Adresse 192.168.1.1
clustnode2 ip Adresse 192.168.1.2

Jetzt k�nnen wir die seriellen Schnitstellen verbinden und testen, da� der hearbeat funktioniert. (Es ist einfacher, wenn man den gleichen seriellen Port auf beiden Rechnern benutzt.) N�heres unter http://www.linux-ha.org/download/GettingStarted.html

Installation von heartbeat

Die Installation ist ganz einfach. heartbeat ist als rpm und tar.gz File verf�gbar. Wenn Du Probleme mit der Installation hast, dann solltest Du besser nicht die Verantwortung f�r ein HA System �bernehmen (... oder es wird vielleicht ein NA [not available] System). Eine gute Anleitung findet sich unter "Getting Started with Linux-HA" auf der linux-ha.org Seite.

Konfiguration des Clusters

Konfiguration von hearbeat

Die Konfigurationsdateien sind in /etc/ha.d
Editiere /etc/ha.d/authkeys und schreibe folgendes:

#/etc/ha.d/authkeys
auth 1
1 crc
#end /etc/ha.d/authkeys

Man kann sp�ter auf md5 oder sha umstellen. Im Moment ist der Autentifizierungsmechanismus mit 1 gut gew�hlt.

edit /etc/ha.d/ha.cf

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility     local0
deadtime 10
serial  /dev/ttyS3  #change this to appropriate port and remove this comment
udp     eth1      #remove this line if you are not using a second network card.
node    clustnode1
node    clustnode2

editiere die Datei /etc/ha.d/haresources

#masternode ip-address service-name
clustnode1 10.0.0.100 httpd

Das legt fest, da� clustnode1 der master ist. Wenn er ausf�llt �bernimmt backup und wenn er wieder funktioniert, wird er den Dienst wieder erhalten.
Der zweite Eintrag definiert die IP Adresse die �bernommen werden soll und der dritte Eintrag ist der dienst. Wenn clustnode2 �bernimmt, wird versucht, den Befehl

/etc/ha.d/httpd start

auszuf�hren und wenn das versagt, wird

/etc/rc.d/init.d/httpd start

ausgef�hrt.
Dasselbe passiert f�r den stop Befehl, wenn der Dienst wieder zur�ckgegeben wird.

/etc/ha.d/httpd stop

und falls das nicht geht:

/etc/rc.d/init.d/httpd stop

Wenn man fertig mit der Konfiguration von clustnode1 ist, kann man die Dateien nach clustnode2 kopieren.
In dem Verzeichnis /etc/ha.d/rc.d findet sich das Script ip-request. Dieses �bernimmt die Zuweisung der Service IP Adresse.
Nun starte einfach /etc/rc.d/init.d/heartbeat auf beiden Rechnern. Es empfiehlt sich au�derdem zu Testzwecken verschiedene Webseiten auf beiden Servern zu haben. Dadurch kann man die Rechner leicht unterscheiden.
Wenn Du mit der Konfiguration auf clustnode1 fertig bist, kannst Du die Dateien nach node2 kopieren.

Es ist au�erdem sicherzustellen, da� der Service httpd nicht automatisch beim Booten gestartet wird. Dazu enfernt man die Links in den etc/rcN Verzeichnissen oder man Verschiebt die Datei httpd (oder apache. Das ist unterschiedlich je nach Distribution) von /etc/rc.d/init.d/ nach /etc/ha.d/rc.d/. Wenn alles funktioniert hat, dann hat clustnode1 die Adresse 10.0.0.100 und beantwortet http Anfragen.
Zum Test kann man jetzt clustnode1 mit shutdown anhalten und innerhalb von 10 Sekunden sollte clustnode2 �bernehmen.
Der maximale Betriebsausfall wird daher 10 Sekunden betragen.

Wie sieht es mit der Integrit�t von Daten aus?

Wenn der Service httpd von clusternode1 nach clusternode2 geht, dann sieht man dort nicht dieselben Daten. Alle Dateien fehlen und die Daten der CGI-Bins.

Zwei Antworten:
1) Man sollte niemals von CGI's in Dateien schreiben. Stattdessen benutzt man eine Netzwerkdatenbank. MySQL ist sehr gut.
2) Man kann beide Clusternodes an ein zentrales externes SCSI Plattensystem anschlie�en. Hierzu mu� man sicherstellen, da� nur ein Rechner immer mit dem SCSI Speichersystem redet und da� beide Rechner unterschiedliche SCSI IDs haben (z.B 6 und 7)
Bei Adaptec 2940 SCSI Karten kann man zum Beispiel die SCSI ID des Hostadapters �ndern. Billigere Karten lassen das nicht zu.
Einige Raid Controller werden als cluster-aware Controller verkauft. Hier ist vorher zu pr�fen, ob diese sich einstellen lassen, ohne da� man zuerst das Microsoft cluster kit kaufen mu�.
Ich hatte zwei NetRaid Controller von HP und diese unterst�tzen definitiv nicht Linux. Solches Zeug sollte man vermeiden.

Eine weitere M�glichkeit ist Fibrechannel Karten, Fibrechannel hub und Fibrechannel Storage. Diese L�sung ist gut, aber erheblich teurer als zwei SCSI Karten.
Eine sehr gute L�sung ist GFS (Global File System, siehe unten) �ber Fibrechannel. Damit kann man auf die Dateien zugreifen, als ob sie auf localen Platten l�gen.

Wir benutzen GFS in einer Produktionsanlage mit 8 Rechnern, wovon 2 in einer wie oben beschriebenen HA Konfiguration laufen.

Wie sieht es mit active/active Clustern aus

Man kann sehr einfach einen Active/Active Server bauen, wenn man ein gutes Plattenspeichersystem hat. Fibrechannel und GFS sind hier eine gute Wahl.
Wenn du mit NFS vertraut bist, kann man auch das benutzen, aber ich w�rde eher davon abraten.

Jedenfalls kann man serviceA dem clustnode1 zuweisen und serviceB clustnode2. In meine haresource file steht z.B:

clustnode2 172.23.2.13 mysql
clustnode1 172.23.2.14 ldap
clustnode2 172.23.2.15 cyrus

Ich benutze GFS und deshalb gibt es kein Problem mit gleichzeitigem Zugriff auf die Daten.
Hier ist clustnode2 der master f�r mysql + cyrus und clustnode1 der master f�r ldap.
Wenn clustnode2 versagt, �bernimmt clustnode1 alle Dienste.

Resourcen

Linux-HA.org: Die Homepage von Linux HA
kimberlite clustering technology: Ein Kimberlite Cluster unterst�tzt 2 Server mit shared SCSI oder Fibrechannel als Plattenspeichersystem in einer active-active failover Umgebung. Kimberlite ist entwickelt worden f�r h�chste Dateninegrit�t und ist sehr robust. Es ist geeignet f�r HA unter Linux, ohne da� man die Applikationen �ndern mu�.
ultra monkey: Ultra Monkey ist ein Projekt, da� load balanced highly available services in einem LAN entwickelt. Es wird Open Source und Linux verwendet. Im Moment arbeitet man an einer skalierbaren HA Web-Farm. Die Technologie kann problemlos auf E-mail und andere Sachen wie z.B FTP �bertragen werden.
Linux Virtual Server: Der Linux Virtual Server ist ein hochverf�gbarer skalierbarer Server, gebaut aus einem Cluster von realen Servern. Mit einem load balancer auf Linuxbasis. Die Architektur des Clusters ist f�r den Benutzer v�llig transparent. Der Endbenutzer sieht nur einen einzigen Server.
4U cluster / 4U SAN: 4U cluster und 4U SAN ist ein HA cluster und eine SAN Implementation von unserer Firma, 4Unet.
Wenn du ein ISP, ein Netzbetreiber, eine Telekomunikationsfirma oder einfach eine Firma bist, die High Availability braucht, dann ist 4Unet der richtige Ort f�r Fragen.
Beachte: 4Unet setzt L�sungen um. Wir verkaufen keine Cluster oder SANs, wir implementieren sie f�r unsere Kunden. All Technologien, die von uns verwendet werden, sind Open Source.
Global File System: Das Global File System (GFS) ist ein shared disk cluster filesystem f�r Linux. GFS unterst�tzt journaling und recovery von fehlerhafen clients. GFS cluster teilen sich physikalisch ein Plattenspeichersystem unter Verwendung von Fibre Channel oder shared SCSI. Das Filesystem erscheint auf jedem Knoten wie ein lokales Filesystem und GFS synchronisiert den Dateizugriff im ganzen cluster. GFS ist voll symmetrisch. Alle Knoten sind gleich. Es gibt keinen einzelnen Server oder irgendeinen Flaschenhals. GFS hat Lese/Schreib-caches und volle UNIXfilesystem Semanik.