ProHoster > Blog > Administrim > Balancimi i ngarkesës në Openstack (Pjesa 2)

Balancimi i ngarkesës në Openstack (Pjesa 2)

Në artikullin e kaluar Ne kemi folur për përpjekjet për të përdorur Watcher dhe kemi paraqitur një raport provash. Ne realizojmë këto teste periodikisht për balancimin dhe funksione të tjera kritike të një cloud-i të madh korporativ ose operator.

Kompleksiteti i lartë i detyrës që po zgjidhim, ndoshta do të kërkojë disa artikuj për të përshkruar projektin tonë. Sot publikojmë artikullin e dytë të serisë, i cili është dedikuar balancimit të makinave virtuale në cloud.

Pak terminologji

Kompania VmWare ka futur utilitarin DRS (Planifikuesi i Burimeve të Distribuara) për balancimin e ngarkesës në ambientin e virtualizimit që e zhvillon dhe e ofron.

Siç shkruan searchvmware.techtarget.com/definition/VMware-DRS
«VMware DRS (Planifikuesi i Burimeve të Distribuara) është një utilitar që balancojë ngarkesat llogaritëse me burimet e disponueshme në një ambient virtual. Ky utilitar është pjesë e paketës së virtualizimit e quajtur VMware Infrastructure.

Me anë të VMware DRS, përdoruesit përcaktojnë rregullat për shpërndarjen e burimeve fizike midis makinave virtuale (VM). Utilitari mund të konfigurohet për menaxhim manual ose automatizuar. Puset e burimeve VMware mund të shtohen, hiqen ose riorganizohen lehtësisht. Nëse dëshirohet, puset e burimeve mund të izolohet midis njësive të ndryshme të biznesit. Nëse ngarkesa e punës në një ose disa makina virtuale ndryshon ndjeshëm, VMware DRS riorganizon makinat virtuale midis serverëve fizikë. Nëse ngarkesa totale e punës zvogëlohet, disa serverë fizikë mund të çaktivizohen përkohësisht dhe ngarkesa e punës të konsolidohet.

Pse është e nevojshme balancimi?


Sipas mendimit tonë, DRS është një funksion i domosdoshëm i cloud-it, megjithëse kjo nuk do të thotë se DRS duhet të përdoret gjithmonë dhe kudo. Në varësi të qëllimit dhe nevojave të cloud-it, mund të ekzistojnë kërkesa të ndryshme për DRS dhe metodat e balancimit. Ndoshta ekzistojnë situata kur balancimi nuk është aspak i nevojshëm. Ose madje dëmshpërblyes.

Për të kuptuar më mirë se ku dhe për cilët klientë DRS është e nevojshme, le të shqyrtojmë qëllimet dhe detyrat e tyre. Cloud-et mund të ndahen në publike dhe private. Këtu janë dallimet kryesore midis këtyre cloud-eve dhe qëllimeve të klientëve.

Cloud-et private / Klientët e mëdhenj korporativë
Cloud-et publike / Bizneset e mesme dhe të vogla, individë

Kriteri kryesor dhe qëllimet e operatorëve
Ofrimi i një shërbimi ose produkti të besueshëm
Reducimi i kostove të shërbimeve në luftën në tregun e konkurrencës

Kërkesat për shërbimin
Besueshmëria në të gjitha nivelet dhe në të gjithë elementët e sistemit

Performanca e garantuar

Prioritizimi i makinave virtuale në disa kategori 

Siguria informative dhe fizike e të dhënave

SLA dhe mbështetje 24/7
Thjeshtësia maksimale në marrjen e shërbimit

Shërbime relativisht të thjeshta

Përgjegjësia për të dhënat bie mbi klientin

Prioritizimi i VM nuk është i nevojshëm

Siguria informative në nivelin e shërbimeve standarde, përgjegjësia mbi klientin

Mund të ketë ndërprerje

Nuk ka SLA, cilësia nuk garantizohet

Mbështetje përmes postës

Backup-i nuk është i detyrueshëm

Karakteristikat e klientit
Një spektër shumë të gjerë aplikacionesh.

Aplikacione të trashëguara, të trasheguara në kompani.

Arkitektura komplekse të personalizuara për çdo klient.

Rregullat e afinitetit.

Funksionimi i softuerit pa ndërprerje në modin 7x24. 

Mjetet e backup-it 'në fluks'.

Ngarkesa ciklike e parashikueshme e klientit.
Aplikacione standarde – balancimi i rrjetit, Apache, WEB, VPN, SQL

Mund të ketë ndërprerje aplikacioni për një kohë të caktuar

