Balansiranje opterećenja u Openstacku (2. dio)

В poslednji članak razgovarali smo o našim pokušajima da koristimo Watcher i dali smo izvještaj o testiranju. Povremeno provodimo takve testove za balansiranje i druge kritične funkcije velikog poduzeća ili oblaka operatera.

Visoka složenost problema koji se rješava može zahtijevati nekoliko članaka za opis našeg projekta. Danas objavljujemo drugi članak u nizu, posvećen balansiranju virtuelnih mašina u oblaku.

Neka terminologija

Kompanija VmWare predstavila je uslužni program DRS (Distributed Resource Scheduler) kako bi uravnotežila opterećenje virtualizacijskog okruženja koje su razvili i ponudili.

Kako piše searchvmware.techtarget.com/definition/VMware-DRS
„VMware DRS (Distributed Resource Scheduler) je uslužni program koji balansira računarsko opterećenje sa dostupnim resursima u virtuelnom okruženju. Uslužni program je dio paketa za virtualizaciju pod nazivom VMware Infrastructure.

Uz VMware DRS, korisnici definišu pravila za distribuciju fizičkih resursa među virtuelnim mašinama (VM). Uslužni program se može konfigurirati za ručnu ili automatsku kontrolu. VMware skupovi resursa mogu se lako dodati, ukloniti ili reorganizirati. Po želji, skupovi resursa mogu biti izolirani između različitih poslovnih jedinica. Ako se radno opterećenje na jednoj ili više virtuelnih mašina dramatično promeni, VMware DRS redistribuira virtuelne mašine preko fizičkih servera. Ako se ukupno radno opterećenje smanji, neki fizički serveri mogu biti privremeno isključeni i radno opterećenje konsolidirano."

Zašto je balansiranje potrebno?

Po našem mišljenju, DRS je obavezna funkcija oblaka, iako to ne znači da se DRS mora koristiti uvijek i svuda. U zavisnosti od svrhe i potreba oblaka, mogu postojati različiti zahtevi 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. Evo glavnih razlika između ovih oblaka i ciljeva korisnika.

Privatni oblaci / Veliki poslovni klijenti
Javni oblaci / Srednja i mala preduzeća, ljudi

Glavni kriterij i ciljevi operatera
Pružanje pouzdane usluge ili proizvoda
Smanjenje troškova usluga u borbi na konkurentnom tržištu

Zahtjevi za uslugu
Pouzdanost na svim nivoima iu svim elementima sistema

Garantovane performanse

Dajte prioritet virtuelnim mašinama u nekoliko kategorija 

Sigurnost informacija i fizičkih podataka

SLA i podrška 24/7
Maksimalna lakoća primanja usluge

Relativno jednostavne usluge

Odgovornost za podatke je na klijentu

Nije potrebno određivanje prioriteta VM-a

Sigurnost informacija na nivou standardnih usluga, odgovornost na klijentu

Možda ima grešaka

Nema SLA, kvalitet nije zagarantovan

Podrška putem e-pošte

Backup nije potreban

Client Features
Vrlo širok spektar primjena.

Naslijeđene aplikacije naslijeđene u kompaniji.

Kompleksne prilagođene arhitekture za svakog klijenta.

Pravila afiniteta.

Softver radi bez zaustavljanja u 7x24 modu. 

Alati za pravljenje rezervnih kopija u letu.

Predvidljivo ciklično opterećenje kupaca.
Tipične aplikacije – balansiranje mreže, Apache, WEB, VPN, SQL

Aplikacija može stati na neko vrijeme

Omogućava proizvoljnu distribuciju VM-ova u oblaku

Sigurnosna kopija klijenta

Predvidivo statistički prosječno opterećenje sa velikim brojem klijenata.

Implikacije za arhitekturu
Geoklastering

Centralizovano ili distribuirano skladištenje

Reserved IBS
Lokalno skladištenje podataka na računarskim čvorovima

Balansirajući ciljevi
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 malog opterećenja

Uštedu energije

Smanjenje troškova osoblja

Za sebe donosimo sljedeće zaključke:

Za privatne oblakekoji se pruža velikim korporativnim klijentima, DRS se može koristiti uz sljedeća ograničenja:

