Vo veľkých cloudových systémoch je otázka automatického vyrovnávania alebo vyrovnávania zaťaženia výpočtových zdrojov obzvlášť akútna. O tento problém sa postaral aj Tionix (vývojár a prevádzkovateľ cloudových služieb, súčasť skupiny spoločností Rostelecom).
A keďže našou hlavnou vývojovou platformou je Openstack a my, ako všetci ľudia, sme leniví, bolo rozhodnuté vybrať nejaký hotový modul, ktorý je už súčasťou platformy. Naša voľba padla na Watcher, ktorý sme sa rozhodli využiť pre naše potreby.
Najprv sa pozrime na pojmy a definície.
Pojmy a definície
Cieľ je človekom čitateľný, pozorovateľný a merateľný konečný výsledok, ktorý sa musí dosiahnuť. Na dosiahnutie každého cieľa existuje jedna alebo viac stratégií. Stratégia je implementácia algoritmu, ktorý je schopný nájsť riešenie pre daný cieľ.
Akcia je elementárna úloha, ktorá mení aktuálny stav cieľového riadeného zdroja klastra OpenStack, ako napríklad: migrácia virtuálneho počítača (migrácia), zmena stavu napájania uzla (change_node_power_state), zmena stavu služby nova (change_nova_service_state ), zmena chuti (zmena veľkosti), registrácia správ NOP (nop), nečinnosť po určitú dobu - pauza (spánok), prenos disku (volume_migrate).
Akčný plán - špecifický tok akcií vykonávaných v určitom poradí na dosiahnutie konkrétneho Cieľa. Akčný plán obsahuje aj meranú globálnu výkonnosť so súborom ukazovateľov výkonnosti. Akčný plán vygeneruje Watcher po úspešnom audite, v dôsledku čoho použitá stratégia nájde riešenie na dosiahnutie cieľa. Akčný plán pozostáva zo zoznamu postupných činností.
Audit je požiadavka na optimalizáciu klastra. Optimalizácia sa vykonáva s cieľom dosiahnuť jeden Cieľ v danom klastri. Pre každý úspešný audit Watcher vygeneruje akčný plán.
Rozsah auditu je súbor zdrojov, v rámci ktorých sa audit vykonáva (zóna(y) dostupnosti, agregátory uzlov, jednotlivé výpočtové uzly alebo uzly úložného priestoru atď.). Rozsah auditu je definovaný v každej šablóne. Ak nie je špecifikovaný rozsah auditu, audituje sa celý klaster.
Šablóna auditu — uložený súbor nastavení na spustenie auditu. Šablóny sú potrebné na spustenie auditov viackrát s rovnakými nastaveniami. Šablóna musí nevyhnutne obsahovať účel auditu, ak nie sú špecifikované stratégie, potom sa vyberú najvhodnejšie existujúce stratégie.
Cluster je kolekcia fyzických strojov, ktoré poskytujú výpočtové, úložné a sieťové zdroje a sú riadené rovnakým uzlom správy OpenStack.
Klastrový dátový model (CDM) je logickou reprezentáciou aktuálneho stavu a topológie zdrojov spravovaných klastrom.
Ukazovateľ účinnosti - indikátor, ktorý udáva, ako prebieha riešenie vytvorené pomocou tejto stratégie. Ukazovatele výkonnosti sú špecifické pre konkrétny cieľ a zvyčajne sa používajú na výpočet celkovej účinnosti výsledného akčného plánu.
Špecifikácia účinnosti je súbor špecifických funkcií spojených s každým cieľom, ktorý definuje rôzne ukazovatele výkonnosti, ktoré musí stratégia na dosiahnutie zodpovedajúceho cieľa dosiahnuť vo svojom riešení. Každé riešenie navrhnuté stratégiou sa pred výpočtom globálnej efektívnosti skontroluje v porovnaní so špecifikáciou.
Bodovací motor je spustiteľný súbor, ktorý má dobre definované vstupy, dobre definované výstupy a vykonáva čisto matematickú úlohu. Týmto spôsobom je výpočet nezávislý od prostredia, v ktorom sa vykonáva – kdekoľvek poskytne rovnaký výsledok.
Watcher Planner - súčasť rozhodovacieho motora Watcher. Tento modul preberá súbor akcií generovaných stratégiou a vytvára plán pracovného toku, ktorý špecifikuje, ako naplánovať tieto rôzne akcie v čase a pre každú akciu, aké sú predpoklady.
Ciele a stratégie pozorovateľa
Cieľ
stratégia
Falošný gól
Falošná stratégia
Falošná stratégia s použitím vzorových vyhodnocovacích motorov
Falošná stratégia so zmenou veľkosti
Úspory energie
Stratégia úspory energie
Konsolidácia serverov
Základná konsolidácia offline serverov
Stratégia konsolidácie pracovnej záťaže VM
Vyvažovanie pracovného zaťaženia
Stratégia migrácie na vyváženie pracovného zaťaženia
Stratégia bilancie skladovacej kapacity
Stabilizácia pracovného zaťaženia
Hlučný sused
Hlučný sused
Tepelná optimalizácia
Stratégia založená na výstupnej teplote
Optimalizácia prúdenia vzduchu
Jednotná stratégia migrácie prúdenia vzduchu
Údržba hardvéru
Zónová migrácia
nezaradené
pohon
Falošný gól — vyhradený cieľ, ktorý sa používa na testovacie účely.
Súvisiace stratégie: Dummy Strategy, Dummy Strategy s použitím vzorových skórovacích motorov a Dummy stratégia so zmenou veľkosti. Dummy strategy je fiktívna stratégia používaná na testovanie integrácie cez Tempest. Táto stratégia neposkytuje žiadnu užitočnú optimalizáciu, jej jediným účelom je použitie testov Tempest.
Falošná stratégia pomocou vzorových skórovacích motorov - stratégia je podobná predchádzajúcej, rozdiel je len v použití vzorového skórovacieho enginu, ktorý vykonáva výpočty pomocou metód strojového učenia.
Dummy stratégia s resize - stratégia je podobná predchádzajúcej, rozdiel je len v použití zmeny príchute (migrácia a zmena veľkosti).
Vo výrobe sa nepoužíva.
Úspory energie — minimalizovať spotrebu energie. Stratégia šetrenia energie tohto cieľa spolu so stratégiou konsolidácie pracovnej záťaže VM (konsolidácia serverov) umožňuje funkcie dynamickej správy napájania (DPM), ktoré šetria energiu dynamickou konsolidáciou pracovných záťaží aj v obdobiach nízkeho využitia zdrojov: virtuálne stroje sa presúvajú do menšieho počtu uzlov. a nepotrebné uzly sú zakázané. Po konsolidácii stratégia ponúka rozhodnutie o zapnutí/vypnutí uzlov v súlade so špecifikovanými parametrami: „min_free_hosts_num“ - počet voľných povolených uzlov, ktoré čakajú na načítanie, a „free_used_percent“ - percento voľných povolených hostiteľov na počet uzlov, ktoré sú obsadené strojmi. Aby stratégia fungovala, musí existovať aktivovaný a nakonfigurovaný Ironic tak, aby zvládal cyklovanie napájania na uzloch.
Parametre stratégie
parameter
тип
v predvolenom nastavení
описание
free_used_percent
čí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_free_hosts_num
Int
1
minimálny počet voľných výpočtových uzlov
Cloud musí mať aspoň dva uzly. Použitá metóda je zmena stavu napájania uzla (change_node_power_state). Stratégia nevyžaduje zhromažďovanie metrík.
Konsolidácia serverov – minimalizujte počet výpočtových uzlov (konsolidácia). Má dve stratégie: Základnú konsolidáciu serverov offline a Stratégiu konsolidácie pracovnej záťaže VM.
Stratégia Basic Offline Server Consolidation minimalizuje celkový počet použitých serverov a tiež minimalizuje počet migrácií.
Základná stratégia vyžaduje nasledujúce metriky:
metriky
službu
pluginy
komentár
compute.node.cpu.percent
nikto
cpu_util
nikto
Parametre stratégie: migrácia_pokusy - počet kombinácií na vyhľadávanie potenciálnych kandidátov na vypnutie (predvolené, 0, žiadne obmedzenia), perióda - časový interval v sekundách na získanie statickej agregácie zo zdroja metrických údajov (predvolené, 700).
Použité metódy: migrácia, zmena stavu služby nova (change_nova_service_state).
Stratégia konsolidácie pracovnej záťaže VM je založená na heuristike prvého prispôsobenia, ktorá sa zameriava na merané zaťaženie CPU a pokúša sa minimalizovať uzly, ktoré majú príliš veľkú alebo príliš nízku záťaž vzhľadom na obmedzenia kapacity zdrojov. Táto stratégia poskytuje riešenie, ktorého výsledkom je efektívnejšie využitie klastrových prostriedkov pomocou nasledujúcich štyroch krokov:
- Fáza vykládky – spracovanie prebytočných zdrojov;
- Fáza konsolidácie – nakladanie s nedostatočne využívanými zdrojmi;
- Optimalizácia riešenia – zníženie počtu migrácií;
- Zakázanie nepoužívaných výpočtových uzlov.
Stratégia vyžaduje nasledujúce metriky:
metriky
službu
pluginy
komentár
Pamäť
nikto
veľkosť.root.disku
nikto
Nasledujúce metriky sú voliteľné, ale zlepšia presnosť stratégie, ak sú k dispozícii:
metriky
službu
pluginy
komentár
pamäť.rezident
nikto
cpu_util
nikto
Parametre stratégie: perióda — časový interval v sekundách na získanie statickej agregácie zo zdroja metrických údajov (predvolené, 3600).
Používa rovnaké metódy ako predchádzajúca stratégia. Viac informácií .
Vyvažovanie pracovného zaťaženia — vyvážiť pracovné zaťaženie medzi výpočtovými uzlami. Cieľ má tri stratégie: Stratégia migrácie rovnováhy pracovnej záťaže, Stabilizácia pracovnej záťaže, Stratégia vyrovnania skladovacej kapacity.
Stratégia migrácie rovnováhy pracovného zaťaženia spúšťa migráciu virtuálnych strojov na základe pracovnej záťaže hostiteľského virtuálneho počítača. Rozhodnutie o migrácii sa vykoná vždy, keď % využitie CPU alebo RAM uzla prekročí zadaný prah. V tomto prípade by mal presunutý virtuálny stroj priblížiť uzol k priemernej záťaži všetkých uzlov.
Požiadavky
- Použitie fyzických procesorov;
- Aspoň dva fyzické výpočtové uzly;
- Nainštalovaný a nakonfigurovaný komponent Ceilometer – ceilometer-agent-compute, ktorý beží na každom výpočtovom uzle, a rozhranie API Ceilometer, ako aj zhromažďovanie nasledujúcich metrík:
metriky
službu
pluginy
komentár
cpu_util
nikto
pamäť.rezident
nikto
Parametre stratégie:
parameter
тип
v predvolenom nastavení
описание
metriky
Reťazec
'cpu_util'
Základné metriky sú: 'cpu_util', 'memory.resident'.
prah
číslo
25.0
Prahová hodnota pracovného zaťaženia pre migráciu.
obdobie
číslo
300
Kumulatívne časové obdobie Ceilometer.
Použitá metóda je migrácia.
Stabilizácia pracovného zaťaženia je stratégia zameraná na stabilizáciu pracovného zaťaženia pomocou živej migrácie. Stratégia je založená na algoritme štandardnej odchýlky a určuje, či je v klastri preťaženie, a reaguje na to spustením migrácie stroja, aby sa klaster stabilizoval.
Požiadavky
- Použitie fyzických procesorov;
- Aspoň dva fyzické výpočtové uzly;
- Nainštalovaný a nakonfigurovaný komponent Ceilometer – ceilometer-agent-compute, ktorý beží na každom výpočtovom uzle, a rozhranie API Ceilometer, ako aj zhromažďovanie nasledujúcich metrík:
metriky
službu
pluginy
komentár
cpu_util
nikto
pamäť.rezident
nikto
Storage Capacity Balance Strategy (stratégia implementovaná počnúc Queens) - stratégia prenáša disky v závislosti od zaťaženia Cinder poolov. Rozhodnutie o prevode sa vykoná vždy, keď miera využitia fondu prekročí stanovený prah. Premiestňovaný disk by mal priblížiť fond k priemernej záťaži všetkých fondov Cinder.
Požiadavky a obmedzenia
- Minimálne dva bazény Cinder;
- Možnosť migrácie disku.
- Klastrový dátový model – zberač dátového modelu klastra Cinder.
Parametre stratégie:
parameter
тип
v predvolenom nastavení
описание
volume_threshold
číslo
80.0
Prahová hodnota diskov pre vyrovnávanie zväzkov.
Použitá metóda je migrácia disku (volume_migrate).
Noisy Neighbor – Identifikujte a migrujte „hlučného suseda“ – virtuálny stroj s nízkou prioritou, ktorý nadmerným využívaním vyrovnávacej pamäte poslednej úrovne negatívne ovplyvňuje výkon virtuálneho stroja s vysokou prioritou z hľadiska IPC. Vlastná stratégia: Noisy Neighbor (použitý parameter stratégie je cache_threshold (predvolená hodnota je 35), keď výkon klesne na zadanú hodnotu, spustí sa migrácia. Aby stratégia fungovala, povoľte metriky LLC (Last Level Cache), najnovší server Intel s podporou CMT, ako aj zhromažďovanie nasledujúcich metrík:
metriky
službu
pluginy
komentár
cpu_l3_cache
nikto
Vyžaduje sa Intel .
Dátový model klastra (predvolené): Kolektor dátového modelu klastra Nova. Použitá metóda je migrácia.
Práca s týmto cieľom cez Dashboard nie je v Queense plne implementovaná.
Tepelná optimalizácia — optimalizovať teplotný režim. Výstupná teplota (výfukového vzduchu) je jedným z dôležitých systémov tepelnej telemetrie na meranie stavu teploty/pracovného zaťaženia servera. Cieľ má jednu stratégiu, stratégiu založenú na výstupnej teplote, ktorá sa rozhodne migrovať pracovné zaťaženie na tepelne priaznivých hostiteľov (najnižšia výstupná teplota), keď výstupná teplota zdrojových hostiteľov dosiahne konfigurovateľný prah.
Aby stratégia fungovala, potrebujete server s nainštalovaným a nakonfigurovaným Intel Power Node Manager , ako aj zhromažďovanie nasledujúcich metrík:
metriky
službu
pluginy
komentár
hardvér.ipmi.node.outlet_temperature
IPMI
Parametre stratégie:
parameter
тип
v predvolenom nastavení
описание
prah
číslo
35.0
Teplotný prah pre migráciu.
obdobie
číslo
30
Časový interval v sekundách na získanie štatistickej agregácie zo zdroja metrických údajov.
Použitá metóda je migrácia.
Optimalizácia prúdenia vzduchu — optimalizovať režim vetrania. Vlastná stratégia – Jednotné prúdenie vzduchu pomocou živej migrácie. Stratégia spúšťa migráciu virtuálneho stroja vždy, keď prúdenie vzduchu z ventilátora servera prekročí zadaný prah.
Aby stratégia fungovala, potrebujete:
- Hardvér: výpočtové uzly < podporujúce NodeManager 3.0;
- Aspoň dva výpočtové uzly;
- Komponent ceilometer-agent-compute a Ceilometer API komponent nainštalovaný a nakonfigurovaný na každom výpočtovom uzle, ktorý môže úspešne hlásiť metriky, ako je prietok vzduchu, výkon systému, vstupná teplota:
metriky
službu
pluginy
komentár
hardvérový.ipmi.uzol.prúdenie vzduchu
IPMI
hardvér.teplota.ipmi.uzla
IPMI
hardvér.ipmi.node.power
IPMI
Aby stratégia fungovala, potrebujete server s nainštalovaným a nakonfigurovaným softvérom Intel Power Node Manager 3.0 alebo novším.
Obmedzenia: Koncept nie je určený na výrobu.
Navrhuje sa použiť tento algoritmus s nepretržitými auditmi, pretože sa plánuje migrácia iba jedného virtuálneho počítača na iteráciu.
Živá migrácia je možná.
Parametre stratégie:
parameter
тип
v predvolenom nastavení
описание
prahový_prúd vzduchu
číslo
400.0
Prahová hodnota prietoku vzduchu pre migračnú jednotku je 0.1 CFM
prahový_vstup_t
číslo
28.0
Prah vstupnej teploty pre rozhodnutie o migrácii
prahový_výkon
číslo
350.0
Prahová hodnota výkonu systému pre rozhodnutie o migrácii
obdobie
číslo
30
Časový interval v sekundách na získanie štatistickej agregácie zo zdroja metrických údajov.
Použitá metóda je migrácia.
Údržba hardvéru — údržba hardvéru. Stratégiou súvisiacou s týmto cieľom je Zónová migrácia. Stratégia je nástrojom pre efektívnu automatickú a minimálnu migráciu virtuálnych strojov a diskov v prípade potreby údržby hardvéru. Stratégia vytvára akčný plán v súlade s váhami: súbor akcií, ktorý má väčšiu váhu, bude naplánovaný pred ostatnými. Existujú dve možnosti konfigurácie: action_weights a paralelizácia.
Obmedzenia: je potrebné nakonfigurovať akčné váhy a paralelizáciu.
Parametre stratégie:
parameter
тип
v predvolenom nastavení
описание
compute_nodes
rad
nikto
Vypočítajte uzly pre migráciu.
storage_pools
rad
nikto
Úložné uzly na migráciu.
paralelne_celkom
celé číslo
6
Celkový počet činností, ktoré sa musia vykonať paralelne.
parallel_per_node
celé číslo
2
Počet akcií vykonaných paralelne pre každý výpočtový uzol.
parallel_per_pool
celé číslo
2
Počet akcií vykonaných paralelne pre každú úložnú oblasť.
priorita
objekt
nikto
Zoznam priorít pre virtuálne stroje a disky.
with_attached_volume
boolean
Falošný
False—virtuálne počítače budú migrované po migrácii všetkých diskov. Pravda – virtuálne počítače budú migrované po migrácii všetkých pripojených diskov.
Prvky poľa výpočtových uzlov:
parameter
тип
v predvolenom nastavení
описание
src_node
reťazec
nikto
Výpočtový uzol, z ktorého sa migrujú virtuálne počítače (povinné).
dst_node
reťazec
nikto
Vypočítajte uzol, do ktorého virtuálne počítače migrujú.
Prvky poľa uzlov úložiska:
parameter
тип
v predvolenom nastavení
описание
src_pool
reťazec
nikto
Úložná oblasť, z ktorej sa migrujú disky (povinné).
dst_pool
reťazec
nikto
Úložná oblasť, do ktorej sa migrujú disky.
typ_src
reťazec
nikto
Pôvodný typ disku (povinné).
dst_type
reťazec
nikto
Výsledný typ disku (povinné).
Prvky priority objektu:
parameter
тип
v predvolenom nastavení
описание
projekt
rad
nikto
Názvy projektov.
compute_node
rad
nikto
Vypočítajte názvy uzlov.
storage_pool
rad
nikto
Názvy úložných oblastí.
vypočítať
enum
nikto
Parametre virtuálneho počítača ["vcpu_num", "mem_size", "disk_size", "created_at"].
skladovanie
enum
nikto
Parametre disku ["veľkosť", "vytvorené_at"].
Používané metódy sú migrácia virtuálneho stroja, migrácia disku.
nezaradené - pomocný cieľ používaný na uľahčenie procesu tvorby stratégie. Neobsahuje žiadne špecifikácie a dá sa použiť vždy, keď stratégia ešte nie je spojená s existujúcim cieľom. Tento cieľ možno použiť aj ako prechodový bod. Stratégiou súvisiacou s týmto cieľom je aktuátor.
Vytvorenie nového cieľa
Watcher Decision Engine má rozhranie zásuvného modulu „externý cieľ“, ktoré umožňuje integrovať externý cieľ, ktorý je možné dosiahnuť pomocou stratégie.
Pred vytvorením nového cieľa by ste sa mali uistiť, že žiadne existujúce ciele nespĺňajú vaše potreby.
Vytvára sa nový doplnok
Ak chcete vytvoriť nový cieľ, musíte: rozšíriť cieľovú triedu, implementovať metódu triedy get_name() vrátiť jedinečné ID nového cieľa, ktorý chcete vytvoriť. Tento jedinečný identifikátor sa musí zhodovať s názvom vstupného bodu, ktorý deklarujete neskôr.
Ďalej musíte implementovať metódu triedy get_display_name() vrátiť preložený zobrazovaný názov cieľa, ktorý chcete vytvoriť (nepoužívajte premennú na vrátenie preloženého reťazca, aby ho prekladací nástroj mohol automaticky zhromaždiť.).
Implementujte metódu triedy get_translatable_display_name()vrátiť prekladový kľúč (v skutočnosti anglický zobrazovaný názov) vášho nového cieľa. Návratová hodnota sa musí zhodovať s reťazcom preloženým do get_display_name().
Implementujte jeho metódu get_efficacy_specification()vrátiť špecifikáciu účinnosti pre váš cieľ. Metóda get_efficacy_specification() vracia inštanciu Unclassified() poskytnutú Watcherom. Táto špecifikácia výkonu je užitočná v procese vývoja vášho cieľa, pretože zodpovedá prázdnej špecifikácii.
→
Architektúra Watcher (viac podrobností) ).
Komponenty
Watcher API - komponent, ktorý implementuje REST API poskytované Watcherom. Interakčné mechanizmy: CLI, Horizon plugin, Python SDK.
Strážca DB — Databáza pozorovateľov.
Watcher Applier — komponent, ktorý implementuje vykonávanie akčného plánu vytvoreného komponentom Watcher Decision Engine.
Watcher Decision Engine - Komponent zodpovedný za výpočet súboru potenciálnych optimalizačných akcií na dosiahnutie cieľa auditu. Ak stratégia nie je špecifikovaná, komponent nezávisle vyberie tú najvhodnejšiu.
Vydavateľ metrík pozorovateľa - Komponent, ktorý zhromažďuje a vypočítava niektoré metriky alebo udalosti a publikuje ich do koncového bodu CEP. Funkcionalitu komponentu môže zabezpečiť aj vydavateľ Ceilometer.
Komplexné spracovanie udalostí (CEP) Engine — motor pre komplexné spracovanie udalostí. Z dôvodov výkonu môže byť súbežne spustených viacero inštancií CEP Engine, pričom každá spracováva špecifický typ metriky/udalosti. V systéme Watcher CEP spúšťa dva typy akcií: - zaznamenávať zodpovedajúce udalosti/metriky do databázy časových radov; - odoslať príslušné udalosti do nástroja Watcher Decision Engine, keď táto udalosť môže ovplyvniť výsledok aktuálnej stratégie optimalizácie, pretože klaster Openstack nie je statický systém.
Komponenty interagujú pomocou protokolu AMQP.
→
Schéma interakcie s Watcherom
Výsledky testu pozorovateľa
- Na stránke Optimalizácia - Akčné plány 500 (na čistých Queens aj na stojane s modulmi Tionix) sa objaví až po spustení auditu a vygenerovaní akčného plánu, prázdny sa normálne otvorí.
- Na záložke Detaily akcie sú chyby, nie je možné získať cieľ a stratégiu auditu (na čistých Queens aj na stojane s modulmi Tionix).
- Audity s cieľom Dummy (test) sa vytvárajú a spúšťajú normálne, vytvárajú sa akčné plány.
- Audity pre cieľ Nezaradený sa nevytvárajú, pretože cieľ nie je funkčný a je určený na medzikonfiguráciu pri vytváraní nových stratégií.
- Audity na účely vyváženia pracovného zaťaženia (stratégia vyváženia kapacity skladovania) sú úspešne vytvorené, ale nevygeneruje sa akčný plán. Nevyžaduje sa žiadna optimalizácia úložného priestoru.
- Audity pre cieľ Workload Balancing (Workload Balance Migration Strategy) sa úspešne vytvoria, ale nevygeneruje sa akčný plán.
- Audity vyváženia pracovného zaťaženia (stratégia stabilizácie pracovného zaťaženia) zlyhajú.
- Audity pre cieľ Hlučný sused sa úspešne vytvoria, ale nevygeneruje sa akčný plán.
- Audity za účelom údržby hardvéru sú úspešne vytvorené, akčný plán sa negeneruje v plnom rozsahu (generujú sa ukazovatele výkonu, ale negeneruje sa samotný zoznam akcií).
- Úpravy v konfiguráciách nova.conf (v predvolenej sekcii compute_monitors = cpu.virt_driver) na výpočtových a riadiacich uzloch neopravujú chyby.
- Audity zamerané na konsolidáciu serverov (základná stratégia) tiež zlyhajú.
- Audity na účely konsolidácie servera (stratégia konsolidácie pracovného zaťaženia virtuálnych počítačov) zlyhajú s chybou. V protokoloch je chyba pri získavaní zdrojových údajov. Diskusia o chybe, najmä .
Pokúsili sme sa špecifikovať Watcher v konfiguračnom súbore (nepomohlo to - v dôsledku chyby na všetkých stránkach Optimalizácie návrat k pôvodnému obsahu konfiguračného súboru situáciu neopraví): [watcher_strategies.basic] zdroj údajov = ceilometer, halušky - Audity na úsporu energie zlyhávajú. Súdiac podľa logov, problémom je stále absencia Ironic, bez baremetalového servisu to nepôjde.
- Audity tepelnej optimalizácie zlyhajú. Spätné sledovanie je rovnaké ako pri konsolidácii servera (stratégia konsolidácie pracovného zaťaženia VM) (chyba zdrojových údajov)
- Audity na účely optimalizácie prúdenia vzduchu zlyhajú s chybou.
Vyskytli sa aj nasledujúce chyby dokončenia auditu. Spätné sledovanie v protokoloch decision-engine.log (stav klastra nie je definovaný).
→ Diskusia o chybe
Záver
Výsledkom nášho dvojmesačného výskumu bol jednoznačný záver, že na získanie plnohodnotného systému vyvažovania pracovnej záťaže budeme musieť v tejto časti úzko spolupracovať na dolaďovaní nástrojov pre platformu Openstack.
Watcher sa ukázal ako seriózny a rýchlo sa rozvíjajúci produkt s obrovským potenciálom, ktorého plné využitie si bude vyžadovať veľa serióznej práce.
Ale o tom viac v ďalších článkoch seriálu.
Zdroj: hab.com