A v1.8 acrescenta o módulo dr com onze novos cenários e leva o terminal CLI do Kafka para o free play.
Esta versão se concentra em algumas das arquiteturas mais difíceis do Kafka: clusters esticados, configurações multirregião, failover, MirrorMaker 2 e recuperação de desastres. Ela também acrescenta a trilha 13, com nove cenários conduzidos diretamente pelo terminal. São 20 novos cenários no total, e o currículo chega a 100 de 134.
O que há na v1.8
As topologias de cluster em si não são novas. Elas aparecem no free play desde a v1.3: primeiro os pares espelhados ativo/passivo e ativo/ativo, depois os clusters esticados de 3-DC e de 2,5-DC.
O que faltava era o currículo em torno delas. A v1.8 acrescenta onze cenários que mostram passo a passo como essas arquiteturas se comportam quando algo dá errado, por que elas falham de maneiras diferentes e o que essas falhas significam na prática.
Clusters esticados (seis cenários). Um único cluster Kafka distribuído por vários locais, onde perder um DC é um problema de replicação, e não um failover regional:
- 2-DC - uma escrita
acks=allexiste nos dois locais, por isso continua durável se qualquer um deles for perdido. - 3-DC e 2,5-DC - uma maioria de 2 de 3 votantes, ou um local testemunha, mantém as eleições de controlador funcionando após a falha de um DC. Na configuração de 2,5-DC, um observador no DC sobrevivente é promovido automaticamente para o ISR para restaurar
min.insync.replicas. - 2-DC sem testemunha - dividir um número par de votantes elimina o quórum, por isso a eleição de líder para até que a conectividade seja restaurada.
- Perder o DC líder, e uma divisão dentro de um DC - a liderança passa para o local sobrevivente; se um link dentro de um DC falha, a réplica isolada fica de fora até que a partição chegue ao seu piso de min.ISR.
Clusters espelhados (cinco cenários). Dois clusters Kafka independentes conectados pelo MirrorMaker 2, onde perder uma região significa fazer failover para outro cluster:
- Lag do mirror e RPO - corte o link de replicação, deixe o lag se acumular, faça o failover e veja exatamente quais registros não chegaram ao outro lado.
- Ativo/ativo - cada região é dona do seu próprio tópico específico da região e o espelha para o outro lado.
- Tradução de offsets - um consumidor não pode simplesmente reutilizar os seus offsets originais depois de passar para outro cluster. Os checkpoints do MM2 os traduzem, e o consumidor relê a cauda desde o checkpoint mais recente.
- Failback - traga de volta o primário original, ressincronize-o e retome a replicação no sentido original sem perder dados.
O emulador do terminal CLI do Kafka
A outra parte importante da v1.8 é uma gaveta de terminal que desliza de baixo para cima (Ctrl+`) e executa comandos da CLI do Kafka no cluster simulado.
São quinze ferramentas: 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, além de cluster-info para inspecionar a topologia à qual você está conectado no momento.
Os comandos usam as mesmas flags e a mesma saída familiar em colunas alinhadas das ferramentas reais do Kafka. Quando o simulador implementa só parte de um comando, o --help do comando informa isso.
O host em que você está logado importa. O prompt mostra o host atual, o ssh alterna entre hosts e a gaveta do terminal inclui um menu de hosts. Você também pode usar Alt+clique em um broker no canvas.
Os comandos atuam sobre o cluster associado a esse host. Em uma topologia multirregião, por exemplo, executar kafka-topics --list a partir de um broker de DR mostra o tópico remoto do MirrorMaker 2, e não o tópico de origem. O cluster-info mostra o quórum dessa região, não uma visão combinada dos dois clusters.
Você também pode apontar --bootstrap-server para um broker de outra região para consultar aquele cluster sem sair do shell atual.
Há também uma visão de sistema de arquivos do log simulado do Kafka. ls, cd, tree, du, df, cat e kafka-dump-log operam sobre os segmentos que o simulador de fato mantém para cada broker.
Os nomes dos arquivos de segmento usam offsets base, a retenção remove arquivos de segmento inteiros e, se um follower estiver limitado (throttled), dá para ver o segmento ativo dele ficando para trás em relação ao do líder.
As leituras da CLI refletem o quadro visível no momento no simulador. Se você pausar a simulação ou voltar pela linha do tempo, executar --describe inspeciona aquele ponto no tempo.
As mutações feitas pela CLI se comportam como qualquer outra ação do simulador: entram no log de ações, podem ser compartilhadas por URL e podem ser reproduzidas quadro a quadro.
O objetivo aqui é a transferência do aprendizado.
Em um incidente real, o que importa é se você consegue olhar para kafka-consumer-groups --describe e saber na hora qual coluna diz o que você precisa. Um simulador que só oferece botões consegue mostrar o conceito, mas não consegue de fato ensinar esse fluxo de trabalho.
Por que DR vem tão tarde
A recuperação de desastres reúne quase tudo o que foi apresentado antes: replicação, offsets de consumidor, quórum do controlador, retenção e tratamento de falhas.
Ela faz mais sentido quando essas peças já são familiares, e é por isso que o módulo de DR aparece tão tarde no currículo.
A v1.9 vai continuar na mesma área, com observadores e Cluster Linking.
Abra o simulador, faça o failover de um datacenter e depois abra o terminal e confira o lag você mesmo.