Чем контроллеры Kafka в режиме KRaft отличаются от режима Zookeeper, как их настроить и чем статический кворум отличается от динамического: краткий ликбез для администратора кластера.
Брокеры и контроллеры: новые роли серверов Kafka в режиме KRaft
Поскольку уже совсем скоро, в мажорном релизе Kafka 4.0, ожидается полный отказ от Zookeeper в пользу внутреннего механизма Quorum и протокола KRaft, администраторам кластера полезно разобраться с изменением настроек в этом новом режиме. Будучи сервисом синхронизации метаданных, ZooKeeper сам отвечал за координацию и управление выбором активных контроллеров среди доступных брокеров Kafka. ZooKeeper обеспечивал выбор одного или нескольких брокеров в качестве контроллеров, которые отвечали за управление метаданными кластера, распределение партий и обработку других управляющих операций. Если текущий контроллер выходил из строя, ZooKeeper автоматически инициировал выбор нового контроллера из числа доступных брокеров. В свою очередь, каждый брокер Kafka автоматически участвовал в выборе контроллеров, которые необходимы для определения лидера раздела топика. Контроллером становился брокер, запущенный раньше остальных. Он создавал в службе ZooKeeper временный узел с названием /controller.
Таким образом, в режиме ZooKeeper каждый брокер Kafka был потенциальным кандидатом на роль контроллера и вручную это настраивать роли узлов кластера не приходилось. В режиме KRaft каждый сервер Kafka может быть настроен как контроллер (controller), брокер (broker) или быть комбинированным сервером, совмещая обе роли. Это поведение настраивается с помощью свойства process.roles.
Комбинированные серверы обычно используются только в среде разработки, поскольку в них невозможно изолировать контроллеры от остальной части системы, чтобы развернуть или масштабировать их отдельно от брокеров. Поэтому комбинированный режим не рекомендуется в критических средах развертывания.
В режиме KRaft в качестве контроллеров выбираются конкретные серверы Kafka. Это кардинальное отличие от режима ZooKeeper, где любой сервер мог стать контроллером. Серверы, выбранные в качестве контроллеров, будут участвовать в кворуме метаданных. Каждый контроллер является либо активным, либо горячим резервом для текущего активного контроллера. Администратору кластера нужно выбрать 3 или 5 серверов-контроллеров с учетом доступности, стоимости простоя и стоимости самих серверов. Для обеспечения высокой доступности большинство контроллеров из всей выборки должны быть активны. Например, при 3 контроллерах кластер может выдержать отказ 1 из них, при 5 контроллерах кластер может выдержать отказ 2 контроллеров и т.д.
Для надежной избыточности, т.е. доступности, по разумной стоимости можно использовать 3 контроллера. Более 3 контроллеров не рекомендуется в критических средах, поскольку иногда в случае частичного отказа сети кворум метаданных кластера может стать недоступным. Это ограничение будет устранено в будущем выпуске Kafka.
Все серверы в кластере Kafka обнаруживают активный контроллер с помощью свойства controller.quorum.bootstrap.servers, в значении которого должны быть перечислены все контроллеры кластера. Каждый контроллер идентифицируется с помощью сокета, т.е. хоста и порта. Например,
controller.quorum.bootstrap.servers=host1:port1,host2:port2,host3:port3
Свойство controller.quorum.bootstrap.servers должно быть задано у каждого сервера кластера Kafka, т.е. каждого контроллера, брокера и комбинированных узлов.
В конфигурации контроллера помимо явной установки роли задается идентификатор узла, список серверов-контроллеров для формирования кворума и определение слушателей для связи между контроллерами и другими компонентами системы. Это может выглядеть так:
process.roles=controller node.id=1 listeners=CONTROLLER://controller1.example.com:9093 controller.quorum.bootstrap.servers=controller1.example.com:9093,controller2.example.com:9093,controller3.example.com:9093 controller.listener.names=CONTROLLER
Статические и динамические кворумы KRaft
В режиме KRaft есть два варианта организации кворумов контроллера: статический и динамический. При использовании статического кворума в файле конфигурации для каждого брокера и контроллера надо указать идентификаторы, сокеты (хосты и порты) всех контроллеров в свойстве controller.quorum.voters. Для динамического кворума вместо этого надо установить ранее рассмотренное свойство controller.quorum.bootstrap.servers. Как уже было отмечено, в этот ключе конфигурации не обязательно надо задавать все узлы кластера: достаточно 3 или 5, чтобы все серверы могли обнаружить кворум. Это похоже на конфигурацию bootstrap.servers, используемую клиентами Kafka, т.е. приложениями-продюсерами и потребителями.
Проверить, какой вариант организации кворумов контроллера используется можно, запустив скрипт kafka-features.sh, предназначенный для управления и отображения состояния различных функций кластера Kafka: экспериментальные возможности, обновления или специфические настройки, которые можно включать или отключать по мере необходимости. Указав совет контроллера и добавив опцию describe, можно получить список и описание текущих доступных функций, их статус (включены или отключены), а также дополнительную информацию о каждой из них. Для этого в CLI-интерфейсе надо выполнить команду (при условии, что контроллер Kafka находится на локальной машине localhost и использует порт 9093 для связи):
$ bin/kafka-features.sh --bootstrap-controller localhost:9093 describe
Если в результате выполнения этой команды в поле kraft.version значение ключа FinalizedVersionLevel равно 0 или отсутствует, используется статический кворум. Если оно равно 1 или более – кворум динамический. Статическая или динамическая природа кворума определяется во время форматирования. В частности, кворум будет отформатирован как динамический, если поле controller.quorum.voters отсутствует, и версия Kafka 3.9+.
Пока невозможно преобразовать кластеры ос статическим кворумом контроллера, в кластеры с динамическим кворумом контроллера. Однако, это будет возможно в будущем. В заключение отметим, что контроллеры Kafka хранят все метаданные для кластера в памяти и на диске. Поэтому для типичного кластера достаточно 5 ГБ основной памяти и 5 ГБ дискового пространства для эффективного хранения журнала метаданных на контроллере.
Научитесь администрированию и эксплуатации Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Администрирование кластера Kafka
- Администрирование Apache Kafka в Kubernetes
- Apache Kafka для инженеров данных
Источники
