В големите облачни системи въпросът за автоматичното балансиране или изравняване на натоварването на изчислителните ресурси е особено остър. Tionix (разработчик и оператор на облачни услуги, част от групата компании Rostelecom) също се е погрижил за този проблем.
И тъй като нашата основна платформа за разработка е Openstack, а ние, като всички хора, сме мързеливи, беше решено да изберем някакъв готов модул, който вече е включен в платформата. Нашият избор падна върху Watcher, който решихме да използваме за нашите нужди.
Първо, нека да разгледаме термините и определенията.
Условия и определения
Цел е четим от човека, видим и измерим краен резултат, който трябва да бъде постигнат. Има една или повече стратегии за постигане на всяка цел. Стратегията е прилагането на алгоритъм, който е в състояние да намери решение за дадена цел.
Действие е елементарна задача, която променя текущото състояние на целевия управляван ресурс на клъстера OpenStack, като например: мигриране на виртуална машина (миграция), промяна на състоянието на захранване на възел (change_node_power_state), промяна на състоянието на услугата nova (change_nova_service_state ), промяна на вкуса (resize), регистриране на NOP съобщения (nop), липса на действие за определен период от време - пауза (sleep), прехвърляне на диск (volume_migrate).
План за действие - специфичен поток от действия, извършвани в определен ред за постигане на конкретна цел. Планът за действие също така съдържа измерено глобално представяне с набор от показатели за изпълнение. План за действие се генерира от Watcher при успешен одит, в резултат на който използваната стратегия намира решение за постигане на целта. Планът за действие се състои от списък с последователни действия.
Одит е заявка за оптимизиране на клъстера. Оптимизацията се извършва с цел постигане на една цел в даден клъстер. За всеки успешен одит Watcher генерира план за действие.
Обхват на одита е набор от ресурси, в рамките на които се извършва одитът (зони на достъпност, агрегатори на възли, отделни изчислителни възли или възли за съхранение и т.н.). Обхватът на одита е дефиниран във всеки шаблон. Ако не е посочен обхват на одит, се одитира целият клъстер.
Шаблон за одит — записан набор от настройки за стартиране на одит. Шаблоните са необходими за извършване на одити многократно с едни и същи настройки. Шаблонът трябва задължително да съдържа целта на одита; ако стратегиите не са посочени, тогава се избират най-подходящите съществуващи стратегии.
Клъстер е колекция от физически машини, които предоставят изчислителни, съхранение и мрежови ресурси и се управляват от един и същ възел за управление на OpenStack.
Клъстерен модел на данни (CDM) е логическо представяне на текущото състояние и топология на ресурсите, управлявани от клъстера.
Индикатор за ефективност - индикатор, който показва как се изпълнява решението, създадено с помощта на тази стратегия. Индикаторите за ефективност са специфични за конкретна цел и обикновено се използват за изчисляване на общата ефективност на получения план за действие.
Спецификация на ефикасността е набор от специфични характеристики, свързани с всяка цел, които определят различните показатели за ефективност, които стратегията за постигане на съответната цел трябва да постигне в своето решение. Всъщност всяко решение, предложено от стратегията, ще бъде проверено спрямо спецификацията, преди да се изчисли неговата глобална ефективност.
Двигател за точкуване е изпълним файл, който има добре дефинирани входове, добре дефинирани изходи и изпълнява чисто математическа задача. По този начин изчислението е независимо от средата, в която се извършва – то ще даде същия резултат навсякъде.
Планиращ наблюдател - част от системата за вземане на решения Watcher. Този модул взема набор от действия, генерирани от стратегия, и създава план за работен поток, който указва как да планирате тези различни действия във времето и какви са предварителните условия за всяко действие.
Цели и стратегии на наблюдателя
Цел
стратегия
Фиктивна цел
Фиктивна стратегия
Фиктивна стратегия, използваща примерни машини за точкуване
Фиктивна стратегия с преоразмеряване
Пестене на енергия
Стратегия за пестене на енергия
Консолидация на сървъри
Основна офлайн сървърна консолидация
Стратегия за консолидиране на работното натоварване на VM
Балансиране на работното натоварване
Стратегия за миграция на баланса на работното натоварване
Стратегия за балансиране на капацитета за съхранение
Стабилизиране на натоварването
Шумен съсед
Шумен съсед
Термична оптимизация
Стратегия, базирана на температурата на изхода
Оптимизация на въздушния поток
Еднаква стратегия за миграция на въздушния поток
Поддръжка на хардуера
Зонова миграция
Некласифициран
задвижващо устройство
Фиктивна цел — запазена цел, която се използва за тестови цели.
Свързани стратегии: фиктивна стратегия, фиктивна стратегия с използване на примерни машини за оценяване и фиктивна стратегия с преоразмеряване. Dummy стратегия е фиктивна стратегия, използвана за интеграционно тестване чрез Tempest. Тази стратегия не предоставя полезна оптимизация, единствената й цел е да използва тестове на Tempest.
Фиктивна стратегия, използваща примерни машини за оценяване - стратегията е подобна на предишната, единствената разлика е използването на примерна „машина за оценяване“, която извършва изчисления с помощта на методи за машинно обучение.
Фиктивна стратегия с преоразмеряване - стратегията е подобна на предишната, единствената разлика е използването на промяна на вкуса (миграция и преоразмеряване).
Не се използва в производството.
Пестене на енергия — минимизиране на консумацията на енергия. Стратегията за пестене на енергия на тази цел, заедно със стратегията за консолидиране на работното натоварване на VM (консолидация на сървъри), е способна на функции за динамично управление на захранването (DPM), които пестят енергия чрез динамично консолидиране на работните натоварвания дори по време на периоди на ниско използване на ресурсите: виртуалните машини се преместват на по-малко възли , а ненужните възли са деактивирани. След консолидация стратегията предлага решение за включване/изключване на възли в съответствие с посочените параметри: “min_free_hosts_num” - броят на свободните активирани възли, които чакат зареждане, и “free_used_percent” - процентът на свободните активирани хостове към брой възли, които са заети от машини. За да работи стратегията, трябва да има активиран и конфигуриран Ironic за обработка на цикъл на захранване на възли.
Параметри на стратегията
параметър
тип
по подразбиране
описание
безплатно_използван_процент
Телефон за връзка:
10.0
съотношение на броя на свободните изчислителни възли към броя на изчислителните възли с виртуални машини
min_free_hosts_num
Int
1
минимален брой свободни изчислителни възли
Облакът трябва да има поне два възела. Използваният метод е промяна на състоянието на захранване на възела (change_node_power_state). Стратегията не изисква събиране на показатели.
Консолидация на сървъри - минимизиране на броя на изчислителните възли (консолидация). Той има две стратегии: основна консолидация на офлайн сървър и стратегия за консолидиране на работното натоварване на VM.
Стратегията за базова офлайн консолидация на сървъри минимизира общия брой използвани сървъри и също така минимизира броя на миграциите.
Основната стратегия изисква следните показатели:
показател
обслужване
плъгини
коментар
compute.node.cpu.percent
нито един
cpu_util
нито един
Параметри на стратегията: migration_attempts - брой комбинации за търсене на потенциални кандидати за изключване (по подразбиране, 0, без ограничения), период - времеви интервал в секунди за получаване на статична агрегация от източника на метрични данни (по подразбиране, 700).
Използвани методи: миграция, промяна на състоянието на услугата nova (change_nova_service_state).
Стратегията за консолидиране на работното натоварване на виртуалната машина се основава на евристика за първо напасване, която се фокусира върху измереното натоварване на процесора и се опитва да минимизира възли, които имат твърде голямо или твърде малко натоварване при ограничения на ресурсния капацитет. Тази стратегия предоставя решение, което води до по-ефективно използване на ресурсите на клъстера, като се използват следните четири стъпки:
- Фаза на разтоварване – обработка на прекомерно използвани ресурси;
- Фаза на консолидация – обработка на недостатъчно използвани ресурси;
- Оптимизиране на решението – намаляване броя на миграциите;
- Деактивиране на неизползваните изчислителни възли.
Стратегията изисква следните показатели:
показател
обслужване
плъгини
коментар
памет
нито един
disk.root.size
нито един
Следните показатели не са задължителни, но ще подобрят точността на стратегията, ако са налични:
показател
обслужване
плъгини
коментар
памет.резидент
нито един
cpu_util
нито един
Параметри на стратегията: период — времеви интервал в секунди за получаване на статична агрегация от източника на метрични данни (по подразбиране, 3600).
Използва същите методи като предишната стратегия. Повече информация .
Балансиране на работното натоварване — балансиране на натоварването между изчислителните възли. Целта има три стратегии: стратегия за миграция на баланса на работното натоварване, стабилизиране на натоварването, стратегия за балансиране на капацитета за съхранение.
Стратегията за миграция на баланса на работното натоварване изпълнява миграции на виртуални машини въз основа на натоварването на хост виртуалната машина. Решение за миграция се взема всеки път, когато % използване на CPU или RAM на даден възел надвиши посочения праг. В този случай преместената виртуална машина трябва да доближи възела до средното натоварване на всички възли.
Изисквания
- Използване на физически процесори;
- Най-малко два физически изчислителни възела;
- Инсталира и конфигурира компонента Ceilometer - ceilometer-agent-compute, работещ на всеки изчислителен възел, и Ceilometer API, както и събиране на следните показатели:
показател
обслужване
плъгини
коментар
cpu_util
нито един
памет.резидент
нито един
Параметри на стратегията:
параметър
тип
по подразбиране
описание
метрика
Низ
'cpu_util'
Основните показатели са: 'cpu_util', 'memory.resident'.
праг
Телефон за връзка:
25.0
Праг на натоварване за миграция.
период
Телефон за връзка:
300
Кумулативен период от време Ceilometer.
Използваният метод е миграция.
Стабилизирането на работното натоварване е стратегия, насочена към стабилизиране на натоварването чрез миграция на живо. Стратегията се основава на алгоритъм за стандартно отклонение и определя дали има задръстване в клъстера и реагира на него чрез задействане на миграция на машина за стабилизиране на клъстера.
Изисквания
- Използване на физически процесори;
- Най-малко два физически изчислителни възела;
- Инсталира и конфигурира компонента Ceilometer - ceilometer-agent-compute, работещ на всеки изчислителен възел, и Ceilometer API, както и събиране на следните показатели:
показател
обслужване
плъгини
коментар
cpu_util
нито един
памет.резидент
нито един
Стратегия за балансиране на капацитета за съхранение (стратегия, приложена, започвайки с Queens) - стратегията прехвърля дискове в зависимост от натоварването на пуловете Cinder. Решение за прехвърляне се взема всеки път, когато степента на използване на пула надвиши определен праг. Дискът, който се премества, трябва да доближи пула до средното натоварване на всички Cinder пулове.
Изисквания и ограничения
- Минимум два басейна Cinder;
- Възможност за дискова миграция.
- Модел на клъстерни данни - Колектор на модел на клъстерни данни на Cinder.
Параметри на стратегията:
параметър
тип
по подразбиране
описание
обем_праг
Телефон за връзка:
80.0
Прагова стойност на дисковете за балансиране на обеми.
Използваният метод е дискова миграция (volume_migrate).
Noisy Neighbor – Идентифицирайте и мигрирайте „шумен съсед“ – виртуална машина с нисък приоритет, която оказва отрицателно въздействие върху производителността на виртуална машина с висок приоритет по отношение на IPC чрез прекомерно използване на кеша от последно ниво. Собствена стратегия: Noisy Neighbor (използваният стратегически параметър е cache_threshold (стойността по подразбиране е 35), когато производителността падне до определената стойност, миграцията се стартира. За да работи стратегията, активирана Метрики на LLC (кеш от последно ниво), най-новият сървър на Intel с поддръжка на CMT, както и събиране на следните показатели:
показател
обслужване
плъгини
коментар
cpu_l3_cache
нито един
Изисква се Intel .
Модел на клъстерни данни (по подразбиране): Nova колектор на модел на клъстерни данни. Използваният метод е миграция.
Работата с тази цел чрез таблото за управление не е напълно внедрена в Queens.
Термична оптимизация — оптимизиране на температурния режим. Температурата на изхода (отработения въздух) е една от важните термални телеметрични системи за измерване на термичното/работното състояние на сървъра. Целта има една стратегия, базирана на изходяща температура стратегия, която решава да мигрира работните натоварвания към термично благоприятни хостове (най-ниска изходна температура), когато изходната температура на изходните хостове достигне конфигурируем праг.
За да работи стратегията, имате нужда от сървър с инсталиран и конфигуриран Intel Power Node Manager , както и събиране на следните показатели:
показател
обслужване
плъгини
коментар
hardware.ipmi.node.outlet_temperature
IPMI
Параметри на стратегията:
параметър
тип
по подразбиране
описание
праг
Телефон за връзка:
35.0
Температурен праг за миграция.
период
Телефон за връзка:
30
Интервалът от време в секунди за получаване на статистическата агрегация от източника на метрични данни.
Използваният метод е миграция.
Оптимизация на въздушния поток — оптимизирайте режима на вентилация. Собствена стратегия - Равномерен въздушен поток с помощта на миграция на живо. Стратегията задейства миграция на виртуална машина всеки път, когато въздушният поток от вентилатора на сървъра надвиши определен праг.
За да работи стратегията, трябва:
- Хардуер: изчислителни възли < поддържащи 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 или по-нова версия.
Ограничения: Концепцията не е предназначена за производство.
Предлага се този алгоритъм да се използва с непрекъснати одити, тъй като се планира само една виртуална машина да бъде мигрирана на итерация.
Възможни са живи миграции.
Параметри на стратегията:
параметър
тип
по подразбиране
описание
праг_въздушен поток
Телефон за връзка:
400.0
Прагът на въздушния поток за единица за миграция е 0.1 CFM
threshold_inlet_t
Телефон за връзка:
28.0
Праг на входящата температура за решение за миграция
прагова_мощност
Телефон за връзка:
350.0
Праг на мощността на системата за решение за миграция
период
Телефон за връзка:
30
Интервалът от време в секунди за получаване на статистическата агрегация от източника на метрични данни.
Използваният метод е миграция.
Хардуерна поддръжка — поддръжка на хардуер. Стратегията, свързана с тази цел, е Зонова миграция. Стратегията е инструмент за ефективна автоматична и минимална миграция на виртуални машини и дискове при нужда от хардуерна поддръжка. Стратегията изгражда план за действие в съответствие с теглата: набор от действия, който има по-голяма тежест, ще бъде планиран преди други. Има две опции за конфигурация: action_weights и parallelization.
Ограничения: теглата на действието и паралелизирането трябва да бъдат конфигурирани.
Параметри на стратегията:
параметър
тип
по подразбиране
описание
изчислителни_възли
масив
None
Изчислителни възли за миграция.
пулове_за съхранение
масив
None
Възли за съхранение за миграция.
паралелно_общо
цяло число
6
Общият брой дейности, които трябва да бъдат изпълнени паралелно.
паралелен_на_възел
цяло число
2
Броят действия, извършени паралелно за всеки изчислителен възел.
паралелен_на_пул
цяло число
2
Броят на действията, извършени паралелно за всеки пул за съхранение.
приоритет
обект
None
Списък с приоритети за виртуални машини и дискове.
с_прикачен_том
булева
Фалшив
False—виртуалните машини ще бъдат мигрирани, след като всички дискове бъдат мигрирани. Вярно – виртуалните машини ще бъдат мигрирани, след като всички свързани дискове бъдат мигрирани.
Елементи на масива от изчислителни възли:
параметър
тип
по подразбиране
описание
src_node
низ
None
Компютърният възел, от който се мигрират виртуалните машини (задължително).
dst_node
низ
None
Изчислете възела, към който мигрират виртуалните машини.
Елементи на масив от възли за съхранение:
параметър
тип
по подразбиране
описание
src_пул
низ
None
Пулът за съхранение, от който се мигрират дисковете (задължително).
dst_пул
низ
None
Пулът за съхранение, към който се мигрират дисковете.
src_type
низ
None
Оригинален тип диск (задължително).
dst_type
низ
None
Полученият тип диск (задължително).
Приоритетни елементи на обекта:
параметър
тип
по подразбиране
описание
проект
масив
None
Имена на проекти.
изчислителен_възел
масив
None
Имена на изчислителни възли.
хранилище_пул
масив
None
Имена на пулове за съхранение.
изчисление
преброяване
None
Параметри на виртуалната машина [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
съхранение
преброяване
None
Параметри на диска [“size”, “created_at”].
Използваните методи са миграция на виртуална машина, миграция на диск.
Некласифициран - спомагателна цел, използвана за улесняване на процеса на разработване на стратегия. Не съдържа спецификации и може да се използва, когато стратегията все още не е свързана със съществуваща цел. Тази цел може да се използва и като преходна точка. Свързана стратегия с тази цел е Actuator.
Създаване на нова цел
Наблюдател Decision Engine има интерфейс на плъгин „външна цел“, който прави възможно интегрирането на външна цел, която може да бъде постигната с помощта на стратегия.
Преди да създадете нова цел, трябва да се уверите, че нито една съществуваща цел не отговаря на вашите нужди.
Създаване на нов плъгин
За да създадете нова цел, трябва: да разширите целевия клас, да приложите метод на клас get_name() за да върнете уникалния идентификатор на новата цел, която искате да създадете. Този уникален идентификатор трябва да съответства на името на входната точка, което декларирате по-късно.
След това трябва да внедрите метода на класа get_display_name() за да върнете преведеното показвано име на целта, която искате да създадете (не използвайте променлива, за да върнете преведения низ, така че той да може да бъде събран автоматично от инструмента за превод.).
Приложете метод на клас get_translatable_display_name()за да върнете ключа за превод (всъщност английското екранно име) на вашата нова цел. Върнатата стойност трябва да съответства на низа, преведен в get_display_name().
Приложете неговия метод get_efficacy_specification()за да върнете спецификацията за ефективност за вашата цел. Методът get_efficacy_specification() връща екземпляра Unclassified(), предоставен от Watcher. Тази спецификация на ефективността е полезна в процеса на разработване на вашата цел, защото съответства на празната спецификация.
→
Архитектура на Watcher (повече подробности) ).
Елементи
API за наблюдение - компонент, който имплементира REST API, предоставен от Watcher. Механизми за взаимодействие: CLI, плъгин Horizon, Python SDK.
Наблюдател DB — База данни на наблюдателя.
Приложение за наблюдение — компонент, който изпълнява изпълнението на план за действие, създаден от компонента Watcher Decision Engine.
Наблюдател Decision Engine - Компонентът, отговорен за изчисляването на набор от потенциални оптимизационни действия за постигане на целта на одита. Ако стратегия не е посочена, компонентът самостоятелно избира най-подходящата.
Издател на показатели за наблюдение - Компонент, който събира и изчислява някои показатели или събития и ги публикува в крайната точка на CEP. Функционалността на компонента може да бъде предоставена и от издателя Ceilometer.
Механизъм за обработка на комплексни събития (CEP). — двигател за комплексна обработка на събития. От съображения за производителност може да има множество екземпляри на CEP Engine, работещи едновременно, като всеки обработва конкретен тип показател/събитие. В системата Watcher, CEP задейства два типа действия: - запис на съответните събития / показатели в базата данни с времеви редове; - изпращане на подходящи събития до Watcher Decision Engine, когато това събитие може да повлияе на резултата от текущата стратегия за оптимизация, тъй като клъстерът Openstack не е статична система.
Компонентите взаимодействат с помощта на протокола AMQP.
→
Схема на взаимодействие с Watcher
Резултати от теста на Watcher
- На страницата Optimization - Action plans 500 (както на чисти Queens, така и на стенд с модули Tionix) се появява само след стартиране на одита и генериране на план за действие, празният се отваря нормално.
- Има грешки в раздела с подробности за действието, не е възможно да се получи целта и стратегията на одита (както на чисти Queens, така и на щанд с Tionix модули).
- Одитите с цел Dummy (тест) се създават и стартират нормално, генерират се планове за действие.
- Одити за некласифицираната цел не се създават, тъй като целта не е функционална и е предназначена за междинна конфигурация при създаване на нови стратегии.
- Одитите за целите на балансиране на работното натоварване (стратегия за балансиране на капацитета за съхранение) са създадени успешно, но не се генерира план за действие. Не е необходима оптимизация на пула за съхранение.
- Одитите за целта за балансиране на работното натоварване (Стратегия за мигриране на баланса на работното натоварване) са създадени успешно, но не се генерира план за действие.
- Одитите за балансиране на работното натоварване (стратегия за стабилизиране на работното натоварване) са неуспешни.
- Одитите за целта Noisy Neighbor са създадени успешно, но не се генерира план за действие.
- Одитите за целите на поддръжката на хардуера са създадени успешно, планът за действие не е генериран изцяло (генерират се индикатори за ефективност, но не се генерира самият списък с действия).
- Редакциите в конфигурациите на nova.conf (в раздела по подразбиране compute_monitors = cpu.virt_driver) на изчислителните и контролните възли не коригират грешките.
- Одитите, насочени към консолидация на сървъри (базова стратегия), също са неуспешни.
- Одитите за целите на консолидацията на сървъра (стратегия за консолидиране на работното натоварване на VM) се провалят с грешка. В регистрационните файлове има грешка при получаване на изходни данни. По-специално обсъждане на грешката .
Опитахме се да посочим Watcher в конфигурационния файл (не помогна - в резултат на грешка на всички страници за оптимизация, връщането към оригиналното съдържание на конфигурационния файл не коригира ситуацията): [watcher_strategies.basic] източник на данни = обточен метър, ньоки - Одитите за спестяване на енергия са неуспешни. Съдейки по регистрационните файлове, проблемът все още е липсата на Ironic, няма да работи без baremetal услуга.
- Одитите за термична оптимизация са неуспешни. Проследяването е същото като за консолидация на сървър (стратегия за консолидиране на работното натоварване на VM) (грешка в изходните данни)
- Одитите за целите на оптимизирането на въздушния поток са неуспешни с грешка.
Срещат се и следните грешки при завършване на одита. Обратно проследяване в регистрационните файлове на decision-engine.log (състоянието на клъстера не е дефинирано).
→ Обсъждане на грешката
Заключение
Резултатът от нашето двумесечно проучване беше недвусмисленото заключение, че за да получим пълноценна, работеща система за балансиране на натоварването, в тази част ще трябва да работим в тясно сътрудничество по усъвършенстване на инструментите за платформата Openstack.
Watcher се доказа като сериозен и бързо развиващ се продукт с огромен потенциал, пълното използване на който ще изисква много сериозна работа.
Но повече за това в следващите статии от поредицата.
Източник: www.habr.com