Версия сайта для слабовидящих
Спустя пару месяцев с выпуска 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
Ближайшая дата курса
14 июня, 2023
Длительность обучения
24 ак.часов
Стоимость обучения
66 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
Ближайшая дата курса
22 мая, 2023
Длительность обучения
24 ак.часов
Стоимость обучения
66 000 руб.
Освойте администрирование кластера Apache Kafka и инструментарий этой платформы для разработки распределенных приложений потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
