v1.8 bringt das Modul dr mit elf neuen Szenarien und holt das Kafka-CLI-Terminal in den Free Play.

Dieses Release konzentriert sich auf einige der schwierigeren Kafka-Architekturen: Stretched Cluster, Multi-Region-Setups, Failover, MirrorMaker 2 und Disaster Recovery. Dazu kommt Track 13 mit neun Szenarien, die direkt über das Terminal gesteuert werden. Das ergibt insgesamt 20 neue Szenarien und bringt das Curriculum auf 100 von 134.

Was in v1.8 steckt

Die Cluster-Topologien selbst sind nicht neu. Im Free Play tauchen sie schon seit v1.3 auf: zuerst die gespiegelten Active/Passive- und Active/Active-Paare, danach die 3-DC- und 2,5-DC-Stretched-Cluster.

Was fehlte, war das Curriculum drumherum. v1.8 bringt elf Szenarien, die durchgehen, wie sich diese Architekturen verhalten, wenn etwas schiefgeht, warum sie auf unterschiedliche Weise ausfallen und was diese Ausfälle in der Praxis bedeuten.

Stretched Cluster (sechs Szenarien). Ein Kafka-Cluster, verteilt über mehrere Standorte, bei dem der Verlust eines DC ein Replikationsproblem ist und kein regionales Failover:

  • 2-DC - ein acks=all-Write existiert an beiden Standorten und bleibt daher haltbar, wenn einer der beiden Standorte verloren geht.
  • 3-DC und 2,5-DC - eine 2-von-3-Mehrheit der Wähler oder ein Witness-Standort hält Controller-Wahlen nach einem DC-Ausfall funktionsfähig. Im 2,5-DC-Setup wird ein Observer im überlebenden DC automatisch in die ISR promotet, um min.insync.replicas wiederherzustellen.
  • 2-DC ohne Witness - die Aufteilung einer geraden Zahl von Wählern hebt das Quorum auf, sodass die Leader-Wahl stillsteht, bis die Verbindung wiederhergestellt ist.
  • Verlust des Leader-DC und eine Spaltung innerhalb eines DC - die Leadership wandert an den überlebenden Standort; fällt eine Verbindung innerhalb eines DC aus, scheidet das isolierte Replikat aus, bis die Partition ihre min.ISR-Untergrenze erreicht.

Gespiegelte Cluster (fünf Szenarien). Zwei unabhängige Kafka-Cluster, verbunden über MirrorMaker 2, bei denen der Verlust einer Region ein Failover auf einen anderen Cluster bedeutet:

  • Mirror-Lag und RPO - die Replikationsverbindung kappen, Lag auflaufen lassen, das Failover auslösen und genau sehen, welche Records es nicht hinübergeschafft haben.
  • Active/Active - jede Region besitzt ihr eigenes regionsspezifisches Topic und spiegelt es auf die andere Seite.
  • Offset-Übersetzung - ein Consumer kann seine ursprünglichen Offsets nach dem Wechsel auf einen anderen Cluster nicht einfach weiterverwenden. MM2-Checkpoints übersetzen sie, wobei der Consumer den Abschnitt seit dem jüngsten Checkpoint erneut abspielt.
  • Failback - den ursprünglichen Primary zurückholen, neu synchronisieren und die Replikation in Vorwärtsrichtung ohne Datenverlust wieder aufnehmen.

Der Kafka-CLI-Terminal-Emulator

