|
|
Dieses Dokument ist verfübar auf: English Castellano Deutsch Francais Nederlands Turkce |
von Atif Ghaffar <atif(at)developer.ch> Über den Autor: 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.
Übersetzt ins Deutsche von: Guido Socher <guido(at)linuxfocus.org> Inhalt:
|
Zusammenfassung:
Während der Entwicklung eines für sein Unternehmen extrem wichtigen Systems wird man sich follgende Fragen stellen:
Nun zu einer ernsthafen Diskussion
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:
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:
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 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 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.
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
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 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
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
#masternode ip-address service-name clustnode1 10.0.0.100 httpdDas legt fest, daß clustnode1 der master ist. Wenn er ausfällt übernimmt backup und wenn er wieder funktioniert, wird er den Dienst wieder erhalten.
/etc/ha.d/httpd startauszuführen und wenn das versagt, wird
/etc/rc.d/init.d/httpd startausgeführt.
/etc/ha.d/httpd stopund falls das nicht geht:
/etc/rc.d/init.d/httpd stopWenn man fertig mit der Konfiguration von clustnode1 ist, kann man die Dateien nach clustnode2 kopieren.
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.
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 cyrusIch benutze GFS und deshalb gibt es kein Problem mit gleichzeitigem Zugriff auf die Daten.
|
Der LinuxFocus Redaktion schreiben
© Atif Ghaffar, FDL LinuxFocus.org Einen Fehler melden oder einen Kommentar an LinuxFocus schicken |
Autoren und Übersetzer:
|
2002-02-24, generated by lfparser version 2.25