В ons het gepraat oor ons pogings om Watcher te gebruik en 'n toetsverslag verskaf. Ons doen gereeld sulke toetse vir balansering en ander kritieke funksies van 'n groot onderneming of operateurwolk.
Die hoë kompleksiteit van die probleem wat opgelos word, kan verskeie artikels vereis om ons projek te beskryf. Vandag publiseer ons die tweede artikel in die reeks, gewy aan die balansering van virtuele masjiene in die wolk.
Sommige terminologie
Die VmWare-maatskappy het die DRS (Distributed Resource Scheduler)-nutsmiddel bekendgestel om die las van die virtualiseringsomgewing wat hulle ontwikkel en aangebied het, te balanseer.
Volgens
“VMware DRS (Distributed Resource Scheduler) is 'n nutsprogram wat rekenaarladings met beskikbare hulpbronne in 'n virtuele omgewing balanseer. Die hulpprogram is deel van 'n virtualiseringsuite genaamd VMware Infrastructure.
Met VMware DRS definieer gebruikers reëls vir die verspreiding van fisiese hulpbronne tussen virtuele masjiene (VM's). Die hulpprogram kan gekonfigureer word vir handmatige of outomatiese beheer. VMware-hulpbronpoele kan maklik bygevoeg, verwyder of herorganiseer word. Indien verlang, kan hulpbronpoele tussen verskillende sake-eenhede geïsoleer word. As die werklading op een of meer virtuele masjiene dramaties verander, herverdeel VMware DRS die virtuele masjiene oor fisiese bedieners. As die algehele werklading afneem, kan sommige fisiese bedieners tydelik vanlyn geneem word en die werklading gekonsolideer word."
Hoekom is balansering nodig?
Na ons mening is DRS 'n moet-hê-wolkfunksie, hoewel dit nie beteken dat DRS altyd en oral gebruik moet word nie. Afhangende van die doel en behoeftes van die wolk, kan daar verskillende vereistes vir DRS en balanseringsmetodes wees. Daar kan situasies wees waar balansering glad nie nodig is nie. Of selfs skadelik.
Om beter te verstaan waar en vir watter kliënte DRS benodig word, kom ons kyk na hul doelwitte en doelwitte. Wolke kan in publiek en privaat verdeel word. Hier is die belangrikste verskille tussen hierdie wolke en kliëntedoelwitte.
Privaat wolke / Groot ondernemingskliënte
Openbare wolke / Medium en klein besighede, mense
Die hoofkriterium en doelwitte van die operateur
Die verskaffing van 'n betroubare diens of produk
Vermindering van die koste van dienste in die stryd in 'n mededingende mark
Diensvereistes
Betroubaarheid op alle vlakke en in alle stelselelemente
Gewaarborgde prestasie
Prioritiseer virtuele masjiene in verskeie kategorieë
Inligting en fisiese data sekuriteit
SLA en XNUMX/XNUMX ondersteuning
Maksimum gemak om die diens te ontvang
Relatief eenvoudige dienste
Verantwoordelikheid vir die data lê by die kliënt
Geen VM-prioritisering vereis nie
Inligtingsekuriteit op die vlak van standaarddienste, verantwoordelikheid op die kliënt
Daar kan foute wees
Geen SLA, kwaliteit nie gewaarborg nie
E-pos ondersteuning
Rugsteun is nie nodig nie
Kliënt kenmerke
Baie wye reeks toepassings.
Verouderde toepassings wat in die maatskappy geërf is.
Komplekse pasgemaakte argitekture vir elke kliënt.
Affiniteit reëls.
Die sagteware werk sonder om te stop in 7x24-modus.
Op-die-vlieg rugsteun gereedskap.
Voorspelbare sikliese kliëntelading.
Tipiese toepassings – netwerkbalansering, Apache, WEB, VPN, SQL
Die toepassing kan vir 'n rukkie stop
Laat arbitrêre verspreiding van VM's in die wolk toe
Kliënt rugsteun
Voorspelbare statisties gemiddelde las met 'n groot aantal kliënte.
Implikasies vir argitektuur
Geoclustering
Gesentraliseerde of verspreide berging
Voorbehou IBS
Plaaslike databerging op rekenaarnodusse
Balanserende doelwitte
Effense vragverspreiding
Maksimum toepassingsreaksie
Minimum vertragingstyd vir balansering
Balanseer slegs wanneer dit duidelik nodig is
Bring toerusting uit vir voorkomende instandhouding
Vermindering van dienskoste en operateurkoste
Deaktiveer sommige hulpbronne in geval van lae vrag
Energiebesparing
Vermindering van personeelkoste
Ons maak die volgende gevolgtrekkings vir onsself:
Vir private wolkeverskaf aan groot korporatiewe kliënte, kan DRS gebruik word onderhewig aan die volgende beperkings:
- inligtingsekuriteit en inagneming van affiniteitsreëls by balansering;
- beskikbaarheid van voldoende hulpbronne in reserwe in die geval van 'n ongeluk;
- virtuele masjiendata is op 'n gesentraliseerde of verspreide bergingstelsel geleë;
- verbysterende administrasie-, rugsteun- en balanseringsprosedures oor tyd;
- balansering slegs binne 'n totaal van kliëntgashere;
- balanseer slegs wanneer daar 'n sterk wanbalans is, die mees doeltreffende en veiligste VM-migrasies (migrasie kan immers misluk);
- balansering van relatief "stil" virtuele masjiene (migrasie van "geraas" virtuele masjiene kan baie lank neem);
- balansering met inagneming van "koste" - die las op die bergingstelsel en netwerk (met pasgemaakte argitekture vir groot kliënte);
- balansering met inagneming van die individuele gedragskenmerke van elke VM;
- Balansering word verkieslik gedurende nie-werksure (nagte, naweke, vakansies) gedoen.
Vir publieke wolkeverskaffing van dienste aan klein kliënte, DRS kan baie meer gereeld gebruik word, met gevorderde vermoëns:
- afwesigheid van inligtingsekuriteitsbeperkings en affiniteitsreëls;
- balansering binne die wolk;
- balansering op enige redelike tyd;
- balansering van enige VM;
- balansering van "geraas" virtuele masjiene (om nie ander te steur nie);
- virtuele masjiendata is dikwels op plaaslike skywe geleë;
- met inagneming van die gemiddelde werkverrigting van bergingstelsels en netwerke (die wolkargitektuur is verenig);
- balansering volgens algemene reëls en beskikbare datasentrumgedragstatistieke.
Kompleksiteit van die probleem
Die moeilikheid om te balanseer is dat DRS met 'n groot aantal onseker faktore moet werk:
- gedrag van gebruikers van elk van die kliënte se inligtingstelsels;
- algoritmes vir die werking van inligtingstelselbedieners;
- gedrag van DBMS-bedieners;
- las op rekenaarhulpbronne, bergingstelsels, netwerk;
- interaksie van bedieners met mekaar in die stryd om wolkbronne.
Die las van 'n groot aantal virtuele toepassingsbedieners en databasisse op wolkbronne vind plaas met verloop van tyd, die gevolge kan hulself manifesteer en mekaar oorvleuel met 'n onvoorspelbare effek oor 'n onvoorspelbare tyd. Selfs om relatief eenvoudige prosesse te beheer (byvoorbeeld om 'n enjin, 'n waterverhittingstelsel by die huis te beheer), moet outomatiese beheerstelsels komplekse gebruik algoritmes met terugvoer.
Ons taak is baie ordes van grootte meer kompleks, en daar is 'n risiko dat die stelsel nie in staat sal wees om die las tot gevestigde waardes binne 'n redelike tyd te balanseer nie, selfs al is daar geen eksterne invloede van gebruikers nie.
Geskiedenis van ons ontwikkelings
Om hierdie probleem op te los, het ons besluit om nie van nuuts af te begin nie, maar voort te bou op bestaande ervaring, en het begin om interaksie te hê met spesialiste met ervaring op hierdie gebied. Gelukkig het ons begrip van die probleem heeltemal saamgeval.
Stadium 1
Ons het 'n stelsel gebruik wat op neurale netwerktegnologie gebaseer is en probeer om ons hulpbronne op grond daarvan te optimaliseer.
Die belangstelling van hierdie stadium was om 'n nuwe tegnologie te toets, en die belangrikheid daarvan was om 'n nie-standaardbenadering toe te pas om 'n probleem op te los waar, ander dinge gelyk, standaardbenaderings hulself feitlik uitgeput het.
Ons het die stelsel geloods, en ons het regtig begin balanseer. Die skaal van ons wolk het ons nie toegelaat om die optimistiese resultate te kry wat deur die ontwikkelaars gestel is nie, maar dit was duidelik dat die balansering werk.
Terselfdertyd het ons nogal ernstige beperkings gehad:
- Om 'n neurale netwerk op te lei, moet virtuele masjiene vir weke of maande sonder noemenswaardige veranderings werk.
- Die algoritme is ontwerp vir optimalisering gebaseer op die ontleding van vroeëre "historiese" data.
- Opleiding van 'n neurale netwerk vereis 'n redelike groot hoeveelheid data en rekenaarhulpbronne.
- Optimalisering en balansering kan relatief selde gedoen word - een keer elke paar uur, wat duidelik nie genoeg is nie.
Stadium 2
Aangesien ons nie tevrede was met die stand van sake nie, het ons besluit om die stelsel aan te pas, en om dit te doen, antwoord hoofvraag – vir wie maak ons dit?
Eerstens - vir korporatiewe kliënte. Dit beteken dat ons 'n stelsel nodig het wat vinnig werk, met daardie korporatiewe beperkings wat implementering net vereenvoudig.
Tweede vraag – wat bedoel jy met die woord “prompt”? As gevolg van 'n kort debat het ons besluit dat ons met 'n reaksietyd van 5–10 minute kan begin, sodat korttermyn-stuwings nie die stelsel in resonansie sal bring nie.
Derde vraag – watter grootte van die gebalanseerde aantal bedieners om te kies?
Hierdie probleem het vanself opgelos. Tipies maak kliënte nie bedienersamevoegings baie groot nie, en dit stem ooreen met die artikel se aanbevelings om samevoegings tot 30-40 bedieners te beperk.
Verder, deur die bedienerpoel te segmenteer, vereenvoudig ons die taak van die balanseringsalgoritme.
Vierde vraag – hoe geskik is 'n neurale netwerk vir ons met sy lang leerproses en seldsame balansering? Ons het besluit om dit te laat vaar ten gunste van eenvoudiger operasionele algoritmes om resultate binne sekondes te kry.
'n Beskrywing van 'n stelsel wat sulke algoritmes gebruik en die nadele daarvan kan gevind word
Ons het hierdie stelsel geïmplementeer en bekendgestel en het bemoedigende resultate gekry – nou ontleed dit gereeld die wolklading en maak aanbevelings vir die verskuiwing van virtuele masjiene, wat grootliks korrek is. Selfs nou is dit duidelik dat ons 10-15% vrystelling van hulpbronne vir nuwe virtuele masjiene kan bereik, terwyl ons die kwaliteit van werk van bestaandes verbeter.
Wanneer 'n wanbalans in RAM of SVE bespeur word, gee die stelsel opdragte aan die Tionix-skeduleerder om regstreekse migrasie van die vereiste virtuele masjiene uit te voer. Soos gesien kan word uit die moniteringstelsel, het die virtuele masjien van een (boonste) na 'n ander (onderste) gasheer beweeg en geheue op die boonste gasheer vrygemaak (in geel sirkels uitgelig), en dit onderskeidelik op die onderste gasheer beset (in wit uitgelig) sirkels).
Nou probeer ons om die doeltreffendheid van die huidige algoritme meer akkuraat te evalueer en probeer om moontlike foute daarin te vind.
Stadium 3
Dit wil voorkom asof 'n mens hieroor kan kalmeer, wag vir bewese effektiwiteit en die onderwerp kan sluit.
Maar ons word aangespoor om 'n nuwe fase uit te voer deur die volgende ooglopende optimaliseringsgeleenthede
- Statistiek, bv. и toon dat twee- en vierverwerkerstelsels aansienlik laer in werkverrigting as enkelverwerkerstelsels is. Dit beteken dat alle gebruikers aansienlik minder uitset ontvang vanaf SVE, RAM, SSD, LAN, FC wat in multiverwerkerstelsels gekoop word in vergelyking met enkelverwerkerstelsels.
- Die hulpbronskeduleerders self kan ernstige foute hê, oor hierdie onderwerp.
- Tegnologieë wat deur Intel en AMD aangebied word vir die monitering van RAM en kas maak dit moontlik om die gedrag van virtuele masjiene te bestudeer en dit op so 'n manier te plaas dat "geraas" bure nie inmeng met "stil" virtuele masjiene.
- Uitbreiding van die stel parameters (netwerk, bergingstelsel, prioriteit van die virtuele masjien, koste van migrasie, sy gereedheid vir migrasie).
In totaal
Die resultaat van ons werk om balanseringsalgoritmes te verbeter was die duidelike gevolgtrekking dat die gebruik van moderne algoritmes moontlik is om aansienlike optimalisering van datasentrumhulpbronne (25-30%) te bereik en terselfdertyd die kwaliteit van kliëntediens te verbeter.
'n Algoritme gebaseer op neurale netwerke is beslis 'n interessante oplossing, maar een wat verdere ontwikkeling nodig het, en weens bestaande beperkings is dit nie geskik om hierdie soort probleem op te los op die volumes wat tipies is vir private wolke nie. Terselfdertyd het die algoritme goeie resultate in openbare wolke van beduidende grootte getoon.
Ons sal jou meer vertel oor die vermoëns van verwerkers, skeduleerders en hoëvlakbalansering in die volgende artikels.
Bron: will.com