v1.8 añade el módulo dr con once escenarios nuevos y lleva el terminal CLI de Kafka al free play.
Esta versión se centra en algunas de las arquitecturas de Kafka más difíciles: clústeres estirados, despliegues multirregión, failover, MirrorMaker 2 y recuperación ante desastres. También añade el itinerario 13, con nueve escenarios que se manejan directamente desde el terminal. En total son 20 escenarios nuevos, y el temario llega a 100 de 134.
Qué trae la v1.8
Las topologías de clúster en sí no son nuevas. Han ido apareciendo en el free play desde la v1.3: primero los pares replicados activo/pasivo y activo/activo, y después los clústeres estirados de 3-DC y de 2,5-DC.
Lo que faltaba era el temario a su alrededor. La v1.8 añade once escenarios que recorren cómo se comportan estas arquitecturas cuando algo sale mal, por qué fallan de maneras distintas y qué significan esos fallos en la práctica.
Clústeres estirados (seis escenarios). Un único clúster de Kafka repartido entre varios emplazamientos, donde perder un DC es un problema de replicación y no un failover regional:
- 2-DC - una escritura
acks=allexiste en ambos emplazamientos, así que sigue siendo duradera si se pierde cualquiera de los dos. - 3-DC y 2,5-DC - una mayoría de 2 de 3 votantes, o un emplazamiento testigo, mantiene funcionando las elecciones del controlador tras el fallo de un DC. En el despliegue de 2,5-DC, un observador del DC superviviente es promocionado automáticamente al ISR para restaurar
min.insync.replicas. - 2-DC sin testigo - dividir un número par de votantes hace perder el quórum, así que la elección de líder se detiene hasta que se restablece la conectividad.
- Perder el DC líder, y una partición de red dentro de un DC - el liderazgo pasa al emplazamiento superviviente; si falla un enlace dentro de un DC, la réplica aislada queda fuera hasta que la partición llega a su suelo de min.ISR.
Clústeres replicados (cinco escenarios). Dos clústeres de Kafka independientes conectados con MirrorMaker 2, donde perder una región significa hacer failover a otro clúster:
- Lag del mirror y RPO - corta el enlace de replicación, deja que se acumule lag, haz failover y comprueba exactamente qué registros no llegaron al otro lado.
- Activo/activo - cada región es dueña de su propio topic específico de región y lo replica hacia el otro lado.
- Traducción de offsets - un consumidor no puede limitarse a reutilizar sus offsets originales tras pasar a otro clúster. Los checkpoints de MM2 los traducen, y el consumidor vuelve a leer el tramo final desde el checkpoint más reciente.
- Failback - recupera el primario original, vuelve a sincronizarlo y reanuda la replicación en sentido directo sin perder datos.
El emulador de terminal CLI de Kafka
La otra gran parte de la v1.8 es un panel de terminal que se despliega desde abajo (Ctrl+`) y ejecuta comandos CLI de Kafka contra el clúster simulado.
Hay quince herramientas: 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, además de cluster-info para inspeccionar la topología a la que estás conectado en ese momento.
Los comandos usan los mismos flags y la misma salida familiar en columnas alineadas que las herramientas reales de Kafka. Cuando el simulador implementa solo una parte de un comando, el --help de ese comando lo indica.
Importa en qué host has iniciado sesión. El prompt muestra el host actual, ssh te mueve entre hosts y el panel del terminal incluye un menú de hosts. También puedes hacer Alt+clic en un broker del lienzo.
Los comandos operan contra el clúster asociado a ese host. En una topología multirregión, por ejemplo, ejecutar kafka-topics --list desde un broker de DR muestra el topic remoto de MirrorMaker 2 en lugar del topic de origen. cluster-info muestra el quórum de esa región, no una vista combinada de ambos clústeres.
También puedes apuntar --bootstrap-server a un broker de otra región para consultar ese clúster sin salir de la shell actual.
También hay una vista de sistema de archivos del log de Kafka simulado. ls, cd, tree, du, df, cat y kafka-dump-log operan sobre los segmentos que el simulador mantiene realmente para cada broker.
Los nombres de archivo de los segmentos usan offsets base, la retención elimina archivos de segmento completos, y si un follower está limitado puedes ver cómo su segmento activo se queda por detrás del del líder.
Las lecturas de la CLI reflejan el fotograma visible en ese momento en el simulador. Si pausas la simulación o retrocedes por la línea de tiempo, ejecutar --describe inspecciona ese instante.
Las mutaciones de la CLI se comportan como cualquier otra acción del simulador: se añaden al registro de acciones, se pueden compartir por URL y se pueden reproducir fotograma a fotograma.
El objetivo aquí es la transferencia.
En un incidente real, importa si puedes mirar kafka-consumer-groups --describe y saber al instante qué columna te dice lo que necesitas. Un simulador que solo te da botones puede mostrar el concepto, pero no puede enseñar de verdad ese flujo de trabajo.
Por qué la DR llega tan tarde
La recuperación ante desastres reúne casi todo lo presentado antes: replicación, offsets de consumidor, el quórum del controlador, retención y gestión de fallos.
Tiene más sentido cuando esas piezas ya te resultan familiares, y por eso el módulo de DR aparece tan tarde en el temario.
La v1.9 seguirá en la misma área con observadores y Cluster Linking.
Abre el simulador, haz failover de un centro de datos, abre después el terminal y comprueba tú mismo el lag.