Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Функция автоматического масштабирования Azure HDInsight позволяет автоматически увеличивать или уменьшать число рабочих узлов в кластере на основе метрик кластера и политики масштабирования, принятых клиентами. Функция автомасштабирования работает путем масштабирования числа узлов в предустановленных ограничениях на основе метрик производительности или определенного расписания операций увеличения масштаба и уменьшения масштаба.
Принцип работы
Функция автомасштабирования использует для активации событий масштабирования условия двух типов: пороговые значения для различных метрик производительности кластера (масштабирования на основе нагрузки) и триггеры на основе времени (масштабирование на основе расписания). Масштабирование на основе нагрузки изменяет количество узлов в кластере в пределах заданного диапазона с целью обеспечения оптимального использования ЦП и снижения стоимости владения. Масштабирование по расписанию изменяет количество узлов в кластере в зависимости от графика операций увеличения и уменьшения масштаба.
В следующем видео представлен обзор проблем, которые решает автомасштабирование, а также о том, как с его помощью можно управлять затратами в HDInsight.
Выбор масштабирования на основе нагрузки или на основе расписания
Можно использовать масштабирование на основе расписания:
- Когда задания должны выполняться по фиксированным расписаниям и в течение прогнозируемой длительности или когда ожидается низкое использование в определенное время суток. Например, тестовые среды и среды разработки в рабочих часах после работы, задания окончания дня.
Можно использовать масштабирование на основе нагрузки:
- Когда шаблоны нагрузки значительно и непредсказуемо изменяются в течение дня. Например, упорядочивание обработки данных с случайными колебаниями шаблонов нагрузки на основе различных факторов.
Метрики кластера
Автомасштабирование постоянно выполняет мониторинг кластера и собирает следующие метрики:
Метрика | Описание |
---|---|
Total Pending CPU (Общее число ожидающих ЦП) | Общее число ядер, необходимое для запуска выполнения всех ожидающих контейнеров. |
Total Pending Memory (Общий объем ожидающей памяти) | Общий объем памяти (в МБ), необходимый для запуска выполнения всех отложенных контейнеров. |
Total Free CPU (Общее число свободных ЦП) | Сумма всех неиспользуемых ядер на активных рабочих узлах. |
Total Free Memory (Общий объем свободной памяти) | Сумма неиспользуемой памяти (в МБ) на активных рабочих узлах. |
Used Memory per Node (Объем используемой памяти на каждом узле) | Нагрузка на рабочем узле. Рабочий узел, на котором используется 10 ГБ памяти, пребывает под большей нагрузкой, чем рабочий узел с 2 ГБ используемой памяти. |
Число управляющих приложениями на узел | Число контейнеров Application Master (AM), работающих на рабочем узле. Рабочий узел, на котором размещаются два контейнера AM, считается более важным, чем рабочий узел, на котором нет контейнеров AM. |
Эти метрики проверяются каждые 60 секунд. Автомасштабирование принимает решения об увеличении и уменьшении масштаба на основе этих метрик.
Полный список метрик кластера см. в статье "Поддерживаемые метрики для Microsoft.HDInsight/clusters".
Условия масштабирования на основе нагрузки
При обнаружении следующих условий автомасштабирование выдает запрос на масштабирование:
Масштабирование | Уменьшение масштаба |
---|---|
Общее число ожидающих ЦП больше, чем общее число свободных ЦП, в течение более чем 3-5 минут. | Общее количество ожидающих ЦП меньше общего объема свободного ЦП в течение более 3–5 минут. |
Общий объем ожидающей памяти больше, чем общий объем свободной памяти, в течение более чем 3-5 минут. | Общий объем ожидающей памяти меньше общей свободной памяти в течение более 3–5 минут. |
При увеличении масштаба функция автомасштабирования отправляет запрос на увеличение масштаба с целью добавления требуемого числа узлов. Увеличение масштаба зависит от числа новых рабочих узлов, необходимого для удовлетворения текущих требований к ЦП и памяти.
Для уменьшения количества узлов функция автоматического масштабирования инициирует запрос на их удаление. Уменьшение масштаба зависит от количества контейнеров Application Master (AM) на каждом узле. Текущие требования к процессору и памяти. Служба также определяет, какие узлы являются кандидатами на удаление в зависимости от текущего состояния выполнения задания. При операции уменьшения масштаба сначала выводятся из эксплуатации узлы, а затем они удаляются из кластера.
Рекомендации по настройке размера базы данных Ambari для автомасштабирования
Рекомендуется правильно настроить размер базы данных Ambari, чтобы получить преимущества автомасштабирования. Клиенты должны использовать правильный уровень базы данных и использовать пользовательскую базу данных Ambari для кластеров больших размеров. Ознакомьтесь с рекомендациями по размеру базы данных и headnode.
Совместимость кластера
Внимание
Функция автомасштабирования Azure HDInsight появилась в общедоступной версии от 7 ноября 2019 года для кластеров Spark и Hadoop. В эту версию включены усовершенствования, недоступные в предварительной версии этой функции. Если вы создали кластер Spark до 7 ноября 2019 г. и хотите использовать функцию автомасштабирования в кластере, рекомендуемый путь — создать новый кластер и enable Autoscale
в новом кластере.
Функция автомасштабирования для Interactive Query (LLAP) выпущена в виде общедоступной версии для HDI 4.0 27 августа 2020 г. Автомасштабирование доступно только в кластерах Spark, Hadoop и Interactive Query
Следующая таблица содержит типы и версии кластеров, совместимых с функцией автомасштабирования.
Версия | Spark | Куст | Интерактивный запрос | HBase | Kafka |
---|---|---|---|---|---|
HDInsight 4.0 без ESP | Да | Да | Да* | Нет | Нет |
HDInsight 4.0 с ESP | Да | Да | Да* | Нет | Нет |
HDInsight 5.0 без ESP | Да | Да | Да* | Нет | Нет |
HDInsight 5.0 с ESP | Да | Да | Да* | Нет | Нет |
* Кластеры Interactive Query можно настроить только для масштабирования на основе расписания. Для масштабирования на основе нагрузки их настроить нельзя.
Начало работы
Создание кластера с автомасштабированием на основе нагрузки
Чтобы включить функцию автомасштабирования с масштабированием на основе нагрузки, выполните следующие действия в рамках обычного процесса создания кластера.
На вкладке "Конфигурация + цены" установите
Enable autoscale
флажок.Выберите значение На основе нагрузки в поле Тип автомасштабирования.
Укажите требуемые значения для следующих свойств.
- Первоначальное число узлов для рабочего узла.
- Минимальное число рабочих узлов.
- Максимальное число рабочих узлов.
Начальное количество рабочих узлов должно быть в диапазоне между максимальным и минимальным количеством. Это значение определяет начальный размер кластера при его создании. В качестве минимального числа рабочих узлов следует указать три или более. Масштабирование кластера менее чем до трех узлов может привести к его зависанию в безопасном режиме вследствие недостаточной репликации файлов. Дополнительные сведения см. в разделе Зависание в безопасном режиме.
Создание кластера с автомасштабированием на основе расписания
Чтобы включить функцию автомасштабирования с масштабированием на основе расписания, выполните следующие действия в рамках обычного процесса создания кластера.
На вкладке "Конфигурация + цены" установите
Enable autoscale
флажок.Укажите число узлов для рабочего узла. Этот параметр управляет пределом увеличения масштаба кластера.
Выберите вариант На основе расписания в поле Тип автомасштабирования.
Нажмите кнопку Настройка, чтобы открыть окно Конфигурация автомасштабирования.
Выберите часовой пояс и нажмите кнопку + Добавить условие.
Выберите дни недели, к которым должно применяться новое условие.
Измените время вступления условия в силу и число узлов, до которого необходимо масштабировать кластер.
При необходимости добавьте дополнительные условия.
Число узлов должно находиться в диапазоне от 3 до максимального числа рабочих узлов, указанного перед добавлением условий.
Заключительные этапы создания
Выберите тип виртуальной машины для рабочих узлов. Для этого выберите виртуальную машину из раскрывающегося списка в поле Размер узла. После выбора типа виртуальной машины для каждого типа узла вы сможете увидеть предполагаемый диапазон затрат для всего кластера. Настройте типы виртуальных машин в соответствии с бюджетом.
Ваша подписка имеет квоту емкости для каждого региона. Общее число ядер на головных узлах и максимальное количество рабочих узлов не может превышать предельную квоту. Тем не менее эта квота — нестрогое ограничение. Вы всегда можете создать запрос в службу поддержки, чтобы легко ее повысить.
Примечание.
Если вы превысите общую квоту на ядра, вы получите сообщение о том, что максимальное число узлов превышает количество доступных ядер в регионе и нужно выбрать другой регион или обратиться в службу поддержки, чтобы увеличить квоту.
Дополнительные сведения о создании кластера HDInsight с помощью портала Azure см. в статье Создание кластеров под управлением Linux в HDInsight с помощью портала Azure.
Создание кластера с помощью шаблона Resource Manager
Автомасштабирование на основе нагрузки
Вы можете создать кластер HDInsight с автомасштабированием на основе нагрузки, используя шаблон Azure Resource Manager, добавив autoscale
узел в computeProfile
>workernode
раздел со свойствами minInstanceCount
и maxInstanceCount
, как показано в фрагменте json. Полный шаблон Resource Manager см. раздел "Шаблон быстрого старта: Развертывание кластера Spark с включенным автомасштабированием на основе нагрузки".
{
"name": "workernode",
"targetInstanceCount": 4,
"autoscale": {
"capacity": {
"minInstanceCount": 3,
"maxInstanceCount": 10
}
},
"hardwareProfile": {
"vmSize": "Standard_D13_V2"
},
"osProfile": {
"linuxOperatingSystemProfile": {
"username": "[parameters('sshUserName')]",
"password": "[parameters('sshPassword')]"
}
},
"virtualNetworkProfile": null,
"scriptActions": []
}
Автомасштабирование на основе расписания
Чтобы создать кластер HDInsight с автомасштабированием на основе расписания с помощью шаблона Azure Resource Manager, добавьте узел autoscale
в раздел computeProfile
>workernode
. Узел autoscale
содержит объект recurrence
, имеющий timezone
и schedule
, которые описывают, когда происходит изменение. Полный шаблон Resource Manager см. здесь: Развертывание кластера Spark с поддержкой автомасштабирования на основе расписания.
{
"autoscale": {
"recurrence": {
"timeZone": "Pacific Standard Time",
"schedule": [
{
"days": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"timeAndCapacity": {
"time": "11:00",
"minInstanceCount": 10,
"maxInstanceCount": 10
}
}
]
}
},
"name": "workernode",
"targetInstanceCount": 4
}
Включение и отключение автомасштабирования для работающего кластера
Использование портала Azure
Чтобы включить автомасштабирование на запущенном кластере, выберите Размер кластера в разделе Параметры. Затем выберите Enable autoscale
. Выберите требуемый тип автомасштабирования и укажите параметры масштабирования на основе нагрузки или расписания. Наконец, щелкните Сохранить.
Использование REST API
Чтобы включить или отключить автомасштабирование на запущенном кластере с помощью REST API, выполните запрос POST к конечной точке автомасштабирования:
https://management.azure.com/subscriptions/{subscription Id}/resourceGroups/{resourceGroup Name}/providers/Microsoft.HDInsight/clusters/{CLUSTERNAME}/roles/workernode/autoscale?api-version=2018-06-01-preview
Используйте в полезных данных запроса надлежащие параметры. Следующие полезные данные JSON могут быть использованы для enable Autoscale
. Используйте нагрузку {autoscale: null}
для отключения автомасштабирования.
{ "autoscale": { "capacity": { "minInstanceCount": 3, "maxInstanceCount": 5 } } }
Полное описание всех нагрузочных параметров см. в разделе выше о включении автоматического масштабирования на основе нагрузки. Не рекомендуется принудительно отключить службу автомасштабирования в работающем кластере.
Мониторинг действий автомасштабирования
Состояние кластера
Состояние кластера на портале Azure можно использовать для мониторинга действий автомасштабирования.
Все сообщения о состоянии кластера, которые могут отображаться, описаны в следующем списке.
Состояние кластера | Описание |
---|---|
Бег | Кластер работает в обычном режиме. Все предыдущие операции автомасштабирования успешно завершены. |
Обновление | Выполняется обновление конфигурации автомасштабирования кластера. |
Конфигурация HDInsight | Выполняется операция увеличения или уменьшения масштаба кластера. |
Ошибка обновления | При обновлении конфигурации автомасштабирования в HDInsight возникли проблемы. Клиенты могут либо повторить попытку обновления, либо отключить автомасштабирование. |
Ошибка | Что-то не так с кластером, и использовать его нельзя. Удалите этот кластер и создайте новый. |
Чтобы просмотреть текущее число узлов в кластере, откройте диаграмму Размер кластера на странице Обзор для кластера. Или в разделе Параметры выберите Размер кластера.
Журнал операций
Журнал операций увеличения и уменьшения масштаба кластера можно просматривать как часть метрик кластера. Кроме того, можно вывести список всех действий масштабирования за последний день, неделю или другой период времени.
В разделе Мониторинг выберите Метрики. Затем в раскрывающемся списке Метрика выберите Добавить метрику и Число активных рабочих. Нажмите кнопку в правом верхнем углу, чтобы изменить диапазон времени.
Лучшие практики
Учитывайте задержку операций масштабирования вверх и вниз.
Выполнение операции масштабирования в целом может занять от 10 до 20 минут. Запланируйте эту задержку при настройке пользовательского расписания. Например, если к 09:00 размер кластера должен составлять 20, задайте для триггера по расписанию более раннее время, например 08:30 или ранее, чтобы выполнить операцию масштабирования к 09:00.
Подготовка к уменьшению масштаба
В процессе вертикального уменьшения масштаба кластера функция автомасштабирования выводит из употребления узлы для соответствия целевому размеру. При автомасштабировании на основе нагрузки, если задачи выполняются на этих узлах, автомасштабирование ожидает завершения задач для кластеров Spark и Hadoop. Поскольку каждый рабочий узел также играет роль в HDFS, временные данные сдвигаются на оставшиеся рабочие узлы. Убедитесь в том, что на оставшихся узлах достаточно места для размещения всех временных данных.
Примечание.
В случае автоматического уменьшения масштаба на основе расписания корректное прекращение использования не поддерживается. Это может привести к сбоям заданий во время операции уменьшения масштаба, и рекомендуется планировать расписания на основе ожидаемых шаблонов расписания заданий, чтобы включить достаточно времени для завершения текущих заданий. Вы можете задать расписания с учетом диапазонов затраченного времени при выполнении предыдущих заданий, что позволит избежать сбоев заданий.
Настройка автомасштабирования на основе расписания на базе шаблона использования
При настройке автомасштабирования на основе расписания необходимо понимать схему использования кластера. Панель мониторинга Grafana поможет разобраться в работе со слотами загрузки и выполнения запросов. На панели мониторинга можно увидеть доступные слоты исполнителей и общее количество слотов исполнителей.
Вот способ оценить количество рабочих узлов, необходимых. Рекомендуется предоставить еще 10 % буфера для обработки вариантов рабочей нагрузки.
Количество используемых слотов исполнителя = Всего слотов исполнителя — Всего доступных слотов исполнителя.
Количество рабочих узлов, необходимых = количество фактически используемых слотов исполнителя / (hive.llap.daemon.num.executors + hive.llap.daemon.task.scheduler.wait.queue.size).
*hive.llap.daemon.num.executors настраивается и по умолчанию — 4.
*hive.llap.daemon.task.scheduler.wait.queue.size настраивается и по умолчанию — 10.
Действия настраиваемого сценария
Пользовательские действия в скриптах в основном используются для настройки узлов (HeadNode / WorkerNodes), которые позволяют нашим клиентам настраивать определенные библиотеки и инструменты, используемые ими. Одним из распространенных вариантов использования является задания, которые выполняются в кластере, могут иметь некоторые зависимости от сторонней библиотеки, принадлежащей клиенту, и она должна быть доступна на узлах для успешного выполнения задания. Для автомасштабирования в настоящее время мы поддерживаем настраиваемые сценарии, которые сохраняются. Каждый раз, когда новые узлы добавляются в кластер в рамках операции увеличения масштаба, эти сохраненные сценарии выполняются. После этого контейнеры или задания распределяются по новым узлам. Хотя пользовательские сценарии помогают при инициализации новых узлов, рекомендуется свести их использование к минимуму, так как это увеличивает общую задержку масштабирования и может повлиять на выполнение запланированных работ.
Учитывайте минимальный размер кластера.
Не уменьшайте кластер менее чем до трех узлов. Масштабирование кластера менее чем до трех узлов может привести к его зависанию в безопасном режиме вследствие недостаточной репликации файлов. Дополнительные сведения см. в разделе Зависание в безопасном режиме.
Доменные службы Microsoft Entra и операции масштабирования
Если вы используете кластер HDInsight с корпоративным пакетом безопасности (ESP), присоединенным к управляемому домену доменных служб Microsoft Entra, рекомендуется регулировать нагрузку на доменные службы Microsoft Entra. В сложных структурах каталогов ограниченная синхронизация рекомендуется, чтобы избежать воздействия на операции масштабирования.
Настройте максимальное количество одновременных запросов в конфигурации Hive для сценария пикового использования.
События автомасштабирования не меняют максимальное количество одновременных запросов конфигурации Hive в Ambari. Это означает, что интерактивная служба Hive Server 2 может обрабатывать только заданное количество одновременных запросов в любой момент времени, даже если число управляющих объектов интерактивного запроса масштабируется вверх и вниз на основе нагрузки и расписания. Общая рекомендация: задать эту конфигурацию для сценария пикового использования, чтобы избежать ручного вмешательства.
Однако может произойти сбой при перезапуске Hive Server 2, если количество рабочих узлов невелико и значение для максимального количества одновременных запросов настроено слишком высоким. Как минимум, требуется минимальное количество рабочих узлов, которое может соответствовать заданному числу Tez Ams
(равно максимальному числу одновременных запросов).
Ограничения
Число демонов Interactive Query
Если в кластерах интерактивных запросов включено автомасштабирование, то события увеличения или уменьшения масштаба также изменяют количество демонов интерактивных запросов до количества активных рабочих узлов. Изменение числа демонов не сохраняется в конфигурации num_llap_nodes
в Ambari. Если службы Hive перезапускаются вручную, число демонов интерактивного запроса сбрасывается в соответствии с конфигурацией в Ambari.
Если служба Interactive Query перезапускается вручную, необходимо вручную изменить конфигурацию num_llap_node
(число узлов, необходимых для запуска управляющей программы Interactive Query Hive) в разделе Advanced hive-interactive-env в соответствии с текущим числом активных рабочих узлов. Интерактивный кластер запросов поддерживает только автомасштабирование на основе расписания.
Следующие шаги
Ознакомьтесь с рекомендациями по масштабированию кластеров вручную в руководствах по масштабированию.