Load Balancing yn Openstack

Yn grutte wolksystemen is it probleem fan automatyske balânsjen of nivellering fan 'e lading op komputerboarnen foaral akuut. Tionix (in ûntwikkelder en operator fan wolktsjinsten, diel fan 'e Rostelecom-groep fan bedriuwen) hat ek foar dit probleem soarge.

En, om't ús haadûntwikkelingsplatfoarm Openstack is, en wy, lykas alle minsken, lui binne, waard besletten om in soarte fan klearmakke module te selektearjen dy't al yn it platfoarm is opnommen. Us kar foel op Watcher, dy't wy besletten om te brûken foar ús behoeften.
Load Balancing yn Openstack
Litte wy earst nei de termen en definysjes sjen.

Betingsten en definysjes

Goal is in minsklik lêsber, waarnimmber en mjitber einresultaat dat berikt wurde moat. D'r binne ien of mear strategyen om elk doel te berikken. In strategy is de ymplemintaasje fan in algoritme dat by steat is om in oplossing te finen foar in bepaald doel.

Aksje is in elemintêre taak dy't de hjoeddeistige tastân fan 'e doelbehearde boarne fan' e OpenStack-kluster feroaret, lykas: migrearje fan in firtuele masine (migraasje), feroarjen fan 'e machtstatus fan in knooppunt (change_node_power_state), feroarjen fan' e steat fan 'e nova-tsjinst (change_nova_service_state ), smaak feroarje (grutte feroarje), NOP-berjochten registrearje (nop), gebrek oan aksje foar in bepaalde tiid - pauze (sliepe), skiifferfier (volume_migrate).

Aksje plan - in spesifike stream fan aksjes útfierd yn in bepaalde folchoarder om in spesifyk doel te berikken. It Aksjeplan befettet ek mjitten globale prestaasjes mei in set prestaasje-yndikatoaren. In aksjeplan wurdt generearre troch Watcher by in suksesfolle kontrôle, as gefolch wêrfan de brûkte strategy in oplossing fynt om it doel te berikken. In aksjeplan bestiet út in list mei opfolgjende aksjes.

Audit is in fersyk om it kluster te optimalisearjen. Optimalisaasje wurdt útfierd om ien doel te berikken yn in opjûne kluster. Foar elke suksesfolle kontrôle genereart Watcher in aksjeplan.

Audit Scope is in set fan boarnen dêr't de kontrôle wurdt útfierd (beskikberens sône (s), node aggregators, yndividuele compute knopen of opslach knopen, ensfh). De kontrôle omfang wurdt definiearre yn elke sjabloan. As in kontrôleomfang net oantsjutte is, wurdt it hiele kluster kontrolearre.

Audit sjabloan - in bewarre set ynstellingen foar it starten fan in kontrôle. Sjabloanen binne nedich om kontrôles meardere kearen út te fieren mei deselde ynstellings. It sjabloan moat needsaaklik it doel fan 'e kontrôle befetsje; as strategyen net oantsjutte binne, dan wurde de meast geskikte besteande strategyen selektearre.

Kluster is in samling fysike masines dy't berekkenjen, opslach en netwurkboarnen leverje en wurde beheard troch deselde OpenStack-behearknooppunt.

Cluster Data Model (CDM) is in logyske foarstelling fan 'e hjoeddeistige steat en topology fan' e middels dy't troch it kluster beheard wurde.

Effisjinsje Indicator - in yndikator dy't oanjout hoe't de oplossing makke mei dizze strategy wurdt útfierd. Prestaasje-yndikatoaren binne spesifyk foar in bepaald doel en wurde typysk brûkt om de globale effektiviteit fan it resultearjende aksjeplan te berekkenjen.

Wirksamkeit Spesifikaasje is in set fan spesifike skaaimerken ferbûn mei elk Doel dat definiearret de ferskate prestaasje yndikatoaren dy't in strategy te berikken de oerienkommende Doel moat berikke yn syn oplossing. Yndie, elke oplossing foarsteld troch de strategy sil wurde kontrolearre tsjin de spesifikaasje foardat it berekkenjen fan syn globale effektiviteit.

