V Povedali smo o poskusih uporabe Watcher in predstavili poročilo o testiranju. Takšna testiranja občasno izvajamo za uravnoteženje in druge kritične funkcije velikega korporativnega ali operaterskega oblaka.
Visoka kompleksnost rešenega problema bo morda zahtevala več člankov za opis našega projekta. Danes objavljamo drugi članek v ciklu, posvečen uravnoteženju virtualnih strežnikov v oblaku.
Nekaj terminologije
Podjetje VmWare je uvedlo orodje DRS (Distributed Resource Scheduler) za uravnoteženje obremenitev v svojem razvojnem in ponudbenem okolju virtualizacije.
Kako piše
VMware DRS (Načrtovalnik distribuiranih virov) je orodje, ki uravnava računalniške obremenitve z razpoložljivimi viri v virtualnem okolju. Orodje je del paket virtualizacije, imenovan VMware Infrastructure.
S pomočjo VMware DRS uporabniki določajo pravila za dodelitev fizičnih virov med virtualnimi strežniki (VS). Orodje je mogoče nastaviti za ročno ali samodejno upravljanje. VMware skladišča virov je enostavno dodati, odstraniti ali reorganizirati. Po želji so lahko skladišča virov izolirana med različnimi poslovnimi enotami. Če se obremenitev na eni ali več virtualnih strežnikih nenadoma spremeni, VMware DRS preuredi virtualne strežnike med fizičnimi strežniki. Če se skupna obremenitev zmanjša, se nekateri fizični strežniki lahko začasno izključijo, delovna obremenitev pa se konsolidira.
Zakaj je potrebna uravnoteženost?
Po našem mnenju je DRS obvezna funkcija oblaka, čeprav to ne pomeni, da je treba DRS uporabljati vedno in povsod. Glede na namen in potrebe oblaka lahko obstajajo različne zahteve glede DRS in metod uravnoteženja. Morda obstajajo situacije, ko uravnoteženje sploh ni potrebno. Ali je celo škodljivo.
Da bi bilo bolje razumeti, kje in za katere stranke je DRS potrebna, si oglejmo njihove cilje in naloge. Oblaki lahko razdelimo na javne in zasebne. Tukaj so glavne razlike med temi oblaki in cilji strank.
Zasebni oblaki / Velike korporativne stranke
Javni oblaki / Srednje in majhno podjetje, posamezniki
Glavni kriterij in cilji operaterja
Nudenje zanesljive storitve ali izdelka
Znižanje stroškov storitev v konkurentnem trgu
Zahteve za storitev
Zanesljivost na vseh ravneh in v vseh elementih sistema
Zagotovljena zmogljivost
Prioritizacija virtualnih naprav v več kategorijah
Informacijska in fizična varnost podatkov
SLA in 24/7 podpora
Največja enostavnost pri pridobivanju storitve
Relativno preproste storitve
Odgovornost za podatke je na stranki
Prioritizacija VM ni potrebna
Informacijska varnost na ravni standardnih storitev, odgovornost na stranki
Lahko pride do izpadov
Brez SLA, kakovost ni zagotovljena
Podpora preko e-pošte
Varnostno kopiranje ni obvezno
Posebnosti stranke
Zelo širok spekter aplikacij.
Legacy aplikacije, prevzete v podjetju.
Zapletene prilagojene arhitekture za vsako stranko.
Affinity pravila.
Delovanje programske opreme brez prekinitev v načinu 7x24.
Orodja za varnostno kopiranje "v realnem času".
Predvidljiva ciklična obremenitev stranke.
Standardne aplikacije – uravnoteženje omrežja, Apache, WEB, VPN, SQL
Mogoče je začasno ustaviti aplikacijo
Dovoljeno je poljubno razporejanje VM v oblaku
Varnostno kopiranje s strani stranke
Predvidljiva statistična povprečna obremenitev pri velikem številu strank.
Posledice za arhitekturo
Geoklasterizacija
Centraliziran ali distribuiran SAN
Rezervirana SRK
Lokalno shranjevanje podatkov na računskih vozliščih
Cilji uravnoteženja
Enakomerno razporejanje obremenitve
Največja odzivnost aplikacij
Minimalni čas zakasnitve pri uravnoteženju
Uravnoteženje le v primeru očitne potrebe
Odklop dela opreme za preventivno vzdrževanje
Znižanje stroškov storitve in stroškov operaterja
Odklop dela virov v primeru nizke obremenitve
Prihranek pri električni energiji
Zmanjšanje stroškov za osebje
Sklepamo naslednje:
Za zasebne oblake, ki jih zagotavljajo veliki korporativni naročniki, se DRS lahko uporablja ob upoštevanju omejitev:
- informacijska varnost in upoštevanje pravil affiniteta pri uravnoteženju;
- zadostna količina virov v rezervi v primeru izredne situacije;
- podatki virtualnih naprav so shranjeni na centraliziranem ali distribuiranem SAN;
- razporeditev administrativnih, varnostnih kopij in uravnoteževalnih postopkov v času;
- uravnoteženje le znotraj skupine gostiteljev stranke;
- uravnoteženje le pri močnem neravnovesju, najuspešnejše in najsigurnejše migracije VM (saj se migracija lahko konča neuspešno);
- uravnoteženje glede na 'mirne' virtualne strežnike (migracija 'hrupnih' virtualnih strežnikov lahko traja zelo dolgo);
- uravnoteženje ob upoštevanju 'stroškov' — obremenitev na SHR in omrežju (pri prilagojenih arhitekturah za velike stranke);
- uravnoteženje ob upoštevanju individualnih značilnosti vedenja vsake VM;
- uravnoteženje naj bo izvedeno v neobratovalnem času (ponoči, ob koncih tedna, praznikih).
Za javne oblake, ki nudijo storitve manjšim naročnikom, se DRS lahko uporablja veliko pogosteje, z razširjenimi možnostmi:
- brez omejitev informacijske varnosti in pravil afinitete;
- uravnoteženje znotraj oblaka;
- uravnoteženje ob vsakem razumnem času;
- uravnoteženje katerekoli VM;
- uravnoteženje 'hrupnih' virtualnih strežnikov (da ne motimo drugih);
- podatki virtualnih strežnikov se pogosto nahajajo na lokalnih disku;
- upoštevanje povprečne zmogljivosti SHR in omrežja (arhitektura oblaka je enotna);
- uravnoteženje po poenostavljenih pravilih in obstoječi statistiki obnašanja podatkovnih centrov.
Složenost problema
Složenost uravnoteženja je v tem, da mora DRS delovati z velikim številom nepredvidljivih dejavnikov:
- vedenje uporabnikov vsake od informacijskih sistemov strank;
- algoritmi delovanja strežnikov informacijskih sistemov;
- vedenje strežnikov DBMS;
- obremenitev procesorskih virov, SHR, omrežja;
- medsebojno delovanje strežnikov v boju za vire oblaka.
Obremenitev velikega števila virtualnih strežnikov aplikacij in podatkovnih virov se v času preoblikuje, posledice se lahko pojavljajo in prekrivajo druga drugo z nepredvidljivim učinkom ob nepredvidljivem času. Tudi za upravljanje razmeroma preprostih procesov (naprimer, za upravljanje motorja, sistema vodnega ogrevanja doma) morajo sistemi avtomatskega uravnavanja uporabljati zapletene algoritme s povratno informacijo.
Naša naloga je mnogo složena, a postoji rizik da sistem ne može ostvariti ravnotežu opterećenja u razumnom vremenu, čak i ako ne dođe do spoljašnjih uticaja od strane korisnika.
Istorija naših razvoja
Kako bismo rešili ovaj problem, odlučili smo da ne počinjemo ispočetka, već da se oslonimo na postojeće iskustvo i da sarađujemo sa stručnjacima koji već imaju iskustva u ovom polju. Na sreću, naše razumevanje problematike je potpuno odgovaralo.
Faza 1
Koristili smo sistem zasnovan na tehnologijama neuronskih mreža i pokušali smo da optimizujemo naše resurse na toj osnovi.
Interes ove faze leži u probanju nove tehnologije, a njena važnost je u primeni nekonvencionalnog pristupa rešavanju problema, gde su standardni pristupi ujednačenim uslovima gotovo iscrpljeni.
Pokrenuli smo sistem, i zaista smo postigli ravnotežu. Razmeru našeg oblaka nije omogućila da dobijemo optimistične rezultate koje su naveli programeri, ali je bilo jasno da ravnoteža funkcioniše.
Pri tome smo imali dovoljno ozbiljna ograničenja:
- Za obuku neuronske mreže potrebno je da virtuelne mašine rade bez značajnih promena tokom nedelja ili meseci.
- Algoritam je dizajniran za optimizaciju na osnovu analize prethodnih 'istorijskih' podataka.
- Za obuku neuronske mreže potrebna su dovoljna količina podataka i računarskih resursa.
- Optimizacija i ravnoteža mogu se raditi relativno retko – svaka nekoliko sati, što očigledno nije dovoljno.
Faza 2
Budući da nas je trenutna situacija nezadovoljavala, odlučili smo da modifikujemo sistem, i za to da odgovorimo na glavno pitanje – za koga to radimo?
Prvo – za korporativne klijente. Znači, potrebna nam je sistem koja funkcioniše operativno, sa onim korporativnim ograničenjima koja samo olakšavaju implementaciju.
Drugo pitanje – šta znači reč 'operativno'? Kao rezultat kratkih rasprava odlučili smo da se oslonimo na vreme reakcije od 5 do 10 minuta, kako kratkotrajne oscilacije ne bi uvodile sistem u rezonansu.
Treće pitanje – koju veličinu balansirane količine servera izabrati?
To vprašanje se je rešilo samo od sebe. Kot pravilo, stranke ne delajo agregatov strežnikov prevelikih, in to ustreza priporočilom iz članka, da se omeji agregate na 30-40 strežnikov.
Poleg tega, ko segmentiramo nabor strežnikov, poenostavimo nalogo algoritmu za obremenitveno uravnoteženje.
Četrto vprašanje – koliko nam ustreza nevronska mreža z njenim dolgotrajnim procesom učenja in redkimi uravnoteženji? Odločili smo se, da se je odpovemo v korist preprostejših operativnih algoritmov, da bi dosegli rezultate v sekundah.
O sistemu, ki uporablja take algoritme in njegovih pomanjkljivostih, si lahko preberete
Implementirali in zagnali smo ta sistem ter pridobili obetavne rezultate – trenutno 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 z izboljšanjem kakovosti dela obstoječih.
Ob odkrivanju neravnotežja po RAM-u ali CPU-ju sistem izda ukaze načrtovalniku Tionix za izvedbo žive migracije zahtevanih virtualnih strojev. Kot je razvidno iz sistema za spremljanje, je virtualni stroj preseljen z enega (zgornjega) na drugega (spodnjega) gostitelja in sprosti pomnilnik na zgornjem gostitelju (označeno z rumenimi krogi), pri tem pa zasede pomnilnik na spodnjem (označeno z belimi krogi).
Zdaj poskušamo bolj natančno ovrednotiti učinkovitost delujočega algoritma in poskušamo najti morebitne napake.
Korak 3
Zdi se, da bi se lahko tu ustavili, počakali na dokazane učinkovitosti in zaključili to temo.
Vendar nas naslednje očitne možnosti optimizacije spodbujajo k izvajanju novega koraka
- Statistika, na primer, in pokazuje, da so sisteme z dvema in štirimi procesorji v svoji zmogljivosti bistveno nižji od enoprocesorskih. To pomeni, da vsi uporabniki prejmejo od kupljenih v večprocesorskih sistemih CPU, RAM, SSD, LAN, FC znatno manjšo donosnost v primerjavi z enoprocesorskimi.
- Sami načrtovalci virov lahko delujejo z resnimi napakami, na to temo.
- Tehnologije za nadzor RAM-a i cache-a koje nude kompanije Intel i AMD omogućavaju analizu ponašanja virtuelnih mašina i njihovo postavljanje na način koji obezbeđuje da „bučni“ susedi ne ometaju rad „mirnih“ virtuelnih mašina.
- Proširenje niza parametara (mreža, skladištenje podataka, prioritet virtuelne mašine, trošak migracije, spremnost za migraciju).
Ukupno
Rezultat našeg rada na unapređenju algoritama za ravnotežu opterećenja jasno ukazuje na to da se modernim algoritmima može postići značajna optimizacija resursa (25-30%) u data centrima, kao i poboljšanje kvaliteta usluga za klijente.
Algoritam zasnovan na neuronskim mrežama predstavlja svakako zanimljivo, ali u razvoju rešenje, i zbog postojećih ograničenja nije pogodno za rešavanje takvih problema u obimima koji su karakteristični za privatne oblake. Ipak, u velikim javnim oblacima, algoritam je pokazao dobre rezultate.
Više o mogućnostima procesora, planera i visoko nivojske ravnoteže opterećenja reći ćemo u sledećim člancima.
Izvor: habr.com
