Hinweis:

Kafka- und Zookeeper-Cluster ohne Ausfallzeit migrieren

Einführung

Viele Services (Cloud-nativ oder On-Premises) verwenden Kafka-Cluster für ihre asynchronen Messaging-Anforderungen, da es sich um eine Messaging-Technologie handelt, die gut skaliert werden kann. Aufgrund von Geschäftsanforderungen kann es zu Situationen kommen, in denen Sie eine Gruppe von Knoten oder das gesamte Cluster ersetzen müssen. In diesem Tutorial wird die Migration von Kafka- und Zookeeper-Cluster auf eine neue Gruppe von Knoten ohne Ausfallzeit beschrieben.

Die Problemstellung

Warum kann es eine Herausforderung sein, einen Knoten in einem Cluster durch einen anderen zu ersetzen? Das Hinzufügen oder Entfernen eines Knotens aus einer Gruppe von Knoten hinter einem Load Balancer ist allgegenwärtig: Fügen Sie einen neuen Knoten hinzu, entfernen Sie den zu entfernenden vorhandenen Knoten, beenden Sie alle aktiven Verbindungen, fahren Sie ihn herunter, entfernen Sie ihn aus der Load Balancer-Konfiguration usw.

Die eigentliche Herausforderung liegt in der staatlichen Verwaltung mit einer Anwendung. In der Regel sind Anwendungen zustandslos und delegieren die Zustandspersistenz an ein Datenmanagementsystem, z. B. ein relationales Datenbankmanagementsystem (RDBMS). Im Gegensatz zu solchen Anwendungen verwalten sowohl Kafka als auch Zookeeper den Status lokal, d.h. die Statuspersistenz erfolgt über lokale Datenträger. Das heißt, wir können einen Knoten nicht einfach durch einen anderen ersetzen, ohne den lokalen Status des vorhandenen Knotens zu berücksichtigen.

Außerdem startet das einfache Hinzufügen eines Knotens im Falle von Kafka nicht automatisch ein Rebalancing der Workload, d.h. eine Neuverteilung von Topic-Partitionen über Broker hinweg. Der neue Knoten nimmt nur an der Workload-Freigabe für neue Themen teil, die ab diesem Zeitpunkt erstellt wurden.

Ein operatives Problem bei quorumbasierten Systemen (in diesem Fall Zookeeper) besteht darin, dass sie die Clustergröße im Voraus kennen müssen. Dies bedeutet, dass jeder Knoten über alle anderen Knoten im Cluster verfügen muss. Wenn Sie mehr als einen Knoten hinzufügen (die genaue Anzahl hängt von der vorhandenen Clustergröße ab), müssen Sie sicherstellen, dass einer der neu hinzugefügten Knoten nicht zum Leader wird. Andernfalls verlieren wir die Daten.

Ziele

Voraussetzungen

Kafka-Cluster migrieren

Das Ersetzen von Knoten im Kafka-Cluster ist relativ einfach. Fügen Sie neue Broker hinzu, und rufen Sie die Migration von Themenpartitionen auf. Sobald die Migration abgeschlossen ist, können wir den alten Broker außer Betrieb setzen. Kafka stellt admin-API für die Durchführung der Partitionsmigration bereit. Die alterPartitionReassignments fügt einem Thema zusätzliche Partitionsreplikate hinzu, wartet darauf, dass sie Mitglied von ISR werden, und tauscht dann den Partitionsleiter aus.

Sie müssen neue Themenpartitionszuweisungen zu alten Brokern deaktivieren (wenn Anwendungslogik zur Laufzeit Themen erstellt), andernfalls würde dies zu einer endlosen Schleife der Migration werden. Um dies zu erreichen, können Sie eine Variante der Themenerstellungs-API verwenden, in der wir die Partitionszuweisung selbst angeben können. Nachfolgend finden Sie einen Beispielalgorithmus.

Allgemeine Schritte für die Migration, die mit der Buchhaltung befolgt werden können (für den Neustart im Falle eines Migrationsprozesses in der Mitte gestoppt oder nicht erfolgreich).

  1. Assert old to new broker ID Zuordnung angegeben und abgeschlossen.

  2. Verwenden Sie AdminClient, um zu prüfen, ob neue Broker verfügbar sind. Wenn nicht alle verfügbar sind, Fehler auslösen und beenden.

  3. Verwenden Sie AdminClient, um zu prüfen, ob das Thema <kafka_topic_migration> im Cluster vorhanden ist.

    • Wenn Thema <kafka_topic_migration> nicht vorhanden ist, erstellen Sie es, indem Sie Replikate manuell für neue Broker zuweisen. Dieses Thema wird für die Buchhaltung von Themen verwendet, die bereits neu zugewiesen sind und migriert werden.

  4. Lesen Sie das Thema <kafka_topic_migration> von Anfang an mit einem Consumer. Jede Nachricht ist ein Themenname, der neuen Brokern neu zugewiesen wurde.

  5. Verwenden Sie AdminClient, um alle verfügbaren Themen im Cluster aufzulisten. Entfernen Sie das Thema <kafka_topic_migration> aus dieser Liste.

  6. Suchen Sie in den obigen beiden Schritten nach den Themen, die neuen Brokern zugewiesen werden sollen.

  7. Für jedes Thema:

    1. Erstellen Sie eine Karte Map<TopicPartition,Optional<NewPartitionReassignment>> reassignment = new HashMap<>();.

    2. Beschreiben Sie mit AdminClient das Thema, um die zugehörigen Partitionen zu suchen.

    3. Für jede Partition:

      1. Bereiten Sie ein NewPartitionReassignment-Objekt vor, indem Sie jede alte Replikat-ID (alte Broker-ID) durch die entsprechende neue Broker-ID ersetzen. Wenn die Broker-ID-Zuordnung nicht den Schlüssel enthält, der der Replikat-ID entspricht, protokollieren Sie eine Warnung, und verwenden Sie die aktuelle ID (wahrscheinlich ist dies der Fall, dass dieses Thema bereits migriert wurde und wir die Buchhaltung verpasst haben).

      2. Fügen Sie diesen Eintrag für die Zuordnung hinzu.

    4. Verwenden Sie AdminClient, um die Neuzuweisung durch Aufrufen der Methode alterPartitionReassignments zu initiieren.

    5. Führen Sie eine Schleife aus, um zu prüfen, ob diese Neuzuweisung abgeschlossen ist, indem Sie bei laufenden Neuzuweisungen (listPartitionReassignments) auflisten und deren Größe auf Null prüfen. Schlafen Sie zwischen jeder Schleife N Sekunden.

    6. Überprüfen Sie, ob die neuen Replikate jeder Partition mit den gewünschten Replikaten übereinstimmen.

    7. Senden Sie diesen Themennamen als Nachricht an das Thema <kafka_topic_migration>.

  8. Wiederholen Sie die Schritte 4 bis 6, wenn keine weiteren Themen zur Neuzuweisung und zum Beenden mehr vorhanden sind.

