Etherpad-lite: Zustandsloses Etherpad

Im Moment gibt es keine Initiative, Etherpad zustandslos zu machen, aber wir ermutigen und laden Sie ein, dies voranzutreiben, da es sich lohnt, es zu verschlingen.

Anstatt zustandslos zu werden, optimierten wir die Leistung des Threads, was bedeutete, dass unsere Lasttestzahlen bei der Simulation (siehe die von uns bereitgestellten Tools) ziemlich beeindruckend sind. Damit sind fast alle unsere Kunden zufrieden.

Unsere anderen großen Kunden (M von Pads, Benutzer mit 5.000 Zahlen pro Tag) haben ein Sharding-System, bei dem Pads mit einer bestimmten URL an eine bestimmte Hardware weitergegeben werden. Füllt also an an Server 1, oz an Server 2 und alle anderen zufälligen Zeichen #!'; usw. auf Server 3. Jeder Server hat auch sein eigenes Backend. Dies ist jedoch nicht optimal, denn wie Sie sagten, HA ist ein Problem ... :)

Die Sache ist die, dass wir alle Operational-Transformationsoperationen für ein bestimmtes Pad in einem bestimmten Thread beibehalten möchten, damit wir den Datenverkehr optimieren und gering halten können. Es macht keinen Sinn, 10 Server zu haben, die OTs für 5 Benutzer verwalten, da dies zu Latenz und Fragilität führen würde. Letztendlich bin ich also der Meinung, dass Sie den Inhalt eines bestimmten Pads in einer Instanz behalten möchten, selbst wenn Sie staatenlos werden.

Trotzdem klingt es so, als wüssten Sie mehr über Staatenlosigkeit / HA mehr als ich und es ist mehr als 5 Jahre her, dass ich mich damit befasst habe umgesetzt 👍

Danke für die Erklärung. Ich verstehe völlig die Gründe für die Entscheidung, einen Thread zu optimieren, anstatt ihn zustandslos zu machen. Vorerst werden wir mit dem zustandsorientierten Setup fortfahren, da wir gerade einen POC aufbauen, der noch immer auf hohem Niveau die Zustimmung der Organisation benötigt. Nachdem wir dies erreicht haben, bin ich in der Tat sehr dafür, die Bemühungen um die Staatenlosigkeit zu unterstützen.

Nur eine Idee rund um HA und um zu klären, warum ich das in unserer Situation suche. Wir arbeiten in einer Unternehmensumgebung und dies kann jede Lösung sehr komplex machen. HA würde es uns ermöglichen, uns auf die Entwicklung guter Lösungen zu konzentrieren, anstatt sich später darum zu kümmern, sie zu verwalten. Das Leben ist schon schwer genug, also hilft jede zustandslose Software! Und das nicht nur für Ingenieure, die die Lösungen erstellen und betreiben ... die Geschäftsseite hat sich schnell durchgesetzt und sieht den Wert der Entwicklung von HA-Lösungen. Da die Hände der Ingenieure für Ad-hoc-Arbeit und Brandbekämpfung frei bleiben, kann man sich stattdessen auf die Generierung neuer Werte konzentrieren.

Super danke; halten Sie uns auf dem Laufenden und zögern Sie nicht, alle Abneigungen / Macken / Fehlerberichte durchzugehen und wir werden uns bemühen, sie so schnell wie möglich zu bearbeiten.

Hallo :welle:

Wir (OpenFUN) haben ein zustandsloses Docker-Image für etherpad-lite : https://github.com/openfun/etherpad-docker