Der andere große Teil von v1.8 ist ein von unten hochfahrender Terminal-Drawer (Ctrl+`), der Kafka-CLI-Befehle gegen den simulierten Cluster ausführt.

Es gibt fünfzehn Tools: kafka-topics, kafka-consumer-groups, kafka-configs, kafka-log-dirs, kafka-reassign-partitions, kafka-leader-election, kafka-get-offsets, kafka-metadata-quorum, kafka-replica-verification, kafka-server-stop, kafka-server-start, kafka-console-producer, kafka-console-consumer, kafka-transactions, dazu cluster-info, um die Topologie zu untersuchen, mit der Sie gerade verbunden sind.

Die Befehle verwenden dieselben Flags und dieselbe vertraute, in Spalten ausgerichtete Ausgabe wie die echten Kafka-Tools. Wo der Simulator einen Befehl nur teilweise implementiert, weist die --help-Ausgabe des Befehls darauf hin.

Das Terminal führt kafka-consumer-groups --describe --group g1 aus. Partition 0 hat den Consumer c1 und LAG 0; Partition 1 hat keinen Consumer, dargestellt als Strich, und LAG 4.
Szenario 13.1.2: Ein Mitglied hat aufgehört zu pollen, deshalb hat Partition 1 keinen Consumer, und ihr Lag steigt - direkt abgelesen an der Spalte, die Sie auch auf einem echten Cluster prüfen würden.

Es kommt darauf an, auf welchem Host Sie eingeloggt sind. Der Prompt zeigt den aktuellen Host, ssh wechselt zwischen Hosts, und der Terminal-Drawer enthält ein Host-Menü. Oder Sie klicken mit gedrückter Alt-Taste auf einen Broker im Canvas.

Befehle arbeiten gegen den Cluster, zu dem dieser Host gehört. Auf einer Multi-Region-Topologie zeigt zum Beispiel kafka-topics --list, ausgeführt auf einem DR-Broker, das Remote-Topic von MirrorMaker 2 statt des Quell-Topics. cluster-info zeigt das Quorum dieser Region, keine kombinierte Ansicht beider Cluster.

Sie können --bootstrap-server auch auf einen Broker in einer anderen Region richten, um diesen Cluster abzufragen, ohne die aktuelle Shell zu verlassen.

Der Terminal-Drawer, geöffnet über einer Zwei-Regionen-Topologie. Auf broker-1 in der primären Region gibt kafka-topics --list orders aus, und derselbe Befehl mit --bootstrap-server broker-3:9092 gibt primary.orders aus. Nach ssh broker-3 zeigt der Prompt die Region dr, und cluster-info gibt das Quorum und die Broker von dr aus. Das Steps-Panel daneben zeigt dieselben Befehle als anklickbare Chips.
Szenario 13.3.1: Derselbe Befehl fragt je nachdem, wo Sie ihn ausführen, einen anderen Cluster ab. Die Chips im Steps-Panel tragen den jeweiligen Befehl vorab ins Terminal ein.

Außerdem gibt es eine Dateisystem-Ansicht des simulierten Kafka-Logs. ls, cd, tree, du, df, cat und kafka-dump-log arbeiten auf den Segmenten, die der Simulator für jeden Broker tatsächlich verwaltet.

Segment-Dateinamen verwenden Basis-Offsets, die Retention entfernt ganze Segmentdateien, und wenn ein Follower gedrosselt wird, sehen Sie, wie sein aktives Segment hinter das des Leaders zurückfällt.

ls -lh orders-0 auf broker-1 listet drei Segmente mit den Basis-Offsets 0, 4 und 8. Nach ssh broker-3 zeigt dieselbe Auflistung auf dem Follower nur die Segmente 0 und 4, wobei das aktive Segment 4 bei 2.0K statt 4.0K steht.
Szenario 13.1.3: Der Leader ist bereits in ein Segment bei Offset 8 weitergerollt, während der gedrosselte Follower noch Segment 4 füllt.

CLI-Lesezugriffe spiegeln den Frame wider, der im Simulator gerade sichtbar ist. Wenn Sie die Simulation pausieren oder auf der Zeitleiste zurückspulen, untersucht ein --describe genau diesen Zeitpunkt.

CLI-Änderungen verhalten sich wie jede andere Simulator-Aktion: Jede landet im Action-Log, lässt sich per URL teilen und Frame für Frame erneut abspielen.

Das Ziel ist hier der Lerntransfer.

In einem echten Incident kommt es darauf an, ob Sie auf kafka-consumer-groups --describe schauen und sofort wissen, welche Spalte Ihnen sagt, was Sie wissen müssen. Ein Simulator, der Ihnen nur Buttons gibt, kann das Konzept zeigen, aber diesen Arbeitsablauf nicht wirklich vermitteln.

Warum DR so spät kommt

Disaster Recovery führt fast alles zusammen, was vorher eingeführt wurde: Replikation, Consumer-Offsets, das Controller-Quorum, Retention und den Umgang mit Ausfällen.

DR ergibt mehr Sinn, sobald diese Bausteine bereits vertraut sind, weshalb das DR-Modul so spät im Curriculum kommt.

v1.9 wird im selben Bereich weitermachen, mit Observern und Cluster Linking.

Öffnen Sie den Simulator, führen Sie ein Failover für ein Rechenzentrum durch, öffnen Sie dann das Terminal und prüfen Sie den Lag selbst.