🥇Terheléselosztás az Openstackban

Nagy felhős rendszerekben különösen fontos az automatikus terheléselosztás vagy egyenletes elosztás a számítási erőforrások között. Ezzel a problémával foglalkozott a Tionix is (felhőszolgáltatások fejlesztője és üzemeltetője, a Rostelecom cégcsoport tagja).

Mivel a fejlesztési platformunk az Openstack, és mint mindenki, mi is lusták vagyunk, úgy döntöttünk, hogy keresünk egy kész modult, ami már benne van a platformban. Választásunk a Watcher-re esett, amelyet felhasználásra szántunk.

Először nézzük meg a fogalmakat és meghatározásokat.

Fogalmak és meghatározások

Cél — ez egy emberek által olvasható, 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 szükséges. A stratégia egy algoritmus megvalósítása, amely képes megoldást találni az adott célra.

Művelet (Action) — ez egy alapvető feladat, amely megváltoztatja a célzott OpenStack klaszter erőforrásának állapotát, például: virtuális gép migrálása (migration), a csomópont tápegységének állapotának megváltoztatása (change_node_power_state), a nova szolgáltatás állapotának megváltoztatása (change_nova_service_state), a flavor megváltoztatása (resize), NOP üzenet regisztrálása (nop), tétlenség egy adott időtartamra — szünet (sleep), lemez áthelyezése (volume_migrate).

Műveleti terv (Action Plan) — specifikus műveletek áramlása, amelyeket meghatározott sorrendben hajtanak végre egy konkrét cél elérése érdekében. A műveleti terv tartalmaz egy értékelhető globális hatékonyságot egy teljesítménymutató készlettel. A műveleti tervet a Watcher generálja, miután a sikeres audit során a használt stratégia megoldást talál a cél elérésére. A műveleti terv egy sorozatos lépések listájából áll.

Audit (Audit) — ez egy kérés a klaszter optimalizálására. Az optimalizálás célja egy cél elérése a megadott klaszterben. Minden sikeres audit során a Watcher műveleti tervet generál.

Audit terület (Audit Scope) — ez egy erőforrásokból álló halmaz, amely lehetővé teszi az auditálást (elérhetőségi zóna(ák), csomópont aggregátorok, különálló számítási csomópontok vagy tárolási csomópontok stb.). Az audit területét minden sablon határozza meg. Ha az audit területét nem adják meg, az egész klasztert auditálják.

Audit Sablon (Audit Template) — a mentett beállítások halmaza az audit futtatásához. A sablonok szükségesek ahhoz, hogy többször is ugyanazokkal a beállításokkal végezhessük el az auditokat. A sablonnak feltétlenül tartalmaznia kell az audit célját; ha a stratégiák nincsenek megadva, a legmegfelelőbb meglévő stratégiák kerülnek kiválasztásra.

Klaszter (Cluster) — ez egy fizikai gépekből álló halmaz, amely számítási, tárolási és hálózati erőforrásokat biztosít, és egyetlen OpenStack vezérlő csomópont által van irányítva.

Klaszter Adatmodell (Cluster Data Model, CDM) — ez egy logikai reprezentációja a kezelt klaszter erőforrásainak aktuális állapotának és topológiájának.

Hatékonysági Mutató (Efficacy Indicator) — olyan mutató, amely megmutatja, hogyan teljesít a megoldás, amelyet a megadott stratégia segítségével hoztak létre. A hatékonysági mutatók a konkrét célokra specifikusak, és általában a globális hatékonyság kiszámítására használják a végső cselekvési tervvel kapcsolatban.

Hatékonysági Specifikáció (Efficacy Specification) — ez a célokkal kapcsolatos specifikus jellemzők halmaza, amely különböző hatékonysági mutatókat definiál, amelyeket a megfelelő cél elérését biztosító stratégiának kell biztosítania a megoldásában. Valójában minden, a stratégia által javasolt megoldást a specifikációval való megfelelés alapján ellenőriznek, mielőtt kiszámítják a globális hatékonyságát.

Számláló Motor (Scoring Engine) — ez egy végrehajtható fájl, amelynek világosan meghatározott bemeneti és kimeneti adatai vannak, és tisztán matematika feladatot hajt végre. Így a számítás nem függ attól a környezettől, amelyben végrehajtják — mindenhol azonos eredményt ad.

