В rääkisime oma katsetest Watcherit kasutada ja esitasime testiaruande. Teeme selliseid teste perioodiliselt suure ettevõtte või operaatori pilve tasakaalustamiseks ja muude kriitiliste funktsioonide jaoks.
Lahendatava probleemi keerukus võib nõuda meie projekti kirjeldamiseks mitut artiklit. Täna avaldame sarja teise artikli, mis on pühendatud virtuaalmasinate tasakaalustamisele pilves.
Mingi terminoloogia
Ettevõte VmWare tutvustas DRS-i (Distributed Resource Scheduler) utiliiti, et tasakaalustada nende arendatud ja pakutava virtualiseerimiskeskkonna koormust.
Järgi
„VMware DRS (Distributed Resource Scheduler) on utiliit, mis tasakaalustab arvutikoormust virtuaalses keskkonnas saadaolevate ressurssidega. Utiliit on osa virtualiseerimiskomplektist nimega VMware Infrastructure.
VMware DRS-iga määratlevad kasutajad reeglid füüsiliste ressursside jaotamiseks virtuaalmasinate (VM-ide) vahel. Utiliiti saab konfigureerida käsitsi või automaatseks juhtimiseks. VMware ressursikogumeid saab hõlpsasti lisada, eemaldada või ümber korraldada. Soovi korral saab erinevate äriüksuste vahel eraldada ressursside kogumid. Kui ühe või mitme virtuaalse masina töökoormus dramaatiliselt muutub, jaotab VMware DRS virtuaalsed masinad ümber füüsiliste serverite vahel. Kui üldine töökoormus väheneb, võidakse mõned füüsilised serverid ajutiselt võrguühenduseta välja lülitada ja töökoormust konsolideerida.
Miks on vaja tasakaalustamist?
Meie arvates on DRS kohustuslik pilvefunktsioon, kuigi see ei tähenda, et DRS-i tuleb kasutada alati ja igal pool. Sõltuvalt pilve eesmärgist ja vajadustest võivad DRS-ile ja tasakaalustamismeetoditele olla erinevad nõuded. Võib ette tulla olukordi, kus tasakaalustamine pole üldse vajalik. Või isegi kahjulik.
Et paremini mõista, kus ja milliste klientide jaoks DRS-i vaja on, mõelgem nende eesmärkidele ja eesmärkidele. Pilved võib jagada avalikeks ja privaatseteks. Siin on peamised erinevused nende pilvede ja klientide eesmärkide vahel.
Privaatpilved / suurettevõtete kliendid
Avalikud pilved / Keskmised ja väikeettevõtted, inimesed
Operaatori põhikriteerium ja eesmärgid
Usaldusväärse teenuse või toote pakkumine
Teenuste kulude vähendamine võitluses konkurentsil turul
Nõuded teenindusele
Töökindlus kõigil tasanditel ja kõigis süsteemielementides
Garanteeritud jõudlus
Jaotage virtuaalsed masinad mitmesse kategooriasse
Info- ja füüsiline andmete turvalisus
SLA ja XNUMX/XNUMX tugi
Teenuse kättesaamise maksimaalne lihtsus
Suhteliselt lihtsad teenused
Vastutus andmete eest lasub kliendil
VM-i prioriseerimist pole vaja
Infoturve standardteenuste tasemel, vastutus kliendil
Võib esineda tõrkeid
SLA puudub, kvaliteet pole garanteeritud
Meili tugi
Varundamine pole vajalik
Kliendi funktsioonid
Väga lai valik rakendusi.
Ettevõttes päritud pärandrakendused.
Komplekssed kohandatud arhitektuurid iga kliendi jaoks.
Afiinsuse reeglid.
Tarkvara töötab 7x24 režiimis peatumata.
Lennu ajal varundamise tööriistad.
Prognoositav tsükliline kliendikoormus.
Tüüpilised rakendused – võrgu tasakaalustamine, Apache, WEB, VPN, SQL
Rakendus võib mõneks ajaks peatuda
Võimaldab VM-ide suvalist levitamist pilves
Kliendi varukoopia
Prognoositav statistiliselt keskmine koormus suure hulga klientidega.
Mõju arhitektuurile
Geoklastereerimine
Tsentraliseeritud või hajutatud salvestusruum
Reserveeritud IBS
Kohalik andmete salvestamine arvutussõlmedes
Eesmärkide tasakaalustamine
Koormuse ühtlane jaotus
Rakenduse maksimaalne reageerimisvõime
Minimaalne viivitusaeg tasakaalustamiseks
Tasakaalustamine ainult siis, kui see on selgelt vajalik
Mõne varustuse toomine ennetavaks hoolduseks
Teenuskulude ja operaatorikulude vähendamine
Mõne ressursi keelamine väikese koormuse korral
Energia säästmine
Personalikulude vähendamine
Teeme enda jaoks järgmised järeldused:
Privaatsete pilvede jaokssuurtele äriklientidele pakutavat DRS-i saab kasutada järgmiste piirangutega:
- infoturve ja afiinsusreeglite arvestamine tasakaalustamisel;
- piisavate ressursside olemasolu reservi avarii korral;
- virtuaalmasina andmed asuvad tsentraliseeritud või hajutatud salvestussüsteemis;
- aja jooksul järkjärguline haldus-, varundus- ja tasakaalustamisprotseduurid;
- tasakaalustamine ainult kliendi hostide agregaadi piires;
- tasakaalustamine ainult tugeva tasakaalustamatuse korral, kõige tõhusamad ja ohutumad VM-i migratsioonid (migratsioon võib ju ebaõnnestuda);
- suhteliselt "vaiksete" virtuaalmasinate tasakaalustamine ("mürarikaste" virtuaalmasinate migratsioon võib võtta väga kaua aega);
- tasakaalustamine, võttes arvesse "kulusid" - salvestussüsteemi ja võrgu koormust (suurklientide jaoks kohandatud arhitektuuridega);
- tasakaalustamine, võttes arvesse iga VM-i individuaalseid käitumisomadusi;
- Tasakaalustamine toimub eelistatavalt töövälisel ajal (ööd, nädalavahetused, pühad).
Avalike pilvede jaokspakkudes teenuseid väikeklientidele, saab DRS-i kasutada palju sagedamini koos täiustatud võimalustega:
- infoturbe piirangute ja afiinsusreeglite puudumine;
- tasakaalustamine pilves;
- tasakaalustamine igal mõistlikul ajal;
- mis tahes virtuaalse masina tasakaalustamine;
- "mürarikaste" virtuaalmasinate tasakaalustamine (et mitte teisi häirida);
- virtuaalmasina andmed asuvad sageli kohalikel ketastel;
- võttes arvesse salvestussüsteemide ja võrkude keskmist jõudlust (pilvearhitektuur on ühtne);
- tasakaalustamine vastavalt üldreeglitele ja olemasolevale andmekeskuse käitumisstatistikale.
Probleemi keerukus
Tasakaalustamise raskus seisneb selles, et DRS peab töötama suure hulga ebakindlate teguritega:
- iga kliendi infosüsteemi kasutajate käitumine;
- infosüsteemi serverite töö algoritmid;
- DBMS-i serverite käitumine;
- koormus arvutusressurssidele, salvestussüsteemidele, võrgule;
- serverite omavaheline suhtlus pilveressursside eest võitlemisel.
Suure hulga virtuaalsete rakendusserverite ja andmebaaside koormus pilveressurssidele toimub aja jooksul, tagajärjed võivad ilmneda ja kattuda üksteisega ettearvamatu mõjuga ettearvamatu aja jooksul. Isegi suhteliselt lihtsate protsesside juhtimiseks (näiteks mootori, veeküttesüsteemi juhtimiseks kodus) peavad automaatjuhtimissüsteemid kasutama keerulisi Algoritmid koos tagasisidega.
Meie ülesanne on mitu suurusjärku keerulisem ja on oht, et süsteem ei suuda mõistliku aja jooksul koormust väljakujunenud väärtustega tasakaalustada, isegi kui kasutajate välised mõjud puuduvad.
Meie arengute ajalugu
Selle probleemi lahendamiseks otsustasime mitte alustada nullist, vaid tugineda olemasolevale kogemusele ja hakkasime suhtlema selle valdkonna kogemustega spetsialistidega. Õnneks langes meie arusaam probleemist täielikult kokku.
1 etapp
Kasutasime närvivõrgu tehnoloogial põhinevat süsteemi ja püüdsime selle põhjal oma ressursse optimeerida.
Selle etapi huviks oli uue tehnoloogia katsetamine ja selle tähtsus mittestandardse lähenemise rakendamisel probleemi lahendamisel, kus muul juhul olid standardsed lähenemised end praktiliselt ammendanud.
Käivitasime süsteemi ja hakkasime tõesti tasakaalustama. Meie pilve ulatus ei võimaldanud meil arendajate väidetud optimistlikke tulemusi saada, kuid oli näha, et tasakaalustamine toimis.
Samal ajal olid meil üsna tõsised piirangud:
- Närvivõrgu treenimiseks peavad virtuaalmasinad töötama ilma oluliste muudatusteta nädalaid või kuid.
- Algoritm on mõeldud optimeerimiseks, mis põhineb varasemate "ajalooliste" andmete analüüsil.
- Närvivõrgu treenimine nõuab üsna suurt hulka andmeid ja arvutusressursse.
- Optimeerimist ja tasakaalustamist saab teha suhteliselt harva – kord paari tunni tagant, millest ilmselgelt ei piisa.
2 etapp
Kuna me ei olnud asjade seisuga rahul, otsustasime süsteemi muuta ja selleks vastata põhiküsimus - kellele me seda teeme?
Esiteks - äriklientidele. See tähendab, et vajame kiiresti töötavat süsteemi, mille ettevõtte piirangud ainult lihtsustavad rakendamist.
Teine küsimus – mida sa mõtled sõna “kohe” all? Lühikese debati tulemusena otsustasime, et võiksime alustada 5–10-minutilise reaktsiooniajaga, et lühiajalised tõusud süsteemi resonantsi ei viiks.
Kolmas küsimus – millist suurust tasakaalustatud arvust serveritest valida?
See probleem lahenes iseenesest. Tavaliselt ei muuda kliendid serverite koondamisi väga suureks ja see on kooskõlas artikli soovitustega piirata koondamisi 30–40 serveriga.
Lisaks lihtsustame serverikogumi segmenteerimisega tasakaalustamisalgoritmi ülesannet.
Neljas küsimus – kui sobiv on meile närvivõrk oma pika õppeprotsessi ja haruldase tasakaalustamisega? Otsustasime sellest loobuda lihtsamate tööalgoritmide kasuks, et saada tulemusi sekunditega.
Selliseid algoritme kasutava süsteemi ja selle puuduste kirjelduse leiate
Võtsime selle süsteemi kasutusele ja käivitasime ning saime julgustavaid tulemusi – nüüd analüüsib see regulaarselt pilvekoormust ja annab soovitusi virtuaalmasinate teisaldamiseks, mis on suures osas õiged. Juba praegu on selge, et suudame uutele virtuaalmasinatele saavutada 10-15% ressursside vabastamist, parandades samas olemasolevate töökvaliteeti.
Kui avastatakse RAM-i või protsessori tasakaalustamatus, annab süsteem Tionixi planeerijale käsud, et viia läbi vajalike virtuaalmasinate reaalajas migratsioon. Nagu seiresüsteemist näha, liikus virtuaalmasin ühest (ülemisest) teise (alumisest) hostist ja vabastas mälu ülemises hostis (kollaste ringidega esile tõstetud), hõivates selle vastavalt alumises (valgega esile tõstetud) ringid).
Nüüd püüame täpsemalt hinnata kehtiva algoritmi tõhusust ja püüame leida selles võimalikke vigu.
3 etapp
Näib, et selle üle võib rahuneda, oodata tõestatud tõhusust ja teema sulgeda.
Kuid meid sunnivad uut etappi läbi viima järgmised ilmsed optimeerimisvõimalused
- Statistika näiteks и näitab, et kahe ja nelja protsessoriga süsteemide jõudlus on oluliselt madalam kui ühe protsessoriga süsteemidel. See tähendab, et kõik kasutajad saavad ühe protsessoriga süsteemides ostetud protsessorilt, RAM-ilt, SSD-lt, LAN-lt, FC-lt oluliselt vähem väljundit.
- Ressursiplaanijatel endil võivad olla tõsised vead, sellel teemal.
- Inteli ja AMD poolt pakutavad tehnoloogiad RAM-i ja vahemälu jälgimiseks võimaldavad uurida virtuaalmasinate käitumist ja paigutada need nii, et “mürarikkad” naabrid “vaikseid” virtuaalmasinaid ei segaks.
- Parameetrite komplekti laiendamine (võrk, salvestussüsteem, virtuaalmasina prioriteet, migratsiooni maksumus, selle valmisolek migratsiooniks).
Kogusummas
Meie tasakaalustamisalgoritmide täiustamise töö tulemuseks oli selge järeldus, et kaasaegseid algoritme kasutades on võimalik saavutada andmekeskuse ressursside oluline optimeerimine (25-30%) ja samal ajal parandada klienditeeninduse kvaliteeti.
Närvivõrkudel põhinev algoritm on kindlasti huvitav, kuid edasiarendamist vajav lahendus, mis olemasolevate piirangute tõttu ei sobi privaatpilvedele omasetel mahtudel sedalaadi probleemi lahendamiseks. Samal ajal näitas algoritm häid tulemusi märkimisväärse suurusega avalikes pilvedes.
Täpsemalt räägime protsessorite, ajakavade ja kõrgetasemelise tasakaalustamise võimalustest järgmistes artiklites.
Allikas: www.habr.com