Skoare Engine is in útfierber bestân dat hat goed definiearre yngongen, goed definiearre útgongen, en fiert in suver wiskundige taak. Op dizze manier is de berekkening ûnôfhinklik fan 'e omjouwing wêryn't it wurdt útfierd - it sil oeral itselde resultaat jaan.

Watcher Planner - diel fan 'e Watcher beslútfoarmjende motor. Dizze module nimt in set aksjes oanmakke troch in strategy en makket in workflowplan dat spesifisearret hoe't dizze ferskillende aksjes yn 'e tiid en foar elke aksje pland wurde, wat de betingsten binne.

Watcher-doelen en strategyen

Goal
Strategyen

Dummy goal
Dummy Strategy 

Dummy Strategy mei help fan sample Scoring Engines

Dummy strategy mei resize

Enerzjy besparje
Saving Energy Strategy

Server Consolidation
Basis Offline Server Consolidation

VM Workload Consolidation Strategy

Workload Balancing
Workload Balance Migraasje Strategy

Storage Kapasiteit Balance Strategy

Workload stabilisaasje

Noisy Buorman
Noisy Buorman

Termyske optimisaasje
Outlet temperatuer basearre strategy

Airflow Optimization
Uniforme loftstreammigraasjestrategy

Hardware ûnderhâld
Sône migraasje

unclassified
Aktuator

Dummy goal - reservearre doel dat wurdt brûkt foar testdoelen.

Related strategyen: Dummy Strategy, Dummy Strategy mei help fan sample Scoring Engines en Dummy strategy mei resize. Dummy-strategy is in dummy-strategy brûkt foar yntegraasjetesten fia Tempest. Dizze strategy leveret gjin nuttige optimalisaasje, it ienige doel is om Tempest-tests te brûken.

Dummy-strategy mei gebrûk fan samplescoremotoren - de strategy is fergelykber mei de foarige, it ienige ferskil is it brûken fan in stekproef "scoremotor" dy't berekkeningen útfiert mei metoaden foar masine-learen.

Dummy-strategy mei grutte feroarje - de strategy is gelyk oan de foarige, it ienige ferskil is it brûken fan it feroarjen fan de smaak (migraasje en grutte feroarje).

Net brûkt yn produksje.

Enerzjy besparje - minimalisearje enerzjyferbrûk. De Saving Energy Strategy fan dit doel, tegearre mei de VM Workload Consolidation Strategy (Server Consolidation), is by steat fan dynamyske enerzjybehear (DPM) funksjes dy't enerzjy besparje troch dynamysk konsolidearjen fan workloads, sels yn perioaden fan leech gebrûk fan boarnen: firtuele masines wurde ferpleatst nei minder knopen , en ûnnedige knopen binne útskeakele. Nei konsolidaasje biedt de strategy in beslút oer it yn-/útskeakeljen fan knopen yn oerienstimming mei de oantsjutte parameters: "min_free_hosts_num" - it oantal frije ynskeakele knopen dy't wachtsje op laden, en "free_used_percent" - it persintaazje frije ynskeakele hosts foar de oantal knopen dy't beset wurde troch masines. Foar de strategy om te wurkjen moat der wêze ynskeakele en konfigureare Ironysk om macht fytsen op knopen te behanneljen.

Strategy parameters

parameter
Typ
standert
описание

free_used_percent
Nûmer
10.0
ferhâlding fan it oantal frije komputerknooppunten oan it oantal komputerknooppunten mei firtuele masines

min_free_hosts_num
int
1
minimum oantal frije komputerknooppunten

De wolk moat op syn minst twa knopen hawwe. De brûkte metoade is it feroarjen fan de macht steat fan it knooppunt (change_node_power_state). De strategy fereasket gjin metriken te sammeljen.