• sigurnost informacija i uzimanje u obzir pravila afiniteta prilikom balansiranja;
• dostupnost dovoljnih resursa u rezervi u slučaju nesreće;
• podaci virtuelne mašine se nalaze na centralizovanom ili distribuiranom sistemu skladištenja;
• neujednačene procedure administracije, rezervne kopije i balansiranja tokom vremena;
• balansiranje samo unutar agregata klijentskih hostova;
• balansiranje samo kada postoji jaka neravnoteža, najefikasnije i najsigurnije VM migracije (na kraju krajeva, migracija može propasti);
• balansiranje relativno „tihih“ virtuelnih mašina (migracija „bučnih“ virtuelnih mašina može potrajati veoma dugo);
• balansiranje uzimajući u obzir “trošak” - opterećenje sistema za skladištenje i mreže (sa prilagođenom arhitekturom za velike klijente);
• balansiranje uzimajući u obzir individualne karakteristike ponašanja svake VM;
• Balansiranje se po mogućnosti vrši u neradno vrijeme (noću, vikendom, praznicima).

Za javne oblakePružajući usluge malim korisnicima, DRS se može koristiti mnogo češće, uz napredne mogućnosti:

• odsustvo ograničenja sigurnosti informacija i pravila afiniteta;
• balansiranje unutar oblaka;
• balansiranje u bilo kom razumnom trenutku;
• balansiranje bilo koje VM;
• balansiranje „bučnih“ virtuelnih mašina (kako ne bi ometali druge);
• podaci virtuelne mašine se često nalaze na lokalnim diskovima;
• uzimajući u obzir prosečne performanse sistema za skladištenje podataka i mreža (arhitektura oblaka je unificirana);
• balansiranje prema općim pravilima i dostupnoj statistici ponašanja data centra.

Složenost problema

Teškoća balansiranja je u tome što DRS mora raditi sa velikim brojem neizvjesnih faktora:

• ponašanje korisnika svakog informacionog sistema klijenta;
• algoritmi za rad servera informacionog sistema;
• ponašanje DBMS servera;
• opterećenje računarskih resursa, sistema za skladištenje podataka, mreže;
• interakcija servera međusobno u borbi za resurse u oblaku.

Opterećenje velikog broja virtuelnih aplikacijskih servera i baza podataka na cloud resurse se javlja tokom vremena, posledice se mogu manifestovati i međusobno se preklapati sa nepredvidivim efektom u nepredvidivom vremenu. Čak i za upravljanje relativno jednostavnim procesima (na primjer, za upravljanje motorom, sistemom za grijanje vode kod kuće), automatski upravljački sistemi moraju koristiti složene proporcionalno-integralno-diferencirajuće algoritmi sa povratnom spregom.

Naš zadatak je mnogo složeniji, a postoji rizik da sistem neće moći izbalansirati opterećenje na utvrđene vrijednosti u razumnom vremenu, čak i ako nema vanjskih utjecaja korisnika.

Istorija našeg razvoja

Kako bismo riješili ovaj problem, odlučili smo da ne počinjemo od nule, već da se nadovežemo na postojeće iskustvo i počeli smo da komuniciramo sa stručnjacima sa iskustvom u ovoj oblasti. Srećom, naše razumijevanje problema se potpuno poklopilo.

Faza 1

Koristili smo sistem zasnovan na tehnologiji neuronskih mreža i pokušali da optimizujemo naše resurse na osnovu njega.

Interes ove faze bio je u testiranju nove tehnologije, a njen značaj u primjeni nestandardnog pristupa rješavanju problema gdje su se, pod jednakim uvjetima, standardni pristupi praktično iscrpili.

Pokrenuli smo sistem i zaista smo počeli da balansiramo. Obim našeg oblaka nije nam dozvolio da dobijemo optimistične rezultate koje su naveli programeri, ali je bilo jasno da balansiranje funkcioniše.

U isto vrijeme, imali smo prilično ozbiljna ograničenja:

• Da bi trenirale neuronsku mrežu, virtuelne mašine treba da rade bez značajnih promena nedeljama ili mesecima.
• Algoritam je dizajniran za optimizaciju zasnovanu na analizi ranijih „povijesnih“ podataka.
• Obuka neuronske mreže zahtijeva prilično veliku količinu podataka i računarskih resursa.
• Optimizacija i balansiranje se mogu raditi relativno rijetko - jednom u nekoliko sati, što očito nije dovoljno.

