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

В artikulli i fundit ne folëm për përpjekjet tona për të përdorur Watcher dhe dhamë një raport testimi. Ne kryejmë periodikisht teste të tilla për balancimin dhe funksionet e tjera kritike të një reje të madhe ndërmarrjeje ose operatori.

Kompleksiteti i lartë i problemit që po zgjidhet mund të kërkojë disa artikuj për të përshkruar projektin tonë. Sot po publikojmë artikullin e dytë të serisë, kushtuar balancimit të makinave virtuale në cloud.

Pak terminologji

Kompania VmWare prezantoi programin DRS (Distributed Resource Scheduler) për të balancuar ngarkesën e mjedisit të virtualizimit që ata zhvilluan dhe ofruan.

Siç shkruan ai searchvmware.techtarget.com/definition/VMware-DRS
“VMware DRS (Distributed Resource Scheduler) është një mjet që balancon ngarkesat e llogaritjes me burimet e disponueshme në një mjedis virtual. Shërbimi është pjesë e një grupi virtualizimi të quajtur VMware Infrastructure.

Me VMware DRS, përdoruesit përcaktojnë rregullat për shpërndarjen e burimeve fizike midis makinave virtuale (VM). Shërbimi mund të konfigurohet për kontroll manual ose automatik. Pishinat e burimeve VMware mund të shtohen, hiqen ose riorganizohen lehtësisht. Nëse dëshironi, grupet e burimeve mund të izolohen midis njësive të ndryshme biznesi. Nëse ngarkesa e punës në një ose më shumë makina virtuale ndryshon në mënyrë dramatike, VMware DRS rishpërndan makinat virtuale nëpër serverë fizikë. Nëse ngarkesa e përgjithshme e punës zvogëlohet, disa serverë fizikë mund të hiqen përkohësisht jashtë linje dhe ngarkesa e punës të konsolidohet."

Pse nevojitet balancimi?


Sipas mendimit tonë, DRS është një tipar i domosdoshëm cloud, megjithëse kjo nuk do të thotë që DRS duhet të përdoret gjithmonë dhe kudo. Në varësi të qëllimit dhe nevojave të resë kompjuterike, mund të ketë kërkesa të ndryshme për DRS dhe metodat e balancimit. Mund të ketë situata ku balancimi nuk nevojitet fare. Ose edhe të dëmshme.

Për të kuptuar më mirë se ku dhe për cilët klientë nevojitet DRS, le të shqyrtojmë qëllimet dhe objektivat e tyre. Retë mund të ndahen në publike dhe private. Këtu janë ndryshimet kryesore midis këtyre reve dhe qëllimeve të klientit.

Retë private / Klientë të ndërmarrjeve të mëdha
Retë publike / Bizneset e mesme dhe të vogla, njerëzit

Kriteri kryesor dhe qëllimet e operatorit
Ofrimi i një shërbimi ose produkti të besueshëm
Ulja e kostos së shërbimeve në luftën në një treg konkurrues

Kërkesat e shërbimit
Besueshmëri në të gjitha nivelet dhe në të gjithë elementët e sistemit

Performanca e garantuar

Jepini përparësi makinave virtuale në disa kategori 

Siguria e informacionit dhe e të dhënave fizike

SLA dhe mbështetje XNUMX/XNUMX
Lehtësia maksimale e marrjes së shërbimit

Shërbime relativisht të thjeshta

Përgjegjësia për të dhënat i takon klientit

Nuk kërkohet prioritizimi i VM-së

Siguria e informacionit në nivelin e shërbimeve standarde, përgjegjësi mbi klientin

Mund të ketë defekte

Pa SLA, cilësia nuk garantohet

Mbështetje me email

Rezervimi nuk është i nevojshëm

Karakteristikat e klientit
Gama shumë e gjerë e aplikacioneve.

Aplikacionet e trashëgimisë të trashëguara në kompani.

Arkitektura komplekse me porosi për çdo klient.

Rregullat e afinitetit.

Softueri funksionon pa u ndalur në modalitetin 7x24. 

Mjete rezervë në fluturim.

Ngarkesa ciklike e parashikueshme e klientit.
Aplikacionet tipike – balancimi i rrjetit, Apache, WEB, VPN, SQL

Aplikimi mund të ndalet për një kohë

Lejon shpërndarje arbitrare të VM-ve në cloud

Rezervimi i klientit

Ngarkesa mesatare e parashikueshme statistikisht me një numër të madh klientësh.

Implikimet për arkitekturën
Gjeoklusterimi

Magazinimi i centralizuar ose i shpërndarë

IBS e rezervuar
Ruajtja lokale e të dhënave në nyjet llogaritëse

Balancimi i objektivave
Shpërndarja e barabartë e ngarkesës

Përgjegjshmëri maksimale e aplikacionit 

Koha minimale e vonesës për balancimin

Balancimi vetëm kur është qartësisht e nevojshme

Nxjerrja e disa pajisjeve për mirëmbajtje parandaluese
Ulja e kostove të shërbimit dhe kostove të operatorit 

