Koormuse jaotamine OpenStackis

Suuremates pilvesüsteemides on automaatse koormuse tasakaalustamise või jaotamise vajadus eriti terav. Meie, Tioniks, mis on pilveteenuste arendaja ja operaator, kuulume Rostelecomi kontserni, oleme sellele küsimusele tähelepanu pööranud.

Kuna meie põhiplatvormiks on OpenStack ja me kõik oleme loomult laisad, otsustasime kasutada mõnda valmis moodulit, mis juba kuulub platvormi koosseisu. Meie valik langes Watcherile, mida otsustasime oma vajaduste jaoks kasutada.

Alustame terminite ja definitsioonide selgitamisest.

Terminid ja definitsioonid

Eesmärk on inimeste poolt arusaadav, jälgitav ja mõõdetav lõpptulemus, mida tuleb saavutada. Iga eesmärgi saavutamiseks on olemas üks või enam strateegiat. Strateegia on algoritmi rakendamine, mis suudab leida lahenduse antud eesmärgile.

Tegevus (Action) — see, et on elementaarne ülesanne, mis muudab OpenStacki klastris sihtkontrollitava ressursi praegust olekut, nagu näiteks: virtuaalmasina migratsioon (migration), sõlme toiteoleku muutmine (change_node_power_state), nova teenuse oleku muutmine (change_nova_service_state), flavori muutmine (resize), NOP sõnumi registreerimine (nop), tegevuste puudumine teatud aja jooksul — paus (sleep), ketta üleviimine (volume_migrate).

Tegevuskava (Action Plan) — spetsiifiline tegevuste voog, mis viiakse läbi kindlas järjekorras konkreetse Eesmärgi saavutamiseks. Tegevuskava sisaldab ka hinnatud globaalset tõhusust koos hulkade efektiivsusnäitajatega. Tegevuskava genereeritakse Watcheri poolt pärast edukat auditi, mille käigus leiab kasutatud strateegia lahenduse eesmärgi saavutamiseks. Tegevuskava koosneb järjestikuste tegevuste loendist.

Audit (Audit) — see on soovitus klastrite optimeerimiseks. Optimeerimine viiakse läbi, et saavutada üks Eesmärk selles klastri. Iga eduka auditi korral genereerib Watcher Tegevuskava.

Auditi piirkond (Audit Scope) — see on ressursside kogum, mille raames toimub auditeerimine (kättesaadavusala(d), sõlmpunktide agregaat, üksikud arvutusüksused või salvestussõlmed jne). Auditiala on määratletud igas šabloonis. Kui auditiala pole märgitud, auditeeritakse kogu klastri ulatust.

Auditimal (Audit Template) — salvestatud seadistuste kogum auditi läbiviimiseks. Šabloonid on vajalikud, et saaks korduvalt audite teha sama seadistusiga. Šabloon peab kindlasti sisaldama auditi eesmärki; kui strateegiaid ei määratleta, valitakse olemasolevatest strateegiatest sobivaimad.

Klaster (Cluster) — see on füüsiliste masinate kogum, mis pakub arvutusressursse, salvestusressursse ja võrgurressursse ning mida haldab sama OpenStack'i juhtimisseade.

Klastri andmemudel (Cluster Data Model, CDM) — see on loogiline ettekujutus hetke seisundist ja süstematiseeritud haldamise all olevate ressursside topoloogiast.

Tõhususe näitaja (Efficacy Indicator) — näitaja, mis näitab, kuidas lahendus, mis on loodud selle strateegia abil, toimib. Tulemuslikkuse näitajad on spetsiifilised konkreetsele eesmärgile ja neid kasutatakse tavaliselt lõpliku tegevuskava globaalse tõhususe arvutamisel.

Tulemuslikkuse spetsifikatsioon (Efficacy Specification) — see on spetsiifiliste omaduste kogum, mis on seotud iga Eesmärgiga ja mis määratleb erinevad tulemuslikkuse näitajad, mida strateegia, mis tagab vastava eesmärgi saavutamise, peab oma lahenduses tagama. Tegelikult kontrollitakse igat lahendust, mille strateegia pakub, spetsifikatsiooniga kooskõla osas, enne kui arvutatakse selle globaalne tõhusus.

