Ein neues Zeitalter für die Cluster-Koordinierung in Elasticsearch

By
David Turner
•
Yannick Welsch

Einer der Gründe für die Beliebtheit von Elasticsearch ist die herausragende Skalierbarkeit von kleinen Clustern mit einer Handvoll Knoten hin zu riesigen Clustern mit Hunderten von Knoten. Im Zentrum steht dabei das Teilsystem für die Cluster-Koordinierung. Elasticsearch Version 7 enthält ein neues Teilsystem für die Cluster-Koordinierung mit vielen Vorteilen gegenüber früheren Versionen. Dieser Artikel beschreibt die Verbesserungen an diesem Teilsystem in Version 7. Finden Sie heraus, wie Sie dieses neue Teilsystem verwenden, wie sich die Änderungen auf Upgrades von Version 6 auswirken und wie diese Verbesserungen Sie davor schützen, Ihre Daten unwissentlich in Gefahr zu bringen. Zum Abschluss befassen wir uns mit einer theoretischen Beschreibung der Funktionsweise des neuen Teilsystems.

Was gehört zur Cluster-Koordinierung?

Ein Elasticsearch-Cluster kann viele Aufgaben ausführen, bei denen mehrere Knoten zusammenarbeiten müssen. Jede Suche muss beispielsweise durch die richtigen Shards geroutet werden, um korrekte Ergebnisse zu garantieren. Jedes Replikat muss aktualisiert werden, wenn Sie Dokumente indexieren oder löschen. Jede Clientanforderung muss vom empfangenden Knoten zum verarbeitenden Knoten weitergeleitet werden. Jeder Knoten hat einen eigenen Überblick über den Cluster, um Suchvorgänge, Indexierungen und andere koordinierte Aktivitäten durchführen zu können. Dieser Überblick wird auch als Clusterstatus bezeichnet. Der Clusterstatus bestimmt etwa die Zuordnungen und Einstellungen für die einzelnen Indizes, die zu den Knoten zugeordneten Shards und die aktuell synchronisierten Shard-Kopien. Diese Informationen müssen unbedingt im gesamten Cluster einheitlich sein. Viele der neu hinzugefügten Features, inklusive der sequenznummerbasierten Replikation und der clusterübergreifenden Replikation, funktionieren nur, weil sie sich auf die Einheitlichkeit des Clusterzustands verlassen können.

Das Koordinierungs-Teilsystem wählt einen bestimmten Knoten als Master für den Cluster aus. Dieser ausgewählte Master-Knoten sorgt dafür, dass alle Knoten in seinem Cluster die Änderungen am Clusterstatus erhalten. Diese Aufgabe ist komplexer als sie zunächst klingt, da verteilte Systeme wie Elasticsearch mit vielen seltsamen Situationen umgehen müssen. Ein Knoten kann auf einmal langsam laufen, für die Garbage Collection anhalten oder plötzlich seinen Stromanschluss verlieren. Netzwerke werden partitioniert, verlieren Pakete, leiden unter hoher Latenz oder stellen Nachrichten nicht in derselben Reihenfolge zu, in der sie verschickt wurden. Diese Probleme können parallel zueinander und periodisch auftreten. Trotzdem muss das Teilsystem für die Cluster-Koordinierung garantieren, dass jeder Knoten eine einheitliche Ansicht des Clusterstatus hat.

Dabei ist wichtig, dass Elasticsearch den Ausfall einzelner Knoten verkraften kann. Dies wird dadurch erreicht, dass Änderungen am Clusterstatus als erfolgreich gelten, nachdem sie von einem Quorum an Knoten akzeptiert wurden. Ein Quorum ist eine sorgfältig ausgewählte Teilmenge der als Master geeigneten Knoten in einem Cluster. Da nur ein Teil der Knoten antworten muss, können einige Knoten ausfallen, ohne die Verfügbarkeit des Clusters zu beeinträchtigen. Das Quorum muss sorgfältig ausgewählt werden, um zu verhindern, dass ein Cluster zwei voneinander unabhängige Master auswählt, die uneinheitliche Entscheidungen treffen, was letztendlich zu Datenverlusten führen kann.

