Load Balancing во Openstack

Во големи облак системи, прашањето за автоматско балансирање или израмнување на оптоварувањето на компјутерските ресурси е особено акутно. За ова прашање се погрижи и Tionix (програмер и оператор на облак услуги, дел од групацијата на компании Ростелеком).

И, бидејќи нашата главна платформа за развој е Openstack, а ние, како и сите луѓе, сме мрзливи, беше одлучено да се избере некој готов модул што е веќе вклучен во платформата. Нашиот избор падна на Watcher, кој решивме да го искористиме за нашите потреби.

Прво, да ги погледнеме поимите и дефинициите.

Поими и дефиниции

цел е читлив, набљудуван и мерлив краен резултат кој мора да се постигне за човекот. Постојат една или повеќе стратегии за постигнување на секоја цел. Стратегија е имплементација на алгоритам кој е способен да најде решение за дадена цел.

Акција е елементарна задача која ја менува моменталната состојба на целниот управуван ресурс на кластерот OpenStack, како што се: мигрирање на виртуелна машина (миграција), промена на состојбата на моќност на јазол (change_node_power_state), промена на состојбата на услугата nova (change_nova_service_state ), менување на вкусот (промена на големина), регистрирање NOP пораки (nop), недостаток на дејство за одредено време - пауза (спиење), пренос на диск (volume_migrate).

План за акција - специфичен тек на акции извршени по одреден редослед за да се постигне одредена Цел. Акцискиот план содржи и измерени глобални перформанси со збир на индикатори за успешност. Акционен план е генериран од Watcher по успешна ревизија, како резултат на што користената стратегија наоѓа решение за постигнување на целта. Акциониот план се состои од листа на последователни дејства.

Ревизија е барање за оптимизирање на кластерот. Се врши оптимизација за да се постигне една Цел во даден кластер. За секоја успешна ревизија, Watcher генерира Акционен план.

Опсег на ревизија е збир на ресурси во кои се врши ревизијата (зони на достапност), агрегатори на јазли, поединечни пресметковни јазли или јазли за складирање итн.). Опсегот на ревизијата е дефиниран во секој образец. Ако опсегот на ревизија не е наведен, се врши ревизија на целиот кластер.

Шаблон за ревизија — зачуван сет на поставки за започнување ревизија. Потребни се шаблони за да се извршат ревизии повеќе пати со исти поставки. Шаблонот нужно мора да ја содржи целта на ревизијата; доколку стратегиите не се специфицирани, тогаш се избираат најсоодветните постоечки стратегии.

Грозд е збирка на физички машини кои обезбедуваат пресметување, складирање и мрежни ресурси и се управувани од истиот јазол за управување со OpenStack.

Модел на кластерски податоци (CDM) е логичен приказ на моменталната состојба и топологија на ресурсите со кои управува кластерот.

Индикатор за ефикасност - индикатор кој покажува како се изведува решението создадено со оваа стратегија. Индикаторите за успешност се специфични за одредена цел и вообичаено се користат за пресметување на глобалната ефективност на акциониот план што произлегува.

Спецификација за ефикасност е збир на специфични карактеристики поврзани со секоја Цел што ги дефинира различните показатели за успешност што стратегијата за постигнување на соодветната Цел мора да ги постигне во нејзиното решение. Навистина, секое решение предложено од стратегијата ќе биде проверено според спецификацијата пред да се пресмета неговата глобална ефективност.

Мотор за бодување е извршна датотека која има добро дефинирани влезови, добро дефинирани излези и извршува чисто математичка задача. На овој начин, пресметката е независна од околината во која се врши - ќе го даде истиот резултат насекаде.

Планер на набљудувач - дел од моторот за одлучување Watcher. Овој модул презема збир на дејства генерирани од стратегија и креира план за работниот тек кој одредува како да се закажат овие различни дејства на време и за секоја акција, кои се предусловите.

Цели и стратегии на Watcher

цел
стратегија

Лажна цел
Лажна стратегија 

Лажна стратегија користејќи примероци за бодување мотори

Лажна стратегија со промена на големината

