Izravnavanje obremenitve v Openstacku (2. del)

В zadnji članek govorili smo o naših poskusih uporabe Watcherja in predložili poročilo o preskusu. Občasno izvajamo takšne teste za uravnoteženje in druge kritične funkcije velikega podjetja ali operaterskega oblaka.

Visoka kompleksnost problema, ki ga rešujemo, bo morda zahtevala več člankov za opis našega projekta. Danes objavljamo drugi članek v seriji, ki je posvečen uravnoteženju virtualnih strojev v oblaku.

Nekaj ​​terminologije

Podjetje VmWare je predstavilo pripomoček DRS (Distributed Resource Scheduler) za uravnoteženje obremenitev virtualizacijskega okolja, ki so ga razvili in ponudili.

Kot piše searchvmware.techtarget.com/definition/VMware-DRS
»VMware DRS (Distributed Resource Scheduler) je pripomoček, ki uravnava računalniške obremenitve z razpoložljivimi viri v virtualnem okolju. Pripomoček je del paketa za virtualizacijo, imenovanega VMware Infrastructure.

Z VMware DRS uporabniki določijo pravila za distribucijo fizičnih virov med virtualnimi stroji (VM). Pripomoček je mogoče konfigurirati za ročni ali samodejni nadzor. Baze virov VMware je mogoče preprosto dodati, odstraniti ali reorganizirati. Če želite, lahko bazene virov izolirate med različnimi poslovnimi enotami. Če se delovna obremenitev na enem ali več virtualnih strojih močno spremeni, VMware DRS prerazporedi virtualne stroje po fizičnih strežnikih. Če se skupna delovna obremenitev zmanjša, bodo nekateri fizični strežniki morda začasno onemogočeni, delovna obremenitev pa konsolidirana."

Zakaj je potrebno uravnoteženje?

Po našem mnenju je DRS obvezna funkcija oblaka, vendar to ne pomeni, da je treba DRS uporabljati vedno in povsod. Odvisno od namena in potreb oblaka lahko obstajajo različne zahteve za DRS in metode uravnoteženja. Obstajajo lahko situacije, ko uravnoteženje sploh ni potrebno. Ali celo škodljivo.

Da bi bolje razumeli, kje in za katere stranke je DRS potreben, razmislimo o njihovih ciljih in ciljih. Oblake lahko razdelimo na javne in zasebne. Tu so glavne razlike med temi oblaki in cilji strank.

Zasebni oblaki / odjemalci velikih podjetij
Javni oblaki / Srednja in mala podjetja, ljudje

Glavno merilo in cilji operaterja
Zagotavljanje zanesljive storitve ali izdelka
Zniževanje stroškov storitev v boju na konkurenčnem trgu

Zahteve za storitve
Zanesljivost na vseh ravneh in v vseh elementih sistema

Zajamčena zmogljivost

Razvrstite virtualne stroje po prednosti v več kategorij 

Informacijska in fizična varnost podatkov

SLA in podpora XNUMX/XNUMX
Največja enostavnost prejemanja storitve

Relativno preproste storitve

Za podatke je odgovoren naročnik

Določanje prednosti VM ni potrebno

Informacijska varnost na ravni standardnih storitev, odgovornost na naročniku

Lahko pride do napak

Brez SLA, kakovost ni zagotovljena

Podpora po e-pošti

Varnostno kopiranje ni potrebno

Funkcije odjemalca
Zelo širok spekter uporabe.

Stare aplikacije, podedovane v podjetju.

Kompleksne arhitekture po meri za vsako stranko.

Pravila afinitete.

Programska oprema deluje brez ustavljanja v načinu 7x24. 

Orodja za sprotno varnostno kopiranje.

Predvidljiva ciklična obremenitev strank.
Tipične aplikacije – uravnoteženje omrežja, Apache, WEB, VPN, SQL

Aplikacija se lahko za nekaj časa ustavi

Omogoča poljubno distribucijo VM-jev v oblaku

Varnostno kopiranje odjemalca

Predvidljiva statistično povprečna obremenitev z velikim številom strank.

Posledice za arhitekturo
Geogručenje

Centralizirano ali porazdeljeno shranjevanje

Pridržan IBS
Lokalno shranjevanje podatkov na računalniških vozliščih

Uravnoteženje ciljev
Enakomerna porazdelitev obremenitve

Največja odzivnost aplikacij 

Minimalni zakasnitveni čas za uravnoteženje

Uravnoteženje le, ko je nujno potrebno

Prinašanje nekaj opreme za preventivno vzdrževanje
Zmanjšanje stroškov storitev in stroškov operaterja 

Onemogočanje nekaterih virov v primeru nizke obremenitve