Wir empfehlen normalerweise drei als Master geeignete Knoten pro Cluster. In diesem Fall bleiben nach einem Ausfall immer noch zwei Knoten erhalten, die ein Quorum bilden und den Betrieb fortsetzen können. Cluster mit weniger als drei als Master geeigneten Knoten können den Verlust eines Knotens nicht ohne Probleme verkraften. Wenn ein Cluster mehr als drei als Master geeignete Knoten hat, können der Auswahlvorgang und die Aktualisierungen des Clusterstatus entsprechend länger dauern.

Evolution oder Revolution?

Elasticsearch verwendete bis Version 6.x ein Teilsystem für die Cluster-Koordinierung mit dem NamenZen Discovery. Dieses Teilsystem wurde im Lauf der Jahre weiterentwickelt und ist gereift, sodass es erfolgreich für die Steuerung von großen wie kleinen Clustern eingesetzt werden kann. Einige der Änderungen, die wir vornehmen wollten, erforderten jedoch tiefgreifende Änderungen an der Funktionsweise.

In Zen Discovery können die Benutzer mit der Einstellung „discovery.zen.minimum_master_nodes“ auswählen, wie viele als Master geeignete Knoten ein Quorum bilden. Diese Einstellung muss unbedingt auf allen Knoten korrekt konfiguriert und bei einer Skalierung des Clusters korrekt angepasst werden. Das System kann nicht erkennen, ob ein Benutzer diese Einstellung falsch konfiguriert hat, und in der Praxis ist es leicht, diese Anpassung nach dem Hinzufügen oder Entfernen von Knoten zu vergessen. Zen Discovery wartet nach jeder Master-Wahl einige Sekunden, um sich vor dieser Art von Fehlkonfiguration zu schützen, und ist auch ansonsten sehr konservativ mit anderen Zeitüberschreitungen. Wenn also der gewählte Master-Knoten ausfällt, dann ist das Cluster für einige entscheidende Sekunden nicht verfügbar, bevor ein Ersatz gewählt wird. Wenn ein Cluster keinen Master wählen kann, ist es oft sehr schwierig, die Ursache dafür zu ermitteln.

Für Elasticsearch 7.0 haben wir das Teilsystem für die Cluster-Koordinierung neu erdacht und neu entwickelt:

  • Wir haben die Einstellung „minimum_master_nodes“ entfernt, und Elasticsearch wählt eigenständig aus, welche Knoten ein Quorum bilden können. 
  • Die Wahl eines Masters dauert jetzt normalerweise weniger als eine Sekunde. 
  • Skalierungsvorgänge in Clustern sind sicherer, einfacher und weniger fehleranfällig, da das Risiko für Systemkonfigurationen geringer ist, bei denen Datenverluste auftreten können. 
  • Die Knoten loggen ihren Status eindeutiger, um die Diagnose zu vereinfachen, wenn ein Knoten dem Cluster nicht beitreten oder kein Master ausgewählt werden kann.

Wenn Sie Knoten hinzufügen oder entfernen, garantiert Elasticsearch automatisch eine optimale Fehlertoleranzstufe, indem die Abstimmungskonfiguration des Clusters aktualisiert wird. Die Abstimmungskonfiguration besteht aus einer Reihe von als Master geeigneten Knoten, deren Stimme bei der Entscheidungsfindung berücksichtigt wird. Normalerweise enthält die Abstimmungskonfiguration alle als Master geeigneten Knoten im Cluster. Das Quorum ist eine einfache Mehrheit der Abstimmungskonfiguration: Alle Änderungen am Clusterstatus müssen von mehr als der Hälfte der Knoten in der Abstimmungskonfiguration bestätigt werden. Da das System die Abstimmungskonfiguration und somit auch das Quorum verwaltet, können Fehlkonfigurationen mit potenziellem Datenverlust sogar beim Hinzufügen und Entfernen von Knoten verhindert werden.

Wenn ein Knoten keinen Master-Knoten findet und selbst also keine Wahl gewinnen kann, sendet Elasticsearch ab Version 7.0 eine periodische Warnmeldung im Log, die den aktuellen Status ausreichend detailliert beschreibt, um viele der üblichen Probleme diagnostizieren zu können.