Watcher Tervező (Watcher Planner) — a Watcher döntéshozatali mechanizmusának része. Ez a modul egy sor műveletet fogad el, amelyet a stratégia generál, és létrehoz egy munkafolyamat tervet, amely meghatározza, hogy ezeket a különféle műveleteket hogyan kell időben ütemezni, és hogy minden művelethez mik a feltételek.

Watcher céljai és stratégiái

Cél
Stratégiák

Dummy cél
Dummy Stratégia

Dummy Stratégia minta Értékelő Motorokkal

Dummy stratégia átméretezéssel

Energia megtakarítás
Energia megtakarító stratégia

Szerver konszolidáció
Alap offline szerver konszolidáció

VM terhelés konszolidációs stratégia

Terhelés egyensúlyozás
Terhelés egyensúlyozó migrációs stratégia

Tároló kapacitás egyensúlyozási stratégia

Terhelés stabilizálás

Zajos szomszéd
Zajos szomszéd

Hőoptimalizálás
Kimeneti hőmérséklet-alapú stratégia

Légáram optimalizálás
Egységes légáram migrációs stratégia

Hardver karbantartás
Zóna migráció

Osztályozatlan
Aktuátor

Dummy cél — tesztelési célként használt tartalék cél.

Kapcsolódó stratégiák: Dummy Stratégia, Dummy Stratégia minta Értékelő Motorokkal é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 által. Ez a stratégia nem biztosít semmilyen hasznos optimalizálást, egyetlen célja, hogy a Tempest teszteket használja.

Dummy stratégia minta Értékelő Motorokkal — a stratégia hasonló az előzőhöz, azonban a "mintázott értékelő motor" használatával különbözik, amely gépi tanulásos módszerekkel számol.

Dummy stratégia átméretezéssel — a stratégia hasonló az előzőhöz, azonban a "flavor" megváltoztatásával (migráció és átméretezés) különbözik.

Nem használják éles környezetben.

Energia megtakarítás — minimalizálja az energiafogyasztást. A Saving Energy Strategy célja a VM Workload Consolidation Strategy (Szerver konszolidáció) mellett képes végrehajtani a dinamikus energiakezelés (DPM) funkcióit, amelyek energiát takarítanak meg a terhelések dinamikus konszolidációja révén még alacsony erőforrás-terhelés esetén is: a virtuális gépeket kevesebb csomópontba helyezik át, míg a felesleges csomópontokat kikapcsolják. A konszolidáció után a stratégia javaslatot tesz a csomópontok be- és kikapcsolására a megadott paraméterek alapján: "min_free_hosts_num" — szabadon lévő bekapcsolt csomópontok száma, amelyek terhelésre várnak, és a "free_used_percent" — a szabad bekapcsolt csomópontok aránya a gépekkel foglalt csomópontok számához képest. A stratégiának működnie kell az Ironic-nak be kell kapcsolnia és be kell állítania a csomópontok energiaellátásának be- és kikapcsolásához.

A stratégia paraméterei

paraméter
típus
alapértelmezett
leírás

szabad_használ_%
Szám
10.0
a szabad számítási csomópontok mennyiségének aránya a virtuális gépekkel rendelkező számítási csomópontok mennyiségéhez

min_szabad_csomopontok_szama
Egész
1
a szabad számítási csomópontok minimális száma

A felhőben legalább két csomópontra van szükség. Az alkalmazott módszer a csomópont tápegységének állapotának megváltoztatása (change_node_power_state). A metrikagyűjtő stratégia nem igényel semmit.

A Szolgáltató Konszolidáció — a számítási csomópontok számának minimalizálása (konszolidáció). Két stratégiát tartalmaz: Alap Offline Szolgáltató Konszolidáció és VM Munkahelyzet Konszolidációs Stratégia.

Az Alap Offline Szolgáltató Konszolidációs stratégia minimalizálja a felhasznált szerverek összes számát, valamint minimalizálja a migrációk számát.

Az alapstratégia a következő metrikákat igényli:

metrika
szolgáltatás
a bővítmények
megjegyzés

compute.node.cpu.percent
ceilometer
nincs

cpu_util
ceilometer
nincs

