nicht angemeldet
Hi,
Hm, nchmal ein kleinens Verständnisproblem:
Angenommen man könnte den Apachen tatsächlich verteilen, dann gibt es aber imer noch nur einen Prozes im gesamten Cluster, der die Anfragen verteilt, oder? Also es gibt ja immer den eien Steuerprozess der sich um eingehende Anfragen kümmert, und diese dann auf die anderen Rechner verteilt. Dieser Prozess liegt dann ja immer auf einer Node, also muss jeder HTTP-Request auch an diese Adresse, oder?
Also mal von Anfang an (Der Übersichtlichkeit wegen immer nur zwei Pfade, es kann aber durchaus mehr geben):
Der Forumsbesucher will die Hauptdatei laden und schickt einen HTTP GET an "forum.de.selfhtml.org/". Die Anfrage kommt nun an den Eingang von 213.139.94.131 (kleiner Hint am Rande: das ist server.teamone.de ;-). Dieser Eingang ist entweder die Maschine/der Cluster selber, oder ein Router. Wenn es die Maschine/der Cluster selber ist, ist da entweder Schluß, oder das ist die Maschine/der Cluster, die/der die Last verteilt. Ähnlich beim Router. Entweder ist da nur eine Firewall drin und fertig, oder die Logik zur Last- bzw. Applikationsverteilung.
Wenn letzteres sind da genügend Ausgänge(Ausgang muß nicht unbedingt gleich Netzkarte sein) vorhanden, um jeden einzelnen Rechner aus dem Cluster einzeln zu bedenken. Auf diesen Einzelrechnern ist dann jedesmal das Gleiche drauf. Synchronisation der Daten erledigt entweder die Clustersoftware oder die Datenhaltung ist extern und intelligent (sprich: eine normale transaktionssichere Datenbank).
Das größte Problem ist aber bei aller Verteilung die Bestimmung der Last.
Ein Programm könnte man noch beobachten, selbst wenn es RAM, I/O oder Rechenzeit überbeansprucht und auch noch alles auf einmal. Bei mehreren Dingern wird's sehr schnell sehr heftig, da ist man evt mehr mit Lastbestimmung beschäftigt, als mit allem anderem. Aber zumindest geht es; wenn auch nur recht grob, wenn es praktikabel sein soll.
Selbst wenn man das täte wäre es immer noch möglich, die Klammotten auf mehrere Schultern zu laden.
Was ist denn mit dem Server-Prozess, da kann es ja nur einen geben, oder?
Warum? Ist doch kein Windows! ;-)
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.
Theoretisch ja. Aber warum sollten sie? Die Last wird vorher schon verteilt, alle Rechner haben die gleichen Datensätze, warum also Kommunikation?
Das heißt theoretisch sollte auf jeder Node ein Server-Prozess gestartet werden? Dazu muss die Server-Software aber mit mehrere Prozessen umgehen können, abgesehen davon dass die Cliuster Software in der Lage sein muss für "distrubutet shared memory" zu sorgen.
Es läßt sich einerseits umgehen (die shared memory Problematik) und andererseits ist es kein Problem. Du kannst in jedem ordentlichem OS nachlesen, wie sowas funktioniert: die Verwaltung mehrerer Prozesse auf einmal.
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?
Das funktioniert doch nicht, oder? Was passiert denn wenn ein Client ein Posting abschickt? Dann startet der Apache eine Client-Prozess, der dem Server-Prozess die Daten per Socket übergibt. Dieser speichert die Postings ja erstmal im RAM.
Ja, wenn das so günstig ist, soll er das so machen. Ich halte das aber für etwas zu kompliziert.
Ich verstehe nicht so recht wie sich der Server-Prozess jetzt verteilen lässt(also dass man parallel meherere Server-Prozesse mit gleichen DAten hat, obwohl die Software eigentlich nur für einen Prozess entwickelt ist). Im Prinzip müsste der Client den Request an jeden Server-prozess senden, oder macht das dann auch der Cluster?
Nein, die Anfrage geht an einen Server, der gerade Zeit dafür hat.
Ist er damit fertig und haben sich Daten geändert, wird die Spiegelung angeworfen. Das kann man sogar recht einfach über ein Hook in write() basteln.
Irgendwie verstehe ich das nicht. Odere belibet wirklich alles beim alten, auf irgendeiner Node wurdde der Cleint-prozess gestartet der komuniziert mit dem Server per Unix Socket Domain, und die Cluster-Software sorgt dafür dass die anderen Prozessde auf den Anderen Nodes ebenfalls upgedatete werden? Nur - woher weiß die Software, ob ich schreibend auf den Server zugreife, so dass der Request an alle verteilt wird, und auf der andere Seite bei einem lesenden Anfrage, dass man die Daten direkt lokal aus dem Server-Prozess auf dem eigenen Rechner auslesen kann, also nichts übertragen werden muss?
Irgendwo ganz unten ist es nachher read() und write(), Hook darein und fettich. Da beide Funktionen in der LibC sind, brauchen die Anwendungen noch nicht einmal dafür geändert werden.
(Das ist "übersimplifiziert" ich weiß ;-)
Oder UDP, das gäbe noch weniger Overhead.
ja stimmt, aber dann muss man in die Anwendungen irgendeien Art von "Empfanmgskontrolle" einbauen, indem man eine Checksumme oder sowas mit zurücküberträgt.
Das ist dann aber schon _sehr_ detailiert, das läßt sich nur im Laufe des Codens beantworten, wie man das jetzt genau macht.
Ja, es ist durchaus möglich, das der Apache nicht out-of-the-box mitspielt. Sollten aber keine größeren chirurgischen Eingriffe nötig sein.
Ja? Willst Du Ihm mal eben abgewöhnen shared memory zu verwenden? ;-)
Wenn's Not tut?
Ich könnte sogar hingehen und ganz auf Apache verzichten, es gibt ja noch mehr HTTP-Server. (Das würde aber nur funktionieren, wenn man wirklich _nur_ die HTTP-Server Funktion des Apachen braucht. Meist braucht man aber noch einen ganzen Haufen mehr)
AFAIK brauchst Du mindestens 2 Prozesse, einmal den Steuerprozess, und mindestens einen der arbeitet. Und die verwenden wohl shared memory. Was willst Du dagegen machen?
Den Shared Memory auf den Haken nehmen?
Aber vielleicht lohnt sich ja auch Gbit Ethernet, soweit ich weiß schafft ein normaler PCI-Bus mit 33 Mhz und 32Bit in der Praxis so um die 80 MB/sekunde, Fast Ethernet aber nur so um die 10. Also ist das schon eine deutliche Steigerung auch wenn man nicht ganz so viel ereicht wie mit schnelleren PCI Versionen, aber die sind viel zu teuer. Gbit Ethernet-Karten bekommt man dagegen schon unter 20 EUR.
Bei den Preisen ließe sich das durchaus überlegen. Lange Kabel sind ja nicht vorhanden.
Nur sind echte Gbit Ethernet Switches noch deutlich teuerer, bis 8 Ports finde ich noch ne Menge, aber darüber wirds sehr teuer. Naja, vermutlich braucht man es her nicht.
8 würden ja auch reichen, 10 war nur, weil's 'ne runde Zahl ist ;-)
Die Porsting werden ja zunächst nicht auf die Platte geschreiben, erst nach x Minuten dann alle zusammen, und ich meine mich zu erinnern das selbst dieses Schreiben dann schonmal für Verzögerungen sorgt, wenn man dagegen noch über Ethernet muss, dann wird dass sicher nicht besser, oder?
Bottleneck ist das I/O mit der Platte selber, nicht das Anschmeißen des Schreibens.
Dazu kommt dann noch die Archivierung nachts, die dann auch noch erheblich länger dauern würde, naja, vielleicht doch Gbit Ethernet? Wobei, sooo viele Daten fallen hier ja auch nicht an... ;-)
Archivierung kann im Hintergrund laufen, die stört nicht. (Frage mich ernsthaft, warum die jetzt stören sollte?)
Apropos Logfiles, wie funktionieren denn dann Apache-Logs wenn die Prozesse Quer verteilt sind?
Genauso, wie vorher auch.
Und der Apache loggt ja ständig, und das nicht wenig.
Läßt sich einstellen.
- für sauberen Clusterbetrieb ist eine getrennte Kommunikationsleitung nötig, darüber ginge dann auch der Abgleich.
Es gibt eh nur noch mindestens 100 MBit Netze, das sollte reichen.Also braucht man 2 Netze?
Wäre zu empfehlen, aber nicht unbedingt zwingend.
[...] Ich habe da irgendwo gelesen das das alles erst funktioniert wenn man auch verteiltes shared memory hinbekommt. Aber das ist noch nicht so weit.
Ist in Arbeit, erste Erfolge sind zu verzeichnen.
Naja, aber das ist ja dasselbe wie mit neuen Prozessoren udn Mainboards, wenn das so neu ist handelt man sich da sicher ne Menge Probleme ein...
Ja, das ist korrekt. Wollte auch nur darauf hinweisen, das die Arbeit an dem Problem schon recht weit gediehen ist.
Kennst Du denn Alternativen die das können? Und wenn das dann sowas noch unter FreeBSD laufen würde wäre das natürlich prima ;-)
Klar:
man gcc
xpdf 24547012.pdf
u.s.w.;->
Meinst Du selber auf FreeBSD portieren?
Ne ne, selber machen! ;-)
(GCC ist der Compiler, aber das wußtest Du ja, 24547012.pdf ist die Dateibezeichnung von "I-32 Intel(R) Architecture Software Developer's Manual Volume 1: Basic Architecture")
Naja, in einem Posting habe ich gelesen dass das nicht ganz so einfach ist, da eben der FreeBSD Kernel etwas anders funktioniert.
Ach, ist doch alles das gleiche Gelumpe: kennst du eins, kennst du alle ;-)
so short
Christoph Zurnieden