In Zen Discovery gibt es außerdem einen sehr seltenen Fehlermodus, der auf unserer Elasticsearch-Resilienzstatusseite als „Repeated network partitions can cause cluster state updates to be lost“ (Wiederholte Netzwerkpartitionierungen können dazu führen, dass Änderungen am Clusterstatus verloren gehen) beschrieben wird und in der neuen Version nicht mehr auftritt. Dieser Eintrag ist jetzt als „behoben“ markiert.

Wie verwende ich diese neue Funktion?

Wenn Sie frisch installierte Elasticsearch-Knoten mit der Standardkonfiguration starten, dann suchen diese Knoten automatisch andere Knoten auf demselben Host und bilden nach wenigen Sekunden einen Cluster. Wenn Sie weitere Knoten auf demselben Host starten, dann finden diese Knoten den Cluster ebenfalls standardmäßig und treten ihm bei. Auf diese Weise können Sie in Elasticsearch Version 7.0 ebenso einfach wie in den früheren Versionen einen Entwicklungs-Cluster mit mehreren Knoten starten.

Dieser vollautomatische Clusterbildungsmechanismus funktioniert problemlos auf einem einzigen Host, ist jedoch nicht robust genug für Produktions- oder andere verteilte Umgebungen. Es besteht das Risiko, dass die Knoten einander nicht rechtzeitig finden und stattdessen zwei oder mehr voneinander unabhängige Cluster bilden. Wenn Sie einen brandneuen Cluster starten möchten, dessen Knoten sich auf mehr als einem Host befinden, dann müssen Sie ab Version 7.0 die ursprünglichen als Master geeigneten Knoten angeben, die der Cluster als Abstimmungskonfiguration für die erste Wahl verwenden soll. Dieser Vorgang wird als Cluster-Bootstrapping bezeichnet und muss nur bei der allerersten Erstellung des Clusters ausgeführt werden. Knoten, die bereits Teil des Clusters sind, speichern die Abstimmungskonfiguration in ihren Datenordnern und verwenden sie nach einem Neustart weiter, und frisch gestartete Knoten, die einem vorhandenen Cluster beitreten, erhalten diese Informationen vom gewählten Master des Clusters.

Beim Cluster-Bootstrapping geben Sie die Namen oder IP-Adressen der ursprünglichen als Master geeigneten Knoten in der Einstellung „cluster.initial_master_nodes“ an. Sie können diese Einstellung in der Befehlszeile oder in der Datei „elasticsearch.yml“ auf einem oder mehreren der als Master geeigneten Knoten angeben. Außerdem müssen Sie das Discovery-Teilsystem konfigurieren, um den Knoten mitzuteilen, wie sie einander finden können.

Wenn „initial_master_nodes“ nicht festgelegt ist und Sie einen Knoten zum ersten Mal starten, dann erwartet dieser Knoten, ein vorhandenes Cluster finden zu können. Wenn ein Knoten kein Cluster findet, wird regelmäßig die folgende Nachricht geloggt:

master not discovered yet, this node has not previously joined a bootstrapped (v7+) cluster,
and [cluster.initial_master_nodes] is empty on this node

Beim Hinzufügen von neuen als Master geeigneten Knoten zu einem Cluster muss keine spezielle Vorgehensweise mehr beachtet werden. Konfigurieren Sie die neuen Knoten so, dass diese den vorhandenen Cluster finden, starten Sie die Knoten, und das Cluster passt seine Abstimmungskonfiguration sicher und automatisch an, wenn die neuen Knoten beitreten. Außerdem können Sie Knoten problemlos entfernen, indem Sie sie anhalten, solange Sie nicht die Hälfte oder mehr der als Master geeigneten Knoten auf einmal anhalten. Falls Sie die Hälfte oder mehr der als Master geeigneten Knoten anhalten oder andere komplexe Skalierungs- und Orchestrierungsvorgänge ausführen müssen, können Sie eine gezieltere Skalierungsprozedur mit einer API verwenden, um die Abstimmungskonfiguration direkt anzupassen.

