У великих хмарних системах особливо гостро постає питання автоматичного балансування чи вирівнювання навантаження на обчислювальні ресурси. Перейнялися цим питанням і в Тіоніксі (розробник і оператор хмарних послуг, входимо до групи компаній Ростелекому).
І оскільки нашою основною платформою розробки є Openstack, а ми, як і всі люди, ліниві, то було вирішено підібрати якийсь готовий модуль, що вже є у складі платформи. Наш вибір упав на Watcher, який ми і вирішили використати для своїх потреб.
Для початку розберемося з термінами та визначеннями.
Терміни та визначення
Мета - це людиночитаний, спостерігається і піддається вимірюванню кінцевий результат, який має бути досягнутий. Для досягнення кожної мети є одна чи більше стратегій. Стратегія - це реалізація алгоритму, який здатний знайти рішення для цієї мети.
Дія (Action) — це елементарне завдання, яке змінює поточний стан цільового керованого ресурсу кластера OpenStack, таке як: міграція віртуальної машини (migration), зміна стану живлення вузла (change_node_power_state), зміна стану служби nova (change_nova_service_state), зміна флевору (resize) (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
Шумний сусід
Шумний сусід
Thermal Optimization
Outlet temperature заснований на стратегії
Оптимізація потоку повітря
Uniform airflow migration strategy
Технічне обслуговування обладнання
Zone migration
Незакритий
Привід
Dummy goal - резервна мета, яка використовується для тестування (reserved goal that is used for testing purposes).
Пов'язані стратегії: Dummy Strategy, Dummy Strategy за допомогою шаблонів 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
Поріг робочого навантаження для міграції.
period
Номер
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.
Thermal Optimization - Оптимізувати температурний режим. Температура на виході (витяжне повітря) є однією з важливих теплових телеметричних систем для вимірювання стану теплового/робочого навантаження сервера. Для мети є одна стратегія - Outlet temperature based strategy, яка приймає рішення про перенесення робочих навантажень на вузли зі сприятливим температурним режимом (найнижча температура на виході), коли температура на виході вихідних хостів досягає порогу, що настроюється.
Для роботи стратегії необхідний сервер із встановленим та налаштованим Intel Power Node Manager , а також збирання наступних метрик:
метрика
служба
плагіни
коментар
hardware.ipmi.node.outlet_temperature
IPMI
Параметри стратегії:
параметр
тип
за замовчуванням
опис
поріг
Номер
35.0
Температурний поріг для міграції
period
Номер
30
Інтервал часу за секунди для отримання статистичної агрегації з джерела даних метрики.
Метод, що використовується, — міграція.
Оптимізація потоку повітря - Оптимізувати режим вентилювання. Власна стратегія Uniform Airflow using live migration. Стратегія запускає міграцію віртуальної машини щоразу, коли повітряний потік від вентилятора сервера перевищує зазначений поріг.
Для роботи стратегії необхідні:
- Апаратне забезпечення: обчислювальні вузли <з підтримкою NodeManager 3.0;
- Мінімум два обчислювальні вузли;
- Встановлений та налаштований на кожному обчислювальному вузлі компонент ceilometer-agent-compute та Ceilometer API, який може успішно повідомляти про такі метрики як потік повітря, потужність системи, температура на вході:
метрика
служба
плагіни
коментар
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Для роботи стратегії необхідний сервер із встановленим та налаштованим 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
period
Номер
30
Інтервал часу за секунди для отримання статистичної агрегації з джерела даних метрики.
Метод, що використовується, — міграція.
Технічне обслуговування обладнання - Обслуговування апаратних засобів. Стратегія, що стосується цієї мети, - Zone migration. Стратегія є інструментом для ефективної автоматичної та мінімальної міграції віртуальних машин та дисків у разі потреби проведення технічного обслуговування апаратних засобів. Стратегія вибудовує план дій відповідно до ваг: набір дій, який має більшу вагу, будуть заплановані раніше за інших. Існує два параметри конфігурації: ваги дій (action_weights) та розпаралелювання (parallelization).
Обмеження: необхідне налаштування ваг дій та розпаралелювання.
Параметри стратегії:
параметр
тип
за замовчуванням
опис
compute_nodes
масив
ніхто
Обчислювальні вузли для міграції.
storage_pools
масив
ніхто
Вузли зберігання для міграції.
parallel_total
ціле
6
Загальна кількість дій, які мають виконуватися паралельно.
parallel_per_node
ціле
2
Кількість дій, які виконуються паралельно для кожного обчислювального вузла.
parallel_per_pool
ціле
2
Кількість дій, які виконуються паралельно для кожного пулу зберігання.
пріоритет
об'єкт
ніхто
Список пріоритетів для віртуальних машин та дисків.
with_attached_volume
boolean
Помилковий
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 показав себе серйозним і швидко розвивається з величезним потенціалом, для повноцінного використання якого знадобиться велика і серйозна робота.
Але про це – у наступних статтях циклу.
Джерело: habr.com