v1.8 dodaje moduł dr z jedenastoma nowymi scenariuszami i wprowadza terminal CLI Kafki do free play.

To wydanie skupia się na kilku trudniejszych architekturach Kafki: klastrach rozciągniętych, układach wieloregionowych, failoverze, MirrorMaker 2 i disaster recovery. Dodaje też ścieżkę 13 z dziewięcioma scenariuszami prowadzonymi bezpośrednio z terminala. Razem daje to 20 nowych scenariuszy, a program sięga 100 ze 134.

Co jest w v1.8

Same topologie klastrów nie są nowe. Pojawiają się w free play od v1.3: najpierw mirrorowane pary active/passive i active/active, a po nich klastry rozciągnięte 3-DC i 2,5-DC.

Brakowało natomiast programu, który by je omawiał. v1.8 dodaje jedenaście scenariuszy, które pokazują, jak te architektury zachowują się, gdy coś idzie nie tak, dlaczego zawodzą na różne sposoby i co te awarie oznaczają w praktyce.

Klastry rozciągnięte (sześć scenariuszy). Jeden klaster Kafki rozłożony na kilka lokalizacji, w którym utrata DC jest problemem replikacji, a nie regionalnym failoverem:

  • 2-DC - zapis z acks=all istnieje w obu lokalizacjach, więc pozostaje trwały po utracie którejkolwiek z nich.
  • 3-DC i 2,5-DC - większość 2 z 3 wyborców albo lokalizacja witness sprawia, że wybór kontrolera nadal działa po awarii DC. W układzie 2,5-DC observer w ocalałym DC jest automatycznie awansowany do ISR, żeby przywrócić min.insync.replicas.
  • 2-DC bez witnessa - podzielenie parzystej liczby wyborców odbiera kworum, więc wybór lidera staje, dopóki łączność nie zostanie przywrócona.
  • Utrata DC lidera i podział wewnątrz jednego DC - przywództwo przechodzi do ocalałej lokalizacji; jeśli zawiedzie łącze wewnątrz DC, odizolowana replika wypada z ISR, aż partycja zejdzie do swojego progu min.ISR.

Klastry mirrorowane (pięć scenariuszy). Dwa niezależne klastry Kafki połączone przez MirrorMaker 2, w których utrata regionu oznacza failover na drugi klaster:

  • Lag mirrora i RPO - przetnij łącze replikacji, pozwól narosnąć lagowi, zrób failover i zobacz dokładnie, które rekordy nie zdążyły przejść na drugą stronę.
  • Active/active - każdy region jest właścicielem własnego, regionalnego tematu i mirroruje go na drugą stronę.
  • Translacja offsetów - konsument nie może po prostu użyć swoich pierwotnych offsetów po przejściu na inny klaster. Tłumaczą je checkpointy MM2, a konsument odtwarza ogon od ostatniego checkpointu.
  • Failback - przywróć pierwotny klaster główny, zsynchronizuj go ponownie i wznów replikację w pierwotnym kierunku bez utraty danych.

Emulator terminala CLI Kafki

Drugą dużą częścią v1.8 jest wysuwana od dołu szuflada z terminalem (Ctrl+`), która uruchamia polecenia CLI Kafki na symulowanym klastrze.

Narzędzi jest piętnaście: 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, a do tego cluster-info do podglądu topologii, z którą jesteś aktualnie połączony.

Polecenia przyjmują te same flagi i wypisują ten sam znajomy wynik w wyrównanych kolumnach co prawdziwe narzędzia Kafki. Tam, gdzie symulator implementuje tylko część polecenia, mówi o tym --help tego polecenia.

Terminal z uruchomionym kafka-consumer-groups --describe --group g1. Partycja 0 ma konsumenta c1 i LAG 0; partycja 1 nie ma konsumenta, co pokazuje kreska, i ma LAG 4.
Scenariusz 13.1.2: jeden członek grupy przestał pollować, więc partycja 1 nie ma konsumenta, a jej lag rośnie - odczytasz to wprost z kolumny, którą sprawdziłbyś na prawdziwym klastrze.

Liczy się host, na którym jesteś zalogowany. Prompt pokazuje bieżący host, ssh przenosi między hostami, a szuflada terminala ma menu hostów. Możesz też kliknąć brokera na kanwie z wciśniętym klawiszem Alt.

Polecenia działają na klastrze powiązanym z tym hostem. Na przykład w topologii wieloregionowej kafka-topics --list uruchomione z brokera DR pokazuje zdalny temat MirrorMaker 2 zamiast tematu źródłowego. cluster-info pokazuje kworum tego regionu, a nie łączny widok obu klastrów.

Możesz też skierować --bootstrap-server na brokera w innym regionie, żeby odpytać tamten klaster bez opuszczania bieżącej powłoki.

Szuflada terminala otwarta nad topologią z dwoma regionami. Na broker-1 w regionie primary kafka-topics --list wypisuje orders, a to samo polecenie z --bootstrap-server broker-3:9092 wypisuje primary.orders. Po ssh broker-3 prompt pokazuje region dr, a cluster-info wypisuje kworum i brokery regionu dr. Panel Steps obok pokazuje te same polecenia jako klikalne chipy.
Scenariusz 13.3.1: to samo polecenie odpytuje inny klaster w zależności od tego, gdzie je uruchomisz. Chipy w panelu Steps wstępnie wpisują do terminala każde z tych poleceń.

Jest też widok systemu plików symulowanego logu Kafki. ls, cd, tree, du, df, cat i kafka-dump-log działają na segmentach, które symulator faktycznie utrzymuje dla każdego brokera.

Nazwy plików segmentów to offsety bazowe, retencja usuwa całe pliki segmentów, a jeśli follower jest dławiony, widać, jak jego aktywny segment zostaje w tyle za segmentem lidera.

ls -lh orders-0 na broker-1 wypisuje trzy segmenty z offsetami bazowymi 0, 4 i 8. Po ssh broker-3 ten sam listing na followerze pokazuje tylko segmenty 0 i 4, przy czym aktywny segment 4 ma 2.0K zamiast 4.0K.
Scenariusz 13.1.3: lider przeszedł już do segmentu od offsetu 8, a dławiony follower wciąż zapełnia segment 4.

Odczyty przez CLI odzwierciedlają klatkę aktualnie widoczną w symulatorze. Jeśli wstrzymasz symulację albo cofniesz się po osi czasu, --describe zbada właśnie ten moment.

Zmiany wykonane przez CLI zachowują się jak każda inna akcja w symulatorze: trafiają do logu akcji, można je udostępnić przez URL i odtworzyć klatka po klatce.

Chodzi tu o transfer umiejętności.

Podczas prawdziwego incydentu liczy się to, czy potrafisz spojrzeć na kafka-consumer-groups --describe i od razu wiedzieć, która kolumna mówi ci to, czego potrzebujesz. Symulator, który daje ci tylko przyciski, może pokazać koncepcję, ale nie nauczy naprawdę takiego sposobu pracy.

Dlaczego DR pojawia się tak późno

Disaster recovery spina niemal wszystko, co pojawiło się wcześniej: replikację, offsety konsumentów, kworum kontrolerów, retencję i obsługę awarii.

Nabiera więcej sensu, gdy te elementy są już znajome, i dlatego moduł DR pojawia się w programie tak późno.

v1.9 pójdzie dalej w tym samym obszarze, z observerami i Cluster Linking.

Otwórz symulator, zrób failover centrum danych, a potem otwórz terminal i sam sprawdź lag.