Wie funktioniert das Upgrade?

Sie können ein Elasticsearch-Cluster mit einem rollenden Upgrade oder einem Neustart des kompletten Clusters von Version 6 auf Version 7 aktualisieren. Wir empfehlen das rollende Upgrade, da Sie die Knoten in diesem Fall einzeln aktualisieren und der Cluster die ganze Zeit über erreichbar bleibt. Sie müssen Ihr Cluster der Version 6 auf Version 6.7 aktualisieren, um ein rollendes Upgrade auf Version 7 ausführen zu können. Mit einem Neustart des kompletten Clusters können Sie beliebige 6.x-Versionen auf Version 7 aktualisieren, allerdings wird dabei der gesamte Cluster heruntergefahren und neu gestartet. Beachten Sie in beiden Fällen, dass an Elasticsearch von Version 6 zu 7 außer den hier beschriebenen Verbesserungen an der Cluster-Koordinierung noch weitere Änderungen vorgenommen wurden. Um ein reibungsloses Upgrade zu garantieren, sollten Sie die ausführlichen Upgrade-Anweisungen immer sorgfältig befolgen.

Bei einem rollenden Upgrade erfolgt das Cluster-Bootstrapping automatisch basierend auf der Anzahl der Knoten im Cluster und der eventuell vorhandenen „minimum_master_nodes“-Einstellung. Daher ist es wichtig, diese Einstellung korrekt festzulegen, bevor Sie das Upgrade starten. „initial_master_nodes“ muss in diesem Fall nicht festgelegt werden, da das Cluster-Bootstrapping beim rollenden Upgrade automatisch durchgeführt wird. Die als Master geeigneten Knoten mit Version 7 bevorzugen bei der Master-Wahl Knoten mit Version 6.7. Daher ist es normal, dass während des Upgrades ein Knoten mit Version 6.7 als Master gewählt wird, bis alle der als Master geeigneten Knoten aktualisiert wurden.

Bei einem Upgrade mit Neustart des kompletten Clusters müssen Sie das Bootstrapping für den aktualisierten Cluster wie oben beschrieben durchführen: Bevor Sie den neu aktualisierten Cluster starten, müssen Sie in „initial_master_nodes“ die Namen oder IP-Adressen der als Master geeigneten Knoten angeben.

Bis Version 6 gab es noch weitere Einstellungen, mit denen Sie das Verhalten von Zen Discovery im Namespace „discovery.zen.*“ konfigurieren konnten. Einige dieser Einstellungen haben in der neuen Version keinen Effekt mehr und wurden entfernt. Andere Einstellungen wurden umbenannt. Falls eine Einstellung umbenannt wurde, ist der alte Name in Version 7 als veraltet markiert, und Sie sollten Ihre Konfiguration anpassen, um die neuen Namen zu verwenden:

| Alter Name | Neuer Name | | --- | --- | | discovery.zen.ping.unicast.hosts | discovery.seed_hosts | | discovery.zen.hosts_provider | discovery.seed_providers | | discovery.zen.no_master_block | cluster.no_master_block |

Das neue Teilsystem für die Cluster-Koordinierung enthält einen neuen Fehlererkennungsmechanismus. Daher haben die Fehlererkennungseinstellungen für Zen Discovery im Namespace „discovery.zen.fd.“ keinen Effekt mehr. Für die meisten Benutzer empfehlen wir die standardmäßigen Fehlererkennungsmechanismen in Version 7 und aufwärts. Bei Bedarf können Sie jedoch Änderungen unter „cluster.fault_detection.“ vornehmen.

Sicherheit geht vor

In Elasticsearch-Versionen vor 7.0 war es möglich, eine Abfolge von Schritten auszuführen, die die Einheitlichkeit des Clusters in Gefahr bringen konnten. Ab Version 7.0 werden Sie darauf hingewiesen, wenn Sie eine unsichere Aktion ausführen, und müssen bestätigen, dass Sie wirklich fortfahren möchten.

