Në sistemet e mëdha të reve, çështja e balancimit automatik ose rregullimit të ngarkesës mbi burimet kompjuterike është veçanërisht e rëndësishme. Këtë problem e kanë marrë parasysh edhe në Tionix (zhvillues dhe operator shërbimesh të reve, pjesë e grupit të kompanive Rostelecom).
Dhe, pasi platforma jonë kryesore e zhvillimit është Openstack, dhe ne, si të gjithë njerëzit, jemi lenkë, u vendos të zgjidhet ndonjë modul i gatshëm që është tashmë në përbërje të platformës. Zgjedhja jonë ra mbi Watcher, të cilin e vendosëm ta përdorim për nevojat tona.
Për të filluar, le të sqarojmë terminologjinë dhe përkufizimet.
Termat dhe përkufizimet
Qëllimi — është një rezultat përfundimtar, i lexueshëm për njerëzit, që mund të vërehet dhe matet, i cili duhet të arrihet. Për të arritur çdo qëllim ka një ose më shumë strategji. Strategjia — është realizimi i një algoritmi që është në gjendje të gjejë një zgjidhje për këtë qëllim.
Veprimi (Action) — është një detyrë elementare që ndryshon gjendjen aktuale të burimit të menaxhuar të OpenStack cluster, si: migrimi i një mașine virtuale (migration), ndryshimi i gjendjes së furnizimit të nyjës (change_node_power_state), ndryshimi i gjendjes së shërbimit nova (change_nova_service_state), ndryshimi i flavor-it (resize), regjistrimi i një mesazhi NOP (nop), mungesa e veprimit për një periudhë të caktuar kohe — pauzë (sleep), migrimi i një disku (volume_migrate).
Plani i Veprimeve (Action Plan) — është një rrjedhë specifike veprimesh, të realizuara në një rend të caktuar për të arritur një Qëllim specifik. Plani i veprimeve gjithashtu përmban një efektivitet të përgjithshëm të vlerësuar me një grup treguesish të performancës. Plani i veprimeve gjenerohet nga Watcher pas një auditi të suksesshëm, në të cilin strategjia e përdorur gjen një zgjidhje për arritjen e qëllimit. Plani i veprimeve përbëhet nga një listë e veprimeve të renditura pas njëra-tjetrës.
Auditi (Audit) — është një kërkesë për optimizimin e klasterit. Optimizimi kryhet për të arritur një Qëllim në këtë klaster. Për çdo audit të suksesshëm, Watcher gjeneron një Plan veprimesh.
Fusha e auditit (Audit Scope) — është një grup burimesh, brenda të cilave kryhet auditi (zona e aksesit, agregatorët e nyjeve, nyjet e veçanta ose nyjet e ruajtjes, etj.). Zona e auditit është e përcaktuar në çdo model. Nëse zona e auditit nuk është përcaktuar, auditohet e gjithë grumbulli.
Modeli i Auditimit (Audit Template) — një grup i ruajtur i konfigurimeve për të nisur auditin. Modelet janë të nevojshme për të kryer auditime shumë herë me të njëjtat konfigurime. Modeli duhet të përmbajë patjetër qëllimin e auditit, nëse strategjitë nuk janë të përcaktuara, atëherë zgjidhen strategjitë më të përshtatshme nga strategjitë ekzistuese.
Grumbulli (Cluster) — është një grup makinash fizike që ofrojnë burime kompjuterike, burime ruajtjeje dhe burime rrjeti dhe menaxhohen nga të njëjtin nyje menaxhimi OpenStack.
Modeli të Dhënave të Grumbullit (Cluster Data Model, CDM) — është një përfaqësim logjik i gjendjes aktuale dhe topologjisë së burimeve të menaxhuara nga grumbulli.
Të Dhënat e Efiçencës (Efficacy Indicator) — është një tregues që tregon se si realizohet zgjidhja e krijuar me këtë strategji. Të dhënat e efiçencës janë specifike për qëllimin e caktuar dhe zakonisht përdoren për të llogaritur efiçencën globale të planit përfundimtar të veprimit.
Specifikimi i Efiçencës (Efficacy Specification) — është një grup veçorish specifike, i lidhur me çdo Qëllim, i cili përcakton tregues të ndryshëm efiçence 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 siguruar që i përmbush specifikimet, para se të llogaritet efiçenca e saj globale.
Motori i Llogaritjes (Scoring Engine) — është një skedar ekzekutiv, i cili ka të dhëna hyrëse dhe dalëse të përcaktuara qartë dhe kryen një detyrë matematikore të pastër. Kështu, llogaritja nuk varet nga mjedisi në të cilin realizohet, - do të japë një rezultat të njëjtë në çdo vend.
Planifikuesi Watcher (Watcher Planner) — pjesa e mekanizmit të marrjes së vendimeve Watcher. Ky modul merr një grup veprimesh të gjeneruara nga strategjia dhe krijon një plan pune që përcakton si të planifikohen në kohë këto veprime të ndryshme dhe për secilën veprim, cila janë kushtet paraprake.
Qëllimet dhe strategjitë Watcher
Qëllimi
Strategjitë
Qëllimi Dummy
Strategjia Dummy
Strategjia Dummy duke përdorur engine-t e mostrave të renditjes
Strategjia Dummy me ndryshimin e madhësisë
Ruajtja e Energjisë
Strategjia e Ruajtjes së Energjisë
Konsolidimi i Serverëve
Konsolidimi i Serverëve Offline Bazë
Strategjia e Konsolidimit të Ngarkesave VM
Balancimi i Ngarkesave
Strategjia e Migrimit të Balancimit të Ngarkesave
Strategjia e Balancimit të Kapacitetit të Ruajtjes
Stabilizimi i Ngarkesave
Fqinj i Zhurmshëm
Fqinj i Zhurmshëm
Optimizimi Termik
Strategjia e bazuar në temperaturën e daljeve
Optimizimi i Fluksit të Ajrit
Strategjia e migrimit të fluksit të ajrit të njëjtë
Mirëmbajtja e Hardware-it
Migrimi i Zonës
Pa Klasifikim
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 engine-t e mostrave të renditjes dhe strategjia Dummy me ndryshimin e madhësisë. Strategjia Dummy — është një strategji e rreme që përdoret për testim integrimi përmes 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 engine-t e mostrave të renditjes — strategjia është e ngjashme me të kaluarën, ndryshimi është se përdor një 'engine' të mostrave të 'renditjes', që mbulon llogaritjen duke përdorur metoda të mësimit të makinerive.
Strategjia Dummy me ndryshimin e madhësisë — strategjia është e ngjashme me të kaluarën, ndryshimi është se përdor ndryshimin e 'flavor' (migrim dhe ndryshim përmasash).
Nuk përdoret në prodhim.
Ruajtja e Energjisë — minimizimi i konsumit të energjisë. Strategjia e këtij qëllimi, Strategjia e Ruajtjes së Energjisë, së bashku me strategjinë e Konsolidimit të Ngarkesave VM (Konsolidimi i Serverëve), është në gjendje të kryejë funksionet e menaxhimit dinamik të energjisë (DPM), të cilat kursejnë energji elektrike duke konsoliduar dinamikisht ngarkesat edhe në periudha me ngarkesë të ulët të burimeve: makinat virtuale transferohen në një numër më të vogël të nyjeve dhe nyjet e panevojshme — çaktivizohen. Pas konsolidimit, strategjia ofron një zgjidhje për ndezjen / çaktivizimin e nyjeve sipas parametrave të caktuar: 'min_free_hosts_num' — numri i nyjeve të lira të ndezura që presin ngarkesa, dhe 'free_used_percent' — përqindja e nyjeve të lira të ndezura në raport me numrin e nyjeve që janë të zëna nga makineritë. Për të punuar strategjia duhet të aktivizohet dhe konfigurohet Ironic për të punuar me ndezjen / çaktivizimin e energjisë në nyje.
Parametrat e strategjisë
parametri
tipin
si parazgjedhje
përshkrim
free_used_percent
Numri
10.0
raporti i numrit të nyjeve të lira kompjuterike në numrin e nyjeve kompjuterike me makina virtuale
min_free_hosts_num
Int
1
numri minimal i nyjeve të lira kompjuterike
Në cloud duhet të ketë së paku dy nyje. Metoda e përdorur është ndryshimi i gjendjes së energjisë së nyjes (change_node_power_state). Kjo strategji nuk kërkon mbledhjen e metrikave.
Konsolidimi i Serverëve — minimizimi i numrit të nyjeve kompjuterike (konsolidim). Ka dy strategji: Basic Offline Server Consolidation dhe VM Workload Consolidation Strategy.
Strategjia Basic Offline Server Consolidation minimizon numrin e përgjithshëm të serverëve të përdorur, si dhe minimizon numrin e migrimeve.
Strategjia bazë kërkon metrikat e mëposhtme:
metrika
shërbimi
plugina
koment
compute.node.cpu.percent
none
cpu_util
none
Parametrat e strategjisë: migration_attempts — numri i kombinimeve për të gjetur kandidatët potencial për fikje (në mënyrë default, 0, pa kufizime), period — intervali i kohës në sekonda për të marrë agregimin statik nga burimi i të dhënave të metrikave (në mënyrë default, 700).
Metodat e përdorura: migrimi, ndryshimi i gjendjes së shërbimit nova (change_nova_service_state).
Strategjia VM Workload Consolidation Strategy bazohet në algoritmin heauristik të përshtatjes së parë (first-fit), i cili fokusohet në ngarkesën e matur të CPU dhe përpiqet të minimizojë nyjet 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ërdorimin më efikas të burimeve të klastri, duke përdorur katër faza të mëposhtme:
- Faza e shpërndarjes — trajtimi i burimeve të tepruara;
- Faza e konsolidimit — trajtimi i burimeve të nënpërdorura;
- Optimizimi i zgjidhjes — reduktimi i numrit të migrimeve;
- Fikja e nyjeve kompjuterike të papërdorura.
Strategjia kërkon metrikat e mëposhtme:
metrika
shërbimi
plugina
koment
memory
none
disk.root.size
none
Metrikat e mëposhtme nuk janë obligative, por rrisin saktësinë e strategjisë nëse janë të disponueshme:
metrika
shërbimi
plugina
koment
memory.resident
none
cpu_util
none
Parametrat e strategjisë: period — intervali i kohës në sekonda për të marrë agregimin statik nga burimi i të dhënave të metrikave (në mënyrë default, 3600).
Përdor të njëjtat metoda si strategjia e mëparshme. Më shumë informacion .
Balancimi i Ngarkesave — balancimi i ngarkesës midis nyjeve kompjuterike. Qëllimi ka tre strategji: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.
Strategjia e Migrimit të Balancimit të Ngarkesës aktivon migrimet e makinave virtuale bazuar në ngarkesën e makinave virtuale të nyjeve. Vendimi për të transferuar merret çdo herë kur % e përdorimit të CPU ose RAM të nyjës tejkalon pragu i caktuar. Në të njëjtën kohë, makina virtuale që po transferohet duhet të afrojë nyjën me ngarkesën mesatare të punës së të gjitha nyjeve.
Kërkesat
- Përdorimi i procesorëve fizikë;
- Minimumi dy nyje të llogaritjes fizike;
- Një komponent i instaluar dhe i konfiguruar Ceilometer — ceilometer-agent-compute, i punësuar në çdo nyje llogaritëse, dhe API e Ceilometer, si dhe mbledhja e metricave të mëposhtme:
metrika
shërbimi
plugina
koment
cpu_util
none
memory.resident
none
Parametrat e strategjisë:
parametri
tipin
si parazgjedhje
përshkrim
metricat
String
'cpu_util'
Metricat në bazë të: 'cpu_util', 'memory.resident'.
threshold
Numri
25.0
Pragu i ngarkesës për migrim.
periudha
Numri
300
Përgjithësimi i periudhës së Ceilometer.
Metoda e përdorur — migrimi.
Stabilizimi i ngarkesës — një strategji e orientuar për stabilizimin e ngarkesës duke përdorur migrimin e gjallë. Strategjia është e bazuar në algoritmin e standardit të devijimit dhe përcakton, nëse ekziston mbingarkesë në klaster dhe reagon ndaj saj duke aktivizuar migrimin e makinave për të stabilizuar klasterin.
Kërkesat
- Përdorimi i procesorëve fizikë;
- Minimumi dy nyje të llogaritjes fizike;
- Një komponent i instaluar dhe i konfiguruar Ceilometer — ceilometer-agent-compute, i punësuar në çdo nyje llogaritëse, dhe API e Ceilometer, si dhe mbledhja e metricave të mëposhtme:
metrika
shërbimi
plugina
koment
cpu_util
none
memory.resident
none
Strategjia e Balancimit të Kapacitetit të Ruajtjes (strategjia është realizuar që nga Queens) — strategjia përcakton transferimin e disqeve në varësi të ngarkesës së pularive Cinder. Vendimi për transferim merret çdo herë kur koeficienti i përdorimit të pularive tejkalon pragun e caktuar. Disku që po transferohet duhet të afrojë pularinë me ngarkesën mesatare të të gjitha pularive Cinder.
Kërkesat dhe kufizimet
- Minimumi dy pulari Cinder;
- Mundësia e migrimit të disqeve.
- Modeli i të dhënave të klasterit — modeli i të dhënave të klasterit Cinder.
Parametrat e strategjisë:
parametri
tipin
si parazgjedhje
përshkrim
volume_threshold
Numri
80.0
Vlera e pragut për disqet për balancimin e volumit.
Metoda e përdorur — migrimi i disqeve (volume_migrate).
Fqinji i Zhurmshëm — identifikimi dhe transferimi i 'fqinjit të zhurmshëm' — makinës virtuale me prioritet të ulët, e cila ndikonn negativisht në performancën e makinës virtuale me prioritet të lartë në terma të IPC, duke përdorur tepër Koshin e Nivelit të Fundit. Strategjia vetjake: Fqinji i Zhurmshëm (parametri i përdorur për strategjinë — cache_threshold (vlera e paracaktuar — 35), kur performanca bie deri në vlerën e caktuar, aktivizohet migrimi. Për funksionimin e strategjisë kërkohen metrike të aktivizuara LLC (Koshi i Nivelit të Fundit), serveri më i fundit Intel me mbështetje për CMT, si dhe mbledhja e metricave të mëposhtme:
metrika
shërbimi
plugina
koment
cpu_l3_cache
none
Nevojitet Intel .
Modeli i të dhënave të klasit (default): Nova cluster data model collector. Metoda e aplikuar është migrimi.
Punimi me këtë qëllim përmes Dashboard nuk është realizuar plotësisht në Queens.
Optimizimi Termik — optimizimi i temperaturës. Tempigat në dalje (ajri i shkarkimit) është një nga sistemet e rëndësishme të telemetrisë termike për matjen e gjendjes së ngarkesës termike / punuese të serverit. Përdoret një strategji për këtë qëllim — Strategjia e bazuar në temperaturën në dalje, e cila merr vendime për transferimin e ngarkesave të punës në nyje me një temperaturë më të favorshme (temperatura më e ulët në dalje), kur temperatura në dalje e hosteve origjinale arrin një prag të rregullueshëm.
Për të funksionuar strategjinë, është e nevojshme një server me Intel Power Node Manager të instaluar dhe të konfiguruar. , si dhe mbledhja e metricave të mëposhtme:
metrika
shërbimi
plugina
koment
hardware.ipmi.node.outlet_temperature
IPMI
Parametrat e strategjisë:
parametri
tipin
si parazgjedhje
përshkrim
threshold
Numri
35.0
Pragu i temperaturës për migrim.
periudha
Numri
30
Intervali i kohës në sekonda për të marrë agregatën statistikore nga burimi i të dhënave të matjeve.
Metoda e përdorur — migrimi.
Optimizimi i Fluksit të Ajrit — optimizimi i ventilimit. Strategjia vetjake — Uniform Airflow using live migration. Strategjia nis migrimin e makinës virtuale sa herë që rrjedha e ajrit nga ventilatori i serverit kalon pragun e caktuar.
Për të funksionuar strategjinë nevojiten:
- Hardueri: nyje llogaritëse <me mbështetje NodeManager 3.0;
- Të paktën dy nyje llogaritëse;
- Komponenti ceilometer-agent-compute dhe Ceilometer API të instaluar dhe të konfiguruar në çdo nyjë llogaritëse, i cili mund të raportojë me sukses për matjet si rrjedha e ajrit, fuqia e sistemit, temperatura në hyrje:
metrika
shërbimi
plugina
koment
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Për të funksionuar strategjinë, është e nevojshme një server me Intel Power Node Manager 3.0 ose version më të ri të instaluar dhe të konfiguruar.
Kufizimet: Koncepti nuk është dizajnuar për prodhim.
Sugjerohet që ky algoritëm të përdoret me audita të vazhdueshme, pasi në një iteracion planifikohet migrimi i vetëm një makine virtuale.
Migrimet e drejtpërdrejta janë të mundshme.
Parametrat e strategjisë:
parametri
tipin
si parazgjedhje
përshkrim
threshold_airflow
Numri
400.0
Pragu i rrjedhës së ajrit për migrim Njësi është 0.1CFM.
threshold_inlet_t
Numri
28.0
Pragu i temperaturës në hyrje për vendimin e migrimit.
threshold_power
Numri
350.0
Pragu i fuqisë së sistemit për vendimin e migrimit.
periudha
Numri
30
Intervali i kohës në sekonda për të marrë agregatën statistikore nga burimi i të dhënave të matjeve.
Metoda e përdorur — migrimi.
Mantenimiento del hardware — shërbimi i pajisjeve. Strategjia, e cila i përket këtij qëllimi, është migrimi i zonës. Strategjia është një mjet për migrimin efektiv dhe minimal të virtual machines dhe disqeve në rast nevoje për shërbim të pajisjeve. Strategjia ndihmon në përgatitjen e një plani veprimi sipas peshave: një grup veprimesh që ka një peshë më të madhe, do të planifikohet 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
tipin
si parazgjedhje
përshkrim
compute_nodes
array
Asnjë
Njësitë llogaritëse për migrimin.
storage_pools
array
Asnjë
Njësitë e ruajtjes për migrimin.
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ësitë llogaritëse.
parallel_per_pool
integer
2
Numri i veprimeve që kryhen paralelisht për çdo grup ruajtjeje.
priority
objekt
Asnjë
Lista e prioriteteve për virtual machines dhe disqe.
with_attached_volume
boolean
False
False — virtual machines do të transferohen pas transferimit të të gjitha disqeve. True — virtual machines do të transferohen pas migrimit të të gjitha disqeve të lidhura.
Elementet e arrays të njësive llogaritëse:
parametri
tipin
si parazgjedhje
përshkrim
src_node
string
Asnjë
Njësia llogaritëse nga e cila transferohen virtual machines (e domosdoshme).
dst_node
string
Asnjë
Llogaritë njësi në të cilin migrat virtual machines.
Elementet e arrays të njësive të ruajtjes:
parametri
tipin
si parazgjedhje
përshkrim
src_pool
string
Asnjë
Grupi i ruajtjes nga i cili transferohen disqet (e domosdoshme).
dst_pool
string
Asnjë
Grupi i ruajtjes në të cilin transferohen disqet.
src_type
string
Asnjë
Lloji origjinal i disqeve (e domosdoshme).
dst_type
string
Asnjë
Lloji përfundimtar i disqeve (e domosdoshme).
Elementet e prioriteteve të objekteve:
parametri
tipin
si parazgjedhje
përshkrim
projekt
array
Asnjë
Emrat e projekteve.
compute_node
array
Asnjë
Emrat e njësi llogaritëse.
storage_pool
array
Asnjë
Emrat e grupeve të ruajtjes.
compute
enum
Asnjë
Parametrat e virtual machines [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
storage
enum
Asnjë
Parametrat e disqeve [“size”, “created_at”].
Metodat e përdorura — migrimi i virtual machines, migrimi i disqeve.
Pa Klasifikim — 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 gjithmonë kur strategjia ende nuk është e lidhur me një qëllim ekzistues. Ky qëllim gjithashtu mund të përdoret si një shkallë kalimtare. Strategjia e lidhur me këtë qëllim është Actuator.
Krijimi i një qëllimi të ri
Motor i vendimeve Watcher ka një ndërfaqe plugu të "qëllimit të jashtëm", e cila ofron mundësinë për të integruar një qëllim 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ë plugu të ri
Për të krijuar një qëllim të ri, ju duhet: të zgjatni klasën e qëllimit, të 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, ju duhet të implementoni metodën e klasës get_display_name () për të kthyer emrin e shfaqjes të përkthyer të qëllimit që dëshironi të krijoni (mos përdorni një variabël për të kthyer varg në përkthyer, në mënyrë që të mund të mbledhë automatikisht nga mjeti i përkthimit.).
Implementoni metodën e klasës get_translatable_display_name (), për të kthyer çelësin e përkthimit (në fakt emri i shfaqjes në anglisht) të qëllimit 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 qëllimin tuaj. Metoda get_efficacy_specification () kthen një instancë Unclassified (), e cila ofrohet nga Watcher. Kjo specifikim efikasiteti është e dobishme gjatë procesit të zhvillimit të qëllimit tuaj, pasi i korrespondon një specifikimi të zbrazët.
→
Arkitektura e Watcher (më shumë ).
Komponentët
API i Watcher — komponent, i cili implementon API REST të ofruar nga Watcher. Mekanizmat e ndërlidhjes: CLI, plugu Horizon, Python SDK.
DB i Watcher — baza e të dhënave të Watcher.
Applier i Watcher — komponent, i cili implementon ekzekutimin e planit të veprimit të krijuar nga komponenti i Motorit të Vendimeve të Watcher.
Motor i vendimeve Watcher — komponent, që është përgjegjës për llogaritjen e një grupi të mundshëm veprimesh optimizuese për të realizuar qëllimin e auditimit. Nëse strategjia nuk është caktuar, komponenti zgjidh më vete më të përshtatshmin.
Botuesi i Metrikave të Watcher — komponent, i cili mbledh dhe llogarit disa metrika ose ngjarje dhe i publikon ato në pikën përfundimtare të CEP. Funksionaliteti i komponentit mund të ofrohet gjithashtu nga botuesi Ceilometer.
Motori i Përpunimit të Ngjarjeve komplekse (CEP) — motori i përpunimit kompleks të ngjarjeve. Për arsye performancës, mund të ketë disa instanca të Motorit CEP që punojnë në të njëjtën kohë, secila prej të cilave përpunon një lloj të caktuar metrikash / ngjarjesh. Në sistemin Watcher, CEP n запуска два вида действий: — запишите соответствующие события / метрики в базу данных временных рядов; — отправьте соответствующие события в компонент Watcher Decision Engine, когда это событие может повлиять на результат текущей стратегии оптимизации, поскольку кластер Openstack не является статической системой.
Ndërveprimi i komponentëve bëhet përmes protokollit AMQP.
→
Skema e ndëtërrimit me Watcher
Rezultatet e testimit të Watcher
- Në faqen Optimization — Planet e veprimit shfaqet gabimi 500 (si në Queens të pastër ashtu edhe në skenarin me modulet Tionix), i cili shfaqet vetëm pasi auditi të nisë dhe plani i veprimit të gjenerohet; faqja bosh hapet normalisht.
- Në skedën Detajet e veprimit, gabime, nuk mund të merret objektivi dhe strategjia e auditit (si në Queens të pastër ashtu edhe në skenarin me modulet Tionix).
- Auditët me qëllim Dummy (testues) krijohen dhe nisin normalisht, planet e veprimit gjenerohen.
- Auditët me qëllim 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.
- Auditët me qëllim Workload Balancing (strategjia Storage Capacity balance) krijohen me sukses, megjithatë plani i veprimit nuk gjenerohet. Optimimi i grupeve të ruajtjes nuk kërkohet.
- Auditët me qëllim Workload Balancing (strategjia Workload Balance Migration Strategy) krijohen me sukses, megjithatë plani i veprimit nuk gjenerohet.
- Auditët me qëllim Workload Balancing (strategjia Workload Stabilization Strategy) përfundojnë me gabim.
- Auditët me qëllim Noisy Neighbor krijohen me sukses, megjithatë plani i veprimit nuk gjenerohet.
- Auditët me qëllim Hardware maintenance krijohen me sukses, plani i veprimit nuk gjenerohet në tërësi (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ë nyjën llogaritur dhe atë kontrolluese nuk korrigjojnë gabimet.
- Auditët me qëllim Server Consolidation (strategjia Basic) gjithashtu përfundojnë me gabim.
- Auditët me qëllim Server Consolidation (strategjia VM workload consolidation) përfundojnë me gabim. Në loge shfaqet gabimi në marrjen e të dhënave burimore. Diskutimi mbi gabimin, në veçanti, .
Tentuan të specifikoni në skedarin e konfigurimit Watcher (nuk ndihmoi - si rezultat, gabime në të gjitha faqet e Optimimit, rikthimi në përmbajtjen origjinale të skedarit të konfigurimit nuk e rregullon situatën):[watcher_strategies.basic]
datasource = ceilometer, gnocchi - Auditet me qëllim Kursimin e Energjisë përfundojnë me gabim. Nga logët, problemi duket se është mungesa e Ironic, nuk do të funksionojë pa shërbimin baremetal.
- Auditet me qëllim Optimimin Termik përfundojnë me gabim. Traceback është i njëjtë me atë për Konsolidimin e Serverëve (strategjia e konsolidimit të ngarkesave VM) (gabim të dhënash të burimeve)
- Auditet me qëllim Optimimin e Ajrit përfundojnë me gabim.
Mund të hasen gjithashtu gabime të tjera përfundimtare të auditeve. Traceback në logët decision-engine.log (nuk është e përcaktuar gjendja e klasterit).
→ Diskutim mbi gabimin
Përfundim
Rezultati i hetimeve tona dy mujor është një përfundim i qartë se për të arritur një sistem të plotë dhe funksional të balancimit të ngarkesës, do të na duhet të punojmë shumë më tepër në këtë pjesë për të përmirësuar mjetet për platformën Openstack.
Watcher ka treguar se është një produkt serioz dhe në zhvillim të shpejtë me potencial të madh, për përdorimin e plotë të të cilit do të nevojitet punë e madhe dhe serioze.
Por për këtë - në artikujt e ardhshëm të ciklit.
Burimi: habr.com
