Cloister → einfaches Cluster-Management von OTP

Fast jede erfolgreiche Geschäftsanwendung gelangt früher oder später in eine Phase, in der horizontale Skalierung erforderlich ist. In vielen Fällen kann man einfach einen neuen Instanz starten und die durchschnittliche Last reduzieren. Es gibt jedoch auch weniger triviale Fälle, in denen wir sicherstellen müssen, dass die verschiedenen Knoten voneinander wissen und die Arbeitslast sorgfältig verteilt wird.

So kam es gelegen, dass erlang, das wir wegen seiner angenehmen Syntax und des Hypes, der darum gemacht wurde, gewählt haben, eine erstklassige Unterstützung für verteilte Systeme. In der Theorie klingt das ziemlich trivial:

Die Kommunikation zwischen Prozessen auf verschiedenen Knoten sowie zwischen Links und Monitoren ist transparent […]

In der Praxis ist alles etwas komplizierter. Verteilt erlang wurde entwickelt, als 'Container' eine große Eisenkiste für den Transport bedeutete und 'Docker' einfach ein Synonym für einen Hafenarbeiter war. In IP4 gab es viele ungenutzte Adressen, die Gründe für Netzwerkausfälle waren in der Regel durch Kabel, die von Ratten durchgebissen wurden, und die durchschnittliche Betriebszeit eines Produktionssystems wurde in Jahrzehnten gemessen.

Jetzt sind wir alle unvorstellbar selbstgenügsam, verpackt und führen eine verteilte erlang in einer Umgebung aus, in der dynamische IP-Adressen nach dem Prinzip des großen Zufalls vergeben werden, und Knoten zu erscheinen und zu verschwinden scheinen, wann immer der Planungsalgorhythmus es wünscht. Um einen Haufen wiederverwendbaren Codes in jedem Projekt, das eine verteilte erlangausführt, zu vermeiden, ist Unterstützung erforderlich.

Hinweis: Ich weiß, dass es libclustergibt. Es ist wirklich cool, hat über tausend Sterne, der Autor ist in der Community bekannt und so weiter. Wenn dir die Möglichkeiten, die dieses Paket zur Erstellung und Wartung eines Clusters bietet, ausreichen – ich freue mich für dich. Leider brauche ich viel mehr. Ich möchte die Konfiguration im Detail steuern und kein außenstehender Zuschauer im Theater der Cluster-Neugestaltung sein.

Anforderungen

Was ich persönlich brauchte, war eine Bibliothek, die die Verwaltung des Clusters übernimmt und folgende Eigenschaften hat:

• transparente Funktion sowohl mit einer fest codierten Liste von Knoten als auch mit dynamischer Entdeckung über Dienste erlang;
• voll funktionsfähiger Rückruf bei jeder Änderung der Topologie (Knoten dorthin, Knoten dorthin, Netzwerkinstabilitäten, Splits);
• transparente Schnittstelle zum Starten eines Clusters mit langen und kurzen Namen, wie bei :nonode@nohost;
• Out-of-the-Box Docker-Unterstützung, ohne Infrastrukturcode schreiben zu müssen.

Das bedeutet, dass ich, nachdem ich die Anwendung lokal in :nonode@nohost, oder in einer künstlich verteilten Umgebung durch test_cluster_task, einfach ausführen möchte docker-compose up --scale my_app=3 und sehen möchte, wie es drei Instanzen in Docker ohne Änderungen am Code ausführt. Ich möchte auch, dass abhängige Anwendungen, wie zum Beispiel mnesia — wenn sich die Topologie ändert, das Cluster hinter den Kulissen live neu konfiguriert wird, ohne dass ein zusätzlicher Schubs von der Anwendung notwendig ist.

Cloister wurde nicht als Alleskönner-Bibliothek gedacht: von Clusterunterstützung bis zur Kaffeezubereitung. Es ist keine Allheilmittel, die versucht, alle möglichen Fälle abzudecken, oder eine akademisch vollständige Lösung im Sinne, den Theoretiker von CS in diesen Begriff einlegt. Diese Bibliothek hat einen sehr klaren Zweck, aber sie soll ihre nicht allzu große Aufgabenmenge perfekt erfüllen. Dieser Zweck besteht darin, vollständige Transparenz zwischen der lokalen Entwicklungsumgebung und einer verteilten elastischen Umgebung mit feindlichen Containern zu gewährleisten.

Der gewählte Ansatz

Cloister soll als Anwendung ausgeführt werden, obwohl erfahrene Benutzer die Möglichkeit haben, den Cluster manuell zu bauen und zu verwalten, indem sie direkt Cloister.Manager im Baum der Aufseher der Zielanwendung starten.

