В поддержку курсов по администрированию Apache Kafka, сегодня рассмотрим особенности масштабирования кластера и связанное с этим переназначение разделов. Читайте далее, чем горизонтальное масштабирование лучше вертикального, как переназначить разделы между брокерами Kafka с целью перебалансировки нагрузки и зачем ограничивать полосу пропускания для перемещения реплик между узлами кластера.
Проблемы масштабирования кластера Apache Kafka и их решения
По мере роста объема обрабатываемых данных встает вопрос о масштабировании имеющейся инфраструктуры. Например, из-за высокой нагрузки на кластер Kafka некоторые из его брокеров могут выйти из строя или слишком замедлиться. Это решается масштабированием кластера, коорое может быть 2-х видов:
- вертикальное – увеличение вычислительной мощности каждого брокера путем замены его аппаратных ресурсов;
- горизонтальное – добавление новых машин в кластер.
Первый вариант означает тщательный пересмотр конфигураций брокера для оптимального использования новой вычислительной мощности. При этом избыточное выделение вычислительных ресурсов и объемов хранения для кластера может стоить довольно дорого, особенно с учетом затрат времени. Поэтому на практике чаще применяется горизонтальное масштабирование кластера Apache Kafka, что включает следующие шаги:
- выделение новых машин с вычислительными ресурсами, подходящим объемом хранения данных и средствами их передачи по сети;
- запуск брокеров с выбранными конфигурациями и предоставленными ресурсами;
- переназначение разделов в кластере, чтобы повысить производительность кластера, перераспределив нагрузку с учетом введения новых брокеров.
Оставив за рамками этой статьи первые 2 шага, рассмотрим переназначение разделов более подробно. Топики Kafka разделены на разделы для балансировки нагрузки. Разделы хранятся на узлах кластера – брокерах. Брокеры реплицируют разделы в соответствии с конфигурацией репликации. Для каждого раздела топика один брокер избирается его лидером, а другие участвуют в репликации данных. При добавлении новых брокеров необходимо вручную переназначить разделы в кластере, чтобы равномерно распределить нагрузку между всеми узлами.
В качестве примера рассмотрим топик Kafka с 12 разделами и планом хранения для девяти брокеров. При горизонтальном масштабировании, т.е. добавлении новых брокеров, узел контроллера перенастроит хранилище разделов для разных брокеров. Изначально узел контроллера хранил раздел 0 на брокерах 3, 4 и 5, причем 4-й был лидером. После переназначения раздел 0 хранится на 1, 5 и 9 узлах с 5-м брокером в качестве лидера. Аналогично изменилось размещение и других разделов. Таким образом, при добавлении новых брокеров переназначение разделов гарантирует, что их равномерное распределение по брокерам, включая вновь добавленные узлы в рамках масштабирования кластера Kafka [1].
Как переназначить разделы топиков с kafka-reassign-partitions: практический пример
Фреймворк включает инструмент для контроля над разделами топиков – kafka-reassign-partitions. Чаще всего используется именно для переназначения разделов в следующих случаях [2]:
- изменение порядка в списке назначений разделов, чтобы контролировать дисбаланс лидеров между брокерами;
- переназначение разделов от одного брокера к другому, что актуально для расширения существующих кластеров, т.е. горизонтального масштабирования;
- переназначение разделов между каталогами журналов на одном или нескольких брокере, чтобы устранить дисбаланс нагрузки хранилища между доступными дисками.
Все это выполняется с помощью всего 2-х файлов JSON, создаваемых пользователем:
- перемещаемые топики (Topics-to-Move), с информацией, какие разделы следует рассматривать при создании плана конфигурации переназначения;
- конфигурация переназначения (Reassignment Configuration) – файл с параметрами переназначения. Когда инструмент kafka-reasssign-partitions запускается с параметром —generate, он генерирует предлагаемую конфигурацию, которую можно точно настроить и сохранить в виде файла JSON. Созданный таким образом файл представляет собой конфигурацию переназначения JSON. Для генерации плана kafka-reassign-partitions требуется файл с перемещаемыми топиками в качестве входных данных.
Рассмотрим, как это работает на практическом примере.
Администрирование кластера Kafka
Код курса
KAFKA
Ближайшая дата курса
3 апреля, 2023
Длительность обучения
24 ак.часов
Стоимость обучения
66 000 руб.
Инструмент kafka-reassign-partitions представляет собой shell-скрипт, который находится в папке bin. Он запускается командой bin/kafka-reassign-partitions.sh в командной строке. Однако перед запуском следует создать список топиков, которые необходимо перебалансировать, в виде файла JSON со следующей структурой:
{«topics»: [{«topic»: «mytopic1»},
{«topic»: «mytopic2»}],
«version»:1
}
В нашем примере переназначения разделов топика под названием test-topic это будет выглядеть так:
{
«topics»: [
{
«topic»: «test-topic»
}
],
«version»: 1
}
Сохраним это как JSON-файл под названием topics.json.
Далее необходимо определить конфигурацию переназначения тоже в виде JSON-файла со следующей структурой:
{«version»:1,
«partitions»:
[{«topic»:»mytopic1″,»partition»:3,»replicas»:[4,5],»log_dirs»:[«any»,»any»]},
{«topic»:»mytopic1″,»partition»:1,»replicas»:[5,4],»log_dirs»:[«any»,»any»]},
{«topic»:»mytopic2″,»partition»:2,»replicas»:[6,5],»log_dirs»:[«any»,»any»]}]
}
Сохраним эту конфигурацию для переназначения в виде JSON-файла plan.json.
Далее запустим инструмент kafka-reassign-partitions с командой создания плана переназначения разделов —generate. Он будет записывать текущее назначение реплики раздела и предлагаемую конфигурацию его переназначения:
bin/kafka-reassign-partitions.sh
—bootstrap-server localhost:9092
—broker-list «1,2,3,4,5,6,7,8,9»
—topics-to-move-json-file «/root/topics.json»
—generate
В результате этой команды создастся план конфигурации переназначения разделов (файл plan.json), реализовать который можно с помощью команды –execute:
bin/kafka-reassign-partitions.sh
—bootstrap-server localhost:9092
—reassignment-json-file «/root/plan.json»
—execute
Время выполнения зависит от размера топика и происходит асинхронно. Узнать о состоянии этого выполнения можно, используя команду –verify:
bin/kafka-reassign-partitions.sh
—bootstrap-server localhost:9092
—reassignment-json-file «/root/plan.json»
—verify
У этого инструмента есть свои особенности [2]:
- рекомендуется сократить объем изменений реплик для каждого экземпляра команды, например, вместо перемещения 10 реплик с помощью одной команды лучше перемещать по две за раз, чтобы сэкономить ресурсы кластера Kafka;
- kafka-reassign-partitions нельзя использовать для создания несинхронизированной реплики в ведущем разделе;
- использовать этот инструмент можно только на корректно работающих брокерах и топиках;
- не стоит откладывать перераспределение нагрузки до критического момента: если система загружена на 70%, самое время применить kafka-reassign-partitions. При достижении пределов ресурсов процесс перераспределения сильно усложняется.
- проверяя статус переназначения разделов с помощью параметра –verify, следует использовать тот же коэффициент репликации, заданный при запуске команды –execute [3].
В заключение отметим, что Kafka позволяет администратору ограничивать трафик репликации, устанавливая верхнюю границу полосы пропускания для перемещения реплик с машины на машину. Это полезно при перебалансировке кластера, начальной загрузке нового брокера, а также добавлении или удалении брокеров, ограничивая влияние этих операций с большим объемом данных на пользователей. Помимо рассмотренного инструмента kafka-reassign-partitions, регулировать трафик репликации можно также непосредственно в конфигурациях системы.
Например, при перебалансировке с помощью следующей команды, перемещение разделов будет выполняться со скоростью не более 50 Мбит/с [3]:
bin/kafka-reassign-partitions
—bootstrap-server myhost:9092
—execute
—reassignment-json-file bigger-cluster.json
—throttle 50000000
Уведомление об этом будет выведено в консоли командной строки:
The throttle limit was set to 50000000 B/s
Successfully started reassignment of partitions.
Увеличить пропускную способность этой операции переназначения разделов, чтобы ускорить перебалансировку, можно, повторно запустив команду –execute с новым значением полосы пропускания [3].
Администрирование кластера Kafka
Код курса
KAFKA
Ближайшая дата курса
3 апреля, 2023
Длительность обучения
24 ак.часов
Стоимость обучения
66 000 руб.
Другие практические тонкости администрирования и эксплуатации Apache Kafka для разработки распределенных приложений потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://abhisheksah.xyz/kafka-scaling/
- https://docs.cloudera.com/cdp-private-cloud-base/7.1.6/kafka-managing/topics/kafka-manage-cli-reassign-overview.html
- https://docs.confluent.io/platform/current/kafka/post-deployment.html