В крупных облачных системах особенно остро стоит вопрос автоматической балансировки или выравнивания нагрузки на вычислительные ресурсы. Озаботились данным вопросом и в Тиониксе (разработчик и оператор облачных услуг, входим в группу компаний Ростелекома).
И, поскольку нашей основной платформой разработки является Openstack, а мы, как и все люди, ленивы, то было решено подобрать какой-то готовый модуль, что уже есть в составе платформы. Наш выбор пал на Watcher, который мы и решили использовать для своих нужд.
Для начала разберемся с терминами и определениями.
नियम और परिभाषाएँ
लक्ष्य — это человекочитаемый, наблюдаемый и поддающийся измерению конечный результат, который должен быть достигнут. Для достижения каждой цели имеются одна или более стратегии. Стратегия — это реализация алгоритма, который способен найти решение для данной цели.
Действие (Action) — это элементарная задача, которая изменяет текущее состояние целевого управляемого ресурса кластера OpenStack, такая как: миграция виртуальной машины (migration), изменение состояния питания узла (change_node_power_state), изменение состояния службы nova (change_nova_service_state), изменение флэвора (resize), регистрация NOP сообщения (nop), отсутствие действий в течении определенной продолжительности времени — пауза (sleep), перенос диска (volume_migrate).
План действий (Action Plan) — специфический поток действий, осуществленных в определенном порядке для достижения конкретной Цели. План действий также содержит оцениваемую глобальную эффективность с набором показателей эффективности. План действий генерируется Watcher при успешно проведенном аудите, в результате которого использованная стратегия находит решение для достижения цели. План действий состоит из списка последовательных действий.
Аудит (Audit) — это запрос на оптимизацию кластера. Оптимизация выполняется для того, чтобы достичь одну Цель в данном кластере. Для каждого успешного аудита Watcher генерирует План действий.
Область аудита (Audit Scope) — это набор ресурсов, в рамках которых производится аудит (зона(ы) доступности, агрегаторы узлов, отдельные вычислительные узлы или узлы хранения и т.д.). Область аудита определена в каждом шаблоне. Если область аудита не указана, производится аудит всего кластера.
Шаблон аудита (Audit Template) — сохраненный набор настроек для запуска аудита. Шаблоны необходимы для того, чтобы многократно запускать аудиты с одинаковыми настройками. Шаблон должен обязательно содержать цель аудита, если стратегии не указываются, то выбираются наиболее подходящие из существующих стратегий.
Кластер (Cluster) — это набор физических машин, которые предоставляют вычислительные ресурсы, ресурсы хранения и сетевые ресурсы и управляются одним и тем же управляющим узлом OpenStack.
Модель данных кластера (Cluster Data Model, CDM) — это логическое представление текущего состояния и топологии управляемых кластером ресурсов.
Показатель эффективности (Efficacy Indicator) — показатель, который указывает на то, как выполняется решение, созданное с помощью данной стратегии. Показатели эффективности специфичны для конкретной цели и обычно используются для расчета глобальной эффективности итогового плана действий.
Спецификация эффективности (Efficacy Specification) — это набор специфических особенностей, связанный с каждой Целью, который определяет различные показатели эффективности, которые стратегия, обеспечивающая достижение соответствующей цели, должна обеспечивать в своем решении. Действительно, каждое решение, предложенное стратегией, будет проверено на соответствие спецификации, прежде чем рассчитывать его глобальную эффективность.
“Подсчитывающий” движок (Scoring Engine) — это исполняемый файл, который имеет четко определенные входные данные, четко определенные выходные данные и выполняет чисто математическую задачу. Таким образом, расчет не зависит от среды, в которой он выполняется, — он даст одинаковый результат в любом месте.
Watcher планировщик (Watcher Planner) — часть механизма принятия решений Watcher. Этот модуль принимает набор действий, сгенерированных стратегией, и создает план рабочего процесса, который определяет, как планировать во времени эти различные действия и для каждого действия, каковы предварительные условия.
Цели и стратегии Watcher
लक्ष्य
रणनीति
Dummy goal
Dummy Strategy
Dummy Strategy using sample Scoring Engines
Dummy strategy with resize
ऊर्जा की बचत
Saving Energy Strategy
सर्वर समेकन
Basic Offline Server Consolidation
VM Workload Consolidation Strategy
Workload Balancing
Workload Balance Migration Strategy
Storage Capacity Balance Strategy
Workload stabilization
शोर करने वाला पड़ोसी
शोर करने वाला पड़ोसी
थर्मल अनुकूलन
Outlet temperature based strategy
वायुप्रवाह अनुकूलन
Uniform airflow migration strategy
हार्डवेयर रखरखाव
Zone migration
अवर्गीकृत
क्रियाकारक
Dummy goal — резервная цель, которая используется для тестирования (reserved goal that is used for testing purposes).
Связанные стратегии: Dummy Strategy, Dummy Strategy using sample Scoring Engines и Dummy strategy with resize. Dummy strategy — фиктивная стратегия, используемая для интеграционного тестирования через Tempest. Эта стратегия не обеспечивает никакой полезной оптимизации, его единственная цель — использовать тесты Tempest.
Dummy strategy using sample Scoring Engines — стратегия аналогична предыдущей, отличается лишь использованием образца “оценивающего движка”, ведущего подсчет с использованием методов машинного обучения.
Dummy strategy with resize — стратегия аналогична предыдущей, отличается лишь использованием изменения флэвора (миграция и ресайз).
Не используется в продакшн.
ऊर्जा की बचत — минимизировать потребление энергии. Стратегия данной цели Saving Energy Strategy совместно со стратегией VM Workload Consolidation Strategy (Server Consolidation) способна выполнять функции динамического управления питанием (DPM), которые экономить электроэнергию за счет динамической консолидации рабочих нагрузок даже в периоды низкой загрузки ресурсов: виртуальные машины переносятся на меньшее количество узлов, а ненужные узлы — отключаются. После консолидации стратегия предлагает решение о включении/выключении узлов в соответствии с заданными параметрами: “min_free_hosts_num” — количество свободных включенных узлов, которые ожидают нагрузки, и “free_used_percent” — процентное соотношение свободных включенных узлов к количеству узлов, которое занято машинами. Для работы стратегии должен быть включен и настроен Ironic для работы с включением/отключением питания на узлах.
Параметры стратегии
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
free_used_percent
नंबर
10.0
соотношение количества свободных вычислительных узлов к количеству вычислительных узлов с виртуальными машинами
min_free_hosts_num
Int
1
минимальное количество свободных вычислительных узлов
В облаке должно быть минимум два узла. Используемый метод — изменение состояния питания узла (change_node_power_state). Сбора метрик стратегия не требует.
Server Consolidation — минимизировать количество вычислительных узлов (консолидация). Имеет две стратегии: Basic Offline Server Consolidation и VM Workload Consolidation Strategy.
Стратегия Basic Offline Server Consolidation минимизирует общее количество используемых серверов, а также минимизирует количество миграций.
Базовая стратегия требует следующие метрики:
मेट्रिक्स
दफ्तर
प्लग-इन
टिप्पणी
compute.node.cpu.percent
कोई नहीं
cpu_util
कोई नहीं
Параметры стратегии: migration_attempts — количество комбинаций для поиска потенциальных кандидатов на выключение (по умолчанию, 0, нет ограничений), period — интервал времени в секундах для получения статической агрегации из источника данных метрики (по умолчанию, 700).
Используемые методы: миграция, изменение состояния службы nova (change_nova_service_state).
Стратегия VM Workload Consolidation Strategy основана на эвристической алгоритме первого подходящего (first-fit), который фокусируется на измеренной загрузке CPU и пытается минимизировать узлы, которые имеют слишком большую или слишком небольшую нагрузку с учетом ограничений емкости ресурсов. Эта стратегия предоставляет решение, которое приводит к более эффективному использованию ресурсов кластера, используя следующие четыре этапа:
- Фаза разгрузки — обработка перерасходованных ресурсов;
- Фаза консолидации — обработка недостаточно используемых ресурсов;
- Оптимизация решения — сокращение количества миграций;
- Отключение неиспользуемых вычислительных узлов.
Стратегия требует следующие метрики:
मेट्रिक्स
दफ्तर
प्लग-इन
टिप्पणी
स्मृति
कोई नहीं
disk.root.size
कोई नहीं
Следующие метрики не являются обязательными, но повышают точности стратегии, если доступны:
मेट्रिक्स
दफ्तर
प्लग-इन
टिप्पणी
memory.resident
कोई नहीं
cpu_util
कोई नहीं
Параметры стратегии: period — интервал времени в секундах для получения статической агрегации из источника данных метрики (по умолчанию, 3600).
Использует те же методы, что и предыдущая стратегия. Подробнее .
Workload Balancing — сбалансировать рабочую нагрузку между вычислительными узлами. Цель обладает тремя стратегиями: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.
Workload Balance Migration Strategy запускает миграции виртуальных машин на основе рабочей нагрузки виртуальных машин узлов. Решение о переносе принимается всякий раз, когда % использования CPU или ОЗУ узла превышает указанный порог. При этом перемещаемая виртуальная машина должна приблизить узел к средней рабочей нагрузке всех узлов.
आवश्यकताएँ
- Использование физических процессоров;
- Минимум два физических вычислительных узла;
- Установленный и настроенный компонент Ceilometer — ceilometer-agent-compute, работающий на каждом вычислительном узле, и Ceilometer API, а также сбор следующих метрик:
मेट्रिक्स
दफ्तर
प्लग-इन
टिप्पणी
cpu_util
कोई नहीं
memory.resident
कोई नहीं
Параметры стратегии:
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
मेट्रिक्स
तार
‘cpu_util’
Метрики, которые лежат в основе: ‘cpu_util’, ‘memory.resident’.
द्वार
नंबर
25.0
Порог рабочей нагрузки для миграции.
अवधि
नंबर
300
Совокупный период времени Ceilometer.
Используемый метод — миграция.
Workload stabilization — стратегия, направленная на стабилизацию рабочей нагрузки с использованием живой миграции. Стратегия основана на алгоритме стандартного отклонения и определяет, существует ли перегрузка в кластере, и реагирует на нее путем запуска миграции машин для стабилизации кластера.
आवश्यकताएँ
- Использование физических процессоров;
- Минимум два физических вычислительных узла;
- Установленный и настроенный компонент Ceilometer — ceilometer-agent-compute, работающий на каждом вычислительном узле, и Ceilometer API, а также сбор следующих метрик:
मेट्रिक्स
दफ्तर
प्लग-इन
टिप्पणी
cpu_util
कोई नहीं
memory.resident
कोई नहीं
Storage Capacity Balance Strategy (стратегия реализована начиная с Queens) — стратегия переносит диски в зависимости от загруженности пулов Cinder. Решение о переносе принимается всякий раз, когда коэффициент использования пула превышает указанный порог. Перемещаемый диск должен приблизить пул к средней нагрузке всех пулов Cinder.
आवश्यकताएँ और प्रतिबंध
- Минимум два пула Cinder;
- Возможность миграции дисков.
- Модель данных кластера — Cinder cluster data model collector.
Параметры стратегии:
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
volume_threshold
नंबर
80.0
Пороговое значение дисков для балансировки объемов.
Используемый метод — миграция диска (volume_migrate).
Noisy Neighbor — идентифицировать и перенести “шумного соседа” — виртуальной машины с низким приоритетом, которая негативно влияет на производительность виртуальной машины с высоким приоритетом с точки зрения IPC, чрезмерно используя Last Level Cache. Собственная стратегия: Noisy Neighbor (используемый параметр стратегии — cache_threshold (значение по умолчанию — 35), при падении производительности до указанного значения запускается миграция. Для работы стратегии необходимы включенные LLC (Last Level Cache) метрики, последний Intel сервер с поддержкой CMT, а также сбор следующих метрик:
मेट्रिक्स
दफ्तर
प्लग-इन
टिप्पणी
cpu_l3_cache
कोई नहीं
Необходим Intel .
Модель данных кластера (по умолчанию): Nova cluster data model collector. Применяемый метод — миграция.
Работа с данной целью через Dashboard не реализована в полном объеме в Queens.
थर्मल अनुकूलन — оптимизировать температурный режим. Температура на выходе (вытяжной воздух) является одной из важных тепловых телеметрических систем для измерения состояния тепловой / рабочей нагрузки сервера. Для цели имеется одна стратегия — Outlet temperature based strategy, которая принимает решения о переносе рабочих нагрузок на узлы с благоприятным температурным режимом (самая низкая температура на выходе), когда температура на выходе исходных хостов достигает настраиваемого порога.
Для работы стратегии необходим сервер с установленным и настроенным Intel Power Node Manager , а также сбор следующих метрик:
मेट्रिक्स
दफ्तर
प्लग-इन
टिप्पणी
hardware.ipmi.node.outlet_temperature
आईपीएमआई
Параметры стратегии:
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
द्वार
नंबर
35.0
Температурный порог для миграции.
अवधि
नंबर
30
Интервал времени в секундах для получения статистической агрегации из источника данных метрики.
Используемый метод — миграция.
वायुप्रवाह अनुकूलन — оптимизировать режим вентилирования. Собственная стратегия — Uniform Airflow using live migration. Стратегия запускает миграцию виртуальной машины всякий раз, когда воздушный поток от вентилятора сервера превышает указанный порог.
Для работы стратегии необходимы:
- Аппаратное обеспечение: вычислительные узлы <с поддержкой NodeManager 3.0;
- Минимум два вычислительных узла;
- Установленный и настроенный на каждом вычислительном узле компонент ceilometer-agent-compute и Ceilometer API, который может успешно сообщать о таких метриках как поток воздуха, мощность системы, температура на входе:
मेट्रिक्स
दफ्तर
प्लग-इन
टिप्पणी
hardware.ipmi.node.airflow
आईपीएमआई
hardware.ipmi.node.temperature
आईपीएमआई
hardware.ipmi.node.power
आईपीएमआई
Для работы стратегии необходим сервер с установленным и настроенным Intel Power Node Manager 3.0 или более поздней версии.
Ограничения: Концепция не предназначена для продакшна.
Предлагается использовать этот алгоритм с непрерывными аудитами, поскольку за одну итерацию планируется миграция только одной виртуальной машины.
Возможны живые миграции.
Параметры стратегии:
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
threshold_airflow
नंबर
400.0
Airflow threshold for migration Unit is 0.1CFM
threshold_inlet_t
नंबर
28.0
Inlet temperature threshold for migration decision
threshold_power
नंबर
350.0
System power threshold for migration decision
अवधि
नंबर
30
Интервал времени в секундах для получения статистической агрегации из источника данных метрики.
Используемый метод — миграция.
हार्डवेयर रखरखाव — обслуживание аппаратных средств. Стратегия, относящаяся к данной целе, — Zone migration. Стратегия является инструментом для эффективной автоматической и минимальной миграции виртуальных машин и дисков в случае необходимости проведения технического обслуживания аппаратных средств. Стратегия выстраивает план действий в соответствии с весами: набор действий, который имеет больший вес, будут запланированы раньше других. Существует два параметра конфигурации: веса действий (action_weights) и распараллеливание (parallelization).
Ограничения: необходима настройка весов действий и распараллеливания.
Параметры стратегии:
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
compute_nodes
सरणी
कोई नहीं
Вычислительные узлы для миграции.
storage_pools
सरणी
कोई नहीं
Узлы хранения для миграции.
parallel_total
पूर्णांक
6
Общее количество действий, которые должны выполняться параллельно.
parallel_per_node
पूर्णांक
2
Количество действий, выполняемых параллельно для каждого вычислительного узла.
parallel_per_pool
पूर्णांक
2
Количество действий, выполняемых параллельно для каждого пула хранения.
प्राथमिकता
वस्तु
कोई नहीं
Список приоритетов для виртуальных машин и дисков.
with_attached_volume
बूलियन
झूठा
False — виртуальные машины будут перенесены после переноса всех дисков. True — виртуальные машины будут перенесены после миграции всех подключенных дисков.
Элементы массива вычислительных узлов:
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
src_node
स्ट्रिंग
कोई नहीं
Вычислительный узел, с которого переносятся виртуальные машины (обязательно).
dst_node
स्ट्रिंग
कोई नहीं
Вычислить узел, на который мигрируют виртуальные машины.
Элементы массива узлов хранения:
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
src_pool
स्ट्रिंग
कोई नहीं
Пул хранения, из которого переносятся диски (обязательно).
dst_pool
स्ट्रिंग
कोई नहीं
Пул хранения, на который переносятся диски.
src_type
स्ट्रिंग
कोई नहीं
Исходный тип диска (обязательно).
dst_type
स्ट्रिंग
कोई नहीं
Итоговый тип диска (обязательно).
Элементы приоритетности объектов:
पैरामीटर
टाइप
डिफ़ॉल्ट रूप से
описание
परियोजना
सरणी
कोई नहीं
Имена проектов.
compute_node
सरणी
कोई नहीं
Имена вычислительных узлов.
storage_pool
सरणी
कोई नहीं
Имена пулов хранения.
गणना करना
एनम
कोई नहीं
Параметры виртуальной машины [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
भंडारण
एनम
कोई नहीं
Параметры дисков [“size”, “created_at”].
Используемые методы — миграция виртуальных машин, миграция дисков.
अवर्गीकृत — вспомогательная цель, используемая для облегчения процесса разработки стратегии. Не содержит спецификаций и может использоваться всякий раз, когда стратегия еще не связана с существующей целью. Эта цель также может быть использована в качестве переходного этапа. Связанная с данной целью стратегия — Actuator.
Создание новой цели
Watcher Decision Engine имеет интерфейс плагина “внешней цели”, который дает возможность интегрировать внешнюю цель, которая может быть достигнута с помощью стратегии.
Прежде чем создавать новую цель, следует убедиться, что ни одна из существующих целей не соответствует вашим потребностям.
Создание нового плагина
Чтобы создать новую цель, вы должны: расширить класс цели, реализовать метод класса get_name () для возвращения уникального идентификатора новой цели, которую вы хотите создать. Этот уникальный идентификатор должен совпадать с именем точки входа, которую вы декларируете позже.
Далее необходимо реализовать метод класса get_display_name () для возвращения переведенного отображаемого имени цели, которую вы хотите создать (не используйте переменную для возврата переведенной строки, чтобы она могла автоматически собираться инструментом перевода.).
Реализуйте метод класса get_translatable_display_name (), чтобы вернуть ключ перевода (фактически английское отображаемое имя) вашей новой цели. Возвращаемое значение должно совпадать со строкой, переведенной в get_display_name ().
Реализуйте его метод get_efficacy_specification (), чтобы вернуть спецификацию эффективности для вашей цели. Метод get_efficacy_specification () возвращает экземпляр Unclassified (), предоставленный Watcher. Эта спецификация эффективности полезна в процессе разработки вашей цели, поскольку она соответствует пустой спецификации.
→
Архитектура Watcher (подробнее ).
अवयव
Watcher API — компонент, реализующий REST API, предоставляемый Watcher. Механизмы взаимодействия: CLI, плагин Horizon, Python SDK.
Watcher DB — база данных Watcher.
Watcher Applier — компонент, реализующий выполнение плана действий, созданного компонентом Watcher Decision Engine.
Watcher Decision Engine — компонент, отвечающий за вычисление набора потенциальных действий по оптимизации для выполнения цели аудита. Если стратегия не указана, компонент самостоятельно выбирает наиболее подходящую.
Watcher Metrics Publisher — компонент, который собирает и вычисляет некоторые метрики или события и публикует их в конечной точке CEP. Функционал компонента может предоставляться также Ceilometer publisher.
Complex Event Processing (CEP) Engine — движок комплексной обработки событий. По соображениям производительности может быть несколько экземпляров CEP Engine, работающих одновременно, каждый из которых обрабатывает определенный тип метрики / событий. В системе Watcher CEP запускает два типа действий: — записать соответствующие события / метрики в базу данных временных рядов; — отправлять соответствующие события в компонент Watcher Decision Engine, когда это событие может повлиять на результат текущей стратегии оптимизации, поскольку кластер Openstack не является статической системой.
Взаимодействие компонентов осуществляется по протоколу AMQP.
→
Схема взаимодействия с Watcher
Результаты тестирования Watcher
- На странице Optimization — Action plans 500 ошибка (как на чистом Queens, так и на стенде с модулями Тионикс), появляется только после того, как запускается аудит и генерируется план действий, пустая открывается нормально.
- На вкладке Action details ошибки, не удается получить цель и стратегию аудита (как на чистом Queens, так и на стенде с модулями Тионикс).
- Аудиты с целью Dummy (тестовые) создаются и запускаются нормально, генерируются планы действий.
- Аудиты с целью Unclassified не создаются, так как цель не является функциональной и предназначена для промежуточной настройки при создании новых стратегий.
- Аудиты с целью Workload Balancing (стратегия Storage Capacity balance) создаются успешно, однако план действий не генерируется. Не требуется оптимизация пулов хранения.
- Аудиты с целью Workload Balancing (стратегия Workload Balance Migration Strategy) создаются успешно, однако план действий не генерируется.
- Аудиты с целью Workload Balancing (стратегия Workload Stabilization Strategy) завершаются ошибкой.
- Аудиты с целью Noisy Neighbor создаются успешно, однако план действий не генерируется.
- Аудиты с целью Hardware maintenance создаются успешно, план действий генерируется не в полном объеме (генерируются показатели эффективности, но не генерируется сам список действий).
- Правки в конфигах nova.conf (в default секции compute_monitors = cpu.virt_driver) на вычислительных и управляющем узле не исправляют ошибки.
- Аудиты с целью Server Consolidation (стратегия Basic) также завершаются с ошибкой.
- Аудиты с целью Server Consolidation (стратегия VM workload consolidation) завершаются с ошибкой. В логах ошибка получения исходных данных. Обсуждение ошибки, в частности, .
Попробовали указать в конфиг-файле Watcher (не помогло — в результате ошибки на всех страницах Optimization, возвращение к исходному содержимому конфиг-файла не исправляет ситуацию): [watcher_strategies.basic] datasource = ceilometer, gnocchi - Аудиты с целью Saving Energy завершаются с ошибкой. Судя по логам, проблема все-таки в отсутствии Ironic, не будет работать без baremetal service.
- Аудиты с целью Thermal Optimization завершаются с ошибкой. Трейсбек тот же, что и для Server Consolidation (стратегия VM workload consolidation) (ошибка исходных данных)
- Аудиты с целью Airflow Optimization завершаются с ошибкой.
Встречаются также следующие ошибки завершения аудита. Трейсбэк в логах decision-engine.log (не определено состояние кластера).
→ Обсуждение ошибки
निष्कर्ष
Результатом наших двухмесячных изысканий стал однозначный вывод о том, что для получения полноценной, работающей системы балансировки нагрузки нам придется, в этой части, вплотную заняться доработкой инструментария для платформы Openstack.
Watcher показал себя серьезным и быстро развивающимся продуктом с огромным потенциалом, для полноценного использования которого потребуется большая и серьезная работа.
Но об этом – в следующих статьях цикла.
स्रोत: www.habr.com