Koormuse tasakaalustamine Openstackis (Osa 2)

Uues eelmisel artiklil Oleme rääkinud Watcher'i kasutamise katsetest ja esitanud katsetuste aruande. Selliseid katseid teeme regulaarselt kõrgema ettevõtte või teenusepakkuja pilve tasakaalustamiseks ja muude kriitiliste funktsioonide jaoks.

Ülesande kõrge keerukus võib nõuda meie projekti kirjeldamiseks mitmeid artikleid. Täna avaldame teise artikli tsüklist, mis on pühendatud virtuaalmasinate tasakaalustamisele pilves.

Veidi terminoloogiat

Ettevõte VMware tutvustas DRS-i (Distributed Resource Scheduler), et tasakaalustada koormust nende välja töötatud ja pakutavates virtuaalisuse keskkondades.

Nagu kirjutab searchvmware.techtarget.com/definition/VMware-DRS
„VMware DRS (jaotatud ressursi planeerija) on tööriist, mis tasakaalustab arvutuskoormust kergesti kergesti kergelt kergesti kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt kergelt.

VMware DRS-i abil saavad kasutajad seadistada reegleid füüsiliste ressursside jaotamiseks virtuaalmasinate vahel. Tööriista saab seadistada käsitsi või automaatse juhtimise jaoks. VMware ressursigrupid võivad olla hõlpsasti lisatud, eemaldatud või ümber korraldatud. Soovi korral võivad ressursigrupid olla erinevate äriüksuste vahel isoleeritud. Kui mingil virtuaalmasinal on koormus järsult muutumas, siis VMware DRS jaotab virtuaalmasinad füüsiliste serverite vahel ümber. Kui kogu koormus väheneb, võivad mõned füüsilised serverid ajutiselt välja lülitada ja koormus võib konsolideerida.

Miks on tasakaalustamine vajalik?

Meie arvates on DRS kohustuslik pilve funktsioon, kuigi see ei tähenda, et DRS-i tuleb alati ja igal pool kasutada. Kõne alla võivad tulla erinevad nõuded DRS-ile ja tasakaalustamismeetoditele sõltuvalt pilve otstarbeks ja vajadustest. Võib-olla on olukordi, kus tasakaalustamine ei ole vajalik või isegi kahjulik.

Et paremini mõista, kus ja millistele klientidele on DRS vajalik, vaatame nende eesmärke ja ülesandeid. Pilved jagunevad avalikeks ja privaatseteks. Siin on peamised erinevused nende pilvede ja klientide eesmärkide vahel.

Privaatpilved / Suured ettevõtted
Avalikud pilved / Keskmine ja väike äri, inimesed

Peamine kriteerium ja operaatori eesmärgid
Usaldusväärse teenuse või toote pakkumine
Teenuste kogumismoega tegelemine konkurentsitihedal turul

Teenuse nõuded
Usaldusväärsus kõigil tasanditel ja süsteemi kõikides elementides

Tagatud jõudlus

Virtuaalmasinate prioritiseerimine mitmesse kategooriasse 

Teabe ja füüsiline andmete turvalisus

SLA ja ööpäevaringne tugi
Teenuse saamise maksimaalne lihtsus

Suhteliselt lihtsad teenused

Andmete eest vastutab klient

Virtuaalmasinate prioritiseerimine ei ole vajalik

Teabe turvalisus standardteenuste tasemel, vastutus kliendil

Süsteemi tõrkeid võib esineda

SLA-d ei ole, kvaliteeti ei garanteerita

Tugi e-posti teel

Varundamine ei ole kohustuslik

Kliendi eripära
Väga lai rakenduste spekter.

Pärandrakendused, mis on ettevõttes edasi antud.

Kliendi jaoks keerukad kohandatud arhitektuurid.

Affiniteedi reeglid.

Tarkvara töötab katkestusteta 7x24 režiimis. 

Varundamisseadmed "reaalajas".

Klientide prognoositav tsükliline koormus.
Standardrakendused – võrgu tasakaalustamine, Apache, WEB, VPN, SQL

Rakenduse peatamine on võimalik teatud ajaks

Võimalik on virtuaalmasinate suvaline jaotus pilves

Varundamine kliendi poolt

Prognoositav statistiliselt keskmine koormus suure hulga klientide korral.

Tagajärjed arhitektuurile
Geoklusterdamine

Keskne või jaotatud andmesalvestus

Reserveeritud DR
Andmete kohalik talletamine arvutuspunktides