Varčevanje z energijo

Zmanjšanje stroškov osebja

Sami sklepamo naslednje:

Za zasebne oblakeki se zagotavlja velikim poslovnim strankam, se DRS lahko uporablja ob upoštevanju naslednjih omejitev:

• informacijska varnost in upoštevanje pravil afinitete pri uravnoteženju;
• razpoložljivost zadostnih sredstev v rezervi za primer nesreče;
• podatki o virtualnem stroju se nahajajo v centraliziranem ali porazdeljenem sistemu za shranjevanje;
• osupljivi postopki upravljanja, varnostnega kopiranja in uravnoteženja skozi čas;
• uravnoteženje samo znotraj agregata odjemalskih gostiteljev;
• uravnoteženje le, ko obstaja močno neravnovesje, najbolj učinkovite in varne migracije VM (navsezadnje lahko migracija ne uspe);
• uravnoteženje razmeroma "tihih" virtualnih strojev (migracija "hrupnih" virtualnih strojev lahko traja zelo dolgo);
• uravnoteženje ob upoštevanju “stroška” - obremenitev pomnilniškega sistema in omrežja (s prilagojenimi arhitekturami za velike odjemalce);
• uravnoteženje ob upoštevanju individualnih značilnosti vedenja vsakega VM;
• Uravnoteženje se po možnosti izvaja v prostem času (noči, vikendi, prazniki).

Za javne oblakepri zagotavljanju storitev malim strankam se DRS lahko uporablja veliko pogosteje, z naprednimi zmogljivostmi:

• odsotnost omejitev glede informacijske varnosti in pravil afinitete;
• uravnoteženje v oblaku;
• izravnava v katerem koli razumnem času;
• uravnoteženje katerega koli VM;
• uravnoteženje "hrupnih" virtualnih strojev (da ne motijo ​​drugih);
• podatki o virtualnem stroju se pogosto nahajajo na lokalnih diskih;
• upoštevanje povprečne zmogljivosti sistemov za shranjevanje in omrežij (arhitektura oblaka je poenotena);
• uravnoteženje v skladu s splošnimi pravili in razpoložljivo statistiko obnašanja podatkovnega centra.

Kompleksnost problema

Težava pri uravnoteženju je v tem, da mora DRS delovati z velikim številom negotovih dejavnikov:

• obnašanje uporabnikov posameznega informacijskega sistema naročnika;
• algoritmi za delovanje strežnikov informacijskega sistema;
• obnašanje strežnikov DBMS;
• obremenitev računalniških virov, sistemov za shranjevanje, omrežja;
• interakcija strežnikov med seboj v boju za vire v oblaku.

Obremenitev velikega števila virtualnih aplikacijskih strežnikov in podatkovnih baz na oblačnih virih se pojavi skozi čas, posledice se lahko pokažejo in prekrivajo z nepredvidljivim učinkom v nepredvidljivem času. Tudi za krmiljenje sorazmerno preprostih procesov (na primer za krmiljenje motorja, sistema za ogrevanje vode doma) morajo avtomatski krmilni sistemi uporabljati zapletene proporcionalno-integralno-diferencialno algoritmi s povratnimi informacijami.

Naša naloga je za veliko redov velikosti bolj zapletena in obstaja tveganje, da sistem ne bo mogel uravnotežiti obremenitve na uveljavljene vrednosti v razumnem času, tudi če ni zunanjih vplivov uporabnikov.

Zgodovina našega razvoja

Da bi rešili to težavo, smo se odločili, da ne bomo začeli iz nič, ampak bomo gradili na obstoječih izkušnjah in začeli sodelovati s strokovnjaki z izkušnjami na tem področju. Na srečo se je naše razumevanje problema popolnoma ujemalo.

Stopnja 1

Uporabili smo sistem, ki temelji na tehnologiji nevronskih mrež in na njegovi podlagi poskušali optimizirati naše vire.

Interes te faze je bil testiranje nove tehnologije, njen pomen pa je bil v uporabi nestandardnega pristopa k reševanju problema, kjer so se standardni pristopi, če so ostali enaki, praktično izčrpali.

Zagnali smo sistem in res začeli uravnotežiti. Obseg našega oblaka nam ni omogočil, da bi dobili optimistične rezultate, ki so jih navedli razvijalci, vendar je bilo jasno, da uravnoteženje deluje.

Hkrati smo imeli precej resne omejitve:

• Za usposabljanje nevronske mreže morajo virtualni stroji delovati brez bistvenih sprememb več tednov ali mesecev.
• Algoritem je zasnovan za optimizacijo na podlagi analize prejšnjih "zgodovinskih" podatkov.
• Usposabljanje nevronske mreže zahteva precej veliko količino podatkov in računalniških virov.
• Optimizacijo in izravnavo lahko izvajamo razmeroma redko – enkrat na nekaj ur, kar pa očitno ni dovolj.

