Как перевести кластер Kafka с ZooKeeper на KRaft, чтобы обеспечить управление метаданными с помощью этого протокола консенсуса: последовательность действий и настройки конфигураций.
Зачем и как переводить Apache Kafka с Zookeeper на KRaft
Напомним, протокол KRaft, который заменяет ZooKeeper для управления метаданными и консенсуса кластера Kafka, был введен еще в версии 2.8 в качестве экспериментальной функции, о чем мы писали здесь. ZooKeeper как сервис синхронизации метаданных был объявлен устаревшим в Kafka 3.5. Начиная с Kafka 3.7, процесс миграции с ZooKeeper на KRaft считается готовым к производственному использованию. В мажорном релизе 4.0 ZooKeeper вообще будет удален из этой платформы потоковой передачи событий. Ожидается, что KRaft предоставит для Kafka унифицированную, отказоустойчивую систему для управления метаданными, поддержки миллионов разделов, ускорения переключения контроллеров и оптимизации моделей безопасности. Это улучшит масштабируемость Kafka и упростит ее эксплуатацию, снижая сложность развертываний платформы потоковой передачи событий.
Поскольку KRaft становится единственным слоем метаданных в Apache Kafka 4.0 и Confluent Platform 8.0, перед обновлением необходимо выполнить миграцию, удалив Zookeeper. Миграция с ZooKeeper на KRaft выполняется с помощью серии изменений конфигурации и последовательных перезапусков:
- сначала получается существующий идентификатор кластера, чтобы можно было соответствующим образом подготовить новый кворум KRaft;
- затем готовится кворум контроллера KRaft;
- далее брокеры перенастраиваются для взаимодействия с KRaft и перезапускаются по одному;
- после перезапуска всех брокеров миграция метаданных происходит автоматически.
На этом этапе система записывает метаданные как в ZooKeeper, так и в KRaft. Этот режим двойной записи нужен, чтобы позволить безопасно вернуться к ZooKeeper, если возникнут какие-либо проблемы. Еще один раунд перенастроек и перезапусков брокеров полностью переведет кластер в режим KRaft. Один последний скользящий перезапуск контроллеров завершит миграцию.
Таким образом, процесс миграции проходит в несколько этапов. Сперва все брокеры находятся в режиме ZooKeeper с контроллером на базе ZooKeeper. Во время начальной загрузки метаданных кворум KRaft загружает метаданные из ZooKeeper, В гибридной фазе некоторые брокеры находятся в режиме ZooKeeper, а контроллер – уже в KRaft. В фазе двойной записи все брокеры работают с KRaft, но контроллер KRaft продолжает писать в ZK. После завершения миграции метаданные больше не пишутся в ZooKeeper.
Настройка конфигураций
Во время миграции кластера из ZooKeeper в KRaft изменение версии метаданных inter.broker.protocol.version не поддерживается. Попытка работать с этим во время миграции вызовет сбой кластера. Перед началом миграции необходимо обновить программное обеспечение брокеров Kafka до версии 3.8.0 и установить конфигурацию inter.broker.protocol.version на 3.8. Также рекомендуется включить ведение журнала TRACE для компонентов миграции, пока она идет. Это можно сделать, добавив следующую конфигурацию log4j в файл log4j.properties каждого контроллера KRaft:
log4j.logger.org.apache.kafka.metadata.migration=TRACE
Во время миграции рекомендуется включить логирование уровня DEBUG на контроллерах KRaft и брокерах ZooKeeper.
Кроме того, что брокеры должны быть настроены для поддержки миграции, перед началом миграции надо развернуть кворум контроллера KRaft. Контроллеры KRaft должны быть снабжены тем же идентификатором кластера, что и существующий кластер Kafka. Кворум контроллера KRaft также должен быть подготовлен с помощью последней версии metadata.version. Это делается автоматически при форматировании узла с помощью инструмента kafka-storage.sh. Помимо стандартной конфигурации KRaft, контроллеры KRaft должны будут включить поддержку миграции, а также предоставить конфигурацию подключения ZooKeeper.
Пример конфигурации контроллера KRaft, готового к миграции, может выглядеть так:
# Sample KRaft cluster controller.properties listening on 9093 process.roles=controller node.id=3000 controller.quorum.voters=3000@localhost:9093 controller.listener.names=CONTROLLER listeners=CONTROLLER://:9093 # Enable the migration zookeeper.metadata.migration.enable=true # ZooKeeper client configuration zookeeper.connect=localhost:2181 # The inter broker listener in brokers to allow KRaft controller send RPCs to brokers inter.broker.listener.name=PLAINTEXT
Значения node.id кластера KRaft должны отличаться от любого существующего брокера broker.id в Zookeeper. В режиме KRaft брокеры и контроллеры используют одно и то же пространство имен Node ID. После запуска кворума контроллера KRaft необходимо перенастроить и перезапустить брокеров. Брокеры можно перезапускать поочередно, чтобы не влиять на доступность кластера. Каждому брокеру требуется следующая конфигурация для связи с контроллерами KRaft и для включения миграции.
Пример конфигурации брокера, готового к миграции, может выглядеть так:
# Sample ZK broker server.properties listening on 9092 broker.id=0 listeners=PLAINTEXT://:9092 advertised.listeners=PLAINTEXT://localhost:9092 listener.security.protocol.map=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT # Set the IBP inter.broker.protocol.version=3.8 # Enable the migration zookeeper.metadata.migration.enable=true # ZooKeeper client configuration zookeeper.connect=localhost:2181 # KRaft controller quorum configuration controller.quorum.voters=3000@localhost:9093 controller.listener.names=CONTROLLER
После того, как последний брокер ZK будет перезапущен с необходимой конфигурацией, миграция начнется автоматически. Завершение миграции на активном контроллере будет залогировано событием с уровнем INFO. После того, как контроллер KRaft завершит миграцию метаданных, брокеры все еще будут работать в режиме ZooKeeper. Пока контроллер KRaft находится в режиме миграции, он продолжит отправлять RPC-вызовы контроллера брокерам режима ZooKeeper. Это включает RPC-вызовы, такие как UpdateMetadata и LeaderAndIsr. Чтобы перенести брокеров в KRaft, их просто нужно перенастроить как брокеров KRaft и перезапустить. Используя приведенную выше конфигурацию брокера в качестве примера, заменим на broker.id и node.id, а также добавим process.roles=broker. Идентификатор брокера/узла должен быть тем же самым при перезапуске. На этом этапе следует удалить конфигурации Zookeeper. Если у брокера настроена авторизация authorizer.class.name через ACL-списки, т.е. kafka.security.authorizer.AclAuthorizer, его надо изменить на org.apache.kafka.metadata.authorizer.StandardAuthorizer.
Таким образом, конфигурационный файл для KRaft-брокера Apache Kafka, который работает без ZooKeeper, будет выглядеть так:
# Sample KRaft broker server.properties listening on 9092 process.roles=broker node.id=0 listeners=PLAINTEXT://:9092 advertised.listeners=PLAINTEXT://localhost:9092 listener.security.protocol.map=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT # Don't set the IBP, KRaft uses "metadata.version" feature flag # inter.broker.protocol.version=3.8 # Remove the migration enabled flag # zookeeper.metadata.migration.enable=true # Remove ZooKeeper client configuration # zookeeper.connect=localhost:2181 # Keep the KRaft controller quorum configuration controller.quorum.voters=3000@localhost:9093 controller.listener.names=CONTROLLER
Каждый брокер перезапускается с конфигурацией KRaft до тех пор, пока весь кластер не будет работать в режиме KRaft. После того, как все брокеры перезапущены в режиме KRaft, последний шаг для завершения миграции — вывести контроллеры KRaft из режима миграции. Это делается путем удаления свойства zookeeper.metadata.migration.enable из каждой из их конфигураций и перезапуска их по одной за раз. После завершения миграции можно безопасно утилизировать кластер ZooKeeper, если он больше не используется для других систем, помимо Kafka. После завершения миграции вернуться в режим ZooKeeper невозможно. Во время миграции, если брокер ZooKeeper работает с несколькими каталогами журналов, любой сбой каталога приведет к отключению брокера. Брокеры с поврежденными каталогами журналов смогут мигрировать в KRaft только после восстановления каталогов.
В результате удаления свойства zookeeper.metadata.migration.enable конфигурационный файл KRaft-брокера Apache Kafka, который работает без ZooKeeper, будет выглядеть так:
# Sample KRaft cluster controller.properties listening on 9093 process.roles=controller node.id=3000 controller.quorum.voters=3000@localhost:9093 controller.listener.names=CONTROLLER listeners=CONTROLLER://:9093 # Disable the migration # zookeeper.metadata.migration.enable=true # Remove ZooKeeper client configuration # zookeeper.connect=localhost:2181
Если используется Confluent Kafka, развернутая в Kubernetes, то Confluent for Kubernetes (CFK) предоставляет автоматизированный способ управления миграцией из ZooKeeper в KRaft. Этот процесс состоит из следующих шагов:
- развертывание контроллеров KRaft с помощью пользовательских определений ресурсов CFK (CRD). Для установления кворума потребуется не менее трех реплик контроллеров KRaft.
- Настройка CRD для миграции CFK выполняет большую часть работы по настройке, включая блокировку ресурсов ZooKeeper и Kafka во время миграции. Необходимо убедиться, что веб-хуки включены для обеспечения этих блокировок.
- Выполнение миграции CFK автоматически извлекает идентификатор кластера Kafka и выполняет миграцию через свой декларативный API. После завершения миграции можно вручную удалить кластер ZooKeeper, если он больше не используется.
Confluent также предлагает набор Ansible Playbooks для автоматизации миграции в традиционных локальных или облачных средах. Автоматизированная конфигурация Ansible автоматизирует настройку контроллеров KRaft и брокеров Kafka, гарантируя их готовность к миграции. Оркестровка скользящих перезапусков брокеров и контроллеров, обеспечивает миграцию с нулевым временем простоя из ZooKeeper в KRaft. После миграции Ansible playbooks могут подтвердить успешность миграции, гарантируя, что все метаданные были переданы в новый кворум KRaft.
Освойте администрирование и эксплуатацию Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
- Администрирование Apache Kafka в Kubernetes
Источники
