En grandaj nubaj sistemoj, la temo de aŭtomata ekvilibro aŭ ebenigado de la ŝarĝo sur komputikaj rimedoj estas speciale akra. Tionix (programisto kaj funkciigisto de nubaj servoj, parto de la grupo de kompanioj Rostelecom) prizorgis ankaŭ ĉi tiun aferon.
Kaj, ĉar nia ĉefa disvolva platformo estas Openstack, kaj ni, kiel ĉiuj homoj, estas maldiligentaj, oni decidis elekti iun pretan modulon, kiu jam estas inkluzivita en la platformo. Nia elekto falis sur Watcher, kiun ni decidis uzi por niaj bezonoj.
Unue, ni rigardu la terminojn kaj difinojn.
Terminoj kaj Difinoj
Golo estas homlegebla, observebla kaj mezurebla fina rezulto, kiun oni devas atingi. Estas unu aŭ pluraj strategioj por atingi ĉiun celon. Strategio estas la efektivigo de algoritmo kiu kapablas trovi solvon por antaŭfiksita celo.
Ago estas elementa tasko kiu ŝanĝas la nunan staton de la cela administrita rimedo de la OpenStack-areo, kiel ekzemple: migrado de virtuala maŝino (migrado), ŝanĝi la potencon staton de nodo (change_node_power_state), ŝanĝi la staton de la nova servo (change_nova_service_state). ), ŝanĝanta guston (regrandigi), registri NOP-mesaĝojn (nop), mankon de agado dum certa tempo - paŭzo (dormo), diskotransigo (volume_migrate).
Agadplano - specifa fluo de agoj faritaj en certa ordo por atingi specifan Celon. La Agadplano ankaŭ enhavas mezurita tutmondan agadon kun aro de agado-indikiloj. Agadplano estas generita de Watcher post sukcesa revizio, kiel rezulto de kiu la strategio uzata trovas solvon por atingi la celon. Agadplano konsistas el listo de sinsekvaj agoj.
Revizio estas peto por optimumigi la areton. Optimumigo estas farita por atingi unu Celon en antaŭfiksita areto. Por ĉiu sukcesa revizio, Watcher generas Agadplanon.
Revizia Amplekso estas aro de resursoj ene de kiuj la revizio estas farita (havebleczono(j), nodo-agregantoj, individuaj komputaj nodoj aŭ stokadnodoj, ktp.). La revizia amplekso estas difinita en ĉiu ŝablono. Se revizia amplekso ne estas specifita, la tuta areto estas kontrolita.
Revizia Ŝablono — konservita aro de agordoj por lanĉi revizion. Ŝablonoj estas bezonataj por plenumi auditoriojn plurfoje kun la samaj agordoj. La ŝablono nepre devas enhavi la celon de la revizio; se strategioj ne estas precizigitaj, tiam la plej taŭgaj ekzistantaj strategioj estas elektitaj.
Areto estas kolekto de fizikaj maŝinoj kiuj disponigas komputadon, stokadon, kaj retajn rimedojn kaj estas administritaj per la sama OpenStack-administra nodo.
Areto-Datummodelo (CDM) estas logika reprezentado de la nuna stato kaj topologio de la resursoj administritaj de la areto.
Indikilo de Efikeco - indikilo kiu indikas kiel la solvo kreita per ĉi tiu strategio estas farita. Efikecindikiloj estas specifaj por speciala celo kaj estas tipe uzitaj por kalkuli la tutmondan efikecon de la rezulta agadplano.
Specifo de Efikeco estas aro de specifaj trajtoj asociitaj kun ĉiu Celo, kiu difinas la diversajn rezultajn indikilojn, kiujn strategio por atingi la respondan Celon devas atingi en sia solvo. Efektive, ĉiu solvo proponita de la strategio estos kontrolita kontraŭ la specifo antaŭ ol kalkuli ĝian tutmondan efikecon.
Poentara Motoro estas plenumebla dosiero, kiu havas bone difinitajn enigaĵojn, bone difinitajn elirojn, kaj plenumas pure matematikan taskon. Tiel, la kalkulo estas sendependa de la medio en kiu ĝi estas farita—ĝi donos la saman rezulton ie ajn.
Watcher Planisto - parto de la decida motoro Watcher. Ĉi tiu modulo prenas aron da agoj generitaj de strategio kaj kreas laborfluan planon, kiu specifas kiel plani ĉi tiujn malsamajn agojn ĝustatempe kaj por ĉiu ago, kiaj estas la antaŭkondiĉoj.
Watcher Celoj kaj Strategioj
Golo
Strategio
Manipula celo
Dummy Strategio
Dummy Strategio uzante specimenajn Scoring Engines
Manipula strategio kun regrandigo
Savanta Energion
Strategio pri Ŝparado de Energio
Servila Firmiĝo
Baza Senreta Servilo-Filigo
VM Laborŝarĝa Plifirmiga Strategio
Ekvilibro de Laborŝarĝo
Laborŝarĝa Ekvilibro Migra Strategio
Stoka Kapacito-Ekvilibro Strategio
Stabiligo de laborŝarĝo
Brua Najbaro
Brua Najbaro
Termika Optimumigo
Elirejo temperaturo bazita strategio
Optimumigo de aerfluo
Uniforma aerflua migrada strategio
Aparataro-prizorgado
Zonomigrado
nesekretaj
Aktoro
Manipula celo — rezervita celo, kiu estas uzata por testaj celoj.
Rilataj strategioj: Dummy Strategio, Dummy Strategio uzante specimenajn Scoring Engines kaj Dummy-strategion kun regrandigo. Dummy-strategio estas imita strategio uzata por integriĝtestado tra Tempest. Ĉi tiu strategio ne provizas ajnan utilan optimumigon, ĝia sola celo estas uzi Tempest-testojn.
Dummy-strategio uzanta specimenajn Poentarajn Motorojn - la strategio estas simila al la antaŭa, la nura diferenco estas la uzo de specimena "Poentara motoro" kiu faras kalkulojn uzante maŝinlernajn metodojn.
Dummy-strategio kun regrandigo - la strategio estas simila al la antaŭa, la sola diferenco estas la uzo de ŝanĝi la guston (migrado kaj regrandigo).
Ne uzata en produktado.
Savanta Energion — minimumigi energikonsumon. La Saving Energy Strategy de ĉi tiu celo, kune kun la VM Workload Consolidation Strategy (Servilo-Filigo), kapablas je dinamika potenco-administrado (DPM) funkcioj kiuj ŝparas energion dinamike solidigante laborkvantojn eĉ dum periodoj de malalta utiligo de rimedoj: virtualaj maŝinoj estas movitaj al malpli da nodoj. , kaj nenecesaj nodoj estas malŝaltitaj. Post firmiĝo, la strategio proponas decidon pri ŝalti/malŝalti nodojn laŭ la specifitaj parametroj: "min_free_hosts_num" - la nombro da liberaj ebligitaj nodoj, kiuj atendas ŝarĝon, kaj "free_used_percent" - la procento de liberaj ebligitaj gastigantoj al la nombro da nodoj, kiuj estas okupataj de maŝinoj. Por ke la strategio funkciu devas ekzisti ebligis kaj agordis Ironian por trakti potencan bicikladon sur nodoj.
Strategiaj parametroj
parametro
speco
implicite
la priskribo
libera_uzata_procento
nombro
10.0
rilatumo de la nombro da liberaj komputiknodoj al la nombro da komputiknodoj kun virtualaj maŝinoj
min_libera_gastigantoj_num
Mez
1
minimuma nombro da liberaj komputaj nodoj
La nubo devas havi almenaŭ du nodojn. La metodo uzata estas ŝanĝi la potencon de la nodo (change_node_power_state). La strategio ne postulas kolekti metrikojn.
Server Consolidation - minimumigi la nombron da komputiknodoj (firmiĝo). Ĝi havas du strategiojn: Baza Senreta Servilo-Filigo kaj VM-Laborŝarĝa Konsolida Strategio.
La Strategio de Baza Senreta Servilo-Filigado minimumigas la totalan nombron de uzataj serviloj kaj ankaŭ minimumigas la nombron da migradoj.
La baza strategio postulas la sekvajn metrikojn:
metrikoj
servo
kromaĵojn
komento
compute.node.cpu.procent
neniu
cpu_util
neniu
Strategiaj parametroj: migration_attempts - nombro da kombinaĵoj por serĉi eblajn kandidatojn por ĉesigo (defaŭlte, 0, sen limigoj), periodo - tempointervalo en sekundoj por akiri statikan agregadon de la metrika datumfonto (defaŭlte, 700).
Metodoj uzataj: migrado, ŝanĝi la nova servo-stato (change_nova_service_state).
La VM Workload Consolidation Strategy baziĝas sur unua-taŭga heŭristiko, kiu fokusiĝas al mezurita CPU-ŝarĝo kaj provas minimumigi nodojn, kiuj havas tro multe aŭ tro malmulte da ŝarĝo konsiderante rimedajn kapacitajn limojn. Ĉi tiu strategio provizas solvon, kiu rezultigas pli efikan uzon de amasresursoj uzante la sekvajn kvar paŝojn:
- Malŝarĝa fazo - prilaborado de tro uzataj rimedoj;
- Consolidation phase - pritraktado de nesufiĉe uzataj rimedoj;
- Optimumigo de la solvo - redukto de la nombro da migradoj;
- Malebligado de neuzataj komputaj nodoj.
La strategio postulas la sekvajn metrikojn:
metrikoj
servo
kromaĵojn
komento
memoro
neniu
disk.radiko.grandeco
neniu
La sekvaj metrikoj estas laŭvolaj sed plibonigos strategioprecizecon se disponeblaj:
metrikoj
servo
kromaĵojn
komento
memoro.loĝanto
neniu
cpu_util
neniu
Strategiaj parametroj: periodo — tempa intervalo en sekundoj por akiri senmovan agregon de la metrika datumfonto (defaŭlte, 3600).
Uzas la samajn metodojn kiel la antaŭa strategio. Pli da detaloj .
Ekvilibro de Laborŝarĝo — ekvilibrigi la laborŝarĝon inter komputikaj nodoj. La celo havas tri strategiojn: Strategio pri Migrado de Laborŝarĝo, Stabiligo de Laborŝarĝo, Strategio pri Stoka Kapacito.
Workload Balance Migration Strategy kuras virtualajn maŝinajn migradojn bazitajn sur la gastiganta virtuala maŝina laborkvanto. Migraddecido estas farita kiam ajn la % CPU aŭ RAM-utiligo de nodo superas la specifitan sojlon. En ĉi tiu kazo, la movita virtuala maŝino devus alproksimigi la nodon al la averaĝa laborkvanto de ĉiuj nodoj.
postuloj
- Uzo de fizikaj procesoroj;
- Almenaŭ du fizikaj komputiknodoj;
- Instalis kaj agordis la Ceilometer-komponenton - ceilometer-agent-compute, funkcianta sur ĉiu komputa nodo, kaj la Ceilometer API, kaj ankaŭ kolekti la sekvajn metrikojn:
metrikoj
servo
kromaĵojn
komento
cpu_util
neniu
memoro.loĝanto
neniu
Strategiaj parametroj:
parametro
speco
implicite
la priskribo
metrikoj
ĉeno
'cpu_util'
La subaj metrikoj estas: 'cpu_util', 'memory.resident'.
sojlo
nombro
25.0
Laborŝarĝa sojlo por migrado.
periodo
nombro
300
Akumula tempoperiodo Ceilometro.
La metodo uzata estas migrado.
Laborkvanto-stabiligo estas strategio celanta stabiligi la laborkvanton uzante vivan migradon. La strategio baziĝas sur norma devio-algoritmo kaj determinas ĉu ekzistas obstrukciĝo en la areto kaj respondas al ĝi ekigante maŝinmigradon por stabiligi la areton.
postuloj
- Uzo de fizikaj procesoroj;
- Almenaŭ du fizikaj komputiknodoj;
- Instalis kaj agordis la Ceilometer-komponenton - ceilometer-agent-compute, funkcianta sur ĉiu komputa nodo, kaj la Ceilometer API, kaj ankaŭ kolekti la sekvajn metrikojn:
metrikoj
servo
kromaĵojn
komento
cpu_util
neniu
memoro.loĝanto
neniu
Storage Capacity Balance Strategy (strategio efektivigita komencante kun Kvinzo) - la strategio transdonas diskojn depende de la ŝarĝo sur la Cinder-naĝejoj. Transiga decido estas farita kiam ajn la naĝeja utiligoprocento superas precizigitan sojlon. La disko movita devus alproksimigi la naĝejon al la averaĝa ŝarĝo de ĉiuj Cinder-naĝejoj.
Postuloj kaj limigoj
- Minimume du Cinder-naĝejoj;
- Eblo de disko migrado.
- Cluster datummodelo - Cinder areto datummodelkolektanto.
Strategiaj parametroj:
parametro
speco
implicite
la priskribo
volumo_sojlo
nombro
80.0
Sojla valoro de diskoj por ekvilibrigi volumojn.
La metodo uzata estas diskmigrado (volume_migrate).
Brua Najbaro - Identigu kaj migru "bruan najbaron" - malaltprioritata virtuala maŝino, kiu negative influas la agadon de altprioritata virtuala maŝino laŭ IPC per trouzado de Last Level Cache. Propra strategio: Brua Najbaro (strategia parametro uzata estas cache_threshold (defaŭlta valoro estas 35), kiam rendimento falas al la specifita valoro, migrado komenciĝas. Por ke la strategio funkciu, estas ebligita. LLC (Lasta Nivela Kaŝmemoro) metrikoj, plej nova Intel-servilo kun CMT-subteno, same kiel kolekti la sekvajn metrikojn:
metrikoj
servo
kromaĵojn
komento
cpu_l3_cache
neniu
Intel postulis .
Areto datummodelo (defaŭlte): Nova areto datummodelkolektilo. La metodo uzata estas migrado.
Labori kun ĉi tiu celo per la Instrumentpanelo ne estas plene efektivigita en Kvinzo.
Termika Optimumigo - optimumigi la temperaturreĝimon. Elirejo (degasaero) temperaturo estas unu el la gravaj termikaj telemetriaj sistemoj por mezuri la termikan/laborŝarĝan statuson de servilo. La celo havas unu strategion, la Outlettemperaturon bazitan strategion, kiu decidas migri laborkvantojn al termike favoraj gastigantoj (plej malsupra ellasejotemperaturo) kiam la ellasejotemperaturo de la fontgastigantoj atingas agordeblan sojlon.
Por ke la strategio funkciu, vi bezonas servilon kun Intel Power Node Manager instalita kaj agordita , same kiel kolekti la sekvajn metrikojn:
metrikoj
servo
kromaĵojn
komento
hardvaro.ipmi.node.outlet_temperature
IPMI
Strategiaj parametroj:
parametro
speco
implicite
la priskribo
sojlo
nombro
35.0
Temperatursojlo por migrado.
periodo
nombro
30
La tempointervalo, en sekundoj, por akiri la statistikan agregadon de la metrika datenfonto.
La metodo uzata estas migrado.
Optimumigo de aerfluo - optimumigi la ventoligan reĝimon. Propra strategio - Uniforma Aerfluo uzante vivan migradon. La strategio ekigas virtualan maŝinan migradon kiam ajn la aerfluo de la servila ventolilo superas specifitan sojlon.
Por ke la strategio funkciu, vi bezonas:
- Aparataro: komputi nodojn < subtenante NodeManager 3.0;
- Almenaŭ du komputikaj nodoj;
- La ceilometer-agent-compute kaj Ceilometer API-komponento instalita kaj agordita sur ĉiu komputika nodo, kiu povas sukcese raporti mezurojn kiel aerfluo, sistema potenco, enirtemperaturo:
metrikoj
servo
kromaĵojn
komento
aparataro.ipmi.nodo.aerfluo
IPMI
aparataro.ipmi.nodo.temperaturo
IPMI
aparataro.ipmi.nodo.potenco
IPMI
Por ke la strategio funkciu, vi bezonas servilon kun Intel Power Node Manager 3.0 aŭ poste instalita kaj agordita.
Limigoj: La koncepto ne estas destinita por produktado.
Estas proponite uzi ĉi tiun algoritmon kun kontinuaj revizioj, ĉar nur unu virtuala maŝino estas planita esti migrita per ripeto.
Vivaj migradoj eblas.
Strategiaj parametroj:
parametro
speco
implicite
la priskribo
sojlo_aera fluo
nombro
400.0
Aerflua sojlo por migra Unuo estas 0.1CFM
sojlo_eniro_t
nombro
28.0
Enirtemperatursojlo por migraddecido
sojlo_potenco
nombro
350.0
Sistempotenca sojlo por decido pri migrado
periodo
nombro
30
La tempointervalo, en sekundoj, por akiri la statistikan agregadon de la metrika datenfonto.
La metodo uzata estas migrado.
Hardada Bontenado — aparataro prizorgado. La strategio rilata al ĉi tiu celo estas Zonomigrado. La strategio estas ilo por efika aŭtomata kaj minimuma migrado de virtualaj maŝinoj kaj diskoj en kazo de bezono de aparataro prizorgado. Strategio konstruas agadplanon laŭ pezoj: aro da agoj, kiu havas pli da pezo, estos planita antaŭ aliaj. Estas du agordaj opcioj: action_weights kaj paraleligo.
Limigoj: ago pezoj kaj paraleligo devas esti agordita.
Strategiaj parametroj:
parametro
speco
implicite
la priskribo
komputi_nodoj
tabelo
neniu
Komputi nodojn por migrado.
stokejoj
tabelo
neniu
Stokaj nodoj por migrado.
paralela_totala
entjero
6
La tuta nombro de agadoj, kiuj devas esti efektivigitaj paralele.
paralela_po_nodo
entjero
2
La nombro da agoj faritaj paralele por ĉiu komputa nodo.
paralela_po_naĝejo
entjero
2
La nombro da agoj faritaj paralele por ĉiu stoka naĝejo.
prioritato
objekto
neniu
Priorita listo por virtualaj maŝinoj kaj diskoj.
kun_ligita_volumo
bulea
falsa
False—virtualaj maŝinoj estos migritaj post kiam ĉiuj diskoj estos migritaj. Vere—virtualaj maŝinoj estos migritaj post kiam ĉiuj konektitaj diskoj estos migritaj.
Elementoj de la aro de komputiknodoj:
parametro
speco
implicite
la priskribo
src_nodo
ĉeno
neniu
La komputa nodo de kiu la virtualaj maŝinoj estas migritaj (postulata).
dst_nodo
ĉeno
neniu
Kalkulu la nodon al kiu la virtualaj maŝinoj migras.
Stokaj nodaj tabelelementoj:
parametro
speco
implicite
la priskribo
src_pool
ĉeno
neniu
La stokado de kiu la diskoj estas migritaj (postulata).
dst_pool
ĉeno
neniu
La stokado al kiu diskoj estas migritaj.
src_tipo
ĉeno
neniu
Originala disko-tipo (postulata).
dst_tipo
ĉeno
neniu
La rezulta disko tipo (postulata).
Objektaj prioritataj elementoj:
parametro
speco
implicite
la priskribo
projekto
tabelo
neniu
Nomoj de projekto.
komputa_nodo
tabelo
neniu
Kalkuli nodnomojn.
stokado_pool
tabelo
neniu
Nomoj de stokado.
komputi
enum
neniu
Virtualaj maŝinaj parametroj [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
stokado
enum
neniu
Diskaj parametroj [“grandeco”, “kreita_ĉe”].
La metodoj uzataj estas virtuala maŝina migrado, disko migrado.
nesekretaj - helpa celo uzata por faciligi la strategio-disvolvan procezon. Enhavas neniujn specifojn kaj povas esti uzata kiam ajn la strategio ankoraŭ ne estas asociita kun ekzistanta celo. Ĉi tiu celo ankaŭ povas esti uzata kiel transira punkto. Rilata strategio al ĉi tiu celo estas Actuator.
Kreante novan celon
Watcher Decision Engine havas "eksteran celon" krominterfaco, kiu ebligas integri eksteran celon, kiu povas esti atingita per strategio.
Antaŭ ol vi kreas novan celon, vi devas certigi, ke neniuj ekzistantaj celoj plenumas viajn bezonojn.
Kreante novan kromprogramon
Por krei novan celon, vi devas: etendi la celklason, efektivigi klasmetodon get_name() por redoni la unikan identigilon de la nova celo, kiun vi volas krei. Ĉi tiu unika identigilo devas kongrui kun la nomo de enirpunkto, kiun vi deklaras poste.
Poste vi devas efektivigi la klasan metodon get_montri_nomo() por redoni la tradukitan montran nomon de la celo, kiun vi volas krei (ne uzu variablon por redoni la tradukitan ĉenon, por ke ĝi povu esti aŭtomate kolektita de la tradukilo.).
Efektivigi klasan metodon get_tradukebla_montra_nomo()por redoni la tradukŝlosilon (fakte la anglan montran nomon) de via nova celo. La revena valoro devas kongrui kun la ĉeno tradukita en get_display_name ().
Efektivigu lian metodon get_efikeca_specifo()por redoni la efikecspecifon por via celo. La metodo get_efficacy_specification() resendas la ekzemplon Unclassified() provizitan de Watcher. Ĉi tiu agado-specifo estas utila en la procezo de evoluigado de via celo ĉar ĝi respondas al la malplena specifo.
→
Watcher-arkitekturo (pli da detaloj) ).
Komponantoj
Watcher API - komponanto kiu efektivigas la REST API provizitan de Watcher. Interagaj mekanismoj: CLI, Horizon kromaĵo, Python SDK.
Watcher DB — Watcher datumbazo.
Aplikanto de Watcher — komponanto kiu efektivigas la plenumon de agadplano kreita de la komponanto Watcher Decision Engine.
Watcher Decision Engine - La komponento respondeca por komputado de aro de eblaj optimumigaj agoj por atingi la auditcelon. Se strategio ne estas specifita, la komponanto sendepende elektas la plej taŭgan.
Eldonisto de Watcher Metrics - Komponanto kiu kolektas kaj kalkulas iujn metrikojn aŭ eventojn kaj publikigas ilin al la CEP-finpunkto. La funkcieco de la komponento ankaŭ povas esti disponigita fare de Ceilometer-eldonisto.
Kompleksa Eventa Pretigo (CEP) Motoro — motoro por kompleksa evento-prilaborado. Pro agado-kialoj, povas ekzisti pluraj okazoj de CEP-Motoro funkcianta samtempe, ĉiu prilaborante specifan specon de metriko/okazaĵo. En la Watcher-sistemo, CEP ekigas du specojn de agoj: - registri koncernajn eventojn / metrikojn en la temp-seriodatumbazo; - sendu taŭgajn eventojn al la Watcher Decision Engine kiam ĉi tiu evento povas influi la rezulton de la nuna optimumiga strategio, ĉar la Openstack-areto ne estas senmova sistemo.
La komponentoj interagas uzante la AMQP-protokolon.
→
Skemo de interago kun Watcher
Watcher-testrezultoj
- Sur la paĝo Optimumigo - Agadplanoj 500 (kaj sur puraj Queens kaj sur stando kun Tionix-moduloj), ĝi aperas nur post kiam la revizio estas lanĉita kaj agadplano estas generita; la malplena malfermiĝas normale.
- Estas eraroj sur la langeto Ago-detaloj, ne eblas akiri la auditcelon kaj strategion (kaj sur puraj Queens kaj sur stando kun Tionix-moduloj).
- Aŭditoroj kun la celo de Dummy (testo) estas kreitaj kaj lanĉitaj normale, agadplanoj estas generitaj.
- Revizioj por la Neklasifikita celo ne estas kreitaj ĉar la celo ne estas funkcia kaj estas celita por meza agordo dum kreado de novaj strategioj.
- Revizioj por la ekvilibro de la laborŝarĝo (strategio pri ekvilibro de la kapablo de stokado) estas kreitaj sukcese, sed agadplano ne estas kreita. Ne necesas optimumigo de stokado.
- Aŭditoroj por la Laborŝarĝa Ekvilibro-celo (Workload Balance Migration Strategy) estas kreitaj sukcese, sed agadplano ne estas generita.
- Revizioj por Laborŝarĝa Ekvilibro (Laborŝarĝa Stabiliga Strategio) malsukcesas.
- Revizioj por la celo Noisy Neighbor estas kreitaj sukcese, sed agadplano ne estas generita.
- Aŭditoroj por Aparataro prizorgado estas kreitaj sukcese, la agadplano ne estas generita en plena (efikecindikiloj estas generitaj, sed la listo de agoj mem ne estas generita).
- Redaktoj en la nova.conf agordoj (en la defaŭlta sekcio compute_monitors = cpu.virt_driver) sur la komputaj kaj kontrolnodoj ne korektas la erarojn.
- Aŭditoroj celantaj Servilo-Filigon (Baza strategio) ankaŭ malsukcesas.
- Revizioj por la Serva Konsolidado (VM-laborŝarĝa firmiga strategio) malsukcesas kun eraro. En la protokoloj estas eraro en la akiro de fontaj datumoj. Diskuto de la eraro, precipe .
Ni provis specifi Watcher en la agorda dosiero (ĝi ne helpis - kiel rezulto de eraro sur ĉiuj Optimumigo-paĝoj, reveni al la originala enhavo de la agorda dosiero ne korektas la situacion): [watcher_strategies.basic] datumfonto = ceilometro, gnokoj - Revizioj por Ŝpari Energion malsukcesas. Juĝante laŭ la protokoloj, la problemo daŭre estas la foresto de Ironio; ĝi ne funkcios sen senmetala servo.
- Revizioj por Termika Optimumigo malsukcesas. La spuro estas la sama kiel por Server Consolidation (VM-laborŝarĝa firmiga strategio) (fonta datuma eraro)
- Revizioj por la celo de Aerflua Optimumigo malsukcesas kun eraro.
La sekvaj reviziokompletaj eraroj ankaŭ estas renkontitaj. Spuro en protokoloj de decision-engine.log (grupo stato ne estas difinita).
→ Diskuto pri la eraro
konkludo
La rezulto de nia du-monata esplorado estis la senduba konkludo, ke por akiri plentaŭgan, funkcian ŝarĝan ekvilibran sistemon, ni devos, en ĉi tiu parto, proksime labori pri rafini la ilojn por la Openstack-platformo.
Watcher pruvis esti serioza kaj rapide evoluanta produkto kun enorma potencialo, kies plena uzo postulos multan seriozan laboron.
Sed pli pri tio en la sekvaj artikoloj de la serio.
fonto: www.habr.com