Горизонтальное масштабирование кластера Apache Kafka: тонкости переназначения разделов

В поддержку курсов по администрированию 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

Ближайшая дата курса

23 ноября, 2022

Длительность обучения

24 ак.часов

Стоимость обучения

60 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

Ближайшая дата курса

23 ноября, 2022

Длительность обучения

24 ак.часов

Стоимость обучения

60 000 руб.

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

• Администрирование кластера Kafka
• Apache Kafka для разработчиков

Источники

1. https://abhisheksah.xyz/kafka-scaling/
2. https://docs.cloudera.com/cdp-private-cloud-base/7.1.6/kafka-managing/topics/kafka-manage-cli-reassign-overview.html
3. https://docs.confluent.io/platform/current/kafka/post-deployment.html