Balancing Beban dina Openstack (Bagian 2)

В tulisan panungtung urang ngobrol ngeunaan usaha urang ngagunakeun Watcher sarta nyadiakeun laporan tés. Kami périodik ngalaksanakeun tés sapertos pikeun nyaimbangkeun sareng fungsi kritis séjén tina perusahaan ageung atanapi operator awan.

Pajeulitna masalah anu direngsekeun tiasa ngabutuhkeun sababaraha tulisan pikeun ngajelaskeun proyék kami. Dinten ieu kami medarkeun artikel kadua dina séri, dedicated ka kasaimbangan mesin virtual dina awan.

Sababaraha terminologi

Perusahaan VmWare ngenalkeun utilitas DRS (Distributed Resource Scheduler) pikeun nyaimbangkeun beban lingkungan virtualisasi anu dikembangkeun sareng ditawarkeun.

nyerat searchvmware.techtarget.com/definition/VMware-DRS
"VMware DRS (Distributed Resource Scheduler) mangrupikeun utilitas anu nyaimbangkeun beban komputasi sareng sumber daya anu sayogi dina lingkungan virtual. Utiliti mangrupikeun bagian tina suite virtualisasi anu disebut Infrastruktur VMware.

Kalawan VMware DRS, pamaké nangtukeun aturan pikeun ngadistribusikaeun sumberdaya fisik diantara mesin virtual (VM). Utiliti tiasa dikonpigurasi pikeun kontrol manual atanapi otomatis. VMware pools sumberdaya bisa gampang ditambahkeun, dihapus, atawa reorganized. Upami hoyong, pools sumberdaya bisa diisolasi antara unit bisnis béda. Lamun beban gawé dina hiji atawa leuwih mesin virtual robah nyirorot, VMware DRS redistributes mesin virtual sakuliah server fisik. Upami beban kerja umumna turun, sababaraha server fisik tiasa samentawis dicandak offline sareng beban kerja dihijikeun."

Naha kasaimbangan diperlukeun?

Numutkeun kami, DRS mangrupikeun fitur awan anu kedah aya, sanaos ieu sanés hartosna DRS kedah dianggo salawasna sareng di mana waé. Gumantung kana tujuan jeung kabutuhan awan, meureun aya sarat béda pikeun DRS jeung métode balancing. Meureun aya kaayaan dimana balancing teu diperlukeun pisan. Atawa malah ngabahayakeun.

Pikeun langkung ngartos dimana sareng dimana klien DRS diperyogikeun, hayu urang pertimbangkeun tujuan sareng tujuanana. Awan bisa dibagi kana umum jeung swasta. Ieu mangrupikeun bédana utama antara awan ieu sareng tujuan palanggan.

Awan swasta / Klién perusahaan ageung
awan publik / Sedeng jeung usaha leutik, jalma

Kriteria utama sareng tujuan operator
Nyadiakeun jasa atanapi produk anu tiasa dipercaya
Ngurangan biaya jasa dina tarung dina pasar kalapa

Syarat jasa
Reliabilitas dina sadaya tingkatan sareng dina sadaya elemen sistem

Kinerja dijamin

Prioritaskeun mesin virtual kana sababaraha kategori 

Inpormasi sareng kaamanan data fisik

SLA jeung XNUMX/XNUMX rojongan
betah maksimum narima jasa

jasa rélatif basajan

Tanggung jawab pikeun data perenahna sareng klien

Taya prioritization VM diperlukeun

Kaamanan inpormasi dina tingkat jasa standar, tanggung jawab kana klien

Meureun aya glitches

Taya SLA, kualitas teu dijamin

rojongan surélék

Nyadangkeun teu perlu

Fitur klien
rentang pisan lega tina aplikasi.

Aplikasi warisan diwariskeun di perusahaan.

arsitéktur custom kompléks pikeun tiap klien.

Aturan pangirut.

Parangkat lunak tiasa dianggo tanpa lirén dina modeu 7x24. 

Alat cadangan on-the-fly.

beban customer siklik diprediksi.
Aplikasi biasa - balancing jaringan, Apache, WEB, VPN, SQL

Aplikasina tiasa eureun sakedap

Ngidinan distribusi sawenang-wenang VM dina awan

Nyadangkeun klien

Beban rata-rata statistik anu tiasa diprediksi sareng sajumlah ageung klien.

Implikasi pikeun arsitéktur
Geoclustering

Panyimpenan terpusat atanapi disebarkeun

Ditangtayungan IBS
Panyimpen data lokal dina titik komputasi

Balancing Goals
Malah distribusi beban

Responsiveness aplikasi maksimum 

Waktu reureuh minimum pikeun balancing

Balancing ngan lamun jelas diperlukeun

Bringing sababaraha parabot kaluar pikeun pangropéa preventative
Ngurangan biaya jasa sareng biaya operator 

Nonaktipkeun sababaraha sumber dina kasus beban low