Ndërprerja e rastit e VM në cloud lejohet

Backup-i nga klienti

Ngarkesa e parashikueshme, në mes të klientëve është statistikisht e mesme.

Pasojat për arkitekturën
Gjeoklasterizimi

Sistemi ruajtĂ«s (SÇH) i centralizuar ose i shpĂ«rndarĂ«

SRK e rezervuar
Ruajtja lokale e të dhënave në nyjat kompjuterike

QĂ«llimet e balancimit
Shpërndarja e barabartë e ngarkesës

Reagimi maksimal i aplikacioneve 

Koha minimale e vonesës në balancim

Balancimi vetëm në rast të nevojës së qartë

Dërgimi i një pjese të pajisjeve në mirëmbajtje parandalues
Reducimi i kostove të shërbimit dhe shpenzimeve të operatorit 

Shkëputja e një pjese të burimeve në rast ngarkese të ulët

Kursimi i energjisë elektrike

Zvogëlimi i shpenzimeve për personelin

Ne bëjmë këto përfundime për veten:

Për cloud-et private, të ofruara për klientët e mëdhenj korporativë, DRS mund të aplikohet duke marrë parasysh kufizimet:

  • siguria informative dhe marrja parasysh e rregullave tĂ« afinitetit gjatĂ« balancimit;
  • prania nĂ« rezervĂ« e njĂ« volumi tĂ« mjaftueshĂ«m burimesh nĂ« rast aksidenti;
  • tĂ« dhĂ«nat e makinave virtuale janĂ« nĂ« sistemin ruajtĂ«s tĂ« centralizuar ose tĂ« shpĂ«rndarĂ«;
  • shpĂ«rndarja nĂ« kohĂ« e procedurave tĂ« administrimit, kopjimit tĂ« sigurt dhe balancimit;
  • balancimi vetĂ«m brenda grumbullit tĂ« hosteve tĂ« klientĂ«ve;
  • balancimi vetĂ«m nĂ« rast tĂ« njĂ« disbalancimi tĂ« rĂ«ndĂ«, migrimet mĂ« efektive dhe mĂ« tĂ« sigurta tĂ« VM (sepse migrimi mund tĂ« pĂ«rfundojĂ« me dĂ«shtim);
  • balancimi nĂ« lidhje me makinat virtuale "tĂ« qeta" (migrimi i makinave virtuale "tĂ« zhurmshme" mund tĂ« zgjasĂ« shumĂ«);
  • balancimi duke marrĂ« parasysh "kostot" — ngarkesat nĂ« storage dhe rrjet (nĂ« arkitekturĂ« tĂ« personalizuar pĂ«r klientĂ« tĂ« mĂ«dhenj);
  • balancimi duke marrĂ« parasysh karakteristikat individuale tĂ« sjelljes sĂ« çdo VM;
  • balancimi preferohet tĂ« bĂ«het nĂ« kohĂ« joaktive (nata, fundjavat, festat).

Për re publike, që ofrojnë shërbime për klientë të vegjël, DRS mund të aplikohet shumë më shpesh, me mundësi të zgjeruara:

  • mungesa e kufizimeve tĂ« sigurisĂ« informative dhe rregullave tĂ« afinitetit;
  • balancimi brenda re;
  • balancimi nĂ« çdo kohĂ« tĂ« arsyeshme;
  • balancimi i çdo VM;
  • balancimi i makinave virtuale "tĂ« zhurmshme" (pĂ«r tĂ« mos shqetĂ«suar tĂ« tjerĂ«t);
  • tĂ« dhĂ«nat e makinave virtuale shpesh ndodhen nĂ« disqe lokale;
  • marrja nĂ« konsideratĂ« e pĂ«rformancĂ«s sĂ« mesatare tĂ« storage dhe rrjetit (arkitektura e re Ă«shtĂ« e njĂ«jtĂ«);
  • balancimi nĂ« pĂ«rputhje me rregullat e pĂ«rgjithshme dhe statistikĂ«n aktuale tĂ« sjelljes sĂ« qendrĂ«s sĂ« tĂ« dhĂ«nave.

Vështirësia e problemit

Vështirësia e balancimit qëndron në faktin se DRS duhet të punojë me një numër të madh faktorësh të pasigurt:

  • sjellja e pĂ«rdoruesve tĂ« çdo prej sistemeve informative tĂ« klientĂ«ve;
  • algoritmet e funksionimit tĂ« serverĂ«ve tĂ« sistemeve informative;
  • sjellja e serverĂ«ve tĂ« DBMS;
  • ngarkesa nĂ« resurset kompjuterike, storage, rrjet;
  • ndĂ«rveprimi i serverĂ«ve me njĂ«ri-tjetrin nĂ« luftĂ« pĂ«r resurset e re.

