No Mēs esam pastāstījuši par mēģinājumiem izmantot Watcher un snieguši izmēģinājumu ziņojumu. Šādas izmēģināšana ir periodiska, lai nodrošinātu līdzsvarošanu un citas kritiskas funkcijas lielajā uzņēmumu vai operatoru mākoņa vidē.
Augsta risināmās problēmas sarežģītība, iespējams, prasīs vairākus rakstus, lai aprakstītu mūsu projektu. Šodien mēs publicējam otro rakstu sērijā, kas veltīta virtuālo mašīnu līdzsvarošanu mākoņos.
Neliels terminoloģijas ievads
Uzņēmums VmWare ir ieviesis DRS (Distribūtais resursu plānotājs) rīku, lai līdzsvarotu slodzi viņu izstrādātajā un piedāvātajā virtuālo resursu vidē.
Kā raksta
«VMware DRS (Distribūtais resursu plānotājs) ir rīks, kas līdzsvaro skaitļošanas slodzes ar pieejamajiem resursiem virtuālā vidē. Rīks ir daļa no virtualizācijas paketes, ko sauc par VMware Infrastructure.
Izmantojot VMware DRS, lietotāji nosaka noteikumus, kā sadalīt fiziskos resursus starp virtuālajām mašīnām (VM). Rīku var konfigurēt, lai tas darbotos manuāli vai automātiski. VMware resursu grupas var viegli pievienot, dzēst vai reorganizēt. Ja vēlas, resursu grupas var izolēt starp dažādām biznesa vienībām. Ja slodze uz vienu vai vairākām virtuālajām mašīnām strauji mainās, VMware DRS pārdala virtuālās mašīnas starp fiziskajiem serveriem. Ja kopējā slodze samazinās, daži fiziskie serveri var tikt pagaidu izslēgti, un slodze tiek konsolidēta.»
Kāpēc ir nepieciešama līdzsvarošana?
Mūsuprāt, DRS ir obligāta funkcija mākonim, lai gan tas nenozīmē, ka DRS ir jāizmanto vienmēr un visur. Atkarībā no mākoņa mērķiem un vajadzībām var pastāvēt dažādas prasības DRS un līdzsvarošana metodēm. Var būt situācijas, kad līdzsvarošana nav nepieciešama vispār. Vai pat kaitīga.
Lai labāk saprastu, kur un kādiem klientiem ir nepieciešams DRS, aplūkosim viņu mērķus un uzdevumus. Mākoņus var iedalīt publiskajos un privātajos. Šie ir galvenie šo mākoņu un klientu mērķu atšķirības.
Privātie mākoņi / Lielie uzņēmumu klienti
Publiskie mākoņi / Vidēja un maza biznesa, cilvēki
Galvenais operators kritērijs un mērķi
Nodrošināt uzticamu pakalpojumu vai produktu
Servisu izmaksu samazināšana konkurējošā tirgū
Prasības pakalpojumiem
Uzticamība visos sistēmas līmeņos un elementu
Garantēta veiktspēja
Virtuālo mašīnu prioritizācija vairākās kategorijās
Informācijas un fiziskā datu drošība
SLA un visu diennakti pieejama atbalsta
Maksimāla pakalpojuma iegūšanas vienkāršība
Salīdzinoši vienkārši pakalpojumi
Atbildība par datiem gulstas uz klienta
VM prioritizācija nav nepieciešama
Informācijas drošība tipisku pakalpojumu līmenī, atbildība uz klientu
Iespējami traucējumi
Nav SLA, kvalitāte netiek garantēta
Atbalsts pa e-pastu
Datu dublēšana nav obligāta
Klienta iespējas
Ļoti plašs lietojumprogrammu klāsts.
Legacy lietojumprogrammas, kas mantojusi uzņēmumā.
Sarežģītas pielāgotas arhitektūras katram klientam.
Afinitātes noteikumi.
Programmatūras darbība bez pārtraukumiem 7x24 režīmā.
Dublēšanas rīki "uz vietas".
Prognozējama cikliski pieprasītā slodze no klienta.
Tipiskas lietojumprogrammas – tīkla līdzsvarošana, Apache, WEB, VPN, SQL
Iespējama lietojumprogrammas apturēšana uz dažām laika
Atļauts brīvi sadalīt VM mākoņa vidē
Datu dublēšana ar klienta palīdzību
Prognozējama vidējā slodze, ja ir liels klientu skaits.
Sekojošās arhitektūras
Ģeoklasterizācija
Centrālizētas vai sadalītas datu glabāšanas sistēmas
Rezervējama SRK
Vietējā datu glabāšana uz aprīkojuma mezgliem
Sadalīšanas mērķi
Vienmērīga slodzes sadale
Maksimāla programmu atbildes spēja
Minimālais laiks līdzsvarošanai
Līdzsvarošana tikai acīmredzamas nepieciešamības gadījumā
Daļas aprīkojuma izņemšana profilaktiskai apkopei
Pakalpojumu izmaksu un operatora izdevumu samazināšana
Daļas resursu izslēgšana zemas slodzes gadījumā
Elektroenerģijas ietaupījums
Personāla izdevumu samazināšana
Mēs izdarām šādus secinājumus:
Privātajiem mākoņiem, ko piegādā lieliem korporatīvajiem pasūtītājiem, DRS var pielietot, ņemot vērā ierobežojumus:
- informācijas drošība un afinitātes noteikumu ievērošana līdzsvarošanas laikā;
- ja nepieciešams, rezerve par pietiekamu resursu apjomu avārijas gadījumā;
- virtuālo mašīnu dati ir centralizētā vai sadalītā datu glabāšanā;
- laika izkliede administrēšanas, datu dublēšanas un līdzsvarozes procedūrām;
- līdzsvarošana tikai klienta hostu agregāta ietvaros;
- līdzsvarošana tikai tad, ja ir būtisks nelīdzsvarotība, visefektīvākās un drošākās VM migrācijas (jo migrācija var beigties neveiksmīgi);
- līdzsvarošana attiecībā uz "mierīgām" virtuālām mašīnām ("troļļojošās" VM migrācija var ilgt ļoti ilgi);
- līdzsvarošana ņemot vērā "izmaksas" — slodzes uz krātuvi un tīklu (pielāgotās arhitektūras lieliem klientiem);
- līdzsvarošana ņemot vērā katras VM individuālās uzvedības īpatnības;
- līdzsvarošana ieteicama ārpus darba laika (naktīs, brīvdienās, svētkos).
Publiskajām mākonīm, kas sniedz pakalpojumus mazajiem klientiem, DRS var tikt pielietots daudz biežāk, ar paplašinātām iespējām:
- kiberdrošības ierobežojumu un afinitātes noteikumu neesamība;
- līdzsvarošana mākonī;
- līdzsvarošana jebkurā saprātīgā laikā;
- līdzsvarošana jebkura VM;
- līdzsvarošana "troļļojošām" virtuālām mašīnām (lai netraucētu pārējām);
- virtūlo mašīnu dati bieži atrodas vietējās diskos;
- vidējās veiktspējas uzglabāšanā un tīklā (mākoņa arhitektūra ir vienota);
- līdzsvarošana, balstoties uz vispārīgiem noteikumiem un pieejamo datu centru uzvedības statistiku.
Problēmas sarežģītība
Līdzsvarozes sarežģītība slēpjas faktā, ka DRS jādarbojas ar daudziem nezināmiem faktoriem:
- katras klientu informācijas sistēmas lietotāju uzvedība;
- informācijas sistēmu serveru darba algoritmi;
- DBMS serveru uzvedība;
- slodze uz aprēķinu resursiem, krātuvi, tīklu;
- serveru savstarpēja mijiedarbība cīņā par mākoņa resursiem.
Lielā skaitā virtuālo lietojumserveru un datu bāzu slodze uz mākoņa resursiem attīstās laika gaitā, sekas var parādīties un uzkrāties viena uz otras ar neparedzamu efektu neparedzamā laikā. Pat salīdzinoši vienkāršu procesu vadībai (piemēram, dzinēja vai mājas ūdensapkures sistēmas vadīšanai) automātiskajām regulēšanas sistēmām ir jāizmanto sarežģīti algoritmi ar atgriezenisko saiti.
Mūsu uzdevums ir vairākas reizes sarežģītāks, un pastāv risks, ka sistēma saprātīgā laikā nespēs nodrošināt slodzes līdzsvaru uz stabilizētiem rādītājiem, pat ja nebūs ārējās ietekmes no lietotājiem.
Mūsu attīstības vēsture
Lai risinātu šo problēmu, mēs nolēmām nesākt no nulles, bet balstīties uz esošo pieredzi un sākt sadarboties ar speciālistiem, kuriem ir pieredze šajā jomā. Par laimi, mūsu izpratne par problēmām bija pilnīgi saskaņota.
Posms 1
Mēs izmantojām sistēmu, kas balstīta uz neironu tīklu tehnoloģiju, un mēģinājām tās ietvaros optimizēt mūsu resursus.
Šī posma interesē bija jaunās tehnoloģijas testēšana, bet tā nozīmība – nestandarta pieejas piemērošana uzdevuma risināšanā, kur citu apstākļu vienādības standartmetodes bija praktiski izsīkušas.
Mēs palaižām sistēmu, un tiešām sākās slodzes līdzsvars. Mūsu mākoņa mērogs neļāva iegūt optimistiskus rezultātus, kādus bija paziņojuši izstrādātāji, taču bija redzams, ka līdzsvars darbojas.
Tomēr mums bija diezgan nopietni ierobežojumi:
- Lai apmācītu neironu tīklu, ir nepieciešams, lai virtuālās mašīnas darbotos bez būtiskām izmaiņām nedēļām vai mēnešiem.
- Algoritms ir paredzēts optimizācijai, balstoties uz iepriekšējiem «vēsturiskajiem» datiem.
- Lai apmācītu neironu tīklu, nepieciešams pietiekami liels datu apjoms un skaitļošanas resursi.
- Optimizāciju un slodzes līdzsvaru var veikt salīdzinoši reti – reizi dažās stundās, kas noteikti ir nepietiekami.
Posms 2
Tā kā mūs neapmierināja esošā situācija, mēs nolēmām modificēt sistēmu, un, lai to izdarītu, atbildēt uz galveno jautājumu – priekš kā mēs to izstrādājam?
Vispirms – uzņēmumu klientiem. Tas nozīmē, ka mums ir nepieciešama sistēma, kas darbojas operatīvi, ierobežojumu ietvaros, kas tikai atvieglo realizāciju.
Otrais jautājums – ko saprast ar vārdu «operatīvi»? Pēc īsām debatēm mēs nolēmām, ka varam orientēties uz reakcijas laiku 5 – 10 minūtes, lai īslaicīgas svārstības neievestu sistēmu rezonansē.
Trešais jautājums – kādu serveru līdzsvarojamo apjomu izvēlēties?
Šī problēma atrisinājās pati par sevi. Parasti klienti neveido serveru agregātus pārāk lielus, un tas atbilst ieteikumiem, kas minēti rakstā par agregātu ierobežošanu līdz 30-40 serveriem.
Turklāt, segmentējot serveru krājumu, mēs atvieglojam uzdevumu līdzsvara algoritmam.
Ceturtais jautājums – cik piemērota mums ir neironu tīkls ar tā ilgo mācīšanās procesu un reāla laika līdzsvarošanu? Mēs nolēmām atteikties no tā, izvēloties vienkāršākus operatīvos algoritmus, lai iegūtu rezultātus sekunžu laikā.
Ar sistēmas aprakstu, kas izmanto šādus algoritmus un tās trūkumiem, var iepazīties
Mēs ieviesām un palaidām šo sistēmu un saņēmām cerinošus rezultātus – tagad tā regulāri analizē mākoņa slodzi un sniedz ieteikumus par virtuālo mašīnu pārvietošanu, kuri lielā mērā ir pareizi. Pat tagad redzams, ka mēs varam panākt 10-15% resursu atbrīvošanu jaunām virtuālajām mašīnām, uzlabojot esošo kvalitāti.
Atklājot disbalansu RAM vai CPU, sistēma dod rīkojumus Tionix plānotājam veikt dzīvu migrāciju nepieciešamajām virtuālajām mašīnām. Kā redzams no uzraudzības sistēmas, virtuālā mašīna pārcēlās no viena (augšējā) uz citu (apakšējo) hostu un atbrīvoja atmiņu augšējā hostā (atzīmēta dzeltenās aplīšos), ieņemot to attiecīgi apakšējā (atzīmēta baltajos aplīšos).
Pašlaik mēs cenšamies precīzāk novērtēt esošā algoritma efektivitāti un cenšamies atrast iespējamās kļūdas tajā.
Posms 3
Izklausās, ka uz to varētu apstāties, gaidīt pierādītu efektivitāti un slēgt šo tēmu.
Tomēr mūs mudina veikt jaunu posmu, ņemot vērā šīs acīm redzamās optimizācijas iespējas
- Statistika, piemēram, un parāda, ka divu un četru procesa sistēmas pēc savas veiktspējas ir ievērojami zemākas nekā vienprocesoru sistēmas. Tas nozīmē, ka visi lietotāji iegūst no pirkuma daudzprocesoru sistēmās CPU, RAM, SSD, LAN, FC būtiski mazāku atdevi, salīdzinot ar vienprocesoru sistēmām.
- Paši resursu plānotāji var strādāt ar nopietnām kļūdām, par šo tēmu.
- Intel un AMD piedāvātās tehnoloģijas RAM un kešatmiņas uzraudzībai ļauj izpētīt virtuālo mašīnu uzvedību un izvietot tās tādā veidā, lai "skaļie" kaimiņi netraucētu "mierīgajām" virtuālajām mašīnām.
- Paplašināt parametru kopu (tīkls, SAN, virtuālās mašīnas prioritāte, migrācijas izmaksas, tās gatavība migrācijai).
Kopējā summa
Mūsu darbu rezultāts algoritmu optimizēšanā sniedza skaidru secinājumu, ka, izmantojot mūsdienīgus algoritmus, var panākt ievērojamu datu centru resursu optimizāciju (25-30%) un tajā pašā laikā uzlabot klientu apkalpošanas kvalitāti.
Algoritms, kas balstās uz neirotīklu, ir noteikti interesants, bet prasa tālāku attīstību un esošo ierobežojumu dēļ nav piemērots šāda veida uzdevumiem apjomos, kas raksturīgi privātiem mākoņiem. Tomēr publiskajos mākoņos, kas ir ievērojamā izmērā, algoritms parādīja labus rezultātus.
Sīkāk par procesoru, plānotāju un augsta līmeņa līdzsvarošanu runāsim nākamajos rakstos.
Avots: habr.com