Çaktivizimi i disa burimeve në rast të ngarkesës së ulët

Kurseni energji

Ulja e kostove të personelit

Ne nxjerrim përfundimet e mëposhtme për veten tonë:

Për retë privateofruar klientëve të korporatave të mëdha, DRS mund të përdoret duke iu nënshtruar kufizimeve të mëposhtme:

  • siguria e informacionit dhe duke marrë parasysh rregullat e afinitetit gjatë balancimit;
  • disponueshmëria e burimeve të mjaftueshme në rezervë në rast aksidenti;
  • të dhënat e makinës virtuale janë të vendosura në një sistem ruajtjeje të centralizuar ose të shpërndarë;
  • administrimi marramendës, procedurat rezervë dhe balancuese me kalimin e kohës;
  • balancimi vetëm brenda një grupi pritës të klientëve;
  • balancimi vetëm kur ka një çekuilibër të fortë, migrimet më efektive dhe të sigurta të VM (në fund të fundit, migrimi mund të dështojë);
  • balancimi i makinave virtuale relativisht "të qeta" (migrimi i makinave virtuale "të zhurmshme" mund të marrë një kohë shumë të gjatë);
  • balancimi duke marrë parasysh "kosto" - ngarkesën në sistemin e ruajtjes dhe rrjetin (me arkitektura të personalizuara për klientët e mëdhenj);
  • balancimi duke marrë parasysh karakteristikat individuale të sjelljes së çdo VM;
  • Balancimi preferohet të bëhet gjatë orarit jo pune (netë, fundjavë, pushime).

Për retë publikeduke ofruar shërbime për klientët e vegjël, DRS mund të përdoret shumë më shpesh, me aftësi të avancuara:

  • mungesa e kufizimeve të sigurisë së informacionit dhe rregullave të afinitetit;
  • balancimi brenda resë;
  • balancimi në çdo kohë të arsyeshme;
  • balancimi i çdo VM;
  • balancimi i makinave virtuale "të zhurmshme" (në mënyrë që të mos shqetësojnë të tjerët);
  • të dhënat e makinës virtuale shpesh ndodhen në disqe lokale;
  • duke marrë parasysh performancën mesatare të sistemeve dhe rrjeteve të ruajtjes (arkitektura cloud është e unifikuar);
  • balancimi sipas rregullave të përgjithshme dhe statistikave të sjelljes së qendrës së të dhënave në dispozicion.

Kompleksiteti i problemit

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

  • sjellja e përdoruesve të secilit prej sistemeve të informacionit të klientëve;
  • algoritme për funksionimin e serverëve të sistemit të informacionit;
  • sjellja e serverëve DBMS;
  • ngarkesa në burimet kompjuterike, sistemet e ruajtjes, rrjeti;
  • ndërveprimi i serverëve me njëri-tjetrin në luftën për burimet cloud.

Ngarkesa e një numri të madh të serverëve të aplikacioneve virtuale dhe bazave të të dhënave në burimet cloud ndodh me kalimin e kohës, pasojat mund të shfaqen dhe të mbivendosen njëra-tjetrën me një efekt të paparashikueshëm gjatë një kohe të paparashikueshme. Edhe për të kontrolluar procese relativisht të thjeshta (për shembull, për të kontrolluar një motor, një sistem ngrohjeje uji në shtëpi), sistemet e kontrollit automatik duhet të përdorin komplekse proporcional-integral-diferencues algoritme me reagime.

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

Detyra jonë është shumë urdhra të përmasave më komplekse, dhe ekziston rreziku që sistemi të mos jetë në gjendje të balancojë ngarkesën me vlerat e vendosura në një kohë të arsyeshme, 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, ne vendosëm të mos fillojmë nga e para, por të ndërtojmë përvojën ekzistuese dhe filluam të ndërveprojmë me specialistë me përvojë në këtë fushë. Për fat të mirë, kuptimi ynë i problemit përkoi plotësisht.

Faza 1

Ne përdorëm një sistem të bazuar në teknologjinë e rrjetit nervor dhe u përpoqëm të optimizonim burimet tona bazuar në të.

Interesi i kësaj faze ishte në testimin e një teknologjie të re dhe rëndësia e saj ishte aplikimi i një qasjeje jo standarde për zgjidhjen e një problemi ku, duke qenë të barabarta, qasjet standarde praktikisht e kishin shteruar veten.

Ne lançuam sistemin dhe me të vërtetë filluam të balancojmë. Shkalla e resë sonë nuk na lejoi të merrnim rezultatet optimiste të deklaruara nga zhvilluesit, por ishte e qartë se balancimi po funksiononte.

Në të njëjtën kohë, ne kishim kufizime mjaft serioze:

  • Për të trajnuar një rrjet nervor, makinat virtuale duhet të funksionojnë pa ndryshime të rëndësishme për javë ose muaj.
  • Algoritmi është krijuar për optimizim bazuar në analizën e të dhënave të mëparshme "historike".
  • Trajnimi i një rrjeti nervor kërkon një sasi mjaft të madhe të dhënash dhe burimesh kompjuterike.
  • Optimizimi dhe balancimi mund të bëhet relativisht rrallë - një herë në disa orë, gjë që nuk është e mjaftueshme.