Ngarkesa e një numri të madh të serverëve virtualë të aplikacioneve dhe të dhënave mbi resurset e re proiston në kohë, pasojat mund të shfaqen dhe të mbivendosen me njëra-tjetrën me një efekt të papërshkrueshëm në një kohë të paparashikueshme. Edhe për menaxhimin e proceseve relativisht të thjeshta (përshembull, për menaxhimin e motorit, sistemit të ngrohjes me ujë të shtëpisë) sistemet e rregullimit automatik duhet të përdorin algoritme të komplikuara proporcionale-integrale-diferenciale me feedback.

Balancimi i ngarkesës në Openstack (Pjesa 2)

Detyra jonë është shumë më e ndërlikuar dhe ekziston rreziku që sistemi të mos arrijë të balancojë ngarkesën në nivelet e qëndrueshme brenda një kohe të arsyeshme, madje edhe nëse nuk ka ndikime të jashtme nga përdoruesit.

Balancimi i ngarkesës në Openstack (Pjesa 2)

Historia e zhvillimeve tona

Për të zgjidhur këtë problem, vendosëm të mos fillonim nga e para, por të mbështeteshim në përvojën ekzistuese dhe të bashkëpunonim me specialistët që kanë përvojë në këtë fushë. Për fat, kuptimi i problemit ishte plotësisht në përputhje me ne.

Faza 1

Ne përdorëm një sistem të bazuar në teknologjinë e rrjeteve neurale dhe provuam të optimizonim burimet tona mbi atë bazë.

Interesi i këtij tregu ishte provimi i teknologjisë së re, ndërsa rëndësia e tij qëndronte në aplikimin e një qasjeje të pazakonshme për zgjidhjen e problemit, ku në kushte të tjera të barabarta, qasjet standarde ishin praktiksht shteruar.

Ne lansuam sistemin dhe vërtet filluam balancimin. Shkalla e reve tona nuk na lejoi të merrnim rezultate optimiste të shpallura nga zhvilluesit, por ishte e qartë se balancimi funksiononte.

Megjithatë, kishim disa kufizime të rëndësishme:

  • PĂ«r tĂ« trajnuar rrjetin neural, Ă«shtĂ« e nevojshme qĂ« makinat virtuale tĂ« funksionojnĂ« pa ndryshime tĂ« ndjeshme pĂ«r javĂ« ose muaj.
  • Algoritmi Ă«shtĂ« projektuar pĂ«r optimizim mbi bazĂ«n e analizĂ«s sĂ« tĂ« dhĂ«nave "historike" mĂ« tĂ« hershme.
  • PĂ«r trajnimin e rrjetit neural kĂ«rkohet njĂ« volum i konsiderueshĂ«m tĂ« dhĂ«nash dhe burimesh kompjuterike.
  • Optimizimi dhe balancimi mund tĂ« bĂ«hen relativisht rrallĂ« – njĂ« herĂ« çdo disa orĂ«, qĂ« Ă«shtĂ« padyshim e pamjaftueshme.

Stage 2

Duke qenĂ« se ne nuk ishim tĂ« kĂ«naqur me situatĂ«n, vendosĂ«m tĂ« modifikonim sistemin, dhe pĂ«r kĂ«tĂ« duhej tĂ« pĂ«rgjigjeshim nĂ« pyetjen kryesore – pĂ«r kĂ« e bĂ«jmĂ« atĂ«?

Fillimisht – pĂ«r klientĂ«t korporatĂ«. KĂ«shtu, na nevojitet njĂ« sistem qĂ« funksionon shpejt, me ato kufizime korporative qĂ« vetĂ«m e thjeshtojnĂ« realizimin.

Pyetja e dytĂ« – çfarĂ« kuptojmĂ« me fjalĂ«n "shpejt"? Si rezultat i disa debatĂ«ve tĂ« shkurtra, vendosĂ«m se mund tĂ« mbĂ«shtetemi nĂ« njĂ« kohĂ« reagimi 5 – 10 minuta, qĂ« skakrricimet e pĂ«rkohshme tĂ« mos e çorientonin sistemin.

PĂ«rgjigjja e tretĂ« – çfarĂ« madhĂ«sie tĂ« sasisĂ« sĂ« serverĂ«ve pĂ«r balancim duhet tĂ« zgjidhim?
Kjo çështje zgjidhte vetvetiu. Si rregull, klientët nuk e bëjnë grumbujt e serverëve shumë të mëdhenj, dhe kjo është në përputhje me rekomandimet nga artikulli për të kufizuar grumbujt në 30-40 serverë.

