Обзор Cruise Control
Архитектура
Cruise Control — инструмент, предназначенный для управления высоконагруженными кластерами Kafka или кластерами с большим количеством хостов, позволяющий оценивать состояние брокеров, а также выполнять балансировку нагрузки.
Работа с Cruise Control в ADS доступна начиная с 3.9.0.1.b1.
Интерфейс Metrics Reporter собирает через JMX метрики брокера Kafka и сохраняет их в топик, определяемый параметром metric.reporter.topic.
Монитор нагрузки (Load Monitor) собирает метрики из топика и создает модель нагрузки кластера (Cluster Load Model), используя которую, анализатор (Analyzer) генерирует предложение по оптимизации (proposal) на основе заданных пользователем целей (goals), а детектор аномалий (Anomaly Detector) выявляет аномалии, которые могут быть исправлены в процессе самовосстановления кластера.
Модель нагрузки кластера — программная модель, отражающая текущее распределение реплик кластера с гранулярностью данных о нагрузке реплик для различных ресурсов.
Пользователь может получить сгенерированное предложение, сделав запрос GET на REST API Cruise Control, и при помощи запроса POST запустить перебалансировку (rebalance) кластера Kafka. Перед запуском перебалансировки пользователь может отредактировать цели и/или настроить самовосстановление кластера при необходимости.
Исполнитель (Executor) отвечает за выполнение предложений по оптимизации, полученных от анализатора.
Обработанные монитором нагрузки метрики также передаются в подключаемое хранилище, в котором сохраняются для восстановления кластера. В ADS это специальные топики в кластере Kafka (определяемые параметрами *.metric.sample.store.topic). Когда Cruise Control будет перезапущен, он загрузит метрики из этого хранилища для заполнения монитора нагрузки.
Ниже подробно описаны компоненты Cruise Control.
Load Monitor
Для создания модели нагрузки кластера внутри монитора нагрузки используется актуальная выборка метрик (metrics sampler) в сочетании с метаданными кластера.
Метрики по всем партициям кластера Kafka назначаются специальным потокам Metric Fetcher Threads при помощи Partition Assignor, который обеспечивает:
-
одинаковое количество метрик партиций для всех потоков;
-
назначение метрик партиций одного топика одному потоку.
Потоки являются частью различных задач выборки (sampling tasks).
Существует три типа задач выборки:
-
Metric Sampling Task — задача выборки метрик.
-
Bootstrap Task — задача выборки bootstrap-метрик.
-
Linear Model Training Task — задача обучения линейной модели.
Задачи координируются при помощи модуля Metric Fetcher Manager. Он создает определенное количество потоков для выполнения каждой задачи.
Все выборки метрик организовываются при помощи модуля Metric Sample Aggregator. Каждая выборка метрик помещается в окно нагрузки (load window) в соответствии с временной меткой выборки.
Окно нагрузки — это агрегированная информация о метриках за заданный временной интервал (временное окно). Такой интервал (окно) определяется параметром partition.metrics.window.ms (broker.metrics.window.ms — для метрик брокеров Kafka).
Количество поддерживаемых окон определяется параметром num.partition.metrics.windows (num.broker.metrics.window — для метрик брокеров Kafka).
Например, если временное окно составляет 1 час, а пользователь настроил хранение 168 окон, Cruise Control будет хранить почасовую информацию о нагрузке за 7 дней.
Количество выборок в одном окне нагрузки определяется параметром metric.sampling.interval.ms.
Например, если пользователь указывает временное окно длительностью 1 час, а интервал выборки — 5 минут, каждое окно должно содержать 12 выборок метрик.
При помощи параметра min.samples.per.partition.metrics.window пользователь может определить минимальное количество выборок в каждом окне, при котором эти выборки будут включены в модель нагрузки кластера.
При запросе пользователя Metric Sample Aggregator возвращает все агрегированные данные окна нагрузки — снепшот нагрузки (workload snapshot) в монитор нагрузки в составе модели нагрузки кластера.
Analyzer
Анализатор генерирует предложения на основе заданных пользователем целей оптимизации и модели нагрузки кластера, полученной из монитора нагрузки.
Предложение — план оптимизации для перебалансировки кластера Kafka. В предложении описывается ряд действий, целью которых является улучшение использования ресурсов кластера и балансировка нагрузки между брокерами, например, перераспределение партиций и выборы лидера.
Cruise Control позволяет задавать жесткие и мягкие цели.
Жесткая цель — цель, которая должна быть достигнута. Такие цели должны быть помещены в список hard.goals.
Мягкая цель — цель, которая может быть не достигнута, если это позволяет достичь всех жестких целей.
Существует набор целей, которые пользователь может добавлять и удалять из списка goals для получения ожидаемого результат балансировки. Пользователи могут создавать свои собственные цели и добавлять их в Cruise Control.
Ниже приведено описание всех существующих целей.
| Цель | Описание |
|---|---|
BrokerSetAwareGoal |
BrokerSet — подмножество брокеров в кластере. Эта цель ограничивает перемещения реплик в пределах BrokerSet |
RackAwareGoal |
Цель, гарантирующая, что все реплики каждой партиции назначаются с учетом стойки |
RackAwareDistributionGoal |
Цель позволяет размещать несколько реплик партиции в одной стойке при условии идеально равномерного распределения реплик каждой партиции по стойкам |
ReplicaCapacityGoal |
При установке этой цели система будет пытаться сделать так, чтобы количество реплик всех брокеров в кластере было меньше заданного |
DiskCapacityGoal |
Цель, гарантирующая, что использование дисковых ресурсов будет ниже заданного порогового значения. Эта цель будет достигнута, если параметр |
NetworkInboundCapacityGoal |
Цель, гарантирующая, что объем используемой входящей сети каждым брокером меньше установленного порога. Объем задается с помощью параметра |
NetworkOutboundCapacityGoal |
Цель, гарантирующая, что объем используемой исходящей сети каждым брокером меньше установленного порога. Объем задается с помощью параметра |
CpuCapacityGoal |
Цель, гарантирующая, что загрузка CPU на каждом брокере меньше установленного порога; задается с помощью параметра |
ReplicaDistributionGoal |
При задании этой цели система будет пытаться сделать так, чтобы все брокеры в кластере имели одинаковое количество реплик |
PotentialNwOutGoal |
Цель, гарантирующая, что потенциальная выходная мощность сети (когда все реплики становятся лидерами) на каждом брокере не превысит исходящую пропускную способность сети брокера |
DiskUsageDistributionGoal |
При задании этой цели система будет пытаться сделать так, чтобы разброс использования между всеми дисками в пределах одного брокера находился в определенном диапазоне. Эта цель будет достигнута, если параметр |
NetworkInboundUsageDistributionGoal |
При задании этой цели система будет пытаться сделать так, чтобы распределение входящего сетевого трафика между всеми брокерами было равномерным |
NetworkOutboundUsageDistributionGoal |
При задании этой цели система будет пытаться сделать так, чтобы распределение исходящего сетевого трафика между всеми брокерами было равномерным |
CpuUsageDistributionGoal |
При задании этой цели система будет пытаться сделать так, чтобы дисперсия утилизации CPU между всеми брокерами была равномерной |
TopicReplicaDistributionGoal |
Цель, гарантирующая равномерное распределение реплик одного топика по всему кластеру |
LeaderReplicaDistributionGoal |
Цель, гарантирующая равномерное распределение реплик-лидеров на всех брокерах кластера |
LeaderBytesInDistributionGoal |
При задании этой цели система будет пытаться сделать так, чтобы входящий сетевой трафик на лидеров партиций в кластере был равномерным |
KafkaAssignerDiskUsageDistributionGoal |
Цель, гарантирующая назначение всех реплик каждой партиции с учетом стойки |
KafkaAssignerEvenRackAwareGoal |
При задании этой цели система будет пытаться обеспечить одинаковое количество реплик на всех брокерах в кластере |
PreferredLeaderElectionGoal |
При задании этой цели система будет пытаться сделать первую реплику в списке реплик ведущей репликой партиции для всех партиций топика |
Anomaly Detector
Детектор аномалий выявляет различные аномалии и после включения самовосстановления (при помощи параметра self.healing.enabled) инициирует попытку автоматического исправления определенных типов сбоев. Цели, используемые для самовосстановления, указываются в списке self.healing.goals.
Ниже приведено описание аномалий.
| Аномалия | Описание |
|---|---|
Broker failures |
Сбой непустого брокера или выход из кластера. Это приводит к появлению офлайн-репликаций/недореплицированных партиций. В этом случае Cruise Control отправляет уведомление, и, если включено самовосстановление для данного типа аномалии, Cruise Control запускает операцию по перемещению всех офлайн-реплик на другие работоспособные брокеры в кластере. Поскольку это может происходить и во время обычных отказов кластера, детектор аномалий предусматривает настраиваемый льготный период, прежде чем сработает уведомление и кластер будет восстановлен |
Goal violations |
Нарушается цель оптимизации. В этом случае Cruise Control отправит уведомление, и если включено самовосстановление для данного типа аномалии, Cruise Control заблаговременно попытается устранить нарушение цели, автоматически анализируя нагрузку и выполняя предложения по оптимизации |
Disk failure |
Выход из строя одного из непустых дисков. Такая аномалия связана только с брокером Kafka, работающим на диске JBOD. В этом случае Cruise Control отправит уведомление, и если включено самовосстановление для данного типа аномалии, Cruise Control запустит операцию по перемещению всех автономных реплик на другие работоспособные брокеры в кластере |
Metric anomaly |
Одна из метрик, собираемых Cruise Control, обнаруживает аномалию (например, резкое увеличение метрики времени очистки журнала). При этом Cruise Control отправляет уведомление. В настоящее время не существует стандартизированной операции самовосстановления для аномалий метрик, поскольку для разных аномалий метрик требуются разные методы устранения. Пользователь может определить собственную аномалию и операцию устранения, реализовав собственные MetricAnomaly и MetricAnomalyFinder |
Topic anomaly |
Один или несколько топиков в кластере нарушают заданные пользователем свойства (например, некоторые партиции на диске слишком велики). В этом случае Cruise Control отправит уведомление. В настоящее время не существует стандартизированной операции самовосстановления для аномалий в топиках, поскольку для разных аномалий в топиках требуются разные методы исправления. Пользователь может определить собственную аномалию и операцию исправления, реализовав собственные методы TopicAnomaly и TopicAnomalyFinder |
Executor
Исполнитель отвечает за выполнение предложений по оптимизации, полученных от анализатора. Работа исполнителя может быть прервана во время выполнения предложений. Исполнитель гарантирует, что выполнение учитывает ресурсы и не перегружает ни одного брокера. Некоторые параметры могут контролировать перемещения партиций при перебалансировке, например, num.concurrent.partition.movements.per.broker или max.num.cluster.partition.movements.
|
ПРИМЕЧАНИЕ
Для получения информации об установке, настройке и использовании Cruise Control в ADS обратитесь к статье Пример использования Cruise Control. |