nicht angemeldet
Hi!
Schade eigentlich, wir hatten hier alle gehofft, das Du zumindest planst, einen Scheck auszustellen ;-)
OK, ich steuere die Netzwerkkabel bei ;-)
(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.)
Du hast selbst gesagt dass ein Cluster für die interne Kommunikation ein eigenes Netz verwenden sollte, also hör mir mit sowas auf ;-)
Zum Thema rsync siehe oben ansonsten und bis hierhin: ja, sieht gut aus.
Wieso ist rsync unsicher? Mit SSH und entsprechenden keys? Und wenn es noch in einem eigenen Netz ist, ist doch kein großes Problem, und ein 100Mbit Netzwerk für 10 Rechner kostet ja nicht die Welt. rsync würde ja sowieso nur innerhalb dieses kleinen LANs funktionieren, Anfragen von außen werden ja nicht weitergeroutet.
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
naja, ich dachte eher an 8 oder 10 Rechner, wovon dann auch mehr als 1 Backend-Serverdienste übernehmen können.
Diese Art der Verteilung hätte ich aber gerne begründet.
OK. Aber dafür bin ich eigentlich nicht der richtige, dafür kenne ich mich mit der Lastverteilung der einzelnen Anwendungen hier nicht genug aus, aber ich will es mal nach bestem Wissen und Gewissen probieren: Was haben wir hier für Prozesse die Last erzeugen? Einen großen Teil der Last erzeigen die httpd Protzesse, siehe:
<iframe src="http://selfaktuell.teamone.de/sonst/mrtg/ps0.html" width="90%" height="90%">http://aktuell.de.selfhtml.org/sonst/mrtg/ps0.html</iframe>
der größte Teil davon sind Prozesse für reines HTML, also selfhtml, selfaktuell... Bei solchen Prozessen brauche ich keinen Backend-Server. Bedenke dass ich NFS nur verwenden will, wenn Apache-Prozesse(PHP) oder CGI-Scripte Dateien beschrieben wollen - wie oft passiert das hier? So gut wie nie. Im Moment wüsste ich nicht eine Stelle wo das passiert. Die fo_post Prozesse des Forums schreiben nicht auf eine Festplatte, sondern komunizieren mit dem fo_server über ein Socket. Mein Gedanke war es, alle Daten die sich nicht ständig ändern, auf die Worker-Nodes zu verteilen, so dass die Lokal auf der Platte liegen und so recht schnell beantwortet werden können. Und das kann man sogar noch weiter spinnen. Ich bin nicht so sicher wie das in Zukunft laufen soll, aber ich vermute dass es dabei bleibt dass Forums-Threads nur Nachts archiviert werden, und nicht in Echtzeit. Wenn man es auf die Spitze treiben wollte, könnte man dann auf jeder Worker-Node die Suche lokal betreiben, das heißt nach dem Archivieren werden die neuen Archivdaten auf die Nodes verteilt(das muss sowieso geschehen wegen den Fallback-Mechanismen), und die Worker-Nodes verwenden bei der Suche dann die lokale Datenbank! Nur ist ja gerade der Sinn einer Datenbank diese zentral zu halten, naja, nur so ein Gedanke ;-) Im übrigen gilt dasselbe für den Archiv-viewer, der könnte auch aotonom auf den einzelnen Nodes laufen, da die Daten ja nur einmal pro Nacht geändert werden. Aber ich glaube der soll über den Forumsserver laufen, naja, so ganz blicke ich noch nicht durch den Source des Forums durch ;-) Du hast geschrieben dass der Load-Balancer ein Bottelneck ist. Meinst Du wirklich? Ja, theoretisch sieht das so aus, aber praktisch, gucke Dir mal die Netzwerkauslastung an:
<iframe src="http://selfaktuell.teamone.de/sonst/mrtg/snmp0.html" width="90%" height="90%">http://aktuell.de.selfhtml.org/sonst/mrtg/snmp0.html</iframe>
Sooo viel ist das nicht, da kann ein so ein Rechner noch deutlich mehr vertragen. Und ja, der arbeitet auf HTTP Ebene und das kann da ganz anders aussehen, aber gucken wir uns auch das an: vom Webalizer nur mal die stark frequentierten Subdomains(August, Quelle:http://webalizer.teamone.de/):
Anfragen pro Stunde schnitt maximal selfhtml 15.280 45.133 selfforum 5.681 35.492 selfaktuell 4.200 12.698 Summe ca. 100.000 Request pro Stunde
Das sind ca. 30 Requests pro Sekunde. OK, das sagt jetzt noch wenig über Lastspitzen aus, aber bedenke dass es sich hierbei schon um am stärksten frequentiierte Stunde im ganzen Monat handelt, und das individuell für jede Subdomain, das muss also nicht zur gleichen Zeit gewesen sein. Aber gut, sagen wir es kommen mal 100 Requests pro Sekunde, und vielleicht kommt da in Zukunft ja noch was dazu vielleicht sind es dann mal ab und an 200 pro Sekunde. Naja, aber das ist doch keine Zahl die einen rein als Proxy arbeitenden Apachen schrecken kann kann, oder? Bedenke dass der Apache überhaupt rein gar nichts mit der Bearbeitung der Requests zu tun hat(keine Plattenzugriffe, kein CGI...), gut, das Verteilen der Request kostet auch Leistung, aber dafür macht mod_backhand das IMO durchaus sehr intelligent:
Was ich jetzt nicht bedacht habe, ist das wir hier ja meines Wissens einen Squit einsetzen, naja, mit dem kenne ich mich nicht aus und ich weiß im Augenblick nicht wie man den da einbauen könnte, aber ich glaube der kann auch sowas in Richtung Load-Balancing, bin aber nicht sicher. Oder vielleicht eher anders herum, man behält Apache mit mod_backhand als Load-Balancer, und verwendet einen Squit-Cache auf jeder Working-Node, naja.
Immerhin ist das System recht komplex. Auch fehlt an einigen Stellen Redundanz.
wo? Für jede Maschine die keine Worker-Node ist muss es ein Script geben, welches aus einer Worker-Node einen eben solchen Server macht. Halt indem Konfigurationen geändert werden, Dienste beendet bzw. gestartet, crontab geändert usw.
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.
Die "Datenhaltungsnode" hält nur ganz, ganz weniger Daten. Eben die die öfter als einmal in der Nacht verändert werden. Und diese Daten brauchen die Clients zum größten Teil nicht für Ihren Betrieb, sondern erst wenn Sie selbst zur Datenhaltungsnode werden sollen. Deshalb werden die Daten regelmäßig verteilt. Wenn jetzt die Datebhaltungsnode ausfällt, dann würde alles einfach weiterlaufen, da die worker-nodes die meisten Daten lokal haben(HTML...). ein Beispiel für schreibende Daten wäre z.B. eine PHP-Session, die die Session-Daten in einer Datei speichert, oder eben solche Dinge, aber wird sowas hier bisher kaum eingesetzt, ich habe es nur erwähnt da es in Zukunft vielleicht mal verwendet werden könnte. Und selbst dann hat die Worker-Node ja höchstens 5 Minuten alte Session-Daten(kann man ja auch öfter synchronisieren, oder direkt beim schreiben). Andere wichtige zentrale Daten sind ja die aktuellen Threads aus dem Forum. Aber wenn der Rechner mit dem Forumsserver abschmiert, dann geht soweiso was verloren da nur periodisch Daten aus dem Ram auf die Platte geschrieben werden. Und das müsste man dann halt bei jedem Schreibvorgang direkt im Cluster verteilen. Wenn die Maschine Forumsserver kaputt geht, hat das bei meiner Lösung im Prinzip nach außen hin denselben Effekt als würde der fo_server Prozess einfach abstürzen und ein paar Sekunden später automatisch neu gestartet werden.
Es werden ständig (also alle paar Minuten) die Daten auf allen Rechnern synchronisiert, also von Node 5 aus per rsync verteilt, 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.
Was denn? Wie gesagt, Postings stehen auch erstmal nur im Ram!
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.
Wo ist das Problem? Wenn ich wissen will ob ein Webserver noch läuft, schicke ich dem z.B: einen HEAD-Request auf den der mir dann einen 304-Response schicken sollte, das kostet am wenigsten Performance, und sagt mir recht klar ob der noch läuft, und wie lange der Request dauert. vergleichbares geht sowohl mit PostgreSQL als auch dem Forumsserver. Also wo ist das Problem? Am besten man schreibt ein kleines C-Progamm welches das macht.
[...]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 ;-)
Das verstehe ich nicht. Wenn ich ein Port-Forewarding einrichte, dann muss ich die Requests auf eine bestimmte IP weiterleiten, genauso wenn ich auf einen Datenbank-Server zugreife muss ich in allen Anwendungen eine feste IP verwenden. Wenn der jetzt ausfällt muss jemand anderes diese IP annehmen, oder ich muss die IPs in allen Anwendungen ändern.
Nun hats Du aber das Problem, das zwei Kisten mächtig viel Arbeit leisten. Einmal den HTTP-Server, der alle Anfragen bearbeitet
Was den aber doch nicht vor größere Probleme stellen sollte, oder? Also ich habe einige benchmarks mit mod_backhand angesehen, z.B. war da einer der hat mit einem PIII 700 mit 128MB RAM 500 Requests pro Sekunde geschafft. Ich weiß jetzt nicht genau, aber es gibt glaube ich sogar noch die Möglichkeit die Anfragen vorbei am Proxy zurückzuschicken, naja. Außerdem schafft das der aktuelle Server ja auch, obwohl darauf alles andere noch nebenher läuft!
und einmal die Datenhaltung, die alle Datenhaltung unter sich hat.
Nein, das iust nur ein ganz, ganz kleiner Teil der Daten der global gehalten werden muss, s.o.
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.
Ich meinte weniger "viel kräftiger", sondern eher "viel zuverlässiger", also hier nicht gerade den allerbilligsten Ramsch nehmen. Von der Leistung her kann das eine 2Ghz Pizzabox mit Sicherheit, sogar recht entspannt, naja, im Prinzip muss es nichtmal ein anderer Rechner sein, ich dachte nur weil das dann Ausfälle wären, die etwas unangenemer sind. Auf der anderen Seite dürfte der Job in wenigen Sekunden umgestellt sein. Beim Load-Balancer hieße dass dann halt ein paar Sekunden nicht erreichbar, beim Dateiserver könnten wenige Daten verloren gehen, wobei es bisher noch keine Anwendung gibt wo wirklich solche wichtigen Daten verloren gehen könnten. Beim Forumsserver heißt das, dass die Daten noch ein paar Sekunden(wenn überhaupt im Sekundenbereich, so viele Daten sind das nicht) länger nicht gesichert sind, also so lange bis sie verteilt sind. Das Datenverlustrisiko würde sich also nur marginal erhöhen. Vielleicht kann man den Forumsserver ja auch auf 2 Maschinen parallel beteiben, wenn das geht, dann müssten schon beide Machinen ausfallen.
KISS, "Keep it simple, stupid!" Wenn ich diesen Grundsatz beherzige, habe ich folgende Konstellation:
WWW | Router | | | Nodes 1,2,3
Die Sache ist nur die, was kostet so ein Router der so Mechanismen kennt die Anfragen zu verteilen? Ich finde da nur richtig teure Teile, die mehr kosten also die 10 Pizzaboxen zusammen. Sicher wäre das besser, weil man den potentiell problematischen billig-Loadbalancer loswird. Nur hat die Verwendung von festen Servern den Vorteil, dass die heute verwendete Software im Prinzip weiterverwendet werden kann. Das ginge bei keiner Lösung vergleichbar zu mosix.
Grüße Andreas