В razgovarali smo o našim pokušajima korištenja Watchera i dali izvješće o testiranju. Povremeno provodimo takve testove za balansiranje i druge kritične funkcije velikog poduzeća ili operaterskog oblaka.
Visoka složenost problema koji se rješava može zahtijevati nekoliko članaka za opis našeg projekta. Danas objavljujemo drugi članak u seriji posvećen balansiranju virtualnih strojeva u oblaku.
Nešto terminologije
Tvrtka VmWare predstavila je uslužni program DRS (Distributed Resource Scheduler) za uravnoteženje opterećenja virtualizacijskog okruženja koje su razvili i ponudili.
Kako piše
“VMware DRS (Distributed Resource Scheduler) je uslužni program koji uravnotežuje računalna opterećenja s dostupnim resursima u virtualnom okruženju. Uslužni program dio je virtualizacijskog paketa koji se zove VMware Infrastructure.
Uz VMware DRS, korisnici definiraju pravila za distribuciju fizičkih resursa između virtualnih strojeva (VM). Uslužni program može se konfigurirati za ručno ili automatsko upravljanje. Skupovi VMware resursa mogu se jednostavno dodati, ukloniti ili reorganizirati. Po želji, skupovi resursa mogu se izolirati između različitih poslovnih jedinica. Ako se radno opterećenje na jednom ili više virtualnih strojeva dramatično promijeni, VMware DRS redistribuira virtualna računala preko fizičkih poslužitelja. Ako se ukupno radno opterećenje smanji, neki fizički poslužitelji mogu biti privremeno isključeni, a radno opterećenje konsolidirano."
Zašto je potrebno balansiranje?
Po našem mišljenju, DRS je značajka oblaka koju morate imati, iako to ne znači da se DRS mora koristiti uvijek i svugdje. Ovisno o namjeni i potrebama oblaka, mogu postojati različiti zahtjevi za DRS i metode balansiranja. Mogu postojati situacije u kojima balansiranje uopće nije potrebno. Ili čak štetno.
Da bismo bolje razumjeli gdje i za koje klijente je DRS potreban, razmotrimo njihove ciljeve i ciljeve. Oblaci se mogu podijeliti na javne i privatne. Ovdje su glavne razlike između ovih oblaka i ciljeva kupaca.
Privatni oblaci / Veliki poslovni klijenti
Javni oblaci / Srednja i mala poduzeća, ljudi
Glavni kriterij i ciljevi operatera
Pružanje pouzdane usluge ili proizvoda
Smanjenje troškova usluga u borbi na konkurentskom tržištu
Zahtjevi usluge
Pouzdanost na svim razinama iu svim elementima sustava
Zajamčena izvedba
Prioritete virtualnih strojeva u nekoliko kategorija
Informacijska i fizička sigurnost podataka
SLA i podrška XNUMX/XNUMX
Maksimalna jednostavnost primanja usluge
Relativno jednostavne usluge
Odgovornost za podatke snosi naručitelj
Nije potrebno određivanje prioriteta VM-a
Informacijska sigurnost na razini standardnih usluga, odgovornost na klijentu
Može biti grešaka
Nema SLA, kvaliteta nije zajamčena
Podrška e-poštom
Sigurnosna kopija nije potrebna
Značajke klijenta
Vrlo širok raspon primjena.
Naslijeđene aplikacije naslijeđene u tvrtki.
Složene prilagođene arhitekture za svakog klijenta.
Pravila afiniteta.
Softver radi bez zaustavljanja u načinu rada 7x24.
On-the-fly alati za sigurnosno kopiranje.
Predvidljivo cikličko opterećenje korisnika.
Tipične aplikacije – balansiranje mreže, Apache, WEB, VPN, SQL
Aplikacija se može zaustaviti na neko vrijeme
Omogućuje proizvoljnu distribuciju VM-ova u oblaku
Sigurnosna kopija klijenta
Predvidljivo statistički prosječno opterećenje s velikim brojem klijenata.
Implikacije za arhitekturu
Geoklasteriranje
Centralizirana ili distribuirana pohrana
Rezervirani IBS
Lokalna pohrana podataka na računalnim čvorovima
Balansiranje ciljeva
Ravnomjerna raspodjela opterećenja
Maksimalni odziv aplikacije
Minimalno vrijeme kašnjenja za balansiranje
Balansiranje samo kada je to neophodno
Iznošenje neke opreme radi preventivnog održavanja
Smanjenje troškova usluga i troškova operatera
Onemogućavanje nekih resursa u slučaju niskog opterećenja
Štednja energije
Smanjenje troškova osoblja
Za sebe izvlačimo sljedeće zaključke:
Za privatne oblakekoji se pruža velikim korporativnim klijentima, DRS se može koristiti uz sljedeća ograničenja:
- informacijska sigurnost i uzimanje u obzir pravila afiniteta pri balansiranju;
- dostupnost dovoljnih resursa u rezervi u slučaju nesreće;
- podaci virtualnog stroja nalaze se na centraliziranom ili distribuiranom sustavu za pohranu;
- zapanjujući postupci administracije, sigurnosne kopije i balansiranja tijekom vremena;
- balansiranje samo unutar agregata klijentskih hostova;
- balansiranje samo kada postoji jaka neravnoteža, najučinkovitije i najsigurnije VM migracije (uostalom, migracija može propasti);
- balansiranje relativno "tihih" virtualnih strojeva (migracija "bučnih" virtualnih strojeva može potrajati jako dugo);
- balansiranje uzimajući u obzir “trošak” - opterećenje sustava za pohranu i mreže (s prilagođenim arhitekturama za velike klijente);
- balansiranje uzimajući u obzir individualne karakteristike ponašanja svakog VM-a;
- Balansiranje je poželjno raditi u neradno vrijeme (noći, vikendi, praznici).
Za javne oblakepružajući usluge malim korisnicima, DRS se može koristiti puno češće, s naprednim mogućnostima:
- nepostojanje ograničenja informacijske sigurnosti i pravila srodnosti;
- balansiranje unutar oblaka;
- balansiranje u bilo kojem razumnom vremenu;
- balansiranje bilo kojeg VM-a;
- balansiranje "bučnih" virtualnih strojeva (kako ne bi ometali druge);
- podaci virtualnog stroja često se nalaze na lokalnim diskovima;
- uzimajući u obzir prosječne performanse sustava za pohranu podataka i mreža (arhitektura oblaka je unificirana);
- balansiranje prema općim pravilima i dostupnoj statistici ponašanja podatkovnog centra.
Složenost problema
Poteškoća balansiranja je u tome što DRS mora raditi s velikim brojem neizvjesnih faktora:
- ponašanje korisnika svakog od informacijskih sustava klijenata;
- algoritmi za rad poslužitelja informacijskog sustava;
- ponašanje DBMS poslužitelja;
- opterećenje računalnih resursa, sustava za pohranu podataka, mreže;
- međusobna interakcija poslužitelja u borbi za resurse oblaka.
Opterećenje velikog broja virtualnih aplikacijskih poslužitelja i baza podataka na cloud resursima događa se tijekom vremena, posljedice se mogu manifestirati i međusobno preklapati s nepredvidivim učinkom kroz nepredvidivo vrijeme. Čak i za upravljanje relativno jednostavnim procesima (na primjer, za upravljanje motorom, sustavom grijanja vode kod kuće), automatski sustavi upravljanja moraju koristiti složene algoritmi s povratnom spregom.
Naš je zadatak mnogo redova veličine složeniji i postoji rizik da sustav neće moći uravnotežiti opterećenje na utvrđene vrijednosti u razumnom vremenu, čak i ako nema vanjskih utjecaja korisnika.
Povijest našeg razvoja
Kako bismo riješili ovaj problem, odlučili smo ne krenuti od nule, već graditi na postojećem iskustvu i počeli smo komunicirati sa stručnjacima s iskustvom u ovom području. Srećom, naše se razumijevanje problema potpuno poklopilo.
Stad 1
Koristili smo sustav temeljen na tehnologiji neuronske mreže i pokušali optimizirati naše resurse na temelju nje.
Interes ove faze bio je u testiranju nove tehnologije, a njezina važnost bila je u primjeni nestandardnog pristupa rješavanju problema gdje su, pod ostalim jednakim uvjetima, standardni pristupi praktički iscrpili sebe.
Pokrenuli smo sustav i stvarno smo počeli balansirati. Razmjer našeg oblaka nije nam omogućio da dobijemo optimistične rezultate koje su naveli programeri, ali bilo je jasno da balansiranje funkcionira.
U isto vrijeme, imali smo prilično ozbiljna ograničenja:
- Za treniranje neuronske mreže, virtualni strojevi trebaju raditi bez značajnih promjena tjednima ili mjesecima.
- Algoritam je dizajniran za optimizaciju na temelju analize ranijih “povijesnih” podataka.
- Uvježbavanje neuronske mreže zahtijeva prilično veliku količinu podataka i računalnih resursa.
- Optimizacija i balansiranje mogu se raditi relativno rijetko – jednom u nekoliko sati, što očito nije dovoljno.
Stad 2
Budući da nismo bili zadovoljni stanjem stvari, odlučili smo modificirati sustav, a kako bismo to učinili, odgovorite glavno pitanje – za koga ga pravimo?
Prvo - za korporativne klijente. To znači da trebamo sustav koji radi brzo, s onim korporativnim ograničenjima koja samo pojednostavljuju implementaciju.
Drugo pitanje – što mislite pod riječju “odmah”? Kao rezultat kratke rasprave, odlučili smo da možemo početi s vremenom odziva od 5-10 minuta, kako kratkotrajni udari ne bi doveli sustav u rezonanciju.
Treće pitanje – koju veličinu uravnoteženog broja poslužitelja odabrati?
Ovaj se problem riješio sam od sebe. Tipično, klijenti ne prave velike agregacije poslužitelja, a to je u skladu s preporukama članka da se agregacije ograniče na 30-40 poslužitelja.
Osim toga, segmentiranjem skupa poslužitelja pojednostavljujemo zadatak algoritma za balansiranje.
Četvrto pitanje – koliko nam odgovara neuronska mreža sa svojim dugim procesom učenja i rijetkim balansiranjem? Odlučili smo ga napustiti u korist jednostavnijih operativnih algoritama kako bismo dobili rezultate u nekoliko sekundi.
Može se pronaći opis sustava koji koristi takve algoritme i njegove nedostatke
Implementirali smo i pokrenuli ovaj sustav i dobili ohrabrujuće rezultate - sada redovito analizira opterećenje oblaka i daje preporuke za premještanje virtualnih strojeva, koje su u velikoj mjeri točne. Već sada je jasno da možemo postići 10-15% oslobađanja resursa za nova virtualna računala uz poboljšanje kvalitete rada postojećih.
Kada se otkrije neravnoteža u RAM-u ili CPU-u, sustav izdaje naredbe Tionix planeru za izvođenje žive migracije potrebnih virtualnih strojeva. Kao što se može vidjeti iz nadzornog sustava, virtualni stroj se pomjerao s jednog (gornjeg) na drugi (donji) host i oslobađao memoriju na gornjem hostu (označeno žutim kružićima), odnosno zauzimajući je na donjem (označeno bijelom bojom) krugovi).
Sada pokušavamo točnije procijeniti učinkovitost trenutnog algoritma i pokušavamo pronaći moguće pogreške u njemu.
Stad 3
Čini se da se o tome možete smiriti, pričekati dokazanu učinkovitost i zatvoriti temu.
No, na provođenje nove faze tjeraju nas sljedeće očite mogućnosti optimizacije
- Statistika npr. и pokazuje da su sustavi s dva i četiri procesora znatno slabijeg učinka od sustava s jednim procesorom. To znači da svi korisnici dobivaju znatno manje izlaza iz CPU-a, RAM-a, SSD-a, LAN-a, FC-a kupljenih u višeprocesorskim sustavima u usporedbi s jednoprocesorskim sustavima.
- Sami planeri resursa mogu imati ozbiljne pogreške, na ovu temu.
- Tehnologije koje nude Intel i AMD za nadzor RAM-a i predmemorije omogućuju proučavanje ponašanja virtualnih strojeva i njihovo postavljanje na takav način da "bučni" susjedi ne ometaju "tihe" virtualne strojeve.
- Proširenje skupa parametara (mreža, sustav za pohranu podataka, prioritet virtualnog stroja, trošak migracije, njegova spremnost za migraciju).
Ukupno
Rezultat našeg rada na poboljšanju algoritama za balansiranje bio je jasan zaključak da je korištenjem suvremenih algoritama moguće postići značajnu optimizaciju resursa podatkovnog centra (25-30%) i istovremeno poboljšati kvalitetu korisničke usluge.
Algoritam temeljen na neuronskim mrežama svakako je zanimljivo rješenje, ali koje treba dalje razvijati, a zbog postojećih ograničenja nije pogodno za rješavanje ovakvog problema na volumenima tipičnim za privatne oblake. U isto vrijeme, algoritam je pokazao dobre rezultate u javnim oblacima značajne veličine.
Reći ćemo vam više o mogućnostima procesora, planera i balansiranja visoke razine u sljedećim člancima.
Izvor: www.habr.com