Tasakaalustamise eesmärgid
Koormuse ühtlane jaotamine

Rakenduste maksimaalne reageerimisvõime 

Minimaalne viivitus tasakaalustamisel

Tasakaalustamine ainult selgelt vajaliku korral

Osade seadmete välja viimine hooldustööd teostama
Teenuse ja operaatori kulude vähendamine 

Osade ressursside väljalülitamine madala koormuse korral

Energiakulu kokkuhoid

Kulude vähendamine personalile

Jõudsime järgmistele järeldustele:

Privaatsete pilvede jaoks, mida pakuvad suured korporatiivsed kliendid, DRS võib rakenduda järgmiste piirangute kohaselt:

• teabe turvalisus ja affiniteedi reeglite arvesse võtmine tasakaalustamisel;
• reservis peab olema piisav ressursside maht hädaolukordade korral;
• virtuaalmasinate andmed paiknevad kesksetes või jaotatud andmesalvestustes;
• ajastatud haldustööde, varukoopiate ja koormuse jaotamise lahtiseletamine;
• koormuse jaotamine ainult kliendi hostide rühmas;
• koormuse jaotamine ainult siis, kui tasakaal on tugevasti häiritud, kõige tõhusamad ja turvalisemad VM-i migreerimised (sest migreerimine võib lõppeda ebaõnnestumisena);
• koormuse jaotamine 'rahulike' virtuaalmasinate põhjal (igal juhul 'mürarikka' virtuaalmasina migreerimine võib võtta kaua aega);
• koormuse jaotamine 'kulude' põhjal — koormus salvestusseadmetele ja võrgule (kohandatud arhitektuuride puhul suurematele klientidele);
• koormuse jaotamine arvestades iga VM-i individuaalseid käitumismustreid;
• koormuse jaotamine oleks soovitatav teha töövälisel ajal (öösel, nädalavahetustel, pühadel).

Avalike pilvede jaoks, mis pakuvad teenuseid väikestele klientidele, võivad DRS-i rakendused olla palju sagedamad, laiemate võimalustega:

• turvasätete ja affiniteedieeskirjade puudumine;
• koormuse jaotamine pilve piires;
• koormuse jaotamine igal mõistlikul ajal;
• koormuse jaotamine igasuguste VM-ide vahel;
• koormuse jaotamine 'mürarikka' virtuaalmasina põhjal (et mitte segada teisi);
• virtuaalmasinate andmed asuvad sageli kohalikul kettal;
• arvestades salvestusseadmete ja võrgu keskmist jõudlust (pilve arhitektuur on ühtne);
• koormuse jaotamine üldiste reeglite ja olemasoleva keskkonna käitumise statistika põhjal.

Probleemi keerukus

Koormuse jaotamise keerukus seisneb selles, et DRS peab töötama suure arvu määramatute teguritega:

• kliendi info süsteemide igaühe kasutajate käitumine;
• infosisüsteemide serverite töö algoritmid;
• andmebaasi serverite käitumine;
• koormus arvutusressurssidele, salvestusseadmetele, võrgule;
• serverite omavaheline suhtlemine ressursside pärast võitlemisel.

Paljude virtuaalserverite rakenduste ja andmebaaside koormus avaldub ajas, tagajärjed võivad ilmneda ja kattuda üksteisega ettearvamatute mõjudega ettearvamatul ajal. Isegi suhteliselt lihtsate protsesside (nt mootori juhtimine, kodu veesoojendussüsteem) juhtimise jaoks peab automaatikaettevõttes olema kasutada keerulisi proportsionaalne-integraalne-differentseerivad tagasiside algoritme.

Meie ülesanne on mitmeid järke keerulisem ja on oht, et süsteem ei suuda mõistliku aja jooksul koormust tasakaalustada seatud väärtustele, isegi kui kasutajaid ei esine välist mõju.

Meie arenduste ajalugu

Selle probleemiga tegelemiseks otsustasime mitte alustada nullist, vaid tugineda olemasolevale kogemusele ja hakkasime suhtlema alal kogenud spetsialistidega. Õnneks kattus meie arusaam probleemist täielikult.

Etapp 1

Kasutame süsteemi, mis põhineb närvivõrkude tehnoloogial, ja proovime selle alusel meie ressursse optimeerida.

Selle etapi huvi seisnes uue tehnoloogia katsetamises ning selle olulisus seisnes mittestandardses lähenemisviisis ülesande lahendamisel, kus sarnastes tingimustes on standardsed lähenemisviisid praktiliselt ammendunud.

