--- title: "Kafka Simulator v1.5 + v1.6 — Stretched Cluster, Storage und Betrieb" date: 2026-09-02T00:00:00.000Z author: "michal" excerpt: "Zwei Packs auf einmal. Free Play vollendet seine Topologie-Leiter mit dem 3-DC-Stretched- und dem 2,5-DC-Witness-Cluster, und 19 neue Szenarien decken den Lebenszyklus des Logs ab — Retention, Compaction, Tiered Storage — dazu die KRaft-Steuerungsebene und den Betrieb eines laufenden Clusters." --- Zwei Packs erscheinen gemeinsam: **v1.5 — Storage & Lebenszyklus** und **v1.6 — Betrieb, Controller & Quotas**. Zusammen bringen sie dem [Kafka Simulator](/kafka-simulator/) **19 neue Szenarien**, das Curriculum erreicht **74 von 122**, und Free Play vollendet die in v1.3 begonnene Leiter der Cluster-Formen. Diesmal beginnen wir mit Free Play — nach diesen beiden Freischaltungen wurde am häufigsten gefragt. ## Free Play: die Topologie-Leiter ist vollständig Seit v1.3 wuchs die Sandbox um eine Cluster-Form pro Pack: erst Active/Passive, dann Active/Active. Beide sind **zwei Cluster**, verbunden durch einen asynchronen Mirror. Die beiden Formen, die jetzt landen, sind von anderer Art: **ein Cluster, über Rechenzentren gespannt**, mit synchroner Replikation und einem ISR, der selbst über das WAN reicht. Der Unterschied zeigt sich in dem Moment, in dem etwas ausfällt: - Im **gespiegelten** Paar ist der Verlust einer Region ein *Failover*: du promotest die andere Seite und nimmst hin, was der Mirror noch nicht kopiert hatte. - Im **gestreckten** Cluster ist der Verlust eines DC ein *Replikationsereignis*: der ISR schrumpft, und ob du noch schreiben kannst, hängt allein an `min.insync.replicas`. ### 3-DC stretched (neu in v1.5) Drei Rechenzentren, ein Cluster. Die Standard-Sandbox gibt dir einen Broker und einen Controller in jedem von `dc-a`, `dc-b` und `dc-c`, wobei die Broker verschränkt sind, sodass die Round-Robin-Platzierung die Replikate jeder Partition über alle drei Standorte verteilt. Drei Partitionen, sodass jedes DC mit einem natürlichen Leader startet, sodass das Layout ausgewogene DC-übergreifende Leadership statt einer einsamen Partition. Es gibt **ein KRaft-Quorum, verteilt über die drei Standorte**, nicht eines pro Region. Kill ein DC und du verlierst einen von drei Wählern; die verbleibenden zwei bilden weiterhin eine Mehrheit und der Cluster trifft weiter Entscheidungen. ### 2,5-DC stretched (neu in v1.6) Die letzte Sprosse: zwei *Daten*-Rechenzentren plus ein dritter **Witness**-Standort, der eine Controller-Stimme hält und überhaupt keine Daten. Das ist die Confluent-MRC-Form. Jedes Daten-DC bekommt **2 synchrone Replikate und 1 Observer** — RF 4 über das Sync-Set, bei `min.insync.replicas` 3. Zwei Dinge zu den Observern: - Sie **zählen nicht zum ISR**, halten also einen `acks=all`-Write nicht auf. Ein WAN-Replikat, das jeden Commit gaten würde, wäre eine Latenz-Katastrophe; ein Observer ist der Weg zu einer entfernten Kopie, ohne sie auf dem Schreibpfad zu bezahlen. - Fällt der ISR unter `min.insync.replicas`, kann ein Observer **automatisch promotet** werden, um die Haltbarkeit wiederherzustellen. Die Sandbox promotet standardmäßig beim ISR-Abfall und degradiert wieder, sobald das DC zurückkehrt; alternativ bleibt er promotet, oder du schaltest die Automatik ab und machst es von Hand. Der Witness passt direkt zu den Controller-Szenarien dieses Releases. Ein Quorum will eine ungerade Zahl von Wählern, und ein drittes volles Rechenzentrum dafür zu kaufen ist teuer — also kaufst du ein halbes. Szenario 06.0.2 („KRaft-Quorum") endet mit genau dem Ausfall, den der Witness verhindern soll; jetzt kannst du beide Aufbauten in der Sandbox nachstellen und vergleichen. Damit sind **alle fünf Cluster-Formen verfügbar**: Single DC, Active/Passive, Active/Active, 3-DC stretched und 2,5-DC stretched. Jede weitere Free-Play-Freischaltung — das Failure Lab in v1.7, das Kafka-CLI-Terminal in v1.8, Governance in v1.9 — ist eine neue Fähigkeit, keine neue Form. Dieselbe Einschränkung wie bei v1.3: Das autorierte **DR-Curriculum**, das diese Topologien erklärt, landet weiterhin erst in v1.8. Die Formen kommen absichtlich zuerst, damit es einen Ort gibt, die Ideen auszuprobieren, bevor die Szenarien sie erzählen. Wer in der Zwischenzeit mehr über Multi-Region-Architekturen lesen möchte: SoftwareMills [Leitfaden zu Apache-Kafka-Disaster-Recovery und Multi-Region-Architekturen](https://softwaremill.com/guide-to-apache-kafka-disaster-recovery-and-multi-region-architectures/) behandelt die Abwägungen, die in diesen Formen stecken, gründlich. Es lohnt sich, ihn beim Spielen mit der Sandbox in einem zweiten Tab offen zu haben. ## Die Szenarien ### v1.5 — Storage & Lebenszyklus (9 Szenarien) Ein Kafka-Log ist kein unendliches Band. Dieses Modul behandelt in drei Gruppen, was mit Records nach dem Schreiben passiert. **Retention** — `retention.ms` und `retention.bytes`, die den Log Start Offset vorschieben, und was ein Consumer bekommt, der nach einem von der Retention bereits gelöschten Offset fragt (`OFFSET_OUT_OF_RANGE` und der folgende Reset). **Compaction** — `cleanup.policy=compact`, das den letzten Wert pro Key behält, Offsets bewahrt und Lücken hinterlässt; Tombstones, die einen Key löschen, mit `delete.retention.ms` als Gnadenfenster, in dem ein Consumer die Löschung noch sehen kann, bevor sie gepurged wird; und `compact,delete`, das beide Policies zusammen fährt. **Tiered Storage** — das Auslagern eines gealterten Log-Präfixes auf die Remote-Ebene, das Zurücklesen und der Unterschied zwischen *lokaler* und *gesamter* Retention. Diese Gruppe verändert die Cluster-Dimensionierung am stärksten: Die lokale Retention begrenzt nicht mehr, wie weit zurück ein Consumer lesen kann. ### v1.6 — die Steuerungsebene (`kraft`, 4 Szenarien) Was der Controller tut, und was stehen bleibt, wenn er fehlt: - **Die Aufgabe des Controllers** und das **KRaft-Quorum** — der Controller hält Metadaten konsistent, nicht Daten. Geht die Quorum-Mehrheit verloren, gibt es keinen Controller: Leader bleiben, wo sie sind, und nichts Neues wird entschieden, bis ein Wähler zurückkommt. - **Controller-Failover und Metadata-Catch-up** — ein neuer aktiver Controller muss den committeten Metadata-Offset erreichen, bevor er bedienen darf; deshalb frieren Wahlen nach einem Failover kurz ein. - **ZooKeeper vs. KRaft** — derselbe Cluster unter zwei Steuerungsebenen, nebeneinander. ### v1.6 — Betrieb (`operations`, 6 Szenarien) Was ein Operator an einem laufenden Cluster ändert, und was jede Änderung kostet: - **Scale-out** und das anschließende Rebalancing; **Scale-in**, mit dem Drainen eines Brokers vor dem Entfernen. - **Partition-Reassignment von Hand** und dasselbe Reassignment **gedrosselt unter Last** — wo du zusiehst, wie ein neues Replikat verspätet in den ISR kommt, weil du seine Aufholrate begrenzt hast, um den Live-Traffic zu schützen. - **Live-Konfigurationsänderungen** und **Client-Quotas**, die einen Producer durch verzögerte Antworten drosseln statt Daten zu verwerfen. ## Wie es weitergeht 74 von 122 Szenarien, sieben ausgelieferte Packs und eine Free-Play-Sandbox, die jetzt jede Cluster-Form modellieren kann, auf die sich der Rest des Curriculums beziehen wird. Als Nächstes v1.7 und das Failure Lab: Broker-Kills und Netzwerkpartitionen auf Zuruf in jede dieser fünf Formen injizieren. Öffne den [Simulator](/kafka-simulator/), starte eine 2,5-DC-Sandbox und kill ein Daten-DC, und sieh dann zu, wie ein Observer promotet wird, um dich über `min.insync.replicas` zu halten.