Server Consolidation - minimalisearje it oantal komputerknooppunten (konsolidaasje). It hat twa strategyen: Basic Offline Server Consolidation en VM Workload Consolidation Strategy.

De Basic Offline Server Consolidation strategy minimalisearret it totale oantal brûkte servers en minimearret ek it oantal migraasjes.

De basisstrategy fereasket de folgjende metriken:

metrics
betsjinning
plugins
комментарий

compute.node.cpu.percent
ceilometer
gjin
 

cpu_util
ceilometer
gjin
 

Strategyparameters: migration_attempts - oantal kombinaasjes om te sykjen nei potensjele kandidaten foar ôfsluting (standert, 0, gjin beheiningen), perioade - tiidynterval yn sekonden om statyske aggregaasje te krijen fan 'e metryske gegevensboarne (standert, 700).

Brûkte metoaden: migraasje, feroarjen fan de nova-tsjinststatus (change_nova_service_state).

De VM Workload Consolidation Strategy is basearre op in earste-fit heuristyk dy't him rjochtet op mjitten CPU-belêsting en besiket om knooppunten te minimalisearjen dy't tefolle as te min lading hawwe jûn beheiningen foar boarnekapasiteit. Dizze strategy leveret in oplossing dy't resulteart yn effisjinter gebrûk fan klusterboarnen mei de folgjende fjouwer stappen:

  1. Unloading faze - ferwurkjen fan tefolle brûkte boarnen;
  2. Konsolidaasjefaze - ferwurkjen fan net brûkte boarnen;
  3. Optimalisaasje fan 'e oplossing - it ferminderjen fan it oantal migraasjes;
  4. Net brûkte komputerknooppunten útskeakelje.

De strategy fereasket de folgjende metriken:

metrics
betsjinning
plugins
комментарий

oantinken
ceilometer
gjin
 

disk.root.grutte
ceilometer
gjin
 

De folgjende metriken binne opsjoneel, mar sille de strategyske krektens ferbetterje as beskikber:

metrics
betsjinning
plugins
комментарий

memory.resident
ceilometer
gjin
 

cpu_util
ceilometer
gjin
 

Strategyparameters: perioade - tiidynterval yn sekonden om statyske aggregaasje te krijen fan 'e metrike gegevensboarne (standert, 3600).

Brûkt deselde metoaden as de foarige strategy. Mear details hjir.

Workload Balancing - balansearje de wurkdruk tusken komputerknooppunten. It doel hat trije strategyen: Workload Balance Migration Strategy, Workload stabilisaasje, Storage Capacity Balance Strategy.

Workload Balance Migration Strategy rint migraasjes foar firtuele masines basearre op de wurkdruk fan 'e host firtuele masine. In migraasjebeslút wurdt makke wannear't de % CPU- of RAM-gebrûk fan in knooppunt de opjûne drompel giet. Yn dit gefal moat de ferpleatse firtuele masine it knooppunt tichter by de gemiddelde wurkdruk fan alle knooppunten bringe.

easken

  • Gebrûk fan fysike processors;
  • Op syn minst twa fysike komputerknooppunten;
  • Ynstallearre en konfigureare de Ceilometer-komponint - ceilometer-agent-compute, rint op elke komputerknooppunt, en de Ceilometer API, lykas ek de folgjende metriken sammelje:

metrics
betsjinning
plugins
комментарий

cpu_util
ceilometer
gjin
 

memory.resident
ceilometer
gjin
 

Strategy parameters:

parameter
Typ
standert
описание

metriken
string
'cpu_util'
De ûnderlizzende metriken binne: 'cpu_util', 'memory.resident'.

drompel
Nûmer
25.0
Workload drompel foar migraasje.

perioade
Nûmer
300
Kumulative tiidperioade Ceilometer.

De brûkte metoade is migraasje.

Stabilisaasje fan wurkdruk is in strategy dy't rjochte is op it stabilisearjen fan de wurkdruk mei live migraasje. De strategy is basearre op in standertdeviaasje-algoritme en bepaalt oft der oerlêst is yn it kluster en reagearret dêrop troch masinemigraasje te triggerjen om it kluster te stabilisearjen.

