A nagyobb felhőrendszerekben különösen égető kérdés az automatikus terheléselosztás vagy a számítási erőforrások terhelésének kiegyenlítése. Ezzel a kérdéssel a Tionix is foglalkozik (felhőszolgáltatások fejlesztője és üzemeltetője, a Rosztelekom csoport tagja).
Mivel a fő fejlesztési platformunk az OpenStack, és mi is, mint minden ember, lusták vagyunk, ezért úgy döntöttünk, hogy kiválasztunk egy kész modult, amely már benne van a platform összeszerelésében. A választásunk a Watcherre esett, amelyet felhasználóink az igényeinknek megfelelően fogunk használni.
Először is nézzük át a kifejezéseket és meghatározásokat.
Kifejezések és meghatározások
Cél — ez az ember által érthető, megfigyelhető és mérhető végső eredmény, amelyet el kell érni. Minden cél eléréséhez egy vagy több stratégia tartozik. A stratégia egy algoritmus megvalósítása, amely képes megoldást találni az adott célra.
Cselekvés (Action) — ez az alapvető feladat, amely megváltoztatja a célzott, OpenStack klaszter szabályozott erőforrásának aktuális állapotát, például: virtuális gép migrálása (migration), csomópont tápellátási állapotának megváltoztatása (change_node_power_state), nova szolgáltatás állapotának megváltoztatása (change_nova_service_state), méretváltás (resize), NOP üzenet regisztrálása (nop), inaktivitás egy bizonyos ideig — szünet (sleep), lemez áthelyezése (volume_migrate).
Cselekvési terv (Action Plan) — egy specifikus cselekvési folyamat, amelyet meghatározott sorrendben hajtanak végre egy konkrét cél eléréséhez. A cselekvési terv tartalmazza az értékelt globális hatékonyságot is a teljesítménymutatók készletével. A cselekvési tervet a Watcher generálja a sikeresen végrehajtott audit során, amely során a használt stratégia megoldásra talál a cél eléréséhez. A cselekvési terv egy sorrendben végrehajtandó cselekvési lista.
Audit (Audit) — ez egy optimalizálási lekérdezés a klaszterre. Az optimalizálás célja egy cél elérése a megadott klaszterben. Minden sikeres audit során a Watcher generál egy cselekvési tervet.
Audit terület (Audit Scope) — ez egy erőforráshalmaz, amelyen belül auditálás történik (elérhetőségi zóna(zónák), csomópontaggregátorok, különálló számítási csomópontok vagy tárolócsomópontok stb.). Az audit területe minden sablonban meghatározott. Ha az audit területe nincs megadva, akkor az egész klaszter auditálásra kerül.
Audit Sablon (Audit Template) — egy mentett beállításkészlet, amelyet audit végrehajtására használnak. A sablonok szükségesek ahhoz, hogy többször, azonos beállításokkal lehessen auditálni. A sablonnak feltétlenül tartalmaznia kell az audit célját; ha nem adnak meg stratégiákat, akkor a létező stratégiák közül a legmegfelelőbbek választhatók.
Klaszter (Cluster) — egy fizikai gépek halmaza, amelyek számítási, tárolási és hálózati erőforrásokat biztosítanak, és egyetlen OpenStack vezérlő csomópont által irányítva működnek.
Klaszter Adatmodell (Cluster Data Model, CDM) — a kezelt klaszter erőforrásainak aktuális állapotát és topológiáját logikailag ábrázoló kép.
Hatékonysági Mutató (Efficacy Indicator) — egy mutató, amely megmutatja, hogyan teljesít a megoldás, amelyet ezen stratégia alkalmazásával hoztak létre. A hatékonysági mutatók specifikusak egy adott célra, és általában a végső cselekvési terv globális hatékonyságának kiszámításához használják.
Hatékonysági Specifikáció (Efficacy Specification) — a célokhoz kapcsolódó specifikus tulajdonságok halmaza, amely meghatározza azokat a különböző hatékonysági mutatókat, amelyeket a cél elérését szolgáló stratégia megoldásának biztosítania kell. Valóban, minden, a stratégiával javasolt megoldást ellenőrizni fogják a specifikációnak való megfelelés szempontjából, mielőtt kiszámítanák annak globális hatékonyságát.
„Számláló” Motor (Scoring Engine) — egy futtatható fájl, amelynek világosan meghatározott bemeneti adatai, világosan meghatározott kimeneti adatai vannak, és egy tisztán matematikai feladatot végez el. Így a számítás nem függ attól a környezettől, amelyben végrehajtják; ugyanazt az eredményt adja bárhol.
Watcher Tervező (Watcher Planner) — a döntéshozatali mechanizmus része a Watcher. Ez a modul egy stratégiával generált cselekvéskészletet fogad be, és kidolgoz egy munkafolyamat-tervet, amely meghatározza, hogyan kell ütemezni ezeket a különböző cselekvéseket az időben, valamint minden cselekvés esetében, hogy mik a feltételek.
A Watcher céljai és stratégiái
Cél
Stratégiák
Dummy cél
Dummy stratégia
Dummy stratégia minta értékelő motorok használatával
Dummy stratégia átméretezéssel
Energia megtakarítás
Energia megtakarítási stratégia
Szerver konszolidáció
Alap offline szerver konszolidáció
VM munkaerő konszolidációs stratégia
Munkaerő egyensúlyozás
Munkaerő egyensúlyozási migrációs stratégia
Tárolókapacitás egyensúlyozási stratégia
Munkaerő stabilizálás
Zajos szomszéd
Zajos szomszéd
Hőmérséklet-optimalizálás
Kimeneti hőmérséklet alapú stratégia
Levegőáramlás optimalizálás
Egységes levegőáramlás migrációs stratégia
Hardverkarbantartás
Zónamigráció
Klassifikálatlan
Aktuátor
Dummy cél — tartalék cél, amelyet tesztelési célokra használnak.
Kapcsolódó stratégiák: Dummy Stratégia, Dummy stratégia minta értékelő motorok használatával és Dummy stratégia átméretezéssel. A Dummy stratégia egy fiktív stratégia, amelyet integrációs tesztelés céljából használnak a Tempest használatával. Ez a stratégia nem biztosít hasznos optimalizálást, egyetlen célja a Tempest tesztek használata.
A Dummy stratégia minta értékelő motorok használatával — a stratégia hasonló az előzőhöz, csupán a „mintának” a számítást végző motor használatától különbözik, amely gépi tanulási módszereket alkalmaz.
A Dummy stratégia átméretezéssel — a stratégia hasonló az előzőhöz, csupán a flavor változásának (migrációs és átméretezési folyamat) alkalmazásában különbözik.
Nem használják a termelésben.
Energia megtakarítás — minimalizálja az energiafogyasztást. A Saving Energy Strategy célja a VM Workload Consolidation Strategy (Szerver Konszolidáció) stratégiájával együtt képes a dinamikus teljesítménykezelési (DPM) funkciók végrehajtására, melyek az energiaköltségének megtakarítását célozzák meg a munkaerők dinamikus konszolidálása révén még alacsony erőforrás-terhelés idején is: a virtuális gépeket kevesebb számú csomópontra költöztetik, míg a felesleges csomópontokat kikapcsolják. A konszolidálás után a stratégia javaslatot tesz a csomópontok bekapcsolására/kikapcsolására a megadott paraméterek alapján: "min_free_hosts_num" — a szabad bekapcsolt csomópontok száma, amelyek a terhelésre várnak, és "free_used_percent" — a szabad bekapcsolt csomópontok aránya a gépekkel foglalt csomópontok számához képest. A stratégia működéséhez szükséges, hogy az Ironic be legyen kapcsolva és konfigurálva legyen a csomópontok áramellátásának bekapcsolására/kikapcsolására.
A stratégia paraméterei
paraméter
típus
alapértelmezett
leírás
szabad_használat_százalék
Szám
10.0
a szabad számítási csomópontok és a virtuális gépekkel rendelkező számítási csomópontok aránya
min_szabad_csomópontok_száma
Int
1
minimális szabad számítási csomópontok száma
A felhőben legalább két csomópontnak kell lennie. Az alkalmazott módszer a csomópont tápegyság állapotának megváltoztatása (change_node_power_state). A metrikák gyűjtésére vonatkozóan a stratégia nem igényel.
A Server Consolidation célja a számítási csomópontok számának minimalizálása (konzolidáció). Két stratégiája van: Basic Offline Server Consolidation és VM Workload Consolidation Strategy.
A Basic Offline Server Consolidation stratégia minimalizálja a felhasznált szerverek összegét, valamint minimalizálja a migrációk számát.
A bázisstratégia a következő metrikákat igényli:
metrika
szolgáltatás
a bővítmények
megjegyzés
compute.node.cpu.percent
nincs
cpu_util
nincs
A stratégia paraméterei: migration_attempts — a potenciális leállítási jelöltek kereséséhez szükséges kombinációk száma (alapértelmezett, 0, nincs korlátozás), period — az időintervallum másodpercekben a metrikák adatforrásaiból statikus aggregációs adatok megszerzésére (alapértelmezett, 700).
Az alkalmazott módszerek: migráció, a nova szolgáltatás állapotának megváltoztatása (change_nova_service_state).
A VM Workload Consolidation Strategy a first-fit heurisztikus algoritmusra épít, amely a CPU mért terhelésére összpontosít, és próbálja minimalizálni azokat a csomópontokat, amelyek túl nagy vagy túl kicsi terheléssel bírnak a forráskapacitások figyelembevételével. Ez a stratégia egy olyan megoldást kínál, amely hatékonyabb erőforrás-felhasználást eredményez a klaszterben, a következő négy lépést alkalmazva:
- Kiürítési fázis — a túllépett erőforrások kezelése;
- Konzolidációs fázis — a gyengén hasznosított erőforrások kezelése;
- A megoldás optimalizálása — a migrációk számának csökkentése;
- A kihasználatlan számítási csomópontok leállítása.
A stratégia a következő metrikákat igényli:
metrika
szolgáltatás
a bővítmények
megjegyzés
memória
nincs
disk.root.size
nincs
A következő metrikák nem kötelezőek, de fokozzák a stratégia pontosságát, ha elérhetők:
metrika
szolgáltatás
a bővítmények
megjegyzés
memory.resident
nincs
cpu_util
nincs
A stratégia paraméterei: period — az időintervallum másodpercekben a metrikák adatforrásaiból statikus aggregációs adatok megszerzésére (alapértelmezett, 3600).
Ugyanazokat a módszereket használja, mint a korábbi stratégia. További részletek .
Munkaerő egyensúlyozás — egyensúlyozza ki a terhelést a számítási csomópontok között. A cél három stratégiával rendelkezik: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.
A Workload Balance Migration Strategy a virtuális gépek terhelésének alapján indítja el a virtuális gépek migrációját a csomópontok között. A migrálásról akkor döntünk, amikor a csomópont CPU- vagy RAM-használatának %-a meghaladja a megadott küszöböt. A migrálni kívánt virtuális gépnek a csomópontot közelebb kell hoznia az összes csomópont átlagos terheléséhez.
Követelmények
- Fizikai processzorok használata;
- Minimum két fizikai számítási csomópont;
- Telepített és konfigurált Ceilometer komponens — ceilometer-agent-compute, amely a minden számítási csomóponton működik, és Ceilometer API, valamint a következő metrikák gyűjtése:
metrika
szolgáltatás
a bővítmények
megjegyzés
cpu_util
nincs
memory.resident
nincs
Stratégiai paraméterek:
paraméter
típus
alapértelmezett
leírás
metrikák
String
'cpu_util'
A metrikák, amelyek a következőkre épülnek: 'cpu_util', 'memory.resident'.
küszöb
Szám
25.0
A terhelési küszöb a migrációhoz.
időszak
Szám
300
A Ceilometer összesített időszaka.
A használt módszer — migráció.
A Workload stabilization — egy olyan stratégia, amely célja a terhelés megszilárdítása élő migrációval. A stratégia a szórás algoritmusán alapul, és meghatározza, hogy van-e túlterhelés a klaszterben, majd reagál rá azáltal, hogy migrálja a gépeket a klaszter stabilizálása érdekében.
Követelmények
- Fizikai processzorok használata;
- Minimum két fizikai számítási csomópont;
- Telepített és konfigurált Ceilometer komponens — ceilometer-agent-compute, amely a minden számítási csomóponton működik, és Ceilometer API, valamint a következő metrikák gyűjtése:
metrika
szolgáltatás
a bővítmények
megjegyzés
cpu_util
nincs
memory.resident
nincs
A Storage Capacity Balance Strategy (a Queens-től kezdődően valósult meg) — stratégia, amely a Cinder medencék terhelése alapján migrálja a lemezeket. A migrálásról akkor döntünk, amikor a medence kihasználtsági tényezője meghaladja a megadott küszöböt. A migrálni kívánt lemeznek közelebb kell hoznia a medencét az összes Cinder medence átlagos terheléséhez.
Követelmények és korlátozások
- Minimum két Cinder medence;
- A lemezek migrálásának lehetősége.
- A klaszter adatmodellje — Cinder cluster data model collector.
Stratégiai paraméterek:
paraméter
típus
alapértelmezett
leírás
volume_threshold
Szám
80.0
A volumenek kiegyensúlyozásához szükséges lemezküszöbérték.
A használt módszer — lemez migrálás (volume_migrate).
Zajos szomszéd — azonosítsa és helyezze át a "zajos szomszédot" - egy alacsony prioritású virtuális gépet, amely negatívan befolyásolja a magas prioritású virtuális gép teljesítményét az IPC szempontjából, túlzottan kihasználva az utolsó szintű gyorsítótárat. Saját stratégia: Noisy Neighbor (a használt stratégiai paraméter — cache_threshold (alapértelmezett érték — 35), a teljesítmény csökkenése esetén a megadott értékhez a migráció elindul. A stratégia működéséhez szükségesek az aktív LLC (Last Level Cache) metrikák, LLC (Last Level Cache) metrikák, utolsó Intel szerver CMT támogatással, és a következő metrikák gyűjtése:
metrika
szolgáltatás
a bővítmények
megjegyzés
cpu_l3_cache
nincs
Szükséges Intel .
A klaszter adatmodellje (alapértelmezett): Nova klaszter adatmodell gyűjtő. Alkalmazott módszer — migráció.
E célra a Dashboard használata nem valósult meg teljes mértékben a Queens verzióban.
Hőmérséklet-optimalizálás — optimalizálni a hőmérsékletet. A kimeneti hőmérséklet (kisütő levegő) egyike a legfontosabb hőmérséklet-telemetriai rendszereknek a szerver hőmérsékleti / munkaterhelési állapotának mérésére. A célhoz rendelkezésre áll egy stratégia — Outlet temperature based strategy, amely döntéseket hoz a munkaterhelések áttelepítéséről a kedvező hőmérsékletű node-ok felé (legalacsonyabb kimeneti hőmérséklet), amikor a kimeneti hőmérséklet az eredeti hoszton elér egy beállított küszöböt.
A stratégia működéséhez szükséges egy szerver telepítve és beállítva az Intel Power Node Manager 3.0 vagy annál újabb verzióval , és a következő metrikák gyűjtése:
metrika
szolgáltatás
a bővítmények
megjegyzés
IPMI
A migrációs hőmérsékleti küszöb.
Stratégiai paraméterek:
paraméter
típus
alapértelmezett
leírás
küszöb
Szám
35.0
Időintervallum másodpercekben a statisztikai aggregáció megszerzéséhez az adatok forrásából.
időszak
Szám
30
— optimalizálni a légáramlás üzemmódját. Saját stratégia — Uniform Airflow using live migration. A stratégia a migrációt indítja, valahányszor a szerver ventilátorának légáramlása meghaladja a megadott küszöböt.
A használt módszer — migráció.
Levegőáramlás optimalizálás A stratégia működéséhez szükségesek:
Hardver: számító node-ok < NodeManager 3.0 támogatással;
- Minimum két számító node;
- Minden számító node-on telepített és beállított ceiloeter-agent-compute és Ceilometer API, amely sikeresen képes jelenteni az olyan metrikákat, mint a légáram, a rendszer teljesítménye, a belépő hőmérséklet:
- hardware.ipmi.node.airflow
metrika
szolgáltatás
a bővítmények
megjegyzés
hardware.ipmi.node.temperature
A migrációs hőmérsékleti küszöb.
hardware.ipmi.node.power
A migrációs hőmérsékleti küszöb.
hardware.ipmi.node.power
A migrációs hőmérsékleti küszöb.
A stratégia működéséhez olyan szerver szükséges, amelyen telepítve és beállítva van az Intel Power Node Manager 3.0 vagy újabb.
Korlátozások: A koncepció nem készült éles környezetbe.
Azt javasolják, hogy ezt az algoritmust folyamatos auditokkal használják, mivel egy iteráció során csak egy virtuális gép migrálását tervezik.
Lehetséges az élő migráció.
Stratégiai paraméterek:
paraméter
típus
alapértelmezett
leírás
threshold_airflow
Szám
400.0
Migrációs levegőztetési küszöbérték egysége 0.1CFM
threshold_inlet_t
Szám
28.0
Bemeneti hőmérsékleti küszöbérték a migrációs döntéshez
threshold_power
Szám
350.0
Rendszer teljesítményküszöb a migrációs döntéshez
időszak
Szám
30
— optimalizálni a légáramlás üzemmódját. Saját stratégia — Uniform Airflow using live migration. A stratégia a migrációt indítja, valahányszor a szerver ventilátorának légáramlása meghaladja a megadott küszöböt.
A használt módszer — migráció.
Hardver karbantartás — hardvereszközök karbantartása. A célhoz kapcsolódó stratégia — zónamigráció. Ez a stratégia eszköz a virtuális gépek és lemezek hatékony automatikus és minimális migrálására, ha szükség van hardvereszközök karbantartására. A stratégia akciótervet épít ki a súlyok szerint: a nagyobb súlyú akciókat korábban tervezik meg. Két konfigurációs paraméter létezik: akciósúlyok (action_weights) és párhuzamosítás (parallelization).
Korlátozások: az akciósúlyok és a párhuzamosítás beállítása szükséges.
Stratégiai paraméterek:
paraméter
típus
alapértelmezett
leírás
compute_nodes
array
None
Migrálásra szánt számító csomópontok.
storage_pools
array
None
Migrálásra szánt tárolók.
parallel_total
egész szám
6
A párhuzamosan végrehajtandó akciók összes száma.
parallel_per_node
egész szám
2
A párhuzamosan végrehajtandó akciók száma minden számító csomópont esetében.
parallel_per_pool
egész szám
2
A párhuzamosan végrehajtandó akciók száma minden tárolópull esetében.
priority
objektum
None
A virtuális gépek és lemezek prioritási listája.
with_attached_volume
boolean
False
False — a virtuális gépek csak a csatlakoztatott lemezek migrálása után kerülnek át. True — a virtuális gépek a csatlakoztatott lemezek migrálása után kerülnek át.
A számító csomópontok tömbje:
paraméter
típus
alapértelmezett
leírás
src_node
string
None
A számító csomópont, ahonnan a virtuális gépeket átviszik (kötelező).
dst_node
string
None
A számító csomópont, ahová a virtuális gépeket migrálják.
A tárolócsomópontok tömbje:
paraméter
típus
alapértelmezett
leírás
src_pool
string
None
A tárolópult, ahonnan a lemezeket átviszik (kötelező).
dst_pool
string
None
A tárolópult, ahová a lemezeket átviszik.
src_type
string
None
A forrástípusa a lemeznek (kötelező).
dst_type
string
None
A cél típusa a lemeznek (kötelező).
Az objektumok prioritási elemei:
paraméter
típus
alapértelmezett
leírás
project
array
None
A projektek nevei.
compute_node
array
None
A számító csomópontok nevei.
storage_pool
array
None
A tárolópulok nevei.
compute
enum
None
A virtuális gép paraméterei [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
tárolás
enum
None
A lemezek paraméterei [“size”, “created_at”].
Használt módszerek — virtuális gépek migrálása, lemezek migrálása.
Klassifikálatlan — egy segédcél, amely a stratégia fejlesztési folyamatának megkönnyítésére szolgál. Nem tartalmaz specifikációkat, és bármikor használható, amikor a stratégia még nem kapcsolódik a meglévő célhoz. Ez a cél átmeneti szakaszként is használható. A kapcsolódó stratégia: Actuator.
Új cél létrehozása
Watcher Decision Engine plugin interfésszel rendelkezik az “externális cél” számára, amely lehetővé teszi egy külső cél integrálását, amely a stratégia segítségével érhető el.
Új cél létrehozása előtt győződjön meg arról, hogy egyik meglévő cél sem felel meg az igényeinek.
Új plugin létrehozása
Új cél létrehozásához ki kell terjesztenie a cél osztályt, és implementálnia kell az osztály metódust get_name () a létrehozni kívánt új cél egyedi azonosítójának visszaadásához. Ennek az egyedi azonosítónak meg kell egyeznie a later deklarált belépési pont nevével.
Ezt követően implementálja az osztály metódust get_display_name () az új cél megjelenített neve (ne használjon változót a fordított szöveg visszaadásához, hogy automatikusan összeszerelhető legyen a fordítóeszközzel).
Implementálja az osztály metódust get_translatable_display_name (), hogy visszaadja a fordítás kulcsát (valójában az angol megjelenített név) az új céljához. A visszatérési értéknek meg kell egyeznie a get_display_name ()-ben lefordított szöveggel.
Implementálja ennek a metódusát get_efficacy_specification (), hogy visszaadja a célja hatékonysági specifikációját. A get_efficacy_specification () metódus egy Unclassified () példányt ad vissza, amelyet a Watcher biztosít. Ez a hatékonysági specifikáció hasznos a célja fejlesztési folyamatában, mivel ez egy üres specifikációnak felel meg.
→
A Watcher architektúrája (több ).
Összetevők
Watcher API — egy komponens, amely a Watcher által biztosított REST API-t valósítja meg. Interakciós mechanizmusok: CLI, Horizon plugin, Python SDK.
Watcher DB — a Watcher adatbázis.
Watcher Applier — egy komponens, amely végrehajtja a Watcher Decision Engine által létrehozott cselekvési terv végrehajtását.
Watcher Decision Engine — a komponens, amely a felmérési cél eléréséhez szükséges optimalizálási intézkedések potenciális halmazának kiszámításáért felelős. Ha a stratégia nincs megadva, a komponens önállóan választja ki a legmegfelelőbbet.
Watcher Metrics Publisher — a komponens, amely összegyűjti és kiszámítja a különböző metrikákat vagy eseményeket, majd publikálja azokat a CEP végpontjára. A komponens funkcióit a Ceilometer publisher is biztosíthatja.
Complex Event Processing (CEP) Engine — komplex eseménykezelő motor. Teljesítménybeli okokból több CEP Engine példány is működhet párhuzamosan, mindegyik egy adott metrika vagy eseménytípus feldolgozására. A Watcher rendszerben a CEP kétféle intézkedést indít: — megfelelő események/metrikák létrehozása az időbeli adatok adatbázisában; — megfelelő események küldése a Watcher Decision Engine komponenshez, amikor ez az esemény hatással lehet a jelenlegi optimalizálási stratégia kimenetelére, mivel az OpenStack klaszter nem statikus rendszer.
A komponensek közötti interakció AMQP protokollon keresztül történik.
→
A Watcher-hez való interakciós séma
Watcher tesztelési eredményei
- Az Optimization — Action plans oldalon 500-as hiba lép fel (mind a tiszta Queens-en, mind a Tiounix modulokkal rendelkező standon), csak azután jelenik meg, hogy a felmérés elindul és az akcióterv generálódik, a üres normálisan nyílik meg.
- Az Action details fülön hiba lép fel, nem sikerül megszerezni a célt és a felmérési stratégiát (mind a tiszta Queens-en, mind a Tiounix modulokkal rendelkező standon).
- A Dummy (teszt) célú felmérések létrejönnek és normálisan elindulnak, generálódnak az akciótervek.
- Az Unclassified célú felmérések nem jönnek létre, mivel a cél nem funkcionális és célja új stratégiák létrehozásához szükséges átmeneti beállítás.
- A Workload Balancing (Storage Capacity balance stratégia) célú felmérések sikeresen létrejönnek, azonban az akcióterv nem generálódik. Nincs szükség a tárolási poolok optimalizálására.
- A Workload Balancing (Workload Balance Migration Strategy stratégia) célú felmérések sikeresen létrejönnek, azonban az akcióterv nem generálódik.
- A Workload Balancing (Workload Stabilization Strategy stratégia) célú felmérések hibával zárulnak.
- A Noisy Neighbor célú felmérések sikeresen létrejönnek, azonban az akcióterv nem generálódik.
- A hardver karbantartás célú auditok sikeresen létrejönnek, azonban a cselekvési terv nem teljes mértékben generálódik (teljesítmény mutatók generálódnak, de a cselekvések listája nem).
- A nova.conf konfigurációs fájlban történt módosítások (a default szekcióban compute_monitors = cpu.virt_driver) nem javítják a hibákat a számító és vezérlő nodok esetében.
- A szerver konszolidáció (Basic stratégia) célú auditok is hibával zárulnak.
- A szerver konszolidáció (VM workload consolidation stratégia) célú auditok is hibával zárulnak. A naplók szerint hiba történt az alapadatok beszerzésénél. A hiba megbeszélése, különösen, .
Megpróbáltuk megadni a Watcher konfigurációs fájlban (nem segített - a hibák az Optimalizálás összes oldalán megjelentek, a konfigurációs fájl eredeti tartalmához való visszatérés nem javította a helyzetet):[watcher_strategies.basic]
datasource = ceilometer, gnocchi - Az energia megtakarítás célú auditok hibával zárulnak. A naplók szerint a probléma valóban az Ironic hiányában rejlik, baremetal szolgáltatás nélkül nem fog működni.
- A hőoptimalizáció célú auditok hibával zárulnak. A traceback ugyanaz, mint a szerver konszolidáció (VM workload consolidation stratégia) esetében (alapadatok hiba).
- A légáramlás optimalizálás célú auditok hibával zárulnak.
A következő auditzárási hibák is előfordulnak. A traceback az decision-engine.log naplókban (a klaszter állapota nem meghatározott).
→ A hiba megbeszélése
Zárás
Két hónapos kutatásunk eredménye egyértelmű következtetés, miszerint a megfelelően működő terheléselosztó rendszer érdekében szorosabban kell foglalkoznunk az Openstack platform eszközeinek fejlesztésével.
A Watcher komoly és gyorsan fejlődő terméknek bizonyult, amelynek teljes körű használatához nagy és komoly munkára lesz szükség.
De erről a ciklus következő cikkeiben lesz szó.
Forrás: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish