Миграция Apache Kafka с Zookeeper на KRaft

Как перевести кластер 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 выполняется с помощью серии изменений конфигурации и последовательных перезапусков:

На этом этапе система записывает метаданные как в 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:

Во время миграции рекомендуется включить логирование уровня DEBUG на контроллерах KRaft и брокерах ZooKeeper.

Кроме того, что брокеры должны быть настроены для поддержки миграции, перед началом миграции надо развернуть кворум контроллера KRaft. Контроллеры KRaft должны быть снабжены тем же идентификатором кластера, что и существующий кластер Kafka. Кворум контроллера KRaft также должен быть подготовлен с помощью последней версии metadata.version. Это делается автоматически при форматировании узла с помощью инструмента kafka-storage.sh. Помимо стандартной конфигурации KRaft, контроллеры KRaft должны будут включить поддержку миграции, а также предоставить конфигурацию подключения ZooKeeper.

Пример конфигурации контроллера KRaft, готового к миграции, может выглядеть так:

Значения node.id кластера KRaft должны отличаться от любого существующего брокера broker.id в Zookeeper. В режиме KRaft брокеры и контроллеры используют одно и то же пространство имен Node ID. После запуска кворума контроллера KRaft необходимо перенастроить и перезапустить брокеров. Брокеры можно перезапускать поочередно, чтобы не влиять на доступность кластера. Каждому брокеру требуется следующая конфигурация для связи с контроллерами KRaft и для включения миграции.

Пример конфигурации брокера, готового к миграции, может выглядеть так:

После того, как последний брокер 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, будет выглядеть так:

Каждый брокер перезапускается с конфигурацией KRaft до тех пор, пока весь кластер не будет работать в режиме KRaft. После того, как все брокеры перезапущены в режиме KRaft, последний шаг для завершения миграции — вывести контроллеры KRaft из режима миграции. Это делается путем удаления свойства zookeeper.metadata.migration.enable из каждой из их конфигураций и перезапуска их по одной за раз. После завершения миграции можно безопасно утилизировать кластер ZooKeeper, если он больше не используется для других систем, помимо Kafka. После завершения миграции вернуться в режим ZooKeeper невозможно. Во время миграции, если брокер ZooKeeper работает с несколькими каталогами журналов, любой сбой каталога приведет к отключению брокера. Брокеры с поврежденными каталогами журналов смогут мигрировать в KRaft только после восстановления каталогов.

В результате удаления свойства zookeeper.metadata.migration.enable конфигурационный файл KRaft-брокера Apache Kafka, который работает без ZooKeeper, будет выглядеть так:

Если используется Confluent Kafka, развернутая в Kubernetes, то Confluent for Kubernetes (CFK) предоставляет автоматизированный способ управления миграцией из ZooKeeper в KRaft. Этот процесс состоит из следующих шагов:

Confluent также предлагает набор Ansible Playbooks для автоматизации миграции в традиционных локальных или облачных средах. Автоматизированная конфигурация Ansible автоматизирует настройку контроллеров KRaft и брокеров Kafka, гарантируя их готовность к миграции. Оркестровка скользящих перезапусков брокеров и контроллеров, обеспечивает миграцию с нулевым временем простоя из ZooKeeper в KRaft. После миграции Ansible playbooks могут подтвердить успешность миграции, гарантируя, что все метаданные были переданы в новый кворум KRaft.

Освойте администрирование и эксплуатацию Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Статья:

Курсы:

Наш сайт:

Копирование, размножение, распространение, перепечатка (целиком или частично), или иное использование материала допускается только с письменного разрешения правообладателя ООО "УЦ Коммерсант"