Ein Elasticsearch 7.0-Cluster wird beispielsweise nicht automatisch wiederhergestellt, wenn mehr als die Hälfte der als Master geeigneten Knoten permanent verloren gehen. Die meisten Elasticsearch-Cluster enthalten drei als Master geeignete Knoten, um den Ausfall eines Knotens ohne Betriebsausfallzeit verkraften zu können. Wenn zwei Knoten permanent verloren gehen, kann der verbleibende Knoten den Betrieb nicht ohne Risiko fortsetzen.

Cluster mit den Elasticsearch-Versionen vor 7.0 konnten sich in dieser Situation unbemerkt wiederherstellen. Die Benutzer konnten ihren Cluster wieder online stellen, indem sie neue, leere und als Master geeignete Knoten bereitstellten, um beliebig viele verlorene Knoten zu ersetzen. Die automatische Wiederherstellung nach einem permanenten Verlust von mindestens der Hälfte der als Master geeigneten Knoten ist unsicher, da keiner der verbleibenden Knoten garantiert eine Kopie des letzten Clusterstatus enthält. Dabei können Datenverluste auftreten. Möglicherweise wurde eine Shard-Kopie aus dem synchronisierten Satz entfernt. Wenn keiner der verbleibenden Knoten davon Kenntnis hat, kann es passieren, dass diese veraltete Shard-Kopie als primäre Kopie zugeordnet wird. Diese Situation war besonders gefährlich, da die Benutzer nicht darauf hingewiesen wurden, dass sie ihr Cluster mit dieser Abfolge von Schritten in Gefahr gebracht haben. Konsistenzprobleme wurden unter Umständen erst nach Wochen oder Monaten bemerkt.

Ab Elasticsearch 7.0 gelten starke Einschränkungen für diese Art von unsicheren Aktionen. Ein Cluster bleibt eher offline, als ein solches Risiko einzugehen. Für den seltenen Fall, dass kein Backup verfügbar ist, können diese unsicheren Vorgänge weiterhin ausgeführt werden, falls keine andere Alternative verfügbar ist. Sie müssen in einigen zusätzlichen Schritten bestätigen, dass Ihnen die Risiken bekannt sind, um zu verhindern, dass Sie versehentlich eine unsichere Aktion ausführen.

Wenn Sie mindestens die Hälfte der als Master geeigneten Knoten verloren haben, sollten Sie zunächst versuchen, die verlorenen Knoten wieder online zu bringen. Wenn die Datenverzeichnisse der Knoten intakt sind, können Sie versuchen, neue Knoten mit diesen Datenverzeichnissen zu starten. In diesem Fall kann der Cluster mit dem aktuellsten Clusterstatus sicher neu gebildet werden.

Falls dies nicht möglich ist, können Sie versuchen, den Cluster mit einem aktuellen Snapshot wiederherzustellen. Dabei wird der Cluster in einem als funktionierend bekannten Zustand wiederhergestellt, allerdings gehen sämtliche Daten verloren, die seit der Erstellung des Snapshots geschrieben wurden. Anschließend können Sie die fehlenden Daten neu indexieren, da Sie den fehlenden Zeitraum kennen. Die Snapshots sind inkrementell und können daher recht häufig erstellt werden. Es ist nicht ungewöhnlich, alle 30 Minuten einen Snapshot zu erstellen, um die Menge der bei einer solchen Wiederherstellung verlorenen Daten zu minimieren.

Falls keine dieser Wiederherstellungsmethoden möglich ist, können Sie als letzten Ausweg das Tool „elasticsearch-node“ für die unsichere Wiederherstellung verwenden. Mit diesem Befehlszeilentool können Systemadministratoren unsichere Aktionen ausführen, indem sie zum Beispiel einen veralteten Master aus einer Minderheit auswählen. In Elasticsearch 7.0 müssen die Schritte, bei denen die Konsistenz gefährdet wird, sehr explizit ausgeführt werden. Auf diese Weise wird verhindert, dass Daten durch eine Abfolge von unsicheren Aktionen versehentlich verloren gehen.

Wie funktioniert die Lösung?