A stratégia paraméterei: migration_attempts — a kikapcsolásra potenciálisan alkalmas jelöltek kereséséhez szükséges kombinációk száma (alapértelmezés szerint 0, nincs korlátozás), period — az adatok statikus aggregálásának időtartama másodpercben a metrikás adatforrásból (alapértelmezés szerint 700).

Az alkalmazott módszerek: migráció, a nova szolgáltatás állapotának megváltoztatása (change_nova_service_state).

A VM Munkahelyzet Konszolidációs Stratégia a first-fit heurisztikus algoritmuson alapul, amely a mért CPU terhelésre összpontosít, és igyekszik minimalizálni azokat a csomópontokat, amelyek túl magas vagy túl alacsony terheléssel bírnak a források kapacitásának korlátai figyelembevételével. Ez a stratégia olyan megoldást kínál, amely a klaszter erőforrásainak hatékonyabb kihasználásához vezet, a következő négy lépést alkalmazva:

Tehermentesítési fázis — a túlkihasznált erőforrások kezelése;
Konszolidációs fázis — a használaton kívüli erőforrások kezelése;
Megoldás optimalizálása — a migrációk számának csökkentése;
A nem használt számítási csomópontok lekapcsolása.

A stratégia a következő metrikákat igényli:

metrika
szolgáltatás
a bővítmények
megjegyzés

memória
ceilometer
nincs

disk.root.size
ceilometer
nincs

A következő metrikák nem kötelezőek, de növelik a stratégia pontosságát, ha elérhetőek:

metrika
szolgáltatás
a bővítmények
megjegyzés

memory.resident
ceilometer
nincs

cpu_util
ceilometer
nincs

A stratégia paraméterei: period — az adatok statikus aggregálásának időtartama másodpercben a metrikás adatforrásból (alapértelmezés szerint 3600).

Ugyanazokat a módszereket használja, mint az előző stratégia. Részletek. itt.

Terhelés egyensúlyozás — a terhelést egyensúlyozni a számítási csomópontok között. A cél három stratégiával rendelkezik: Terheléskiegyenlítő Migrációs Stratégia, Terhelésstabilizálás, Tárhely Kiegyenlítő Stratégia.

A Terheléskiegyenlítő Migrációs Stratégia a virtuális gépek migrációját indítja a csomópontok terhelése alapján. A migrációs döntést akkor hozzák meg, amikor a csomópont % CPU- vagy RAM-használata meghaladja a megadott küszöböt. Ezenkívül a migrálandó virtuális gépnek közelítenie kell a csomópontot a csomópontok átlagos terheléséhez.

Követelmények

Fizikai processzorok használata;
Legalább két fizikai számítási csomópont;
Beállított és konfigurált Ceilometer-komponens — ceilometer-agent-compute, amely 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
ceilometer
nincs

memory.resident
ceilometer
nincs

A stratégia paraméterei:

paraméter
típus
alapértelmezett
leírás

metrikák
String
'cpu_util'
Az alapul szolgáló metrikák: '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 terhelésstabilizálás — olyan stratégia, amely a terhelés stabilizálására irányul élő migráció alkalmazásával. A stratégia a standard eltérés algoritmusán alapul, és meghatározza, hogy van-e túlterhelés a klaszterben, reagál rá azzal, hogy elindítja a gépek migrációját a klaszter stabilizálásához.

Követelmények

Fizikai processzorok használata;
Legalább két fizikai számítási csomópont;
Beállított és konfigurált Ceilometer-komponens — ceilometer-agent-compute, amely 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
ceilometer
nincs

memory.resident
ceilometer
nincs

Tárhely Kiegyenlítő Stratégia (a Queens verziótól kezdődően megvalósítva) — a stratégia a Cinder poolok terhelése alapján helyezi át a lemezeket. A migrációs döntést akkor hozzák meg, amikor a pool kihasználtsága meghaladja a megadott küszöböt. A migrálandó lemeznek közelítenie kell a poolt a Cinder poolok átlagos terheléséhez.

Követelmények és korlátozások

Legalább két Cinder pool;
A lemezek migrálásának lehetősége.
A klaszter adatmodelje — Cinder klaszter adatmodell gyűjtő.

A stratégia paraméterei:

paraméter
típus
alapértelmezett
leírás

volume_threshold
Szám
80.0
A diszkek küszöbértéke a volumenek kiegyenlítéséhez.

A használt módszer — lemez migráció (volume_migrate).

