Re: Cluster wie Raid mit verteilten CPU-Ressourcen

Hallo Nils,

On Sun, 22 Jun 2003, Nils Beyer wrote:

> Ich möchte zwei Rechner so zusammenbasteln, dass sie sich
> versch. Dienste rechnerisch teilen. Die beiden Rechner
> sollen für ca. 20 Laptops die Internet-Versorgung über
> ISDN, Sat und DSL ermöglichen, ferner DHCP spielen und
> ein ftp- und http-Server darstellen. Für die Außenwelt
> sollen die beiden Rechner als Einer aussehen. Fällt
> ein Rechner aus, soll man davon nichts merken, bis der
> defekte Rechner wieder instandgesetzt und eingebaut
> wurde.

Du hattest vorher unter anderem samba und nfs erwaehnt. Wo werden die hier
benoetigt?

Mein Vorschlag: Du verteilst die Dienste so auf die beiden Rechner, dass
sie moeglichst "gleichverteilt" sind, d.h. beide Rechner ausgelastet sind.

Wenn sich z.B. herausstellt, dass Dein HTTP-Daemon der Rsourcenfresser
schlechthin ist, packe ihn auf einen der Rechner und lasse den anderen
alles andere machen.

Komfiguriere die Rechner so, dass beide prinzipiell allws machen koennen
und schreibe zwei Startskripts fuer "Servicegruppe 1" und "Servicegruppe
2".

Jeder Rechner startet im Defaultfall eines der Skripte und im Ausfall des
anderen das zweite hinterher.

Schreibe fuer jeden Service ein "Mirrorskript", welches die Daten des
jeweils aktiven Services auf den andren uebertraegt, nutze differentielle
Uebertragungen, wie es z.B. rsync bietet (d.h. statt aller Daten werden
nur die uebertragen, die sich seit dem letzten Mal geaendert haben).

Zur Erinnerung: Vergiss das Backup trotzdem nicht. Das ist dieses Feature,
was es einem ermoeglicht, eine Datei, die unbemerkt vor vier Wochen
"verschwunden" ist, wieder aus dem Hut (Bandgeraet, CD-Leser etc.) zu
zaubern.

Das kann eigentlich erst einmal in den seltensten Faellen verkehrt sein;)

Vermeide, wenn moeglich, gleichzeitig gestartete Services, die auf gleiche
Datenbestaende schreibend zugreifen. Dass naehmlich musst Du die Daten
sharen, NFS oder aehnliches einsetzen, und das erzeugt zusaetzliche Last.

In solchen Faellen doch nochmal ueber einen zusaetzlichen File- oder auch
DB-Server nachdenken..

Sind die beiden Rechner das Gateway zur Aussenwelt und die Laptops drinnen
oder sind die Laptops die der "Road-Warrior" irgendwo draussen? Sind es
die Einwahl- oder Auswahlrechner? Sieht die Aussenwelt statische
IP-Adressen?

Steht irgendwo "davor" noch ein Router, evt. mit Firewallfaehigkeiten?

Davon wuerde ich einiges abhaengig machen, was evt. helfen koennte, den
Uebergang etwas nahtloser zu gestalten.

Fuer simples Failover auf IP-Ebene im LAN bietet sich z.B. VRRP an.
Besonders gut einsetzbar fuer Services, die Daten im wesentlichen lesen
und nicht veraendern (s.unten)

Das gilt auch fuer "Loadbalancing". Man kann z.B. mit einem Firewall
TCP-Sessions verteilen und so zwei Server fuer einen Service
beschaeftigen.

Sonst hilft auch Round-Robin-DNS (Angabe zweier IP-Adressen fuer einen
Namen)