Sobald die Migration abgeschlossen ist, können wir die alten Broker außer Betrieb nehmen und die benutzerdefinierte Logik der Themenerstellung deaktivieren.

Hinweis: Bevor Sie die alten Broker außer Betrieb nehmen, stellen Sie sicher, dass alle Clients für dieses Cluster die bootstrap.servers-Konfiguration mit neuen Brokern aktualisiert haben.

Zookeeper-Cluster migrieren

Da es sich um ein Quorum-basiertes System handelt (um jede Operation zu begehen, benötigen wir mindestens ein Quorum von Stimmen) und angesichts der Wiederwahl der Anführer dazu führt, dass Schreibvorgänge gestoppt werden, ist die Zookeeper-Migration der schwierigste Teil. Es gibt ein paar Ansätze zum Ersetzen von Knoten. Ein einfacher Ansatz besteht darin, mehrere Runden des rollierenden Neustarts des gesamten Clusters auszuführen und in jeder Runde einen neuen Knoten hinzuzufügen. Dieser Ansatz ist möglicherweise aufgrund mehrerer Neustartrunden des Leader-Knotens und der Verzögerung bei der Ausführung der Gesamtmigration nicht akzeptabel.

Hinweis: Es können nicht alle neuen Knoten (als Teilnehmer) auf einmal hinzugefügt werden, da das Risiko besteht, dass ein neuer Knoten führend wird, ohne alle Daten zu synchronisieren (was zu einem Datenverlust führt).

Geben Sie nie mehr als einen Join-Server in derselben anfänglichen Konfiguration wie die Teilnehmer an. Derzeit wissen die verbindenden Server nicht, dass sie einem bestehenden Ensemble beitreten, wenn mehrere Joiner als Teilnehmer aufgeführt sind, können sie ein unabhängiges Kolleg bilden, das eine Split-Brain-Situation wie Bearbeitungsvorgänge unabhängig von Ihrem Hauptensemble schafft. Es ist in Ordnung, mehrere Joiner als Beobachter in einer anfänglichen Konfiguration aufzulisten.

In der Zookeeper-Version über 3.5.0 unterstützen wir die dynamische Neukonfiguration des Zookeeper-Ensembles. Das Flag reconfigEnabled muss auf true gesetzt werden, damit die dynamische Neukonfiguration funktioniert. Weitere Informationen finden Sie unter Dynamische Rekonfiguration des ZooKeeper-Ensembles.

Sie können neue Knoten mit der Rolle Observer mit der anfänglichen Konfiguration von Joinern hinzufügen, die aus Servern in der letzten festgeschriebenen Konfiguration bestehen. Beispiel: Wenn die Server 4 und 5 gleichzeitig zu (1, 2, 3) hinzugefügt werden, lautet die anfängliche Konfiguration von 4 (1, 2, 3, 4, 5), wobei 4 und 5 als Beobachter aufgelistet sind. Ebenso wird die Konfiguration von 5 (1, 2, 3, 4, 5) sein, wobei 4 und 5 als Beobachter aufgeführt sind.

Hinweis: Wenn Sie die Joiner als Beobachter auflisten, werden sie nicht tatsächlich zu Beobachtern. Dadurch wird nur verhindert, dass sie versehentlich ein Quorum mit anderen Joinern bilden. Stattdessen kontaktieren sie die Server in der aktuellen Konfiguration und übernehmen die letzte festgeschriebene Konfiguration (1, 2, 3), in der die Joiner fehlen. Nach der Verbindung mit dem derzeitigen Leiter werden die Schreiner zu nicht stimmberechtigten Anhängern, bis das System neu konfiguriert und dem Ensemble hinzugefügt wird (wie gewünscht als Teilnehmer oder Beobachter).

Sobald alle Knoten hochgefahren und gestartet sind, wird die Reconfig-API aufgerufen, um neue Knoten als Teilnehmer dynamisch hinzuzufügen und alte Knoten aus dem Ensemble zu entfernen. Beispiel: Verwenden der CLI.

reconfig -remove 1,2,3 -add
server.5=hostA:2111:2112;2113,6=hostB:2111:2112:participant;2113,7=
hostC:2111:2112:participant;2113*

Nach diesem Schritt können alte Knoten außer Betrieb genommen werden.

Hinweis:

Danksagungen

Weitere Lernressourcen

Lernen Sie andere Übungen auf docs.oracle.com/learn kennen, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube Channel zu. Außerdem können Sie education.oracle.com/learning-explorer besuchen, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.