Wir führen dieses Image über k8s (OKD) aus und es läuft gut in der Produktion (siehe https://pad.education), aber wir leiden unter Websocket-Problemen, während wir versuchen, unsere Pods zu skalieren. Wir haben eine Redis-basierte Abstraktionsschicht entworfen, um dies zu beheben, aber leider scheinen nicht alle Ereignisse zu dieser Abstraktionsschicht überzugehen... Sie können unseren POC hier einsehen: https://github.com/openfun/etherpad- Docker/Zug/8

@ottomattas Ich bin mir nicht sicher, ob Sie versuchen, Ihre Instanz in einem k8s-Kontext oder sogar in einem Docker-Container auszuführen, aber wir können uns in diesem Fall zusammenschließen: Pray:

@JohnMcLear Jeder Rat zur Verwendung des socket.io-redis-Adapters wäre eine große Hilfe. :beten:

Pad.education lädt keine Pads?

Ich helfe gerne, wenn ich kann, wie sieht Ihr Zeitplan aus?

Pad.education lädt keine Pads?

Nein, es lädt Pads! Aber wir führen nur eine Etherpad-Instanz aus und können nicht "auf Kubernetes-Weise" skalieren (_d. h._ indem wir weitere Repliken der App hinzufügen und Anfragen mit einem Round-Robin-Algorithmus weiterleiten).

Zuerst dachte ich, dass dies nur an Websockets liegt, und deshalb haben wir versucht, einen socket.io-redis Adapter zu verwenden, damit eine Etherpad-Instanz nicht an einen Client gebunden ist. Es funktioniert jedoch nicht, da einige Ereignisse nicht an diesen Redis-Adapter gesendet werden, und, FWIU [1], werden wir mit anderen Problemen im Zusammenhang mit dem Anwendungsstatus konfrontiert. Habe ich recht?

Ich helfe gerne, wenn ich kann, wie sieht Ihr Zeitplan aus?

Im Moment ist die Skalierung dieses neuen Dienstes für uns nicht entscheidend (alles läuft gut), aber wir planen für die Zukunft. Ich frage mich, was erreicht werden soll, um die Anwendung zustandslos zu machen? Ist der Redis-Socket.io-Adapter eine Sackgasse?

Wenn es keine Priorität hat, Etherpad zustandslos zu machen oder zu viele Änderungen an der Kern-App erforderlich sind, haben wir andere alternative Pläne, die dem Sharding-Ansatz ähnlich sind, den Sie zuvor erklärt haben [2]. Ich sammle Feedback, um den effizienteren/pragmatischeren Ansatz zur Skalierung der App zu wählen.

[1] https://github.com/ether/etherpad-lite/issues/3680#issuecomment -566809617
[2] https://github.com/ether/etherpad-lite/issues/3848#issuecomment -610942249

@jmaupetit , im Sharding der Pad-Namen.

Ich interessiere mich auch sehr für ein solches Feature, wir brauchen auch HA und Load-Balancing.
Ich bin nur ein Anfänger mit Etherpad, aber in der Wartezeit habe ich es auf 2 Servern bereitgestellt und verteile den Zugriff je nach Art meiner Benutzer, wir können ungefähr 5 000 Benutzer gleichzeitig haben und vielleicht mehr. Die 2 Etherpads-Server fordern dieselbe Datenbank an, und für das Failover habe ich den zweiten Server als Fallback-Server platziert.

@JohnMcLear

Unsere anderen großen Kunden (M von Pads, Benutzer mit 5.000 Zahlen pro Tag) haben ein Sharding-System, bei dem Pads mit einer bestimmten URL an eine bestimmte Hardware weitergegeben werden. Füllt also an an Server 1, oz an Server 2 und alle anderen zufälligen Zeichen #!'; usw. auf Server 3. Jeder Server hat auch sein eigenes Backend. Dies ist jedoch nicht optimal, denn wie Sie sagten, HA ist ein Problem ... :)

Mich würde interessieren, wie die Leute das gemacht haben und welche Sharding-Systeme sie gemacht haben. Wir können kein solches Feedback zur Bereitstellung großer Instanzen finden.

@jgribonvald Vollständiger Haftungsausschluss hier: Ich mache diese Arbeit für gewerbliche Kunden, also ist dies wirklich die Art von Arbeit, die ich auf einem Tagessatz erledige. Aber im Sinne von Open Source und zur Unterstützung unserer Community gibt es hier eine Varnish-VCL, die Sie manipulieren können, um zu funktionieren.

Splittern

    vcl 4.0;

    backend static {
        .host = "staticcontent.etherpad.com";
        .port = "9001";
        .connect_timeout = 6000s;
        .first_byte_timeout = 6000s;
        .between_bytes_timeout = 6000s;
    }

    backend ep1 {
        .host = "192.168.0.1";
        .port = "9001";
        .connect_timeout = 6000s;
        .first_byte_timeout = 6000s;
        .between_bytes_timeout = 6000s;
    }

    backend ep2 {
        .host = "192.168.0.2";
        .port = "9001";
        .connect_timeout = 6000s;
        .first_byte_timeout = 6000s;
        .between_bytes_timeout = 6000s;
    }

    sub vcl_recv {
           if (req.url == "^/static/*$") {
              set req.backend_hint = static;
           } else {
        set req.backend_hint = vm1;
        }

   .. logic for socket header stickiness [ secret sauce I can't copy/pasta (see below for understanding)]

    sub vcl_recv {
           if (req.url == "^/[a-g]/*$") {
              set req.backend_hint = ep1;
           }

    sub vcl_recv {
           if (req.url == "^/[h-z]/*$") {
              set req.backend_hint = ep2;
           }

Sie werden wahrscheinlich ein Rewrite basierend auf req.http.header festlegen wollen, das die padId für die Socket-Konnektivität enthalten muss. Die uri ist immer /socket.io/ . Sie müssten etherpad erweitern, um padId in die Header aufzunehmen. Das geht ganz einfach mit einem Plugin.

Kleben

Unter Verwendung eines beliebigen Key/Value-Systems können Sie leicht ein Routing-System auf Pad-Ebene implementieren. Grundsätzlich hätte Ihr Umschreibeendpunkt einen gemeinsam genutzten (idealerweise schnellen Zugriff im Arbeitsspeicher) Speicherplatz von Server<>padId [1 zu 1-Beziehung] und jeder Routingendpunkt ist sich dieser Beziehung bewusst, sodass der Benutzer basierend auf der padId an den Server weitergeleitet wird. So funktionieren andere große Plattformen, denn wie ich bereits sagte, möchten Sie wirklich nicht, dass eine einzige Pad-Sockel-Konnektivität verteilt wird. Dies ist immer noch Sharding, aber es ist dynamisch, basierend auf den von Ihnen festgelegten Kriterien (zB geografische Nähe des Pad-Erstellers), afaik macht Google dies.

Das erledigen

Der Grund, warum wir dies als Etherpad-Entwickler nicht tun, ist, dass die Rollouts variieren (eine große Menge), sodass wir unsere Devops / Sys-Admin-Freunde anvertrauen, die derzeit beliebte Lösung so einzusetzen, dass sie die benötigte Größe erreicht. Während diese Frage willkommen ist, möchte ich nur die Gründe angeben, warum sie nicht in Etherpad integriert ist.

@JohnMcLear Vielen Dank, ich werde sehen, was wir damit machen können!

Siehe auch https://github.com/ether/etherpad-lite/issues/3335

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität hatte. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.