„Arvestav” mootor (Scoring Engine) — see on teostust fail, millel on selgelt määratletud sisendid, selgelt määratletud väljundid ning mis täidab rangelt matemaatilist ülesannet. Seega ei sõltu arvutus keskkonnast, kus see toimub — see annab igal pool sama tulemuse.

Watcher planeerija (Watcher Planner) — osa Watcher'iga seotud otsustusprotsessist. See moodul võtab vastu strateegia genereeritud tegevuste kogumi ja loob töövoo plaani, mis määratleb, kuidas ajas planeerida neid erinevaid tegevusi ning iga tegevuse puhul, millised on eeltingimused.

Watcher'i eesmärgid ja strateegiad

Eesmärk
Strateegiad

Dummy eesmärk
Dummy strateegia 

Dummy strateegia, mis kasutab näidisreitingumootoreid

Dummy strateegia, mis kasutab suurendamist

Energia säästmine
Energia säästmise strateegia

Serverite konsolideerimine
Põhjalik offline serverite konsolideerimine

VM töökoormuse konsolideerimise strateegia

Töökoormuse tasakaalustamine
Töökoormuse tasakaalu migreerimise strateegia

Salvestusmahu tasakaalu strateegia

Töökoormuse stabiliseerimine

Mürarikka naabri probleem
Mürarikka naabri probleem

Termiline optimeerimine
Väljundi temperatuuri põhine strateegia

Õhuvoolu optimeerimine
Ühtne õhuvoolu migreerimise strateegia

Riistvara hooldus
Tsooni migreerimine

Klassifitseerimata
Toimimisseade

Dummy eesmärk — reservi eesmärk, mida kasutatakse testimise jaoks.

Seondunud strateegiad: Dummy Strategy, Dummy Strategy using sample Scoring Engines ja Dummy strategy with resize. Dummy strateegia — fiktiivne strateegia, mida kasutatakse integreerimistestide läbiviimiseks Tempesti kaudu. See strateegia ei paku mingit kasulikku optimeerimist, selle ainus eesmärk on kasutada Tempesti teste.

Dummy strateegia, mis kasutab prooviskoorimisjõude — strateegia on sarnane eelnevale, erinedes vaid prooviskoorimise mootori kasutamisest, mis arvutab tulemusi masinõppe meetodite abil.

Dummy strateegia muutmisega — strateegia on sarnane eelnevale, erinedes vaid flaavori muutmisest (migratsioon ja suurendamine).

Ei kasutata tootmises.

Energia säästmine — energiatarbimise vähendamine. Selle eesmärgi Saving Energy Strategy strateegia koos VM Workload Consolidation Strategy (Server Consolidation) strateegiaga suudab täita dünaamilise energiakasutuse juhtimise (DPM) funktsioone, mis säästab elektrit dünaamilise koormuste konsolideerimise kaudu isegi madalaressursi kasutuse perioodidel: virtuaalmasinad liiguvad väiksema arvu sõlmede juurde ja mittevajalikud sõlmed lülitatakse välja. Pärast konsolideerimist pakub strateegia lahendust sõlmede sisselülitamiseks/väljalülitamiseks vastavalt määratud parameetritele: “min_free_hosts_num” — vaba sisselülitatud sõlmede arv, mis ootavad koormust, ja “free_used_percent” — vaba sisselülitatud sõlmede protsent suhtega sõlmede koguarvuga, mis on masinate poolt hõivatud. Strateegia tööks peab olema Ironic sisse lülitatud ja seadistatud sõlmede sisselülitamiseks/väljalülitamiseks.

strateegia parameetrid

parameeter
tüüp
vaikimisi
kirjeldus

free_used_percent
Number
10.0
vabade arvutussõlmede suhe arvutussõlmede arvuga, kus on virtuaalmasinad

min_free_hosts_num
Int
1
minimaalne vabade arvutussõlmede arv