Заштеда на енергија
Стратегија за заштеда на енергија

Консолидација на серверот
Основна консолидација на офлајн сервер

Стратегија за консолидација на обемот на работа на VM

Балансирање на обемот на работа
Стратегија за миграција на рамнотежа на обемот на работа

Стратегија за биланс на капацитет за складирање

Стабилизација на обемот на работа

Бучен сосед
Бучен сосед

Термичка оптимизација
Стратегија заснована на излезна температура

Оптимизација на протокот на воздух
Единствена стратегија за миграција на протокот на воздух

Одржување на хардвер
Миграција на зоната

некласифицирани
Побудувачкиот

Лажна цел — резервирана цел што се користи за тестирање.

Поврзани стратегии: Лажна стратегија, Лажна стратегија со користење на примероци на мотори за бодување и лажна стратегија со промена на големината. Лажна стратегија е лажна стратегија што се користи за тестирање за интеграција преку 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.

Основната стратегија за консолидација на офлајн сервер го минимизира вкупниот број на користени сервери и исто така го минимизира бројот на миграции.

Основната стратегија ги бара следните метрики:

метрички
Сервис
приклучоци
коментар

пресметај.јазол.cpu.процент
цеилометар
никој
 

cpu_util
цеилометар
никој
 

Параметри на стратегијата: migration_ttempts - број на комбинации за пребарување на потенцијални кандидати за исклучување (стандардно, 0, без ограничувања), период - временски интервал во секунди за да се добие статичка агрегација од метричкиот извор на податоци (стандардно, 700).

Користени методи: миграција, менување на состојбата на услугата nova (change_nova_service_state).

Стратегијата за консолидација на обемот на работа на VM се заснова на хеуристика за прво вклопување која се фокусира на измерено оптоварување на процесорот и се обидува да ги минимизира јазлите кои имаат премногу или премалку оптоварување со оглед на ограничувањата на капацитетот на ресурсите. Оваа стратегија обезбедува решение што резултира со поефикасно користење на ресурсите на кластерот користејќи ги следните четири чекори:

1. Фаза на растоварање - обработка на прекумерно искористени ресурси;
2. Фаза на консолидација - обработка на недоволно искористените ресурси;
3. Оптимизација на решението - намалување на бројот на миграции;
4. Оневозможување на неискористени пресметковни јазли.

Стратегијата ги бара следните метрики:

метрички
Сервис
приклучоци
коментар

меморија
цеилометар
никој
 

диск.корен.големина
цеилометар
никој
 

Следниве метрики се опционални, но ќе ја подобрат точноста на стратегијата доколку се достапни:

метрички
Сервис
приклучоци
коментар

меморија.жител
цеилометар
никој
 

cpu_util
цеилометар
никој
 

Стратешки параметри: период — временски интервал во секунди за да се добие статичка агрегација од метричкиот извор на податоци (стандардно, 3600).

Ги користи истите методи како и претходната стратегија. Повеќе детали тука.

Балансирање на обемот на работа — избалансирајте го обемот на работа помеѓу компјутерските јазли. Целта има три стратегии: Стратегија за миграција на рамнотежа на обемот на работа, стабилизација на обемот на работа, стратегија за рамнотежа на капацитет за складирање.

Стратегијата за миграција на билансот на обемот на работа извршува миграции на виртуелната машина врз основа на обемот на работа на домаќинот на виртуелната машина. Одлуката за миграција се донесува секогаш кога % искористеноста на процесорот или RAM меморијата на јазолот го надминува наведениот праг. Во овој случај, поместената виртуелна машина треба да го доближи јазолот до просечниот обем на работа на сите јазли.

Барања

• Употреба на физички процесори;
• Најмалку два физички пресметувачки јазли;
• Инсталирана и конфигурирана компонентата Ceilometer - ceilometer-agent-compute, која работи на секој компјутерски јазол и Ceilometer API, како и собирање на следните метрики:

метрички
Сервис
приклучоци
коментар

cpu_util
цеилометар
никој
 

меморија.жител
цеилометар
никој
 

