Deux packs sortent ensemble : v1.5 — Stockage et cycle de vie et v1.6 — Exploitation, contrôleur et quotas. À eux deux ils apportent au Kafka Simulator 19 nouveaux scénarios, le programme atteint 74 sur 122, et le mode libre termine l’échelle de formes de cluster commencée en v1.3.

Cette fois nous commençons par le mode libre : ce sont ces deux déblocages qu’on nous a le plus demandés.

Mode libre : l’échelle de topologies est complète

Depuis la v1.3, le bac à sable gagnait une forme de cluster par pack : d’abord actif/passif, puis actif/actif. Les deux sont deux clusters reliés par un miroir asynchrone. Les deux formes qui arrivent maintenant sont d’une autre nature : un seul cluster étiré entre datacenters, où la réplication est synchrone et où l’ISR lui-même traverse le WAN.

La différence apparaît dès que quelque chose tombe :

  • Dans une paire en miroir, perdre une région est un failover : vous promouvez l’autre côté et acceptez ce que le miroir n’avait pas encore copié.
  • Dans un cluster étiré, perdre un DC est un événement de réplication : l’ISR rétrécit, et savoir si vous pouvez encore écrire dépend uniquement de min.insync.replicas.

3-DC étiré (nouveau en v1.5)

Trois datacenters, un cluster. Le bac à sable par défaut vous donne un broker et un contrôleur dans chacun de dc-a, dc-b et dc-c, les brokers étant entrelacés pour que le placement round-robin répartisse les réplicas de chaque partition sur les trois sites. Trois partitions, donc chaque DC ouvre avec un leader naturel, et la disposition montre un leadership équilibré entre DC plutôt qu’une partition solitaire.

Il y a un quorum KRaft réparti sur les trois sites, et non un par région. Tuez un DC et vous perdez un votant sur trois ; les deux restants forment toujours une majorité et le cluster continue de décider.

2,5-DC étiré (nouveau en v1.6)

Le dernier barreau : deux datacenters de données plus un troisième site témoin qui détient une voix de contrôleur et aucune donnée.

C’est la forme MRC de Confluent. Chaque DC de données reçoit 2 réplicas synchrones et 1 observateur — RF 4 sur l’ensemble synchrone, avec min.insync.replicas à 3. Deux choses sur les observateurs :

  • Ils ne comptent pas dans l’ISR, donc ils ne retiennent pas une écriture acks=all. Un réplica traversant le WAN qui conditionnerait chaque commit serait un désastre de latence ; un observateur, c’est la façon de garder une copie distante sans la payer sur le chemin d’écriture.
  • Quand l’ISR passe sous min.insync.replicas, un observateur peut être promu automatiquement pour restaurer la durabilité. Par défaut le bac à sable promeut à la chute de l’ISR et rétrograde de nouveau au rétablissement du DC ; il peut aussi rester promu, ou vous coupez l’automatisme et le faites à la main.

Le témoin s’accorde directement aux scénarios de contrôleur de cette livraison. Un quorum veut un nombre impair de votants, et acheter un troisième datacenter complet pour l’obtenir coûte cher — alors vous en achetez un demi. Le scénario 06.0.2 (« quorum KRaft ») se termine exactement sur la panne que le témoin sert à empêcher ; vous pouvez désormais monter les deux configurations dans le bac à sable et les comparer.

Avec cela, les cinq formes de cluster sont disponibles : DC unique, actif/passif, actif/actif, 3-DC étiré et 2,5-DC étiré. Chaque déblocage restant du mode libre — le laboratoire de pannes en v1.7, le terminal CLI Kafka en v1.8, la gouvernance en v1.9 — est une capacité nouvelle, pas une forme nouvelle.

Même réserve qu’en v1.3 : le programme DR qui raconte ces topologies arrive toujours en v1.8. Les formes atterrissent d’abord, volontairement, pour qu’il y ait un endroit où essayer les idées avant que les scénarios ne les expliquent.

Si vous voulez en lire davantage sur les architectures multi-régions entre-temps, le guide de SoftwareMill sur la reprise après sinistre et les architectures multi-régions avec Apache Kafka traite en profondeur des arbitrages que ces formes encodent. À garder ouvert dans un autre onglet pendant que vous manipulez le bac à sable.

Les scénarios

v1.5 — Stockage et cycle de vie (9 scénarios)

Un log Kafka n’est pas une bande infinie. Ce module couvre en trois groupes ce qui arrive aux enregistrements après leur écriture.

Rétention — retention.ms et retention.bytes faisant avancer le log start offset, et ce que reçoit un consommateur qui demande un offset déjà supprimé par la rétention (OFFSET_OUT_OF_RANGE, et le reset qui suit).

Compaction — cleanup.policy=compact conservant la dernière valeur par clé, préservant les offsets et laissant des trous ; les tombstones supprimant une clé, avec delete.retention.ms comme fenêtre de grâce permettant à un consommateur de voir la suppression avant sa purge ; et compact,delete faisant tourner les deux politiques ensemble.

Stockage hiérarchisé — décharger un préfixe vieilli du log vers le niveau distant, le relire, et la différence entre rétention locale et rétention totale. C’est le groupe qui change le plus votre dimensionnement : la rétention locale cesse d’être ce qui borne jusqu’où un consommateur peut remonter.

v1.6 — le plan de contrôle (kraft, 4 scénarios)

Ce que fait le contrôleur, et ce qui s’arrête quand il n’est plus là :

  • Le rôle du contrôleur et le quorum KRaft — le contrôleur garde les métadonnées cohérentes, pas les données. Perdez la majorité du quorum et il n’y a plus de contrôleur : les leaders restent en place et plus rien de nouveau n’est décidé tant qu’un votant ne revient pas.
  • Bascule du contrôleur et rattrapage des métadonnées — un nouveau contrôleur actif doit atteindre l’offset de métadonnées validé avant de pouvoir servir, d’où le gel momentané des élections après une bascule.
  • ZooKeeper contre KRaft — le même cluster sous deux plans de contrôle, côte à côte.

v1.6 — exploitation (operations, 6 scénarios)

Ce qu’un exploitant change sur un cluster en production, et ce que chaque changement coûte :

  • Montée en charge et le rééquilibrage qui suit ; réduction, avec le drainage d’un broker avant son retrait.
  • Réaffectation de partitions à la main, et la même réaffectation bridée sous charge — où vous voyez un nouveau réplica rejoindre l’ISR en retard parce que vous avez plafonné son rattrapage pour protéger le trafic vivant.
  • Changements de configuration à chaud et quotas client bridant un producteur en retardant ses réponses plutôt qu’en jetant des données.

La suite

74 scénarios sur 122, sept packs livrés, et un bac à sable capable de modéliser toutes les formes de cluster auxquelles le reste du programme se référera. Ensuite, la v1.7 et le laboratoire de pannes : injecter des kills de brokers et des partitions réseau dans n’importe laquelle de ces cinq formes, à la demande.

Ouvrez le simulateur, démarrez un bac à sable 2,5-DC et tuez un DC de données, puis regardez un observateur être promu pour vous maintenir au-dessus de min.insync.replicas.