La v1.8 ajoute le module dr avec onze nouveaux scénarios et amène le terminal CLI Kafka dans le free play.

Cette version se concentre sur certaines des architectures Kafka les plus difficiles : clusters étirés, configurations multi-régions, failover, MirrorMaker 2 et reprise après sinistre. Elle ajoute aussi la piste 13, avec neuf scénarios pilotés directement depuis le terminal. Cela fait 20 nouveaux scénarios au total et porte le cursus à 100 sur 134.

Ce que contient la v1.8

Les topologies de cluster elles-mêmes ne sont pas nouvelles. Elles apparaissent dans le free play depuis la v1.3 : d’abord les paires en miroir actif/passif et actif/actif, puis les clusters étirés 3-DC et 2,5-DC.

Ce qui manquait, c’était le cursus autour d’elles. La v1.8 ajoute onze scénarios qui montrent pas à pas comment ces architectures se comportent quand les choses tournent mal, pourquoi elles tombent en panne de manières différentes, et ce que ces pannes signifient en pratique.

Clusters étirés (six scénarios). Un seul cluster Kafka réparti sur plusieurs sites, où perdre un DC est un problème de réplication plutôt qu’un failover régional :

  • 2-DC - une écriture acks=all existe dans les deux sites, elle reste donc durable si l’un ou l’autre des sites est perdu.
  • 3-DC et 2,5-DC - une majorité de 2 votants sur 3, ou un site témoin, permet aux élections de contrôleur de continuer à fonctionner après la panne d’un DC. Dans la configuration 2,5-DC, un observateur du DC survivant est automatiquement promu dans l’ISR pour rétablir min.insync.replicas.
  • 2-DC sans témoin - scinder un nombre pair de votants fait perdre le quorum, si bien que l’élection de leader s’arrête jusqu’au rétablissement de la connectivité.
  • Perte du DC leader, et coupure à l’intérieur d’un DC - le leadership passe au site survivant ; si un lien à l’intérieur d’un DC tombe, le réplica isolé décroche jusqu’à ce que la partition atteigne son plancher min.ISR.

Clusters en miroir (cinq scénarios). Deux clusters Kafka indépendants reliés par MirrorMaker 2, où perdre une région signifie basculer vers un autre cluster :

  • Lag du miroir et RPO - coupez le lien de réplication, laissez le lag s’accumuler, basculez, et voyez exactement quels enregistrements ne sont pas passés de l’autre côté.
  • Actif/actif - chaque région possède son propre topic régional et le met en miroir de l’autre côté.
  • Traduction d’offsets - un consommateur ne peut pas simplement réutiliser ses offsets d’origine après être passé sur un autre cluster. Les checkpoints de MM2 les traduisent, et le consommateur rejoue la fin du flux depuis le checkpoint le plus récent.
  • Failback - ramenez le primaire d’origine, resynchronisez-le et reprenez la réplication dans le sens d’origine sans perdre de données.

L’émulateur de terminal CLI Kafka

L’autre grande partie de la v1.8 est un tiroir de terminal qui glisse depuis le bas (Ctrl+`) et exécute des commandes CLI Kafka sur le cluster simulé.

Il y a quinze outils : 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, plus cluster-info pour inspecter la topologie à laquelle vous êtes actuellement connecté.

Les commandes utilisent les mêmes options et la même sortie familière en colonnes alignées que les vrais outils Kafka. Lorsque le simulateur n’implémente qu’une partie d’une commande, son --help le précise.

Le terminal exécutant kafka-consumer-groups --describe --group g1. La partition 0 a le consommateur c1 et un LAG de 0 ; la partition 1 n'a aucun consommateur, ce qu'indique un tiret, et un LAG de 4.
Scénario 13.1.2 : un membre a cessé de poller, donc la partition 1 n’a aucun consommateur et son lag grimpe - à lire directement dans la colonne que vous consulteriez sur un vrai cluster.

L’hôte sur lequel vous êtes connecté compte. L’invite affiche l’hôte courant, ssh permet de passer d’un hôte à l’autre, et le tiroir du terminal comporte un menu des hôtes. Vous pouvez aussi faire Alt+clic sur un broker dans le canevas.

Les commandes agissent sur le cluster associé à cet hôte. Sur une topologie multi-régions, par exemple, lancer kafka-topics --list depuis un broker DR affiche le topic distant de MirrorMaker 2 plutôt que le topic source. cluster-info affiche le quorum de cette région, pas une vue combinée des deux clusters.

Vous pouvez aussi faire pointer --bootstrap-server vers un broker d’une autre région pour interroger ce cluster sans quitter le shell courant.

Le tiroir du terminal ouvert au-dessus d'une topologie à deux régions. Sur broker-1, dans la région primaire, kafka-topics --list affiche orders, et la même commande avec --bootstrap-server broker-3:9092 affiche primary.orders. Après ssh broker-3, l'invite affiche la région dr, et cluster-info affiche le quorum et les brokers de dr. Le panneau Steps à côté montre les mêmes commandes sous forme de puces cliquables.
Scénario 13.3.1 : la même commande interroge un cluster différent selon l’endroit où vous la lancez. Les puces du panneau Steps préremplissent le terminal avec chaque commande.

Il y a aussi une vue système de fichiers du log Kafka simulé. ls, cd, tree, du, df, cat et kafka-dump-log travaillent sur les segments que le simulateur maintient réellement pour chaque broker.

Les noms de fichiers des segments reprennent les offsets de base, la rétention supprime des fichiers de segment entiers, et si un follower est bridé, vous voyez son segment actif prendre du retard sur celui du leader.

ls -lh orders-0 sur broker-1 liste trois segments d'offsets de base 0, 4 et 8. Après ssh broker-3, le même listing sur le follower ne montre que les segments 0 et 4, le segment actif 4 faisant 2.0K au lieu de 4.0K.
Scénario 13.1.3 : le leader est passé à un segment à l’offset 8, tandis que le follower bridé remplit encore le segment 4.

Les lectures CLI reflètent l’image actuellement visible dans le simulateur. Si vous mettez la simulation en pause ou remontez la frise chronologique, lancer --describe inspecte cet instant précis.

Les mutations CLI se comportent comme n’importe quelle autre action du simulateur : elles sont ajoutées au journal d’actions, peuvent être partagées par URL et rejouées image par image.

L’objectif, ici, est le transfert des apprentissages.

Lors d’un vrai incident, ce qui compte, c’est de pouvoir regarder kafka-consumer-groups --describe et savoir immédiatement quelle colonne vous dit ce dont vous avez besoin. Un simulateur qui ne vous donne que des boutons peut montrer le concept, mais il ne peut pas vraiment enseigner cette façon de travailler.

Pourquoi la reprise après sinistre arrive si tard

La reprise après sinistre rassemble presque tout ce qui a été présenté auparavant : la réplication, les offsets des consommateurs, le quorum du contrôleur, la rétention et la gestion des pannes.

Elle prend davantage de sens une fois ces éléments devenus familiers, c’est pourquoi le module DR apparaît si tard dans le cursus.

La v1.9 poursuivra dans le même domaine avec les observateurs et Cluster Linking.

Ouvrez le simulateur, faites basculer un datacenter, puis ouvrez le terminal et vérifiez le lag vous-même.