Параметри на стратегијата:

параметар
Тип
стандардно
описание

метрика
Стринг
'cpu_util'
Основните метрики се: „cpu_util“, „memory.resident“.

праг
Број
25.0
Праг на обемот на работа за миграција.

период
Број
300
Кумулативен временски период Цеилометар.

Методот што се користи е миграција.

Стабилизацијата на обемот на работа е стратегија насочена кон стабилизирање на обемот на работа користејќи жива миграција. Стратегијата се заснова на алгоритам за стандардно отстапување и одредува дали има застој во кластерот и реагира на тоа со активирање на миграција на машината за стабилизирање на кластерот.

Барања

• Употреба на физички процесори;
• Најмалку два физички пресметувачки јазли;
• Инсталирана и конфигурирана компонентата Ceilometer - ceilometer-agent-compute, која работи на секој компјутерски јазол и Ceilometer API, како и собирање на следните метрики:

метрички
Сервис
приклучоци
коментар

cpu_util
цеилометар
никој
 

меморија.жител
цеилометар
никој
 

Стратегија за рамнотежа на капацитет за складирање (стратегија имплементирана почнувајќи од Квинс) - стратегијата пренесува дискови во зависност од оптоварувањето на базените на Cinder. Одлуката за трансфер се носи секогаш кога стапката на искористеност на базенот надминува одреден праг. Дискот што се преместува треба да го доближи базенот до просечното оптоварување на сите базени на Cinder.

Барања и ограничувања

• Минимум два базени Cinder;
• Можност за миграција на дискот.
• Модел на кластерски податоци - Собирач на модели на податоци од кластерот Cinder.

Параметри на стратегијата:

параметар
Тип
стандардно
описание

волумен_праг
Број
80.0
Празна вредност на дисковите за балансирање на волумени.

Методот што се користи е миграција на дискот (volume_migrate).

