Π kami bercakap tentang percubaan kami untuk menggunakan Watcher dan menyediakan laporan ujian. Kami secara berkala menjalankan ujian sedemikian untuk mengimbangi dan fungsi kritikal lain bagi perusahaan besar atau awan pengendali.
Kerumitan tinggi masalah yang sedang diselesaikan mungkin memerlukan beberapa artikel untuk menerangkan projek kami. Hari ini kami menerbitkan artikel kedua dalam siri ini, khusus untuk mengimbangi mesin maya dalam awan.
Beberapa istilah
Syarikat VmWare memperkenalkan utiliti DRS (Distributed Resource Scheduler) untuk mengimbangi beban persekitaran virtualisasi yang mereka bangunkan dan tawarkan.
Menurut
βVMware DRS (Penjadual Sumber Teragih) ialah utiliti yang mengimbangi beban pengkomputeran dengan sumber yang tersedia dalam persekitaran maya. Utiliti adalah sebahagian daripada suite virtualisasi yang dipanggil VMware Infrastructure.
Dengan VMware DRS, pengguna mentakrifkan peraturan untuk mengagihkan sumber fizikal antara mesin maya (VM). Utiliti boleh dikonfigurasikan untuk kawalan manual atau automatik. Kumpulan sumber VMware boleh ditambah, dialih keluar atau disusun semula dengan mudah. Jika dikehendaki, kumpulan sumber boleh diasingkan antara unit perniagaan yang berbeza. Jika beban kerja pada satu atau lebih mesin maya berubah secara mendadak, VMware DRS mengagihkan semula mesin maya merentas pelayan fizikal. Jika beban kerja keseluruhan berkurangan, sesetengah pelayan fizikal mungkin dibawa ke luar talian buat sementara waktu dan beban kerja disatukan."
Mengapa pengimbangan diperlukan?
Pada pendapat kami, DRS adalah ciri awan yang mesti ada, walaupun ini tidak bermakna DRS mesti digunakan sentiasa dan di mana-mana. Bergantung pada tujuan dan keperluan awan, mungkin terdapat keperluan yang berbeza untuk DRS dan kaedah pengimbangan. Mungkin terdapat situasi di mana pengimbangan tidak diperlukan sama sekali. Atau malah memudaratkan.
Untuk lebih memahami di mana dan untuk pelanggan mana DRS diperlukan, mari kita pertimbangkan matlamat dan objektif mereka. Awan boleh dibahagikan kepada awam dan peribadi. Berikut ialah perbezaan utama antara awan ini dan matlamat pelanggan.
Awan peribadi / Pelanggan perusahaan besar
Awan awam / Perniagaan sederhana dan kecil, orang
Kriteria dan matlamat utama pengendali
Menyediakan perkhidmatan atau produk yang boleh dipercayai
Mengurangkan kos perkhidmatan dalam perjuangan dalam pasaran yang kompetitif
Keperluan perkhidmatan
Kebolehpercayaan pada semua peringkat dan dalam semua elemen sistem
Prestasi terjamin
Utamakan mesin maya kepada beberapa kategori
Keselamatan maklumat dan data fizikal
SLA dan sokongan XNUMX/XNUMX
Kemudahan maksimum menerima perkhidmatan
Perkhidmatan yang agak mudah
Tanggungjawab untuk data terletak pada pelanggan
Tiada keutamaan VM diperlukan
Keselamatan maklumat pada tahap perkhidmatan standard, tanggungjawab pada pelanggan
Mungkin terdapat gangguan
Tiada SLA, kualiti tidak terjamin
Sokongan e-mel
Sandaran tidak perlu
Ciri Pelanggan
Pelbagai aplikasi yang sangat luas.
Permohonan warisan yang diwarisi dalam syarikat.
Seni bina tersuai yang kompleks untuk setiap pelanggan.
Peraturan perkaitan.
Perisian ini berfungsi tanpa henti dalam mod 7x24.
Alat sandaran segera.
Beban pelanggan kitaran yang boleh diramalkan.
Aplikasi biasa β pengimbangan rangkaian, Apache, WEB, VPN, SQL
Permohonan mungkin berhenti seketika
Membenarkan pengedaran sewenang-wenangnya VM dalam awan
Sandaran pelanggan
Purata beban statistik yang boleh diramalkan dengan sejumlah besar pelanggan.
Implikasi untuk seni bina
Geoclustering
Storan berpusat atau teragih
IBS terpelihara
Storan data tempatan pada nod pengiraan
Mengimbangi Matlamat
Pengagihan beban sekata
Responsif aplikasi maksimum
Masa tunda minimum untuk mengimbangi
Mengimbangi hanya apabila jelas perlu
Membawa keluar beberapa peralatan untuk penyelenggaraan pencegahan
Mengurangkan kos perkhidmatan dan kos pengendali
Melumpuhkan beberapa sumber sekiranya beban rendah
Menjimatkan tenaga
Mengurangkan kos kakitangan
Kami membuat kesimpulan berikut untuk diri kami sendiri:
Untuk awan peribadidiberikan kepada pelanggan korporat besar, DRS boleh digunakan tertakluk kepada sekatan berikut:
- keselamatan maklumat dan mengambil kira peraturan pertalian apabila mengimbangi;
- ketersediaan sumber simpanan yang mencukupi sekiranya berlaku kemalangan;
- data mesin maya terletak pada sistem storan berpusat atau teragih;
- pemisahan masa prosedur pentadbiran, sandaran dan pengimbangan;
- mengimbangi hanya dalam agregat hos pelanggan;
- mengimbangi hanya apabila terdapat ketidakseimbangan yang kuat, migrasi VM yang paling berkesan dan selamat (lagipun, penghijrahan boleh gagal);
- mengimbangi mesin maya yang agak "tenang" (penghijrahan mesin maya "bising" boleh mengambil masa yang sangat lama);
- mengimbangi dengan mengambil kira "kos" - beban pada sistem storan dan rangkaian (dengan seni bina tersuai untuk pelanggan besar);
- mengimbangi dengan mengambil kira ciri tingkah laku individu setiap VM;
- Pengimbangan sebaiknya dilakukan pada waktu tidak bekerja (malam, hujung minggu, cuti).
Untuk awan awammenyediakan perkhidmatan kepada pelanggan kecil, DRS boleh digunakan dengan lebih kerap, dengan keupayaan lanjutan:
- ketiadaan sekatan keselamatan maklumat dan peraturan pertalian;
- mengimbangi dalam awan;
- mengimbangi pada bila-bila masa yang munasabah;
- mengimbangi mana-mana VM;
- mengimbangi mesin maya "bising" (supaya tidak mengganggu orang lain);
- data mesin maya selalunya terletak pada cakera tempatan;
- mengambil kira prestasi purata sistem storan dan rangkaian (seni bina awan disatukan);
- mengimbangi mengikut peraturan am dan statistik gelagat pusat data yang tersedia.
Kerumitan masalah
Kesukaran mengimbangi ialah DRS mesti bekerja dengan sejumlah besar faktor yang tidak pasti:
- tingkah laku pengguna setiap sistem maklumat pelanggan;
- algoritma untuk pengendalian pelayan sistem maklumat;
- tingkah laku pelayan DBMS;
- memuatkan sumber pengkomputeran, sistem storan, rangkaian;
- interaksi pelayan antara satu sama lain dalam perjuangan untuk sumber awan.
Muatan sejumlah besar pelayan aplikasi maya dan pangkalan data pada sumber awan berlaku dari semasa ke semasa, akibatnya boleh nyata dan bertindih antara satu sama lain dengan kesan yang tidak dapat diramalkan dalam masa yang tidak dapat diramalkan. Malah untuk mengawal proses yang agak mudah (contohnya, untuk mengawal enjin, sistem pemanasan air di rumah), sistem kawalan automatik perlu menggunakan kompleks algoritma dengan maklum balas.
Tugas kami adalah banyak pesanan magnitud yang lebih kompleks, dan terdapat risiko bahawa sistem tidak akan dapat mengimbangi beban kepada nilai yang ditetapkan dalam masa yang munasabah, walaupun tidak ada pengaruh luaran daripada pengguna.
Sejarah perkembangan kita
Untuk menyelesaikan masalah ini, kami memutuskan untuk tidak bermula dari awal, tetapi untuk membina pengalaman sedia ada, dan mula berinteraksi dengan pakar yang berpengalaman dalam bidang ini. Nasib baik, pemahaman kami tentang masalah itu benar-benar bertepatan.
Peringkat 1
Kami menggunakan sistem berdasarkan teknologi rangkaian saraf dan cuba mengoptimumkan sumber kami berdasarkannya.
Kepentingan peringkat ini adalah dalam menguji teknologi baharu, dan kepentingannya adalah dalam menggunakan pendekatan bukan standard untuk menyelesaikan masalah di mana, perkara lain yang sama, pendekatan standard secara praktikalnya telah meletihkan diri mereka sendiri.
Kami melancarkan sistem, dan kami benar-benar mula mengimbangi. Skala awan kami tidak membenarkan kami memperoleh hasil optimistik yang dinyatakan oleh pembangun, tetapi jelas bahawa pengimbangan itu berfungsi.
Pada masa yang sama, kami mempunyai batasan yang agak serius:
- Untuk melatih rangkaian saraf, mesin maya perlu berjalan tanpa perubahan ketara selama beberapa minggu atau bulan.
- Algoritma ini direka bentuk untuk pengoptimuman berdasarkan analisis data "sejarah" yang lebih awal.
- Melatih rangkaian saraf memerlukan jumlah data dan sumber pengkomputeran yang agak besar.
- Pengoptimuman dan pengimbangan boleh dilakukan agak jarang - sekali setiap beberapa jam, yang jelas tidak mencukupi.
Peringkat 2
Oleh kerana kami tidak berpuas hati dengan keadaan, kami memutuskan untuk mengubah suai sistem, dan untuk melakukan ini, jawab soalan utama β untuk siapa kita membuatnya?
Pertama - untuk pelanggan korporat. Ini bermakna kita memerlukan sistem yang berfungsi dengan cepat, dengan sekatan korporat yang hanya memudahkan pelaksanaan.
Soalan kedua β apakah yang anda maksudkan dengan perkataan "segera"? Hasil daripada perbahasan singkat, kami memutuskan bahawa kami boleh bermula dengan masa tindak balas 5β10 minit, supaya lonjakan jangka pendek tidak akan memperkenalkan sistem kepada resonans.
Soalan ketiga β apakah saiz bilangan pelayan yang seimbang untuk dipilih?
Isu ini diselesaikan sendiri. Biasanya, pelanggan tidak membuat pengagregatan pelayan sangat besar, dan ini konsisten dengan cadangan artikel untuk mengehadkan pengagregatan kepada 30-40 pelayan.
Di samping itu, dengan membahagikan kumpulan pelayan, kami memudahkan tugas algoritma pengimbangan.
Soalan keempat β seberapa sesuaikah rangkaian saraf untuk kita dengan proses pembelajaran yang panjang dan pengimbangan yang jarang berlaku? Kami memutuskan untuk meninggalkannya demi algoritma operasi yang lebih mudah untuk mendapatkan hasil dalam beberapa saat.
Penerangan tentang sistem yang menggunakan algoritma tersebut dan kelemahannya boleh didapati
Kami melaksanakan dan melancarkan sistem ini dan menerima hasil yang menggalakkan - kini ia kerap menganalisis beban awan dan membuat cadangan untuk menggerakkan mesin maya, yang sebahagian besarnya betul. Malah sekarang adalah jelas bahawa kita boleh mencapai pelepasan 10-15% sumber untuk mesin maya baharu sambil meningkatkan kualiti kerja yang sedia ada.
Apabila ketidakseimbangan dalam RAM atau CPU dikesan, sistem mengeluarkan arahan kepada penjadual Tionix untuk melaksanakan pemindahan langsung mesin maya yang diperlukan. Seperti yang dapat dilihat dari sistem pemantauan, mesin maya berpindah dari satu (atas) ke satu lagi (bawah) hos dan membebaskan memori pada hos atas (diserlahkan dalam bulatan kuning), masing-masing mendudukinya di bawah (diserlahkan dalam warna putih. bulatan).
Sekarang kami cuba menilai dengan lebih tepat keberkesanan algoritma semasa dan cuba mencari kemungkinan ralat di dalamnya.
Peringkat 3
Nampaknya seseorang boleh bertenang dalam perkara ini, menunggu keberkesanan yang terbukti dan menutup topik.
Tetapi kami didorong untuk melaksanakan peringkat baharu dengan peluang pengoptimuman yang jelas berikut
- Statistik, contohnya, ΠΈ menunjukkan bahawa sistem dua dan empat pemproses adalah jauh lebih rendah dalam prestasi berbanding sistem pemproses tunggal. Ini bermakna semua pengguna menerima output yang jauh lebih sedikit daripada CPU, RAM, SSD, LAN, FC yang dibeli dalam sistem berbilang pemproses berbanding sistem pemproses tunggal.
- Penjadual sumber sendiri mungkin mempunyai ralat yang serius, mengenai topik ini.
- Teknologi yang ditawarkan oleh Intel dan AMD untuk memantau RAM dan cache memungkinkan untuk mengkaji kelakuan mesin maya dan meletakkannya sedemikian rupa sehingga jiran "bising" tidak mengganggu mesin maya "tenang".
- Peluasan set parameter (rangkaian, sistem storan, keutamaan mesin maya, kos penghijrahan, kesediaannya untuk penghijrahan).
Dalam jumlah
Hasil kerja kami untuk meningkatkan algoritma pengimbangan adalah kesimpulan yang jelas bahawa menggunakan algoritma moden adalah mungkin untuk mencapai pengoptimuman ketara sumber pusat data (25-30%) dan pada masa yang sama meningkatkan kualiti perkhidmatan pelanggan.
Algoritma berdasarkan rangkaian saraf pastinya merupakan penyelesaian yang menarik, tetapi yang memerlukan pembangunan lanjut, dan disebabkan oleh batasan sedia ada, ia tidak sesuai untuk menyelesaikan masalah seperti ini pada volum biasa untuk awan peribadi. Pada masa yang sama, algoritma menunjukkan hasil yang baik dalam awan awam dengan saiz yang ketara.
Kami akan memberitahu anda lebih lanjut tentang keupayaan pemproses, penjadual dan pengimbangan peringkat tinggi dalam artikel berikut.
Sumber: www.habr.com