Bei der Ausführung als Anwendung verlässt sich die Bibliothek auf config, aus dem sie die folgenden Hauptwerte liest:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # oder ~w|n1@foo n2@bar|a
  consensus: 3,              # Anzahl der Nodes, die berücksichtigt werden sollen
                             #    das Cluster ist aktiv
  listener: MyApp.Listener   # Listener, der aufgerufen wird, wenn
                             #    sich der Ring geändert hat

Die oben genannten Parameter bedeuten wörtlich folgendes: Cloister wird für die OTP-Anwendung verwendet :my_app, nutzt Erlang-Dienstentdeckung zum Verbinden von Knoten, mindestens drei, und MyApp.Listener Modul (implementiert @behaviour Cloister.Listener) ist konfiguriert, um Benachrichtigungen über Änderungen der Topologie zu empfangen. Eine detaillierte Beschreibung der vollständigen Konfiguration finden Sie in Dokumentation.

Mit dieser Konfiguration wird die Anwendung Cloister schrittweise gestartet ., wobei der Startprozess der Hauptanwendung bis zum Erreichen eines Konsenses (drei Knoten sind verbunden und verknüpft, wie im obigen Beispiel) verschoben wird. Dies gibt der Hauptanwendung die Möglichkeit zu vermuten, dass der Cluster bereits verfügbar ist, wenn sie gestartet wird. Bei jeder Änderung der Topologie (es wird viele geben, da die Knoten nicht vollständig synchron gestartet werden) wird ein Handler aufgerufen. MyApp.Listener.on_state_change/2. In den meisten Fällen führen wir eine Aktion aus, sobald wir eine Statusmeldung erhalten. %Cloister.Monitor{status: :up}, was bedeutet: „Hallo, der Cluster ist zusammengestellt.“

In den meisten Fällen ist die Einstellung consensus: 3 optimal, denn selbst wenn wir erwarten, dass sich mehr Knoten anschließen, wird der Callback durchlaufen. status: :rehashing → status: :up für jeden neu hinzugefügten oder entfernten Knoten.

Beim Start im Entwicklungsmodus genügt es, einfach consensus: 1 und Cloister festzulegen, und es wird freudig die Wartezeit auf die Clusterbildung überspringen und sehen, :nonode@nohost, oder :node@host, oder :node@host.domain — abhängig davon, wie der Knoten konfiguriert wurde (:none | :shortnames | :longnames).

Verwaltung verteilter Anwendungen

Verteilte Anwendungen sind in der Regel nicht isoliert und beinhalten oft ebenfalls verteilte Abhängigkeiten wie mnesia. Es ist einfach, ihre Rekonfiguration aus demselben Callback on_state_change/2zu verwalten. Hier ist beispielsweise eine ausführliche Beschreibung, wie man mnesia zur Laufzeit in Dokumentation Cloister.

ändern kann. Der Hauptvorteil der Nutzung Cloister besteht darin, dass es alle notwendigen Operationen zur Neuordnung des Clusters nach einer Änderung der Topologie durchführt. unter der HaubeDie Anwendung wird einfach in einer bereits vorbereiteten verteilten Umgebung gestartet, mit allen verbundenen Knoten, unabhängig davon, ob wir die IP-Adressen und damit die Knotennamen im Voraus kennen oder ob sie dynamisch zugewiesen/ändern wurden. Das erfordert keine speziellen Docker-Konfigurationseinstellungen, und aus Sicht des Anwendungsentwicklers gibt es keinen Unterschied zwischen dem Start in einer verteilten Umgebung oder lokal auf :nonode@nohost. Weitere Informationen dazu finden Sie in Dokumentation.

Trotz der Tatsache, dass eine komplexe Handhabung von Topologieänderungen durch eine eigene Implementierung möglich ist, können immer Grenzfälle auftreten, in denen diese Bibliotheksbeschränkungen und ein voreingenommener Ansatz zur Konfiguration zum Stolperstein bei der Implementierung werden. Das ist in Ordnung, nehmen Sie einfach das oben Genannte. MyApp.Listener. libcluster, die universeller ist, oder sogar den Low-Level-Cluster selbst zu bearbeiten. Ziel dieser Bibliothek ist es nicht, alle möglichen Szenarien abzudecken, sondern das gängigste Szenario ohne unnötige Schmerzen und umständliches Kopieren und Einfügen zu nutzen.

Hinweis: An dieser Stelle war im Original die Phrase „Happy clustering!“, und Yandex, das ich benutze (ich kann ja nicht selbst in Wörterbüchern suchen), hat mir die Option „S glücklichen Clustering!“ vorgeschlagen. Ein besserer Übersetzung wäre wohl gerade im Hinblick auf die aktuelle geopolitische Situation unmöglich.

Quelle: habr.com