Falls Sie sich mit verteilten System auskennen, erkennen Sie die Cluster-Koordinierung als eines der Probleme, die mit einem verteilten Konsens gelöst werden können.  Der verteilte Konsens war noch größtenteils unerforscht, als die Entwicklung von Elasticsearch begann, aber in den letzten Jahren wurden auf diesem Gebiet große Fortschritte erzielt.

Zen Discovery hat viele Ideen des Algorithmus für den verteilten Konsens übernommen, allerdings eher auf organische Weise als durch strenge Übernahme des theoretisch beschriebenen Modells. Außerdem verwendet Zen Discovery sehr konservative Werte für Zeitüberschreitungen, was die Wiederherstellung nach einem Ausfall stark verlangsamen kann. Mit der Einführung des neuen Teilsystems für die Cluster-Koordinierung in 7.0 hatten wir die Gelegenheit, das theoretische Modell viel exakter umzusetzen.

Verteilte Koordinierung ist ein bekanntermaßen komplexes Problem. Wir haben umfangreich auf formale Methoden zurückgegriffen, um unsere Designs vorab zu validieren, und automatisierte Tools liefern umfassende Garantien im Hinblick auf Korrektheit und Sicherheit. Sie finden die formale Spezifikation des neuen Elasticsearch-Algorithmus für die Cluster-Koordinierung in unserem öffentlichen Elasticsearch-Repository für formale Modelle. Das zentrale Sicherheitsmodul des Algorithmus ist einfach und präzise, und es besteht eine direkte 1:1-Entsprechung zwischen dem formalen Modell und dem Produktionscode im Elastic-Repository.

Wenn Sie mit der Familie der Algorithmen für den verteilten Konsens vertraut sind, zu denen Paxos, Raft, Zab und Viewstamped Replication (VR) gehören, dann wird Ihnen das zentrale Sicherheitsmodul bekannt vorkommen. Es enthält ein einziges wiederbeschreibbares Register und verwendet den Begriff eines Master-Terms, der die Ballots (Wahlurnen) aus Paxos, die Terms (Wahlzeiträume) aus Raft und die Views (Ansichten) aus VR abbildet. Das zentrale Sicherheitsmodul und sein formales Modell sind außerdem für Cluster-Bootstrapping, Persistenz über Knotenneustarts hinweg und dynamische Konfigurationsänderungen zuständig. All diese Features sind wichtig, um sicherzustellen, dass sich das System in allen Situationen korrekt verhält.

Um diesen theoretisch robusten Kern herum haben wir eine Liveness-Ebene implementiert, um sicherzustellen, dass nach beliebigen Ausfällen im Cluster ein Master gewählt wird und in der Lage ist, Änderungen am Clusterstatus zu veröffentlichen, sobald das Netzwerk wiederhergestellt wurde und genügend Knoten online sind. Die Liveness-Ebene verwendet verschiedene moderne Techniken, um viele gängige Probleme zu vermeiden. Der Wahl-Scheduler ist dynamisch und passt sein Verhalten an die Netzwerksituation an, um die Anzahl der angefochtenen Wahlen zu minimieren. Nicht gewinnbare Wahlen werden mit einer Vorabwahl nach dem Beispiel von Raft unterdrückt, noch bevor sie beginnen, um Unterbrechungen durch unerwünschte Knoten zu vermeiden. Die Latenzerkennung verhindert, dass Knoten den Cluster stören können, wenn sie zu weit hinter den Master zurückfallen. Die aktive bidirektionale Fehlererkennung garantiert, dass die Knoten im Cluster immer in beide Richtungen miteinander kommunizieren können. Die meisten Änderungen am Clusterstatus werden effizient als kleine Diffs veröffentlicht, um nicht den gesamten Clusterstatus von Knoten zu Knoten kopieren zu müssen. Wenn ein Master ordnungsgemäß beendet wird, ernennt er ausdrücklich einen Nachfolger seiner Wahl, um die Ausfallzeit bei einem geplanten Failover zu minimieren, indem eine vollständige Wahl vermieden wird. Wir haben eine Testinfrastruktur entwickelt, um die Auswirkungen verschiedener pathologischer Störungen über Sekunden, Minuten oder Stunden hinweg effizient zu simulieren und sicherzustellen, dass der Cluster immer schnell wiederhergestellt wird, nachdem die Störung behoben wurde.

