Спустя пару месяцев с выпуска Apache Kafka 2.7.0, Confluent анонсировал новый релиз этой платформы потоковой передачи событий, в котором, наконец, случится долгожданный отказ от Zookeeper. Читайте далее, как это облегчит жизнь администратору Kafka-кластера и разработчику распределенных приложений потоковой аналитики больших данных, а также как подготовить свою Big Data инфраструктуру к таким изменениям.
13 плюсов KIP-500 для администратора и разработчика Big Data
Уже совсем скоро, в марте 2021 года, ожидается новый релиз Apache Kafka 2.8.0 [1], главной фишкой которого будет долгожданный KIP-500 (Kafka Improvement Proposal) по отказу от Zookeeper, как обязательной части Кафка-кластера. Напомним, до сих пор Kafka использует сервис синхронизации распределенных систем Apache ZooKeeper для хранения метаданных, таких как расположение разделов и конфигурация топиков. Вопрос ухода от Зукипер был поднят еще в 2019 году, о чем мы писали здесь.
Удаление Зукипер из Kafka значительно упростит администрирование, благодаря сокращению объема настраиваемых служб и возможности развернуть контроллер и брокер в одной JVM. Кроме того, администратору Big Data кластера больше не придется [2]:
- тратить время на изучение, конфигурирование, обновление и поддержку еще одной распределенной системы;
- определять количества серверов для ансамбля Зукипер, чтобы сбалансировать емкость чтения и записи;
- обеспечивать наличие отдельной конфигурации безопасности для Зукипер, которая отличается от остальной части Kafka-кластера;
- обеспечивать совместное использование ансамбля Зукипер между приложениями Kafka и сторонними сервисами;
- настраивать таймауты брокера на Зукипер через конфигурации connection.timeout.ms и zookeeper.session.timeout.ms;
- изменять конфигурации Зукипер при добавлении новой функциональной возможности, например, для явного разрешения отдельных команд;
- периодически перезапускать ансамбль Зукипер в рамках управления исправлениями и обновлениями;
- подбирать оптимальный размер дорогих SSD-дисков для каждого сервера ZooKeeper;
- настраивать политику для очистки старых данных Зукипер через purgeInterval и autopurge.snapRetainCount;
- обеспечивать совместное использование путей к каталогам для журнала транзакций ZooKeeper и каталогов моментальных снимков (snapshot’ов).
С точки зрения разработчика Kafka-приложений при отказе новый релиз этой Big Data платформы принесет следующие преимущества [2]:
- повышение скорости обработки данных за счет того, что брокеры будут хранить метаданные локально в журнале и считывать с контроллера только последний набор изменений, аналогично тому, как потребители Kafka могут читать самый конец журнала, а не весь журнал;
- отсутствие ограничений на число разделов кластера Kafka – теперь масштабирование будет действительно бесконечным;
- устранение причины потери сообщений в случае рассинхронизации Kafka и Зукипер из-за его перезапуска или сбоя.
Администрирование кластера Kafka
Код курса
KAFKA
Ближайшая дата курса
9 декабря, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Как отказаться от Zookeeper на практике: план перехода на Apache Kafka 2.8.0
Чтобы использовать все вышеназванные и другие преимущества отказа от Zookeeper в новом релизе Apache Kafka 2.8.0, необходимо подготовиться к переходу на новую версию. Для этого нужно внести следующие изменения, настроив [3]:
- клиенты, сервисы и инструменты администрирования Kafka, о чем мы поговорим далее;
- REST Proxy API – перейти с v1 на v2 или v3;
- получить ID Кафка-кластера, что пригодится администратору в случае мониторинга, аудита, агрегирования журналов и устранения неполадок. Ранее получить идентификатора кластера можно было из Зукипер с помощью команды zookeeper-shell: zookeeper-shell zookeeper:2181 get /cluster/id. Теперь для этого придется использовать файл журнала брокера или файл metadata.properties. При отсутствии доступа к журналам брокера, можно использовать функцию descriptionCluster() в AdminClient или инструменты администрирования Кафка с включенным ведением журнала на уровне TRACE.
Настройка клиентов, сервисов и инструментов администрирование
Здесь идет речь о клиентских приложениях (потребители и продюсеры), приложения Kafka Streams и ksqlDB, сервисы платформs Confluent (Kafka Connect, Confluent Replicator, Confluent REST Proxy, Confluent Schema Registry, Confluent Control Center или Confluent Metrics Reporter), команды CLI-интерфейса. Все они нуждаются в новой конфигурации, которая указывает, как подключиться к кластеру Кафка. В старых версиях Кафка это делалось через соединение ZooKeeper. В более новых версиях появилась возможность подключаться к брокерам вместо Зукипер. Поэтому в production-развертываниях следует проверить наличие старых клиентов или сервисов, которые настроенные для подключения к Зукипер: zookeeper.connect = zookeeper: 2181.
При переходе на Кафка 2.8.0 рекомендуется выполнить аудит всех клиентских приложений и служб, чтобы заменить вышеуказанную конфигурацию для подключения к брокерам Kafka вместо Зукипер: bootstrap.servers = брокер: 9092.
Также потребуется замена в реестре схем (Schema Registry: вместо конфигурации kafkastore.connection.url = zookeeper: 2181 нужно задать kafkastore.bootstrap.servers = broker: 9092.
Аналогично, в инструментах командной строки вместо аргумента —zookeeper с информацией о подключении Зукипер, например,
kafka-themes —zookeeper zookeeper: 2181 —create —topic test1 —partitions 1 —replication-factor 1,
будет
kafka-themes —bootstrap-server broker: 9092 —create —topic test1 —partitions 1 —replication-factor 1 —command-config
В случае защищенных кластеров с использованием SSL или SASL_SSL, инструменты администрирования требуют дополнительных настроек безопасности для подключения к брокерам, в частности, аргумент —command-config, чтобы указать на файл свойств соединения AdminClient.
Краткий перечень мероприятий по отказу от Зукипер показан далее в таблице.
| Действие | С ZooKeeper | Без ZooKeeper |
| Настройка клиентов и сервисов | zookeeper.connect=zookeeper:2181 | bootstrap.servers=broker:9092 |
| Конфигурирование Schema Registry | kafkastore.connection.url=zookeeper:2181 | kafkastore.bootstrap.servers=broker:9092 |
| Настройка инструментов администрирования | kafka-topics —zookeeper zookeeper:2181 … | kafka-topics —bootstrap-server broker:9092 … —command-config <properties to connect to brokers> |
| REST Proxy API | v1 | v2 or v3 |
| Получение идентификатора Кафка-кластера (Kafka cluster ID) | zookeeper-shell zookeeper:2181 get /cluster/id | kafka-metadata-quorum or view metadata.properties or confluent cluster describe —url http://broker:8090 —output json |
Дополнительно к вышеотмеченным подготовительным мероприятиям по отказу от Зукипер, при развертывании Apache Kafka 2.8.0 администратору кластера нужно сделать следующее [3]:
- проверить конфигурации и клиентские инструменты, чтобы определить все параметры и аргументы ZooKeeper;
- определить возможные зависимости Зукипер в порядке запуска сервиса. Например, при использовании Docker, следует проверить конфигурацию depends_on, чтобы увидеть, где контейнер ZooKeeper является необходимым условием.
- Найти косвенные зависимости ZooKeeper, такие как модули Runbook, которые используют Зукипер в качестве узла перехода для выполнения команд на другом узле.
Что еще нового вас ожидает в релизе Apache Kafka 2.8.0, читайте в нашей свежей статье.
Apache Kafka для инженеров данных
Код курса
DEVKI
Ближайшая дата курса
20 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Освойте администрирование кластера Apache Kafka и инструментарий этой платформы для разработки распределенных приложений потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