Faza 2

Meqenëse nuk ishim të kënaqur me gjendjen e punëve, vendosëm të modifikojmë sistemin dhe për ta bërë këtë, përgjigjuni pyetja kryesore - për kë po e bëjmë?

Së pari - për klientët e korporatave. Kjo do të thotë që ne kemi nevojë për një sistem që funksionon shpejt, me ato kufizime të korporatës që thjeshtojnë zbatimin.

Pyetja e dytë – çfarë kuptoni me fjalën “menjëherë”? Si rezultat i një debati të shkurtër, vendosëm që mund të fillonim me një kohë përgjigjeje prej 5-10 minutash, në mënyrë që rritjet afatshkurtra të mos e futnin sistemin në rezonancë.

Pyetja e tretë – çfarë madhësie të numrit të balancuar të serverëve për të zgjedhur?
Kjo çështje u zgjidh vetë. Në mënyrë tipike, klientët nuk i bëjnë grumbullimet e serverëve shumë të mëdhenj, dhe kjo është në përputhje me rekomandimet e artikullit për të kufizuar grumbullimet në 30-40 serverë.

Përveç kësaj, duke segmentuar grupin e serverëve, ne thjeshtojmë detyrën e algoritmit të balancimit.

Pyetja e katërt – sa i përshtatshëm është për ne një rrjet nervor me procesin e tij të gjatë të të mësuarit dhe balancimin e rrallë? Ne vendosëm ta braktisim atë në favor të algoritmeve më të thjeshta operacionale në mënyrë që të marrim rezultate në sekonda.

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

Mund të gjendet një përshkrim i një sistemi që përdor algoritme të tilla dhe disavantazhet e tij këtu

Ne e implementuam dhe lançuam këtë sistem dhe morëm rezultate inkurajuese - tani ai analizon rregullisht ngarkesën e resë kompjuterike dhe bën rekomandime për lëvizjen e makinave virtuale, të cilat janë kryesisht të sakta. Edhe tani është e qartë se mund të arrijmë 10-15% çlirim të burimeve për makinat e reja virtuale duke përmirësuar cilësinë e punës së atyre ekzistuese.

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

Kur zbulohet një çekuilibër në RAM ose CPU, sistemi lëshon komanda për programuesin Tionix për të kryer migrimin e drejtpërdrejtë të makinave virtuale të kërkuara. Siç shihet nga sistemi i monitorimit, makina virtuale kaloi nga një host (i sipërm) në tjetrin (poshtë) dhe liroi memorien në hostin e sipërm (të theksuar me rrathë të verdhë), përkatësisht duke e zënë atë në atë të poshtëm (të theksuar me të bardhë). rrathë).

Tani ne po përpiqemi të vlerësojmë më saktë efektivitetin e algoritmit aktual dhe po përpiqemi të gjejmë gabime të mundshme në të.

Faza 3

Duket se mund të qetësoheni për këtë, të prisni efektivitetin e provuar dhe të mbyllni temën.
Por ne jemi të shtyrë për të kryer një fazë të re nga mundësitë e mëposhtme të dukshme të optimizimit

  1. Statistikat, për shembull, këtu и këtu tregon se sistemet me dy dhe katër procesorë janë dukshëm më të ulët në performancë sesa sistemet me një procesor. Kjo do të thotë që të gjithë përdoruesit marrin dukshëm më pak dalje nga CPU, RAM, SSD, LAN, FC të blera në sistemet me shumë procesorë në krahasim me sistemet me një procesor.
  2. Vetë programuesit e burimeve mund të kenë gabime serioze, këtu është një nga artikujt në këtë temë.
  3. Teknologjitë e ofruara nga Intel dhe AMD për monitorimin e RAM dhe cache bëjnë të mundur studimin e sjelljes së makinave virtuale dhe vendosjen e tyre në atë mënyrë që fqinjët "të zhurmshëm" të mos ndërhyjnë me makinat virtuale "të qeta".
  4. Zgjerimi i grupit të parametrave (rrjeti, sistemi i ruajtjes, përparësia e makinës virtuale, kostoja e migrimit, gatishmëria e saj për migrim).

Në total

Rezultati i punës sonë për të përmirësuar algoritmet e balancimit ishte përfundimi i qartë se duke përdorur algoritme moderne është e mundur të arrihet një optimizim i konsiderueshëm i burimeve të qendrës së të dhënave (25-30%) dhe në të njëjtën kohë të përmirësohet cilësia e shërbimit ndaj klientit.

Një algoritëm i bazuar në rrjetet nervore është sigurisht 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 lloj problemi në vëllimet tipike për retë private. Në të njëjtën kohë, algoritmi tregoi rezultate të mira në retë publike me madhësi të konsiderueshme.

Ne do t'ju tregojmë më shumë për aftësitë e procesorëve, programuesve dhe balancimit të nivelit të lartë në artikujt e mëposhtëm.

Burimi: www.habr.com

Shto një koment