Openstack Load Balancing (Bagian 2)

Dalam artikel sebelumnya, kami berbicara tentang mencoba menggunakan Watcher dan menyajikan laporan pengujian. Kami secara berkala melakukan pengujian tersebut untuk menyeimbangkan dan fungsi penting lainnya dari cloud perusahaan atau operator besar.

Kompleksitas tinggi dari masalah yang sedang diselesaikan mungkin memerlukan beberapa artikel untuk menggambarkan proyek kami. Hari ini kami menerbitkan artikel kedua dalam seri tentang menyeimbangkan mesin virtual di cloud.

Beberapa terminologi

VmWare telah memperkenalkan utilitas DRS (Distributed Resource Scheduler) untuk menyeimbangkan beban lingkungan virtualisasi mereka.

Seperti searchvmware.techtarget.com/definition/VMware-DRS menulis
“VMware DRS (Distributed Resource Scheduler) adalah utilitas yang menyeimbangkan beban komputasi dengan sumber daya yang tersedia di lingkungan virtual. Utilitas adalah bagian dari paket virtualisasi yang disebut Infrastruktur VMware.

Dengan menggunakan VMware DRS, pengguna menetapkan aturan untuk mendistribusikan sumber daya fisik antara mesin virtual (VM). Utilitas dapat dikonfigurasi untuk kontrol manual atau otomatis. Kumpulan sumber daya VMware dapat dengan mudah ditambahkan, dihapus atau direorganisasi. Jika diinginkan, kumpulan sumber daya dapat diisolasi antara unit bisnis yang berbeda. Jika beban kerja dari satu atau lebih mesin virtual berubah secara dramatis, VMware DRS mendistribusikan ulang mesin virtual antara server fisik. Jika keseluruhan beban kerja berkurang, beberapa server fisik mungkin sementara turun dan beban kerja dikonsolidasikan. "

Mengapa saya perlu menyeimbangkan?

Menurut pendapat kami, DRS adalah fitur yang sangat diperlukan dari cloud, meskipun ini tidak berarti bahwa DRS harus digunakan kapan saja, di mana saja. Bergantung pada tujuan dan kebutuhan cloud, mungkin ada persyaratan berbeda untuk DRS dan metode penyeimbangan. Mungkin ada situasi di mana keseimbangan tidak diperlukan sama sekali. Atau bahkan berbahaya.

Untuk lebih memahami di mana dan di mana klien DRS dibutuhkan, pertimbangkan tujuan dan sasaran mereka. Awan dapat dibagi menjadi publik dan pribadi. Berikut adalah perbedaan utama antara cloud dan tujuan pelanggan ini.

Kami menarik kesimpulan berikut untuk diri kita sendiri:

Untuk cloud pribadi yang disediakan untuk pelanggan korporat besar, DRS dapat diterapkan dengan batasan:

• keamanan informasi dan aturan afinitas akuntansi untuk penyeimbangan;
• ketersediaan sumber daya dalam jumlah yang cukup jika terjadi kecelakaan;
• data mesin virtual berada pada sistem penyimpanan terpusat atau terdistribusi;
• keragaman waktu administrasi, cadangan dan menyeimbangkan prosedur;
• menyeimbangkan hanya dalam agregat host klien;
• hanya menyeimbangkan dengan ketidakseimbangan yang kuat, migrasi VM yang paling efisien dan aman (bagaimanapun, migrasi bisa gagal);
• menyeimbangkan mesin virtual yang relatif “sunyi” (migrasi mesin virtual “berisik” dapat memakan waktu sangat lama);
• menyeimbangkan dengan mempertimbangkan "biaya" - beban pada sistem penyimpanan dan jaringan (dengan arsitektur khusus untuk pelanggan besar);
• menyeimbangkan dengan mempertimbangkan perilaku individu masing-masing VM;
• keseimbangan diinginkan setelah jam (malam, akhir pekan, liburan).

Untuk cloud publik yang menyediakan layanan kepada pelanggan kecil, DRS dapat digunakan lebih sering, dengan fitur-fitur canggih:

• kurangnya batasan keamanan informasi dan aturan afinitas;
• menyeimbangkan di dalam awan;
• menyeimbangkan pada waktu yang wajar;
• menyeimbangkan VM apa pun;
• menyeimbangkan "virtual" mesin virtual (agar tidak mengganggu sisanya);
• data mesin virtual sering terletak di drive lokal;
• akuntansi untuk penyimpanan rata-rata dan kinerja jaringan (arsitektur cloud disatukan);
• menyeimbangkan menurut aturan umum dan statistik yang tersedia tentang perilaku pusat data.

Kompleksitas masalah

Kesulitan menyeimbangkan adalah bahwa DRS harus bekerja dengan banyak faktor yang tidak pasti:

• perilaku pengguna dari masing-masing sistem informasi pelanggan;
• algoritma untuk pengoperasian server sistem informasi;
• Perilaku server DBMS
• memuat sumber daya komputasi, penyimpanan, jaringan;
• interaksi server di antara mereka sendiri dalam perjuangan untuk sumber daya cloud.

Muatan sejumlah besar server aplikasi virtual dan database pada sumber daya cloud terjadi seiring waktu, konsekuensinya dapat terjadi dan tumpang tindih dengan efek yang tidak dapat diprediksi setelah waktu yang tidak dapat diprediksi. Bahkan untuk mengendalikan proses yang relatif sederhana (misalnya, untuk mengendalikan mesin, sistem pemanas air di rumah), sistem kontrol otomatis perlu menggunakan algoritme pembeda proporsional-integral yang kompleks dengan umpan balik.



Tugas kami adalah banyak pesanan yang lebih rumit, dan ada risiko bahwa sistem tidak akan dapat menyeimbangkan beban ke nilai yang ditetapkan dalam waktu yang wajar, bahkan jika pengaruh eksternal dari pengguna tidak terjadi.

Sejarah perkembangan kami

Untuk mengatasi masalah ini, kami memutuskan untuk tidak memulai dari awal, tetapi membangun berdasarkan pengalaman yang ada, dan mulai berinteraksi dengan para ahli di bidang ini. Untungnya, pemahaman kita tentang masalah itu bertepatan sepenuhnya.

Tahap 1

Kami menggunakan sistem yang didasarkan pada teknologi jaringan saraf, dan mencoba mengoptimalkan sumber daya kami atas dasar itu.

Minat tahap ini adalah untuk menguji teknologi baru, dan kepentingannya adalah untuk menerapkan pendekatan non-standar untuk memecahkan masalah, di mana, hal-hal lain dianggap sama, pendekatan standar praktis melelahkan diri mereka sendiri.

Kami memulai sistem, dan kami benar-benar menyeimbangkan. Skala cloud kami tidak memungkinkan kami untuk mendapatkan hasil optimis yang diumumkan oleh pengembang, tetapi jelas bahwa penyeimbangan berfungsi.

Selain itu, kami memiliki batasan yang agak serius:

• Untuk melatih jaringan saraf, mesin virtual perlu dijalankan tanpa perubahan signifikan selama berminggu-minggu atau berbulan-bulan.
• Algoritma ini dirancang untuk optimasi berdasarkan analisis data "historis" sebelumnya.
• Untuk melatih jaringan saraf, diperlukan sejumlah besar data dan sumber daya komputasi.
• Optimalisasi dan penyeimbangan dapat dilakukan relatif jarang - setiap beberapa jam sekali, yang jelas tidak cukup.

Tahap 2

Karena kami tidak senang dengan keadaan, kami memutuskan untuk memodifikasi sistem, dan untuk ini menjawab pertanyaan utama - untuk siapa kita melakukannya?

Pertama untuk klien korporat. Jadi, kita membutuhkan sistem yang bekerja secara efisien, dengan batasan perusahaan yang hanya menyederhanakan implementasi.

Pertanyaan kedua adalah apa yang dimaksud dengan kata "operasional"? Sebagai hasil dari debat singkat, kami memutuskan bahwa memungkinkan untuk membangun waktu respons 5-10 menit sehingga lompatan jangka pendek tidak memperkenalkan sistem ke resonansi.

