nicht angemeldet
Hi,
Schade eigentlich, wir hatten hier alle gehofft, das Du zumindest planst, einen Scheck auszustellen ;-)
OK, ich steuere die Netzwerkkabel bei ;-)
Vorsicht, Du könntest beim Wort genommen werden! ;-)
(Es gibt qualitative und damit auch preisliche Unterschiede bei den nötigen Kabeln. Eine komplette Verkabelung kann durchaus mehr als 100 EUR kosten! Aber gut, soviel ist das auch nicht ;-)
(rsync (alle rtools) und NFS sind sicherheitstechnisch bedenklich, [...]
Du hast selbst gesagt dass ein Cluster für die interne Kommunikation ein eigenes Netz verwenden sollte, also hör mir mit sowas auf ;-)
rsynch bräuchte ien _physikalisch_ getrenntes Netz, das ist bei ausreichender Durchsatzmöglichkeit ormalerweise nicht nötig, wäre halt nur schön.
Wieso ist rsync unsicher? Mit SSH und entsprechenden keys? [...]
Du kennst den Overhead von Verschlüsselung? Und damit meine ich nicht nur die extra Bandbreite (die schon bei 100 MBit und bei dem Bedarf nicht mehr weiter auffällt) sondern vor allem dei nötige Rechneleistung, die kann man nicht mehr so ohne weiteres ignorieren. Auch wird es dann recht komplex und damit fehleranfällig.
Aber vielleicht bin ich auch nur zusehr von meiner Paranoia besessen, die mir sagt: Alles was man nicht verschlüsseln muß, weil es einfach nicht da ist, ist ein Sorge weniger ;-)
rsync würde ja sowieso nur innerhalb dieses kleinen LANs funktionieren, Anfragen von außen werden ja nicht weitergeroutet.
Das Gefährdungspotential ist zu groß, darf man sich nicht drauf verlassen.
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.
Teil != Box.
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:
Wenn Du Dich nicht damit auskennst, warum hast Du dann diese Lösung gewählt? Die hast Du doch nicht aus dem losen Ärmel geschüttelt, oder? ;-)
Was haben wir hier für Prozesse die Last erzeugen?
Einen großen Teil der Last erzeigen die httpd Protzesse, siehe:
(Ach, das mit den Iframes funtkioniert tatsächlich? Nie vorher ausprobiert. Kompliment an Christian! Funktioniert hier (Konqueror 3.2.1) übrigens, warum Mozilla mäkelt ist schwer nachzuvollziehen)
der größte Teil davon sind Prozesse für reines HTML, also selfhtml, selfaktuell
[...]
Das der größte Teil read-only Operationen sind, war schon klar (ich hätte den Anteil übrigens für größer gehalten, wie kommt's?) nicht umsonst ist da ein Cache zwischengeschaltet.
Aber ich verstehe immer noch nicht so gaz, warum Du in Details optimierst und dabei eine hochkomplexe Umgebung schaffst. Das rentiert sich doch nicht.
Im übrigen gilt dasselbe für den Archiv-viewer,[...]
Entweder trennst Du alle Applikationen, oder faßt alle zusammen. Ein Mischmasch ist nicht gesund. Ist ein wenig zu allgemein, da einige Programme zu sehr zusammengehören, die sollte man dann natürlich als Einheit auffassen. Aber auch so sparsam wie möglich.
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:
Das die Netzauslastung niedrig ist, heißt nicht, des der Loadbalancer kein Bottleneck ist. Der ist eben einer und die andere Seite sind viele. Ob er sch auch so auswirkt ist natürlich eine andere Frage. Davon unbeleckt bleibt aber auch natürlich der Ausfall.
[...] 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.
Ich bezweifele nicht, das es zu schaffen ist.
Aber jetzt habe ich auch den Faden verloren: was wolltest Du mir damit sagen?
Was ich jetzt nicht bedacht habe, ist das wir hier ja meines Wissens einen Squit einsetzen[...]
Was hindert und hakt und nicht wirklich essentiell ist fliegt gnadenlos raus ;-)
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.
Das dauert. Was passiert in der Zwischenzeit? Steht alles?
Auch sind für so tiefgreifende Funktionen wahrscheinlich root-Rechte nötig, das ist sicherheitstechnisch nicht akzeptabel.
Was passiert überhaupt bei einem Fehler bei dem Vorgang? Wie möchtest Du den abfangen?
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 es eh so wenig Daten sind, diese selten gebraucht und alle regelmäßig verteilt werden, wofür dann überhaupt einen Datenhaltungsnode?
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.
Das ist eher unwahrscheinlich. PHP hat nicht genügend Vorzüge um als passendes Werkzeug für unseren Zweck angesehen werden zu können. Außerdem stehen evt noch Lizenzprobleme dagegen. (Die PHP-Lizenz, auch die Neue, ist seit Version 4 nicht mehr kompatibel zur GPL)
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).
Bei Sessiondaten können selbst 5 Minuten zuviel sein ;-)
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.
Ja, und genau dagegen muß etwas getan werden, das darf nicht mehr passieren.
Das fällt nämlich am meisten auf ;-)
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.
Mit oder ohne Datenverlust?
Es werden ständig (also alle paar Minuten) die Daten auf allen Rechnern synchronisiert, also von Node 5 aus per rsync verteilt,
[...]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!
Wenn sie in mindestens 2 RAMs stünden, wäre die Gefahr des Verlustes geringer.
Auch ließe sich das ändern, wenn alle Postings direkt auf Platte geschrieben würden. Das ist jetzt mehr oder weniger nur im RAM, weil der derzeit völlig unterdimensionierte Server damit nicht klarkommen würde. Mit ausreichend Schmackes in der Box wäre das kein Hinderungsgrund mehr.
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? [...]
Das Problem ist, das wir hier über statusfreie Protokolle reden. Die kannst Du nur Brute Force (hier: Timeout) auf Funktion überprüfen. Auch bekommst Du dann nur raus, ob der Server überhaupt noch läuft, das geht über dei Heartbeatfunktionen besser. Auch müßtest Du die Priorität der HEAD Anfragen hochschrauben, die ist nämlich meist im Keller um DoS zu reduzieren. Sicherheitstechnisch nicht so gelungen. Der Selfserver hat eh schon genügend Probleme in dem Bereich, mußt nicht auch noch einen draufsetzen.
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.
Oder ich frage jemanden, der sich damit auskennt. Das ist zwar ein geringfügiger Overhead, aber IPs in Skripten, Datenbanken o.ä. on-the-fly zu ändern ist gefährlich in vielerlei Hinsicht. Keine empfohlene Vorgehensweise.
[...]
[...]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.
Wenn Ausfälle unangenehm werden, muß für Zuverlässigkeit georgt werden, ja, das ist korrekt. Allerdings kann das auch durch redundante Auslegung erfolgen. Ist in unserem Fall billiger.
Kleine Anektdote am Rande: In einem Posting weiter oben (kein Link, mit Absicht) wurde doch glatt die Verfügbarkeit von Boxen wie folgt berechnet:
Wenn eine Box 90% Zuverlässigkeit hat, dann haben zwei Boxen von 90% Zuverlässigkeit nur noch 90% * 90% = 81% Zuverlässigkeit. Wer bringt den Leuten heutzutage eigentlich Wahrscheinlichkeitsrechnung bei? ;-\
Auf der anderen Seite dürfte der Job in wenigen Sekunden umgestellt sein.
Du müßtest relativ viel umbauen, das könnte schon eine Minute dauern. Aber gut, so viel ist das nicht, der Fall dürfte ja auch nicht regelmäßig eintreten.
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.
Wirkich _lebenswichitg_ sind natürlich keine der Daten, aber auch eine Reputation ist etwas wert!
KISS, "Keep it simple, stupid!"
Wenn ich diesen Grundsatz beherzige, habe ich folgende Konstellation:WWW
|
Router
| | |
Nodes 1,2,3Die 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.
Nein, ich meinte - wie eigentlich etwas früher schon beschrieben? - keinen Router, wie er als Rubrik im Handel zu finden ist, sondern das logische Gerät. Es muß noch nicht einmal ein einzelnes Gerät sein, ja es ist noch nicht einmal nötig, das das überhaupt ein physikalisches Gerät ist, denn sogar die Clustersoftware könnte den Part übernehmen (Dann wird's allerdings kompliziert ;-)
Sicher wäre das besser, weil man den potentiell problematischen billig-Loadbalancer loswird.
"Billig" nicht unbedingt ;-)
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.
Jetzt häng Dich doch nicht so an MOSIX fest!
Da hab' ich ja was gesagt *sigh* ;-)
Au Mann, jetzt war's sogar "etwas zuviel", hoffe habe nicht zuviel geripped.
so short
Christoph Zurnieden