Pilves peab olema vähemalt kaks sõlme. Kasutatav meetod on sõlme toiteoleku muutmine (change_node_power_state). Kogumisstrateegia ei nõua metrikat.

Serveri konsolideerimine — arvutussõlmede arvu minimeerimine (konsolideerimine). Sel on kaks strateegiat: Basic Offline Server Consolidation ja VM Workload Consolidation Strategy.

Strateegia Basic Offline Server Consolidation minimeerib kasutatavate serverite koguarvu ning vähendab ka migratsioonide arvu.

Põhistrateegia nõuab järgmisi metrikasid:

metrika
teenus
pluginate
kommentaar

compute.node.cpu.percent
ceilometer
ei midagi
 

cpu_util
ceilometer
ei midagi
 

Strateegia parameetrid: migration_attempts — kandidaatide väljalülitamiseks otsitavate kombinatsioonide arv (vaikimisi 0, piiranguid pole), period — ajavahemik sekundites, mil saadakse staatiline agregatsioon metrikate andmeallikast (vaikimisi 700).

Kasutatavad meetodid: migratsioon, nova teenuse oleku muutmine (change_nova_service_state).

VM Workload Consolidation Strategy strateegia põhineb esimese sobiva (first-fit) heuristilise algoritmi peal, mis keskendub mõõdetud CPU koormusele ning püüab minimeerida sõlmi, millel on liiga suur või liiga väike koormus, arvestades ressursside mahutavuse piire. See strateegia pakub lahendust, mis viib klastrite ressursside tõhusama kasutamiseni, kasutades järgmisi nelja etappi:

1. Vabastusfaas — ületarbimisega ressursside töötlemine;
2. Konsolideerimise faas — alakasutatud ressursside töötlemine;
3. Lahenduse optimeerimine — migreerimiste arvu vähendamine;
4. Kasutamata arvutussõlmede väljalülitamine.

Strateegia nõuab järgmisi mõõdikuid:

metrika
teenus
pluginate
kommentaar

memory
ceilometer
ei midagi
 

disk.root.size
ceilometer
ei midagi
 

Järgmised mõõdikud ei ole kohustuslikud, kuid suurendavad strateegia täpsust, kui need on saadaval:

metrika
teenus
pluginate
kommentaar

memory.resident
ceilometer
ei midagi
 

cpu_util
ceilometer
ei midagi
 

Strateegia parameetrid: period — aja vahemik sekundites, et saada staatilisi kogutud andmeid mõõdikate allikast (vaikimisi 3600).

Kasutab samu meetodeid nagu eelmine strateegia. Lisainfot siit.

Töökoormuse tasakaalustamine — töökoormuse tasakaalustamine arvutuslike sõlmede vahel. Eesmärk sisaldab kolme strateegiat: töökoormuse tasakaalu migreerimise strateegia, töökoormuse stabiliseerimine, salvestusmahu tasakaalu strateegia.

Töökoormuse tasakaalu migreerimise strateegia käivitab virtuaalmasinate migreerimised sõlmde töökoormuse alusel. Otsus migreerimise kohta tehakse iga kord, kui sõlme % CPU või RAM kasutus ületab määratud lävendi. Sel juhul peab migreeritav virtuaalmasin tõmbama sõlme kõigi sõlmede keskmisele töökoormusele lähemale.

Nõuded

• Füüsiliste protsessorite kasutamine;
• Kaks füüsilist arvutuslikku sõlme vähemalt;
• Paigaldatud ja konfigureeritud Ceilometer komponent — ceilometer-agent-compute, töötades igas arvutuslikus sõlmes, ja Ceilometer API, samuti järgmiste mõõdikute kogumine:

metrika
teenus
pluginate
kommentaar

cpu_util
ceilometer
ei midagi
 

memory.resident
ceilometer
ei midagi
 

Strateegia parameetrid:

parameeter
tüüp
vaikimisi
kirjeldus

mõõdikutest
String
‘cpu_util’
Mõõdikud, mis põhinevad: ‘cpu_util’, ‘memory.resident’.

lävend
Number
25.0
Töökoormuse lävend migreerimiseks.

