U Pisali smo o pokušajima korištenja Watchera i predstavili izvještaj o probama. Takva testiranja povremeno provodimo za balansiranje i druge kritične funkcije velikog korporativnog ili operatorskog oblaka.
Visoka složenost riješenog zadatka možda će zahtijevati nekoliko članaka za opis našeg projekta. Danas objavljujemo drugi članak serijala posvećenog balansiranju virtualnih strojeva u oblaku.
Malo terminologije
Tvrtka VmWare je uvela alat DRS (Raspoređivač raspodijeljenih resursa) za balansiranje opterećenja u svom razvoju i ponudi okruženja virtualizacije.
Kako piše
«VMware DRS (Raspoređivač raspodijeljenih resursa) je alat koji balansira računalna opterećenja s dostupnim resursima u virtualnom okruženju. Alat je dio paketa virtualizacije pod nazivom VMware Infrastructure.
Pomoću VMware DRS korisnici definiraju pravila raspodjele fizičkih resursa među virtualnim strojevima (VM). Alat se može postaviti na ručno ili automatsko upravljanje. VMware resursni bazeni mogu se lako dodavati, uklanjati ili reorganizirati. Ako je potrebno, resursni bazeni mogu biti izolirani između različitih poslovnih jedinica. Ako se radno opterećenje jednog ili više virtualnih strojeva naglo mijenja, VMware DRS redistribuira virtualne strojeve među fizičkim poslužiteljima. Ako se ukupno radno opterećenje smanjuje, neki fizički poslužitelji mogu biti privremeno isključeni, a radno opterećenje konsolidirano.»
Zašto je potrebna ravnoteža?
Prema našem mišljenju, DRS je obavezna funkcija oblaka, iako to ne znači da se DRS mora koristiti uvijek i svugdje. Ovisno o svrsi i potrebama oblaka mogu postojati različiti zahtjevi za DRS i metodama ravnoteže. Možda postoje situacije kada ravnoteža nije potrebna uopće. Ili je čak štetna.
Da bismo bolje razumjeli gdje i za koje klijente je DRS potreban, razmotrit ćemo njihove ciljeve i zadatke. Oblačne usluge možemo podijeliti na javne i privatne. Ovo su glavne razlike između tih oblaka i ciljeva klijenata.
Privatni oblak / Veliki korporativni klijenti
Javni oblak / Srednji i mali poduzetnici, građani
Glavni kriterij i ciljevi operatora
Pružanje pouzdanih usluga ili proizvoda
Smanjenje troškova usluga u borbi na konkurentnom tržištu
Zahtjevi za uslugu
Pouzdanost na svim razinama i u svim elementima sustava
Jamčena učinkovitost
Prioritizacija virtualnih mašina u nekoliko kategorija
Informacijska i fizička sigurnost podataka
SLA i podrška 24/7
Maksimalna jednostavnost dobivanja usluge
Relativno jednostavne usluge
Odgovornost za podatke leži na klijentu
Prioritizacija VM nije potrebna
Informacijska sigurnost na razini standardnih usluga, odgovornost na klijentu
Mogući su prekidi
Nema SLA, kvaliteta nije garantirana
Podrška putem e-pošte
Sigurnosno kopiranje nije obavezno
Osobitosti klijenta
Vrlo širok spektar aplikacija.
Legacy aplikacije, naslijeđene u kompaniji.
Složene prilagođene arhitekture za svakog klijenta.
Affinity pravila.
Rad softvera bez zaustavljanja u režimu 7x24.
Sredstva sigurnosnog kopiranja 'u hodu'.
Predvidivo cikličko opterećenje klijenta.
Standardne aplikacije – balansiranje mreže, Apache, WEB, VPN, SQL
Moguće je zaustavljanje aplikacije na neko vrijeme
Dopuštena je proizvoljna raspodjela VM u oblaku
Sigurnosno kopiranje od strane klijenta
Predvidiva na temelju velikog broja klijenata statistički prosječna opterećenja.
Posljedice za arhitekturu
Geoklasterizacija
Centralizirani ili distribuirani SAN
Rezervne SRK
Lokalno pohranjivanje podataka na računalnim čvorovima
Ciljevi balansiranja
Ravnomjerna raspodjela opterećenja
Maksimalna odzivnost aplikacija
Minimalno vrijeme zastoja na balansiranju
Balansiranje samo u slučaju očite nužnosti
Između dijela opreme na preventivnom održavanju
Smanjenje troškova usluge i troškova operatera
Isključivanje dijela resursa u slučaju niskog opterećenja
Ušteda energije
Smanjenje troškova osoblja
Mi donosimo sljedeće zaključke:
Za privatne oblake, koji se pružaju velikim korporativnim klijentima, DRS se može primjenjivati uzimajući u obzir ograničenja:
- informacijska sigurnost i uzimanje u obzir affinity pravila prilikom balansiranja;
- imati u rezervi dovoljnu količinu resursa u slučaju nesreće;
- podaci virtualnih mašina nalaze se na centraliziranom ili distribuiranom SAN;
- raspoređivanje vremena administrativnih procedura, izrade sigurnosnih kopija i balansiranja;
- balansiranje samo unutar agregata hostova klijenta;
- balansiranje samo u slučaju snažnog disbalansa, najučinkovitije i najsigurnije migracije VM-a (jer migracija može završiti neuspjehom);
- balansiranje u odnosu na 'mirne' virtualne strojeve (migracija 'bučnih' virtualnih strojeva može potrajati jako dugo);
- balansiranje uzimajući u obzir 'trošak' — opterećenje na SAN-u i mreži (prilikom prilagođenih arhitektura za velike klijente);
- balansiranje uzimajući u obzir individualne osobitosti ponašanja svakog VM-a;
- balansiranje poželjno u izvanradno vrijeme (noću, vikendom, praznicima).
Za javne oblake, koji pružaju usluge manjim klijentima, DRS može biti primjenjen znatno češće, s proširenim mogućnostima:
- nedostatak ograničenja informacijske sigurnosti i pravila afiniteta;
- balansiranje unutar oblaka;
- balansiranje u bilo kojem razumnom vremenu;
- balansiranje bilo kojeg VM-a;
- balansiranje 'bučnih' virtualnih strojeva (da ne ometa ostale);
- podaci virtualnih strojeva često se nalaze na lokalnim diskovima;
- uzimanje u obzir prosječne izvedbe SAN-a i mreže (arhitektura oblaka je jedinstvena);
- balansiranje prema općim pravilima i dostupnoj statistici ponašanja podatkovnih centara.
Složenost problema
Složenost balansiranja sastoji se u tome što DRS mora raditi s velikim brojem neodređenih faktora:
- ponašanje korisnika svakog od informacijskih sustava klijenata;
- algoritmi rada servera informacijskih sustava;
- ponašanje servera DBMS-a;
- opterećenje na procesorskim resursima, SAN-u, mreži;
- međusobna interakcija servera u borbi za resurse oblaka.
Opterećenje velikog broja virtualnih serverskih aplikacija i baza podataka na resurse oblaka vremenski se manifestira, a posljedice se mogu javljati i preklapati jedne s drugima s nepredvidivim učinkom kroz nepredvidivo vrijeme. Čak i za upravljanje relativno jednostavnim procesima (na primjer, za upravljanje motorom, sustavom vodene grijanja kuće) sustavima automatskog reguliranja potrebno je koristiti složene algoritme s povratnom spregom.
Naša zadaća je mnogo složenija, a postoji rizik da sustav neće moći provesti ravnotežu opterećenja u razumnom vremenu, čak i ako ne dođe do izvanjskih utjecaja od strane korisnika.
Povijest naših razvoja
Kako bismo riješili ovaj problem, odlučili smo ne počinjati ispočetka, već se osloniti na postojeće iskustvo i surađivati s stručnjacima koji već imaju iskustva u ovoj oblasti. Na sreću, naše razumijevanje problematike se potpuno poklopilo.
Faza 1
Koristili smo sustav temeljen na tehnologiji neuronskih mreža i pokušali optimizirati naše resurse na temelju toga.
Interes ovog koraka bio je u testiranju nove tehnologije, a njegova važnost u primjeni nesstandardnog pristupa rješavanju zadatka, gdje su pod ostalim jednakim uvjetima standardni pristupi praktički iscrpljeni.
Pokrenuli smo sustav i stvarno je došlo do ravnoteže. Veličina našeg oblaka nije nam omogućila optimistične rezultate koji su najavljeni od strane developera, ali se vidjelo da ravnoteža radi.
U tom procesu imali smo prilično ozbiljna ograničenja:
- Za obuku neuronske mreže potrebno je da virtualne mašine rade bez značajnijih promjena tijekom tjedana ili mjeseci.
- Algoritam je osmišljen za optimizaciju na temelju analize ranijih „historijskih” podataka.
- Za obuku neuronske mreže potrebno je dovoljno velik volumen podataka i računalnih resursa.
- Optimizacija i ravnoteža mogu se provoditi relativno rijetko – svakih nekoliko sati, što je očito nedovoljno.
Faza 2
Budući da nas nije zadovoljavao trenutni status, odlučili smo modificirati sustav i odgovoriti na glavno pitanje – za koga to radimo?
Prvo – za korporativne klijente. Znači, potrebna nam je sustav koji radi operativno, s onim korporativnim ograničenjima koja samo pojednostavljuju implementaciju.
Drugo pitanje – što znači riječ „operativno”? Nakon kratkih rasprava odlučili smo da se možemo osloniti na vrijeme reakcije od 5 – 10 minuta, kako kratkotrajni skokovi ne bi doveli sustav u rezonancu.
Treće pitanje – koju veličinu ravnotežnog broja poslužitelja odabrati?
Ovo pitanje se samo od sebe rešilo. Klijenti obično ne prave veće agregate servera, što je u skladu sa preporukama iz članka da se ograniče agregati na 30-40 servera.
Pored toga, segmentacijom skupa servera olakšavamo zadatak algoritmu za balansiranje.
Četvrto pitanje – koliko nam odgovara neuronska mreža sa svojim dugim procesom obuke i retkim balansiranjima? Doneli smo odluku da je odbacimo u korist jednostavnijih operativnih algoritama, kako bismo dobijali rezultate u sekundi.
O sistemu koji koristi takve algoritme i njegovim nedostacima možete se upoznati
Implementirali smo i pokrenuli ovaj sistem i dobili ohrabrujuće rezultate – sada redovno analizira opterećenje oblaka i daje preporuke za premještanje virtuelnih mašina, koje su u velikoj meri tačne. Čak i sada je vidljivo da možemo postići oslobađanje resursa od 10-15% za nove virtuelne mašine uz poboljšanje kvaliteta rada postojećih.
Kada se otkrije disbalans RAM-a ili CPU-a, sistem šalje komande u Tionix planer za izvršenje žive migracije potrebnih virtuelnih mašina. Kao što je vidljivo iz sistema za monitoring, virtuelna mašina je prešla sa jednog (gornjeg) na drugi (donji) host i oslobodila memoriju na gornjem hostu (označeno žutim krugovima), zauzevši je odgovarajuće na donjem (označeno belim krugovima).
Sada se trudimo da preciznije ocenimo efikasnost trenutnog algoritma i pokušavamo da pronađemo moguće greške.
Faza 3
Naizgled, ovde se može smiriti, sačekati dok se ne dokaže efikasnost i zatvoriti temu.
Ali nas usmeravaju ka sprovođenju novog koraka sledeće očigledne mogućnosti optimizacije
- Statistika, na primer, i pokazuje da su dvoprocesorske i četvoroprocesorske sisteme po svojoj performansi značajno slabije od jednoprocesorskih. Znači, svi korisnici dobijaju značajno manji učinak od CPU, RAM, SSD, LAN, FC kupljenih u višprocesorskim sistemima u poređenju sa jednoprocesorskim.
- Sami planeri resursa mogu raditi sa ozbiljnim greškama, o ovoj temi.
- Tehnologije za praćenje RAM-a i cache-a koje nude tvrtke Intel i AMD omogućuju proučavanje ponašanja virtualnih strojeva i njihovo postavljanje tako da "neumorni" susjedi ne ometaju rad "mirnih" virtualnih strojeva.
- Proširenje skupa postavki (mreža, SAN, prioritet virtualnih strojeva, troškovi migracije, spremnost za migraciju).
U konačnici
Rezultat našeg rada na unapređenju algoritama uravnoteženja je nedvosmislena spoznaja da se modernim algoritmima može postići značajna optimizacija resursa (25-30%) data centara, čime se povećava kvaliteta usluge korisnicima.
Algoritam temeljen na neuronskim mrežama je, bez sumnje, zanimljivo, ali u daljnji razvoj zahtijevajuće rješenje, i zbog postojećih ograničenja nije prikladan za rješavanje ovakvih zadataka na razinama tipičnim za privatne oblake. Međutim, u javnim oblacima značajne veličine, algoritam je pokazao dobre rezultate.
Više o mogućnostima procesora, planera i visoko razine uravnoteženja ćemo predstaviti u sljedećim člancima.
Izvor: habr.com
