A nagy felhőrendszerekben különösen akut probléma a számítási erőforrások terhelésének automatikus kiegyenlítése vagy kiegyenlítése. A Tionix (felhőszolgáltatások fejlesztője és üzemeltetője, a Rostelecom cégcsoport része) is foglalkozott ezzel a kérdéssel.
És mivel a fő fejlesztői platformunk az Openstack, és mi, mint minden ember, lusták vagyunk, úgy döntöttünk, hogy kiválasztunk néhány kész modult, amely már benne van a platformban. Választásunk a Watcherre esett, amelyet úgy döntöttünk, hogy az igényeinknek megfelelően használunk.
Először is nézzük meg a kifejezéseket és definíciókat.
Fogalmak és meghatározások
Gól egy ember által olvasható, megfigyelhető és mérhető végeredmény, amit el kell érni. Minden cél eléréséhez egy vagy több stratégia létezik. A stratégia egy olyan algoritmus megvalósítása, amely képes megoldást találni egy adott célra.
Akció egy olyan elemi feladat, amely megváltoztatja az OpenStack-fürt megcélzott felügyelt erőforrásának aktuális állapotát, például: virtuális gép áttelepítése (migráció), egy csomópont energiaállapotának megváltoztatása (change_node_power_state), a nova szolgáltatás állapotának megváltoztatása (change_nova_service_state). ), íz megváltoztatása (átméretezés), NOP üzenetek regisztrálása (nop), cselekvés hiánya egy bizonyos ideig - szünet (alvás), lemezátvitel (volume_migrate).
Akcióterv - a cselekvések meghatározott folyamata, amelyet meghatározott sorrendben hajtanak végre egy adott cél elérése érdekében. A cselekvési terv mért globális teljesítményt is tartalmaz teljesítménymutatókkal. Sikeres audit után a Watcher cselekvési tervet készít, melynek eredményeként az alkalmazott stratégia megoldást talál a cél elérésére. Az akcióterv egymást követő tevékenységek listájából áll.
Könyvvizsgálat egy kérés a fürt optimalizálására. Az optimalizálás egy adott klaszterben egy cél elérése érdekében történik. A Watcher minden sikeres audithoz cselekvési tervet készít.
Ellenőrzési hatókör az erőforrások halmaza, amelyen belül az auditot végzik (rendelkezésre állási zóna(k), csomópont-aggregátorok, egyedi számítási csomópontok vagy tárolási csomópontok stb.). Az ellenőrzés hatóköre minden sablonban meg van határozva. Ha nincs megadva ellenőrzési hatókör, akkor a teljes fürt ellenőrzése megtörténik.
Audit sablon — egy mentett beállításkészlet az audit indításához. Sablonok szükségesek ahhoz, hogy az auditokat ugyanazokkal a beállításokkal többször is lehessen futtatni. A sablonnak feltétlenül tartalmaznia kell az audit célját, ha nem adunk meg stratégiákat, akkor a legmegfelelőbb meglévő stratégiákat választjuk ki.
Fürt olyan fizikai gépek gyűjteménye, amelyek számítási, tárolási és hálózati erőforrásokat biztosítanak, és amelyeket ugyanaz az OpenStack felügyeleti csomópont kezel.
Klaszter adatmodell (CDM) a fürt által kezelt erőforrások aktuális állapotának és topológiájának logikus ábrázolása.
Hatékonysági mutató - egy indikátor, amely jelzi, hogy az ezzel a stratégiával létrehozott megoldás hogyan valósul meg. A teljesítménymutatók egy adott célra specifikusak, és jellemzően az eredményül kapott cselekvési terv globális hatékonyságának kiszámítására szolgálnak.
Hatékonysági specifikáció az egyes Célokhoz kapcsolódó sajátos jellemzők halmaza, amely meghatározza a különböző teljesítménymutatókat, amelyeket a megfelelő Cél elérését szolgáló stratégiának el kell érnie a megoldásában. Valójában minden, a stratégia által javasolt megoldást a specifikációhoz képest ellenőriznek, mielőtt kiszámítják a globális hatékonyságát.
Pontozási motor egy olyan végrehajtható fájl, amely jól definiált bemenetekkel, jól definiált kimenetekkel rendelkezik, és pusztán matematikai feladatot lát el. Ily módon a számítás független attól, hogy milyen környezetben végzik – bárhol ugyanazt az eredményt adja.
Figyelő Tervező - a Watcher döntéshozó motor része. Ez a modul egy stratégia által generált műveletsort vesz fel, és létrehoz egy munkafolyamat-tervet, amely meghatározza, hogyan ütemezzük ezeket a különböző műveleteket időben és minden egyes művelethez, mik az előfeltételek.
Figyelő céljai és stratégiái
Gól
stratégia
Hamis gól
Dummy stratégia
Dummy stratégia minta pontozási motorok használatával
Dummy stratégia átméretezéssel
Energy Saving
Energiatakarékossági stratégia
Szerver konszolidáció
Alapvető offline szerverkonszolidáció
VM-munkaterhelés-konszolidációs stratégia
Munkaterhelés kiegyensúlyozása
Munkaterhelés egyensúlya migrációs stratégia
Tárolási kapacitás egyensúlyi stratégia
Munkaterhelés stabilizálása
Zajos szomszéd
Zajos szomszéd
Termikus optimalizálás
Kimeneti hőmérsékleten alapuló stratégia
Légáramlás optimalizálás
Egységes légáramlás migrációs stratégia
Hardver karbantartás
Zóna migráció
nem titkos
Működtető
Hamis gól — fenntartott cél, amelyet tesztelési célokra használnak.
Kapcsolódó stratégiák: Dummy-stratégia, Dummy-stratégia mintapontozási motorokkal és Dummy-stratégia átméretezéssel. A Dummy stratégia egy álstratégia, amelyet a Tempesten keresztüli integráció tesztelésére használnak. Ez a stratégia nem nyújt hasznos optimalizálást, egyetlen célja a Tempest tesztek használata.
Dummy stratégia minta pontozási motorokkal - a stratégia hasonló az előzőhöz, az egyetlen különbség egy minta „pontozó motor” használata, amely gépi tanulási módszerekkel végez számításokat.
Dummy stratégia átméretezéssel - a stratégia hasonló az előzőhöz, az egyetlen különbség az íz megváltoztatása (migráció és átméretezés).
Gyártásban nem használt.
Energy Saving – az energiafogyasztás minimalizálása. Ennek a célnak az energiatakarékossági stratégiája a VM Workload Consolidation Strategy (Server Consolidation) stratégiával együtt képes olyan dinamikus energiagazdálkodási (DPM) funkciókra, amelyek energiát takarítanak meg a munkaterhelések dinamikus konszolidálásával még alacsony erőforrás-kihasználtság esetén is: a virtuális gépek kevesebb csomópontba kerülnek át. , és a szükségtelen csomópontok le vannak tiltva. A konszolidáció után a stratégia döntést kínál a csomópontok be-/kikapcsolásáról a megadott paramétereknek megfelelően: „min_free_hosts_num” - a szabad engedélyezett csomópontok száma, amelyek betöltésre várnak, és „free_used_percent” - a szabad engedélyezett gazdagépek százalékos aránya a gépek által elfoglalt csomópontok száma. Ahhoz, hogy a stratégia működjön, léteznie kell engedélyezve és konfigurálva az Ironic, hogy kezelje a tápellátást a csomópontokon.
Stratégia paraméterei
paraméter
típus
alapértelmezés szerint
описание
szabad_használt_százalék
Szám
10.0
a szabad számítási csomópontok számának aránya a virtuális gépekkel rendelkező számítási csomópontok számához képest
min_free_hosts_num
Int
1
a szabad számítástechnikai csomópontok minimális száma
A felhőnek legalább két csomóponttal kell rendelkeznie. A használt módszer a csomópont energiaállapotának megváltoztatása (change_node_power_state). A stratégia nem igényel mérőszámok gyűjtését.
Szerverkonszolidáció – minimalizálja a számítási csomópontok számát (konszolidáció). Két stratégiája van: az alapvető offline kiszolgálókonszolidáció és a virtuális gépek munkaterhelésének konszolidációs stratégiája.
A Basic Offline Server Consolidation stratégia minimalizálja a használt kiszolgálók teljes számát, és minimalizálja az áttelepítések számát is.
Az alapstratégia a következő mutatókat követeli meg:
mérőszámok
szolgáltatás
bővítmények
megjegyzés
compute.node.cpu.percent
egyik sem
cpu_util
egyik sem
Stratégiai paraméterek: migration_attempts – a lehetséges leállítási jelöltek keresésének kombinációinak száma (alapértelmezett, 0, korlátozás nélkül), periódus – időintervallum másodpercben a metrikus adatforrásból származó statikus összesítéshez (alapértelmezett, 700).
Használt módszerek: migráció, a nova szolgáltatás állapotának megváltoztatása (change_nova_service_state).
A virtuális gép munkaterhelésének konszolidációs stratégiája egy első illesztésű heurisztikán alapul, amely a mért CPU-terhelésre összpontosít, és megpróbálja minimalizálni azokat a csomópontokat, amelyek túl sok vagy túl kevés terhelést kapnak az erőforrás-kapacitás korlátai miatt. Ez a stratégia olyan megoldást kínál, amely a fürterőforrások hatékonyabb felhasználását eredményezi a következő négy lépéssel:
- Kirakodási szakasz - túlhasznált erőforrások feldolgozása;
- Konszolidációs szakasz - az alulhasznosított erőforrások kezelése;
- A 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 letiltása.
A stratégia a következő mutatókat követeli meg:
mérőszámok
szolgáltatás
bővítmények
megjegyzés
emlékezet
egyik sem
lemez.gyökér.méret
egyik sem
A következő mutatók nem kötelezőek, de javítják a stratégia pontosságát, ha rendelkezésre állnak:
mérőszámok
szolgáltatás
bővítmények
megjegyzés
memória.lakó
egyik sem
cpu_util
egyik sem
Stratégiai paraméterek: periódus – időintervallum másodpercben a metrikus adatforrásból származó statikus összesítéshez (alapértelmezett, 3600).
Ugyanazokat a módszereket használja, mint az előző stratégia. További részletek .
Munkaterhelés kiegyensúlyozása — egyensúlyba hozza a számítási csomópontok közötti munkaterhelést. A célnak három stratégiája van: Munkaterhelés egyensúlyi migrációs stratégia, Munkaterhelés stabilizálása, Tárolási kapacitás egyensúlyi stratégia.
A Workload Balance Migration Strategy a gazda virtuális gép munkaterhelése alapján futtatja a virtuálisgép-áttelepítéseket. Az áttelepítési döntés meghozatalra kerül, ha egy csomópont CPU- vagy RAM-kihasználtsága meghaladja a megadott küszöbértéket. Ebben az esetben az áthelyezett virtuális gépnek közelebb kell vinnie a csomópontot az összes csomópont átlagos munkaterheléséhez.
Követelmények
- Fizikai processzorok használata;
- Legalább két fizikai számítási csomópont;
- Telepítette és konfigurálta a Ceilometer összetevőt - ceilometer-agent-compute, amely minden számítási csomóponton fut, valamint a Ceilometer API-t, valamint összegyűjtötte a következő mutatókat:
mérőszámok
szolgáltatás
bővítmények
megjegyzés
cpu_util
egyik sem
memória.lakó
egyik sem
Stratégia paraméterek:
paraméter
típus
alapértelmezés szerint
описание
mutatók
Húr
"cpu_util"
A mögöttes mérőszámok: 'cpu_util', 'memory.resident'.
küszöb
Szám
25.0
Munkaterhelési küszöb az áttelepítéshez.
időszak
Szám
300
Összesített időtartam Ceilométer.
Az alkalmazott módszer a migráció.
A terhelés stabilizálása egy olyan stratégia, amelynek célja a terhelés stabilizálása élő migráció segítségével. A stratégia egy standard deviation algoritmuson alapul, és meghatározza, hogy van-e torlódás a fürtben, és a fürt stabilizálása érdekében gépi migráció indításával válaszol rá.
Követelmények
- Fizikai processzorok használata;
- Legalább két fizikai számítási csomópont;
- Telepítette és konfigurálta a Ceilometer összetevőt - ceilometer-agent-compute, amely minden számítási csomóponton fut, valamint a Ceilometer API-t, valamint összegyűjtötte a következő mutatókat:
mérőszámok
szolgáltatás
bővítmények
megjegyzés
cpu_util
egyik sem
memória.lakó
egyik sem
Tárolókapacitás-egyensúlyi stratégia (a Queenstől kezdődően megvalósított stratégia) – a stratégia a Cinder-készletek terhelésétől függően továbbítja a lemezeket. Átadási döntés születik, amikor a készlet kihasználtsága túllép egy meghatározott küszöböt. Az áthelyezett lemeznek közelebb kell vinnie a készletet az összes Cinder-készlet átlagos terheléséhez.
Követelmények és korlátozások
- Minimum két Cinder medence;
- Lemez migráció lehetősége.
- Klaszter adatmodell - Cinder fürt adatmodell gyűjtő.
Stratégia paraméterek:
paraméter
típus
alapértelmezés szerint
описание
volume_threshold
Szám
80.0
A lemezek küszöbértéke a kötetek kiegyenlítéséhez.
A használt módszer a lemez áttelepítése (volume_migrate).
Zajos szomszéd – A „zajos szomszéd” azonosítása és áttelepítése – egy alacsony prioritású virtuális gép, amely az utolsó szintű gyorsítótár túlzott használatával negatívan befolyásolja a magas prioritású virtuális gépek teljesítményét az IPC szempontjából. Saját stratégia: Zajos szomszéd (a használt stratégia paramétere a cache_threshold (alapértelmezett érték 35), ha a teljesítmény a megadott értékre esik, elindul az áttelepítés. A stratégia működéséhez engedélyezve van LLC (Last Level Cache) mérőszámai, legújabb Intel szerver CMT támogatással, valamint a következő mutatók összegyűjtése:
mérőszámok
szolgáltatás
bővítmények
megjegyzés
cpu_l3_cache
egyik sem
Intel szükséges .
Fürt adatmodell (alapértelmezett): Nova fürt adatmodell gyűjtő. Az alkalmazott módszer a migráció.
Az ezzel a céllal az irányítópulton keresztül történő munkavégzés a Queensben nem valósult meg teljes mértékben.
Termikus optimalizálás — optimalizálja a hőmérsékleti rendszert. A kilépő (elszívott levegő) hőmérséklet az egyik fontos termikus telemetriai rendszer a szerver termikus/munkaterhelési állapotának mérésére. A célnak egyetlen stratégiája van, a Kimeneti hőmérsékleten alapuló stratégia, amely úgy dönt, hogy a munkaterheléseket áthelyezi a termikusan kedvező állomásokra (a legalacsonyabb kimeneti hőmérséklet), amikor a forrásállomások kimeneti hőmérséklete elér egy konfigurálható küszöböt.
A stratégia működéséhez szükség van egy kiszolgálóra, amelyen telepítve és konfigurálva van az Intel Power Node Manager , valamint a következő mutatók összegyűjtése:
mérőszámok
szolgáltatás
bővítmények
megjegyzés
hardware.ipmi.node.outlet_temperature
IPMI
Stratégia paraméterek:
paraméter
típus
alapértelmezés szerint
описание
küszöb
Szám
35.0
A migráció hőmérsékleti küszöbe.
időszak
Szám
30
Az időintervallum másodpercben a statisztikai összesítés metrikus adatforrásból való lekéréséhez.
Az alkalmazott módszer a migráció.
Légáramlás optimalizálás — optimalizálja a szellőztetési módot. Saját stratégia – Egységes légáramlás élő migráció segítségével. A stratégia akkor váltja ki a virtuális gép áttelepítését, amikor a kiszolgáló ventilátorának légáramlása meghalad egy meghatározott küszöböt.
A stratégia működéséhez a következőkre van szüksége:
- Hardver: számítási csomópontok < támogatja a NodeManager 3.0-t;
- Legalább két számítási csomópont;
- Az egyes számítási csomópontokon telepített és konfigurált ceilometer-agent-compute és Ceilometer API komponens, amely sikeresen jelenthet olyan mutatókat, mint a légáramlás, a rendszer teljesítménye, a bemeneti hőmérséklet:
mérőszámok
szolgáltatás
bővítmények
megjegyzés
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
A stratégia működéséhez szükség van egy kiszolgálóra, amelyen telepítve és konfigurálva van az Intel Power Node Manager 3.0 vagy újabb verziója.
Korlátozások: A koncepciót nem gyártják.
Javasoljuk ennek az algoritmusnak a használatát folyamatos ellenőrzésekkel, mivel iterációnként csak egy virtuális gépet terveznek migrálni.
Élő migráció lehetséges.
Stratégia paraméterek:
paraméter
típus
alapértelmezés szerint
описание
küszöb_levegőáramlás
Szám
400.0
A migrációs egység légáramlási küszöbértéke 0.1CFM
threshold_inlet_t
Szám
28.0
A bemeneti hőmérséklet küszöbértéke a migrációs döntéshez
küszöb_teljesítmény
Szám
350.0
A rendszer teljesítményének küszöbértéke az átállási döntéshez
időszak
Szám
30
Az időintervallum másodpercben a statisztikai összesítés metrikus adatforrásból való lekéréséhez.
Az alkalmazott módszer a migráció.
Hardverkarbantartás - hardver karbantartás. A célhoz kapcsolódó stratégia a zóna migráció. A stratégia a virtuális gépek és lemezek hatékony automatikus és minimális migrációjának eszköze, ha hardverkarbantartásra van szükség. A stratégia a súlyoknak megfelelően cselekvési tervet épít fel: a nagyobb súlyú cselekvések halmazát a többiek előtt tervezik meg. Két konfigurációs lehetőség van: action_weights és párhuzamosítás.
Korlátozások: a műveleti súlyokat és a párhuzamosítást konfigurálni kell.
Stratégia paraméterek:
paraméter
típus
alapértelmezés szerint
описание
compute_nodes
sor
Egyik sem
Számítsa ki a csomópontokat az áttelepítéshez.
storage_pools
sor
Egyik sem
Tároló csomópontok az áttelepítéshez.
párhuzamos_összesen
egész szám
6
A párhuzamosan végrehajtandó tevékenységek teljes száma.
párhuzamos_csomópontonként
egész szám
2
Az egyes számítási csomópontokhoz párhuzamosan végrehajtott műveletek száma.
párhuzamos_poolonként
egész szám
2
Az egyes tárterületeken párhuzamosan végrehajtott műveletek száma.
prioritás
tárgy
Egyik sem
Prioritáslista virtuális gépekhez és lemezekhez.
csatolt_kötettel
logikai
Hamis
Hamis – a virtuális gépek áttelepítése az összes lemez áttelepítése után történik meg. Igaz – a virtuális gépek áttelepítése az összes csatlakoztatott lemez áttelepítése után történik meg.
A számítási csomópontok tömbjének elemei:
paraméter
típus
alapértelmezés szerint
описание
src_node
húr
Egyik sem
Az a számítási csomópont, amelyről a virtuális gépek áttelepítésre kerülnek (kötelező).
dst_node
húr
Egyik sem
Számítsa ki azt a csomópontot, amelyre a virtuális gépek migrálnak.
Tárolócsomópont tömb elemei:
paraméter
típus
alapértelmezés szerint
описание
src_pool
húr
Egyik sem
A tárterület, amelyről a lemezek áttelepítése történik (kötelező).
dst_pool
húr
Egyik sem
A tárterület, amelyre a lemezek migrálva vannak.
src_type
húr
Egyik sem
Eredeti lemeztípus (kötelező).
dst_type
húr
Egyik sem
Az eredményül kapott lemeztípus (kötelező).
Objektum prioritású elemek:
paraméter
típus
alapértelmezés szerint
описание
program
sor
Egyik sem
Projektek nevei.
számítási_csomópont
sor
Egyik sem
Számítsa ki a csomópontok nevét.
storage_pool
sor
Egyik sem
Tárolókészletek nevei.
kiszámít
enum
Egyik sem
A virtuális gép paraméterei ["vcpu_num", "mem_size", "disk_size", "created_at"].
tárolás
enum
Egyik sem
Lemezparaméterek ["size", "created_at"].
Az alkalmazott módszerek a virtuális gépek migrációja, a lemez migráció.
nem titkos - a stratégia kidolgozásának elősegítésére szolgáló segédcél. Nem tartalmaz specifikációkat, és akkor használható, ha a stratégia még nincs társítva egy meglévő célhoz. Ez a cél átmeneti pontként is használható. Ehhez a célhoz kapcsolódó stratégia az aktuátor.
Új cél megteremtése
Figyelő döntési motor „külső cél” beépülő felülettel rendelkezik, amely lehetővé teszi egy stratégia segítségével elérhető külső cél integrálását.
Mielőtt új célt hoz létre, győződjön meg arról, hogy egyetlen meglévő cél sem felel meg az Ön igényeinek.
Új bővítmény létrehozása
Új cél létrehozásához a következőket kell tennie: kiterjeszteni a célosztályt, megvalósítani egy osztálymetódust get_name() hogy visszaadja a létrehozni kívánt új cél egyedi azonosítóját. Ennek az egyedi azonosítónak meg kell egyeznie a belépési pont nevével, amelyet később deklarál.
Ezután meg kell valósítania az osztály metódust get_display_name() a létrehozni kívánt cél lefordított megjelenítési nevének visszaadásához (ne használjon változót a lefordított karakterlánc visszaadásához, hogy azt a fordítóeszköz automatikusan összegyűjthesse.).
Osztálymetódus implementálása get_translable_display_name()hogy visszaadja az új cél fordítási kulcsát (valójában az angol megjelenítési nevet). A visszatérési értéknek meg kell egyeznie a get_display_name() karakterlánccal.
Alkalmazza a módszerét get_efficiacy_specification()hogy visszaadja a célhoz tartozó hatékonysági specifikációt. A get_efficiacy_specification() metódus a Watcher által biztosított Unclassified() példányt adja vissza. Ez a teljesítményspecifikáció hasznos a cél kidolgozásának folyamatában, mert megfelel az üres specifikációnak.
→
Watcher architektúra (további részletek) ).
Alkatrészek
Watcher API - egy összetevő, amely megvalósítja a Watcher által biztosított REST API-t. Interakciós mechanizmusok: CLI, Horizon plugin, Python SDK.
Figyelő DB — Figyelő adatbázis.
Figyelő Applier — a Watcher Decision Engine komponens által létrehozott cselekvési terv végrehajtását megvalósító komponens.
Figyelő döntési motor - Az a komponens, amely felelős a lehetséges optimalizálási műveletek halmazának kiszámításáért az ellenőrzési cél elérése érdekében. Ha nincs megadva stratégia, a komponens önállóan választja ki a legmegfelelőbbet.
Watcher Metrics Kiadó - Egy összetevő, amely összegyűjt és kiszámít néhány mérőszámot vagy eseményt, és közzéteszi azokat a CEP-végponton. Az összetevő funkcionalitását a Ceilometer kiadó is biztosíthatja.
Complex Event Processing (CEP) motor — motor komplex eseményfeldolgozáshoz. Teljesítmény okokból előfordulhat, hogy több CEP Engine-példány fut egyidejűleg, és mindegyik egy adott típusú metrikát/eseményt dolgoz fel. A Watcher rendszerben a CEP kétféle műveletet indít el: - rögzíti a megfelelő eseményeket / mérőszámokat az idősor adatbázisban; - küldje el a megfelelő eseményeket a Watcher Decision Engine-nek, ha ez az esemény hatással lehet az aktuális optimalizálási stratégia eredményére, mivel az Openstack fürt nem statikus rendszer.
A komponensek az AMQP protokoll segítségével működnek együtt.
→
A Watcherrel való interakció sémája
Figyelő teszt eredményei
- Az Optimalizálás - Akciótervek 500 oldalon (mind a tiszta Queen-eken, mind a Tionix modulokkal ellátott standon) csak az audit elindítása és az akcióterv generálása után jelenik meg, az üres normál módon nyílik meg.
- Az Action details fülön hibák vannak, nem lehet lekérni az audit célját és stratégiáját (mind a tiszta Queens-en, mind a Tionix modulokkal ellátott állványon).
- A Dummy (teszt) célú auditok normál módon jönnek létre és indulnak, akciótervek készülnek.
- A besorolatlan cél auditjai nem jönnek létre, mert a cél nem működőképes, és az új stratégiák létrehozásakor történő köztes konfigurálásra szolgál.
- A Workload Balancing (Tárolási kapacitás egyensúlyi stratégia) céljára szolgáló auditok sikeresen elkészülnek, de cselekvési terv nem készül. Nincs szükség tárterület-optimalizálásra.
- A munkateher-egyensúlyozási cél (Munkaterhelés-egyensúly migrációs stratégia) ellenőrzései sikeresen létrejöttek, de cselekvési terv nem jön létre.
- A terheléselosztás (munkaterhelés-stabilizációs stratégia) ellenőrzései sikertelenek.
- A Zajos szomszéd cél auditálása sikeresen megtörtént, de cselekvési terv nem jön létre.
- A Hardver karbantartási célú auditok sikeresen elkészülnek, az akcióterv nem készül el teljes egészében (teljesítménymutatók generálódnak, de maga a műveletlista nem jön létre).
- A számítási és vezérlő csomópontok nova.conf konfigurációinak módosításai (az alapértelmezett compute_monitors = cpu.virt_driver szakaszban) nem javítják a hibákat.
- A kiszolgálókonszolidációt (alapvető stratégia) célzó auditok szintén sikertelenek.
- A kiszolgálókonszolidáció (VM-munkaterhelés-konszolidációs stratégia) naplózása hibával meghiúsul. A naplókban hiba van a forrásadatok megszerzésében. A hiba megbeszélése különösen .
Megpróbáltuk megadni a Watchert a konfigurációs fájlban (nem segített - az összes optimalizálási oldalon fellépő hiba következtében a konfigurációs fájl eredeti tartalmához való visszatérés nem javítja a helyzetet): [watcher_strategies.basic] datasource = celométer, gnocchi - Az energiatakarékosság ellenőrzése sikertelen. A naplókból ítélve a probléma továbbra is az Ironic hiánya, nem fog működni meztelen kiszolgálás nélkül.
- A termikus optimalizálás auditálása sikertelen. A visszakövetés ugyanaz, mint a szerverkonszolidációnál (VM-munkaterhelés-konszolidációs stratégia) (forrásadat-hiba)
- A légáramlás optimalizálása céljából végzett auditok hibával meghiúsulnak.
A következő ellenőrzési befejezési hibákat is tapasztaltuk. Nyomon követés a Decision-engine.log naplókban (a fürt állapota nincs megadva).
→ A hiba megbeszélése
Következtetés
Két hónapos kutatásunk eredménye az az egyértelmű következtetés, hogy egy teljes értékű, működő terheléselosztó rendszer elérése érdekében ebben a részben szorosan együtt kell dolgoznunk az Openstack platform eszközeinek finomításán.
A Watcher komoly és hatalmas potenciállal rendelkező, gyorsan fejlődő terméknek bizonyult, melynek teljes kihasználása nagyon komoly munkát igényel.
De erről bővebben a sorozat következő cikkeiben.
Forrás: will.com