nicht angemeldet
Hi,
Bevor ich das jetzt schreibe will ich nur eben klarstellen, dass ich hier nichts plane, sondern Überlegungen anstelle, nicht das das missverstanden wird ;-)
Schade eigentlich, wir hatten hier alle gehofft, das Du zumindest planst, einen Scheck auszustellen ;-)
Nachdem ich mir jetzt wirklich so einiges zu Clustern durchgelesen habe, bin ich jetzt der Meinung das es mit mosix keinen Sinn macht aus den bekannten Gründeen,
War ja auch nur für Dich als Beispiel zum Lesen und Verstehen, wie sowas funktioniert. Das es für die Zwecke des Selfservers das falsche Werkzeug ist, hatte ich allerdings gleich am Anfang erwähnt, wenn ich micht ganz irre (zu faul, nachzublättern ;-).
und eine gute Alternative die genau das kann was wir brauchen habe ich nicht gefunden. Also habe ich mir was anderes überlegt, und zwar dass man nicht so tief in Kernel und Programmcode eingreifen muss, sondern einfach bekannte Techniken wie Loadbalancing, rsync, NFS... verwendet. Hier meine Gedanken dazu:
(rsync (alle rtools) und NFS sind sicherheitstechnisch bedenklich, das müßte dann wirklich über physikalisch getrennte Netze laufen, wäre also teurer und aufwendiger und weil aufwendiger auch nochmal sicherheitstechnisch bedenklich, also doppelt. Nicht so schön.)
Aufbau des Netzwerkes:
[www<->NAT<->viele gleiche Boxen]
Logischer Aufbau:
Internet-WWW
|
|
Load-Balancer: Apache + mod_backhand
|
|
Mehrere Worker-Nodes: Apache, fo_view, fo_post...
|
|
Backend-Server: fo_server, PostgreSQL, NFS
Auf allen Rechnern ist dasselbe installiert, und mit rsync wird dafür gesorgt dass alle denselben Datenbestand haben. Ziel ist es das jeder Rechner jeden "Job" machen kann, also bei Problemen für einen anderen einspringen kann.
Zum Thema rsync sihe oben ansonsten und bis hierhin: ja, sieht gut aus.
Hierfür sind 2 spezielle Shell-Scripte zu entwickeln, die auf allen Rechern liegen. Das erste um aus der Worker-Node den Backend-Server zu machen, und das 2. um zum Load-Balancer zu werden.
Jetzt wird's durcheinan...achso, ja.
Ich gehe mal von 5 Rechnern aus. Alle 5 Rechner bilden ein eigenes, privates LAN, die HTTP-Anfragen gehen ein NAT-Gateway, wobei, das ist glaube ich der falsche Ausdruck,
Nimm "Router", "Router" ist schön allgemein, das paßt in solchen Fällen immer ;-)
zumindest sorgt dieses Gerät für Port-Forewarding, so dass Requests an 213.139.94.131:80 an Node 1 weitergeleitet werden. Auf diesem Rechner läuft Apache mit mod_backhand, womit die Anfragen an die Worker-Nodes übergeben werden(recht intelligenter, transparenter Proxy ;-)), und er kann auch selber Requests beantworten, die Verteilung erfolgt automatisch. Die Worker-Nodes bekommen dann also die HTTP-Requests und arbeiten die ab, dort laufen dann auch die Forums-Clients, die mit dem Forumsserver auf Node 5 per Socket kommunizieren. Selbiges gilt für Datenbankverbindungen.
Im Prinzip wird ja nur auf Node 5 was auf die Festplatte geschrieben. Auf den Worker-Nodes wird ein Netzwerklaufwerk von Node 5 gemountet. Hier werden alle Dateien gespeichert, die evtl, von irgendwelchen PHP/PERL... Scripten beschrieben werden.
Du verteilst die Last also wie folgt:
1 Teil für die Kommunikation mit den HTTP-Clients
3 Teile für die Bearbeitung der Anfragen
1 Teil für Datenhaltung
Diese Art der Verteilung hätte ich aber gerne begründet. Immerhin ist das System recht komplex. Auch fehlt an einigen Stellen Redundanz. Das kann durchaus sinnvoll sein, kann ich aber im Augenblick nicht so ganz nachvollziehen. Insbesondere, wenn der Datenhaltungsnode ausfällt, müßte die ganze Maschien stoppen, da der Node, der die Funktion des Datenhaltungsnodes übernimmt, auch alle Daten spiegeln müßte. Das dauert nicht nur, es besteht auch die Gefahr, das die Kiste einen Totalausfall hat und keine Daten mehr weitergeben kann.
Es werden ständig (also alle paar Minuten) die Daten auf allen Rechnern synchronisiert, also von Node 5 aus per rsync verteilt,
Ah so macht er's also.
Das würde einerseits den evt Datenverlust auf dei Zeit zwischen den Synchronisationen reduzieren, andererseits wäre die Menge der Daten etwas höher, als wenn jedesmal "weltweit" geschrieben würde. Die etwas höhere Menge führt evt zu einem regelmäßigem "Schluckauf" des Clusters. Aber das sollte akzeptabel sein. Ob der Datenverlust akzeptabel ist, ist natürlich eine andere Frage, in 5 Minuten kann sich je nach Tageszeit schon allerhand ansammeln.
wobei nur die Änderungen komprimiert auf alle anderen Nodes übertragen werden.
Nur Änderungen zu übertragen erfordert übrigens auch einen Kontrollmechanismus, aber das nur am Rande (Wenn ständig synchron gespeichert wird, muß das natürlich auch passieren, aber es ist nicht ganz so aufwendig und es kann auch nicht ganz soviel passieren)
Da mehr als zwei Nodes beteiligt sind, kann das z.B. über regelmäßige Abstimmung über die MD5-Summen der Forumshauptdatei erfolgen (byzantinisches Protokoll)
Die Worker-Nodes überprüfen im Gegenzug den Status der beiden anderen Rechner - mit welcher Technik auch immer,
Ich befürchte, genau hier hängt der Hammer, das ist das größte Problem. Es gibt aber zumindest Heartbeat Lösungen, also zumindest die Frage ob das Dingen überhaupt noch am Leben ist, kann halbwegs sicher beantwortet werden.
[...]Hierzu müsste dann die IP in allen die DB verwendenden Programmen verändert werden, und diese Änderung per rsync verteilt werden.
Wenn Du die hardcodierten Pfade durch dynamische ersetztest, hättest Du dieses Problem nicht ;-)
Wenn man dann z.B. 8 von den genannten Pizza-Boxen als Worker-Nodes einsetzt, dazu eine etwas hochwertigere Maschine als Loadbalancer und den aktuellen Server als Backend-Server(ich finde es schon sinnvoll wenn dieser ein DUAL-System ist und ein SCSI-RAID verwendet weil hier alle drauf zugreifen), dann hat man IMHO ein durchaus leistungsfähiges System mit einer sehr hohen Verfügbarkeit, welches noch recht günstig ist, viel mehr als ein einziges leistungsfähiges DUAL-XEON System wird das nicht kosten. OK, wenn man sagt man würde auch etwas mehr ausgeben für 2 XEON Systeme, oder noch ne Ecke mehr für einen "richtigen" Server, dann bekommt man für das Geld dann 20 und mehr "Pizzaboxen" die parallel arbeiten.
Nun hats Du aber das Problem, das zwei Kisten mächtig viel Arbeit leisten. Einmal den HTTP-Server, der _alle_ Anfragen bearbeitet udn einmal die Datenhaltung, die _alle_ Datenhaltung unter sich hat. Fällt einer der beiden aus, müßte nach Denem Prinzip eine der Pizzaboxen diesen Part übernehmen. Hier oben sagts Du aber, das die beiden Maschinen deutlich kräftiger sein müssen. Da sehe ich einen gewissen Wiederspruch.
Der Load-Balancer, der ja im Prinzip als Proxy arbeitet, schafft erheblich mehr Requests pro Sekunde als zur Zeit auf dem Server anfallen, da ist noch sehr viel Luft, stellt also in absehbarer Zeit keinen Flachenhals dar. Man könnte noch ein 2. Netzwerk aufbauen, also eines für HTTP, und eines für den Rest, damit die HTTP-Kommunikation nicht unter einer evtl. etwas größeren "rsync-Orgie" leidet.
Dur brauchst eh ein zweites Netzwerk, schon aus Sicherheitsgründen. Bis auf den nötigen Switch läge das aber preislich im Rahmen. Der Transport würde auchnicht viel Rechnezeit beanspruchen, wäre also auch akzeptabel.
Wobei das ja egal ist wenn der Cluster in der Lage wäre die Worker-Threads der Serversoftware auf anderen Nodes zu verteilen, oder?
Das wäre z.B. eine Möglichkeit.nur kann mosix das halt nicht.
Dann ist das das falsche Werkzeug. Der Nächste bitte! ;-)
Und ich kann mir nicht vorstellen das "distributet shared memory" besonders effektiv ist, gerade der Performance wegen liegen die Daten ja im RAM, und wenn dann andauernd bei RAM-Zugriffen Daten über das Netzwerk austgetauscht werden kann das doch nicht wirklich performant sein, oder?
Nein, _besonders_ effektiv ist das nicht, aber vielleicht ist das _ausreichend_ effektiv? Das würde eine ziemliche statistische Rechnung ergeben, da weiß man vorher wirklich nicht, was am Ende tatsächlich rauskommt.
Angenommen letzteres ist der Fall, wenn man davon ausgeht dass ein Forum immer aus nur einem Serverprozess besteht, wie soll es dann funktionieren auf allen Nodes je einen solchen Server-Prozess zu haben?
Indem man einfach einen startet?
Und wie synchronisierst Du die Daten in den verschiedenen RAMs?
Ach, immer diese Detailbesessenen ;-)
Geht nicht gibt's nicht, aber "ist nicht sinnvoll" dagegen zu Hauf.
Es gibt einige beherzigenswerte Regeln im Geschäft, die wichtigste ist wohl KISS, "Keep it simple, stupid!". Wenn Du zwei Möglichkeiten hast, wobei eine einfach und schön, aber etwas langsam ist, die andere hingegen hochkomplex, dafür aber richtig flott: nimm die einfache und rüste den Rechner auf, ist billiger und schont die Nerven. Ausnahmen bestätigen auch hierbei nur die Regel.
Wenn ich diesen Grundsatz beherzige, habe ich folgende Konstellation:
WWW
|
Router
| | | ...
Nodes 1,2,3 ...
Der Router hat ein wenig Intelligenz eingebaut, die Nodes bilden mit eigenem Netzwerk eine Art Cluster.
Der Router übernimmt die Anfragen aus dem Netz und wirft damit um sich (Reihum, Round-Robin, was weiß ich, egal). Für jede Anfrage, die er an einen Node abgegeben hat, zählt er einen Zähler hoch. Dieser Zähler ist fest mit dem jeweiligem Node verknüpft. Für jede Antwort dekrementiert er diesen Zähler wieder. Erreicht der Zähler einen bestimmten Wert (T&E) ist dieser Node als ausgelastet zu betrachten. Übernimmte dieser Node auch nach einer bestimmten Zeit (T&E) keine Anfrage mehr, ist er als kaputt zu betrachten und fürderhin zu ignorieren. (Meldung an Sysadmin nicht zu vergessen! ;-). Außerdem ist der Maximalwert zu erhöhen. Wenn keiner der Nodes an den Router mehr etwas absetzen kann ist der Router als tot zu btrachten (Clustersoftware). Einen Ruf an den Sysadmin kann dabei wahrscheinlich nicht abgesetzt werden, allerdings ist so ein Ausfall auch von Außen festzustellen, die Masse an Beschwerden sollten also als Weckruf genügen ;-)
Das ist natürlich _sehr_ simpel und düfte in praxi wahrscheinlich nicht genügen, aber der Platz für ein Posting ist ja auch begrenzt ;-)
(Aus diesem Grunde habe ich auch erstmal das Problem der Datensynchronisation ausgeklammert, das würde für ein eigenes Posting reichen, das läßt sich leider nicht derart simplifizieren)
Aber so hast Du eine hohe Verfügbarkeit (solange der Router und mindestens ein Node noch laufen gibt es auch Antworten, die allerdings aber auch über Timeoutwert liegen könnten. Zumindest die Datenkonsistenz ist damit aber gesichert.) und hohe Rechenleistung.
Es werden in dieser Konstellation natürlich nirgendwo Maximalwerte erreicht, aber alle Werte würde ich blind als "ausreichend" bezeichnen.
so short
Christoph Zurnieden