Faza 2

Pošto nismo bili zadovoljni stanjem, odlučili smo da modifikujemo sistem, a da to uradimo, odgovori glavno pitanje – za koga ga pravimo?

Prvo - za korporativne klijente. To znači da nam je potreban sistem koji radi brzo, sa onim korporativnim ograničenjima koja samo pojednostavljuju implementaciju.

Drugo pitanje – šta mislite pod rečju „brzo”? Kao rezultat kratke debate, odlučili smo da možemo početi sa vremenom odziva od 5-10 minuta, kako kratkotrajni prenaponi ne bi doveli sistem u rezonanciju.

Treće pitanje – koju veličinu balansiranog broja servera odabrati?
Ovaj problem se riješio sam od sebe. Obično klijenti ne prave velike agregacije servera, i to je u skladu sa preporukama članka da se agregacije ograniče na 30-40 servera.

Osim toga, segmentiranjem skupa servera, pojednostavljujemo zadatak algoritma balansiranja.

Četvrto pitanje – koliko je neuronska mreža pogodna za nas sa svojim dugim procesom učenja i rijetkim balansiranjem? Odlučili smo da ga napustimo u korist jednostavnijih operativnih algoritama kako bismo dobili rezultate u sekundi.

Može se pronaći opis sistema koji koristi takve algoritme i njegove nedostatke ovdje

Implementirali smo i pokrenuli ovaj sistem i dobili ohrabrujuće rezultate – sada redovno analizira opterećenje oblaka i daje preporuke za premeštanje virtuelnih mašina, koje su uglavnom tačne. Već sada je jasno da možemo postići 10-15% oslobađanja resursa za nove virtuelne mašine uz poboljšanje kvaliteta rada postojećih.

Kada se otkrije neravnoteža u RAM-u ili CPU-u, sistem izdaje komande Tionix planeru da izvrši migraciju uživo potrebnih virtuelnih mašina. Kao što se vidi iz sistema za nadzor, virtuelna mašina se pomerala sa jednog (gornjeg) na drugi (donji) host i oslobodila memoriju na gornjem hostu (označeno žutim krugovima), odnosno zauzimajući ga na donjem (istaknuto belom). krugovi).

Sada pokušavamo preciznije procijeniti učinkovitost trenutnog algoritma i pokušavamo pronaći moguće greške u njemu.

Faza 3

Čini se da se na ovo može smiriti, sačekati dokazanu efikasnost i zatvoriti temu.
Ali guraju nas da izvršimo novu fazu slijedećim očiglednim mogućnostima optimizacije

1. Statistika, npr. ovdje и ovdje pokazuje da su dvo- i četvoroprocesorski sistemi znatno niži u performansama od jednoprocesorskih sistema. To znači da svi korisnici dobijaju znatno manje izlaza od CPU-a, RAM-a, SSD-a, LAN-a, FC-a kupljenih u višeprocesorskim sistemima u odnosu na jednoprocesorske.
2. Sami planeri resursa mogu imati ozbiljne greške, evo jednog od članaka na ovu temu.
3. Tehnologije koje nude Intel i AMD za praćenje RAM-a i keša omogućavaju proučavanje ponašanja virtuelnih mašina i njihovo postavljanje na takav način da „bučni“ susedi ne ometaju „tihe“ virtuelne mašine.
4. Proširenje skupa parametara (mreža, sistem skladištenja, prioritet virtuelne mašine, cena migracije, njena spremnost za migraciju).

Ukupno

Rezultat našeg rada na unapređenju algoritama balansiranja bio je jasan zaključak da je korišćenjem savremenih algoritama moguće postići značajnu optimizaciju resursa data centra (25-30%) i istovremeno poboljšati kvalitet usluge korisnicima.

Algoritam baziran na neuronskim mrežama svakako je zanimljivo rješenje, ali koje treba dalje razvijati, a zbog postojećih ograničenja nije pogodan za rješavanje ovakve vrste problema na volumenima tipičnim za privatne oblake. Istovremeno, 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 na visokom nivou u sljedećim člancima.

izvor: www.habr.com