easken

  • Gebrûk fan fysike processors;
  • Op syn minst twa fysike komputerknooppunten;
  • Ynstallearre en konfigureare de Ceilometer-komponint - ceilometer-agent-compute, rint op elke komputerknooppunt, en de Ceilometer API, lykas ek de folgjende metriken sammelje:

metrics
betsjinning
plugins
комментарий

cpu_util
ceilometer
gjin
 

memory.resident
ceilometer
gjin
 

Storage Capacity Balance Strategy (strategy útfierd te begjinnen mei Queens) - de strategy transfers skiven ôfhinklik fan de lading op de Cinder pools. In oerdrachtbeslút wurdt makke as it gebrûksnivo fan it swimbad in spesifisearre drompel giet. De skiif wurdt ferpleatst moat bringe it swimbad tichter by de gemiddelde lading fan alle Cinder pools.

Easken en beheiningen

  • Minimum twa Cinder pools;
  • Mooglikheid fan skiif migraasje.
  • Cluster data model - Cinder kluster data model samler.

Strategy parameters:

parameter
Typ
standert
описание

volume_threshold
Nûmer
80.0
Drompelwearde fan skiven foar balânsjen fan folumes.

De brûkte metoade is skiifmigraasje (volume_migrate).

Noisy Neighbor - Identifisearje en migrearje in "lawaaiige buorman" - in firtuele masine mei lege prioriteit dy't de prestaasjes fan in firtuele masine mei hege prioriteit negatyf beynfloedet yn termen fan IPC troch te folle gebrûk fan Last Level Cache. Eigen strategy: Noisy Neighbor (de strategyparameter dy't brûkt wurdt is cache_threshold (standertwearde is 35), as prestaasjes sakket nei de opjûne wearde, wurdt migraasje begûn. Foar de strategy om te wurkjen, ynskeakele LLC (Last Level Cache) metriken, lêste Intel tsjinner mei CMT stipe, lykas it sammeljen fan de folgjende metriken:

metrics
betsjinning
plugins
комментарий

cpu_l3_cache
ceilometer
gjin
Intel fereaske CMT.

Cluster data model (standert): Nova cluster data model samler. De brûkte metoade is migraasje.

Wurkje mei dit doel fia it Dashboard is net folslein ymplementearre yn Queens.

Termyske optimisaasje - optimisearje it temperatuerregime. Outlet (exhaust lucht) temperatuer is ien fan de wichtige termyske telemetry systemen te mjitten de termyske / wurklast status fan in tsjinner. It doel hat ien strategy, de Outlet-temperatuerbasearre strategy, dy't beslút om wurklasten te migrearjen nei thermysk geunstige hosts (leechste útlaattemperatuer) as de útlaattemperatuer fan 'e boarnehosts in konfigurearbere drompel berikt.

Foar de strategy om te wurkjen, hawwe jo in server nedich mei Intel Power Node Manager ynstalleare en konfigureare 3.0 of letter, lykas it sammeljen fan de folgjende metriken:

metrics
betsjinning
plugins
комментарий

hardware.ipmi.node.outlet_temperature
ceilometer
IPMI
 

Strategy parameters:

parameter
Typ
standert
описание

drompel
Nûmer
35.0
Temperatuer drompel foar migraasje.

perioade
Nûmer
30
It tiidynterval, yn sekonden, om de statistyske aggregaasje te krijen fan 'e metrike gegevensboarne.

De brûkte metoade is migraasje.

Airflow Optimization - optimalisearje de fentilaasjemodus. Eigen strategy - Uniform Airflow mei help fan live migraasje. De strategy triggert migraasje fan firtuele masines elke kear as de loftstream fan 'e serverfan in opjûne drompel giet.

