Openstack Load Balancing

Dalam sistem cloud yang besar, masalah penyeimbangan otomatis atau penyeimbangan beban pada sumber daya komputasi sangat akut. Orang Tionghoa juga menangani masalah ini (pengembang dan operator layanan cloud, kami adalah bagian dari grup perusahaan Rostelecom).

Dan, karena platform pengembangan utama kami adalah Openstack, dan kami, seperti semua orang, malas, diputuskan untuk mengambil semacam modul siap pakai yang sudah menjadi bagian dari platform. Pilihan kami jatuh pada Watcher, yang kami putuskan untuk digunakan untuk kebutuhan kami.

Pertama, mari kita berurusan dengan istilah dan definisi.

Ketentuan dan definisi

Tujuan adalah hasil akhir yang dapat dibaca, diamati, dan diukur manusia yang harus dicapai. Untuk mencapai setiap tujuan, ada satu atau lebih strategi. Strategi adalah implementasi dari algoritma yang mampu menemukan solusi untuk tujuan tertentu.

Tindakan adalah tugas dasar yang mengubah keadaan saat ini dari sumber daya yang dikelola target dari klaster OpenStack, seperti: memigrasi mesin virtual (migrasi), mengubah status kekuatan sebuah simpul (change_node_power_state), mengubah status layanan nova (change_nova_service_state), mengubah rasa (mengubah ukuran) , mendaftarkan pesan NOP (nop), tidak adanya tindakan untuk jangka waktu tertentu - jeda (tidur), transfer disk (volume_migrate).

Rencana Tindakan (Action Plan) - aliran tindakan tertentu yang dilakukan dalam urutan tertentu untuk mencapai Tujuan tertentu. Rencana aksi juga memuat perkiraan kinerja global dengan seperangkat indikator kinerja. Rencana tindakan dihasilkan oleh Watcher setelah audit yang berhasil, akibatnya strategi yang digunakan menemukan solusi untuk mencapai tujuan. Rencana tindakan terdiri dari daftar tindakan berurutan.

Audit adalah permintaan untuk optimasi cluster. Optimalisasi dilakukan untuk mencapai satu tujuan dalam kluster yang diberikan. Untuk setiap audit yang berhasil, Watcher membuat Rencana Tindakan.

Lingkup Audit adalah seperangkat sumber daya di mana audit dilakukan (zona ketersediaan, agregator node, node komputasi individual atau node penyimpanan, dll.). Lingkup audit didefinisikan dalam setiap templat. Jika ruang lingkup audit tidak ditentukan, seluruh cluster diaudit.

Template Audit - Kumpulan pengaturan yang tersimpan untuk memulai audit. Templat diperlukan untuk menjalankan audit dengan pengaturan yang sama beberapa kali. Template harus mengandung tujuan audit, jika strategi tidak diindikasikan, maka strategi yang paling sesuai yang ada dipilih.

Cluster adalah seperangkat mesin fisik yang menyediakan sumber daya komputasi, penyimpanan, dan jaringan dan dikelola oleh node kontrol OpenStack yang sama.

Cluster Data Model (CDM) adalah representasi logis dari keadaan saat ini dan topologi sumber daya yang dikelola cluster.

Indikator Efisiensi (Indikator Efisiensi) - indikator yang menunjukkan bagaimana solusi yang dibuat menggunakan strategi ini diimplementasikan. Indikator kinerja khusus untuk tujuan tertentu dan biasanya digunakan untuk menghitung efektivitas global dari rencana aksi final.

Spesifikasi Khasiat adalah seperangkat fitur spesifik yang terkait dengan setiap Sasaran, yang mendefinisikan berbagai indikator kinerja yang harus disediakan oleh strategi yang memastikan pencapaian tujuan yang sesuai dalam keputusannya. Memang, setiap solusi yang diusulkan oleh strategi akan diperiksa untuk kesesuaian dengan spesifikasi sebelum menghitung efektivitas globalnya.

"Mesin skoring" adalah file yang dapat dieksekusi yang memiliki input yang terdefinisi dengan baik, output yang terdefinisi dengan baik, dan melakukan tugas matematika murni. Jadi, perhitungan tidak tergantung pada lingkungan di mana ia dilakukan - itu akan memberikan hasil yang sama di mana saja.

Watcher Planner adalah bagian dari mesin pengambilan keputusan Watcher. Modul ini menerima serangkaian tindakan yang dihasilkan oleh strategi dan membuat rencana alur kerja yang mendefinisikan bagaimana merencanakan berbagai tindakan ini dalam waktu dan untuk setiap tindakan, apa saja prasyaratnya.

Tujuan dan Strategi Pengamat

Sasaran dummy - sasaran cadangan yang digunakan untuk tujuan pengujian.