Ngirit tanaga

Ngurangan biaya tanaga

Urang narik kacindekan ieu pikeun diri urang sorangan:

Pikeun awan swastadisadiakeun pikeun konsumén perusahaan badag, DRS bisa dipaké tunduk kana larangan handap:

• kaamanan inpormasi sareng tumut kana aturan afinitas nalika ngimbangan;
• kasadiaan sumber daya anu cukup dina cadangan upami aya kacilakaan;
• data mesin virtual lokasina dina sistem gudang terpusat atawa disebarkeun;
• administrasi staggering, cadangan tur balancing prosedur kana waktu;
• balancing ngan dina hiji agrégat host klien;
• balancing ngan lamun aya saimbangna kuat, paling éféktif jeung aman VM migrations (sanggeus kabeh, migrasi bisa gagal);
• balancing rélatif "sepi" mesin virtual (migrasi tina "bising" mesin virtual tiasa nyandak lila pisan);
• balancing nyokot kana akun "biaya" - beban dina sistem gudang jeung jaringan (kalawan arsitéktur ngaropéa pikeun klien badag);
• balancing nyokot kana akun ciri kabiasaan individu unggal VM;
• Balancing preferably dipigawé salila jam non-kerja (wengi, weekends, libur).

Pikeun awan umumnyadiakeun layanan ka konsumén leutik, DRS bisa dipaké leuwih sering, kalawan kamampuhan canggih:

• henteuna larangan kaamanan inpormasi sareng aturan afinitas;
• kasaimbangan dina awan;
• kasaimbangan iraha wae nu lumrah;
• nyaimbangkeun sagala VM;
• balancing "bising" mesin virtual (supaya teu ngaganggu batur);
• data mesin virtual mindeng ayana dina disk lokal;
• merhatikeun kinerja rata-rata sistem panyimpenan sareng jaringan (arsitektur awan ngahijikeun);
• balancing nurutkeun aturan umum jeung sadia statistik kabiasaan puseur data.

Pajeulitna masalah

Kasusah balancing nyaéta DRS kedah dianggo sareng sajumlah ageung faktor anu teu pasti:

• kabiasaan pamaké unggal sistem informasi klien ';
• algoritma pikeun operasi server sistem informasi;
• kabiasaan server DBMS;
• beban dina sumber komputasi, sistem gudang, jaringan;
• interaksi server saling dina perjuangan sumberdaya awan.

Beban sajumlah ageung pangladén aplikasi virtual sareng pangkalan data dina sumber awan lumangsung dina waktosna, akibatna tiasa ngawujud diri sareng silih tumpang tindih sareng pangaruh anu teu kaduga dina waktos anu teu kaduga. Malah pikeun ngadalikeun prosés anu kawilang basajan (contona, pikeun ngadalikeun mesin, sistem pemanasan cai di bumi), sistem kontrol otomatis kedah nganggo kompleks. proporsional-integral-diferensiasi algoritma kalawan eupan balik.

Tugas kami nyaéta seueur pesenan ageungna langkung kompleks, sareng aya résiko yén sistem moal tiasa nyaimbangkeun beban kana nilai anu didirikeun dina waktos anu lumayan, sanaos henteu aya pangaruh éksternal ti pangguna.

Sajarah kamajuan urang

Pikeun ngajawab masalah ieu, urang mutuskeun teu mimitian ti scratch, tapi pikeun ngawangun on pangalaman aya, sarta mimiti berinteraksi sareng spesialis kalawan pangalaman dina widang ieu. Untungna, pamahaman kami masalah sagemblengna coincided.

tahap 1

Kami nganggo sistem dumasar kana téknologi jaringan saraf sareng nyobian ngaoptimalkeun sumber daya kami dumasar kana éta.

Kapentingan tahap ieu dina nguji hiji téhnologi anyar, sarta pentingna éta dina nerapkeun pendekatan non-standar pikeun ngarengsekeun masalah dimana, hal séjén anu sarua, pendekatan baku geus praktis exhausted sorangan.

Urang dibuka sistem, sarta kami bener dimimitian balancing. Skala awan kami henteu ngijinkeun urang kéngingkeun hasil optimis anu dinyatakeun ku pamekar, tapi écés yén balancingna jalan.

Dina waktos anu sami, urang ngagaduhan watesan anu serius:

• Pikeun ngalatih jaringan saraf, mesin virtual kedah dijalankeun tanpa parobahan anu signifikan salami sababaraha minggu atanapi sasih.
• Algoritma dirancang pikeun optimasi dumasar kana analisis data "sajarah" saméméhna.
• Ngalatih jaringan saraf butuh jumlah data sareng sumber komputasi anu cukup ageung.
• Optimasi sareng kasaimbangan tiasa dilakukeun jarang - sakali unggal sababaraha jam, anu jelas henteu cekap.

tahap 2

