Në sistemet e mëdha cloud, çështja e balancimit automatik ose nivelizimit të ngarkesës në burimet kompjuterike është veçanërisht e rëndësishme. Kjo çështje ka shqetësuar edhe Tioniks (zhvilluesi dhe operatori i shërbimeve cloud, i përfshirë në grupin e kompanive të Rostelekomit).
Dhe, duke qenë se platforma jonë kryesore e zhvillimit është Openstack, dhe ne, si të gjithë njerëzit, jemi kompleksë, u vendos të gjejmë ndonjë modul të gatshëm që tashmë është në përbërje të platformës. Zgjedhja jonë ra te Watcher, të cilin e vendosëm ta përdorim për nevojat tona.
Së pari, le të merremi me terminologjinë dhe përcaktimet.
Termat dhe përcaktimet
QĂ«llimi â Ă«shtĂ« njĂ« rezultat i dukshĂ«m, tĂ« cilin e mund tĂ« matet dhe qĂ« duhet tĂ« arrihet. PĂ«r tĂ« arritur çdo qĂ«llim, ekzistojnĂ« njĂ« ose mĂ« shumĂ« strategji. Strategjia Ă«shtĂ« implementimi i njĂ« algoritmi qĂ« Ă«shtĂ« nĂ« gjendje tĂ« gjejĂ« zgjidhje pĂ«r kĂ«tĂ« qĂ«llim.
Veprimi (Action) â Ă«shtĂ« njĂ« detyrĂ« elementare qĂ« ndryshon gjendjen aktuale tĂ« burimit tĂ« menaxhuar tĂ« grupit OpenStack, siç janĂ«: migrimi i njĂ« makine virtuale (migration), ndryshimi i gjendjes sĂ« energjisĂ« sĂ« nodit (change_node_power_state), ndryshimi i gjendjes sĂ« shĂ«rbimit nova (change_nova_service_state), ndryshimi i flavors (resize), regjistrimi i mesazhit NOP (nop), pasiviteti pĂ«r njĂ« periudhĂ« tĂ« caktuar kohe â pauza (sleep), migrimi i disqeve (volume_migrate).
Plani i veprimit (Action Plan) â Ă«shtĂ« njĂ« rrjedhĂ« specifike veprimesh qĂ« realizohen nĂ« njĂ« rend tĂ« caktuar pĂ«r tĂ« arritur njĂ« QĂ«llim tĂ« caktuar. Plani i veprimit gjithashtu pĂ«rmban njĂ« vlerĂ«sim tĂ« efikasitetit global me njĂ« grup treguesish efikasiteti. Plani i veprimit gjenerohet nga Watcher pas njĂ« auditi tĂ« suksesshĂ«m, ku strategjia e pĂ«rdorur gjen njĂ« zgjidhje pĂ«r arritjen e qĂ«llimit. Plani i veprimit pĂ«rbĂ«het nga njĂ« listĂ« veprimesh tĂ« renditura.
Auditi (Audit) â Ă«shtĂ« njĂ« kĂ«rkesĂ« pĂ«r optimizimin e grupit. Optimizimi realizohet pĂ«r tĂ« arritur njĂ« QĂ«llim nĂ« kĂ«tĂ« grup. PĂ«r çdo audit tĂ« suksesshĂ«m, Watcher gjeneron njĂ« Plan veprimi.
Fusha e auditit (Audit Scope) â Ă«shtĂ« njĂ« grup burimesh, nĂ« tĂ« cilat bĂ«het auditimi (zona tĂ« disponueshmĂ«risĂ«, grumbulluesit e nyjeve, nyjet individuale tĂ« kompjuterit ose nyjet e ruajtjes, etj.). Zonat e auditimit pĂ«rcaktohen nĂ« çdo model. NĂ«se zona e auditimit nuk Ă«shtĂ« specifikuar, auditohet e gjithĂ« klasteri.
Modeli i Auditimit (Audit Template) â njĂ« grup i ruajtur konfigurimesh pĂ«r ekzekutimin e auditit. Modelet janĂ« tĂ« nevojshme pĂ«r tĂ« ekzekutuar shumĂ« herĂ« auditime me konfigurime tĂ« njĂ«jta. Modeli duhet tĂ« pĂ«rmbajĂ« patjetĂ«r qĂ«llimin e auditimit; nĂ«se strategjitĂ« nuk pĂ«rcaktohen, zgjidhen ato strategji mĂ« tĂ« pĂ«rshtatshme nga strategjitĂ« ekzistuese.
Klasteri (Cluster) â Ă«shtĂ« njĂ« grup makinash fizike qĂ« ofrojnĂ« burime kompjuterike, burime ruajtjeje dhe burime rrjeti dhe menaxhohen nga e njĂ«jta nyje menaxhuese OpenStack.
Modeli i tĂ« DhĂ«nave tĂ« Klasterit (Cluster Data Model, CDM) â Ă«shtĂ« njĂ« pĂ«rfaqĂ«sim logjik i gjendjes dhe topologjisĂ« aktuale tĂ« burimeve tĂ« menaxhuara nga klasteri.
Treguesi i Efikasitetit (Efficacy Indicator) â njĂ« tregues qĂ« tregon se si kryhet zgjidhja e krijuar me kĂ«tĂ« strategji. Treguesit e rendimentit janĂ« specifikĂ« pĂ«r qĂ«llimin e caktuar dhe zakonisht pĂ«rdoren pĂ«r tĂ« llogaritur rendimentin global tĂ« planit pĂ«rfundimtar tĂ« veprimit.
Specifikimi i rendimentit (Efficacy Specification) â Ă«shtĂ« njĂ« grup karakteristikash specifike tĂ« lidhura me çdo QĂ«llim, qĂ« pĂ«rcakton treguesit e ndryshĂ«m tĂ« rendimentit qĂ« strategjia, e cila siguron arritjen e qĂ«llimit pĂ«rkatĂ«s, duhet tĂ« sigurojĂ« nĂ« zgjidhjen e saj. NĂ« tĂ« vĂ«rtetĂ«, çdo zgjidhje e propozuar nga strategjia do tĂ« verifikohet pĂ«r t'u pajtuar me specifikimin, pĂ«rpara se tĂ« llogaritet rendimenti i saj global.
Motori i llogaritjes (Scoring Engine) â Ă«shtĂ« njĂ« skedar ekzekutiv qĂ« ka tĂ« dhĂ«na hyrĂ«se tĂ« pĂ«rcaktuara qartĂ«, tĂ« dhĂ«na dalĂ«se tĂ« pĂ«rcaktuara qartĂ« dhe kryen njĂ« detyrĂ« matematike tĂ« pastĂ«r. KĂ«shtu, llogaritja nuk varet nga mjedisi nĂ« tĂ« cilin ekzekutohet, â ajo do tĂ« japĂ« tĂ« njĂ«jtin rezultat kudo.
Planifikuesi Watcher (Watcher Planner) â njĂ« pjesĂ« e mekanizmit tĂ« marrjes sĂ« vendimeve tĂ« Watcher. Ky moduli pranon njĂ« set veprimesh tĂ« gjeneruara nga strategjia dhe krijon njĂ« plan pune qĂ« pĂ«rcakton se si tĂ« planifikohen nĂ« kohĂ« kĂ«to veprime tĂ« ndryshme dhe pĂ«r secilĂ«n veprim, çfarĂ« janĂ« kushtet pĂ«rparĂ«se.
Qëllimet dhe strategjitë e Watcher
QĂ«llimi
Strategjitë
QĂ«llimi Dummy
Strategjia DummyÂ
Strategjia Dummy duke përdorur motorë vlerësimi
Strategjia Dummy me rregullim të madhësisë
Kursimi i Energjisë
Strategjia e Kursimit të Energjisë
Konsolidimi i Serverëve
Konsolidimi i Bazës Offline të Serverëve
Strategjia e Konsolidimit të Ngarkesave të VM
Balancimi i Ngarkesës
Strategjia e Migrimit për Balancimin e Ngarkesës
Strategjia për Balancimin e Kapacitetit të Ruajtjes
Stabilizimi i Ngarkesës
Fqini e Zhurmshme
Fqini e Zhurmshme
Optimizimi Termik
Strategjia e bazuar në temperaturën e daljes
Optimizimi i Ajrit
Strategjia e migrimit të ajrit të njëtrajtshëm
Mirëmbajtja e Harduerit
Migrimi i Zonës
TĂ« Pa Klasifikuar
Aktuator
QĂ«llimi Dummy â njĂ« qĂ«llim rezervĂ« qĂ« pĂ«rdoret pĂ«r testim (reserved goal that is used for testing purposes).
Strategjitë e lidhura: Strategjia Dummy, Strategjia Dummy duke përdorur motorë vlerësimi dhe Strategjia Dummy me rregullim të madhësisë. Strategjia Dummy është një strategji fiktive e përdorur për testimin integrues nëpërmjet Tempest. Kjo strategji nuk ofron asnjë optimizim të dobishëm, qëllimi i saj i vetëm është të përdorë testet Tempest.
Strategjia dummy duke pĂ«rdorur motorĂ« tĂ« mostrĂ«s pĂ«r vlerĂ«sim â strategjia Ă«shtĂ« e ngjashme me tĂ« kaluarĂ«n, ndryshon vetĂ«m pĂ«rmes pĂ«rdorimit tĂ« njĂ« "motori vlerĂ«sues" qĂ« kryen llogaritjet duke pĂ«rdorur metoda tĂ« mĂ«simit tĂ« makinerive.
Strategjia dummy me ripĂ«rcaktim â strategjia Ă«shtĂ« e ngjashme me tĂ« kaluarĂ«n, ndryshon vetĂ«m pĂ«rmes pĂ«rdorimit tĂ« ndryshimit tĂ« flavorit (migro dhe ripĂ«rcakto).
Nuk përdoret në prodhim.
Kursimi i EnergjisĂ« â minimizoni konsumin e energjisĂ«. Strategjia e kĂ«tij qĂ«llimi Saving Energy Strategy sĂ« bashku me strategjinĂ« VM Workload Consolidation Strategy (Server Consolidation) Ă«shtĂ« nĂ« gjendje tĂ« realizojĂ« funksionet e menaxhimit dinamik tĂ« energjisĂ« (DPM), tĂ« cilat kursejnĂ« energji elektrike pĂ«rmes konsolidimit dinamik tĂ« ngarkesave edhe nĂ« periudha tĂ« ngarkesĂ«s sĂ« ulĂ«t: makinat virtuale transferohen nĂ« njĂ« numĂ«r mĂ« tĂ« vogĂ«l nyjesh, ndĂ«rsa nyjet e panevojshme çaktivizohen. Pas konsolidimit, strategjia ofron njĂ« zgjidhje pĂ«r aktivizimin/çaktivizimin e nyjeve nĂ« pĂ«rputhje me parametrat e caktuar: âmin_free_hosts_numâ â numri i nyjeve tĂ« lira tĂ« aktivizuara qĂ« presin ngarkesat, dhe âfree_used_percentâ â proporcioni i nyjeve tĂ« lira tĂ« aktivizuara me numrin e nyjeve qĂ« janĂ« tĂ« zĂ«na nga makinat. PĂ«r funksionimin e strategjisĂ« duhet tĂ« jetĂ« aktivizuar dhe konfiguruar Ironic pĂ«r tĂ« punuar me aktivizimin/çaktivizimin e energjisĂ« nĂ« nyje.
Parametrat e strategjisë
parametri
llojin
në mënyrë default
përshkrimi
free_used_percent
Numri
10.0
proporcioni i numrit të nyjeve të lira të përpunimit me numrin e nyjeve të përpunimit me makina virtuale
min_free_hosts_num
Int
1
numri minimal i nyjeve të lira të llogaritjes
Në cloud duhet të ketë të paktën dy nyje. Metoda e përdorur është ndryshimi i gjendjes së energjisë së nyjës (change_node_power_state). Strategjia e mbledhjes së metrikeve nuk kërkon asnjë kërkesë.
Konsolidimi i ServerĂ«ve â minimizimi i numrit tĂ« nyjeve tĂ« llogaritjes (konsolidimi). Ka dy strategji: Basic Offline Server Consolidation dhe VM Workload Consolidation Strategy.
Strategjia Basic Offline Server Consolidation minimizon numrin total të serverëve të përdorur dhe gjithashtu minimizon numrin e migrimeve.
Strategjia bazë kërkon metrike të mëposhtme:
metrikë
shërbim
plugina
komentar
compute.node.cpu.percent
none
Â
cpu_util
none
Â
Parametrat e strategjisĂ«: migration_attempts â numri i kombinimeve pĂ«r tĂ« kĂ«rkuar kandidatĂ« potencialĂ« pĂ«r fikje (me default, 0, nuk ka kufizime), period â intervali i kohĂ«s nĂ« sekonda pĂ«r tĂ« marrĂ« agregimin statik nga burimi i tĂ« dhĂ«nave tĂ« metrikeve (me default, 700).
Metodat e përdorura: migrimi, ndryshimi i gjendjes së shërbimit nova (change_nova_service_state).
Strategjia e Konsolidimit të Ngarkesës VM bazohet në një algoritëm heuristik të parë të përshtatshëm (first-fit), i cili fokusohet në ngarkesën e matur të CPU dhe përpiqet të minimizojë nodet që kanë ngarkesë shumë të madhe ose shumë të vogël duke marrë parasysh kufizimet e kapacitetit të burimeve. Kjo strategji ofron një zgjidhje që çon në përdorim më efikas të burimeve të klashtër, duke përdorur katër faza si më poshtë:
- Faza e shkarkimit â trajtimi i burimeve tĂ« tejkaluara;
- Faza e konsolidimit â trajtimi i burimeve tĂ« nĂ«npĂ«rdorura;
- Optimizimi i zgjidhjes â reduktimi i numrit tĂ« migrimeve;
- Ăaktivizimi i nodĂ«ve tĂ« kompjuterĂ«ve tĂ« pavendosur.
Strategjia kërkon metrika të mëposhtme:
metrikë
shërbim
plugina
komentar
memory
none
Â
disk.root.size
none
Â
Metrikat e mëposhtme nuk janë të detyrueshme, por rrisin saktësinë e strategjisë, nëse janë në dispozitë:
metrikë
shërbim
plugina
komentar
memory.resident
none
Â
cpu_util
none
Â
Parametrat e strategjisĂ«: period â intervali i kohĂ«s nĂ« sekonda pĂ«r tĂ« marrĂ« agregat statik nga burimi i tĂ« dhĂ«nave tĂ« metrikĂ«s (nĂ« mĂ«nyrĂ« tĂ« paracaktuar, 3600).
Përdor të njëjtat metoda si strategjia e mëparshme. Më shumë informacion .
Balancimi i NgarkesĂ«s â balancimi i ngarkesĂ«s sĂ« punĂ«s midis nyjeve pĂ«rpunuese. QĂ«llimi ka tri strategji: Strategjia e Migrimit tĂ« Balancimit tĂ« NgarkesĂ«s, Stabilizimi i NgarkesĂ«s sĂ« PunĂ«s, Strategjia e Balancimit tĂ« Kapacitetit tĂ« Ruajtjes.
Strategjia e Migrimit të Balancimit të Ngarkesës nis migrimet e makinave virtuale në bazë të ngarkesës së punës së makinave virtuale në nyje. Vendimi për të kaluar merret çdo herë kur % e përdorimit të CPU-së ose RAM-it të nyjes kalon pragun e caktuar. Gjatë kësaj, makina virtuale që zhvendoset duhet ta afrojë nyjen në ngarkesën mesatare të punës së të gjitha nyjeve.
KĂ«rkesat
- Përdorimi i procesorëve fizikë;
- Të paktën dy nyje fizike përpunuese;
- NjĂ« komponent i instaluar dhe i konfiguruar Ceilometer â ceilometer-agent-compute, qĂ« funksionon nĂ« çdo nyje pĂ«rpunuese, dhe Ceilometer API, si dhe mbledhja e metrikave tĂ« mĂ«poshtme:
metrikë
shërbim
plugina
komentar
cpu_util
none
Â
memory.resident
none
Â
Parametrat e strategjisë:
parametri
llojin
në mënyrë default
përshkrimi
metrikat
String
'cpu_util'
Metrikat që qëndrojnë në bazë: 'cpu_util', 'memory.resident'.
pragu
Numri
25.0
Pragu i ngarkesës së punës për migrimin.
periudha
Numri
300
Periudha e përgjithshme e kohës së Ceilometer.
Metoda e pĂ«rdorur â migrimi.
Stabilizimi i ngarkesĂ«s â njĂ« strategji e orientuar drejt stabilizimit tĂ« ngarkesĂ«s sĂ« punĂ«s duke pĂ«rdorur migrimin e gjallĂ«. Kjo strategji bazohet nĂ« algoritmin e devijimit standard dhe pĂ«rcakton nĂ«se ka mbingarkesĂ« nĂ« grup dhe reagon duke iniciuar migrimin e makinerive pĂ«r tĂ« stabilizuar grupin.
KĂ«rkesat
- Përdorimi i procesorëve fizikë;
- Të paktën dy nyje fizike përpunuese;
- NjĂ« komponent i instaluar dhe i konfiguruar Ceilometer â ceilometer-agent-compute, qĂ« funksionon nĂ« çdo nyje pĂ«rpunuese, dhe Ceilometer API, si dhe mbledhja e metrikave tĂ« mĂ«poshtme:
metrikë
shërbim
plugina
komentar
cpu_util
none
Â
memory.resident
none
Â
Strategjia e Balancimit tĂ« Kapacitetit tĂ« Ruajtjes (implementuar qĂ« nga Queens) â strategjia transferon diskĂ«t nĂ« varĂ«si tĂ« ngarkesĂ«s sĂ« grupeve Cinder. Vendimi pĂ«r transferim merret çdo herĂ« kur koeficienti i pĂ«rdorimit tĂ« grupit tejkalon pragun e caktuar. Disku qĂ« po transferohet duhet tĂ« afrojĂ« grupin me ngarkesĂ«n mesatare tĂ« tĂ« gjithĂ« grupeve Cinder.
KĂ«rkesat dhe kufizimet
- Të paktën dy grupe Cinder;
- Mundësia për migrimin e diskëve.
- Modeli i tĂ« dhĂ«nave tĂ« grupit â grumbulli i tĂ« dhĂ«nave Cinder.
Parametrat e strategjisë:
parametri
llojin
në mënyrë default
përshkrimi
volume_threshold
Numri
80.0
Vlera pragore e diskëve për balancimin e volumit.
Metoda e pĂ«rdorur â migrimi i diskut (volume_migrate).
FqinjĂ«si e Zhurmshme â identifikoni dhe transferoni "fqinjĂ«sin e zhurmshĂ«m" â njĂ« makinĂ« virtuale me pĂ«rprioritet tĂ« ulĂ«t, e cila ndikon negativisht nĂ« performancĂ«n e njĂ« makine virtuale me pĂ«rprioritet tĂ« lartĂ« nga pikĂ«pamja e IPC, duke pĂ«rdorur shumicĂ«n e Last Level Cache. Strategjia jonĂ«: FqinjĂ«si i ZhurmshĂ«m (parametri i pĂ«rdorur pĂ«r strategjinĂ« â cache_threshold (vlera e paracaktuar â 35), kur performanca bie nĂ« vlerĂ«n e caktuar, aktivizohet migrimi. PĂ«r tĂ« funksionuar strategjia, kĂ«rkohet qĂ« metricat LLC (Last Level Cache), serveri mĂ« i fundit Intel me mbĂ«shtetje pĂ«r CMT, si dhe grumbullimi i metricave tĂ« mĂ«poshtme:
metrikë
shërbim
plugina
komentar
cpu_l3_cache
none
Nevojitet Intel .
Modeli i tĂ« dhĂ«nave tĂ« grupit (e paracaktuar): Nova cluster data model collector. Metoda e aplikuar â migrimi.
Puna me këtë objektiv përmes Dashboard nuk është realizuar plotësisht në Queens.
Optimizimi Termik â optimizoni regjimin e temperaturĂ«s. Temperatura nĂ« dalje (ajri i nxjerrĂ«) Ă«shtĂ« njĂ« nga sistemet e rĂ«ndĂ«sishme tĂ« telemetrisĂ« termike pĂ«r tĂ« matur gjendjen e ngarkesĂ«s termike / punuese tĂ« serverit. PĂ«r kĂ«tĂ« qĂ«llim Ă«shtĂ« njĂ« strategji â Strategjia e bazuar nĂ« temperaturĂ«n e daljes, e cila merr vendime pĂ«r tĂ« transferuar ngarkesat nĂ« nyjat me njĂ« regjimin tĂ« favorshĂ«m tĂ« temperaturĂ«s (temperatura mĂ« e ulĂ«t nĂ« dalje), kur temperatura nĂ« dalje e hosteve burim arrin njĂ« prag tĂ« konfigurueshĂ«m.
Për funksionimin e strategjisë nevojitet një server me Intel Power Node Manager të instaluar dhe të konfiguruar , si dhe grumbullimi i metricave të mëposhtme:
metrikë
shërbim
plugina
komentar
hardware.ipmi.node.outlet_temperature
IPMI
Â
Parametrat e strategjisë:
parametri
llojin
në mënyrë default
përshkrimi
pragu
Numri
35.0
Pragu i temperaturës për migrimin.
periudha
Numri
30
Intervali i kohës në sekonda për marrjen e agregatës statistikore nga burimi i të dhënave të metrikës.
Metoda e pĂ«rdorur â migrimi.
Optimizimi i Ajrit â optimizoni modin e ventilimit. Strategjia jonĂ« â Uniform Airflow using live migration. Strategjia aktivizon migrimin e makinĂ«s virtuale sa herĂ« qĂ« ajri nga ventilatori i serverit tejkalon pragun e pĂ«rcaktuar.
Për funksionimin e strategjisë nevojiten:
- Harduer: nyjat llogaritusese <me mbështetje për NodeManager 3.0;
- Të paktën dy nodë kompjuterike;
- Komponenti ceilometer-agent-compute dhe Ceilometer API, i instaluar dhe i konfiguruar në çdo nodë kompjuterike, i cili mund të raportojë me sukses metrika si fluksi i ajrit, fuqia e sistemit, temperatura në hyrje:
metrikë
shërbim
plugina
komentar
hardware.ipmi.node.airflow
IPMI
Â
hardware.ipmi.node.temperature
IPMI
Â
hardware.ipmi.node.power
IPMI
Â
Përveç kësaj, nevojitet një server me Intel Power Node Manager 3.0 ose një version më të ri të instaluar dhe të konfiguruar.
Kufizime: Koncepti nuk është i destinuar për prodhim.
Sugjerohet që të përdoret ky algoritëm me audite të vazhdueshme, pasi gjatë një iteracioni planifikohet migraimi vetëm i një makine virtuale.
Migraret e drejta janë të mundshme.
Parametrat e strategjisë:
parametri
llojin
në mënyrë default
përshkrimi
threshold_airflow
Numri
400.0
Pragu i fluksit të ajrit për migërimin Njësia është 0.1CFM
threshold_inlet_t
Numri
28.0
Pragu i temperaturës në hyrje për vendimin e migërimit
threshold_power
Numri
350.0
Pragu i fuqisë së sistemit për vendimin e migërimit
periudha
Numri
30
Intervali i kohës në sekonda për marrjen e agregatës statistikore nga burimi i të dhënave të metrikës.
Metoda e pĂ«rdorur â migrimi.
MirĂ«mbajtja e Harduerit â shĂ«rbimi i pajisjeve harduerike. Strategjia e lidhur me kĂ«tĂ« objektiv Ă«shtĂ« Migrimi i ZonĂ«s. Kjo strategji Ă«shtĂ« njĂ« mjet pĂ«r migimin efikas, automatik dhe minimal tĂ« makinĂ« virtuale dhe disqeve nĂ« rast nevoje pĂ«r mirĂ«mbajtjen teknike tĂ« pajisjeve harduerike. Strategjia ndihmon nĂ« ndĂ«rtimin e njĂ« plani veprimi sipas peshave: grupe veprimesh me mĂ« shumĂ« peshĂ« do tĂ« planifikohen mĂ« herĂ«t se tĂ« tjerat. Ka dy parametra konfigurimi: peshat e veprimeve (action_weights) dhe paralelizimi (parallelization).
Kufizimet: kërkohet konfigurimi i peshave të veprimeve dhe paralelizimit.
Parametrat e strategjisë:
parametri
llojin
në mënyrë default
përshkrimi
compute_nodes
array
Asnjë
Njësi llogaritëse për migrim.
storage_pools
array
Asnjë
Njësitë e ruajtjes për migrim.
parallel_total
integer
6
Numri total i veprimeve që duhet të kryhen paralelisht.
parallel_per_node
integer
2
Numri i veprimeve që kryhen paralelisht për çdo njësinë llogaritëse.
parallel_per_pool
integer
2
Numri i veprimeve që kryhen paralelisht për çdo grup ruajtjeje.
prioriteti
object
Asnjë
Lista e prioriteteve për makinat virtuale dhe disqet.
with_attached_volume
boolean
False
False â makinat virtual do tĂ« transferohen pas transferimit tĂ« tĂ« gjithĂ« disqeve. True â makinat virtual do tĂ« transferohen pas migrimit tĂ« tĂ« gjithĂ« disqeve tĂ« lidhura.
Elementet e arrays së nyjeve kompjuterike:
parametri
llojin
në mënyrë default
përshkrimi
src_node
string
Asnjë
Nyja kompjuterike nga e cila po transferohen makinat virtuale (e domosdoshme).
dst_node
string
Asnjë
Nyja kompjuterike në të cilën migrrohen makinat virtuale.
Elementet e arrays së nyjeve të ruajtjes:
parametri
llojin
në mënyrë default
përshkrimi
src_pool
string
Asnjë
Puli i ruajtjes nga e cila po transferohen disqet (e domosdoshme).
dst_pool
string
Asnjë
Puli i ruajtjes në të cilin po transferohen disqet.
src_type
string
Asnjë
Tipi origjinë i disqit (e domosdoshme).
dst_type
string
Asnjë
Tipi përfundimtar i disqit (e domosdoshme).
Elementet e prioriteteve të objekteve:
parametri
llojin
në mënyrë default
përshkrimi
project
array
Asnjë
Emrat e projekteve.
compute_node
array
Asnjë
Emrat e nyjeve kompjuterike.
storage_pool
array
Asnjë
Emrat e pulave të ruajtjes.
compute
enum
Asnjë
Parametrat e makinave virtuale [âvcpu_numâ, âmem_sizeâ, âdisk_sizeâ, âcreated_atâ].
storage
enum
Asnjë
Parametrat e disqeve [âsizeâ, âcreated_atâ].
Metodat e pĂ«rdorura â migrimi i makinave virtuale, migrimi i disqeve.
TĂ« Pa Klasifikuar â njĂ« qĂ«llim ndihmĂ«s, i pĂ«rdorur pĂ«r tĂ« lehtĂ«suar procesin e zhvillimit tĂ« strategjisĂ«. Nuk pĂ«rmban specifikime dhe mund tĂ« pĂ«rdoret kur strategjia nuk Ă«shtĂ« ende e lidhur me njĂ« qĂ«llim ekzistues. Ky qĂ«llim gjithashtu mund tĂ« pĂ«rdoret si njĂ« hap kalimtar. Strategjia e lidhur me kĂ«tĂ« qĂ«llim Ă«shtĂ« Actuator.  Â
Krijimi i një qëllimi të ri
Watcher Decision Engine ka njĂ« ndĂ«rfaqe plugin âqĂ«llimi i jashtĂ«mâ, i cili lejon integrimin e njĂ« qĂ«llimi tĂ« jashtĂ«m, i cili mund tĂ« arrihet pĂ«rmes strategjisĂ«.
Para se të krijoni një qëllim të ri, sigurohuni që asnjë nga qëllimet ekzistuese nuk përputhet me nevojat tuaja.
Krijimi i një plugini të ri
Për të krijuar një qëllim të ri, ju duhet të: zgjeroni klasën e qëllimit, implementoni metodën e klasës get_name () për të kthyer identifikuesin unik të qëllimit të ri që dëshironi të krijoni. Ky identifikues unik duhet të përputhet me emrin e pikës së hyrjes që do të shpallni më vonë.
Më pas është e nevojshme të implementoni metodën e klasës get_display_name () për të kthyer emrin e shfaqjes së përkthyer të objektit që dëshironi të krijoni (mos përdorni një variabël për të kthyer varg e përkthyer për ta bërë atë të mundur të mblidhet automatikisht nga një mjet përkthimi).
Implementoni metodën e klasës get_translatable_display_name (), për të kthyer çelësin e përkthimit (në fakt emrin e shfaqjes në anglisht) të objektit tuaj të ri. Vlera e kthyer duhet të përputhet me vargun e përkthyer në get_display_name ().
Implementoni metodën e tij get_efficacy_specification (), për të kthyer specifikimin e efikasitetit për objektin tuaj. Metoda get_efficacy_specification () kthen një instancë Unclassified (), e siguruar nga Watcher. Ky specifikim efikasiteti është i dobishëm në procesin e zhvillimit të objektit tuaj, pasi i përshtatet specifikimit të zbrazët.
â
Arkitektura e Watcher (më shumë ).
Komponentët
Watcher API â komponenti qĂ« implementon REST API-nĂ« e ofruar nga Watcher. Mekanizmat e ndĂ«rveprimit: CLI, plugin Horizon, Python SDK.
Watcher DB â baza e tĂ« dhĂ«nave tĂ« Watcher.
Watcher Applier â komponenti qĂ« zbatosh pĂ«rmbushjen e planit tĂ« veprimit, tĂ« krijuar nga komponenti Watcher Decision Engine.
Watcher Decision Engine â komponenti qĂ« Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r llogaritjen e njĂ« grupi veprimesh potenciale pĂ«r optimizimin e arritjes sĂ« qĂ«llimit tĂ« auditit. NĂ«se strategjia nuk Ă«shtĂ« e caktuar, komponenti zgjedh vetĂ« atĂ« mĂ« tĂ« pĂ«rshtatshme.
Botuesi i Metrikave tĂ« Watcher â komponenti qĂ« mbledh dhe llogarit disa metrika ose ngjarje dhe i botĂ«n ato nĂ« pikĂ«n fundore tĂ« CEP. Funksionaliteti i komponentit mund tĂ« ofrohet gjithashtu nga botuesi Ceilometer.
MakinĂ« pĂ«r Procesimin e Ngjarjeve tĂ« Kompleksuara (CEP) â njĂ« makinĂ« pĂ«r procesimin e ngjarjeve komplekse. PĂ«r arsye tĂ« performancĂ«s, mund tĂ« ketĂ« disa instanca tĂ« MakinĂ«s CEP qĂ« punojnĂ« nĂ« tĂ« njĂ«jtĂ«n kohĂ«, secila qĂ« pĂ«rpunon njĂ« tip tĂ« caktuar metri / ngjarjesh. NĂ« sistemin Watcher, CEP aktivizon dy lloje veprimesh: â regjistrimi i ngjarjeve / metrike pĂ«rkatĂ«se nĂ« databazĂ«n e kohĂ«ve; â dĂ«rgimi i ngjarjeve pĂ«rkatĂ«se nĂ« komponentin Watcher Decision Engine, kur kjo ngjarje mund tĂ« ndikojĂ« nĂ« rezultatet e strategjisĂ« aktuale tĂ« optimizimit, pasi klasteri OpenStack nuk Ă«shtĂ« njĂ« sistem statik.
Ndërveprimi i komponentëve kryhet sipas protokollit AMQP.
â
Skema e ndërveprimit me Watcher
Rezultatet e testimit të Watcher
- NĂ« faqen Optimization â Planet e veprimit ka njĂ« gabim 500 (si nĂ« Queens tĂ« pastĂ«r ashtu edhe nĂ« skenĂ«n me modulat TioniX), qĂ« shfaqet vetĂ«m pasi tĂ« nisĂ« auditi dhe tĂ« gjenerohet plani i veprimit, hapja e zbrazĂ«t bĂ«het normalisht.
- Në skedën Detajet e veprimit ka gabime, nuk mund të merret objekti dhe strategjia e auditit (si në Queens të pastër ashtu edhe në skenën me modulat TioniX).
- Auditimet me objektiv Dummy (teste) krijohen dhe nisin normalisht, planet e veprimit gjenerohen.
- Auditimet me objektiv Unclassified nuk krijohen, pasi objekti nuk është funksional dhe është i destinuar për konfigurim të përkohshëm gjatë krijimit të strategjive të reja.
- Auditimet me objektiv Workload Balancing (strategjia Storage Capacity balance) krijohen me sukses, megjithatë plani i veprimit nuk gjenerohet. Optimizimi i grupeve të ruajtjes nuk nevojitet.
- Auditimet me objektiv Workload Balancing (strategjia Workload Balance Migration Strategy) krijohen me sukses, megjithatë plani i veprimit nuk gjenerohet.
- Auditimet me objektiv Workload Balancing (strategjia Workload Stabilization Strategy) përfundojnë me gabim.
- Auditimet me objektiv Noisy Neighbor krijohen me sukses, megjithatë plani i veprimit nuk gjenerohet.
- Auditët për mirëmbajtjen e harduerit krijohen me sukses, plani i veprimit gjenerohet në mënyrë të paplotë (gjenerohen treguesit e performancës, por lista e veprimeve vetë nuk gjenerohet).
- Ndryshimet në konfigurimet nova.conf (në seksionin default compute_monitors = cpu.virt_driver) në nyjat llogaritëse dhe menaxhuese nuk rregullojnë gabimet.
- Auditët për konsolidimin e serverëve (strategjia Basic) gjithashtu përfundojnë me gabim.
- Auditët për konsolidimin e serverëve (strategjia VM workload consolidation) përfundojnë me gabim. Në loge ka gabime në marrjen e të dhënave hyrëse. Diskutimi i gabimit, në veçanti, .
Provua të specifikohet në skedarin e konfigurimit të Watcher (nuk ndihmoi - si rezultat, gabime në të gjitha faqet e Optimësimit, kthimi në përmbajtjen fillestare të skedarit të konfigurimit nuk e rregullon situatën):[watcher_strategies.basic]
datasource = ceilometer, gnocchi - Auditët për kursimin e energjisë përfundojnë me gabim. Sipas logeve, problemi duket se është mungesa e Ironic, nuk do të punojë pa shërbimin baremetal.
- Auditët për optimizimin termik përfundojnë me gabim. Traceback është i njëjtë me atë për konsolidimin e serverëve (strategjia VM workload consolidation) (gabimi i të dhënave hyrëse).
- Auditët për optimizimin e Airflow përfundojnë me gabim.
Këto gabime përfundimtare të auditit gjithashtu ndodhin. Traceback në logët decision-engine.log (gjendja e klasterit nuk është e përcaktuar).
â Diskutimi i gabimit
PĂ«rfundimi
Rezultati i kërkimeve tona dy mujore është një konkluzion i qartë se për të krijuar një sistem të plotë dhe funksional të balancimit të ngarkesës, na duhet që të angazhohemi thellësisht në përmirësimin e mjeteve për platformën Openstack.
Watcher ka treguar veten si një produkt i rëndësishëm dhe në zhvillim të shpejtë me një potencial të jashtëzakonshëm, për përdorimin e të cilit do të jetë e nevojshme një punë e madhe dhe serioze.
Por pĂ«r kĂ«tĂ« â nĂ« artikujt e ardhshĂ«m tĂ« ciklit.
Burimi: habr.com