Foar de strategy om te wurkjen hawwe jo nedich:

  • Hardware: berekkenje nodes < stipet NodeManager 3.0;
  • Op syn minst twa komputerknooppunten;
  • De ceilometer-agent-compute en Ceilometer API-komponint ynstalleare en konfigureare op elke komputerknooppunt, dy't metriken mei súkses kinne rapportearje lykas luchtstream, systeemkrêft, ynlaattemperatuer:

metrics
betsjinning
plugins
комментарий

hardware.ipmi.node.airflow
ceilometer
IPMI
 

hardware.ipmi.node.temperatuer
ceilometer
IPMI
 

hardware.ipmi.node.power
ceilometer
IPMI
 

Foar de strategy om te wurkjen, hawwe jo in tsjinner nedich mei Intel Power Node Manager 3.0 of letter ynstalleare en konfigureare.

Beheinings: It konsept is net bedoeld foar produksje.

It wurdt foarsteld om dit algoritme te brûken mei trochgeande audits, om't mar ien firtuele masine is pland om per iteraasje te migrearjen.

Live migraasjes binne mooglik.

Strategy parameters:

parameter
Typ
standert
описание

threshold_airflow
Nûmer
400.0
Airflow drompel foar migraasje Unit is 0.1CFM

threshold_inlet_t
Nûmer
28.0
Inlet temperatuer drompel foar migraasje beslút

threshold_power
Nûmer
350.0
Systeem macht drompel foar migraasje beslút

perioade
Nûmer
30
It tiidynterval, yn sekonden, om de statistyske aggregaasje te krijen fan 'e metrike gegevensboarne.

De brûkte metoade is migraasje.

Hardwareûnderhâld - hardware ûnderhâld. De strategy yn ferbân mei dit doel is Zone migraasje. De strategy is in ark foar effektive automatyske en minimale migraasje fan firtuele masines en skiven yn gefal fan needsaak foar hardwareûnderhâld. Strategy bout in plan fan aksje yn oerienstimming mei gewichten: in set fan aksjes dy't mear gewicht hat sil wurde pland foar oaren. Der binne twa konfiguraasje opsjes: action_weights en parallelization.

Beheinings: aksjegewichten en parallelisaasje moatte wurde konfigureare.

Strategy parameters:

parameter
Typ
standert
описание

compute_nodes
Array
Gjin
Berekkenje knopen foar migraasje.

storage_pools
Array
Gjin
Opslachknooppunten foar migraasje.

parallel_totaal
integer
6
It totale oantal aktiviteiten dy't parallel moatte wurde útfierd.

parallel_per_node
integer
2
It oantal aksjes dy't parallel wurde útfierd foar elke komputerknooppunt.

parallel_per_pool
integer
2
It oantal aksjes útfierd yn parallel foar eltse opslach pool.

prioriteit
foarwerp
Gjin
Prioriteitslist foar firtuele masines en skiven.

with_attached_volume
booleaanske
falsk
False - firtuele masines sille wurde migrearre nei't alle skiven binne migrearre. Wier - firtuele masines sille wurde migrearre nei't alle ferbûne skiven binne migrearre.

Eleminten fan 'e array fan komputerknooppunten:

parameter
Typ
standert
описание

src_node
string
Gjin
It komputerknooppunt wêrút de firtuele masines wurde migrearre (fereaske).

dst_node
string
Gjin
Berekkenje it knooppunt dêr't de firtuele masines migrearje.

Opslach node array eleminten:

parameter
Typ
standert
описание

src_pool
string
Gjin
De opslachpool wêrút de skiven wurde migrearre (ferplicht).

dst_pool
string
Gjin
De opslachpool wêrnei skiven wurde migrearre.

src_type
string
Gjin
Orizjinele skiiftype (fereaske).

dst_type
string
Gjin
It resultearjende skiiftype (ferplicht).

Objektprioriteit eleminten:

parameter
Typ
standert
описание

projekt
Array
Gjin
Projektnammen.

compute_node
Array
Gjin
Berekkenje node nammen.

storage_pool
Array
Gjin
Opslach pool nammen.

