Dalam sistem cloud besar, masalah penyeimbangan otomatis atau pemerataan beban sumber daya komputasi menjadi sangat akut. Tionix (pengembang dan operator layanan cloud, bagian dari grup perusahaan Rostelecom) juga telah menangani masalah ini.
Dan, karena platform pengembangan utama kami adalah Openstack, dan kami, seperti semua orang, malas, diputuskan untuk memilih beberapa modul siap pakai yang sudah disertakan dalam platform. Pilihan kami jatuh pada Watcher, yang kami putuskan untuk digunakan untuk kebutuhan kami.
Pertama, mari kita lihat istilah dan definisinya.
Ketentuan dan definisi
target adalah hasil akhir yang dapat dibaca manusia, dapat diamati dan diukur yang harus dicapai. Ada satu atau lebih strategi untuk mencapai setiap tujuan. Strategi adalah implementasi suatu algoritma yang mampu menemukan solusi untuk tujuan tertentu.
Tindakan adalah tugas dasar yang mengubah keadaan saat ini dari sumber daya target yang dikelola cluster OpenStack, seperti: memigrasikan mesin virtual (migrasi), mengubah keadaan daya sebuah node (change_node_power_state), mengubah keadaan layanan nova (change_nova_service_state ), mengubah rasa (mengubah ukuran), mendaftarkan pesan NOP (nop), kurangnya tindakan untuk jangka waktu tertentu - jeda (tidur), transfer disk (volume_migrate).
Rencana aksi - aliran tindakan tertentu yang dilakukan dalam urutan tertentu untuk mencapai Tujuan tertentu. Rencana Aksi juga memuat kinerja global yang diukur dengan serangkaian indikator kinerja. Rencana tindakan dihasilkan oleh Watcher setelah audit berhasil, sebagai hasilnya strategi yang digunakan menemukan solusi untuk mencapai tujuan. Rencana tindakan terdiri dari daftar tindakan berurutan.
Audit adalah permintaan untuk mengoptimalkan cluster. Optimasi dilakukan untuk mencapai satu Tujuan dalam cluster tertentu. Untuk setiap audit yang berhasil, Watcher membuat Rencana Tindakan.
Ruang Lingkup Audit adalah sekumpulan sumber daya tempat audit dilakukan (zona ketersediaan, agregator node, node komputasi individual atau node penyimpanan, dll.). Ruang lingkup audit ditentukan di setiap templat. Jika tidak ada cakupan audit yang ditentukan, seluruh klaster akan diaudit.
Templat Audit — serangkaian pengaturan tersimpan untuk meluncurkan audit. Templat diperlukan untuk menjalankan audit beberapa kali dengan pengaturan yang sama. Templat harus memuat tujuan audit, jika strategi tidak ditentukan, maka strategi yang ada yang paling sesuai akan dipilih.
Gugus adalah kumpulan mesin fisik yang menyediakan sumber daya komputasi, penyimpanan, dan jaringan dan dikelola oleh node manajemen OpenStack yang sama.
Model Data Klaster (CDM) adalah representasi logis dari keadaan saat ini dan topologi sumber daya yang dikelola oleh cluster.
Indikator Efisiensi - indikator yang menunjukkan bagaimana solusi yang dibuat dengan menggunakan strategi ini dilakukan. Indikator kinerja bersifat spesifik untuk tujuan tertentu dan biasanya digunakan untuk menghitung efektivitas global dari rencana aksi yang dihasilkan.
Spesifikasi Khasiat adalah sekumpulan fitur spesifik yang terkait dengan setiap Sasaran yang mendefinisikan berbagai indikator kinerja yang harus dicapai oleh strategi untuk mencapai Sasaran terkait dalam solusinya. Memang benar, setiap solusi yang diusulkan oleh strategi tersebut akan diperiksa berdasarkan spesifikasinya sebelum menghitung efektivitas globalnya.
Mesin Penilaian adalah file yang dapat dieksekusi yang memiliki masukan terdefinisi dengan baik, keluaran terdefinisi dengan baik, dan melakukan tugas matematika murni. Dengan cara ini, penghitungan tidak bergantung pada lingkungan di mana penghitungan dilakukan—penghitungan akan memberikan hasil yang sama di mana pun.
Perencana Pengamat - bagian dari mesin pengambilan keputusan Watcher. Modul ini mengambil serangkaian tindakan yang dihasilkan oleh strategi dan membuat rencana alur kerja yang menentukan cara menjadwalkan tindakan yang berbeda ini pada waktunya dan untuk setiap tindakan, apa saja prasyaratnya.
Tujuan dan Strategi Pengamat
target
strategi
Tujuan tiruan
Strategi Boneka
Strategi Dummy menggunakan sampel Mesin Penilaian
Strategi tiruan dengan pengubahan ukuran
Menghemat energi
Strategi Penghematan Energi
Konsolidasi Server
Konsolidasi Server Offline Dasar
Strategi Konsolidasi Beban Kerja VM
Penyeimbangan Beban Kerja
Strategi Migrasi Keseimbangan Beban Kerja
Strategi Keseimbangan Kapasitas Penyimpanan
Stabilisasi beban kerja
Tetangga yang berisik
Tetangga yang berisik
Optimasi Termal
Strategi berbasis suhu outlet
Optimasi Aliran Udara
Strategi migrasi aliran udara yang seragam
Perawatan perangkat keras
Migrasi zona
Unclassified
Actuator
Tujuan tiruan — tujuan khusus yang digunakan untuk tujuan pengujian.
Strategi terkait: Strategi Dummy, Strategi Dummy menggunakan sampel Scoring Engines dan strategi Dummy dengan pengubahan ukuran. Strategi dummy adalah strategi dummy yang digunakan untuk pengujian integrasi melalui Tempest. Strategi ini tidak memberikan optimasi yang berguna, satu-satunya tujuan adalah menggunakan tes Tempest.
Strategi dummy menggunakan sample Scoring Engines - strateginya mirip dengan yang sebelumnya, yang membedakan hanya penggunaan sample “scoring engine” yang melakukan perhitungan menggunakan metode machine learning.
Strategi dummy dengan resize - strateginya mirip dengan yang sebelumnya, perbedaannya hanya pada penggunaan perubahan ragam (migrasi dan resize).
Tidak digunakan dalam produksi.
Menghemat energi — meminimalkan konsumsi energi. Strategi Penghematan Energi pada tujuan ini, bersama dengan Strategi Konsolidasi Beban Kerja VM (Konsolidasi Server), mampu menghadirkan fitur manajemen daya dinamis (DPM) yang menghemat energi dengan mengkonsolidasikan beban kerja secara dinamis bahkan selama periode pemanfaatan sumber daya rendah: mesin virtual dipindahkan ke node yang lebih sedikit , dan node yang tidak diperlukan dinonaktifkan. Setelah konsolidasi, strategi ini menawarkan keputusan untuk mengaktifkan/menonaktifkan node sesuai dengan parameter yang ditentukan: “min_free_hosts_num” - jumlah node aktif gratis yang menunggu untuk dimuat, dan “free_used_percent” - persentase host aktif gratis ke jumlah node yang ditempati oleh mesin. Agar strategi berhasil, harus ada mengaktifkan dan mengonfigurasi Ironic untuk menangani perputaran daya pada node.
Parameter strategi
parameter
Ketik
secara default
описание
gratis_bekas_persen
Jumlah
10.0
rasio jumlah node komputasi bebas dengan jumlah node komputasi dengan mesin virtual
min_free_hosts_num
Int
1
jumlah minimum node komputasi bebas
Cloud harus memiliki setidaknya dua node. Metode yang digunakan adalah dengan mengubah status daya node (change_node_power_state). Strategi ini tidak memerlukan pengumpulan metrik.
Konsolidasi Server - meminimalkan jumlah node komputasi (konsolidasi). Strategi ini memiliki dua strategi: Konsolidasi Server Offline Dasar dan Strategi Konsolidasi Beban Kerja VM.
Strategi Konsolidasi Server Offline Dasar meminimalkan jumlah total server yang digunakan dan juga meminimalkan jumlah migrasi.
Strategi dasar memerlukan metrik berikut:
metrik
melayani
plugin
komentar
komputasi.node.cpu.persen
tak satupun
cpu_util
tak satupun
Parameter strategi: migrasi_upaya - jumlah kombinasi untuk mencari kandidat potensial untuk dimatikan (default, 0, tanpa batasan), periode - interval waktu dalam hitungan detik untuk mendapatkan agregasi statis dari sumber data metrik (default, 700).
Metode yang digunakan: migrasi, mengubah status layanan nova (change_nova_service_state).
Strategi Konsolidasi Beban Kerja VM didasarkan pada heuristik first-fit yang berfokus pada pengukuran beban CPU dan berupaya meminimalkan node yang memiliki beban terlalu banyak atau terlalu sedikit mengingat keterbatasan kapasitas sumber daya. Strategi ini memberikan solusi yang menghasilkan penggunaan sumber daya cluster yang lebih efisien dengan menggunakan empat langkah berikut:
- Fase pembongkaran - pemrosesan sumber daya yang digunakan secara berlebihan;
- Fase konsolidasi – menangani sumber daya yang kurang dimanfaatkan;
- Optimalisasi solusi - mengurangi jumlah migrasi;
- Menonaktifkan node komputasi yang tidak digunakan.
Strategi ini memerlukan metrik berikut:
metrik
melayani
plugin
komentar
ingatan
tak satupun
disk.root.ukuran
tak satupun
Metrik berikut bersifat opsional namun akan meningkatkan akurasi strategi jika tersedia:
metrik
melayani
plugin
komentar
memori.residen
tak satupun
cpu_util
tak satupun
Parameter strategi: periode — interval waktu dalam hitungan detik untuk mendapatkan agregasi statis dari sumber data metrik (default, 3600).
Menggunakan metode yang sama seperti strategi sebelumnya. Keterangan lebih lanjut .
Penyeimbangan Beban Kerja — menyeimbangkan beban kerja antar node komputasi. Sasarannya memiliki tiga strategi: Strategi Migrasi Keseimbangan Beban Kerja, Stabilisasi Beban Kerja, Strategi Keseimbangan Kapasitas Penyimpanan.
Strategi Migrasi Keseimbangan Beban Kerja menjalankan migrasi mesin virtual berdasarkan beban kerja mesin virtual host. Keputusan migrasi dibuat setiap kali % penggunaan CPU atau RAM suatu node melebihi ambang batas yang ditentukan. Dalam hal ini, mesin virtual yang dipindahkan harus mendekatkan node ke beban kerja rata-rata semua node.
Persyaratan
- Penggunaan prosesor fisik;
- Setidaknya dua node komputasi fisik;
- Menginstal dan mengonfigurasi komponen Ceilometer - ceilometer-agent-compute, yang berjalan pada setiap node komputasi, dan API Ceilometer, serta mengumpulkan metrik berikut:
metrik
melayani
plugin
komentar
cpu_util
tak satupun
memori.residen
tak satupun
Parameter strategi:
parameter
Ketik
secara default
описание
metrik
Tali
'cpu_util'
Metrik yang mendasarinya adalah: 'cpu_util', 'memory.resident'.
ambang
Jumlah
25.0
Ambang batas beban kerja untuk migrasi.
periode
Jumlah
300
Ceilometer periode waktu kumulatif.
Metode yang digunakan adalah migrasi.
Stabilisasi beban kerja adalah strategi yang bertujuan untuk menstabilkan beban kerja menggunakan migrasi langsung. Strategi ini didasarkan pada algoritma deviasi standar dan menentukan apakah ada kemacetan di cluster dan meresponsnya dengan memicu migrasi mesin untuk menstabilkan cluster.
Persyaratan
- Penggunaan prosesor fisik;
- Setidaknya dua node komputasi fisik;
- Menginstal dan mengonfigurasi komponen Ceilometer - ceilometer-agent-compute, yang berjalan pada setiap node komputasi, dan API Ceilometer, serta mengumpulkan metrik berikut:
metrik
melayani
plugin
komentar
cpu_util
tak satupun
memori.residen
tak satupun
Strategi Keseimbangan Kapasitas Penyimpanan (strategi diterapkan dimulai dengan Queens) - strategi mentransfer disk tergantung pada beban pada kumpulan Cinder. Keputusan transfer dibuat setiap kali tingkat pemanfaatan kumpulan melebihi ambang batas yang ditentukan. Disk yang dipindahkan harus membawa kumpulan lebih dekat ke beban rata-rata semua kumpulan Cinder.
Persyaratan dan batasan
- Minimal dua kolam Cinder;
- Kemungkinan migrasi disk.
- Model data klaster - Pengumpul model data klaster Cinder.
Parameter strategi:
parameter
Ketik
secara default
описание
volume_ambang batas
Jumlah
80.0
Nilai ambang batas disk untuk menyeimbangkan volume.
Metode yang digunakan adalah migrasi disk (volume_migrate).
Noisy Neighbor - Mengidentifikasi dan memigrasikan “noisy neighbour” - mesin virtual berprioritas rendah yang berdampak negatif terhadap kinerja mesin virtual berprioritas tinggi dalam hal IPC dengan menggunakan Last Level Cache secara berlebihan. Strategi sendiri: Noisy Neighbor (parameter strategi yang digunakan adalah cache_threshold (nilai default adalah 35), ketika kinerja turun ke nilai yang ditentukan, migrasi dimulai. Agar strategi berfungsi, aktifkan Metrik LLC (Cache Tingkat Terakhir), server Intel terbaru dengan dukungan CMT, serta mengumpulkan metrik berikut:
metrik
melayani
plugin
komentar
cpu_l3_cache
tak satupun
Diperlukan Intel .
Model data klaster (default): Pengumpul model data klaster Nova. Metode yang digunakan adalah migrasi.
Upaya mencapai tujuan ini melalui Dasbor tidak sepenuhnya diterapkan di Queens.
Optimasi Termal — mengoptimalkan rezim suhu. Suhu keluar (udara buang) adalah salah satu sistem telemetri termal yang penting untuk mengukur status termal/beban kerja server. Target memiliki satu strategi, strategi berbasis suhu outlet, yang memutuskan untuk memigrasikan beban kerja ke host yang secara termal menguntungkan (suhu outlet terendah) ketika suhu outlet host sumber mencapai ambang batas yang dapat dikonfigurasi.
Agar strategi ini berhasil, Anda memerlukan server dengan Intel Power Node Manager yang terinstal dan dikonfigurasi , serta mengumpulkan metrik berikut:
metrik
melayani
plugin
komentar
perangkat keras.ipmi.node.outlet_temperature
IPMI
Parameter strategi:
parameter
Ketik
secara default
описание
ambang
Jumlah
35.0
Ambang batas suhu untuk migrasi.
periode
Jumlah
30
Interval waktu, dalam detik, untuk memperoleh agregasi statistik dari sumber data metrik.
Metode yang digunakan adalah migrasi.
Optimasi Aliran Udara — mengoptimalkan mode ventilasi. Strateginya sendiri - Uniform Airflow menggunakan migrasi langsung. Strategi ini memicu migrasi mesin virtual setiap kali aliran udara dari kipas server melebihi ambang batas yang ditentukan.
Agar strategi berhasil, Anda memerlukan:
- Perangkat keras: menghitung node <mendukung NodeManager 3.0;
- Setidaknya dua node komputasi;
- Komponen ceilometer-agent-compute dan Ceilometer API diinstal dan dikonfigurasi pada setiap node komputasi, yang berhasil melaporkan metrik seperti aliran udara, daya sistem, suhu masuk:
metrik
melayani
plugin
komentar
perangkat keras.ipmi.node.aliran udara
IPMI
perangkat keras.ipmi.node.temperature
IPMI
perangkat keras.ipmi.node.power
IPMI
Agar strategi ini berhasil, Anda memerlukan server dengan Intel Power Node Manager 3.0 atau lebih baru yang terinstal dan dikonfigurasi.
Keterbatasan: Konsep ini tidak dimaksudkan untuk produksi.
Diusulkan untuk menggunakan algoritma ini dengan audit berkelanjutan, karena hanya satu mesin virtual yang direncanakan untuk dimigrasi per iterasi.
Migrasi langsung dimungkinkan.
Parameter strategi:
parameter
Ketik
secara default
описание
ambang batas_aliran udara
Jumlah
400.0
Ambang batas aliran udara untuk Unit migrasi adalah 0.1CFM
ambang batas_masuk_t
Jumlah
28.0
Ambang batas suhu masuk untuk keputusan migrasi
ambang batas_daya
Jumlah
350.0
Ambang batas kekuatan sistem untuk keputusan migrasi
periode
Jumlah
30
Interval waktu, dalam detik, untuk memperoleh agregasi statistik dari sumber data metrik.
Metode yang digunakan adalah migrasi.
Pemeliharaan Perangkat Keras — pemeliharaan perangkat keras. Strategi yang terkait dengan tujuan ini adalah migrasi Zona. Strategi ini adalah alat untuk migrasi mesin virtual dan disk secara otomatis dan minimal jika diperlukan pemeliharaan perangkat keras. Strategi membangun rencana tindakan sesuai dengan bobotnya: serangkaian tindakan yang memiliki bobot lebih akan direncanakan sebelum tindakan lainnya. Ada dua opsi konfigurasi: action_weights dan paralelisasi.
Keterbatasan: bobot tindakan dan paralelisasi perlu dikonfigurasi.
Parameter strategi:
parameter
Ketik
secara default
описание
komputasi_node
susunan
None
Hitung node untuk migrasi.
penyimpanan_kolam
susunan
None
Node penyimpanan untuk migrasi.
paralel_total
bilangan bulat
6
Jumlah total kegiatan yang harus dilaksanakan secara paralel.
paralel_per_node
bilangan bulat
2
Jumlah tindakan yang dilakukan secara paralel untuk setiap node komputasi.
parallel_per_pool
bilangan bulat
2
Jumlah tindakan yang dilakukan secara paralel untuk setiap kumpulan penyimpanan.
prioritas
obyek
None
Daftar prioritas untuk mesin virtual dan disk.
dengan_terlampir_volume
boolean
Salah
Salah—mesin virtual akan dimigrasikan setelah semua disk dimigrasi. Benar—mesin virtual akan dimigrasikan setelah semua disk yang terhubung telah dimigrasi.
Elemen array node komputasi:
parameter
Ketik
secara default
описание
src_node
tali
None
Node komputasi tempat mesin virtual dimigrasikan (wajib).
dst_node
tali
None
Hitung node tujuan migrasi mesin virtual.
Elemen array simpul penyimpanan:
parameter
Ketik
secara default
описание
src_pool
tali
None
Kumpulan penyimpanan tempat disk dimigrasikan (wajib).
dst_pool
tali
None
Kumpulan penyimpanan tempat disk dimigrasikan.
src_type
tali
None
Jenis disk asli (wajib).
dst_type
tali
None
Jenis disk yang dihasilkan (wajib).
Elemen prioritas objek:
parameter
Ketik
secara default
описание
proyek
susunan
None
Nama proyek.
komputasi_node
susunan
None
Hitung nama node.
penyimpanan_kumpulan
susunan
None
Nama kumpulan penyimpanan.
menghitung
enum
None
Parameter mesin virtual ["vcpu_num", "mem_size", "disk_size", "created_at"].
penyimpanan
enum
None
Parameter disk ["ukuran", "dibuat_at"].
Metode yang digunakan adalah migrasi mesin virtual, migrasi disk.
Unclassified - tujuan tambahan yang digunakan untuk memfasilitasi proses pengembangan strategi. Tidak mengandung spesifikasi dan dapat digunakan kapan pun strategi tersebut belum dikaitkan dengan tujuan yang ada. Tujuan ini juga dapat dijadikan titik transisi. Strategi yang terkait dengan tujuan ini adalah Aktuator.
Menciptakan tujuan baru
Mesin Keputusan Pengamat memiliki antarmuka plugin “tujuan eksternal” yang memungkinkan untuk mengintegrasikan tujuan eksternal yang dapat dicapai dengan menggunakan strategi.
Sebelum membuat sasaran baru, Anda harus memastikan bahwa tidak ada sasaran yang ada yang memenuhi kebutuhan Anda.
Membuat plugin baru
Untuk membuat target baru, Anda harus: memperluas kelas target, mengimplementasikan metode kelas dapatkan_nama() untuk mengembalikan ID unik dari target baru yang ingin Anda buat. Pengidentifikasi unik ini harus sesuai dengan nama titik masuk yang Anda deklarasikan nanti.
Selanjutnya Anda perlu mengimplementasikan metode kelas dapatkan_nama_tampilan() untuk mengembalikan nama tampilan terjemahan dari target yang ingin Anda buat (jangan gunakan variabel untuk mengembalikan string yang diterjemahkan sehingga dapat dikumpulkan secara otomatis oleh alat terjemahan.).
Menerapkan metode kelas get_translatable_display_name()untuk mengembalikan kunci terjemahan (sebenarnya nama tampilan bahasa Inggris) dari target baru Anda. Nilai yang dikembalikan harus cocok dengan string yang diterjemahkan ke dalam get_display_name().
Terapkan metodenya dapatkan_kemanjuran_spesifikasi()untuk mengembalikan spesifikasi efisiensi untuk target Anda. Metode get_efisiensi_spesifikasi() mengembalikan instance Unclassified() yang disediakan oleh Watcher. Spesifikasi kinerja ini berguna dalam proses pengembangan tujuan Anda karena sesuai dengan spesifikasi yang kosong.
→
Arsitektur pengamat (lebih detail) ).
Komponen
API Pengamat - komponen yang mengimplementasikan REST API yang disediakan oleh Watcher. Mekanisme interaksi: CLI, plugin Horizon, Python SDK.
Pengamat DB — Basis data pengamat.
Penerapan Pengamat — komponen yang mengimplementasikan pelaksanaan rencana tindakan yang dibuat oleh komponen Watcher Decision Engine.
Mesin Keputusan Pengamat - Komponen yang bertanggung jawab menghitung serangkaian tindakan pengoptimalan potensial untuk mencapai tujuan audit. Jika suatu strategi tidak ditentukan, komponen secara independen memilih strategi yang paling tepat.
Penerbit Metrik Pengamat - Komponen yang mengumpulkan dan menghitung beberapa metrik atau peristiwa dan mempublikasikannya ke titik akhir CEP. Fungsionalitas komponen juga dapat disediakan oleh penerbit Ceilometer.
Mesin Pemrosesan Peristiwa Kompleks (CEP). — mesin untuk pemrosesan acara yang kompleks. Untuk alasan performa, mungkin ada beberapa instance Mesin CEP yang berjalan secara bersamaan, masing-masing memproses jenis metrik/peristiwa tertentu. Dalam sistem Watcher, CEP memicu dua jenis tindakan: - mencatat peristiwa/metrik terkait dalam database deret waktu; - mengirimkan kejadian yang sesuai ke Watcher Decision Engine ketika kejadian ini dapat mempengaruhi hasil strategi optimasi saat ini, karena cluster Openstack bukanlah sistem statis.
Komponen berinteraksi menggunakan protokol AMQP.
→
Skema interaksi dengan Watcher
Hasil tes pengamat
- Pada halaman Optimasi - Rencana Aksi 500 (baik pada Queens murni maupun pada stand dengan modul Tionix), halaman tersebut hanya muncul setelah audit diluncurkan dan rencana aksi dibuat; yang kosong terbuka secara normal.
- Ada kesalahan pada tab Detail tindakan, tidak mungkin mendapatkan tujuan dan strategi audit (baik pada Queens murni maupun pada stand dengan modul Tionix).
- Audit dengan tujuan Dummy (pengujian) dibuat dan diluncurkan secara normal, rencana tindakan dihasilkan.
- Audit untuk sasaran Tidak Terklasifikasi tidak dibuat karena sasaran tersebut tidak berfungsi dan dimaksudkan untuk konfigurasi perantara saat membuat strategi baru.
- Audit untuk tujuan Penyeimbangan Beban Kerja (strategi keseimbangan Kapasitas Penyimpanan) berhasil dibuat, namun rencana tindakan tidak dihasilkan. Tidak diperlukan pengoptimalan kumpulan penyimpanan.
- Audit untuk tujuan Penyeimbangan Beban Kerja (Strategi Migrasi Keseimbangan Beban Kerja) berhasil dibuat, namun rencana tindakan tidak dibuat.
- Audit untuk Penyeimbangan Beban Kerja (Strategi Stabilisasi Beban Kerja) gagal.
- Audit untuk target Noisy Neighbor berhasil dibuat, namun rencana tindakan tidak dibuat.
- Audit untuk tujuan pemeliharaan Perangkat Keras berhasil dibuat, rencana tindakan tidak dibuat secara lengkap (indikator kinerja dibuat, namun daftar tindakan itu sendiri tidak dibuat).
- Pengeditan pada konfigurasi nova.conf (di bagian default compute_monitors = cpu.virt_driver) pada node komputasi dan kontrol tidak memperbaiki kesalahan.
- Audit yang menargetkan Konsolidasi Server (Strategi dasar) juga gagal.
- Audit untuk tujuan Konsolidasi Server (strategi konsolidasi beban kerja VM) gagal karena kesalahan. Ada kesalahan dalam memperoleh data awal di log. Diskusi tentang kesalahan, khususnya .
Kami mencoba menentukan Watcher di file konfigurasi (tidak membantu - karena kesalahan pada semua halaman Optimasi, kembali ke konten asli file konfigurasi tidak memperbaiki situasi): [watcher_strategies.basic] sumber data = ceilometer, gnocchi - Audit untuk Penghematan Energi gagal. Dilihat dari log, masalahnya masih belum adanya Ironic; itu tidak akan berfungsi tanpa layanan baremetal.
- Audit untuk Optimasi Termal gagal. Pelacakan baliknya sama seperti untuk Konsolidasi Server (strategi konsolidasi beban kerja VM) (kesalahan data sumber)
- Audit untuk tujuan Pengoptimalan Aliran Udara gagal karena kesalahan.
Kesalahan penyelesaian audit berikut juga ditemui. Traceback di log Decision-engine.log (status cluster tidak ditentukan).
→ Diskusi kesalahan
Kesimpulan
Hasil dari penelitian kami selama dua bulan adalah kesimpulan yang jelas bahwa untuk mendapatkan sistem penyeimbangan beban yang berfungsi penuh, pada bagian ini, kami harus bekerja sama untuk menyempurnakan alat untuk platform Openstack.
Watcher telah terbukti menjadi produk yang serius dan berkembang pesat dengan potensi yang sangat besar, yang penggunaan penuhnya akan memerlukan banyak kerja serius.
Namun lebih lanjut tentang ini di artikel seri berikutnya.
Sumber: www.habr.com