nicht angemeldet
Hi,
Könntest mal nach MOSIX googeln. Wäre zwar nicht unbedingt die Software meiner Wahl, aber MOSIX ist sehr gut dokumentiert, würde Dir wahrscheinlich weiterhelfen.
Oh ja, _sehr_ interessant. Hat nur ein paar Haken, damit läuft kein verteilter Apache, kein PostgreSQL, keine pthreads, und die aktuelle Version läuft nur unter Linux.
Na, dann weißt Du ja jetzt, warum das nicht die Software meiner Wahl ist ;-)
Aber war sehr interessant!
Genau deshalb der Hinweis, damit Du erstmal langsam dahinter kommst, was da überhaupt vorgeht. War aber auch das einzige wovon ich _weiß_, das es gut dokumentiert ist ;-)
Achso, ja gut, einen Loadbalancer/Router o.ä. braucht es schon, das ist wahr. Fällt bei mir aber unter Peripherie, braucht außerdem keine beweglichen Teile ist also haltbar. Aber mehrere IPs unter ein und derselben Adresse ist durchaus gängig, da müßte nichts verteilt werden.
Ja, die Frage die ich mir gestellt habe ist ob das dann auch öffentliche IPs sind die dann durchgeroutet sind, oder ob die Maschinen private IPs bekommen, vermutlich letzteres.
Kann auch beides sein, ist nichts ungewöhnliches. Wird aber vor allem bei Mailservern gemacht, da ist das laut Protokoll sogar vorgesehen (Das sind die Zahlen neben den MX-Servern, die geben die Reihenfolge der Auswahl vor. Können aber auch gleich sein.)
Und: ja, in einem Cluster sollte jeder Rechner alles können, das würde die Administration sehr vereinfachen.
Aber dazu muss die Cluster-Software in der Lage sein auch Prozesse die Shared Memory(z.B. Apache) verwenden zu verteilen, das kann Mosix AFAIK nicht. Hast Du eigentlich praktische Erfahrung mit Clustern?
Ja.
Läuft sowas auch wirklich stabil?
Ja.
Wenn ich mir so überlege wie komplex das ganze ist...
Na, ganz so schlimm ist's auch wieder nicht ;-)
Ich hatte eigentlich gedacht, dass alle Request über einen(qualitativ hochwertigeren) Rechner kommen, der die anderen Rechner vewaltet, und dann nur die Prozesse auf die Rechner verteilt, je nach deren Auslastung. Sowas in der Art, aber sowas finde ich nicht ;-)
Optimal wäre es natürlich wenn ein Loadbalancer die Requests direkt schön verteilt.
Da ist die Frage der Definition von "Last", wie mir Michael Schroepl erst gerade sagte, das ist schwer zu beantworten. Ein vollautomatischer Loadbalancer wäre also für die Vielfalt der Aufgaben nur sehr beschränkt einsetzbar. Wäre wohl am Ende viel T&E nötig.
Ich finde immer nur Informationen wie man dann Software entwickelt, die sich auf mehrere Rechner verteilen lässt, aber gerade das will ich ja nicht, ich will eine Software die das für alle Prozesse übernimmt. Gibts sowas nicht?
Diese Frage verstehe ich nicht. Wenn Du einen Prozess auf viele Rechner verteilen kannst, warum solltest Du nicht viele Prozesse auf viele Rechner verteilen können? Wo liegt da der Hinderungsgrund?
Das hat sich inzwischen geklärt, nur eben für Apache & Co. nicht. Und das fände ich schon wichtig, da der afaik ja die ganzen Client-Prozesse über CGI startet, und das ist dann schon besser wenn das auch verteilt würde.
Jetzt bin ich ganz verwirrt. Warum sollten die ganzen Prozesse über CGI gestartet werden, was macht das für einen Sinn? Selbst wenn man das täte wäre es immer noch möglich, die Klammotten auf mehrere Schultern zu laden.
Ich habe noch eine Frage, angenommen wir starten nur einen Server-Prozess für den Forumsserver, können die Client-Prozesse von den verschiedenen Clusterrechnern dann auch per Unix-Socket Domain drauf zugreifen?
Theoretisch ja. Aber warum sollten sie? Die Last wird vorher schon verteilt, alle Rechner haben die gleichen Datensätze, warum also Kommunikation?
Eigentlich ja nicht, oder? Aber auch wenn schon, das würde dann ja eh über TCP weitergeleitet, also kann man sich den Overhead auch sparen und in der Forums-Anwendung die Kommunikation direkt auf TCP umstellen, wenn ich CK richtig verstanden habe ist das jedenfalls möglich ;-)
Oder UDP, das gäbe noch weniger Overhead. Aber warum so kompliziert?
Ja? Was ist z.B. mit dem Apachen, wie genau würde das verteilt?
Thread- bzw prozessweise (Je nach Apache)
Zumindest bei mosix habe ich gelesen dass das eben nicht geht.
"Geht nich, gipps nich!" ;-)
(Vorrausgesetzt das alle Quellen verfügbar sind natürlich)
Das ginge wenn der Apache alleine mit Threads arbeiten würde, aber das macht er in keiner Varante, das worker MPM ist im Prinzip dasselbe wie prefork, nur dass die Kinderprozesse eine feste Anzahl von Threads starten die die Requests bearbeiten. Das hat eigentlich nur den Vorteil das der Server bei ein klein wenig höherer Leistung weniger RAM verbraucht als mit prefork, soll dagegen aber nicht ganz so stabil sein.
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.
Vorbehaltlich möglichen schweren Irrtums meinerseits ;-)
Haben dann alle Maschinen die selben Daten auf der Platte?
Ja. Wäre zumindest die billigste Lösung.
Dann muss man aber bei jedem Schreibvorgang auf alle Platten gleichzeitig schreiben, und dazu noch alles über das Ethernet übertreagen, und zumindest Fast Ethernet ist noch deutlich langsamer als normaler Platten.
Eigentlich ein Mißverständnis meinerseits (Ich will schon eigentlich Daten und Anwendung getrennt halten, so ist das ja nicht ;-), aber bei näherer Betrachtung auch nicht schlecht, denn:
-
Es wird selten geschrieben und wenn, nicht allzuviel.
Es werden zwar regelmäßig Postings abgesetzt, aber keine 100 Stück pro Sekunde o.ä. (Wäre mal statistisch aus den Logfiles zu ziehen, wie so die ganzen Spitzenwerte lauten). Die Dinger haben maximal rund 16 kib an Daten (Auch hier wieder: Durchschnitt aus den Logfiles) -
Verzögerungen beim Spiegeln liegen im Sekundenbereich, das fällt dem Benutzer nicht auf.
Wenn das Posting beim sofortigem Reload der Forumsdatei nicht da ist, wird einfach neu reloaded. Das dauert alles ein paar Sekunden, bis dahin ist es gespiegelt. (Man könnte auch den Danke-Text dahingehend verändern, das es nicht mehr heißt "...ist jetzt im Forum lesbar" sondern "...ist in ein paar Sekunden im Forum lesbar") Auch hierüber sollten einige Angaben aus den Logfiles zu ziehen sein, wenn auch nicht mehr ganz so sauber, wie oben. -
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.
Man muß nicht in den Quellcode eingreifen, da die Prozesse(Threads) selber nicht vom Programm gestartet werden, sondern vom OS, oder von Bibiotheken. Änderungen an beiden erfordern keinerlei Änderung am Programm selber.
Aber zumimndest bei mosix ist es wohl doch ein Problem mit dem RAM, bei normalen Prozessen und Threads ist das anscheinend kein Problem mehr, bei shared memory und pthreads wohl doch, und leider benutzen das viele gute Programme. 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.
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.
;->
Aber das ist von 2003: http://howto.ipng.be/openMosixWiki/index.php/don't
Das steht eigentlich so alles wo es sinnvoll wäre, Anwendungen die pthreads und solche die shared memory nutzen, Apache und PostgreSQL. Aber Du sagstest ja Du würdest mosix eh nicht einsetzen - was dann?
Siehe oben ;-)
Nein, ernsthaft: das ist zu entscheiden, wenn man genau weiß, was überhaupt gebraucht wird. Das dauert auch alles sowieso noch etwas länger, vielleicht ist bis dahin sogar MOSIX die erste Wahl, wer weiß?
Bis jetzt gibt es aber wirklich keine fertige Software, es gilt also das Übliche: Nachschauen, wie es die anderen gemacht haben, wo deren Probleme liegen und wo deren Nutzen und dann selber bauen. So kleine Cluster sind meist Spezialisten, da kann man kaum Fertigware für nehmen.
Ich befürchte, das es um die simple Frage geht: was ist am billigsten für unsere Zwecke.
Ja, da hast Du Recht, auch wenn das vermutlich am Ende dann nicht in Frage kommt, ich finde das Thema trotzdem höchst interessant ;-)
Nicht nur das: jetzt kannst Du bei nächster Gelgenheit bei so einem Thema lässig in's Archiv verweisen:"Das hatten wir doch erst letzthin, schau doch mal [link ... " ;-)
PS: "mosix" ist ein ein ziemlich dämliche Name ;-)
Jupp! ;-)
so short
Christoph Zurnieden