В големите облачни системи особено остро стои въпросът за автоматичното балансиране или изравняване на натоварването върху изчислителните ресурси. За този въпрос се загрижиха и в Тионикс (разработчик и оператор на облачни услуги, част от групата компании Ростелеком).
И, тъй като нашата основна платформа за разработка е 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 цел
Dummy стратегия
Dummy стратегия, използваща пробни оценяващи двигатели
Dummy стратегия с преоразмеряване
Спестяване на енергия
Стратегия за спестяване на енергия
Консолидация на сървъри
Основна офлайн консолидация на сървъри
Стратегия за консолидация на натоварвания на ВМ
Баланс на натоварването
Стратегия за миграция на баланса на натоварването
Стратегия за баланс на капацитета на хранилището
Стабилизация на натоварването
Шумен съсед
Шумен съсед
Термална оптимизация
Стратегия на база температура на изхода
Оптимизация на въздушния поток
Стратегия за миграция на равномерен въздушен поток
Поддръжка на хардуер
Миграция на зони
Некласифициран
Актюатор
Dummy цел — резервна цел, която се използва за тестване (reserved goal that is used for testing purposes).
Свързани стратегии: Dummy стратегия, Dummy стратегия, използваща пробни оценяващи двигатели и Dummy стратегия с преоразмеряване. Dummy стратегия — фиктивна стратегия, използвана за интеграционно тестване чрез Tempest. Тази стратегия не осигурява полезна оптимизация, единствената й цел е използването на тестовете на Tempest.
Dummy стратегия, използваща пробни оценяващи двигатели — стратегия, аналогична на предишната, различаваща се само с използването на образец на “оцениващ двигател”, който прави броене с методи на машинно обучение.
Dummy стратегия с преоразмеряване — стратегия, аналогична на предишната, различаваща се само с използването на промяна на флавора (миграция и преоразмеряване).
Не се използва в продукция.
Спестяване на енергия — да се минимизира потреблението на енергия. Стратегията на целта за спестяване на енергия, съвместно със стратегията за консолидация на натоварването на ВМ (Консолидация на сървъри), е в състояние да изпълнява функции на динамично управление на захранването (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
none
cpu_util
none
Параметри на стратегията: migration_attempts — брой комбинации за търсене на потенциални кандидати за изключване (по подразбиране: 0, без ограничения), period — интервал от време в секунди за получаване на статична агрегация от източника на данни за метрики (по подразбиране: 700).
Използвани методи: миграция, промяна на състоянието на услугата nova (change_nova_service_state).
Стратегията VM Workload Consolidation Strategy е базирана на хевристичния алгоритъм за първо подходящо (first-fit), който се фокусира върху измереното натоварване на CPU и се опитва да минимизира възлите, които имат твърде голямо или твърде малко натоварване, като взема предвид ограниченията на ресурсите. Тази стратегия предлага решение, което води до по-ефективно използване на ресурсите на клъстера, използвайки следните четири етапа:
- Фаза на разтоварване — обработка на преразходвани ресурси;
- Фаза на консолидация — обработка на недостатъчно използвани ресурси;
- Оптимизация на решението — намаляване на броя на миграциите;
- Изключване на неизползвани изчислителни възли.
Стратегията изисква следните метрики:
метрика
услуга
плъгини
коментар
memory
none
disk.root.size
none
Следните метрики не са задължителни, но повишават точността на стратегията, ако са налични:
метрика
услуга
плъгини
коментар
memory.resident
none
cpu_util
none
Параметри на стратегията: period — интервал от време в секунди за получаване на статична агрегация от източника на данни за метрики (по подразбиране: 3600).
Използва същите методи като предишната стратегия. Подробности .
Баланс на натоварването — балансиране на работното натоварване между изчислителните възли. Целта притежава три стратегии: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.
Стратегията за миграция на баланса на натоварването стартира миграции на виртуални машини на базата на натоварването на виртуалните машини на възлите. Решение за преместване се взема всеки път, когато процента на използване на CPU или RAM на възела надвишава зададения праг. При това преносимата виртуална машина трябва да приближи възела до средното натоварване на всички възли.
Изисквания
- Използване на физически процесори;
- Минимум два физически изчислителни възела;
- Инсталиран и настроен компонент Ceilometer – ceilometer-agent-compute, работещ на всеки изчислителен възел, и Ceilometer API, както и събиране на следните метрики:
метрика
услуга
плъгини
коментар
cpu_util
none
memory.resident
none
Параметри на стратегията:
параметър
тип
по подразбиране
описание
metrics
String
‘cpu_util’
Метрики, които лежат в основата: ‘cpu_util’, ‘memory.resident’.
праг
Брой
25.0
Праг на натоварването за миграция.
период
Брой
300
Общ период от време Ceilometer.
Използваният метод е миграция.
Стабилизиране на натоварването – стратегия, насочена към стабилизиране на натоварването чрез жива миграция. Стратегията е базирана на алгоритъма на стандартното отклонение и определя дали има претоварване в клъстера и реагира на него чрез стартиране на миграции на машините за стабилизиране на клъстера.
Изисквания
- Използване на физически процесори;
- Минимум два физически изчислителни възела;
- Инсталиран и настроен компонент Ceilometer – ceilometer-agent-compute, работещ на всеки изчислителен възел, и Ceilometer API, както и събиране на следните метрики:
метрика
услуга
плъгини
коментар
cpu_util
none
memory.resident
none
Стратегия за баланс на капацитета на съхранение (стратегия реализирана от 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
none
Необходим Intel .
Модел на данни за кластера (по подразбиране): Nova cluster data model collector. Използваният метод е миграция.
Работата с тази цел през Dashboard не е напълно реализирана в Queens.
Термална оптимизация — оптимизиране на температурния режим. Температурата на изхода (изпускан въздух) е една от важните термични телеметрични системи за измерване на състоянието на термичната/работната натовареност на сървъра. За целта има една стратегия — стратегия, базирана на температурата на изхода, която взема решения за прехвърляне на работни натоварвания на възли с благоприятен температурен режим (най-ниската температура на изхода), когато температурата на изхода на основните хостове надвиши зададения праг.
За работата на стратегията е необходим сървър с инсталиран и настроен Intel Power Node Manager. , както и събиране на следните метрики:
метрика
услуга
плъгини
коментар
hardware.ipmi.node.outlet_temperature
IPMI
Параметри на стратегията:
параметър
тип
по подразбиране
описание
праг
Брой
35.0
Температурен праг за миграция.
период
Брой
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
Праг на въздушния поток за миграция. Единицата е 0.1CFM
threshold_inlet_t
Брой
28.0
Праг на температурата на входа за вземане на решение за миграция
threshold_power
Брой
350.0
Праг на мощността на системата за вземане на решение за миграция
период
Брой
30
Интервал на времето в секунди за получаване на статистическа агрегация от източника на данни за метрики.
Използваният метод е миграция.
Поддръжка на хардуер — обслужване на хардуерни средства. Стратегията, свързана с тази цел, е миграция на зоната. Стратегията е инструмент за ефективна автоматична и минимална миграция на виртуални машини и дискове в случай на необходимост от техническо обслужване на хардуера. Стратегията изгражда план за действие в съответствие с тежестите: набор от действия, които имат по-голяма тежест, ще бъдат планирани по-рано от другите. Съществуват два конфигурационни параметъра: тежести на действията (action_weights) и паралелизация (parallelization).
Ограничения: необходима е настройка на тежестите на действията и паралелизацията.
Параметри на стратегията:
параметър
тип
по подразбиране
описание
изчислителни_възли
масив
Няма
Изчислителни възли за миграция.
съхранителни_пулове
масив
Няма
Възли за съхранение за миграция.
паралелно_общо
цяло число
6
Общият брой действия, които трябва да се изпълняват паралелно.
паралелно_на_възел
цяло число
2
Брой действия, изпълнявани паралелно за всеки изчислителен възел.
паралелно_на_пул
цяло число
2
Брой действия, изпълнявани паралелно за всеки пул за съхранение.
приоритет
обект
Няма
Списък с приоритети за виртуални машини и дискове.
с_прикачен_обем
булев
False
False — виртуалните машини ще бъдат прехвърлени след прехвърлянето на всички дискове. True — виртуалните машини ще бъдат прехвърлени след миграцията на всички прикрепени дискове.
Елементи на масива с изчислителни възли:
параметър
тип
по подразбиране
описание
източник_възел
string
Няма
Изчислителен възел, от който се прехвърлят виртуалните машини (задължително).
целеви_възел
string
Няма
Възел, на който мигрират виртуалните машини.
Елементи на масива за съхранение:
параметър
тип
по подразбиране
описание
източников_пул
string
Няма
Пул за съхранение, от който се прехвърлят дисковете (задължително).
целеви_пул
string
Няма
Пул за съхранение, на който се прехвърлят дисковете.
източников_тип
string
Няма
Изходен тип на диска (задължително).
целеви_тип
string
Няма
Завършващ тип на диска (задължително).
Елементи на приоритетите на обектите:
параметър
тип
по подразбиране
описание
проект
масив
Няма
Имена на проекти.
изчислителен_възел
масив
Няма
Имена на изчислителните възли.
съхранителен_пул
масив
Няма
Имена на пуловете за съхранение.
изчислителен
enum
Няма
Параметри на виртуалната машина [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
storage
enum
Няма
Параметри на дисковете [“size”, “created_at”].
Използвани методи — миграция на виртуални машини, миграция на дискове.
Некласифициран — спомагателна цел, използвана за улесняване на процеса на разработка на стратегия. Не съдържа спецификации и може да се използва всякога, когато стратегията все още не е свързана с съществуваща цел. Тази цел може също да бъде използвана като преходен етап. Свързаната със съществуващата цел стратегия е Актуатор.
Създаване на нова цел
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 (в секция по подразбиране 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