Për më tepër, duke segmentuar rezervuarin e serverëve, ne i lehtësojmë algoritmit të balancimit detyrën.

Pyetja e katĂ«rt – sa e pĂ«rshtatshme Ă«shtĂ« rrjeti nervor me procesin e tij tĂ« gjatĂ« tĂ« mĂ«simit dhe balancimet e rralla? Ne morĂ«m vendimin pĂ«r tĂ« hequr dorĂ« nga ai nĂ« favor tĂ« algoritmeve mĂ« tĂ« thjeshta operative, qĂ« tĂ« marrim rezultate brenda sekondash.

Balancimi i ngarkesës në Openstack (Pjesa 2)

Me përshkrimin e sistemit që përdor këta algoritma dhe disavantazhet e tij, mund të njiheni këtu

Ne e kemi implementuar dhe lançuar kĂ«tĂ« sistem dhe kemi marrĂ« rezultate premtuese – tani ai analizon rregullisht ngarkesĂ«n e re tĂ« qeverisjes dhe jep rekomandime pĂ«r zhvendosjen e makinave virtuale, tĂ« cilat janĂ« nĂ« shumĂ« raste tĂ« sakta. Edhe tani duket se ne mund tĂ« arrijmĂ« njĂ« lirimin e burimeve prej 10-15% pĂ«r makina virtuale tĂ« reja me pĂ«rmirĂ«simin e cilĂ«sisĂ« sĂ« punĂ«s sĂ« atyre ekzistuese.

Balancimi i ngarkesës në Openstack (Pjesa 2)

Kur zbulohet një disbalancë në RAM ose CPU, sistemi jep urdhra në planifikuesin Tionix për kryerjen e migracionit të gjallë të makinave virtuale të nevojshme. Siç duket nga sistemi i monitorimit, makina virtuale është zhvendosur nga një host (i sipërm) në një tjetër (në të poshtme) dhe ka liruar kujtesën në hostin e sipërm (të shënuara me rreth të verdhë), duke e zënë atë përkatësisht në të poshtmen (të shënuara me rreth të bardhë).

Tani po përpiqemi të vlerësojmë më saktë efikasitetin e algoritmit aktual dhe po përpiqemi të gjejmë gabimet e mundshme në të.

Stage 3

Duket se mund të qetësohemi me këtë, të presim efikasitetin e provuar dhe të mbyllim temën.
Por na shtyjnë drejt një faze të re të mundësive të dukshme për optimizim

  1. Statistika, për shembull, këtu dhe këtu tregon se sistemet me dy dhe katër procesorë janë ndjeshëm më pak efikase se ato me një procesor. Pra, të gjithë përdoruesit marrin një kthim shumë më të ulët nga CPU, RAM, SSD, LAN, FC që janë blerë në sisteme multinocionale, krahasuar me ato me një procesor.
  2. Vetë planifikuesit e burimeve mund të punojnë me gabime të rënda, kjo është një nga artikujt në lidhje me këtë temë.
  3. Teknologjitë e ofruara nga kompanitë Intel dhe AMD për monitorimin e RAM-it dhe cache-it lejojnë studimin e sjelljes së makinave virtuale dhe vendosjen e tyre në mënyrë që fqinjët "zhurmshëm" të mos pengojnë jetesën e makinave virtuale "të qeta".
  4. Zgjerimi i grupit të parametrave (rrjeti, ruajtja, prioriteti i makinës virtuale, kostoja e migrimit, gatishmëria për migrim).

Përveç kësaj

Rezultati i punës sonë për përmirësimin e algoritmeve të balancimit rezultoi në një konkluzion të qartë se përmes algoritmeve moderne mund të arrihet optimizim i konsiderueshëm i burimeve (25-30%) të centreve të të dhënave dhe njëkohësisht të rritet cilësia e shërbimeve për klientët.

Algoritmi i bazuar në rrjetet nervore, ashtu siç është, padyshim që është një zgjidhje interesante, por që ka nevojë për zhvillim të mëtejshëm dhe për shkak të kufizimeve ekzistuese nuk është i përshtatshëm për zgjidhjen e këtij lloji të detyrave në volumin tipik për re private. Megjithatë, në re publike të mëdha, algoritmi ka treguar rezultate të mira.

Më shumë në lidhje me mundësitë e procesorëve, planifikuesve dhe balancimit në nivele të larta do të tregojmë në artikujt e ardhshëm.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster