La v1.8 aggiunge il modulo dr con undici nuovi scenari e porta il terminale CLI di Kafka nel free play.

Questa release si concentra su alcune delle architetture Kafka più difficili: cluster stirati, configurazioni multi-regione, failover, MirrorMaker 2 e disaster recovery. Aggiunge anche il percorso 13, con nove scenari guidati direttamente dal terminale. In totale sono 20 nuovi scenari, e il programma arriva a 100 su 134.

Cosa c’è nella v1.8

Le topologie di cluster in sé non sono nuove. Compaiono nel free play dalla v1.3: prima le coppie mirrorate attivo/passivo e attivo/attivo, poi i cluster stirati 3-DC e 2,5-DC.

Mancava il programma attorno a queste topologie. La v1.8 aggiunge undici scenari che mostrano passo dopo passo come si comportano queste architetture quando qualcosa va storto, perché si guastano in modi diversi e cosa significano in pratica quei guasti.

Cluster stirati (sei scenari). Un solo cluster Kafka distribuito su più siti, dove perdere un DC è un problema di replicazione e non un failover di regione:

  • 2-DC - una scrittura acks=all esiste in entrambi i siti, quindi resta durevole se si perde uno qualsiasi dei due.
  • 3-DC e 2,5-DC - una maggioranza di 2 votanti su 3, o un sito testimone, mantiene funzionanti le elezioni del controller dopo il guasto di un DC. Nella configurazione 2,5-DC, un observer nel DC superstite viene promosso automaticamente nell’ISR per ripristinare min.insync.replicas.
  • 2-DC senza testimone - dividere un numero pari di votanti fa perdere il quorum, quindi l’elezione del leader si ferma finché la connettività non viene ripristinata.
  • Perdere il DC del leader, e uno split dentro un DC - la leadership passa al sito superstite; se cade un collegamento dentro un DC, la replica isolata si sfila finché la partizione non raggiunge la sua soglia di min.ISR.

Cluster mirrorati (cinque scenari). Due cluster Kafka indipendenti collegati con MirrorMaker 2, dove perdere una regione significa fare failover su un altro cluster:

  • Lag del mirror e RPO - taglia il collegamento di replica, lascia accumulare il lag, fai failover e vedi esattamente quali record non sono arrivati dall’altra parte.
  • Attivo/attivo - ogni regione possiede il proprio topic specifico di regione e lo replica verso l’altro lato.
  • Traduzione degli offset - un consumer non può semplicemente riusare i suoi offset originali dopo essere passato a un altro cluster. I checkpoint di MM2 li traducono, con il consumer che rilegge la coda successiva al checkpoint più recente.
  • Failback - riporta in servizio il primario originale, risincronizzalo e riprendi la replica nella direzione originale senza perdere dati.

L’emulatore di terminale CLI di Kafka

L’altra parte importante della v1.8 è un pannello a scomparsa con il terminale, che sale dal basso (Ctrl+`) ed esegue comandi della CLI di Kafka contro il cluster simulato.

Gli strumenti sono quindici: 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, più cluster-info per ispezionare la topologia a cui sei connesso in quel momento.

I comandi usano gli stessi flag e lo stesso familiare output a colonne allineate dei veri strumenti di Kafka. Dove il simulatore implementa solo una parte di un comando, il suo --help lo dice.

Il terminale che esegue kafka-consumer-groups --describe --group g1. La partizione 0 ha il consumer c1 e LAG 0; la partizione 1 non ha consumer, indicato da un trattino, e LAG 4.
Scenario 13.1.2: un membro ha smesso di fare poll, quindi la partizione 1 non ha consumer e il suo lag sale - lo leggi direttamente nella colonna che controlleresti su un cluster reale.

L’host a cui sei collegato conta. Il prompt mostra l’host corrente, ssh ti sposta da un host all’altro e il pannello del terminale include un menu degli host. Puoi anche fare Alt+clic su un broker nel canvas.

I comandi agiscono sul cluster associato a quell’host. Su una topologia multi-regione, per esempio, eseguire kafka-topics --list da un broker DR mostra il topic remoto di MirrorMaker 2 invece del topic sorgente. cluster-info mostra il quorum di quella regione, non una vista combinata dei due cluster.

Puoi anche puntare --bootstrap-server su un broker di un’altra regione per interrogare quel cluster senza lasciare la shell corrente.

Il pannello del terminale aperto su una topologia a due regioni. Su broker-1 nella regione primaria, kafka-topics --list stampa orders, e lo stesso comando con --bootstrap-server broker-3:9092 stampa primary.orders. Dopo ssh broker-3 il prompt mostra la regione dr, e cluster-info stampa il quorum e i broker di dr. Il pannello Steps accanto mostra gli stessi comandi come chip cliccabili.
Scenario 13.3.1: lo stesso comando interroga un cluster diverso a seconda di dove lo esegui. I chip del pannello Steps precompilano il terminale con ciascun comando.

C’è anche una vista filesystem del log Kafka simulato. ls, cd, tree, du, df, cat e kafka-dump-log operano sui segmenti che il simulatore mantiene davvero per ogni broker.

I nomi dei file di segmento usano i base offset, la retention rimuove file di segmento interi e, se un follower è limitato da un throttle, puoi vedere il suo segmento attivo restare indietro rispetto a quello del leader.

ls -lh orders-0 su broker-1 elenca tre segmenti con base offset 0, 4 e 8. Dopo ssh broker-3, lo stesso elenco sul follower mostra solo i segmenti 0 e 4, con il segmento attivo 4 a 2.0K invece di 4.0K.
Scenario 13.1.3: il leader è già passato a un segmento all’offset 8, mentre il follower limitato sta ancora riempiendo il segmento 4.

Le letture della CLI riflettono il frame attualmente visibile nel simulatore. Se metti in pausa la simulazione o torni indietro sulla timeline, eseguire --describe ispeziona quel momento.

Le modifiche fatte dalla CLI si comportano come qualsiasi altra azione del simulatore: vengono aggiunte al registro delle azioni, si possono condividere tramite URL e si possono riprodurre frame per frame.

L’obiettivo qui è il trasferimento.

Durante un incidente reale conta se riesci a guardare kafka-consumer-groups --describe e capire subito quale colonna ti dice ciò che ti serve. Un simulatore che ti dà solo pulsanti può mostrare il concetto, ma non può davvero insegnare quel flusso di lavoro.

Perché il DR arriva così tardi

Il disaster recovery mette insieme quasi tutto ciò che è stato introdotto prima: replicazione, offset dei consumer, quorum del controller, retention e gestione dei guasti.

Ha più senso quando quei pezzi sono già familiari, ed è per questo che il modulo DR compare così tardi nel programma.

La v1.9 proseguirà nello stesso ambito con gli observer e Cluster Linking.

Apri il simulatore, fai il failover di un datacenter, poi apri il terminale e controlla il lag con i tuoi occhi.