Stopnja 2

Ker s stanjem nismo bili zadovoljni, smo se odločili za spremembo sistema in za to odgovor glavno vprašanje – za koga ga izdelujemo?

Prvič - za poslovne stranke. To pomeni, da potrebujemo sistem, ki deluje hitro, s tistimi korporativnimi omejitvami, ki samo poenostavijo implementacijo.

Drugo vprašanje – kaj mislite z besedo »takoj«? Po krajši debati smo se odločili, da lahko začnemo z odzivnim časom 5–10 minut, da kratkotrajni sunki ne bi spravili sistema v resonanco.

Tretje vprašanje – kakšno velikost uravnoteženega števila strežnikov izbrati?
Ta težava se je rešila sama od sebe. Običajno odjemalci združevanja strežnikov ne naredijo zelo velikih, kar je skladno s priporočili v članku, da se združevanja omejijo na 30–40 strežnikov.

Poleg tega s segmentacijo strežniškega bazena poenostavimo nalogo algoritma za izravnavo.

Četrto vprašanje – kako primerna je za nas nevronska mreža s svojim dolgim ​​procesom učenja in redkim uravnovešanjem? Odločili smo se, da ga opustimo v korist enostavnejših operativnih algoritmov, da bi dobili rezultate v nekaj sekundah.

Opis sistema, ki uporablja takšne algoritme, in njegove slabosti lahko najdete tukaj

Ta sistem smo implementirali in zagnali ter prejeli spodbudne rezultate – sedaj redno analizira obremenitev oblaka in daje priporočila za premikanje virtualnih strojev, ki so v veliki meri pravilna. Že zdaj je jasno, da lahko dosežemo 10-15% sprostitev virov za nove virtualne stroje ob izboljšanju kakovosti dela obstoječih.

Ko je zaznano neravnovesje v RAM-u ali CPE-ju, sistem izda ukaze razporejevalniku Tionix za izvedbo selitve v živo zahtevanih virtualnih strojev. Kot je razvidno iz nadzornega sistema, se je virtualni stroj premaknil z enega (zgornjega) na drugega (spodnjega) gostitelja in sprostil pomnilnik na zgornjem gostitelju (označeno z rumenimi krogi) oziroma ga je zasedel na spodnjem gostitelju (označeno z belo krogi).

Zdaj poskušamo natančneje oceniti učinkovitost trenutnega algoritma in poskušamo najti morebitne napake v njem.

Stopnja 3

Zdi se, da se lahko o tem umirite, počakate na dokazano učinkovitost in zaprete temo.
Toda k izvedbi nove faze nas prisilijo naslednje očitne priložnosti za optimizacijo

1. Statistika npr. tukaj и tukaj kaže, da so dvo- in štiriprocesorski sistemi znatno slabše zmogljivi kot enoprocesorski sistemi. To pomeni, da vsi uporabniki prejmejo bistveno manj izhoda iz CPU, RAM-a, SSD-ja, LAN-a, FC-ja, kupljenega v večprocesorskih sistemih v primerjavi z enoprocesorskimi.
2. Sami načrtovalci virov imajo lahko resne napake, tukaj je eden od člankov na to temo.
3. Tehnologije, ki jih ponujata Intel in AMD za spremljanje RAM-a in predpomnilnika, omogočajo preučevanje obnašanja virtualnih strojev in njihovo namestitev tako, da "hrupni" sosedje ne motijo ​​"tihih" virtualnih strojev.
4. Razširitev nabora parametrov (omrežje, sistem za shranjevanje, prioriteta virtualnega stroja, stroški migracije, njegova pripravljenost na migracijo).

Skupno

Rezultat našega dela za izboljšanje algoritmov za uravnoteženje je bil jasen zaključek, da je z uporabo sodobnih algoritmov mogoče doseči znatno optimizacijo virov podatkovnega centra (25-30%) in hkrati izboljšati kakovost storitev za stranke.

Algoritem, ki temelji na nevronskih mrežah, je vsekakor zanimiva rešitev, ki pa jo je treba še razvijati in zaradi obstoječih omejitev ni primeren za reševanje tovrstnih problemov na volumnih, značilnih za privatne oblake. Hkrati je algoritem pokazal dobre rezultate v javnih oblakih velike velikosti.

V naslednjih člankih vam bomo povedali več o zmožnostih procesorjev, načrtovalcev in uravnoteženja na visoki ravni.

Vir: www.habr.com