V Rääkisime katsetest kasutada Watcherit ja esitasime testide aruande. Selliseid katseid teeme regulaarselt koormuse tasakaalustamiseks ja muude kriitiliste funktsioonide jaoks suurettevõtte või operaatori pilves.
Probleemi kõrge keerukus võib vajada mitmeid artikleid meie projekti kirjeldamiseks. Täna avaldame teise artikli tsiklist, mis käsitleb virtuaalmasinate tasakaalustamist pilves.
Veidi terminoloogiat
Ettevõte VmWare tutvustas DRS-i (Distributed Resource Scheduler) tööriista, et tasakaalustada nende väljatöötatud ja pakutavat virtualiseerimiskeskkonda.
Nagu kirjutab
«VMware DRS (Jaotatud ressursi ajakava) on tööriist, mis tasakaalustab arvutuskoormused saadaval olevate ressurssidega virtuaalses keskkonnas. Tööriist kuulub virtualiseerimise paketisse nimega VMware Infrastructure.»
VMware DRS abil saavad kasutajad määrata reeglid füüsiliste ressursside jaotamiseks virtuaalsete masinate (VM) vahel. Tööriista saab konfigureerida käsitsi või automaatse halduse jaoks. VMware ressursside grupid saab lihtsalt lisada, eemaldada või reorganiseerida. Soovi korral võivad ressursigrupid olla isoleeritud erinevate äriüksuste vahel. Kui ühe või mitme virtuaalse masina koormus muutub järsult, jaotab VMware DRS virtuaalsed masinad füüsiliste serverite vahel ümber. Kui üldine koormus väheneb, võivad mõned füüsilised serverid ajutiselt välja lülitada ja koormus konsolideerida.
Miks on vajaliku tasakaalu loomine?
Meie arvates on DRS pilveteenuse jaoks hädavajalik funktsioon, kuigi see ei tähenda, et DRS-i tuleks kasutada alati ja igal pool. Olenemata pilveotstarbest ja -vajadustest võivad DRS-i ja tasakaalustamise meetodite nõuded varieeruda. Võimalik, et on olukordi, kus tasakaalustamine pole üldse vajalik. Või isegi kahjulik.
Ette mõista paremini, kus ja millistele klientidele DRS on vajalik, vaatame nende eesmärke ja ülesandeid. Pilved saab jagada avalikeks ja privaatseteks. Siin on peamised erinevused nende pilvede ja klientide eesmärkide vahel.
Privaatpilved / Suured ettevõtteklientide
Avalikud pilved / Keskmine ja väike äri, inimesed
Operaatori peamine kriteerium ja eesmärk
Usaldusväärse teenuse või toote pakkumine
Teenuste kulu vähendamine konkurentsitihedas turus
Teenusele esitatavad nõuded
Usaldusväärsus kõigil süsteemi tasanditel ja elementidel
Tagatud jõudlus
Virtuaalmasinate prioriseerimine mitmesse kategooriasse
Andmete informatsiooniline ja füüsiline turvalisus
SLA ja ööpäevaringne tugi
Teenuse saamise maksimaalne lihtsus
Suhteliselt lihtsad teenused
Andmete eest vastutab klient
Virtuaalmasinate prioriseerimine ei ole vajalik
Informatsiooniline turvalisus tavaliste teenuste tasemel, vastutus kliendil
Võimalikud katked
SLA ei ole, kvaliteet ei ole tagatud
Toetamine e-posti teel
Varundamine ei ole kohustuslik
Kliendi omadused
Väga lai rakenduste valik.
Pärandrakendused, mis on ettevõttes edasi antud.
Komplekssed kohandatud arhitektuurid iga kliendi jaoks.
Affiniteedi reeglid.
Tarkvara töötab pidevalt 24/7.
Varundusvahendid "ühelt poolt".
Prognoositav kliendi tsükliline koormus.
Tüüpilised rakendused – võrgu tasakaalustamine, Apache, WEB, VPN, SQL
Rakenduse peatamine on võimalik teatud ajaks.
VMS-i juhuslik jaotus pilves on lubatud.
Varundamine kliendi enda jõududega.
Prognoositav statistiliselt keskmine koormus suure arvu klientide korral.
Arhitektuuri tagajärjed.
Geoklastratsioon.
Keskne või jaotatud andmesalvestus.
Varustatud andmetöötlus.
Andmete kohalik salvestamine arvutisõlmedes.
Tasakaalustamise eesmärgid.
Koormuse ühtlane jaotamine.
Rakenduste maksimaalne reageerimisvõime.
Minimaalne viivitus tasakaalustamisel.
Tasakaalustamine ainult siis, kui see on selgelt vajalik.
Osade seadmete suwksionaarne hooldus.
Teenuse ja operaatori kulude vähendamine.
Mugavuste väljalülitamine madala koormuse korral.
Elektrienergia säästmine.
Kulu vähendamine personali kohta
Teeme endale järgmised järeldused:
Privaatsete pilvede jaoks, mida pakuvad suured ettevõtte kliendid, võib DRS-i rakendada järgmistel tingimustel:
- informatsiooni turvalisus ja afiinite reeglite arvestamine koormuse jaotamisel;
- piisava varu olemasolu mittehädaolukordade korral;
- virtuaalmasinate andmed asuvad tsentraliseeritud või jagatud andmesalvestussüsteemis;
- administratsiooni, varundamise ja koormuse jaotamise protseduuride ajas jaotamine;
- koormuse jaotus ainult kliendi hostide rühmas;
- koormuse jaotus ainult siis, kui on suur tasakaalutegu, kõige tõhusamad ja turvalisemad VM-i migreerimised (sest migreerimine võib ebaõnnestuda);
- koormuse jaotus suhteliselt 'rahulike' virtuaalmasinate suhtes (migreerimine 'mürarikkaid' virtuaalmasinaid võib võtta väga kaua);
- koormuse jaotus arvestades 'hinda' — koormust andmesalvestussüsteemis ja võrgus (suuremate klientide kohandatud arhitektuuride puhul);
- koormuse jaotus arvestades iga VM-i individuaalseid käitumisomadusi;
- koormuse jaotus oleks soovitatav töövälisel ajal (öösel, nädalavahetustel, pühadel).
Avalike pilvede jaoks, väikestele klientidele teenuseid pakkuv DRS võib olla palju sagedamini rakendatav, laiendatud võimalustega:
- teabele juurdepääsu ja afiinuspoliitikate puudumine;
- tasakaalustamine pilve piires;
- tasakaalustamine igal mõistlikul ajal;
- tasakaalustamine mis tahes VM-i puhul;
- tasakaalustamine 'mürarikkaid' virtuaalmasinaid (et mitte segada teisi);
- virtuaalmasinate andmed asuvad sageli lokaalsetel ketastel;
- keskmise jõudluse arvestamine talletussüsteemis ja võrgus (pilve arhitektuur on ühtne);
- tasakaalustamine üldiste reeglite ja olemasoleva käitumisstatistika alusel.
Probleemi keerukus
Tasakaalustamise keerukus seisneb selles, et DRS peab töötama paljude määramatute teguritega:
- kasutajate käitumine iga kliendi infosüsteemis;
- infosisüsteemide serverite töö algoritmid;
- andmebaasi serverite käitumine;
- koormus arvutusressurssidele, talletussüsteemile, võrgule;
- serverite omavaheline suhtlemine võitluses pilve ressurside pärast.
Suure hulga virtuaalsete rakendus- ja andmebaaserverite koormuse suunamine pilveressurssidele toimub aja jooksul. Tagajärjed võivad ilmneda ja üksteisega kattuda ettearvamatute efektidega. Isegi suhteliselt lihtsate protsesside haldamiseks (näiteks kodu küttesüsteemi juhtimiseks) on automaatika jaoks vajalikud keerukad regulatsioonisüsteemid. tagasisidega algoritmid.
Meie ülesanne on mitu korda keerulisem ja on oht, et süsteem ei suuda mõistlikus ajavahemikus koormust tavapärastesse väärtustesse tasakaalustada, isegi kui väliseid mõjusid kasutajatelt ei teki.
Meie arenduste ajalugu
Selle probleemi lahendamiseks otsustasime mitte alustada nullist, vaid tugineda olemasolevale teadlikkusele ning hakkasime koostööd tegema spetsialistidega, kes omavad selles valdkonnas kogemusi. Õnneks kattusid meie arusaamad probleemist täielikult.
Etapp 1
Kasutasime närvivõrkude tehnoloogial põhinevat süsteemi ning katsetasime selle abil oma ressursside optimeerimist.
Selle etapi huvi seisnes uue tehnoloogia proovimises ning selle tähtsus – mittestandardse lähenemise rakendamises probleemi lahendamiseks, kus muude võrdsuse tingimuste korral on tavapärased lähenemisviisid praktiliselt ammendunud.
Käivitasime süsteemi ja meil tõesti toimus tasakaalustamine. Meie pilve ulatus ei lubanud meil saada optimistlikke tulemusi, mida arendajad olid lubanud, kuid oli näha, et tasakaalustamine töötab.
Samas olid meil piisavalt tõsised piirangud:
- Närvivõrgu koolitamiseks on vajalik, et virtuaalmasinad töötaksid oluliste muutusteta nädalate või kuude jooksul.
- Algoritm on kavandatud optimeerimiseks, tuginedes varasemate 'ajalooliste' andmete analüüsile.
- Närvivõrgule õpetamiseks on vajalik piisavalt suur andmemaht ja arvutusressursid.
- Optimeerimist ja tasakaalustamist saab teha suhteliselt harva – kord paaritunnise intervalliga, mis on ilmselgelt puudulik.
Etapp 2
Kuna meid ei rahuldanud olukord, otsustasime süsteemi täiustada ja selleks vastata peamisele küsimusele – kelle jaoks me seda teeme?
Esmalt – äriklientide jaoks. See tähendab, et vajame süsteemi, mis töötab kiiresti, koos nende äri piirangutega, mis ainult lihtsustavad teostamist.
Teine küsimus – mida mõista sõna «kiire» all? Pärast lühikesi arutelusid otsustasime, et reaktsiooniaeg peaks olema 5–10 minutit, et lühiajalised kõikumised ei tooks süsteemi tasakaalu.
Kolmas küsimus – milline on sobiv tasakaalustatavate serverite hulk?
See küsimus lahendati iseenesest. Üldiselt ei tee kliendid serverigruppe liiga suurteks, ja see vastab soovitustele piirata gruppe 30–40 serveriga.
Lisaks, serveripoolde segmenteerides lihtsustame tasakaalustamisalgoritmi ülesannet.
Neljas küsimus – kui sobiv on meile närvivõrk oma pika õpetamisprotsessi ja harvade tasakaalustamistega? Otsustasime sellest loobuda, eelistades lihtsamaid operatiivalgoritme, et saavutada tulemusi sekunditega.
Süsteemi kirjeldus, mis kasutab selliseid algoritme ja selle puudused on tutvumiseks saadaval
Oleme selle süsteemi rakendanud ja käivitanud, saavutades lohutavaid tulemusi – praegu analüüsib see regulaarselt pilve koormust ja annab soovitusi virtuaalmasinate liigutamiseks, mis on tõenäoliselt õiged. Juba nüüd on näha, et saame saavutada 10-15% vabastamist ressurssidest uute virtuaalmasinate jaoks, parandades samal ajal olemasolevate töö kvaliteeti.
Kui RAM-i või CPU tasakaaluhäired avastatakse, saadab süsteem Tioonixi ajakava haldurile käsud vajalikud virtuaalmasinad elumigratsiooni teostamiseks. Nagu näha jälgimissüsteemist, on virtuaalmasin liikunud ühest (ülemisest) hostist teise (alam hosti) ja vabastanud mälu ülemises hostis (märgitud kollaste ringidega), võttes selle vastavalt alam hostis (märgitud valgete ringidega).
Praegu püüame täpsemalt hinnata kehtiva algoritmi tõhusust ja otsime selles võimalikke vigu.
Etapp 3
Tundub, et sellega võiks rahule jääda, oodata tõestatud efektiivsust ja teema sulgeda.
Kuid meid suunavad järgmise etapi elluviimisele järgmised selged optimeerimisvõimalused
- Statistika, näiteks, ja näitab, et kahe- ja neljatuumilised süsteemid on oma jõudluses oluliselt madalamad kui ühetuumalised. See tähendab, et kõik kasutajad saavad ostetud mitme protsessoriga süsteemidest CPU, RAM, SSD, LAN, FC palju madalamat kasu võrreldes ühetuumalistega.
- Ise ressursiplaneerijad võivad töötada tõsiste vigadega, sel teemal.
- Intel ja AMD poolt pakutavad RAM-i ja vahemälu jälgimise tehnoloogiad võimaldavad uurida virtuaalmasinate käitumist ja paigutada neid nii, et "mürarikkad" naabrid ei segaks "rahulikke" virtuaalmasinaid.
- Muutmine parameetrite komplekti (võrk, andmemootor, virtuaalmasina prioriteet, migreerimise maksumus, selle migratsiooniks valmisolek).
Kokku
Meie töö tulemusena tasakaaluotsingualgoritmide täiustamiseks jõudsime selgele järeldusele, et tänapäevaste algoritmide abil on võimalik saavutada andmekeskuste ressursside olulist optimeerimist (25-30%) ja samal ajal parandada klienditeeninduse kvaliteeti.
Närvivõrgupõhine algoritm on kindlasti huvitav, kuid vajab edasist arendamist ning olemasolevate piirangute tõttu ei sobi see suure mahuga ülesannete lahendamiseks, mis on tüüpiline privaatpilvudes. Samas on avalikes pilvedes, kus maht on märkimisväärne, algoritm näidanud häid tulemusi.
Protsessorite, ajakava ja kõrgema taseme koormuse jaotamise võimalustega tutvustame teemasid järgmistes artiklites.
Allikas: habr.com