Noisy Neighbor - Идентификувајте и мигрирајте „бучен сосед“ - виртуелна машина со низок приоритет што негативно влијае на перформансите на виртуелната машина со висок приоритет во однос на IPC со прекумерна употреба на кешот на последното ниво. Сопствена стратегија: Noisy Neighbor (користен параметар на стратегијата е cache_threshold (стандардната вредност е 35), кога перформансите паѓаат на одредената вредност, започнува миграцијата. За стратегијата да работи, овозможено LLC (Кеш на последно ниво) метрика, најновиот Intel сервер со CMT поддршка, како и собирање на следните метрики:

метрички
Сервис
приклучоци
коментар

cpu_l3_cache
цеилометар
никој
Се бара Intel CMT.

Модел на кластерски податоци (стандардно): Нов кластерски колектор на модели на податоци. Методот што се користи е миграција.

Работата со оваа цел преку контролната табла не е целосно имплементирана во Квинс.

Термичка оптимизација — оптимизирајте го температурниот режим. Температурата на излезот (издувниот воздух) е еден од важните системи за термичка телеметрија за мерење на статусот на топлинска/оптовареност на серверот. Целта има една стратегија, стратегија заснована на температура на излезот, која одлучува да мигрира оптоварување на термички поволни домаќини (најниска излезна температура) кога температурата на излезот на изворните домаќини ќе достигне праг што може да се конфигурира.

За да функционира стратегијата, потребен ви е сервер со инсталиран и конфигуриран Intel Power Node Manager 3.0 или подоцна, како и собирање на следните метрики:

метрички
Сервис
приклучоци
коментар

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.1CFM

threshold_inlet_t
Број
28.0
Праг на влезната температура за одлука за миграција

праг_моќ
Број
350.0
Праг на моќност на системот за одлука за миграција

период
Број
30
Временскиот интервал, во секунди, за да се добие статистичката агрегација од метричкиот извор на податоци.

Методот што се користи е миграција.

Одржување на хардвер — одржување на хардверот. Стратегијата поврзана со оваа цел е миграција на зоната. Стратегијата е алатка за ефективна автоматска и минимална миграција на виртуелни машини и дискови во случај на потреба од одржување на хардверот. Стратегијата гради план за акција во согласност со тежините: збир на дејства што имаат поголема тежина ќе бидат планирани пред другите. Постојат две опции за конфигурација: action_weights и паралелизација.

Ограничувања: треба да се конфигурираат тежини за акција и паралелизација.

Параметри на стратегијата:

параметар
Тип
стандардно
описание

пресметани_јазли
низа
Никој
Пресметајте јазли за миграција.

складирање_базени
низа
Никој
Јазли за складирање за миграција.

паралелно_вкупно
број
6
Вкупниот број на активности кои мора да се извршуваат паралелно.

паралелно_на_јазол
број
2
Бројот на дејства извршени паралелно за секој компјутерски јазол.

паралелно_по_базен
број
2
Бројот на дејства извршени паралелно за секој базен за складирање.

приоритет
објект
Никој
Список на приоритети за виртуелни машини и дискови.

со_прикачен_том
boolean
Лажни
Неточно - виртуелните машини ќе се мигрираат откако ќе се мигрираат сите дискови. Точно - виртуелните машини ќе се мигрираат откако ќе се мигрираат сите поврзани дискови.

Елементи од низата компјутерски јазли:

параметар
Тип
стандардно
описание

src_node
низа
Никој
Пресметувачкиот јазол од кој се мигрираат виртуелните машини (задолжително).

dst_node
низа
Никој
Пресметајте го јазолот до кој мигрираат виртуелните машини.

Елементи на низа од јазли за складирање:

параметар
Тип
стандардно
описание

src_pool
низа
Никој
Базенот за складирање од кој се мигрираат дисковите (задолжително).

dst_pool
низа
Никој
Базен за складирање на кој се мигрираат дисковите.

src_type
низа
Никој
Оригинален тип на диск (задолжителен).

dst_type
низа
Никој
Добиениот тип на диск (задолжителен).

Приоритетни елементи на објектот:

параметар
Тип
стандардно
описание

проект
низа
Никој
Имиња на проекти.

пресметување_јазол
низа
Никој
Пресметајте ги имињата на јазлите.

складирање_базен
низа
Никој
Имиња на базени за складирање.

пресмета
енум
Никој
Параметри на виртуелната машина [„vcpu_num“, „mem_size“, „disk_size“, „created_at“].

складирање
енум
Никој
Параметри на дискот [„големина“, „created_at“].

Користените методи се миграција на виртуелна машина, миграција на дискот.

некласифицирани - помошна цел што се користи за олеснување на процесот на развој на стратегијата. Не содржи спецификации и може да се користи секогаш кога стратегијата сè уште не е поврзана со постоечка цел. Оваа цел може да се користи и како преодна точка. Поврзана стратегија со оваа цел е Actuator.   

Создавање нова цел

Мотор за одлучување на гледачот има интерфејс за приклучок „надворешна цел“ што овозможува интегрирање на надворешна цел што може да се постигне со помош на стратегија.

Пред да креирате нова цел, треба да бидете сигурни дека ниту една постојна цел не ги задоволува вашите потреби.

Креирање на нов приклучок

За да креирате нова цел, мора: да ја проширите целната класа, да имплементирате метод на класа get_name () да го вратите единствениот ID на новата цел што сакате да ја креирате. Овој уникатен идентификатор мора да одговара на името на влезната точка што ќе го пријавите подоцна.

Следно, треба да го имплементирате методот на класа 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.

Watcher DB — База на податоци на Watcher.

Апликатор Watcher — компонента што го имплементира извршувањето на акциониот план креиран од компонентата Watcher Decision Engine.

Мотор за одлучување на гледачот - Компонентата одговорна за пресметување на збир на потенцијални оптимизациски дејства за да се постигне целта на ревизијата. Ако стратегијата не е наведена, компонентата самостојно ја избира најсоодветната.

Издавач на Watcher Metrics - Компонента која собира и пресметува некои метрики или настани и ги објавува до крајната точка на CEP. Функционалноста на компонентата може да ја обезбеди и издавачот Ceilometer.

Мотор за комплексна обработка на настани (CEP). — мотор за сложена обработка на настани. Од причини за изведба, може да има повеќе примероци на CEP Engine кои работат истовремено, при што секој обработува специфичен тип на метрика/настан. Во системот Watcher, CEP активира два типа на дејства: - запишување на соодветните настани / метрика во базата на податоци за временски серии; - испратете соодветни настани до Watcher Decision Engine кога овој настан може да влијае на резултатот од тековната стратегија за оптимизација, бидејќи кластерот Openstack не е статичен систем.

Компонентите комуницираат со помош на протоколот AMQP.

→ Конфигурирање на Watcher

Шема на интеракција со Watcher

Резултати од тестот Watcher

1. На страницата Оптимизација - Акциони планови 500 (и на чисти Queens и на штанд со модули на Tionix), се појавува само откако ќе се започне ревизијата и ќе се генерира акционен план; празниот се отвора нормално.
2. Има грешки на картичката Детали за акција, не е можно да се добие целта и стратегијата на ревизијата (и на чисти Queens и на штанд со модули на Tionix).
3. Ревизиите со цел Dummy (тест) се креираат и започнуваат нормално, се генерираат акциони планови.
4. Ревизии за целта Некласифицирана не се креираат бидејќи целта не е функционална и е наменета за средна конфигурација при креирање на нови стратегии.
5. Ревизиите за целите на балансирање на обемот на работа (стратегија на рамнотежа на капацитет за складирање) се успешно креирани, но акционен план не е генериран. Не е потребна оптимизација на базенот за складирање.
6. Ревизиите за целта за балансирање на обемот на работа (Стратегија за миграција на рамнотежа на работа) се успешно креирани, но акционен план не е генериран.
7. Ревизиите за балансирање на обемот на работа (Стратегија за стабилизација на обемот на работа) не успеваат.
8. Ревизиите за целта Noisy Neighbor се успешно креирани, но акционен план не е генериран.
9. Ревизиите за одржување на хардверот се успешно креирани, акциониот план не се генерира во целост (генерирани се индикатори за успешност, но самата листа на дејства не е генерирана).
10. Уредувањата во конфигурациите nova.conf (во стандардниот дел compute_monitors = cpu.virt_driver) на пресметковните и контролните јазли не ги поправаат грешките.
11. Ревизиите за намената Консолидација на серверот (Основна стратегија) исто така не успеваат.
12. Ревизиите за целите на Консолидација на серверот (стратегија за консолидација на обемот на работа на VM) не успеваат со грешка. Во дневниците има грешка при добивање на изворни податоци. Дискусија за грешката, особено тука.
    Се обидовме да го наведеме Watcher во конфигурациската датотека (не помогна - како резултат на грешка на сите страници за оптимизација, враќањето на оригиналната содржина на конфигурациската датотека не ја коригира ситуацијата):
    [watcher_strategies.basic] извор на податоци = целометар, њоки
13. Ревизиите за заштеда на енергија не успеваат. Судејќи според дневниците, проблемот е сепак отсуството на Ironic, тој нема да работи без бареметал сервис.
14. Ревизиите за термичка оптимизација не успеваат. Следењето е исто како и за консолидација на сервер (стратегија за консолидација на обемот на работа на VM) (грешка на изворните податоци)
15. Ревизиите за целите на оптимизацијата на протокот на воздух не успеваат со грешка.

Се среќаваат и следните грешки при завршувањето на ревизијата. Повторно следење во дневниците на engine-engine.log (состојбата на кластерот не е дефинирана).

→ Дискусија за грешката тука

Заклучок

Резултатот од нашето двомесечно истражување беше недвосмислениот заклучок дека за да се добие полноправен, работен систем за балансирање на оптоварување, во овој дел ќе треба тесно да работиме на рафинирање на алатките за платформата Openstack.

Watcher се покажа како сериозен и брзо развивачки производ со огромен потенцијал, чија целосна употреба ќе бара многу сериозна работа.

Но, повеќе за ова во следните написи од серијата.

Извор: www.habr.com