Kusabab kami henteu puas ku kaayaan, kami mutuskeun pikeun ngarobih sistem, sareng pikeun ngalakukeun ieu, jawab. patarosan utama – keur saha urang nyieun eta?

Kahiji - pikeun klien perusahaan. Ieu ngandung harti yén urang peryogi sistem anu gancang dianggo, sareng larangan perusahaan anu ngan ukur nyederhanakeun palaksanaan.

Patarosan kadua - naon anu anjeun hartosna ku kecap "gancang"? Salaku hasil tina debat pondok, urang mutuskeun yén urang bisa mimitian ku waktu respon 5-10 menit, ku kituna surges jangka pondok moal ngawanohkeun sistem kana résonansi.

Patarosan katilu - naon ukuran jumlah saimbang tina server milih?
masalah ieu direngsekeun sorangan. Ilaharna, klien teu nyieun aggregations server kacida gedéna, sarta ieu konsisten jeung saran artikel pikeun ngawatesan aggregations ka 30-40 server.

Salaku tambahan, ku ngabagi kolam renang server, urang nyederhanakeun tugas algoritma balancing.

Patarosan kaopat - kumaha cocogna jaringan saraf pikeun urang kalayan prosés diajar anu panjang sareng kasaimbangan anu jarang? Kami mutuskeun pikeun ngantunkeun éta pikeun milih algoritma operasional anu langkung saderhana pikeun kéngingkeun hasil dina sababaraha detik.

Katerangan ngeunaan sistem anu ngagunakeun algoritma sapertos kitu sareng kalemahanana tiasa dipendakan di dieu

Kami ngalaksanakeun sareng ngaluncurkeun sistem ieu sareng nampi hasil anu nyorong - ayeuna éta rutin nganalisa beban awan sareng ngadamel saran pikeun mindahkeun mesin virtual, anu sabagéan ageung leres. Malah ayeuna jelas yén urang tiasa ngahontal 10-15% sékrési sumberdaya pikeun mesin virtual anyar bari ngaronjatkeun kualitas karya nu geus aya.

Nalika henteu saimbangna dina RAM atanapi CPU dideteksi, sistem ngaluarkeun paréntah ka penjadwal Tionix pikeun ngalakukeun migrasi langsung tina mesin virtual anu diperyogikeun. Salaku bisa ditempo ti sistem monitoring, mesin virtual dipindahkeun ti hiji (luhur) ka nu sejen (handap) host na dibébaskeun memori dina host luhur (disorot dina bunderan konéng), mungguh occupying eta dina handap (disorot bodas. bunderan).

Ayeuna urang nyobian langkung akurat ngira-ngira éféktivitas algoritma ayeuna sareng nyobian mendakan kasalahan anu mungkin di jerona.

tahap 3

Éta sigana bakal tenang dina ieu, ngantosan efektivitas anu kabuktian sareng nutup topikna.
Tapi urang kadorong pikeun ngalaksanakeun tahap anyar ku kasempetan optimasi atra handap

1. Statistik, contona, di dieu и di dieu nembongkeun yen sistem dua- jeung opat-processor nyata handap dina kinerja ti sistem single-processor. Ieu ngandung harti yén sakabéh pamaké narima kaluaran nyata kirang ti CPU, RAM, SSD, LAN, FC dibeuli dina sistem multiprocessor dibandingkeun sistem single-processor.
2. The schedulers sumberdaya sorangan bisa boga kasalahan serius, ieu salah sahiji artikel dina topik ieu.
3. Téknologi anu ditawarkeun ku Intel sareng AMD pikeun ngawaskeun RAM sareng cache ngamungkinkeun pikeun diajar paripolah mesin virtual sareng nempatkeun aranjeunna dina cara anu "bising" tatanggana henteu ngaganggu mesin virtual "tenang".
4. Ékspansi set parameter (jaringan, sistem panyimpen, prioritas mesin virtual, biaya migrasi, kesiapan pikeun migrasi).

dina total

Hasil karya urang pikeun ngaronjatkeun algoritma balancing éta kacindekan jelas yén ngagunakeun algoritma modern kasebut nyaéta dimungkinkeun pikeun ngahontal optimasi signifikan sumberdaya puseur data (25-30%) sarta dina waktos anu sareng ngaronjatkeun kualitas layanan palanggan.

Algoritma dumasar kana jaringan saraf pasti mangrupikeun solusi anu pikaresepeun, tapi anu peryogi pamekaran salajengna, sareng kusabab keterbatasan anu aya, éta henteu cocog pikeun ngarengsekeun masalah sapertos kieu dina jilid anu khas pikeun awan pribadi. Dina waktos anu sami, algoritma nunjukkeun hasil anu saé dina awan umum anu ukuranana signifikan.

Kami bakal nyarioskeun langkung seueur ngeunaan kamampuan prosesor, jadwal, sareng kasaimbangan tingkat luhur dina tulisan di handap ieu.

sumber: www.habr.com