Noisy Neighbor — azonosítani és áthelyezni a „zajos szomszédot” — egy alacsony prioritású virtuális gép, amely negatívan hat a magas prioritású virtuális gép teljesítményére az IPC szempontjából, túlfeszítve az utolsó szintű gyorsítótárat. Saját stratégia: Noisy Neighbor (használt stratégiai paraméter — cache_threshold (alapértelmezett érték — 35), amikor a teljesítmény erre az értékre csökken, az áthelyezés elindul. A stratégia működéséhez szükségesek LLC (Last Level Cache) metrikák, a legutolsó Intel szerver, amely támogatja a CMT-t,, valamint a következő metrikák gyűjtése:

metrika
szolgáltatás
a bővítmények
megjegyzés

cpu_l3_cache
ceilometer
nincs
Szükséges Intel CMT.

A klaszter adatmódja (alapértelmezett): Nova cluster data model collector. A használt módszer — áthelyezés.

A cél Dashboard általi kezelése a Queens verzióban nem valósult meg teljesen.

Hőoptimalizálás — optimalizálni a hőmérsékleteket. A kimeneti hőmérséklet (elszívott levegő) az egyik legfontosabb hőmérsékleti telemetriai rendszer a szerverhőmérséklet / munkaterhelés állapotának mérésére. A célhoz egy stratégia létezik — Outlet temperature based strategy, amely döntéseket hoz arról, hogy a munkaterheléseket kedvező hőmérsékleti viszonyokkal rendelkező csomópontokra helyezi át (a legalacsonyabb kimeneti hőmérséklet), amikor az eredeti hosztok kimeneti hőmérséklete eléri az állítható küszöböt.

A stratégia működéséhez szükséges egy szerver telepített és konfigurált Intel Power Node Manager 3.0 vagy újabb verzióval. hardware.ipmi.node.outlet_temperature, valamint a következő metrikák gyűjtése:

metrika
szolgáltatás
a bővítmények
megjegyzés

IPMI
ceilometer
A migrációs hőmérséklet-küszöb.

A stratégia paraméterei:

paraméter
típus
alapértelmezett
leírás

küszöb
Szám
35.0
Idő intervallum másodpercekben a statisztikai aggregáláshoz az adatforrás metrikáiból.

időszak
Szám
30
— optimalizálni a szellőzést. Saját stratégia — Uniform Airflow using live migration. A stratégia minden egyes alkalommal elindítja a virtuális gép migrálását, amikor a szerver ventilátorának légáramlása meghaladja a megadott küszöbértéket.

A használt módszer — migráció.

Légáram optimalizálás A stratégia működéséhez szükséges:

Hardver: számítási csomópontok <NodeManager 3.0 támogatással;

Legalább két számítási csomópont;
Minden számítási csomóponton telepített és konfigurált ceilometer-agent-compute komponens és Ceilometer API, amely sikeresen tud jelenteni olyan metrikákról, mint a légáramlás, a rendszer teljesítménye, a bemeneti hőmérséklet:
hardware.ipmi.node.airflow

metrika
szolgáltatás
a bővítmények
megjegyzés

hardware.ipmi.node.temperature
ceilometer
A migrációs hőmérséklet-küszöb.

hardware.ipmi.node.power
ceilometer
A migrációs hőmérséklet-küszöb.

A stratégiához egy Intel Power Node Manager 3.0 vagy újabb verzióval telepített és konfigurált szerver szükséges.

Korlátozások: A koncepció nem célja a termelés.

Az algoritmust folyamatos auditokkal ajánljuk használni, mivel egy iterációnál csak egy virtuális gép migrálása tervezett.

Lehetséges élő migrációk.

A stratégia paraméterei:

paraméter
típus
alapértelmezett
leírás

threshold_airflow
Szám
400.0
Migrációs légáram-küszöb egysége 0.1CFM

threshold_inlet_t
Szám
28.0
Bejárati hőmérséklet-küszöb a migrációs döntéshez

threshold_power
Szám
350.0
Rendszer teljesítmény-küszöb a migrációs döntéshez

A használt módszer — migráció.

Hardver karbantartás — hardvereszközök karbantartása. A célhoz tartozó stratégia — zónamigráció. A stratégia eszköz a virtuális gépek és lemezek hatékony automatikus és minimális migrálására, ha a hardvereszközök karbantartása szükségessé válik. A stratégia akciós tervet alakít ki a súlyok szerint: azokat az akciókat, amelyeknek nagyobb a súlyuk, előbb tervezik be. Két konfigurációs paraméter található: az akciók súlyai (action_weights) és a párhuzamosítás (parallelization).

Korlátozások: szükséges az akciók súlyainak és a párhuzamosítás konfigurálása.

A stratégia paraméterei:

paraméter
típus
alapértelmezett
leírás

compute_nodes
array
None
Kiszolgáló csomópontok a migrációhoz.

storage_pools
array
None
Tároló csomópontok migrációhoz.

parallel_total
integer
6
A párhuzamosan végrehajtandó akciók összesített száma.

parallel_per_node
integer
2
Párhuzamosan végrehajtott akciók száma minden egyes számítási csomóponton.

parallel_per_pool
integer
2
Párhuzamosan végrehajtott akciók száma minden tárolócsoportban.

priority
object
None
A virtuális gépek és lemezek prioritásainak listája.

with_attached_volume
boolean
False
False — a virtuális gépeket minden lemez átmozgatása után mozgatják. True — a virtuális gépeket az összes csatlakoztatott lemez migrálása után mozgatják.

A számítási csomópontok tömbje:

paraméter
típus
alapértelmezett
leírás

src_node
string
None
A számítási csomópont, ahonnan a virtuális gépeket áthelyezik (kötelező).

dst_node
string
None
A számítási 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ási pool, ahonnan a lemezek áthelyezésre kerülnek (kötelező).

dst_pool
string
None
A tárolási pool, ahová a lemezek áthelyezésre kerülnek.

src_type
string
None
A forrástípus lemez (kötelező).

dst_type
string
None
A cél típusú lemez (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ási csomópontok nevei.

storage_pool
array
None
A tárolási poolok 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álati módszerek — virtuális gépek migrálása, lemezek migrálása.

Osztályozatlan — egy segítő cél, amely a stratégiai tervezés folyamatának megkönnyítésére szolgál. Nem tartalmaz specifikációkat, és bármikor felhasználható, amikor a stratégia még nem kapcsolódik létező célhoz. Ez a cél átmeneti lépésként is használható. A szóban forgó célhoz kapcsolódó stratégia — Actuator.

Új cél létrehozása

Watcher Decision Engine plugin interfésze van az 'externális cél' számára, amely lehetővé teszi külső cél integrálását, amelyet a stratégia segítségével lehet elérni.

Mielőtt új célt hozna létre, győződjön meg arról, hogy egyetlen 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 meg kell valósítania az osztály metódust get_name () az új cél egyedi azonosítójának visszaadásához, amelyet létre szeretne hozni. Ennek az egyedi azonosítónak meg kell egyeznie a később deklarált belépési pont nevével.

Ezután meg kell valósítania az osztály metódusát get_display_name () az új cél megjelenített, lefordított nevének visszaadásához (ne használjon változót a lefordított szöveg visszaadásához, hogy az automatikusan összegyűjthesse a fordítóeszköz.).

Valósítsa meg az osztály metódusát get_translatable_display_name (), hogy visszaadja a fordítási kulcsot (tulajdonképpen az angol megjelenítési nevet) az új cél számára. A visszatérő értéknek meg kell egyeznie a get_display_name ()-ban lefordított szöveggel.

Valósítsa meg 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 tervezési folyamatában, mivel megfelel a üres specifikációnak.

→ További információ itt

A Watcher architektúrája (további itt).

Összetevők

Watcher API — a Watcher által biztosított REST API-t megvalósító komponens. Interakciós mechanizmusok: CLI, Horizon plugin, Python SDK.

Watcher DB — a Watcher adatbázisa.

Watcher Applier — a csapat által létrehozott cselekvési terv végrehajtását megvalósító komponens, amelyet a Watcher Decision Engine hozott létre.

Watcher Decision Engine — a komponens, amely felelős a potenciális optimalizálási intézkedések halmazának kiszámításáért az audit céljának végrehajtásához. Ha a stratégia nincs megadva, a komponens maga választja ki a legmegfelelőbbet.

Watcher Metrics Publisher — a komponens, amely gyűjti és kiszámolja egyes metrikákat vagy eseményeket, és publikálja azokat a CEP végpontra. A kompónens funkciói a Ceilometer publisher révén is biztosíthatók.

Complex Event Processing (CEP) Engine — a komplex események feldolgozási motorja. Teljesítmény szempontjából több példány is futhat egyszerre, mindegyik egy bizonyos típusú metrikát / eseményt dolgoz fel. A Watcher rendszerben a CEP kétféle intézkedést indít el: — a vonatkozó események / metrikák rögzítése az időbeli adatbázisba; — a vonatkozó események küldése a Watcher Decision Engine komponenshez, amikor ez az esemény befolyásolhatja a jelenlegi optimalizálási stratégia eredményét, mivel az Openstack klaszter nem statikus rendszer.

A komponensek közötti kommunikáció AMQP protokollon keresztül történik.

→ Watcher konfigurálása

A Watcher-hez való interakciós séma

A Watcher tesztelési eredményei

Az Optimization — Action plans oldalon 500-as hiba jelenik meg (mind a tiszta Queens, mind a Tionix modulokkal rendelkező stand esetén), csak akkor fordul elő, amikor elindul az audit és generálódik a cselekvési terv, a üresen normálisan nyílik meg.
Az Action details fülön hibák vannak, nem sikerül megszerezni az audit célját és stratégiáját (mind a tiszta Queens, mind a Tionix modulokkal rendelkező stand esetén).
A Dummy célú auditok (teszt) normálisan létrejönnek és elindulnak, cselekvési terveket generálnak.
Az Unclassified célú auditok nem jönnek létre, mivel a cél nem funkcionális, és új stratégiák létrehozása során közbenső beállításokra szolgál.
A Workload Balancing célú auditok (Storage Capacity balance stratégia) sikeresen létrejönnek, azonban az intézkedési terv nem generálódik. Nincs szükség a tárolási készletek optimalizációjára.
A Workload Balancing célú auditok (Workload Balance Migration Strategy stratégia) sikeresen létrejönnek, azonban az intézkedési terv nem generálódik.
A Workload Balancing célú auditok (Workload Stabilization Strategy stratégia) hibával zárulnak.
A Noisy Neighbor célú auditok sikeresen létrejönnek, azonban az intézkedési terv nem generálódik.
A Hardver karbantartás célú auditok sikeresen létrejönnek, a cselekvési terv nem generálódik teljes mértékben (a teljesítmény mutatói generálódnak, de magának a cselekvési listának a létrehozása nem történik meg).
A nova.conf konfigurációs fájlok módosítása (a default szekcióban compute_monitors = cpu.virt_driver) a számító és vezérlő csomópontokon nem javítja a hibákat.
A Server Consolidation célú auditok (Basic stratégia) szintén hibával zárulnak.
A Server Consolidation célú auditok (VM workload consolidation stratégia) hibával végződnek. A naplókban a kiindulási adatok beszerzésével kapcsolatos hiba található. A hiba megbeszélése, különösen, itt.
Megpróbáltuk megadni a Watcher konfigurációs fájlban (nem segített – az összes Optimization oldalon hibák léptek fel, a konfigurációs fájl eredeti tartalmához való visszatérés sem javította a helyzetet):
[watcher_strategies.basic]
datasource = ceilometer, gnocchi
A Saving Energy célú auditok hibával zárulnak. A naplók alapján a probléma végül az Ironic hiányosságában rejlik, a baremetal szolgáltatás nélkül nem fog működni.
A Thermal Optimization célú auditok hibával zárulnak. A hiba nyomkövetése ugyanaz, mint a Server Consolidation (VM workload consolidation stratégia) esetében (a kiindulási adatok hibája).
Az Airflow Optimization célú auditok is hibával zárulnak.

A következő audit befejezési hibák is előfordulnak. A döntéshozó motor naplójaiban a nyomkövetés (a klaszter állapota nem meghatározott).

→ A hiba megbeszélése itt

Zárás

Két hónapos kutatásaink eredményeként egyértelmű következtetésre jutottunk, hogy a teljeskörű, működő terheléselosztó rendszer elérése érdekében szorosan foglalkoznunk kell az Openstack platform eszközeinek továbbfejlesztésével.

A Watcher komoly és gyorsan fejlődő termékként mutatkozott be, amelynek teljes körű kihasználása nagy és komoly munkát igényel.

De erről a ciklus következő cikkeiben lesz szó.

Forrás: habr.com