Pertanyaan ketiga adalah berapa ukuran jumlah server yang seimbang untuk dipilih?
Masalah ini diputuskan dengan sendirinya. Biasanya, klien tidak membuat agregat server sangat besar, dan ini konsisten dengan rekomendasi dalam artikel untuk membatasi agregat menjadi 30-40 server.

Selain itu, dengan mensegmentasi pool server, kami menyederhanakan tugas algoritma balancing.

Pertanyaan keempat adalah seberapa besar jaringan saraf cocok untuk kita dengan proses belajarnya yang panjang dan keseimbangan yang jarang? Kami memutuskan untuk mengabaikannya demi algoritma operasional yang lebih sederhana untuk mendapatkan hasil dalam hitungan detik.



Deskripsi sistem yang menggunakan algoritma dan kekurangannya dapat ditemukan di sini.

Kami menerapkan dan meluncurkan sistem ini dan menerima hasil yang menggembirakan - sekarang secara teratur menganalisis beban cloud dan memberikan rekomendasi untuk memindahkan mesin virtual, yang sebagian besar benar. Bahkan sekarang jelas bahwa kita dapat mencapai 10-15% pelepasan sumber daya untuk mesin virtual baru dengan peningkatan kualitas yang ada.



Jika ketidakseimbangan terdeteksi oleh RAM atau CPU, sistem memberikan perintah kepada penjadwal Tionics untuk melakukan migrasi langsung dari mesin virtual yang diperlukan. Seperti yang dapat dilihat dari sistem pemantauan, mesin virtual bergerak dari satu host (atas) ke host (bawah) lainnya dan membebaskan memori pada host atas (disorot dalam lingkaran kuning), masing-masing menempatinya pada host yang lebih rendah (disorot dalam lingkaran putih).

Sekarang kami mencoba untuk mengevaluasi secara lebih akurat keefektifan algoritma saat ini dan berusaha menemukan kemungkinan kesalahan di dalamnya.

Tahap 3

Tampaknya Anda bisa tenang dalam hal ini, menunggu efektivitas terbukti dan tutup topik.
Tetapi peluang pengoptimalan berikut yang jelas mendorong kami untuk melakukan fase baru.

1. Statistik, misalnya, di sini dan di sini menunjukkan bahwa sistem dua dan empat prosesor dalam kinerjanya secara signifikan lebih rendah daripada yang prosesor tunggal. Ini berarti bahwa semua pengguna menerima pengembalian yang jauh lebih rendah dari CPU, RAM, SSD, LAN, FC yang dibeli dalam sistem multiprosesor dibandingkan dengan yang menggunakan prosesor tunggal.
2. Perencana sumber daya sendiri dapat bekerja dengan kesalahan serius, berikut adalah salah satu artikel tentang topik ini.
3. Teknologi yang ditawarkan oleh Intel dan AMD untuk memonitor RAM dan cache memungkinkan mempelajari perilaku mesin virtual dan menempatkannya sedemikian rupa sehingga tetangga yang berisik tidak mengganggu mesin virtual yang sunyi.
4. Memperluas set parameter (jaringan, penyimpanan, prioritas mesin virtual, biaya migrasi, kesiapannya untuk migrasi).

Total

Hasil kerja kami pada peningkatan algoritma penyeimbang adalah kesimpulan yang jelas bahwa karena algoritma modern dimungkinkan untuk mencapai optimalisasi sumber daya yang signifikan (25-30%) dari pusat data dan meningkatkan kualitas layanan pelanggan.

Algoritme yang didasarkan pada jaringan saraf, tentu saja, merupakan solusi menarik yang perlu dikembangkan lebih lanjut, dan karena pembatasan yang ada, tidak cocok untuk memecahkan masalah pada volume karakteristik cloud pribadi. Pada saat yang sama, dalam cloud publik dengan ukuran yang signifikan, algoritma menunjukkan hasil yang baik.

Kami akan memberi tahu Anda lebih banyak tentang kemampuan prosesor, penjadwal, dan penyeimbangan tingkat tinggi dalam artikel berikut.