nicht angemeldet
Hallo!
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 ;-)
Na, bevor es an den Kabeln scheitert... :)
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.
Das stimmt auch wieder. Aber in einem physikalisch getrenneten Netz ist das ja nicht das Problem, oder?
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.
Ja, das hatten wir irgendwo schonmal ;-)
Ich habe letztens Geschmack an nmap gefunden, nettes tool, damit habe ich gerade mal mein Netzwerk zu Hause hinter nem DSL-Router gescannt, und - frag mich nicht wieso - aber das Teil hat tatsächlich offene Ports hinter dem Router gefunden, obwohl die nicht von außen per port forewarding weitergeleitet werden, hat die dann als "filtered" markiert. Naja, und wenn das schon geht...
naja, ich dachte eher an 8 oder 10 Rechner, wovon dann auch mehr als 1 Backend-Serverdienste übernehmen können.
Teil != Box.
Aber meine "Teile" bezogen sich auch in keinster Weise auf ein Verhältnis, nur wäre das in der Praxis vermutlich tatsächlich irgendwo in dem Bereich wie Du es beschreibst.
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? ;-)
Es interessiert mich halt, kann gut sein dass Olli, CK oder wer auch immer das ganze aus einem etwas anderen Blickwinkel sehen ;-)
| | 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?)
Ja, das hat mich jetzt allerdings auch sehr gewundert dass das Forum so viele Requests hat wie selfhml.
nicht umsonst ist da ein Cache zwischengeschaltet.
Vielleicht liegt es daran? Vielleicht stehen nur die tatsächlch beim Apache landenden Requests im Webalizer? Wobei ich mich eigentlich glaube zu erinnern dass das die Logs des Caches sind, naja.
Aber ich verstehe immer noch nicht so gaz, warum Du in Details optimierst und dabei eine hochkomplexe Umgebung schaffst. Das rentiert sich doch nicht.
Ja, nachdem Du das ganze doch etwas auseinander genommen hast, macht es wohl doch nicht so viel Sinn. Ich dachte halt dass man am einfachsten eine Sttruktur aufbaut die möglichst nicht in die Applikationen selbst eingreifen muss.
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.
Hm, wenn Du das sagst, ich dachte halt dass man den Overrhead durch Netzwerk-Traffic für den Live-Betrieb so gering wie möglich halten sollte, wenn die Daten für eine mögliche Übernahme eines Dienstes doch eh auf der Platte liegen müssen, fand ich es ein bisschen schade drum dieselben diese Daten dann über das Netzwerk abzufragen.
[...] 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?
Du hast gesagt der Loadbalancer sei ein Bottelneck, und ich meine dagegen dass diese Last auch für eine Billigrechner kein Problem darstellt. BEdenke was der aktuelle Server noch so nebenher alles macht, und der Load-Balancer muss die Requests ja nur verteilen, nicht abarbeiten.
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.
Ah ja, das ist natürlich wahr. Hm, und nun? Alles Quatsch gewesen?
Was passiert überhaupt bei einem Fehler bei dem Vorgang? Wie möchtest Du den abfangen?
Ja, das wird langsam immer komplexer ;-)
Am Ende wird das noch zu einem Mosix2 ;-)
Wenn es eh so wenig Daten sind, diese selten gebraucht und alle regelmäßig verteilt werden, wofür dann überhaupt einen Datenhaltungsnode?
Das sollte ja kein eigener Rechner sein, das könnte ein anderer (z.B. Forumsserver) ja nebenher machen. Der Sinn ist halt, dass man in CGI-Programmen Daten beschreiben, kann, ohne ginge das nzr durch sntsprechende Sessions durch den Load-Balancer, um die auf einen Request folgenden Request an dieselbe Node zu dirigieren.
Und wenn die Daten nicht nur für einen Besuch gespeichert werden, dann müssen geschreibene Daten auch auif alle Nodes üvbertragen werden, und da dachte ich mir, für die paar Daten sei NFS doch die einfachere Lösung.
[vielleicht wird ja mal PHP eingeetzt]
Das ist eher unwahrscheinlich. PHP hat nicht genügend Vorzüge um als passendes Werkzeug für unseren Zweck angesehen werden zu können.
Doch, es gibt viele Leute die ein Ziel mit PHP schneller erreichen als mit PERL, ich zum Beispeil eben weil ich mit PHP gelernt habe. Heute nervt mich das, aber für einfache Aufgaben im Web-Umfeld ist PHP ideal.
Außerdem stehen evt noch Lizenzprobleme dagegen. (Die PHP-Lizenz, auch die Neue, ist seit Version 4 nicht mehr kompatibel zur GPL)
Nein, sie ist erheblich freier. Und selbst wenn, die Kompatibilität ist doch nur vorgeschreiben wenn wir die Software vertreibern wollten, oder? Willst Du mir jetzt erzählen dass alle die auf einem Linux-Rechner PHP verwenden gegen die GPL verstoßen?
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?
Mit demselben Datenverlust wie es im Augenblick passieren würde.
[Datenverlust bei Absturz des Forumsservers]
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.
Ja, das kann gut sein. Ist die Frage wieviel Schmackes man da wohl braucht, also entweder man vergrößert die Gesamtleistung, oder man entfernt andere Prozesse. Womit wir wieder bei der Ausgangsfrage wären(dicke Maschine, Cluster, einige wenige Maschinen...).
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.
Also Dich ;-)
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.
deswegen ja die IP des Servers annehmen, wenn eben ping 192.168.0.x scheitert. Oder per Heartbeat oder was auch immer. Aber da gibts ja noch Lösungen mit virtuellen IPs, meinst Du das?
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.
Meinst Du 2 Server die sich beobachten? Halt sowas:
<img src="http://t1d.www-1.cacheibm.com/servers/esdd/articles/linux_clust/before.gif" border="0" alt="">
<img src="http://t1d.www-1.cacheibm.com/servers/esdd/articles/linux_clust/after.gif" border="0" alt="">
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? ;-\
Hm? Wenn ich mich richtig erinnere ging es darum, dass wenn eine der beiden Boxen ausfällt gar nichts mehr lief. Was ist denn daran falsch?
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* ;-)
Jajaja, das hast Du schon mehrfach gesagt ;-)
Nur hattest Du vollkommen Recht, einige dieser Lösungen sind kaum bis gar nicht dokumentiert, zumindest finde ich absolut nichts. Naja, aber Du kennst eine Software die einen Apachen über den Cluster verteilen kann, die zudem noch auf FreeBSD, wenigstens Linux läuft?
Au Mann, jetzt war's sogar "etwas zuviel", hoffe habe nicht zuviel geripped.
Das Problem hatte ich auch schon des öfteren, irgendwann kann man nichts mehr kürzen und muss irgendwelchen Text löschen, der nicht ganz so wichtig ist ;-)
Grüße
Andreas