В kita ngomong babagan upaya nggunakake Watcher lan menehi laporan tes. Kita rutin nindakake tes kasebut kanggo imbangan lan fungsi kritis liyane saka awan perusahaan utawa operator gedhe.
Kompleksitas dhuwur saka masalah sing ditanggulangi mbutuhake sawetara artikel kanggo njlèntrèhaké proyek kita. Dina iki kita nerbitake artikel kapindho ing seri kasebut, darmabakti kanggo ngimbangi mesin virtual ing méga.
Sawetara terminologi
Perusahaan VmWare ngenalake sarana DRS (Distributed Resource Scheduler) kanggo ngimbangi beban lingkungan virtualisasi sing dikembangake lan ditawakake.
Nalika piyambakipun nyerat
"VMware DRS (Distributed Resource Scheduler) minangka sarana sing ngimbangi beban komputasi karo sumber daya sing kasedhiya ing lingkungan virtual. Utilitas kasebut minangka bagean saka suite virtualisasi sing diarani VMware Infrastructure.
Kanthi VMware DRS, pangguna nemtokake aturan kanggo nyebarake sumber daya fisik ing antarane mesin virtual (VM). Utilitas bisa dikonfigurasi kanggo kontrol manual utawa otomatis. Kolam sumber daya VMware bisa gampang ditambahake, dibusak, utawa diatur maneh. Yen dikarepake, blumbang sumber bisa diisolasi ing antarane unit bisnis sing beda. Yen beban kerja ing siji utawa luwih mesin virtual diganti kanthi dramatis, VMware DRS nyebarake maneh mesin virtual ing server fisik. Yen beban kerja sakabèhé suda, sawetara server fisik bisa uga dicopot sacara offline lan beban kerja digabung.
Napa imbangan dibutuhake?
Miturut pendapat kita, DRS minangka fitur maya sing kudu ana, sanajan iki ora ateges DRS kudu digunakake ing endi wae. Gumantung saka tujuan lan kabutuhan awan, bisa uga ana syarat sing beda kanggo DRS lan cara balancing. Bisa uga ana kahanan nalika keseimbangan ora dibutuhake. Utawa malah mbebayani.
Kanggo luwih ngerti ngendi lan kanggo klien sing DRS dibutuhake, ayo nimbang tujuan lan tujuane. Awan bisa dipérang dadi umum lan pribadi. Mangkene bedane utama ing antarane awan lan tujuan pelanggan.
Awan pribadi / Klien perusahaan gedhe
Awan umum / Sedheng lan bisnis cilik, wong
Kriteria utama lan tujuan operator
Nyedhiyakake layanan utawa produk sing dipercaya
Ngurangi biaya layanan ing perang ing pasar sing kompetitif
syarat layanan
Reliabilitas ing kabeh tingkat lan ing kabeh unsur sistem
Kinerja dijamin
Prioritasake mesin virtual dadi sawetara kategori
Informasi lan keamanan data fisik
SLA lan XNUMX/XNUMX support
Ease maksimum nampa layanan
Layanan sing relatif prasaja
Tanggung jawab kanggo data kasebut ana ing klien
Ora ana prioritas VM sing dibutuhake
Keamanan informasi ing tingkat layanan standar, tanggung jawab ing klien
Bisa uga ana glitches
Ora SLA, kualitas ora dijamin
Dhukungan email
Gawe serep ora perlu
Fitur Klien
Wiyar banget saka aplikasi.
Aplikasi warisan sing diwarisake ing perusahaan.
Arsitèktur khusus sing rumit kanggo saben klien.
Aturan afinitas.
Piranti lunak bisa digunakake tanpa mandheg ing mode 7x24.
Alat serep on-the-fly.
Beban pelanggan siklik sing bisa diramal.
Aplikasi umum - balancing jaringan, Apache, WEB, VPN, SQL
Aplikasi bisa mandheg sedhela
Ngidini distribusi VM kanthi sewenang-wenang ing méga
Gawe serep klien
Beban rata-rata statistik sing bisa diramal kanthi akeh klien.
Implikasi kanggo arsitektur
Geoclustering
Panyimpenan terpusat utawa disebarake
Reserved IBS
Panyimpenan data lokal ing simpul komputasi
Goals Balancing
Malah distribusi beban
Respon aplikasi maksimal
Wektu tundha minimal kanggo imbangan
Balancing mung yen cetha perlu
Nggawa sawetara peralatan metu kanggo pangopènan nyegah
Ngurangi biaya layanan lan biaya operator
Mateni sawetara sumber daya ing cilik mbukak kurang
Ngirit energi
Ngurangi biaya personel
Kita nggawe kesimpulan ing ngisor iki kanggo awake dhewe:
Kanggo awan pribadikasedhiya kanggo pelanggan perusahaan gedhe, DRS bisa digunakake miturut watesan ing ngisor iki:
- keamanan informasi lan njupuk menyang akun aturan karemenan nalika balancing;
- kasedhiyan sumber daya sing cukup kanggo cadangan yen ana kacilakan;
- data mesin virtual dumunung ing sistem panyimpenan terpusat utawa mbagekke;
- pemisahan wektu administrasi, prosedur serep lan imbangan;
- imbangan mung ing agrégat host klien;
- imbangan mung nalika ana boten seimbang kalebet kuwat, migrasi VM paling efektif lan aman (sawise kabeh, migrasi bisa gagal);
- ngimbangi mesin virtual sing relatif "sepi" (migrasi mesin virtual "rame" bisa njupuk wektu sing suwe);
- imbangan njupuk menyang akun "biaya" - beban ing sistem panyimpenan lan jaringan (kanthi arsitektur khusus kanggo klien gedhe);
- imbangan njupuk menyang akun karakteristik prilaku individu saben VM;
- Balancing luwih becik ditindakake sajrone jam kerja (wengi, akhir minggu, preian).
Kanggo awan umumnyediakake layanan kanggo pelanggan cilik, DRS bisa digunakake luwih asring, kanthi kapabilitas majeng:
- ora ana watesan keamanan informasi lan aturan afinitas;
- imbangan ing méga;
- imbangan ing sembarang wektu cukup;
- imbangan sembarang VM;
- ngimbangi mesin virtual "rame" (supaya ora ngganggu wong liya);
- data mesin virtual asring dumunung ing disk lokal;
- nganggep kinerja rata-rata sistem panyimpenan lan jaringan (arsitektur maya digabungake);
- imbangan miturut aturan umum lan kasedhiya statistik prilaku pusat data.
Kompleksitas masalah
Kangelan ngimbangi yaiku DRS kudu nggarap akeh faktor sing ora mesthi:
- prilaku pangguna saben sistem informasi klien;
- algoritma kanggo operasi server sistem informasi;
- prilaku server DBMS;
- mbukak sumber daya komputasi, sistem panyimpenan, jaringan;
- interaksi server karo saben liyane ing perjuangan kanggo sumber daya maya.
Beban saka akeh server aplikasi virtual lan database ing sumber maya dumadi liwat wektu, jalaran bisa mujudake awake dhewe lan tumpang tindih karo efek sing ora bisa diprediksi sajrone wektu sing ora bisa ditebak. Malah kanggo ngontrol proses sing relatif prasaja (contone, kanggo ngontrol mesin, sistem pemanas banyu ing omah), sistem kontrol otomatis kudu nggunakake kompleks. algoritma karo umpan balik.
Tugas kita yaiku akeh pesenan sing luwih rumit, lan ana risiko manawa sistem ora bakal bisa ngimbangi beban menyang nilai sing diadegake ing wektu sing cukup, sanajan ora ana pengaruh eksternal saka pangguna.
Sejarah perkembangan kita
Kanggo ngatasi masalah iki, kita mutusake ora miwiti saka ngeruk, nanging kanggo mbangun pengalaman sing wis ana, lan wiwit sesambungan karo spesialis sing duwe pengalaman ing wilayah iki. Untunge, pemahaman kita babagan masalah kasebut pas.
Panggung 1
Kita nggunakake sistem adhedhasar teknologi jaringan saraf lan nyoba ngoptimalake sumber daya adhedhasar iku.
Kapentingan ing tahap iki yaiku nguji teknologi anyar, lan pentinge kanggo ngetrapake pendekatan non-standar kanggo ngrampungake masalah ing ngendi, prekara liya padha, pendekatan standar wis kesel dhewe.
We dibukak sistem, lan kita tenan miwiti imbangan. Skala awan kita ora ngidini kita entuk asil optimis sing dikandhakake para pangembang, nanging jelas manawa imbangan kasebut bisa digunakake.
Ing wektu sing padha, kita duwe watesan sing cukup serius:
- Kanggo nglatih jaringan saraf, mesin virtual kudu mlaku tanpa owah-owahan sing signifikan sajrone pirang-pirang minggu utawa wulan.
- Algoritma kasebut dirancang kanggo optimasi adhedhasar analisis data "historis" sadurungé.
- Latihan jaringan saraf mbutuhake jumlah data lan sumber daya komputasi sing cukup akeh.
- Optimasi lan imbangan bisa ditindakake kanthi jarang - sapisan saben sawetara jam, sing jelas ora cukup.
Panggung 2
Amarga kita ora puas karo kahanan, kita mutusake kanggo ngowahi sistem kasebut, lan kanggo nindakake iki, wangsulane pitakonan utama – kanggo sapa kita nggawe?
First - kanggo klien perusahaan. Iki tegese kita butuh sistem sing bisa digunakake kanthi cepet, kanthi watesan perusahaan sing mung nyederhanakake implementasine.
Pitakonan kapindho - apa tegese tembung "cepet"? Minangka asil saka debat singkat, kita mutusake yen kita bisa miwiti kanthi wektu nanggepi 5-10 menit, supaya lonjakan jangka pendek ora bakal ngenalake sistem menyang resonansi.
Pitakonan katelu – apa ukuran nomer imbang saka server kanggo milih?
Masalah iki ditanggulangi dhewe. Biasane, klien ora nggawe agregasi server gedhe banget, lan iki konsisten karo rekomendasi artikel kanggo mbatesi agregasi dadi 30-40 server.
Kajaba iku, kanthi segmentasi blumbang server, kita nyederhanakake tugas algoritma imbangan.
Pitakonan kaping papat - kepiye jaringan saraf sing cocog kanggo kita kanthi proses sinau sing dawa lan keseimbangan sing langka? Kita mutusake kanggo nglirwakake kanthi milih algoritma operasional sing luwih gampang supaya entuk asil sajrone sawetara detik.
Katrangan babagan sistem sing nggunakake algoritma kasebut lan kekurangane bisa ditemokake
Kita ngetrapake lan ngluncurake sistem iki lan entuk asil sing nyemangati - saiki nganalisa beban awan kanthi rutin lan menehi rekomendasi kanggo mindhah mesin virtual, sing umume bener. Malah saiki wis jelas yen kita bisa entuk 10-15% release sumber daya kanggo mesin virtual anyar nalika nambah kualitas karya sing wis ana.
Nalika ora imbang ing RAM utawa CPU dideteksi, sistem ngetokake prentah menyang panjadwal Tionix kanggo nindakake migrasi langsung saka mesin virtual sing dibutuhake. Minangka bisa dideleng saka sistem ngawasi, mesin virtual pindhah saka siji (ndhuwur) menyang liyane (ngisor) inang lan mbebasake memori ing inang ndhuwur (disorot ing bunderan kuning), mungguh manggoni ing ngisor (disorot putih). bunderan).
Saiki kita nyoba luwih akurat netepake efektifitas algoritma saiki lan nyoba nemokake kesalahan sing bisa ditindakake.
Panggung 3
Kayane wong bisa tenang babagan iki, ngenteni efektifitas sing wis kabukten lan nutup topik kasebut.
Nanging kita didorong kanggo nindakake tahap anyar kanthi kesempatan optimasi sing jelas
- Statistik, contone, и nuduhake yen loro- lan sistem papat prosesor Ngartekno luwih murah ing kinerja saka sistem siji-prosesor. Iki tegese kabeh pangguna nampa output Ngartekno kurang saka CPU, RAM, SSD, LAN, FC dituku ing sistem multiprocessor dibandhingake siji-prosesor.
- Penjadwal sumber daya dhewe bisa uga duwe kesalahan serius, ing topik iki.
- Teknologi sing ditawakake Intel lan AMD kanggo ngawasi RAM lan cache ndadekake bisa sinau prilaku mesin virtual lan nyelehake kanthi cara sing "rame" tetanggan ora ngganggu mesin virtual "sepi".
- Ekspansi paramèter (jaringan, sistem panyimpenan, prioritas mesin virtual, biaya migrasi, kesiapan kanggo migrasi).
Total
Asil karya kita kanggo nambah kalkulus balancing yaiku kesimpulan sing jelas yen nggunakake algoritma modern bisa entuk optimalisasi sumber daya pusat data (25-30%) lan ing wektu sing padha nambah kualitas layanan pelanggan.
Algoritma adhedhasar jaringan saraf mesthi dadi solusi sing menarik, nanging sing mbutuhake pangembangan luwih lanjut, lan amarga watesan sing ana, ora cocog kanggo ngrampungake masalah kaya iki ing volume sing khas kanggo awan pribadi. Ing wektu sing padha, algoritma kasebut nuduhake asil sing apik ing awan umum kanthi ukuran sing signifikan.
Kita bakal ngandhani luwih akeh babagan kemampuan prosesor, jadwal, lan keseimbangan tingkat dhuwur ing artikel ing ngisor iki.
Source: www.habr.com