Keep it simple. Die Anzahl eingesetzter Tools und Feauture ist der Zahl
der moeglichen Problemfaelle proportional. Die Komplexitaet nimmt aber
nicht linear zu. Dieses ist ein oft uebersehener Fakt. Ein wenig
Komplexitaetstheorie wuerde uebrigens so mancher I-T.-Kraft gut zu Gesicht
stehen (musst Du jetzt nicht persoenlich nehmen;-), im I.T.- Bereich geht
extrem viel schief, weil "Blaue-Himmel-Phantasien" eben keinen Sturm
vorhersehen und einplanen. Und wenn, dann nur aus Westen und bei Ostwind
faellt dann alles zusammen.

Wenn Du zwei Rechner aufgesetzt hast, koennen die oft Monate und Jahre
laufen, manchmal hat man im Ausfallfall am ehesten die Schwierigkeit, sich
zu erinnern, wo er doch stand (Beschriftung nicht vergessen!)

Und mir scheint es so, dass der Ausfall, hervorgerufen dadurch, dass
jemand erst einmal das Startskript fuer den Notfall aufrufen muss, haeufig
vertetbar ist.

Dann kann man die Services transparent via DNS umschalten. Klar, DNS cacht
und es dauert so etwas. Aber wenn es einmal in zwei Jahren vorkommt und
man dem, der eilig draufzugreifen muss, schnell auf Anfrage die IP-Adresse
gibt?

Haeufiger gibt es ein nicht sauber geschriebenes Ueberwachungsskript,
welches das Skript automatisch startet, und zwar vielleicht nur deshalb,
weil der Apache gerade mal ein bisschen beschaeftigter ist, und einen
Timeout hat. (s. Ollis Mail)

Monitore gibt es - nagios und mon z.B. und bei beiden habe ich schon
falschen Alarm erlebt, weil z.B. der Monitor selbst und nicht dder Service
Probleme hat. Ich benutze soetwas gern zum Ueberwchen, aber nur ungern
fuer automatisches Failover.

Die Monitore sind modular aufgebaut, es kmmen einige Standardmodule mit,
die z.B. pingen, einen Port ueberwachen, Webserver abfragen etc. Da kannst
Du gern nachlesen, was die so treiben, es ist keine Magie.

Und mon z.B. ist in Perl geschrieben, und unter Belastung hast Du da z.B.
schon mal einen Timeout, weil das Starten von Perl zu schwerfaellig ist.
Dann denkt der beschaeftigte Rechner, der den Monitor nicht mehr sauber
faehrt, der andere ist nicht mehr da und startet also noch weitere
Services:-(

Und ein troepfelndes DNS ist auch immer wieder zu ueberraschenden
Nebeneffekten faehig..

Neben dem Ueberwachungsskript ist es auch noch noetig, die beiden nun
gleichzeitig geschriebenen Datenbestaende zu synchronisieren. Und das ist
nicht wirklich simpel.

Besonders schoen, wenn der Service "flackert", (ueberlastet, Server 2
uebernimmt, wieder da, zurueckschalten, Server 1 wieder ueberlastet und
antwortet nicht, Server2 uebernimmt..:-(

Und: sicher, man kann vieles lernen und es macht auch Spass. Aber wenn man
sich zuviel auf einmal vornimmt, bricht einem das Ganze moeglicherweise
durch Nichtbedachtes ein und man weiss nicht mehr, wo mit der Aufloesung
des Knotens anfangen.

Ach ja, denk dran, es auch fuer andere bedienbar zu machen. Es mag Deine
Unabkoemmlichkeit in der Firma unterstreichen, wenn nur Du es kannst,
erhoeht aber ganz sicher auch den Stress.

Dokumentation tut not!

Es gibt meines Wissens derzeit unter FreeBSD nichts
OpenMosix-Vergleichbares. Unter Linux sorgt es dafuer, dass Prozesse nach
Konfiguration und Anforderung nahtlos von einer Kiste auf die andere im
Cluster migrieren koennen.

Meintest Du die AS/400 mit Deiner grossen Kiste? Die kann wirklich
Einiges, ist aber nicht unbedingt fuer einen Appel und 'n Ei zu haben.

Es gruesst
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 23 Jun 2003 - 04:46:33 CEST