periood
Number
300
Ceilometeri koguperiood.

Kasutatud meetod on migreerimine.

Töökoormuse stabiliseerimine — strateegia, mille eesmärk on töökoormuse stabiliseerimine elava rände abil. Strateegia põhineb standardhälbe algoritmil ja määrab, kas klastris on ülekoormus, ning reageerib sellele masinate rände käivitamise kaudu, et klastrit stabiliseerida.

Nõuded

• Füüsiliste protsessorite kasutamine;
• Kaks füüsilist arvutuslikku sõlme vähemalt;
• Paigaldatud ja konfigureeritud Ceilometer komponent — ceilometer-agent-compute, töötades igas arvutuslikus sõlmes, ja Ceilometer API, samuti järgmiste mõõdikute kogumine:

metrika
teenus
pluginate
kommentaar

cpu_util
ceilometer
ei midagi
 

memory.resident
ceilometer
ei midagi
 

Salvestuskapasiteedi tasakaalu strateegia (strateegia on rakendatud alates Queens'ist) — strateegia, mis viib kettad üle sõltuvalt Cinder'i basseinide koormusest. Üleviimise otsus tehakse igal korral, kui basseinide kasutusmäär ületab määratud piirväärtuse. Üleviidud ketas peab viima basseini Cinder'i kõigi basseinide keskmise koormuse lähedale.

Nõuded ja piirangud

• Minimaalselt kaks Cinder'i basseini;
• Ketaste rände võimalus.
• Klastri andmemudel — Cinder'i klastrite andmemudeli kogujad.

Strateegia parameetrid:

parameeter
tüüp
vaikimisi
kirjeldus

volume_threshold
Number
80.0
Kettaste piirväärtus mahtude tasakaalustamiseks.

Kasutatav meetod — ketta ränne (volume_migrate).

Noisy Neighbor — tuvastada ja viia "mürarikka naaber" – madala prioriteediga virtuaalmasin, mis negatiivselt mõjutab kõrge prioriteediga virtuaalmasina jõudlust IPC kontekstis, liialdades viimase taseme vahemälu kasutamisega. Omandipõhine strateegia: Noisy Neighbor (kasutatud strateegia parameeter — cache_threshold (vaikeväärtus — 35), jõudluse langemise korral määratud väärtusele käivitub migreerimine. Strateegia tööks on vajalikud aktiveeritud LLC (Last Level Cache) mõõdikud, viimane Intel server CMT toe jaotusega, , samuti järgmiste mõõdikutega kogumine:cpu_l3_cache

metrika
teenus
pluginate
kommentaar

Nõutav Intel
ceilometer
ei midagi
CMT Klastri andmemudel (vaikeväärtus): Nova cluster data model collector. Kasutatud meetod — migreerimine..

Selle eesmärgiga töötlus Dashboardi kaudu ei ole Queensis täielikult rakendatud.

Selle eesmärgi täitmine Dashboardi kaudu ei ole Queensis täielikult teostatav.

Termiline optimeerimine — optimeerida temperatuurirežiimi. Väljaheite temperatuur (väljuv õhk) on üks olulisemaid soojusmonitorimise süsteeme serveri soojuse / töökoormuse seisundi mõõtmiseks. Selle eesmärgi saavutamiseks on olemas üks strateegia — väljalaske temperatuuri põhine strateegia, mis langetab otsuseid töökoormuse hilisemiseks üleviimiseks sõlmedesse, kus on soodsad temperatuurirežiimid (madalaim väljalaske temperatuur), kui algsete hostide väljalaske temperatuur saavutab seadistatava läve.

Strateegia tööks on vajalik server, millel on installitud ja seadistatud Intel Power Node Manager. 3.0 või uuema versiooni.cpu_l3_cache

metrika
teenus
pluginate
kommentaar

hardware.ipmi.node.outlet_temperature
ceilometer
IPMI
 

Strateegia parameetrid:

parameeter
tüüp
vaikimisi
kirjeldus

lävend
Number
35.0
Temperatuuriline lävi migreerimiseks.

periood
Number
30
Aeg intervalli sekundites statistilise kogumise saamiseks andmeallika metrikast.

Kasutatud meetod on migreerimine.

Õhuvoolu optimeerimine — optimeerida ventilatsioonirežiimi. Strateegia — Ühtlane õhuvool, kasutades elus migratsiooni. Strateegia käivitab virtuaalmasina migratsiooni iga kord, kui serveri ventilaatori õhuvool ületab määratud läve.

Strateegia tööks on vajalik:

• Riistvara: arvutusüksused <NodeManager 3.0 toe all;
• Kaks või enam arvutusüksust;
• Iga arvutusüksuse peal on installitud ja seadistatud komponent ceilometer-agent-compute ning Ceilometer API, mis suudab edastada selliseid mõõdikuid nagu õhuvool, süsteemi energia ja sissetuleku temperatuur:

metrika
teenus
pluginate
kommentaar

hardware.ipmi.node.airflow
ceilometer
IPMI
 

hardware.ipmi.node.temperature
ceilometer
IPMI
 

hardware.ipmi.node.power
ceilometer
IPMI
 

Strateegia rakendamiseks on vajalik server, kuhu on installitud ja seadistatud Intel Power Node Manager versioon 3.0 või uuem.

Piirangud: Konseptsioon ei ole mõeldud tootmis kasutuseks.

Soovitame kasutada seda algoritmi pidevate audititega, kuna ühe iteratsiooni jooksul on plaanis migreerida ainult üks virtuaalne masin.

Elumigatsioonid on võimalikud.

Strateegia parameetrid:

parameeter
tüüp
vaikimisi
kirjeldus

threshold_airflow
Number
400.0
Õhuvoolu lävi migreerimise jaoks on ühik 0.1CFM

threshold_inlet_t
Number
28.0
Sissetuleku temperatuurilävi migratsioonitehtes

threshold_power
Number
350.0
Süsteemi energialävi migratsioonitehtes

periood
Number
30
Aeg intervalli sekundites statistilise kogumise saamiseks andmeallika metrikast.

Kasutatud meetod on migreerimine.

Riistvara hooldus — riistvara hooldus. Stratēģija, kas attiecas uz šo mērķi, ir Zone migration. Šī stratēģija ir rīks efektīvai automātiskai un minimālai virtuālo mašīnu un disku migrācijai, ja ir nepieciešama riistvara apkope. Stratēģija izstrādā rīcības plānu atbilstoši svaram: pasākumu komplekts, kam ir lielāks svars, tiks plānots pirms citiem. Ir divi konfigurācijas parametri: rīcību svari (action_weights) un paralelizācija (parallelization).

Ierobežojumi: nepieciešama rīcību svaru un paralelizācijas iestatīšana.

Strateegia parameetrid:

parameeter
tüüp
vaikimisi
kirjeldus

compute_nodes
array
Puudub
Migrācijai paredzēti aprēķinu mezgli.

storage_pools
array
Puudub
Migrācijai paredzētie krātuves mezgli.

parallel_total
integer
6
Kopējais darbību skaits, kas jāveic paralēli.

parallel_per_node
integer
2
Darbību skaits, kas tiek veikts paralēli katram aprēķinu mezglam.

parallel_per_pool
integer
2
Darbību skaits, kas tiek veikts paralēli katram krātuves pulkam.

prioriteet
object
Puudub
Prioritāšu saraksts virtuālajām mašīnām un diskiem.

with_attached_volume
boolean
False
Vale — virtuaalsed masinad liiguvad pärast kõigi diskide liikumist. Tõsi — virtuaalsed masinad liiguvad pärast kõigi ühendatud diskide migratsiooni.

Arvutusnodestruktuuri elemendid:

parameeter
tüüp
vaikimisi
kirjeldus

src_node
string
Puudub
Arvutusnode, kust virtuaalsed masinad liiguvad (kohustuslik).

dst_node
string
Puudub
Arvutusnode, kuhu virtuaalsed masinad migreruvad.

Salvestusturunduse elementide elemendid:

parameeter
tüüp
vaikimisi
kirjeldus

src_pool
string
Puudub
Salvestusturundus, kust diskid liiguvad (kohustuslik).

dst_pool
string
Puudub
Salvestusturundus, kuhu diskid liiguvad.

src_type
string
Puudub
Algne diski tüüp (kohustuslik).

dst_type
string
Puudub
Lõpptüüpi diski tüüp (kohustuslik).

Objektide prioriteetsuse elemendid:

parameeter
tüüp
vaikimisi
kirjeldus

project
array
Puudub
Projektide nimed.

compute_node
array
Puudub
Arvutusnode'de nimed.

storage_pool
array
Puudub
Salvestusturunduse nimed.

compute
enum
Puudub
Virtuaalmasina parameetrid [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].

storage
enum
Puudub
Diskide parameetrid [“size”, “created_at”].

Kasutatud meetodid — virtuaalmasinate migratsioon, diskide migratsioon.

Klassifitseerimata — abistav eesmärk, mida kasutatakse strateegia arendamise protsessi lihtsustamiseks. Ei sisalda spetsifikatsioone ja võib olla kasutusel iga kord, kui strateegia ei ole veel seotud olemasoleva eesmärgiga. Seda eesmärki saab kasutada ka üleminekuastmena. Selle eesmärgiga seotud strateegia on Actuator.   

Uue eesmärgi loomine

Watcher Decision Engine omab „välist eesmärki” pluginaliidest, mis võimaldab integreerida välise eesmärgi, mis on saavutatav strateegia abil.

Enne uue eesmärgi loomist peaksite veenduma, et ükski olemasolev eesmärk ei vasta teie vajadustele.

Uue plugina loomine

Uue eesmärgi loomiseks peate: laiendama eesmärgi klassi, rakendama klassi meetodi get_name () tagastamaks uue eesmärgi unikaalse identifikaatori, mille soovite luua. See unikaalne identifikaator peab vastama hiljem kuulutatud sisenemispunkti nimele.

Seejärel peate rakendama klassi meetodi get_display_name () sihtmärgi tõlgitud kuvamise nime tagastamiseks, mille soovite luua (ärge kasutage muutujaid tõlgitud stringi tagastamiseks, et see saaks automaatselt tõlke tööriista poolt kokku pannud.).

Rakenda klassi meetod get_translatable_display_name (), et tagastada tõlke võti (tegelikult ingliskeelne kuvamisnimi) uue sihtmärgi jaoks. Tagastatav väärtus peab vastama stringile, mis on tõlgitud meetodis get_display_name ().

Rakenda selle meetod get_efficacy_specification (), et tagastada sihtmärgi tõhususe spetsifikatsioon. Meetod get_efficacy_specification () tagastab Watcher'i poolt antud Unclassified () eksemplari. See tõhususe spetsifikatsioon on kasulik teie sihtmärgi arendamise protsessis, kuna see vastab tühjale spetsifikatsioonile.

→ Loe lähemalt siit

Watcheri arhitektuur (lisateave siit).

Komponendid

Watcher API — komponent, mis rakendab REST API, mida pakub Watcher. Suhtlemismehhanismid: CLI, Horizon plugin, Python SDK.

Watcher DB — Watcheri andmebaas.

Watcher Applier — komponent, mis rakendab tegevusplaani täitmist, mille on koostanud Watcher Decision Engine.

Watcher Decision Engine — komponent, mis vastutab auditi eesmärgi täitmiseks optimeerimisvõimaluste komplekti arvutamise eest. Kui strateegia pole määratud, valib komponent ise sobivama.

Watcher Metrics Publisher — komponent, mis kogub ja arvutab mõned mõõdikud või sündmused ning avaldab need CEP lõpp-punktis. Komponendi funktsionaalsust saab pakkuda ka Ceilometer publisher.

Kompleksne Sündmuste Töötlus (CEP) Mootor — kompleksne sündmuste töötlemise mootori. Jõudluse kaalutlustel võib olla mitu CEP mootori eksemplari, mis töötavad samal ajal, igaüks neist töötleb teatud tüüpi mõõdikuid/sündmusi. Watcheri süsteemis käivitab CEP kaks tüüpi toiminguid: — salvestada vastavad sündmused/mõõdikud ajareale andmebaasi; — saata vastavad sündmused Watcher Decision Engine komponenti, kui see sündmus võib mõjutada olemasoleva optimeerimisstrateegia tulemust, kuna Openstacki klaster pole staatiline süsteem.

Komponentide vaheline suhtlemine toimub AMQP protokolli kaudu.

→ Watcheri konfigureerimine

Watcheri interaktsiooni skeem

Watcheri testimise tulemused

1. Lehe Optimization — Action plans 500 viga (nii puhtal Queensil kui ka Tiionixi moodulitega seistes) ilmneb ainult pärast auditit ja tegevuskava genereerimist, tühi avaneb normaalselt.
2. Action details vahekaardil vigu, sihtmärki ja auditistrateegiat ei õnnestu saada (nii puhtal Queensil kui ka Tiionixi moodulitega seistes).
3. Auditid sihiga Dummy (testimiseks) luuakse ja käivitatakse normaalselt, tegevuskavad genereeritakse.
4. Auditid sihiga Unclassified ei loo, kuna sihtmärk ei ole funktsionaalne ja on mõeldud vahepealse seadistamise jaoks uute strateegiate loomisel.
5. Auditid sihiga Workload Balancing (Storage Capacity balance strateegia) luuakse edukalt, kuid tegevuskava ei genereerita. Salvestuspulkade optimeerimine ei ole vajalik.
6. Auditid sihiga Workload Balancing (Workload Balance Migration Strategy strateegia) luuakse edukalt, kuid tegevuskava ei genereerita.
7. Auditid sihiga Workload Balancing (Workload Stabilization Strategy strateegia) lõpetatakse veaga.
8. Auditid sihiga Noisy Neighbor luuakse edukalt, kuid tegevuskava ei genereerita.
9. Riistvara hoolduse auditid luuakse edukalt, tegevusplaan genereeritakse mittetäielikult (tulemusnäitajad genereeritakse, kuid tegevuste loetelu ise ei genereeru).
10. Muutused nova.conf konfiguratsioonifailides (default sektsioonis compute_monitors = cpu.virt_driver) arvutus- ja juhtimismoodulites ei paranda vigu.
11. Serveri konsolideerimise auditid (baastrateegia) lõppevad samuti tõrkega.
12. Serveri konsolideerimise auditid (VM töökoormuse konsolideerimise strateegia) lõppevad tõrkega. Logides on viga algandmete saamisel. Probleemi arutelu, eelkõige, siit.
    Proovisime konfiguraatoris Watcher määrata (ei aidanud — kõikide Optimiseerimise lehtede vead ei kao, tagasipöördumine algsetesse konfiguraatorifailidesse ei paranda olukorda):

    [watcher_strategies.basic]
    datasource = ceilometer, gnocchi

13. Energiat säästmise auditid lõppevad tõrkega. Logide põhjal tundub, et probleem on siiski Ironicu puudumises, ilma baremetal teenuseta ei tööta.
14. Termilise optimeerimise auditid lõppevad tõrkega. Jälgimine on sama, mis serveri konsolideerimise puhul (VM töökoormuse konsolideerimise strateegia) (algandmete viga).
15. Airflow optimeerimise auditid lõppevad tõrkega.

Audit järelkontrolli käigus võivad ilmneda järgmised tõrketeated. Otsustuste loomise logides on jälgimise jäljed (klastri olekut ei ole kindlaks tehtud).

→ Tõrke arutelu siit

Kokkuvõte

Kaks kuud kestnud uuringute tulemusena on meie järeldus selge: et saada tõhus ja töökorras koormuse tasakaalustamise süsteem, tuleb meil tegeleda OpenStacki platvormi tööriista täiendamisega.

Watcher on end tõestanud kui tõsine ja kiiresti arenev toode, mille täieõiguslikuks kasutamiseks on vajalik intensiivne ja põhjalik töö.

Kuid sellest räägime järgnevates artiklites.

Allikas: habr.com