Ing sistem awan gedhe, masalah imbangan otomatis utawa leveling beban ing sumber daya komputasi utamane akut. Tionix (pangembang lan operator layanan awan, bagean saka grup perusahaan Rostelecom) uga wis ngurus masalah iki.
Na, wiwit platform pembangunan utama Openstack, lan kita, kaya kabeh wong, kesed, iki mutusaké kanggo milih sawetara modul siap-digawe sing wis klebu ing platform. Pilihan kita tiba ing Watcher, sing kita mutusake kanggo nggunakake kanggo kabutuhan.
Pisanan, ayo ndeleng istilah lan definisi.
Syarat lan Definisi
Tujuane minangka asil pungkasan sing bisa diwaca manungsa, bisa diamati lan bisa diukur sing kudu digayuh. Ana siji utawa luwih strategi kanggo nggayuh saben tujuan. Strategi minangka implementasi algoritma sing bisa nemokake solusi kanggo tujuan tartamtu.
Tumindak minangka tugas dhasar sing ngganti kahanan saiki sumber daya sing dikelola target saka kluster OpenStack, kayata: migrasi mesin virtual (migrasi), ngganti status daya simpul (change_node_power_state), ngganti status layanan nova (change_nova_service_state). ), ngganti rasa (ngowahi ukuran), ndhaptar pesen NOP (nop), kurang tumindak kanggo wektu tartamtu - ngaso (turu), transfer disk (volume_migrate).
Rencana Tindakan - aliran tumindak tartamtu sing ditindakake kanthi urutan tartamtu kanggo nggayuh Tujuan tartamtu. Rencana Tindakan uga ngemot kinerja global sing diukur kanthi sakumpulan indikator kinerja. Rencana aksi digawe dening Watcher nalika audit sukses, minangka asil saka strategi sing digunakake nemokake solusi kanggo nggayuh tujuan kasebut. Rencana aksi kalebu dhaptar tumindak sing berurutan.
Audit iku panjalukan kanggo ngoptimalake kluster. Optimasi ditindakake kanggo nggayuh siji Sasaran ing klompok tartamtu. Kanggo saben audit sing sukses, Watcher ngasilake Rencana Tindakan.
Lingkup Audit minangka kumpulan sumber daya ing ngendi audit ditindakake (zona kasedhiyan, agregator simpul, simpul komputasi individu utawa simpul panyimpenan, lsp.). Ruang lingkup audit ditetepake ing saben cithakan. Yen orane katrangan audit ora ditemtokake, kabeh kluster bakal diaudit.
Cithakan Audit - setelan sing disimpen kanggo mbukak audit. Cithakan dibutuhake kanggo nindakake audit kaping pirang-pirang kanthi setelan sing padha. Cithakan kasebut kudu ngemot tujuan audit; yen strategi ora ditemtokake, banjur strategi sing ana sing paling cocok dipilih.
Kluster minangka kumpulan mesin fisik sing nyedhiyakake sumber daya komputasi, panyimpenan, lan jaringan lan dikelola dening simpul manajemen OpenStack sing padha.
Model Data Kluster (CDM) minangka perwakilan logis saka kahanan saiki lan topologi sumber daya sing dikelola dening kluster.
Indikator Efisiensi - indikator sing nuduhake carane solusi digawe nggunakake strategi iki dileksanakake. Indikator kinerja khusus kanggo tujuan tartamtu lan biasane digunakake kanggo ngetung efektivitas global saka rencana aksi sing diasilake.
Spesifikasi Khasiat minangka sakumpulan fitur khusus sing ana gandhengane karo saben Sasaran sing nemtokake macem-macem indikator kinerja sing kudu ditindakake strategi kanggo nggayuh Sasaran sing cocog ing solusi kasebut. Pancen, saben solusi sing diusulake dening strategi kasebut bakal dipriksa miturut spesifikasi sadurunge ngitung efektifitas global.
Scoring Engine minangka file eksekusi sing nduweni input sing wis ditemtokake, output sing ditemtokake kanthi apik, lan nindakake tugas matematika sing murni. Kanthi cara iki, pitungan kasebut ora gumantung saka lingkungan sing ditindakake - bakal menehi asil sing padha ing ngendi wae.
Pengawas Planner - bagean saka mesin nggawe keputusan Watcher. Modul iki njupuk sakumpulan tumindak sing digawe dening strategi lan nggawe rencana alur kerja sing nemtokake cara gawe jadwal tumindak sing beda-beda ing wektu lan kanggo saben tumindak, apa prasyarate.
Sasaran lan Sastranegara Watcher
Tujuane
Sastranegara
Gol goblok
Strategi Dummy
Dummy Strategy nggunakake sampel Scoring Engines
Strategi goblok kanthi ukuran
Ngirit Energi
Strategi Ngirit Energi
Konsolidasi Server
Konsolidasi Server Offline dhasar
Strategi Konsolidasi Beban Kerja VM
Workload Balancing
Workload Balance Migration Strategy
Strategy imbangan Kapasitas Storage
Stabilisasi beban kerja
Tanggane rame
Tanggane rame
Optimasi termal
Strategi adhedhasar suhu outlet
Optimisasi Aliran Udara
Strategi migrasi aliran udara seragam
Pangopènan hardware
Migrasi zona
Ora diklasifikasikake
Aktuator
Gol goblok - goal reserved sing digunakake kanggo tujuan testing.
Sastranegara sing gegandhengan: Strategi Dummy, Strategi Dummy nggunakake Mesin Skor sampel lan strategi Dummy kanthi ukuran. Strategi goblok minangka strategi goblok sing digunakake kanggo tes integrasi liwat Tempest. Strategi iki ora nyedhiyakake optimasi sing migunani, tujuane mung nggunakake tes Tempest.
Strategi goblok nggunakake Sample Scoring Engines - strategi kasebut padha karo sing sadurunge, mung bedane yaiku nggunakake sampel "mesin skor" sing nindakake petungan nggunakake metode pembelajaran mesin.
Strategi goblok kanthi ngowahi ukuran - strategi kasebut padha karo sing sadurunge, mung bedane yaiku nggunakake ngganti rasa (migrasi lan ngowahi ukuran).
Ora digunakake ing produksi.
Ngirit Energi - nyilikake konsumsi energi. Strategi Saving Energy goal iki, bebarengan karo Strategi Konsolidasi Beban Kerja VM (Konsolidasi Server), nduweni fitur manajemen daya dinamis (DPM) sing bisa ngirit energi kanthi nggabungake beban kerja kanthi dinamis sanajan sajrone wektu panggunaan sumber daya sing sithik: mesin virtual dipindhah menyang node sing luwih sithik. , lan simpul sing ora perlu dipateni. Sawise konsolidasi, strategi kasebut menehi keputusan kanggo ngaktifake / mateni simpul sesuai karo paramèter sing ditemtokake: "min_free_hosts_num" - jumlah simpul aktif gratis sing nunggu muatan, lan "free_used_percent" - persentase host sing aktif gratis menyang nomer simpul sing dikuwasani dening mesin. Kanggo strategi bisa digunakake kudu ana diaktifake lan diatur Ironic kanggo nangani siklus daya ing kelenjar.
Paramèter strategi
paramèter
ketik
kanthi gawan
katrangan
free_used_percent
Panggil
10.0
rasio jumlah simpul komputasi gratis kanggo jumlah simpul komputasi kanthi mesin virtual
min_free_hosts_num
Int
1
jumlah minimal node komputasi gratis
Awan kudu paling sethithik rong simpul. Cara sing digunakake yaiku ngganti status daya simpul (change_node_power_state). Strategi kasebut ora mbutuhake metrik ngumpulake.
Konsolidasi Server - nyilikake jumlah simpul komputasi (konsolidasi). Wis rong strategi: Konsolidasi Server Offline Dasar lan Strategi Konsolidasi Beban Kerja VM.
Strategi Konsolidasi Server Offline Dasar nyilikake jumlah total server sing digunakake lan uga nyilikake jumlah migrasi.
Strategi dhasar mbutuhake metrik ing ngisor iki:
metrik
layanan
plugins
komentar
compute.node.cpu.percent
ora ana
cpu_util
ora ana
Parameter strategi: migration_attempts - jumlah kombinasi kanggo nggoleki calon potensial kanggo mati (standar, 0, ora ana watesan), periode - interval wektu ing detik kanggo entuk agregasi statis saka sumber data metrik (standar, 700).
Cara sing digunakake: migrasi, ngganti status layanan nova (change_nova_service_state).
Strategi Konsolidasi Beban Kerja VM adhedhasar heuristik sing cocog pisanan sing fokus ing beban CPU sing diukur lan nyoba nyilikake simpul sing duwe beban sing akeh utawa sithik amarga watesan kapasitas sumber. Strategi iki nyedhiyakake solusi sing nyebabake panggunaan sumber daya kluster sing luwih efisien nggunakake patang langkah ing ngisor iki:
- Tahap unloading - pangolahan sumber daya sing ora digunakake;
- Fase konsolidasi - nangani sumber daya sing ora digunakake;
- Optimasi solusi - nyuda jumlah migrasi;
- Mateni node komputasi sing ora digunakake.
Strategi kasebut mbutuhake metrik ing ngisor iki:
metrik
layanan
plugins
komentar
memori
ora ana
disk.root.size
ora ana
Metrik ing ngisor iki opsional nanging bakal nambah akurasi strategi yen kasedhiya:
metrik
layanan
plugins
komentar
memori.penduduk
ora ana
cpu_util
ora ana
Parameter strategi: periode — interval wektu ing detik kanggo entuk agregasi statis saka sumber data metrik (standar, 3600).
Nggunakake cara sing padha karo strategi sadurunge. rincian liyane .
Workload Balancing - ngimbangi beban kerja ing antarane simpul komputasi. Sasaran kasebut nduweni telung strategi: Strategi Migrasi Keseimbangan Beban Kerja, Stabilisasi Beban Kerja, Strategi Keseimbangan Kapasitas Panyimpenan.
Workload Balance Migration Strategy mbukak migrasi mesin virtual adhedhasar beban kerja mesin virtual host. Kaputusan migrasi digawe nalika % panggunaan CPU utawa RAM saka simpul ngluwihi batesan sing ditemtokake. Ing kasus iki, mesin virtual sing dipindhah kudu nggawa simpul nyedhaki beban kerja rata-rata kabeh simpul.
syarat
- Panganggone prosesor fisik;
- Paling ora rong simpul komputasi fisik;
- Dipasang lan dikonfigurasi komponen Ceilometer - ceilometer-agent-compute, mlaku ing saben simpul komputasi, lan Ceilometer API, uga ngumpulake metrik ing ngisor iki:
metrik
layanan
plugins
komentar
cpu_util
ora ana
memori.penduduk
ora ana
Parameter strategi:
paramèter
ketik
kanthi gawan
katrangan
metrik
String
'cpu_util'
Metrik dhasar yaiku: 'cpu_util', 'memory.resident'.
batesan
Panggil
25.0
Ambang beban kerja kanggo migrasi.
wektu
Panggil
300
Ceilometer periode wektu kumulatif.
Cara sing digunakake yaiku migrasi.
Stabilisasi beban kerja minangka strategi kanggo nyetabilake beban kerja kanthi nggunakake migrasi langsung. Strategi kasebut adhedhasar algoritma panyimpangan standar lan nemtokake manawa ana kemacetan ing kluster lan nanggapi kanthi micu migrasi mesin kanggo stabil kluster.
syarat
- Panganggone prosesor fisik;
- Paling ora rong simpul komputasi fisik;
- Dipasang lan dikonfigurasi komponen Ceilometer - ceilometer-agent-compute, mlaku ing saben simpul komputasi, lan Ceilometer API, uga ngumpulake metrik ing ngisor iki:
metrik
layanan
plugins
komentar
cpu_util
ora ana
memori.penduduk
ora ana
Kapasitas Storage Balance Strategy (strategi dipun ginakaken miwiti karo Queens) - strategi nransfer disk gumantung ing mbukak ing Cinder pools. Kaputusan transfer digawe nalika tingkat panggunaan blumbang ngluwihi batesan sing ditemtokake. Disk sing dipindhah kudu nggawa blumbang nyedhaki beban rata-rata kabeh blumbang Cinder.
Syarat lan watesan
- Minimal rong kolam Cinder;
- Kemungkinan migrasi disk.
- Model data cluster - kolektor model data cluster Cinder.
Parameter strategi:
paramèter
ketik
kanthi gawan
katrangan
volume_ambang
Panggil
80.0
Nilai ambang disk kanggo keseimbangan volume.
Cara sing digunakake yaiku migrasi disk (volume_migrate).
Noisy Neighbor - Ngenali lan migrasi "tetangga sing rame" - mesin virtual prioritas kurang sing duwe pengaruh negatif marang kinerja mesin virtual prioritas dhuwur ing babagan IPC kanthi nggunakake Cache Tingkat Terakhir. Strategi dhewe: Noisy Neighbor (parameter strategi sing digunakake yaiku cache_threshold (nilai standar yaiku 35), nalika kinerja mudhun menyang nilai sing ditemtokake, migrasi diwiwiti. Supaya strategi bisa digunakake, diaktifake metrik LLC (Last Level Cache), server Intel paling anyar karo support CMT, uga ngumpulake metrik ing ngisor iki:
metrik
layanan
plugins
komentar
cpu_l3_cache
ora ana
Intel dibutuhake .
Model data kluster (standar): kolektor model data kluster Nova. Cara sing digunakake yaiku migrasi.
Nggarap gol iki liwat Dashboard ora dileksanakake kanthi lengkap ing Queens.
Optimasi termal - ngoptimalake rezim suhu. Suhu Outlet (udhara knalpot) minangka salah sawijining sistem telemetri termal sing penting kanggo ngukur status termal / beban kerja server. Sasaran duwe strategi siji, strategi adhedhasar suhu Outlet, sing mutusake kanggo mindhah beban kerja menyang host sing cocog karo termal (suhu stopkontak paling murah) nalika suhu stopkontak saka host sumber tekan ambang sing bisa dikonfigurasi.
Kanggo strategi bisa, sampeyan kudu server karo Intel Power Node Manager diinstal lan diatur , uga ngumpulake metrik ing ngisor iki:
metrik
layanan
plugins
komentar
hardware.ipmi.node.outlet_temperature
IPMI
Parameter strategi:
paramèter
ketik
kanthi gawan
katrangan
batesan
Panggil
35.0
Ambang suhu kanggo migrasi.
wektu
Panggil
30
Interval wektu, ing detik, kanggo entuk panggabungan statistik saka sumber data metrik.
Cara sing digunakake yaiku migrasi.
Optimisasi Aliran Udara - ngoptimalake mode ventilasi. Strategi dhewe - Aliran Udara Seragam nggunakake migrasi langsung. Strategi kasebut nyebabake migrasi mesin virtual nalika aliran udara saka penggemar server ngluwihi ambang sing ditemtokake.
Kanggo strategi bisa digunakake, sampeyan butuh:
- Hardware: ngitung node < ndhukung NodeManager 3.0;
- Paling ora rong simpul komputasi;
- Komponen ceilometer-agent-compute lan Ceilometer API dipasang lan dikonfigurasi ing saben simpul komputasi, sing bisa kasil nglaporake metrik kayata aliran udara, daya sistem, suhu inlet:
metrik
layanan
plugins
komentar
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Kanggo strategi bisa, sampeyan kudu server karo Intel Power Node Manager 3.0 utawa mengko diinstal lan diatur.
Watesan: Konsep iki ora dimaksudake kanggo produksi.
Disaranake nggunakake algoritma iki kanthi audit terus-terusan, amarga mung siji mesin virtual sing direncanakake bakal migrasi saben pengulangan.
Migrasi langsung bisa.
Parameter strategi:
paramèter
ketik
kanthi gawan
katrangan
threshold_airflow
Panggil
400.0
Ambang aliran udara kanggo Unit migrasi yaiku 0.1CFM
threshold_inlet_t
Panggil
28.0
Ambang suhu mlebu kanggo keputusan migrasi
ambang_daya
Panggil
350.0
Ambang daya sistem kanggo keputusan migrasi
wektu
Panggil
30
Interval wektu, ing detik, kanggo entuk panggabungan statistik saka sumber data metrik.
Cara sing digunakake yaiku migrasi.
Pangopènan piranti keras - pangopènan hardware. Strategi sing ana gandhengane karo tujuan iki yaiku migrasi Zona. Strategi kasebut minangka alat kanggo migrasi mesin lan disk virtual kanthi otomatis lan minimal yen perlu kanggo pangopènan hardware. Strategi mbangun rencana tumindak sing cocog karo bobot: sakumpulan tumindak sing luwih bobot bakal direncanakake sadurunge liyane. Ana rong pilihan konfigurasi: action_weights lan parallelization.
Watesan: bobot tumindak lan paralelisasi kudu dikonfigurasi.
Parameter strategi:
paramèter
ketik
kanthi gawan
katrangan
ngitung_node
Uploaded
Ana
Etung node kanggo migrasi.
storage_pools
Uploaded
Ana
Node panyimpenan kanggo migrasi.
parallel_total
ongko
6
Jumlah total kegiatan sing kudu ditindakake kanthi paralel.
parallel_per_node
ongko
2
Jumlah tumindak sing ditindakake kanthi paralel kanggo saben simpul komputasi.
parallel_per_pool
ongko
2
Jumlah tumindak dileksanakake ing podo karo kanggo saben blumbang panyimpenan.
prioritas
obyek
Ana
Dhaptar prioritas kanggo mesin virtual lan disk.
with_attached_volume
boolean
palsu
Mesin virtual palsu bakal dipindhah sawise kabeh disk wis migrasi. True—mesin virtual bakal dipindhah sawise kabeh disk sing disambungake wis dipindhah.
Elemen saka array node komputasi:
paramèter
ketik
kanthi gawan
katrangan
src_node
senar
Ana
Node komputasi saka ngendi mesin virtual dipindhah (dibutuhake).
dst_node
senar
Ana
Etung simpul sing migrasi mesin virtual.
Unsur susunan simpul panyimpenan:
paramèter
ketik
kanthi gawan
katrangan
src_pool
senar
Ana
Kolam panyimpenan saka ngendi disk dipindhah (dibutuhake).
dst_pool
senar
Ana
Kolam panyimpenan kanggo migrasi disk.
src_type
senar
Ana
Jinis disk asli (dibutuhake).
dst_type
senar
Ana
Jinis disk sing diasilake (dibutuhake).
Unsur prioritas obyek:
paramèter
ketik
kanthi gawan
katrangan
project
Uploaded
Ana
Jeneng proyek.
ngitung_node
Uploaded
Ana
Ngetung jeneng node.
panyimpenan_pool
Uploaded
Ana
Jeneng blumbang panyimpenan.
ngitung
enum
Ana
Parameter mesin virtual ["vcpu_num", "mem_size", "disk_size", "created_at"].
panyimpenan
enum
Ana
Parameter disk ["ukuran", "digawe_ing"].
Cara sing digunakake yaiku migrasi mesin virtual, migrasi disk.
Ora diklasifikasikake - tujuan tambahan sing digunakake kanggo nggampangake proses pangembangan strategi. Ora ana spesifikasi lan bisa digunakake nalika strategi kasebut durung ana gandhengane karo tujuan sing wis ana. Tujuan iki uga bisa digunakake minangka titik transisi. Strategi sing ana gandhengane karo tujuan iki yaiku Actuator.
Nggawe gol anyar
Mesin Keputusan Watcher nduweni antarmuka plugin "tujuan eksternal" sing ndadekake bisa nggabungake tujuan eksternal sing bisa digayuh kanthi nggunakake strategi.
Sadurunge nggawe gol anyar, sampeyan kudu nggawe manawa ora ana target sing cocog karo kabutuhan sampeyan.
Nggawe plugin anyar
Kanggo nggawe target anyar, sampeyan kudu: ngluwihi kelas target, ngleksanakake metode kelas njaluk_jeneng() kanggo ngasilake ID unik saka target anyar sing pengin digawe. Pengenal unik iki kudu cocog karo jeneng titik entri sing sampeyan umumake mengko.
Sabanjure sampeyan kudu ngleksanakake metode kelas njaluk_tampilan_jeneng() kanggo ngasilake jeneng tampilan sing diterjemahake saka target sing pengin digawe (aja nggunakake variabel kanggo ngasilake string sing diterjemahake supaya bisa diklumpukake kanthi otomatis dening alat terjemahan.).
Ngleksanakake metode kelas njaluk_translatable_display_name()kanggo ngasilake kunci terjemahan (sejatine jeneng tampilan basa Inggris) target anyar sampeyan. Nilai bali kudu cocog karo string sing diterjemahake menyang get_display_name().
Ngleksanakake cara dheweke get_efficacy_specification()kanggo ngasilake spesifikasi efisiensi kanggo target sampeyan. Metode get_efficacy_specification () ngasilake conto Unclassified () sing diwenehake dening Watcher. Spesifikasi kinerja iki migunani ing proses ngembangake gol amarga cocog karo spesifikasi kosong.
→
Arsitektur Watcher (luwih rinci) ).
Komponen
Watcher API - komponen sing ngetrapake API REST sing diwenehake dening Watcher. Mekanisme interaksi: CLI, Horizon plugin, Python SDK.
Pengawas DB - Database pengawas.
Watcher Applier - komponen sing ngleksanakake eksekusi rencana aksi sing digawe dening komponen Watcher Decision Engine.
Mesin Keputusan Watcher - Komponen sing tanggung jawab kanggo ngitung sakumpulan tumindak optimasi potensial kanggo nggayuh tujuan audit. Yen strategi ora ditemtokake, komponen kasebut kanthi mandiri milih sing paling cocog.
Penerbit Watcher Metrics - Komponen sing ngumpulake lan ngetung sawetara metrik utawa acara lan nerbitake menyang titik pungkasan CEP. Fungsi komponen uga bisa diwenehake dening penerbit Ceilometer.
Kompleks Event Processing (CEP) Engine - engine kanggo Processing acara Komplek. Kanggo alasan kinerja, bisa uga ana sawetara kedadean CEP Engine mlaku bebarengan, saben ngolah jinis tartamtu saka metrik / acara. Ing sistem Watcher, CEP micu rong jinis tumindak: - nyathet acara / metrik sing relevan ing basis data seri wektu; - ngirim acara cocok kanggo Watcher Decision Engine nalika acara iki bisa mengaruhi asil saka strategi Optimization saiki, wiwit Openstack cluster ora sistem statis.
Komponen interaksi nggunakake protokol AMQP.
→
Skema interaksi karo Watcher
Hasil tes pengamat
- Ing kaca Optimization - Rencana aksi 500 (loro ing Queens murni lan ing stand karo modul Tionix), katon mung sawise audit diluncurake lan rencana aksi digawe; sing kosong mbukak normal.
- Ana kasalahan ing tab rincian Tindakan, iku ora bisa kanggo njaluk goal audit lan strategi (loro ing Queens murni lan ing ngadeg karo modul Tionix).
- Audit kanthi tujuan Dummy (tes) digawe lan diluncurake kanthi normal, rencana tumindak digawe.
- Audit kanggo goal Unclassified ora digawe amarga goal ora fungsi lan dimaksudaké kanggo konfigurasi penengah nalika nggawe strategi anyar.
- Audit kanggo tujuan Workload Balancing (Strategi imbangan Kapasitas Panyimpenan) digawe kanthi sukses, nanging rencana aksi ora digawe. Ora ana optimasi blumbang panyimpenan sing dibutuhake.
- Audit kanggo tujuan Keseimbangan Beban Kerja (Strategi Migrasi Keseimbangan Beban Kerja) digawe kanthi sukses, nanging rencana aksi ora digawe.
- Audit kanggo Workload Balancing (Strategi Stabilisasi Beban Kerja) gagal.
- Audit kanggo target Noisy Neighbor digawe kanthi sukses, nanging rencana aksi ora digawe.
- Audit kanggo tujuan pangopènan Hardware digawe kanthi sukses, rencana aksi ora digawe kanthi lengkap (indikator kinerja digawe, nanging dhaptar tumindak dhewe ora digawe).
- Suntingan ing nova.conf configs (ing bagean gawan compute_monitors = cpu.virt_driver) ing ngitung lan kontrol kelenjar ora mbenerake kasalahan.
- Audit nargetake Konsolidasi Server (Strategi dhasar) uga gagal.
- Audit kanggo tujuan Konsolidasi Server (strategi konsolidasi beban kerja VM) gagal kanthi kesalahan. Ing log ana kesalahan kanggo njupuk data sumber. Diskusi babagan kesalahan, utamane .
Kita nyoba nemtokake Watcher ing file konfigurasi (ora mbantu - minangka asil saka kesalahan ing kabeh kaca Optimasi, bali menyang isi asli file konfigurasi ora mbenerake kahanan): [watcher_strategies.basic] datasource = ceilometer, gnocchi - Audit kanggo Ngirit Energi gagal. Ditilik dening log, masalah isih ora ana Ironic; ora bakal bisa digunakake tanpa layanan baremetal.
- Audit kanggo Optimasi Termal gagal. Traceback padha karo Konsolidasi Server (strategi konsolidasi beban kerja VM) (kesalahan data sumber)
- Audit kanggo tujuan Optimasi Aliran Udara gagal kanthi kesalahan.
Kesalahan rampung audit ing ngisor iki uga ditemokake. Traceback ing log decision-engine.log (negara cluster ora ditetepake).
→ Diskusi babagan kesalahan
kesimpulan
Asil saka riset rong sasi kita ana kesimpulan unequivocal sing kanggo njupuk full-fledged, sistem load balancing, kita kudu, ing bagean iki, bisa rapet kanggo nyaring piranti kanggo platform Openstack.
Watcher wis kabukten minangka produk sing serius lan berkembang kanthi cepet kanthi potensial gedhe, panggunaan lengkap sing mbutuhake kerja serius.
Nanging luwih akeh babagan iki ing artikel seri sabanjure.
Source: www.habr.com