berekkenje
enum
Gjin
Parameters fan firtuele masines ["vcpu_num", "mem_size", "disk_size", "created_at"].

opslach
enum
Gjin
Skiifparameters ["grutte", "created_at"].

De brûkte metoaden binne firtuele masine-migraasje, skiifmigraasje.

unclassified - in helpmiddel dat wurdt brûkt om it proses fan strategyûntwikkeling te fasilitearjen. Befettet gjin spesifikaasjes en kin brûkt wurde as de strategy noch net is assosjearre mei in besteande doel. Dit doel kin ek brûkt wurde as oergongspunt. In relatearre strategy foar dit doel is Actuator.   

It meitsjen fan in nij doel

Watcher Decision Engine hat in "eksterne doel" plugin ynterface dat makket it mooglik om te yntegrearjen in ekstern doel dat kin wurde berikt mei help fan in strategy.

Foardat jo in nij doel meitsje, moatte jo derfoar soargje dat gjin besteande doelen foldogge oan jo behoeften.

It meitsjen fan in nije plugin

Om in nij doel te meitsjen, moatte jo: de doelklasse útwreidzje, in klassemetoade ymplementearje get_name() om de unike ID werom te jaan fan it nije doel dat jo oanmeitsje wolle. Dizze unike identifier moat oerienkomme mei de yngongspuntnamme dy't jo letter ferklearje.

Dêrnei moatte jo de klassemetoade ymplementearje get_display_name() om de oersette werjeftenamme werom te jaan fan it doel dat jo oanmeitsje wolle (brûk gjin fariabele om de oersette tekenrige werom te jaan, sadat it automatysk sammele wurde kin troch it oersetark.).

Implementearje in klasse metoade get_translatable_display_name()om de oersettingskaai (eigentlik de Ingelske werjeftenamme) fan jo nije doel werom te jaan. De weromkommende wearde moat oerienkomme mei de tekenrige oerset yn get_display_name ().

Implementearje syn metoade get_efficacy_specification()om de effisjinsjespesifikaasje foar jo doel werom te jaan. De metoade get_efficacy_specification() jout de Unclassified()-eksimplaar werom fan Watcher. Dizze prestaasjespesifikaasje is nuttich yn it proses fan it ûntwikkeljen fan jo doel, om't it oerienkomt mei de lege spesifikaasje.

Lês hjir mear

Watcher-arsjitektuer (mear details) hjir).

Load Balancing yn Openstack

Komponinten

Load Balancing yn Openstack

Watcher API - in komponint dat de REST API ymplementearret levere troch Watcher. Ynteraksjemeganismen: CLI, Horizon plugin, Python SDK.

Watcher DB - Watcher databank.

Watcher Applier - in komponint dat de útfiering ymplemintearret fan in aksjeplan makke troch de Watcher Decision Engine-komponint.

Watcher Decision Engine - De komponint ferantwurdlik foar it berekkenjen fan in set fan potinsjele optimalisaasjeaksjes om it auditdoel te berikken. As in strategy is net oantsjutte, selektearret de komponint selsstannich de meast geskikte.

Watcher Metrics Publisher - In komponint dat guon metriken of eveneminten sammelet en berekkent en se publisearret nei it CEP-einpunt. De funksjonaliteit fan 'e komponint kin ek wurde levere troch Ceilometer-útjouwer.

Complex Event Processing (CEP) Engine - motor foar komplekse evenemint ferwurking. Foar prestaasjesredenen kinne d'r meardere CEP Engine-eksimplaren tagelyk rinne, elk ferwurket in spesifyk type metrik / evenemint. Yn it Watcher-systeem triggert CEP twa soarten aksjes: - registrearje relevante eveneminten / metriken yn 'e tiidreeksdatabase; - Stjoer passende eveneminten nei de Watcher Decision Engine as dit barren kin beynfloedzje it resultaat fan 'e hjoeddeistige optimalisaasjestrategy, om't it Openstack-kluster gjin statysk systeem is.