Warum nicht Raft?

Wir werden oft gefragt, warum wir nicht einfach einen der standardmäßigen Algorithmen für den verteilten Konsens „einstöpseln“, zum Beispiel Raft. Zu diesem Zweck gibt es eine Reihe von bekannten Algorithmen, jeweils mit eigenen Vor- und Nachteilen. Wir haben sämtliche verfügbare Literatur sorgfältig ausgewertet und uns inspirieren lassen. Eine unserer ersten Machbarkeitsstudien verwendete ein eng an Raft angelehntes Protokoll. Aus dieser Erfahrung haben wir gelernt, dass wir für die vollständige Integration mit Elasticsearch umfassende Änderungen vornehmen müssen. Viele der Standardalgorithmen schreiben außerdem Designentscheidungen vor, die im Zusammenspiel mit Elasticsearch Probleme bereiten können. Zum Beispiel:

  • Viele der Algorithmen bauen auf ein Betriebs-Log auf, während die Cluster-Koordinierung in Elasticsearch direkt auf dem eigentlichen Clusterstatus basiert. Auf diese Weise können wichtige Optimierungen wie etwa Batching (Zusammenfassen wichtiger Operationen in einem einzigen Broadcast) einfacher unterstützt werden als in einem operationsbasierten Modell.
  • Die Skalierungsmöglichkeiten sind bei vielen Algorithmen stark eingeschränkt und für viele Wartungsaufgaben sind zahlreiche Schritte erforderlich, während die Cluster-Koordinierung von Elasticsearch beliebige Konfigurationsänderungen sicher in einem einzigen Schritt vornehmen kann. Dadurch wird das umgebende System vereinfacht, da problematische Zwischenzustände vermieden werden.
  • Oft wird großer Wert auf Sicherheit gelegt, und die Algorithmen geben keine Garantie für Liveness und legen nicht fest, wie ein Cluster reagieren soll, wenn ein Knoten fehlerhaft ist. Die Integritätsprüfungen von Elasticsearch sind komplex, wurden über viele Jahre hinweg in der Praxis eingesetzt und verfeinert. Daher war es wichtig für uns, die vorhandene Funktionsweise zu erhalten. Tatsächlich war es wesentlich einfacher, die Sicherheitseigenschaften des Systems zu implementieren, als seine Liveness zu garantieren. Ein Großteil des Implementierungsaufwands befasste sich mit den Liveness-Eigenschaften des Systems.
  • Eines der Projektziele war die Möglichkeit, ein rollendes Upgrade ohne Betriebsausfallzeit von einem 6.7-Cluster mit Zen Discovery auf ein Cluster der Version 7 mit dem neuen Teilsystem für die Cluster-Koordinierung durchführen zu können. Es erschien uns nicht machbar, einen der Standardalgorithmen so anzupassen, dass diese Art von rollendem Upgrade möglich wäre.

Eine vollständige und unternehmenstaugliche Implementierung eines Algorithmus für den verteilten Konsens bedeutet erheblichen Entwicklungsaufwand und muss über den Stand der akademischen Literatur hinausgehen. Anpassungen sind in der Praxis unvermeidbar, aber die Koordinierungsprotokolle sind komplex, und jede Anpassung birgt das Risiko neuer Fehler. Aus technischer Hinsicht war es schlussendlich sinnvoll, diese Anpassungen so zu behandeln, als würden wir ein neues Protokoll entwickeln.

Zusammenfassung

Elasticsearch 7.0 wird mit einem neuen Teilsystem für die Cluster-Koordinierung ausgeliefert, das schneller, sicherer und benutzerfreundlicher ist. Das System unterstützt rollende Upgrades ohne Betriebsausfallzeit von Version 6.7 und dient als Basis für eine robuste Datenreplikation. Um das neue Teilsystem für die Cluster-Koordinierung zu testen, laden Sie die neueste 7.0-Betaversion herunter, lesen Sie die Dokumentation, probieren Sie die Lösung aus und schicken Sie uns Ihr Feedback.