Strategi terkait: Strategi Dummy, Strategi Dummy menggunakan mesin Scoring sampel 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, tujuan utamanya adalah untuk menggunakan tes Tempest.

Strategi boneka menggunakan sampel Mesin Pencetak - strategi ini mirip dengan yang sebelumnya, hanya berbeda dalam penggunaan sampel "mesin evaluasi", yang melakukan perhitungan menggunakan metode pembelajaran mesin.

Strategi boneka dengan ukuran - strategi ini mirip dengan yang sebelumnya, hanya berbeda dalam penggunaan mengubah rasa (migrasi dan mengubah ukuran).

Tidak digunakan dalam produksi.

Hemat Energi - meminimalkan konsumsi energi. Strategi untuk tujuan ini. Menyimpan Strategi Energi bersamaan dengan Strategi Konsolidasi Beban Kerja VM (Konsolidasi Server) mampu melakukan fungsi manajemen daya dinamis (DPM), yang menghemat energi dengan secara dinamis mengkonsolidasikan beban kerja bahkan selama periode beban sumber daya rendah: mesin virtual ditransfer ke node yang lebih sedikit: , dan node yang tidak perlu terputus. Setelah konsolidasi, strategi menawarkan keputusan untuk menghidupkan / mematikan node sesuai dengan parameter yang diberikan: "min_free_hosts_num" - jumlah node yang disertakan gratis yang menunggu untuk dimuat, dan "free_used_percent" - persentase node yang disertakan gratis ke jumlah node yang ditempati oleh mesin. Agar strategi berjalan, Ironic harus dihidupkan dan dikonfigurasikan untuk bekerja dengan power on / off pada node.

Opsi Strategi

Harus ada setidaknya dua node di cloud. Metode yang digunakan adalah mengubah status daya simpul (change_node_power_state). Strategi tidak memerlukan kumpulan metrik.

Konsolidasi Server - meminimalkan jumlah node komputasi (konsolidasi). 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 membutuhkan metrik berikut:


Parameter strategi: migrasi_attempts - jumlah kombinasi untuk mencari kandidat shutdown potensial (default, 0, tanpa batasan), interval periode-waktu dalam detik untuk mendapatkan agregasi statis dari sumber data metrik (700 secara default).

Metode yang digunakan: migrasi, perubahan status layanan nova (change_nova_service_state).

Strategi Konsolidasi Beban Kerja VM didasarkan pada algoritma heuristik fit pertama, yang berfokus pada beban CPU yang diukur dan mencoba untuk meminimalkan node yang memiliki terlalu banyak atau terlalu sedikit beban, dengan mempertimbangkan keterbatasan kapasitas sumber daya. Strategi ini memberikan solusi yang mengarah pada penggunaan sumber daya klaster yang lebih efisien menggunakan empat langkah berikut:

1. Fase bongkar - pemrosesan sumber daya yang digunakan secara berlebihan;
2. Fase konsolidasi - pemrosesan sumber daya yang kurang dimanfaatkan;
3. Optimalisasi solusi - mengurangi jumlah migrasi;
4. Menonaktifkan node komputasi yang tidak digunakan.

Strategi ini membutuhkan metrik berikut:


Metrik berikut bersifat opsional, tetapi tingkatkan akurasi strategi jika tersedia:

Parameter strategi: interval periode - waktu dalam detik untuk mendapatkan agregasi statis dari sumber data metrik (3600 secara default).

Menggunakan metode yang sama dengan strategi sebelumnya. Lebih detail di sini .

Penyeimbangan Beban Kerja - menyeimbangkan beban kerja antara node komputasi. Tujuannya memiliki tiga strategi: Strategi Migrasi Keseimbangan Beban Kerja, stabilisasi beban kerja, Strategi Keseimbangan Kapasitas Penyimpanan.

Strategi Migrasi Saldo Beban Kerja meluncurkan migrasi mesin virtual berdasarkan beban kerja mesin virtual host. Keputusan untuk mentransfer dibuat setiap kali% utilisasi CPU atau RAM dari node melebihi ambang yang ditentukan. Dalam hal ini, mesin virtual yang dipindahkan harus membawa node lebih dekat ke beban kerja rata-rata semua node.

Persyaratan

• Penggunaan prosesor fisik;
• Setidaknya dua node komputasi fisik;
• Komponen Ceilometer yang diinstal dan dikonfigurasi adalah ceilometer-agent-compute yang bekerja pada setiap node komputasi, dan Ceilometer API, serta mengumpulkan metrik berikut:

Opsi Strategi:

Metode yang digunakan adalah migrasi.

Stabilisasi beban kerja - 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;
• Komponen Ceilometer yang diinstal dan dikonfigurasi adalah ceilometer-agent-compute yang bekerja pada setiap node komputasi, dan Ceilometer API, serta mengumpulkan metrik berikut:

Strategi Keseimbangan Kapasitas Penyimpanan (strategi yang diterapkan sejak Queens) - strategi mentransfer disk tergantung pada beban kumpulan Cinder. Keputusan transfer dibuat setiap kali penggunaan kumpulan melebihi ambang yang ditentukan. Disk jelajah harus membawa kolam lebih dekat ke beban rata-rata semua kolam Cinder.

Persyaratan dan Batasan

• Setidaknya dua kolam Cinder;
• Kemampuan untuk memigrasi disk.
• Kolektor model data cluster.

Opsi Strategi:


Metode yang digunakan adalah migrasi disk (volume_migrate).

Noisy Neighbor - mengidentifikasi dan memigrasi "tetangga berisik" - mesin virtual prioritas rendah yang mempengaruhi kinerja mesin virtual prioritas tinggi dari sudut pandang IPC, menggunakan Cache Level Terakhir. Strategi sendiri: Noisy Neighbor (parameter strategi yang digunakan adalah cache_threshold (nilai default adalah 35), migrasi dimulai ketika kinerja turun ke nilai yang ditentukan. Untuk strategi untuk bekerja, metrik LLC (Cache Level Terakhir) yang disertakan , server Intel terbaru dengan dukungan CMT , dan juga koleksi metrik berikut:

Model data cluster (default): Kolektor model data data cluster. Metode yang diterapkan adalah migrasi.

Bekerja untuk tujuan ini melalui Dashboard tidak sepenuhnya diimplementasikan di Queens.

Optimalisasi Termal - mengoptimalkan kondisi suhu. Temperatur outlet (udara buang) adalah salah satu sistem telemetri termal yang penting untuk mengukur keadaan termal / beban kerja server. Untuk tujuan tersebut, ada satu strategi - Strategi berbasis suhu outlet, yang membuat keputusan untuk mentransfer beban kerja ke node dengan kondisi suhu yang menguntungkan (suhu terendah saat keluar) ketika suhu pada output host asli mencapai ambang custom.

Agar strategi dapat berfungsi, Anda memerlukan server dengan Intel Power Node Manager 3.0 atau yang lebih baru yang diinstal dan dikonfigurasi, serta kumpulan metrik berikut:

Opsi Strategi:

Metode yang digunakan adalah migrasi.

Optimalisasi Aliran Udara - optimalkan mode ventilasi. Strategi sendiri - Aliran Udara Seragam menggunakan migrasi langsung. Strategi memulai migrasi mesin virtual setiap kali aliran udara dari kipas server melebihi ambang yang ditentukan.

Agar berhasil, strateginya membutuhkan:

• Perangkat keras: menghitung node <dengan dukungan NodeManager 3.0;
• Setidaknya dua node komputasi;
• Komponen ceilometer-agent-compute dan Ceilometer API yang dipasang dan dikonfigurasikan pada setiap node komputasi dapat berhasil melaporkan metrik seperti aliran udara, daya sistem, dan suhu saluran masuk:

Agar strategi berjalan, Anda memerlukan server dengan Intel Power Node Manager 3.0 atau yang lebih baru yang diinstal dan dikonfigurasi.

Keterbatasan: Konsep ini tidak dimaksudkan untuk produksi.

Diusulkan untuk menggunakan algoritma ini dengan audit kontinu, karena hanya satu mesin virtual yang direncanakan akan dimigrasi per iterasi.

Migrasi langsung dimungkinkan.

Opsi Strategi:

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 otomatis yang efisien dan minimal mesin dan disk virtual jika terjadi pemeliharaan perangkat keras. Strategi membangun rencana tindakan sesuai dengan bobot: satu set tindakan yang memiliki bobot lebih akan direncanakan di depan yang lain. Ada dua opsi konfigurasi: bobot tindakan (action_weights) dan paralelisasi.

Keterbatasan: perlu untuk menyesuaikan bobot tindakan dan paralelisasi.

Opsi Strategi:

Elemen-elemen array node komputasi:

Elemen array node penyimpanan:

Elemen objek prioritas:

Metode yang digunakan - migrasi mesin virtual, migrasi disk.

Unclassified adalah tujuan pendukung yang digunakan untuk memfasilitasi pengembangan strategi. Itu tidak mengandung spesifikasi dan dapat digunakan kapan pun strategi belum terhubung dengan tujuan yang ada. Tujuan ini juga dapat digunakan sebagai tahap transisi. Strategi terkait adalah Aktuator.

Buat tujuan baru

Watcher Decision Engine memiliki antarmuka plug-in "tujuan eksternal" yang memungkinkan Anda untuk mengintegrasikan tujuan eksternal yang dapat dicapai menggunakan strategi.

Sebelum membuat tujuan baru, Anda harus memastikan bahwa tidak ada tujuan yang ada memenuhi kebutuhan Anda.

Buat plugin baru

Untuk membuat target baru, Anda harus: memperluas kelas target, menerapkan metode kelas get_name () untuk mengembalikan pengidentifikasi unik untuk target baru yang ingin Anda buat. Pengidentifikasi unik ini harus cocok dengan nama titik masuk yang Anda nyatakan nanti.

Selanjutnya, Anda perlu menerapkan metode kelas get_display_name () untuk mengembalikan nama tampilan yang diterjemahkan dari target yang ingin Anda buat (jangan gunakan variabel untuk mengembalikan string yang diterjemahkan sehingga dapat dikumpulkan secara otomatis oleh alat terjemahan.).

Terapkan metode kelas get_translate_display_name () untuk mengembalikan kunci terjemahan (sebenarnya nama tampilan bahasa Inggris) dari target baru Anda. Nilai kembali harus cocok dengan string yang diterjemahkan ke dalam get_display_name ().

Terapkan metode get_efficacy_specification () untuk mengembalikan spesifikasi kinerja untuk tujuan Anda. Metode get_efficacy_specification () mengembalikan instance Unclassified () yang disediakan oleh Watcher. Spesifikasi kinerja ini berguna dalam proses mengembangkan tujuan Anda karena memenuhi spesifikasi kosong.

→ Lebih detail di sini

Pengamat Arsitektur (info lebih lanjut di sini ).

Komponen

API Watcher - komponen yang mengimplementasikan REST API yang disediakan oleh Watcher. Mekanisme interaksi: CLI, plugin Horizon, Python SDK.

Watcher DB - database Watcher.

Watcher Applier - komponen yang mengimplementasikan implementasi rencana aksi yang dibuat oleh komponen Watcher Decision Engine.

Watcher Decision Engine adalah komponen yang bertanggung jawab untuk menghitung serangkaian tindakan optimisasi potensial untuk memenuhi tujuan audit. Jika strategi tidak ditentukan, komponen secara mandiri memilih yang paling cocok.

Penerbit Metrik Penerbit adalah komponen yang mengumpulkan dan menghitung beberapa metrik atau peristiwa dan menerbitkannya di titik akhir CEP. Fungsionalitas fitur juga dapat disediakan oleh penerbit Ceilometer.

Mesin Pemroses Kejadian Kompleks (CEP)- Mesin untuk pemrosesan acara yang kompleks. Untuk alasan kinerja, mungkin ada beberapa contoh Mesin CEP berjalan pada saat yang sama, masing-masing menangani jenis metrik / peristiwa tertentu. Dalam sistem Watcher, CEP meluncurkan dua jenis tindakan: - menulis peristiwa / metrik yang sesuai ke basis data deret waktu; - mengirim peristiwa yang relevan ke komponen Mesin Pengamat Pengamat ketika peristiwa ini dapat memengaruhi hasil strategi pengoptimalan saat ini, karena klaster Openstack bukan sistem statis.

Interaksi komponen dilakukan sesuai dengan protokol AMQP.

→ Mengkonfigurasi Pengamat

Skema interaksi dengan Watcher

Hasil Tes Pengamat

1. Optimization — Action plans 500 ( Queens, ), , , .
2. Action details , ( Queens, ).
3. Dummy () , .
4. Unclassified , .
5. Workload Balancing ( Storage Capacity balance) , . .
6. Workload Balancing ( Workload Balance Migration Strategy) , .
7. Workload Balancing ( Workload Stabilization Strategy) .
8. Noisy Neighbor , .
9. Hardware maintenance , ( , ).
10. nova.conf ( default compute_monitors = cpu.virt_driver) .
11. Server Consolidation ( Basic) .
12. Server Consolidation ( VM workload consolidation) . . , , .
    - Watcher ( — Optimization, - ):
    
    [watcher_strategies.basic]
    datasource = ceilometer, gnocchi
13. Saving Energy . , - Ironic, baremetal service.
14. Thermal Optimization . , Server Consolidation ( VM workload consolidation) ( )
15. Audit untuk Optimasi Aliran Udara gagal.

Kesalahan penyelesaian audit berikut juga ditemukan. Traceback di log decision-engine.log (status cluster tidak ditentukan).

→ Diskusi kesalahan di sini

Kesimpulan

Hasil dari penelitian dua bulan kami adalah kesimpulan yang jelas bahwa untuk mendapatkan sistem penyeimbangan beban kerja yang lengkap, kami harus bekerja erat dalam menyelesaikan alat untuk platform Openstack.

Watcher telah membuktikan dirinya sebagai produk yang serius dan berkembang pesat dengan potensi yang sangat besar, untuk penggunaan penuh yang membutuhkan banyak pekerjaan serius.

Tetapi lebih banyak tentang itu di artikel siklus berikutnya.