Горизонтальное масштабирование кластера 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

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

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 в Москве:

• Администрирование кластера 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