De komponinten ynteraksje mei it AMQP-protokol.

Watcher konfigurearje

Skema fan ynteraksje mei Watcher

Load Balancing yn Openstack

Watcher testresultaten

  1. Op 'e Optimalisaasje - Aksjeplannen 500 side (sawol op suvere Queens as op in stand mei Tionix-modules), ferskynt it allinich nei't de kontrôle is lansearre en in aksjeplan wurdt generearre; de ​​lege iepenet normaal.
  2. Der binne flaters op de Aksje details ljepper, it is net mooglik om te krijen de kontrôle doel en strategy (sawol op suver Queens en op in stand mei Tionix modules).
  3. Audits mei it doel fan Dummy (test) wurde makke en normaal lansearre, aksjeplannen wurde oanmakke.
  4. Audits foar it net-klassifisearre doel wurde net makke om't it doel net funksjoneel is en bedoeld is foar tuskenkonfiguraasje by it meitsjen fan nije strategyen.
  5. Audits foar it doel fan Workload Balancing (Storage Capacity balance strategy) wurde makke mei súkses, mar in aksjeplan wurdt net oanmakke. Gjin opslach pool optimalisaasje nedich.
  6. Audits foar it doel Workload Balancing (Workload Balance Migration Strategy) wurde mei súkses makke, mar in aksjeplan wurdt net oanmakke.
  7. Audits foar Workload Balancing (Workload Stabilization Strategy) mislearje.
  8. Audits foar it Noisy Neighbour-doel wurde mei súkses makke, mar in aksjeplan wurdt net generearre.
  9. Audits foar it doel fan Hardware ûnderhâld wurde makke mei súkses, it aksjeplan wurdt net generearre folslein (prestaasje yndikatoaren wurde oanmakke, mar de list fan aksjes sels wurdt net oanmakke).
  10. Bewurkings yn de nova.conf configs (yn de standert seksje compute_monitors = cpu.virt_driver) op de berekkenjen en kontrôle knopen net korrigearje de flaters.
  11. Audits dy't rjochte binne op Server Consolidation (Basisstrategy) mislearje ek.
  12. Audits foar it doel fan Server Consolidation (VM workload konsolidaasje strategy) mislearje mei in flater. Yn de logs is d'r in flater by it krijen fan boarnegegevens. Diskusje oer de flater, benammen hjir.
    Wy besochten Watcher op te jaan yn 'e konfiguraasjetriem (it holp net - as gefolch fan in flater op alle optimisaasjesiden, werom nei de orizjinele ynhâld fan it konfiguraasjetriem korrigeart de situaasje net):

    [watcher_strategies.basic] datasource = ceilometer, gnocchi
  13. Audits foar Saving Energy fail. Beoardielje nei de logs, it probleem is noch altyd de ôfwêzigens fan Ironic; it sil net wurkje sûnder baremetal tsjinst.
  14. Audits foar termyske optimalisaasje mislearje. De traceback is itselde as foar Server Consolidation (VM workload konsolidaasjestrategy) (boarne gegevens flater)
  15. Audits foar it doel fan Airflow Optimization mislearje mei in flater.

De folgjende flaters foar foltôging fan kontrôle wurde ek tsjinkaam. Traceback yn decision-engine.log logs (kluster steat is net definiearre).

→ Diskusje oer de flater hjir

konklúzje

It resultaat fan ús twa-moanne ûndersyk wie de ûndûbelsinnige konklúzje dat om in folweardich, wurkjend load balancing systeem te krijen, wy moatte nau gearwurkje oan it ferfine fan de ark foar it Openstack-platfoarm yn dit diel.

Watcher hat bewiisd in serieus en rap ûntwikkeljend produkt te wêzen mei enoarm potensjeel, wêrfan it folsleine gebrûk in protte serieus wurk sil fereaskje.

Mar mear oer dit yn 'e folgjende artikels fan' e searje.

Boarne: www.habr.com

Add a comment