Käivitame süsteemi ja meil tõesti hakkas tasakaalustus tööle. Meie pilve ulatus ei lubanud meil saada optimistlikke tulemusi, nagu arendajad olid väitnud, kuid oli näha, et tasakaalustus töötab.

Selle juures olid meil tõsised piirangud:

• Närvivõrgu koolitamiseks on vajalik, et virtuaalmasinad töötaksid ilma märkimisväärsete muutusteta nädalaid või kuid.
• Algoritm on mõeldud optimeerimiseks lähtudes varasemate "ajalooliste" andmete analüüsist.
• Närvivõrgu koolitamiseks on vajalik piisavalt suur andmehulk ja arvutusvõime.
• Optimeerimist ja tasakaalustamist saab teha suhteliselt harva – paar korda tunnis, mis on ilmselgelt ebapiisav.

Etapp 2

Kuna meid ei rahuldanud olukord, otsustasime süsteemi modifitseerida ja sellele vastata peamisele küsimusele – kellele me seda valmistame?

Esmalt – ettevõtte klientidele. See tähendab, et vajame süsteemi, mis töötab kiiresti, koos nende ettevõtte piirangutega, mis ainult lihtsustavad elluviimist.

Teine küsimus – mida mõista sõna "kiiresti" all? Lühikeste arutelude tulemusena otsustasime, et saame lähtuda reageerimise ajast 5 – 10 minutit, et lühiajalised hüpped ei häiriks süsteemi.

Kolmas küsimus – kui palju servereid tuleks tasakaalustada?
See, this issue resolved itself. Typically, clients do not make server aggregates very large, and this aligns with the recommendations in the article to limit aggregates to 30-40 servers.

Furthermore, by segmenting the server pool, we simplify the task for the balancing algorithm.

The fourth issue – how suitable is the neural network for us with its long training process and infrequent balancing? We decided to opt out of it in favor of simpler operational algorithms, to achieve results in seconds.

You can learn about the system that uses such algorithms and its drawbacks siit

We implemented and launched this system and received promising results – it now regularly analyzes the cloud load and provides recommendations for moving virtual machines, which are largely correct. Even now, it's clear that we can achieve a 10-15% resource release for new virtual machines while improving the performance of existing ones.

Upon detecting an imbalance in RAM or CPU, the system sends commands to the Tionix scheduler to perform live migration of the required virtual machines. As seen in the monitoring system, a virtual machine moved from one (upper) host to another (lower) host and freed memory on the upper host (highlighted in yellow circles), occupying it accordingly on the lower one (highlighted in white circles).

Currently, we are trying to evaluate the effectiveness of the existing algorithm more accurately and are looking for possible errors within it.

Etapp 3

It would seem that we could relax at this point, wait for proven efficiency, and close the topic.
But we are pushed towards conducting a new phase by the following clear optimization opportunities

1. Statistics, for example, siit ja siit show that dual- and quad-processor systems are significantly lower in performance compared to single-processor systems. This means that all users receive much lower returns from purchased multi-processor systems in terms of CPU, RAM, SSD, LAN, FC, compared to single-processor ones.
2. The resource schedulers themselves can operate with serious errors, here is one of the articles sellel teemal.
3. Intel ja AMD pakuvad RAM ja vahemälu jälgimise tehnoloogiaid, mis võimaldavad uurida virtuaalmasinate käitumist ja paigutada neid nii, et "müra" naabrid ei segaks "rahulikke" virtuaalmasinaid.
4. Parameetrite komplekti laienemine (võrk, salvestusseade, virtuaalmasina prioriteet, migratsiooni maksumus, migratsiooni valmisolek).

Kokkuvõttes

Meie töö tulemuseks tasakaalustamisalgoritmide täiustamisel on selge järeldus, et tänu kaasaegsetele algoritmidele on võimalik saavutada olulisi ressursside (25-30%) optimeerimist andmekeskustes ja samal ajal parandada klienditeeninduse kvaliteeti.

Neuraalvõrkudel põhinev algoritm on kahtlemata huvitav, kuid vajab edasist arendamist ning olemasolevate piirangute tõttu ei sobi see selliste ülesannete lahendamiseks, mis on iseloomulikud privaatsetele pilvedele. Samas on avalikes suurtes pilvedes näidanud algoritm häid tulemusi.

Protsessorite, planeerijate ja kõrgema taseme tasakaalustamise võimaluste kohta räägime järgnevates artiklites.

Allikas: habr.com