Vo veľkých cloudových systémoch sa najmä vynára otázka automatického vyváženia alebo vyrovnávania zaťaženia výpočtových zdrojov. Tento problém si uvedomila aj spoločnosť Tionix (vývojár a prevádzkovateľ cloudových služieb, patríme do skupiny spoločností Rostelecom).
A pretože našou hlavnou vývojovou platformou je OpenStack, a sme, ako každý, leniví, rozhodli sme sa vybrať nejaký hotový modul, ktorý už je súčasťou platformy. Naším výberom bol Watcher, ktorý sme sa rozhodli využiť na naše potreby.
Na začiatok si objasníme pojmy a definície.
Pojmy a definície
Cieľ — je to človeku zrozumiteľný, pozorovateľný a merateľný konečný výsledok, ktorý má byť dosiahnutý. Na dosiahnutie každého cieľa existuje jedna alebo viacero stratégií. Stratégia je realizácia algoritmu, ktorý dokáže nájsť riešenie pre daný cieľ.
Akcia (Action) — je to elementárna úloha, ktorá mení aktuálny stav riadeného zdroja klastru OpenStack, ako napríklad: migrácia virtuálnej mašiny (migration), zmena stavu napájania uzla (change_node_power_state), zmena stavu služby nova (change_nova_service_state), zmena typu (resize), registrácia správy NOP (nop), absencia akcií počas určitého časového obdobia — pauza (sleep), presun disku (volume_migrate).
Akčný plán (Action Plan) — je to špecifický sled akcií, vykonaných v určenom poradí s cieľom dosiahnuť konkrétny cieľ. Akčný plán taktiež obsahuje hodnotenú globálnu efektívnosť s množinou výkonových ukazovateľov. Akčný plán generuje Watcher po úspešnom audite, v dôsledku ktorého použitá stratégia nájde riešenie na dosiahnutie cieľa. Akčný plán sa skladá zo zoznamu sekvenčných akcií.
Audit (Audit) — je to požiadavka na optimalizáciu klastru. Optimalizácia sa vykonáva s cieľom dosiahnuť jeden cieľ v danom klastri. Pre každý úspešný audit Watcher generuje akčný plán.
Oblasť auditu (Audit Scope) — je súbor zdrojov, v rámci ktorého sa vykonáva audit (zóny dostupnosti, agregátory uzlov, samostatné výpočtové uzly alebo úložné uzly atď.). Oblasť auditu je definovaná v každej šablóne. Ak oblasť auditu nie je určená, vykonáva sa audit celého klastrom.
Šablóna auditu (Audit Template) — uložený súbor nastavení na spustenie auditu. Šablóny sú potrebné na opakované spúšťanie auditov s rovnakými nastaveniami. Šablóna musí obsahovať cieľ auditu; ak nie sú uvedené stratégie, vyberajú sa najvhodnejšie z existujúcich stratégií.
Klastor (Cluster) — je súbor fyzických strojov, ktoré poskytujú výpočtové zdroje, zdroje úložiska a sieťové zdroje a spravujú sa jedným a tým istým riadiacim uzlom OpenStack.
Model dát klastru (Cluster Data Model, CDM) — je logické znázornenie aktuálneho stavu a topológie riadených zdrojov klastru.
Ukazovateľ účinnosti (Efficacy Indicator) — ukazovateľ, ktorý naznačuje, ako dobre je riešenie vypracované pomocou danej stratégie. Ukazovatele účinnosti sú špecifické pre konkrétny cieľ a zvyčajne sa používajú na výpočet celkovej účinnosti konečného plánu akcií.
Špecifikácia účinnosti (Efficacy Specification) — je súbor špecifických vlastností spojených s každým cieľom, ktorý určuje rôzne ukazovatele účinnosti, ktoré musí stratégia zabezpečiť vo svojom riešení na dosiahnutie príslušného cieľa. Všetky riešenia navrhnuté stratégiou budú skontrolované na zhodu so špecifikáciou pred tým, než sa vypočíta ich celková účinnosť.
„Počítajúci“ motor (Scoring Engine) — je spustiteľný súbor, ktorý má presne definované vstupy, presne definované výstupy a vykonáva čisto matematickú úlohu. Takže výpočet nezávisí od prostredia, v ktorom sa vykonáva, — poskytne rovnaký výsledok kdekoľvek.
Watcher plánovač (Watcher Planner) — súčasť rozhodovacieho mechanizmu Watcher. Tento modul prijíma súbor akcií generovaných stratégiou a vytvára plán pracovného postupu, ktorý určuje, ako časovať tieto rôzne akcie a pre každú akciu, aké sú predpoklady.
Ciele a stratégie Watcher
Cieľ
Stratégie
Dummy cieľ
Dummy stratégia
Dummy stratégia používajúca vzorové hodnotiace motory
Dummy stratégia s premenou veľkosti
Úspora energie
Stratégia úspory energie
Konsolidácia serverov
Základná offline konsolidácia serverov
Stratégia konsolidácie pracovnej záťaže VM
Vyváženie pracovnej záťaže
Stratégia migrácie vyváženia pracovnej záťaže
Stratégia vyváženia kapacity úložiska
Stabilizácia pracovnej záťaže
Hlučný sused
Hlučný sused
Tepelná optimalizácia
Stratégia založená na teplote výstupu
Optimalizácia prúdenia vzduchu
Stratégia migrácie rovnomerného prúdenia vzduchu
Údržba hardvéru
Migrácia zóny
Nezaradené
Akčný člen
Dummy cieľ — rezervovaný cieľ, ktorý sa používa na testovanie (reserved goal that is used for testing purposes).
Súvisiace stratégie: Dummy stratégia, Dummy stratégia používajúca vzorové hodnotiace motory a Dummy stratégia s premenou veľkosti. Dummy stratégia — fiktívna stratégia používaná na integračné testovanie pomocou Tempest. Táto stratégia neposkytuje žiadnu užitočnú optimalizáciu, jej jediným cieľom je používať testy Tempest.
Dummy stratégia používajúca vzorové hodnotiace motory — stratégia je podobná predchádzajúcej, líši sa iba použitím vzorového "hodnotiaceho motora", ktorý vedie vyhodnotenie pomocou metód strojového učenia.
Dummy stratégia s premenou veľkosti — stratégia je podobná predchádzajúcej, líši sa iba použitím zmeny veľkosti (migrácia a zmenšenie).
Nepoužíva sa v produkcii.
Úspora energie — minimalizovať spotrebu energie. Stratégia tohto cieľa Stratégia úspory energie v kombinácii so stratégiou konsolidácie pracovnej záťaže VM (Konsolidácia serverov) je schopná vykonávať funkcie dynamického riadenia napájania (DPM), ktoré šetria elektrickú energiu pomocou dynamickej konsolidácie pracovných záťaží aj počas období nízkej záťaže zdrojov: virtuálne stroje sú presúvané na menší počet uzlov, a nepotrebné uzly sú vypínané. Po konsolidácii stratégia navrhuje riešenie na zapínanie/vypínanie uzlov v súlade so stanovenými parametrami: "min_free_hosts_num" — počet voľných zapnutých uzlov, ktoré čakajú na záťaž, a "free_used_percent" — percentuálny pomer voľných zapnutých uzlov k počtu uzlov, ktoré sú obsadené strojmi. Pre fungovanie stratégie musí byť zapnutý a nastavený Ironic na fungovanie so zapínaním/vypínaním napájania na uzloch.
Parametre stratégie
parameter
typ
predvolene
popis
percento_voľných_zdrojov
Číslo
10.0
pomer počtu voľných výpočtových uzlov k počtu výpočtových uzlov s virtuálnymi strojmi
min_num_voľných_uzlov
Int
1
minimálny počet voľných výpočtových uzlov
V cloude by mali byť aspoň dva uzly. Použitá metóda - zmena stavu napájania uzla (change_node_power_state). Stratégia nevyžaduje zber metrík.
Server Consolidation - minimalizovať počet výpočtových uzlov (konzolidácia). Má dve stratégie: Basic Offline Server Consolidation a VM Workload Consolidation Strategy.
Stratégia Basic Offline Server Consolidation minimalizuje celkový počet používaných serverov, ako aj minimalizuje počet migrácií.
Základná stratégia vyžaduje nasledujúce metrík:
metrika
služba
pluginy
komentár
compute.node.cpu.percent
none
cpu_util
none
Parametre stratégie: migration_attempts - počet kombinácií na vyhľadávanie potenciálnych kandidátov na vypnutie (podľa predvolieb 0, bez obmedzení), period - interval času v sekundách na získanie statickej agregácie z zdroja dát metrík (podľa predvolieb 700).
Použité metódy: migrácia, zmena stavu služby nova (change_nova_service_state).
Stratégia VM Workload Consolidation Strategy je založená na heuristickom algoritme prvého vyhovujúceho (first-fit), ktorý sa sústreďuje na nameranú záťaž CPU a snaží sa minimalizovať uzly, ktoré majú príliš vysokú alebo príliš nízku záťaž s ohľadom na obmedzenia kapacity zdrojov. Táto stratégia poskytuje riešenie, ktoré vedie k efektívnejšiemu využívaniu zdrojov clustra v štyroch fázach:
- Fáza uvoľnenia - spracovanie nadmerne využívaných zdrojov;
- Fáza konsolidácie - spracovanie nedostatočne využívaných zdrojov;
- Optimalizácia riešenia - zníženie počtu migrácií;
- Vypínanie nevyužívaných výpočtových uzlov.
Stratégia vyžaduje nasledujúce metrík:
metrika
služba
pluginy
komentár
memory
none
disk.root.size
none
Nasledujúce metrík nie sú povinné, ale zlepšujú presnosť stratégie, ak sú dostupné:
metrika
služba
pluginy
komentár
memory.resident
none
cpu_util
none
Parametre stratégie: period - interval času v sekundách na získanie statickej agregácie z zdroja dát metrík (podľa predvolieb 3600).
Používa tie isté metódy ako predchádzajúca stratégia. Podrobnosti .
Vyváženie pracovnej záťaže — vyvážiť pracovnú záťaž medzi výpočtovými uzlami. Cieľ má tri stratégie: Stratégia migrácie pracovníckej záťaže, Stabilizácia pracovnej záťaže, Stratégia balansovania kapacity úložiska.
Stratégia migrácie pracovnej záťaže spúšťa migrácie virtuálnych strojov na základe pracovnej záťaže virtuálnych strojov uzlov. Rozhodnutie o presune sa prijíma vždy, keď % využitia CPU alebo RAM uzla presahuje stanovený prah. Pri tom presúvaný virtuálny stroj by mal priblížiť uzol k priemernej pracovnej záťaži všetkých uzlov.
Požiadavky
- Používanie fyzických procesorov;
- Minimálne dva fyzické výpočtové uzly;
- Nastavená a nakonfigurovaná zložka Ceilometer — ceilometer-agent-compute, fungujúca na každom výpočtovom uzle, a Ceilometer API, ako aj zber nasledujúcich metrík:
metrika
služba
pluginy
komentár
cpu_util
none
memory.resident
none
Parametre stratégie:
parameter
typ
predvolene
popis
metrics
String
'cpu_util'
Metriky, ktoré sú základom: 'cpu_util', 'memory.resident'.
threshold
Číslo
25.0
Prahová hodnota pracovnej záťaže pre migráciu.
period
Číslo
300
Súhrnný časový úsek Ceilometer.
Použitá metóda — migrácia.
Stabilizácia pracovnej záťaže — stratégia zameraná na stabilizáciu pracovnej záťaže pomocou živých migrácií. Stratégia je založená na algoritmoch štandardného odchýlenia a určuje, či existuje preťaženie v clustre, a reaguje na toto preťaženie spustením migrácie strojov na stabilizáciu clustra.
Požiadavky
- Používanie fyzických procesorov;
- Minimálne dva fyzické výpočtové uzly;
- Nastavená a nakonfigurovaná zložka Ceilometer — ceilometer-agent-compute, fungujúca na každom výpočtovom uzle, a Ceilometer API, ako aj zber nasledujúcich metrík:
metrika
služba
pluginy
komentár
cpu_util
none
memory.resident
none
Stratégia balansovania kapacity úložiska (stratégia je implementovaná od verzie Queens) — stratégia presúva disky v závislosti od zaťaženia bazénov Cinder. Rozhodnutie o presune sa prijíma vždy, keď koeficient využitia bazéna presahuje stanovený prah. Presúvaný disk by mal priblížiť bazén k priemernej záťaži všetkých bazénov Cinder.
Požiadavky a obmedzenia
- Minimálne dva bazény Cinder;
- Možnosť migrácie diskov.
- Model dát clustra — zber dát o clustri Cinder.
Parametre stratégie:
parameter
typ
predvolene
popis
volume_threshold
Číslo
80.0
Prahová hodnota diskov na balansovanie objemov.
Použitá metóda — migrácia disku (volume_migrate).
Noisy Neighbor — identifikácia a presun „hlučného suseda“ — virtuálnej mašiny s nízkou prioritou, ktorá negatívne ovplyvňuje výkon virtuálnej mašiny s vysokou prioritou z hľadiska IPC, nadmerne používanie Last Level Cache. Vlastná stratégia: Noisy Neighbor (používaný parameter stratégie — cache_threshold (predvolená hodnota — 35), pri poklese výkonu na uvedenú hodnotu sa spúšťa migrácia. Pre fungovanie stratégie sú potrebné zapnuté LLC (Last Level Cache) metriky, posledný Intel server s podporou CMT, ako aj zber nasledujúcich metriky:
metrika
služba
pluginy
komentár
cpu_l3_cache
none
Potrebný Intel .
Model údajov klastra (predvolené): Nova cluster data model collector. Používaná metóda — migrácia.
Práca s touto úlohou cez Dashboard nie je v plnej miere implementovaná v Queens.
Tepelná optimalizácia — optimalizovať teplotný režim. Teplota na výstupe (odpadový vzduch) je jedným z dôležitých tepelných telemetrických systémov na meranie stavu tepelnej / pracovnej záťaže servera. Pre cieľ je k dispozícii jedna stratégia — Outlet temperature based strategy, ktorá rozhoduje o presune pracovných záťaží na uzly s priaznivým teplotným režimom (najnižšia teplota na výstupe), keď teplota na výstupe pôvodných hostiteľov dosiahne nastaviteľný prah.
Pre fungovanie stratégie je potrebný server s nainštalovaným a nastaveným Intel Power Node Manager , ako aj zber nasledujúcich metriky:
metrika
služba
pluginy
komentár
hardware.ipmi.node.outlet_temperature
IPMI
Parametre stratégie:
parameter
typ
predvolene
popis
threshold
Číslo
35.0
Teplotný prah pre migráciu.
period
Číslo
30
Interval času v sekundách na získanie štatistickej agregácie zo zdroja dát metriky.
Použitá metóda — migrácia.
Optimalizácia prúdenia vzduchu — optimalizovať režim vetrania. Vlastná stratégia — Uniform Airflow using live migration. Stratégia spúšťa migráciu virtuálnej mašiny vždy, keď prietok vzduchu od ventilátora servera presiahne uvedený prah.
Pre fungovanie stratégie sú potrebné:
- Hardvér: výpočtové uzly <s podporou NodeManager 3.0;
- Minimálne dva výpočtové uzly;
- Nainštalovaný a nastavený na každom výpočtovom uzle komponent ceilometer-agent-compute a Ceilometer API, ktoré môže úspešne hlásiť také metriky ako prietok vzduchu, výkon systému, teplota na vstupe:
metrika
služba
pluginy
komentár
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Na realizáciu stratégie je potrebný server so nainštalovaným a nakonfigurovaným Intel Power Node Manager 3.0 alebo novšej verzie.
Obmedzenia: Koncepcia nie je určená na produkčné prostredie.
Odporúča sa používať tento algoritmus s nepretržitými auditmi, pretože v rámci jednej iterácie je plánovaná migrácia iba jednej virtuálnej mašiny.
Živé migrácie sú možné.
Parametre stratégie:
parameter
typ
predvolene
popis
threshold_airflow
Číslo
400.0
Práhová hodnota prúdenia vzduchu pre migráciu je 0.1CFM
threshold_inlet_t
Číslo
28.0
Práhová teplota vstupu na rozhodovanie o migrácii
threshold_power
Číslo
350.0
Práhová hodnota výkonu pre rozhodovanie o migrácii
period
Číslo
30
Interval času v sekundách na získanie štatistickej agregácie zo zdroja dát metriky.
Použitá metóda — migrácia.
Údržba hardvéru — údržba hardvérových prostriedkov. Stratégia vzťahujúca sa k tomuto cieľu — Zónová migrácia. Stratégia slúži ako nástroj pre efektívnu automatickú a minimálnu migráciu virtuálnych strojov a diskov v prípade potreby vykonania technickej údržby hardvérových prostriedkov. Stratégia vytvára plán akcií na základe váh: súbor akcií, ktorý má väčšiu váhu, sa naplánuje skôr ako ostatné. Existujú dva konfiguračné parametre: váhy akcií (action_weights) a paralelizácia (parallelization).
Obmedzenia: je potrebné nastaviť váhy akcií a paralelizáciu.
Parametre stratégie:
parameter
typ
predvolene
popis
compute_nodes
array
None
Počítačové uzly pre migráciu.
storage_pools
array
None
Uzly úložiska pre migráciu.
parallel_total
integer
6
Celkový počet akcií, ktoré sa majú vykonávať paralelne.
parallel_per_node
integer
2
Počet akcií vykonávaných súčasne pre každý počítačový uzol.
parallel_per_pool
integer
2
Počet akcií vykonávaných súčasne pre každý úložný pool.
priority
object
None
Zoznam priorít pre virtuálne stroje a disky.
with_attached_volume
boolean
False
False — virtuálne stroje budú presunuté po presune všetkých diskov. True — virtuálne stroje budú presunuté po migrácii všetkých pripojených diskov.
Prvky poľa počítačových uzlov:
parameter
typ
predvolene
popis
src_node
string
None
Počítačový uzol, z ktorého sa prenášajú virtuálne stroje (povinné).
dst_node
string
None
Počítačový uzol, na ktorý sa migrujú virtuálne stroje.
Prvky poľa uzlov úložiska:
parameter
typ
predvolene
popis
src_pool
string
None
Úložný pool, z ktorého sa prenášajú disky (povinné).
dst_pool
string
None
Úložný pool, na ktorý sa prenášajú disky.
src_type
string
None
Typ disku pôvodu (povinné).
dst_type
string
None
Konečný typ disku (povinné).
Prvky prioritizácie objektov:
parameter
typ
predvolene
popis
project
array
None
Názvy projektov.
compute_node
array
None
Názvy počítačových uzlov.
storage_pool
array
None
Názvy úložných poolov.
compute
enum
None
Parametre virtuálneho stroja [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
úložisko
enum
None
Parametre diskov [“size”, “created_at”].
Použité metódy — migrácia virtuálnych strojov, migrácia diskov.
Nezaradené — pomocný cieľ, používaný na zjednodušenie procesu vývoja stratégie. Neobsahuje špecifikácie a môže sa používať, keď stratégia ešte nie je spojená s existujúcim cieľom. Tento cieľ môže byť tiež použitý ako prechodná fáza. So svojím cieľom súvisiaca stratégia — Actuator.
Vytvorenie nového cieľa
Watcher Decision Engine má rozhranie pluginu “vonkajšej cieľa”, ktoré umožňuje integrovať vonkajší cieľ, ktorý môže byť dosiahnutý pomocou stratégie.
Pred vytvorením nového cieľa by ste sa mali uistiť, že žiaden z existujúcich cieľov nespĺňa vaše požiadavky.
Vytvorenie nového pluginu
Aby ste vytvorili nový cieľ, musíte: rozšíriť triedu cieľa, implementovať metódu triedy get_name () na vrátenie jedinečného identifikátora nového cieľa, ktorý chcete vytvoriť. Tento jedinečný identifikátor musí zodpovedať názvu vstupného bodu, ktorý deklarujete neskôr.
Následne je potrebné implementovať metódu triedy get_display_name () na vrátenie preloženého zobrazeného názvu cieľa, ktorý chcete vytvoriť (nepoužívajte premennú na vrátenie preloženého reťazca, aby mohla byť automaticky zhromaždená nástrojom prekladu).
Implementujte metódu triedy get_translatable_display_name (), aby ste vrátili kľúč prekladu (v skutočnosti anglický zobrazený názov) vášho nového cieľa. Návratová hodnota musí zodpovedať reťazcu, ktorý bol preložený v get_display_name ().
Implementujte jeho metódu get_efficacy_specification (), aby ste vrátili špecifikáciu účinnosti pre váš cieľ. Metóda get_efficacy_specification () vracia inštanciu Unclassified (), ktorú poskytol Watcher. Táto špecifikácia účinnosti je užitočná v procese vývoja vášho cieľa, pretože zodpovedá prázdnej špecifikácii.
→
Architektúra Watchera (viac ).
Komponenty
Watcher API — komponent, ktorý implementuje REST API poskytované Watcherom. Mechanizmy interakcie: CLI, plugin Horizon, Python SDK.
Watcher DB — databáza Watcher.
Watcher Applier — komponent, ktorý implementuje vykonávanie akčného plánu, ktorý vytvoril komponent Wacher Decision Engine.
Watcher Decision Engine — komponent, ktorý zodpovedá za výpočet sady potenciálnych akcií na optimalizáciu na dosiahnutie cieľa auditu. Ak nie je určená stratégia, komponent si sám vyberá najvhodnejší prístup.
Watcher Metrics Publisher — komponent, ktorý zhromažďuje a počíta určité metriky alebo udalosti a publikuje ich do koncového bodu CEP. Funkcionalita komponentu môže byť zabezpečená aj prostredníctvom Ceilometer publisher.
Complex Event Processing (CEP) Engine — motor komplexnej správy udalostí. Z hľadiska výkonu môže existovať niekoľko inštancií CEP Engine, ktoré pracujú súčasne, pričom každá spracováva určitý typ metriky / udalostí. V systéme Watcher CEP spúšťa dva typy akcií: — zapisovať príslušné udalosti / metriky do databázy časových radov; — odosielať príslušné udalosti do komponentu Watcher Decision Engine, keď táto udalosť môže ovplyvniť výsledok aktuálnej stratégie optimalizácie, keďže klaster OpenStack nie je statický systém.
Interakcia komponentov prebieha prostredníctvom protokolu AMQP.
→
Schéma interakcie s Watcher
Výsledky testovania Watcher
- Na stránke Optimalizácia — Plány akcií sa objavuje chyba 500 (ako na čistej verzii Queens, tak aj na stande s modulmi Tionix), objaví sa iba po spustení auditu a generovaní plánu akcií, prázdna stránka sa otvára normálne.
- Na karte Podrobnosti akcie sa objavujú chyby, nemožno získať cieľ a stratégiu auditu (ako na čistej verzii Queens, tak aj na stande s modulmi Tionix).
- Audity s cieľom Dummy (testovacie) sa vytvárajú a spúšťajú normálne, plány akcií sa generujú.
- Audity s cieľom Unclassified sa nevytvárajú, pretože cieľ nie je funkčný a je určený na medzistupňové nastavenie pri vytváraní nových stratégií.
- Audity s cieľom Workload Balancing (stratégia vyváženia kapacity úložiska) sa vytvárajú úspešne, avšak plán akcií sa negeneruje. Optimalizácia úložných poolov nie je potrebná.
- Audity s cieľom Workload Balancing (stratégia migrácie vyváženia záťaže) sa vytvárajú úspešne, avšak plán akcií sa negeneruje.
- Audity s cieľom Workload Balancing (stratégia stabilizácie záťaže) končia chybou.
- Audity s cieľom Noisy Neighbor sa vytvárajú úspešne, avšak plán akcií sa negeneruje.
- Audity pre Hardware maintenance sa úspešne vytvárajú, akčný plán sa generuje nie v plnom rozsahu (generujú sa výkonnostné ukazovatele, ale nevytvára sa samotný zoznam akcií).
- Úpravy v konfiguračných súboroch nova.conf (v default sekcii compute_monitors = cpu.virt_driver) na výpočtových a riadiacich uzloch neopravujú chyby.
- Audity pre Server Consolidation (strategia Basic) taktiež končia s chybou.
- Audity pre Server Consolidation (strategia VM workload consolidation) skončia s chybou. V logoch je chyba pri získavaní pôvodných údajov. Diskusia o chybe, najmä .
Skúsili sme uviesť v konfiguračnom súbore Watcher (nepomohlo – výsledkom sú chyby na všetkých stránkach Optimization, návrat k pôvodnému obsahu konfiguračného súboru situáciu neopravuje):[watcher_strategies.basic]
datasource = ceilometer, gnocchi - Audity pre Saving Energy končia s chybou. Podľa logov je problém predsa len v absencii Ironic, bez baremetal service to nebude fungovať.
- Audity pre Thermal Optimization končia s chybou. Traceback je rovnaký ako pre Server Consolidation (strategia VM workload consolidation) (chyba pôvodných údajov)
- Audity pre Airflow Optimization končia s chybou.
Objavujú sa aj nasledujúce chyby pri ukončení auditu. Traceback v logoch decision-engine.log (nebolo určené stav clustra).
→ Diskusia o chybe
Záver
Výsledkom našich dvojmesačných výskumov bol jednoznačný záver, že na dosiahnutie plne funkčného systému vyvažovania záťaže budeme musieť v tejto oblasti úzko spolupracovať na zdokonalení nástrojov pre platformu Openstack.
Watcher sa ukázal ako vážny a rýchlo sa rozvíjajúci produkt s obrovským potenciálom, na plné využitie ktorého bude potrebné veľa a vážnej práce.
O tom ale – v nasledujúcich článkoch cyklu.
Zdroj: habr.com
