Në sistemet e mëdha cloud, çështja e balancimit automatik ose nivelimit të ngarkesës në burimet kompjuterike është veçanërisht e mprehtë. Për këtë çështje është kujdesur edhe Tionix (zhvillues dhe operator i shërbimeve cloud, pjesë e grupit të kompanive Rostelecom).
Dhe, meqenëse platforma jonë kryesore e zhvillimit është Openstack, dhe ne, si të gjithë njerëzit, jemi dembelë, u vendos që të zgjidhnim një modul të gatshëm që tashmë është përfshirë në platformë. Zgjedhja jonë ra mbi Watcher, të cilin vendosëm ta përdorim për nevojat tona.
Së pari, le të shohim termat dhe përkufizimet.
Kushtet dhe përkufizimet
Qëllim është një rezultat përfundimtar i lexueshëm, i vëzhgueshëm dhe i matshëm nga njeriu që duhet të arrihet. Ekzistojnë një ose më shumë strategji për të arritur çdo qëllim. Një strategji është zbatimi i një algoritmi që është në gjendje të gjejë një zgjidhje për një qëllim të caktuar.
Veprimi është një detyrë elementare që ndryshon gjendjen aktuale të burimit të menaxhuar të synuar të grupit OpenStack, të tilla si: migrimi i një makine virtuale (migrimi), ndryshimi i gjendjes së fuqisë së një nyje (change_node_power_state), ndryshimi i gjendjes së shërbimit nova (change_nova_service_state ), ndryshimi i shijes (ndryshimi i madhësisë), regjistrimi i mesazheve NOP (nop), mungesa e veprimit për një kohë të caktuar - pauzë (gjumë), transferimi i diskut (volume_migrate).
Plani i veprimit - një rrjedhë specifike e veprimeve të kryera në një mënyrë të caktuar për të arritur një qëllim specifik. Plani i Veprimit përmban gjithashtu performancën globale të matur me një sërë treguesish të performancës. Një plan veprimi gjenerohet nga Watcher pas një auditimi të suksesshëm, si rezultat i të cilit strategjia e përdorur gjen një zgjidhje për të arritur qëllimin. Një plan veprimi përbëhet nga një listë veprimesh të njëpasnjëshme.
Auditimi është një kërkesë për të optimizuar grupin. Optimizimi kryhet për të arritur një qëllim në një grup të caktuar. Për çdo auditim të suksesshëm, Watcher gjeneron një plan veprimi.
Fushëveprimi i auditimit është një grup burimesh brenda të cilave kryhet auditimi (zonat e disponueshmërisë), grumbulluesit e nyjeve, nyjet individuale llogaritëse ose nyjet e ruajtjes, etj.). Shtrirja e auditimit përcaktohet në çdo shabllon. Nëse një fushë auditimi nuk është e specifikuar, i gjithë grupi auditohet.
Modeli i auditimit — një grup i ruajtur cilësimesh për nisjen e një auditimi. Modelet janë të nevojshme për të ekzekutuar auditime shumë herë me të njëjtat cilësime. Modeli duhet të përmbajë domosdoshmërisht qëllimin e auditimit; nëse strategjitë nuk janë të specifikuara, atëherë zgjidhen strategjitë ekzistuese më të përshtatshme.
Kllaster është një koleksion makinerish fizike që ofrojnë burime llogaritëse, ruajtjeje dhe rrjeti dhe menaxhohen nga e njëjta nyje menaxhuese OpenStack.
Modeli i të dhënave të grupimit (CDM) është një paraqitje logjike e gjendjes aktuale dhe topologjisë së burimeve të menaxhuara nga grupi.
Treguesi i efikasitetit - një tregues që tregon se si kryhet zgjidhja e krijuar duke përdorur këtë strategji. Treguesit e performancës janë specifikë për një qëllim të caktuar dhe zakonisht përdoren për të llogaritur efektivitetin global të planit të veprimit që rezulton.
Specifikimi i efikasitetit është një grup karakteristikash specifike të lidhura me çdo qëllim që përcakton treguesit e ndryshëm të performancës që duhet të arrijë një strategji për të arritur qëllimin përkatës në zgjidhjen e saj. Në të vërtetë, çdo zgjidhje e propozuar nga strategjia do të kontrollohet në përputhje me specifikimet përpara se të llogaritet efektiviteti i saj global.
Motori i pikëve është një skedar i ekzekutueshëm që ka hyrje të mirëpërcaktuara, dalje të përcaktuara mirë dhe kryen një detyrë thjesht matematikore. Në këtë mënyrë, llogaritja është e pavarur nga mjedisi në të cilin kryhet - do të japë të njëjtin rezultat kudo.
Planifikues vëzhgues - pjesë e motorit të vendimmarrjes Watcher. Ky modul merr një sërë veprimesh të krijuara nga një strategji dhe krijon një plan të rrjedhës së punës që specifikon se si të planifikohen këto veprime të ndryshme në kohë dhe për çdo veprim, cilat janë parakushtet.
Qëllimet dhe Strategjitë e Vëzhguesit
Qëllim
strategji
Goli i rremë
Strategjia dummy
Strategjia dummy duke përdorur modele të motorëve të pikëzimit
Strategjia e rreme me ndryshimin e përmasave
Ruajtja e Energjisë
Strategjia e Kursimit të Energjisë
Konsolidimi i serverit
Konsolidimi bazë i serverit jashtë linje
Strategjia e konsolidimit të ngarkesës së punës VM
Balancimi i ngarkesës së punës
Strategjia e balancës së ngarkesës së punës për migrimin
Strategjia e Bilancit të Kapacitetit të Magazinimit
Stabilizimi i ngarkesës së punës
Fqinjë e zhurmshme
Fqinjë e zhurmshme
Optimizimi termik
Strategjia e bazuar në temperaturën e daljes
Optimizimi i rrjedhës së ajrit
Strategji uniforme e migrimit të rrjedhës së ajrit
Mirëmbajtja e harduerit
Migrimi i zonës
Unclassified
Actuator
Goli i rremë — objektivi i rezervuar që përdoret për qëllime testimi.
Strategjitë e ndërlidhura: Strategjia Dummy, Strategjia Dummy duke përdorur modele të motorëve të pikëzimit dhe strategjia Dummy me ndryshim përmasash. Strategjia dummy është një strategji dummy e përdorur për testimin e integrimit përmes Tempest. Kjo strategji nuk ofron ndonjë optimizim të dobishëm, qëllimi i saj i vetëm është të përdorë testet Tempest.
Strategjia e rreme duke përdorur motorët e vlerësimit të mostrës - strategjia është e ngjashme me atë të mëparshme, ndryshimi i vetëm është përdorimi i një "motori të pikëve" të mostrës që kryen llogaritjet duke përdorur metoda të mësimit të makinerive.
Strategjia dummy me ndryshimin e madhësisë - strategjia është e ngjashme me atë të mëparshme, ndryshimi i vetëm është përdorimi i ndryshimit të shijes (migrimi dhe ndryshimi i madhësisë).
Nuk përdoret në prodhim.
Ruajtja e Energjisë — minimizoni konsumin e energjisë. Strategjia e Kursimit të Energjisë së këtij qëllimi, së bashku me Strategjinë e Konsolidimit të Ngarkesës së Punës VM (Konsolidimi i Serverit), është i aftë për veçori të menaxhimit dinamik të energjisë (DPM) që kursejnë energji duke konsoliduar në mënyrë dinamike ngarkesat e punës edhe gjatë periudhave të përdorimit të ulët të burimeve: makinat virtuale zhvendosen në më pak nyje , dhe nyjet e panevojshme janë çaktivizuar. Pas konsolidimit, strategjia ofron një vendim për ndezjen/fikjen e nyjeve në përputhje me parametrat e specifikuar: "min_free_hosts_num" - numri i nyjeve të aktivizuara falas që janë duke pritur për ngarkesë dhe "free_used_percent" - përqindja e hosteve të aktivizuar falas në numri i nyjeve që janë të zëna nga makinat. Që strategjia të funksionojë duhet të ketë aktivizuar dhe konfiguruar Ironic për të trajtuar ciklimin e energjisë në nyje.
Parametrat e strategjisë
parametri
një tip
nga parazgjedhja
описание
për qind_përdorur_falas
Numër
10.0
raporti i numrit të nyjeve informatike të lira me numrin e nyjeve llogaritëse me makina virtuale
min_falas_hosts_num
int
1
numri minimal i nyjeve llogaritëse të lira
Reja duhet të ketë të paktën dy nyje. Metoda e përdorur është ndryshimi i gjendjes së fuqisë së nyjes (change_node_power_state). Strategjia nuk kërkon mbledhjen e metrikave.
Konsolidimi i Serverit - minimizoni numrin e nyjeve llogaritëse (konsolidimi). Ka dy strategji: Konsolidimi Bazë i Serverit Offline dhe Strategjia e Konsolidimit të Ngarkesës së Punës VM.
Strategjia Bazë e Konsolidimit të Serverit Offline minimizon numrin total të serverëve të përdorur dhe gjithashtu minimizon numrin e migrimeve.
Strategjia bazë kërkon matjet e mëposhtme:
metrikë
shërbimi
shtojcat
комментарий
llogarit.nyjë.cpu.përqind
asnje
cpu_util
asnje
Parametrat e strategjisë: migrimi_përpjekjet - numri i kombinimeve për të kërkuar kandidatët e mundshëm për mbyllje (parazgjedhja, 0, pa kufizime), periudha - intervali kohor në sekonda për të marrë grumbullimin statik nga burimi i të dhënave metrike (parazgjedhja, 700).
Metodat e përdorura: migrimi, ndryshimi i gjendjes së shërbimit nova (change_nova_service_state).
Strategjia e Konsolidimit të Ngarkesës së Punës VM bazohet në një heuristikë të përshtatjes së parë që fokusohet në ngarkesën e matur të CPU-së dhe përpiqet të minimizojë nyjet që kanë shumë ose shumë pak ngarkesë, duke pasur parasysh kufizimet e kapacitetit të burimeve. Kjo strategji ofron një zgjidhje që rezulton në përdorim më efikas të burimeve të grupimit duke përdorur katër hapat e mëposhtëm:
- Faza e shkarkimit - përpunimi i burimeve të mbipërdorura;
- Faza e konsolidimit - trajtimi i burimeve të pashfrytëzuara;
- Optimizimi i zgjidhjes - zvogëlimi i numrit të migrimeve;
- Çaktivizimi i nyjeve llogaritëse të papërdorura.
Strategjia kërkon matjet e mëposhtme:
metrikë
shërbimi
shtojcat
комментарий
kujtim
asnje
disk.rrënja.madhësia
asnje
Metrikat e mëposhtme janë opsionale, por do të përmirësojnë saktësinë e strategjisë nëse janë të disponueshme:
metrikë
shërbimi
shtojcat
комментарий
kujtim.banor
asnje
cpu_util
asnje
Parametrat e strategjisë: periudha — intervali kohor në sekonda për të marrë grumbullimin statik nga burimi i të dhënave metrike (parazgjedhja, 3600).
Përdor të njëjtat metoda si strategjia e mëparshme. Më shumë detaje .
Balancimi i ngarkesës së punës — balanconi ngarkesën e punës midis nyjeve informatike. Objektivi ka tre strategji: Strategjia e Migrimit të Balancimit të Ngarkesës së Punës, Stabilizimi i ngarkesës së Punës, Strategjia e Balancimit të Kapacitetit të Magazinimit.
Strategjia e migrimit të balancës së ngarkesës së punës drejton migrimet e makinës virtuale bazuar në ngarkesën e punës së makinës virtuale të hostit. Një vendim migrimi merret sa herë që % e përdorimit të CPU ose RAM të një nyje tejkalon pragun e specifikuar. Në këtë rast, makina virtuale e lëvizur duhet ta afrojë nyjen me ngarkesën mesatare të të gjitha nyjeve.
Kërkesat
- Përdorimi i përpunuesve fizikë;
- Të paktën dy nyje llogaritëse fizike;
- Instaloi dhe konfiguroi komponentin Ceilometer - ceilometer-agent-compute, që funksionon në secilën nyje llogaritëse dhe API-në Ceilometer, si dhe duke mbledhur metrikat e mëposhtme:
metrikë
shërbimi
shtojcat
комментарий
cpu_util
asnje
kujtim.banor
asnje
Parametrat e strategjisë:
parametri
një tip
nga parazgjedhja
описание
certifikatë lindjeje
Varg
'cpu_util'
Metrikat themelore janë: 'cpu_util', 'memory.resident'.
prag
Numër
25.0
Pragu i ngarkesës së punës për migrimin.
periudhë
Numër
300
Periudha kumulative kohore Ceilometri.
Metoda e përdorur është migrimi.
Stabilizimi i ngarkesës së punës është një strategji që synon stabilizimin e ngarkesës së punës duke përdorur migrimin e drejtpërdrejtë. Strategjia bazohet në një algoritëm të devijimit standard dhe përcakton nëse ka mbingarkesë në grup dhe i përgjigjet asaj duke shkaktuar migrimin e makinës për të stabilizuar grupin.
Kërkesat
- Përdorimi i përpunuesve fizikë;
- Të paktën dy nyje llogaritëse fizike;
- Instaloi dhe konfiguroi komponentin Ceilometer - ceilometer-agent-compute, që funksionon në secilën nyje llogaritëse dhe API-në Ceilometer, si dhe duke mbledhur metrikat e mëposhtme:
metrikë
shërbimi
shtojcat
комментарий
cpu_util
asnje
kujtim.banor
asnje
Strategjia e balancës së kapacitetit të ruajtjes (strategjia e zbatuar duke filluar me Queens) - strategjia transferon disqe në varësi të ngarkesës në pishinat Cinder. Një vendim transferimi merret sa herë që shkalla e përdorimit të grupit tejkalon një prag të caktuar. Disku që zhvendoset duhet ta afrojë pishinën me ngarkesën mesatare të të gjitha pishinave të Cinder.
Kërkesat dhe kufizimet
- Minimumi dy pishina Cinder;
- Mundësia e migrimit të diskut.
- Modeli i të dhënave Cluster - Koleksionuesi i modelit të të dhënave të grupit Cinder.
Parametrat e strategjisë:
parametri
një tip
nga parazgjedhja
описание
pragu_volumi
Numër
80.0
Vlera e pragut të disqeve për balancimin e vëllimeve.
Metoda e përdorur është migrimi i diskut (volume_migrate).
Fqinji i zhurmshëm - Identifikoni dhe migroni një "fqinj të zhurmshëm" - një makinë virtuale me prioritet të ulët që po ndikon negativisht në performancën e një makine virtuale me prioritet të lartë për sa i përket IPC-së duke përdorur tepruar memorien e nivelit të fundit. Strategjia vetjake: Fqinji i zhurmshëm (parametri i strategjisë i përdorur është cache_threshold (vlera e parazgjedhur është 35), kur performanca bie në vlerën e specifikuar, nis migrimi. Që strategjia të funksionojë, aktivizohet LLC (Last Level Cache) metrikë, Serveri më i fundit Intel me mbështetje CMT, si dhe duke mbledhur metrikat e mëposhtme:
metrikë
shërbimi
shtojcat
комментарий
cpu_l3_cache
asnje
Kërkohet Intel .
Modeli i të dhënave të grupimit (parazgjedhja): Mbledhësi i modelit të të dhënave të grupimit Nova. Metoda e përdorur është migrimi.
Puna me këtë qëllim përmes Panelit nuk zbatohet plotësisht në Queens.
Optimizimi termik — optimizoni regjimin e temperaturës. Temperatura e daljes (ajri i shkarkimit) është një nga sistemet e rëndësishme të telemetrisë termike për të matur statusin termik/ngarkese të një serveri. Objektivi ka një strategji, strategjinë e bazuar në temperaturën e daljes, e cila vendos të migrojë ngarkesat e punës në hoste termikisht të favorshëm (temperatura më e ulët e daljes) kur temperatura e daljes së pritësve të burimit arrin një prag të konfigurueshëm.
Që strategjia të funksionojë, ju duhet një server me Intel Power Node Manager të instaluar dhe konfiguruar , si dhe duke mbledhur metrikat e mëposhtme:
metrikë
shërbimi
shtojcat
комментарий
hardware.ipmi.node.outlet_temperature
IPMI
Parametrat e strategjisë:
parametri
një tip
nga parazgjedhja
описание
prag
Numër
35.0
Pragu i temperaturës për migrim.
periudhë
Numër
30
Intervali kohor, në sekonda, për të marrë grumbullimin statistikor nga burimi i të dhënave metrike.
Metoda e përdorur është migrimi.
Optimizimi i rrjedhës së ajrit — optimizoni mënyrën e ventilimit. Strategjia vetjake - Rrjedha uniforme e ajrit duke përdorur migrimin e drejtpërdrejtë. Strategjia shkakton migrimin e makinës virtuale sa herë që fluksi i ajrit nga tifozi i serverit tejkalon një prag të specifikuar.
Që strategjia të funksionojë ju duhet:
- Hardware: nyjet llogaritëse < që mbështesin NodeManager 3.0;
- Të paktën dy nyje llogaritëse;
- Komponenti ceilometer-agent-compute dhe Ceilometer API i instaluar dhe konfiguruar në çdo nyje llogaritëse, të cilat mund të raportojnë me sukses metrikë të tillë si rrjedha e ajrit, fuqia e sistemit, temperatura e hyrjes:
metrikë
shërbimi
shtojcat
комментарий
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperaturë
IPMI
hardware.ipmi.node.power
IPMI
Që strategjia të funksionojë, ju nevojitet një server me Intel Power Node Manager 3.0 ose më të ri të instaluar dhe konfiguruar.
Kufizimet: Koncepti nuk është menduar për prodhim.
Propozohet që ky algoritëm të përdoret me auditime të vazhdueshme, pasi vetëm një makinë virtuale është planifikuar të migrohet për përsëritje.
Migrimet e gjalla janë të mundshme.
Parametrat e strategjisë:
parametri
një tip
nga parazgjedhja
описание
pragu_rrjedhja e ajrit
Numër
400.0
Pragu i rrjedhës së ajrit për njësinë e migrimit është 0.1CFM
pragu_hyrje_t
Numër
28.0
Pragu i temperaturës së hyrjes për vendimin e migrimit
pragu_fuqi
Numër
350.0
Pragu i fuqisë së sistemit për vendimin e migrimit
periudhë
Numër
30
Intervali kohor, në sekonda, për të marrë grumbullimin statistikor nga burimi i të dhënave metrike.
Metoda e përdorur është migrimi.
Mirëmbajtja e pajisjeve — mirëmbajtja e harduerit. Strategjia e lidhur me këtë qëllim është migrimi i zonës. Strategjia është një mjet për migrimin efektiv automatik dhe minimal të makinave dhe disqeve virtuale në rast nevoje për mirëmbajtje harduerike. Strategjia ndërton një plan veprimi në përputhje me peshat: një grup veprimesh që kanë më shumë peshë do të planifikohen përpara të tjerëve. Ekzistojnë dy opsione konfigurimi: action_weights dhe paralelizimi.
Kufizimet: peshat e veprimit dhe paralelizimi duhet të konfigurohen.
Parametrat e strategjisë:
parametri
një tip
nga parazgjedhja
описание
nyjet llogaritëse
grup
Asnje
Llogaritni nyjet për migrim.
depo_pishina
grup
Asnje
Nyjet e ruajtjes për migrim.
paralel_total
numër i plotë
6
Numri total i aktiviteteve që duhet të kryhen paralelisht.
paralel_për_nyje
numër i plotë
2
Numri i veprimeve të kryera paralelisht për secilën nyje llogaritëse.
paralel_për_pishinë
numër i plotë
2
Numri i veprimeve të kryera paralelisht për çdo pishinë magazinimi.
prioritet
objekt
Asnje
Lista e përparësive për makinat dhe disqet virtuale.
me_vëllim_të bashkangjitur
Boolean
I rremë
E rreme—makinat virtuale do të migrohen pasi të jenë migruar të gjithë disqet. E vërtetë—makinat virtuale do të migrohen pasi të jenë migruar të gjithë disqet e lidhur.
Elementet e grupit të nyjeve llogaritëse:
parametri
një tip
nga parazgjedhja
описание
src_nyja
varg
Asnje
Nyja llogaritëse nga e cila po migrohen makinat virtuale (kërkohet).
dst_nyja
varg
Asnje
Llogaritni nyjen në të cilën po migrojnë makinat virtuale.
Elementet e grupit të nyjeve të ruajtjes:
parametri
një tip
nga parazgjedhja
описание
src_pool
varg
Asnje
Pishina e ruajtjes nga e cila po migrohen disqet (kërkohet).
dst_pool
varg
Asnje
Pishina e ruajtjes në të cilën disqet janë migruar.
src_lloj
varg
Asnje
Lloji origjinal i diskut (kërkohet).
dst_type
varg
Asnje
Lloji i diskut që rezulton (kërkohet).
Elementet prioritare të objektit:
parametri
një tip
nga parazgjedhja
описание
projekt
grup
Asnje
Emrat e projekteve.
nyja_llogaritëse
grup
Asnje
Llogaritni emrat e nyjeve.
ruajtje_pishinë
grup
Asnje
Emrat e pishinave të ruajtjes.
llogarit
një numër
Asnje
Parametrat e makinës virtuale ["vcpu_num", "mem_size", "disk_size", "created_at"].
ruajtje
një numër
Asnje
Parametrat e diskut ["madhësia", "krijuar_at"].
Metodat e përdorura janë migrimi i makinës virtuale, migrimi i diskut.
Unclassified - një qëllim ndihmës që përdoret për të lehtësuar procesin e zhvillimit të strategjisë. Nuk përmban specifikime dhe mund të përdoret sa herë që strategjia nuk është ende e lidhur me një qëllim ekzistues. Ky qëllim mund të përdoret gjithashtu si një pikë tranzicioni. Një strategji e lidhur me këtë qëllim është Actuator.
Krijimi i një qëllimi të ri
Motori i Vendimit Watcher ka një ndërfaqe shtojce "qëllimi i jashtëm" që bën të mundur integrimin e një qëllimi të jashtëm që mund të arrihet duke përdorur një strategji.
Para se të krijoni një qëllim të ri, duhet të siguroheni që asnjë objektiv ekzistues nuk i plotëson nevojat tuaja.
Krijimi i një shtojce të re
Për të krijuar një objektiv të ri, duhet: të zgjeroni klasën e synuar, të zbatoni një metodë klase get_name () për të kthyer ID-në unike të objektivit të ri që dëshironi të krijoni. Ky identifikues unik duhet të përputhet me emrin e pikës së hyrjes që deklaroni më vonë.
Më pas ju duhet të zbatoni metodën e klasës emri_merr_shfaqje() për të kthyer emrin e përkthyer të ekranit të objektivit që dëshironi të krijoni (mos përdorni një ndryshore për të kthyer vargun e përkthyer në mënyrë që të mund të mblidhet automatikisht nga mjeti i përkthimit.).
Zbatoni një metodë klase get_translatable_display_name()për të kthyer çelësin e përkthimit (në fakt emrin e shfaqur në anglisht) të objektivit tuaj të ri. Vlera e kthyer duhet të përputhet me vargun e përkthyer në get_display_name().
Zbatoni metodën e tij get_efficacy_specification()për të kthyer specifikimin e efikasitetit për objektivin tuaj. Metoda get_efficacy_specification() kthen shembullin e paklasifikuar() të ofruar nga Watcher. Ky specifikim i performancës është i dobishëm në procesin e zhvillimit të qëllimit tuaj sepse korrespondon me specifikimin bosh.
→
Arkitektura e vëzhguesit (më shumë detaje) ).
Komponentet
Watcher API - një komponent që zbaton API-në REST të ofruar nga Watcher. Mekanizmat e ndërveprimit: CLI, shtojca Horizon, Python SDK.
Vëzhguesi DB — Baza e të dhënave Watcher.
Aplikuesi Watcher — një komponent që zbaton ekzekutimin e një plani veprimi të krijuar nga komponenti Watcher Decision Engine.
Motori i Vendimit Watcher - Komponenti përgjegjës për llogaritjen e një sërë veprimesh të mundshme optimizimi për të arritur qëllimin e auditimit. Nëse një strategji nuk është e specifikuar, komponenti zgjedh në mënyrë të pavarur atë më të përshtatshmen.
Botuesi Watcher Metrics - Një komponent që mbledh dhe llogarit disa metrika ose ngjarje dhe i publikon ato në pikën përfundimtare të CEP. Funksionaliteti i komponentit mund të sigurohet edhe nga botuesi Ceilometer.
Motori i përpunimit të ngjarjeve komplekse (CEP). - motor për përpunimin kompleks të ngjarjeve. Për arsye të performancës, mund të ketë disa raste të CEP Engine që funksionojnë njëkohësisht, secila duke përpunuar një lloj specifik metrikë/ngjarje. Në sistemin Watcher, CEP aktivizon dy lloje veprimesh: - regjistroni ngjarjet / metrikat përkatëse në bazën e të dhënave të serive kohore; - dërgoni ngjarjet e duhura në Motorin e Vendimeve Watcher kur kjo ngjarje mund të ndikojë në rezultatin e strategjisë aktuale të optimizimit, pasi grupi Openstack nuk është një sistem statik.
Komponentët ndërveprojnë duke përdorur protokollin AMQP.
→
Skema e ndërveprimit me Watcher
Rezultatet e testit Watcher
- Në faqen Optimization - Action Plans 500 (si në Queens të pastër ashtu edhe në një stendë me module Tionix), ai shfaqet vetëm pasi të fillojë auditimi dhe të krijohet një plan veprimi; ai bosh hapet normalisht.
- Ka gabime në skedën Detajet e Veprimit, nuk është e mundur të merret qëllimi dhe strategjia e auditimit (si në Queens të pastër ashtu edhe në një stendë me module Tionix).
- Auditimet me qëllimin e Dummy (testit) krijohen dhe fillojnë normalisht, gjenerohen planet e veprimit.
- Auditimet për qëllimin e paklasifikuar nuk krijohen sepse qëllimi nuk është funksional dhe synohet për konfigurim të ndërmjetëm gjatë krijimit të strategjive të reja.
- Auditimet për qëllimin e Balancimit të ngarkesës së punës (strategjia e balancës së kapacitetit të ruajtjes) janë krijuar me sukses, por një plan veprimi nuk është krijuar. Nuk kërkohet optimizim i pishinës së ruajtjes.
- Auditimet për objektivin e balancimit të ngarkesës së punës (Strategjia e Migrimit të Balancimit të Punës) janë krijuar me sukses, por një plan veprimi nuk është krijuar.
- Auditimet për Balancimin e Ngarkesës së Punës (Strategjia e Stabilizimit të Ngarkesës së Punës) dështojnë.
- Auditimet për objektivin Noisy Neighbor janë krijuar me sukses, por një plan veprimi nuk është krijuar.
- Auditimet për qëllimin e mirëmbajtjes së harduerit krijohen me sukses, plani i veprimit nuk gjenerohet i plotë (gjenerohen tregues të performancës, por vetë lista e veprimeve nuk gjenerohet).
- Ndryshimet në konfigurimet nova.conf (në seksionin e paracaktuar compute_monitors = cpu.virt_driver) në nyjet e llogaritjes dhe kontrollit nuk korrigjojnë gabimet.
- Auditimet që synojnë Konsolidimin e Serverit (Strategjia bazë) gjithashtu dështojnë.
- Auditimet për qëllimin e Konsolidimit të Serverit (strategjia e konsolidimit të ngarkesës së punës VM) dështojnë me një gabim. Në regjistrat ka një gabim në marrjen e të dhënave burimore. Diskutimi i gabimit, në veçanti .
Ne u përpoqëm të specifikonim Watcher në skedarin e konfigurimit (nuk ndihmoi - si rezultat i një gabimi në të gjitha faqet e Optimizimit, kthimi në përmbajtjen origjinale të skedarit të konfigurimit nuk e korrigjon situatën): [watcher_strategies.basic] burim i të dhënave = ceilometër, njoki - Auditimet për kursimin e energjisë dështojnë. Duke gjykuar nga shkrimet, problemi është ende mungesa e Ironic, nuk do të funksionojë pa shërbim baremetal.
- Auditimet për optimizimin termik dështojnë. Gjurmimi është i njëjtë si për Konsolidimin e Serverit (strategjia e konsolidimit të ngarkesës së punës VM) (gabim i të dhënave burimore)
- Auditimet për qëllimin e optimizimit të rrjedhës së ajrit dështojnë me një gabim.
Janë hasur edhe gabimet e mëposhtme në përfundimin e auditimit. Traceback në regjistrat vendim-engine.log (gjendja e grupit nuk është e përcaktuar).
→ Diskutimi i gabimit
Përfundim
Rezultati i hulumtimit tonë dy-mujor ishte përfundimi i qartë se për të përftuar një sistem të plotë të balancimit të ngarkesës funksionale, në këtë pjesë do të duhet të punojmë ngushtë në rafinimin e mjeteve për platformën Openstack.
Watcher është dëshmuar të jetë një produkt serioz dhe me zhvillim të shpejtë me potencial të jashtëzakonshëm, përdorimi i plotë i të cilit do të kërkojë shumë punë serioze.
Por më shumë për këtë në artikujt e ardhshëm të serisë.
Burimi: www.habr.com