Гайды
Высокая доступность Kafka: KRaft vs ZooKeeper
Репликация и rack awareness, роль ZooKeeper, режим KRaft и контроллеры, миграция и практики кластера.
~10 мин чтения
Высокая доступность Kafka: KRaft vs ZooKeeper
Высокая доступность Kafka строится на нескольких брокерах, репликации партиций и корректных настройках лидера / ISR. Исторически метаданные кластера (кто лидер какой партиции) жили в Apache ZooKeeper; с KIP-500 пришёл режим KRaft (Kafka Raft) — метаданные в самом Kafka. Термины топиков и партиций — Apache Kafka: топики, партиции и оффсеты.
1. Что даёт HA для брокеров
- Репликация фактором RF ≥ 3 для продакшена (выдержать потерю одного узла и операции обслуживания).
min.insync.replicas(ISR) — минимум реплик, которые должны подтвердить запись приacks=all.- Rack awareness (
broker.rack) — раскладка лидеров/реплик по стойкам/зонам.
2. ZooKeeper-эра (legacy)
ZooKeeper хранил:
- Список брокеров, контроллер кластера
- Назначение лидеров партиций, ACL
- Конфигурацию (частично)
Минусы: третий стек в эксплуатации (ZK кластер), масштабирование метаданных при очень большом числе партиций, отдельные апгрейды.
Новые деплои на актуальных версиях чаще целят в KRaft-only.
3. KRaft: контроллеры и quorum
В KRaft метаданные — это запись в внутренний топик __cluster_metadata (упрощённо), а контроллеры — выделенные брокеры (или роль на брокерах) с Raft-кворумом для согласованности.
Плюсы:
- Один продукт для эксплуатации
- Быстрее создание/удаление топиков на очень больших кластерах (в ряде бенчмарков)
- Упрощённый путь миграции метаданных (официальные миграции ZK → KRaft по документации версии)
Требования: версии Kafka с поддержкой production KRaft (см. матрицу для вашей 3.x).
4. Контроллер и брокер
Active controller один; остальные hot standby. При падении — выборы Raft.
Брокеры остаются точкой данных и клиентского трафика; контроллер обрабатывает metadata запросы и изменения топологии.
5. Практические рекомендации по кластеру
| Параметр / практика | Зачем |
|---|---|
| RF=3, min.insync.replicas=2 | Пережить один узел без потери commit при acks=all |
| Отдельные диски под логи | IO изоляция |
| Мониторинг offline partitions, URP | Ранний сигнал деградации |
| Регулярные rolling restart | Проверка процедур |
Подробнее по метрикам — Мониторинг Kafka.
6. Миграция ZK → KRaft
Поэтапно, с бэкапом и версией, где миграция поддержана официально. Не смешивать «полумеры» между режимами без гайда для конкретной версии.
Типичный путь: отдельный KRaft-кластер + MirrorMaker 2 / replicator для данных, либо официальная процедура ZK → KRaft для метаданных на стопроцентно совместимой версии — читайте release notes, число контроллеров держите нечётным (3 или 5) под ваш SLA.
7. Связь с клиентами
Клиентам всё равно нужен bootstrap.servers брокеров; разница ZK/KRaft не меняет wire protocol для producer/consumer, но меняет операционку и версии для админов.
8. Метаданные и диски контроллера
Контроллеры KRaft пишут metadata log на отдельные быстрые диски; не смешивайте с дисками data-папок брокера без понимания IO-профиля. Планируйте quorum из нечётного числа узлов для Raft.