Π kami berbicara tentang upaya kami menggunakan Watcher dan memberikan laporan pengujian. Kami secara berkala melakukan pengujian tersebut untuk menyeimbangkan dan fungsi penting lainnya dari perusahaan besar atau operator cloud.
Tingginya kompleksitas masalah yang sedang dipecahkan mungkin memerlukan beberapa artikel untuk menjelaskan proyek kami. Hari ini kami menerbitkan artikel kedua dalam seri ini, yang didedikasikan untuk menyeimbangkan mesin virtual di cloud.
Sedikit terminologi
Perusahaan VmWare memperkenalkan utilitas DRS (Distributed Resource Scheduler) untuk menyeimbangkan beban lingkungan virtualisasi yang mereka kembangkan dan tawarkan.
Menurut
βVMware DRS (Distributed Resource Scheduler) adalah utilitas yang menyeimbangkan beban komputasi dengan sumber daya yang tersedia di lingkungan virtual. Utilitas ini merupakan bagian dari rangkaian virtualisasi yang disebut Infrastruktur VMware.
Dengan VMware DRS, pengguna menentukan aturan untuk mendistribusikan sumber daya fisik di antara mesin virtual (VM). Utilitas dapat dikonfigurasi untuk kontrol manual atau otomatis. Kumpulan sumber daya VMware dapat dengan mudah ditambahkan, dihapus, atau diatur ulang. Jika diinginkan, kumpulan sumber daya dapat diisolasi antara unit bisnis yang berbeda. Jika beban kerja pada satu atau lebih mesin virtual berubah drastis, VMware DRS akan mendistribusikan ulang mesin virtual ke seluruh server fisik. Jika beban kerja keseluruhan berkurang, beberapa server fisik mungkin offline untuk sementara dan beban kerja dikonsolidasikan."
Mengapa keseimbangan diperlukan?
Menurut kami, DRS adalah fitur cloud yang wajib dimiliki, meski bukan berarti DRS harus digunakan selalu dan di mana saja. Tergantung pada tujuan dan kebutuhan cloud, mungkin terdapat 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 untuk klien mana DRS dibutuhkan, mari kita pertimbangkan tujuan dan sasaran mereka. Awan dapat dibagi menjadi publik dan pribadi. Berikut adalah perbedaan utama antara cloud dan sasaran pelanggan.
Cloud pribadi / Klien perusahaan besar
Cloud publik / Usaha menengah dan kecil, masyarakat
Kriteria utama dan tujuan operator
Memberikan layanan atau produk yang dapat diandalkan
Mengurangi biaya layanan dalam pertarungan di pasar yang kompetitif
Persyaratan layanan
Keandalan di semua tingkatan dan di semua elemen sistem
Performa terjamin
Prioritaskan mesin virtual ke dalam beberapa kategori
Keamanan informasi dan data fisik
SLA dan dukungan XNUMX/XNUMX
Kemudahan maksimal dalam menerima layanan
Layanan yang relatif sederhana
Tanggung jawab atas data terletak pada klien
Tidak diperlukan prioritas VM
Keamanan informasi pada tingkat layanan standar, tanggung jawab pada klien
Mungkin ada gangguan
Tidak ada SLA, kualitas tidak terjamin
Dukungan email
Cadangan tidak diperlukan
Fitur Klien
Rentang aplikasi yang sangat luas.
Aplikasi lawas yang diwarisi di perusahaan.
Arsitektur khusus yang kompleks untuk setiap klien.
Aturan afinitas.
Perangkat lunak ini bekerja tanpa henti dalam mode 7x24.
Alat pencadangan saat itu juga.
Beban pelanggan siklik yang dapat diprediksi.
Aplikasi umum β penyeimbangan jaringan, Apache, WEB, VPN, SQL
Aplikasi mungkin berhenti untuk sementara waktu
Mengizinkan distribusi VM secara sewenang-wenang di cloud
Cadangan klien
Beban rata-rata yang dapat diprediksi secara statistik dengan sejumlah besar klien.
Implikasinya bagi arsitektur
Geokluster
Penyimpanan terpusat atau terdistribusi
IBS yang dipesan
Penyimpanan data lokal pada node komputasi
Menyeimbangkan Tujuan
Distribusi beban yang merata
Responsivitas aplikasi maksimal
Waktu tunda minimum untuk penyeimbangan
Menyeimbangkan hanya jika benar-benar diperlukan
Membawa beberapa peralatan untuk pemeliharaan preventif
Mengurangi biaya layanan dan biaya operator
Menonaktifkan beberapa sumber daya jika beban rendah
Menghemat energi
Mengurangi biaya personel
Kami menarik kesimpulan berikut untuk diri kami sendiri:
Untuk cloud pribadidisediakan untuk pelanggan korporat besar, DRS dapat digunakan dengan batasan berikut:
- keamanan informasi dan mempertimbangkan aturan afinitas saat menyeimbangkan;
- ketersediaan sumber daya cadangan yang cukup pada saat terjadi kecelakaan;
- data mesin virtual terletak pada sistem penyimpanan terpusat atau terdistribusi;
- pemisahan waktu prosedur administrasi, pencadangan dan penyeimbangan;
- menyeimbangkan hanya dalam agregat host klien;
- menyeimbangkan hanya ketika ada ketidakseimbangan yang kuat, migrasi VM yang paling efektif dan aman (bagaimanapun juga, migrasi bisa gagal);
- menyeimbangkan mesin virtual yang relatif βtenangβ (migrasi mesin virtual yang βberisikβ dapat memakan waktu sangat lama);
- menyeimbangkan dengan mempertimbangkan "biaya" - beban pada sistem penyimpanan dan jaringan (dengan arsitektur yang disesuaikan untuk klien besar);
- penyeimbangan dengan mempertimbangkan karakteristik perilaku individu dari setiap VM;
- Penyeimbangan sebaiknya dilakukan di luar jam kerja (malam hari, akhir pekan, hari libur).
Untuk cloud publikmemberikan layanan kepada pelanggan kecil, DRS dapat digunakan lebih sering, dengan kemampuan tingkat lanjut:
- tidak adanya batasan keamanan informasi dan aturan afinitas;
- menyeimbangkan dalam cloud;
- menyeimbangkan pada waktu yang wajar;
- menyeimbangkan VM apa pun;
- menyeimbangkan mesin virtual yang βberisikβ (agar tidak mengganggu orang lain);
- data mesin virtual sering kali terletak di disk lokal;
- dengan mempertimbangkan kinerja rata-rata sistem penyimpanan dan jaringan (arsitektur cloud terpadu);
- menyeimbangkan menurut aturan umum dan statistik perilaku pusat data yang tersedia.
Kompleksitas masalah
Kesulitan dalam penyeimbangan adalah DRS harus bekerja dengan sejumlah besar faktor yang tidak pasti:
- perilaku pengguna setiap sistem informasi klien;
- algoritma pengoperasian server sistem informasi;
- perilaku server DBMS;
- beban pada sumber daya komputasi, sistem penyimpanan, jaringan;
- interaksi server satu sama lain dalam perebutan sumber daya cloud.
Pemuatan sejumlah besar server aplikasi virtual dan database pada sumber daya cloud terjadi seiring berjalannya waktu, konsekuensinya dapat terwujud dan saling tumpang tindih dengan efek yang tidak dapat diprediksi dalam waktu yang tidak dapat diprediksi. Bahkan untuk mengendalikan proses yang relatif sederhana (misalnya, untuk mengendalikan mesin, sistem pemanas air di rumah), sistem kendali otomatis perlu menggunakan sistem yang kompleks. algoritma dengan umpan balik.
Tugas kita jauh lebih kompleks, dan terdapat risiko bahwa sistem tidak akan mampu menyeimbangkan beban ke nilai yang ditetapkan dalam waktu yang wajar, bahkan jika tidak ada pengaruh eksternal dari pengguna.
Sejarah perkembangan kami
Untuk mengatasi masalah ini, kami memutuskan untuk tidak memulai dari awal, tetapi membangun pengalaman yang ada, dan mulai berinteraksi dengan spesialis yang berpengalaman di bidang ini. Untungnya, pemahaman kami tentang masalah ini sepenuhnya bertepatan.
tahap 1
Kami menggunakan sistem berdasarkan teknologi jaringan saraf dan mencoba mengoptimalkan sumber daya kami berdasarkan teknologi tersebut.
Kepentingan tahap ini adalah untuk menguji teknologi baru, dan kepentingannya adalah untuk menerapkan pendekatan non-standar untuk memecahkan masalah di mana, jika hal-hal lain dianggap sama, pendekatan standar secara praktis telah kehabisan tenaga.
Kami meluncurkan sistemnya, dan kami benar-benar mulai menyeimbangkan. Skala cloud kami tidak memungkinkan kami mendapatkan hasil optimis yang dinyatakan oleh pengembang, namun jelas bahwa penyeimbangannya berhasil.
Pada saat yang sama, kami mempunyai keterbatasan yang cukup serius:
- Untuk melatih jaringan saraf, mesin virtual perlu berjalan tanpa perubahan signifikan selama berminggu-minggu atau berbulan-bulan.
- Algoritma ini dirancang untuk optimasi berdasarkan analisis data βhistorisβ sebelumnya.
- Melatih jaringan saraf memerlukan data dan sumber daya komputasi dalam jumlah yang cukup besar.
- Optimalisasi dan penyeimbangan dapat dilakukan relatif jarang - setiap beberapa jam sekali, dan ini jelas tidak cukup.
tahap 2
Karena kami tidak puas dengan keadaannya, kami memutuskan untuk memodifikasi sistem, dan untuk melakukan ini, jawablah pertanyaan utama β untuk siapa kita membuatnya?
Yang pertama adalah untuk klien korporat. Artinya kita memerlukan sistem yang bekerja cepat, dengan batasan perusahaan yang hanya menyederhanakan implementasi.
Pertanyaan kedua β apa yang Anda maksud dengan kata βsegeraβ? Sebagai hasil dari perdebatan singkat, kami memutuskan bahwa kami dapat memulai dengan waktu respons 5β10 menit, sehingga lonjakan jangka pendek tidak akan membuat sistem mengalami resonansi.
Pertanyaan ketiga β berapa ukuran jumlah server seimbang yang harus dipilih?
Masalah ini teratasi dengan sendirinya. Biasanya, klien tidak membuat agregasi server menjadi sangat besar, dan hal ini konsisten dengan rekomendasi artikel untuk membatasi agregasi hingga 30-40 server.
Selain itu, dengan mengelompokkan kumpulan server, kami menyederhanakan tugas algoritma penyeimbangan.
Pertanyaan keempat β seberapa cocokkah jaringan saraf bagi kita dengan proses pembelajaran yang panjang dan keseimbangan yang langka? Kami memutuskan untuk meninggalkannya demi algoritma operasional yang lebih sederhana untuk mendapatkan hasil dalam hitungan detik.
Penjelasan tentang sistem yang menggunakan algoritma tersebut dan kekurangannya dapat ditemukan
Kami menerapkan dan meluncurkan sistem ini dan mendapatkan hasil yang menggembirakan - sekarang sistem ini secara teratur menganalisis beban cloud dan membuat 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 sekaligus meningkatkan kualitas kerja mesin yang sudah ada.
Ketika ketidakseimbangan dalam RAM atau CPU terdeteksi, sistem mengeluarkan perintah ke penjadwal Tionix untuk melakukan migrasi langsung dari mesin virtual yang diperlukan. Seperti yang dapat dilihat dari sistem pemantauan, mesin virtual berpindah dari satu host (atas) ke host lain (bawah) dan mengosongkan memori di host atas (disorot dengan lingkaran kuning), masing-masing menempatinya di host bawah (disorot dengan warna putih). lingkaran).
Sekarang kami mencoba menilai efektivitas algoritma saat ini dengan lebih akurat dan mencoba menemukan kemungkinan kesalahan di dalamnya.
tahap 3
Tampaknya kita bisa tenang dalam hal ini, menunggu efektivitas yang terbukti dan menutup topik.
Namun kami didorong untuk melakukan tahap baru dengan peluang pengoptimalan yang jelas berikut ini
- Statistik, misalnya, ΠΈ menunjukkan bahwa sistem dua dan empat prosesor memiliki kinerja yang jauh lebih rendah dibandingkan sistem prosesor tunggal. Ini berarti bahwa semua pengguna menerima output yang jauh lebih sedikit dari CPU, RAM, SSD, LAN, FC yang dibeli dalam sistem multiprosesor dibandingkan dengan sistem prosesor tunggal.
- Penjadwal sumber daya itu sendiri mungkin mengalami kesalahan serius, tentang hal ini.
- Teknologi yang ditawarkan oleh Intel dan AMD untuk memantau RAM dan cache memungkinkan untuk mempelajari perilaku mesin virtual dan menempatkannya sedemikian rupa sehingga tetangga yang βberisikβ tidak mengganggu mesin virtual yang βtenangβ.
- Perluasan kumpulan parameter (jaringan, sistem penyimpanan, prioritas mesin virtual, biaya migrasi, kesiapannya untuk migrasi).
Total
Hasil dari pekerjaan kami untuk meningkatkan algoritma penyeimbangan adalah kesimpulan yang jelas bahwa dengan menggunakan algoritma modern, dimungkinkan untuk mencapai optimalisasi sumber daya pusat data yang signifikan (25-30%) dan pada saat yang sama meningkatkan kualitas layanan pelanggan.
Algoritme yang didasarkan pada jaringan saraf tentu saja merupakan solusi yang menarik, namun memerlukan pengembangan lebih lanjut, dan karena keterbatasan yang ada, algoritma ini tidak cocok untuk memecahkan masalah semacam ini pada volume yang biasa terjadi pada private cloud. Pada saat yang sama, algoritme menunjukkan hasil yang baik di cloud publik berukuran signifikan.
Kami akan memberi tahu Anda lebih banyak tentang kemampuan prosesor, penjadwal, dan penyeimbangan tingkat tinggi di artikel berikut.
Sumber: www.habr.com