I Vi har fortalt om forsøgene med at bruge Watcher og præsenteret en testrapport. Sådanne tests gennemfører vi jævnligt for at balancere og andre kritiske funktioner af store corporate- eller operatørscloud.
Den høje kompleksitet i opgaven kan kræve flere artikler til at beskrive vores projekt. I dag offentliggør vi den anden artikel i rækken, der handler om balancering af virtuelle maskiner i skyen.
Lidt terminologi
VmWare har introduceret DRS (Distributed Resource Scheduler) værktøjet til belastningsbalancering i den af dem udviklede og tilbudte virtualiseringsmiljø.
Som nævnt på
“VMware DRS (Distributed Resource Scheduler) er et værktøj, der balancerer beregningsoverlast med de tilgængelige ressourcer i et virtuelt miljø. Værktøjet er en del af et virtualiseringspakke kaldet VMware Infrastructure.
Med VMware DRS definerer brugerne regler for distribution af fysiske ressourcer mellem virtuelle maskiner (VM). Værktøjet kan konfigureres til manuel eller automatisk administration. VMware-ressourcepuljer kan let tilføjes, fjernes eller omorganiseres. Hvis ønskes, kan ressourcepuljerne isoleres mellem forskellige forretningsenheder. Hvis arbejdsbyrden på en eller flere virtuelle maskiner ændrer sig drastisk, omfordeler VMware DRS de virtuelle maskiner mellem de fysiske servere. Hvis den samlede arbejdsbyrde mindskes, kan nogle fysiske servere midlertidigt slukkes, og arbejdsbyrden kan konsolideres.
Hvorfor er balancering nødvendig?
Efter vores mening er DRS en uundgåelig funktion i skyen, selvom det ikke betyder, at DRS skal bruges altid og overalt. Afhængig af formålet og behovene i skyen kan der være forskellige krav til DRS og balanceringsmetoder. Der kan være situationer, hvor balancering overhovedet ikke er nødvendig. Eller endda skadelig.
For bedre at forstå, hvor og for hvilke kunder DRS er nødvendigt, lad os overveje deres mål og opgaver. Skydes kan opdeles i offentlige og private. Her er de vigtigste forskelle mellem disse skyer og kundernes mål.
Private skyer / Store virksomhedskunder
Offentlige skyer / Små og mellemstore virksomheder, mennesker
Hovedkriterium og mål for operatøren
At levere en pålidelig service eller produkt
Reduktion af serviceomkostninger i konkurrencen på markedet
Krav til tjenesten
Pålidelighed på alle niveauer og i alle systemelementer
Garanteret ydeevne
Prioritering af virtuelle maskiner i flere kategorier
Informations- og fysisk datasikkerhed
SLA og døgnsupport
Maksimal enkelhed i modtagelse af tjenesten
Relativt enkle tjenester
Ansvarsområder for data ligger hos kunden
Prioritering af VM er ikke påkrævet
Informationssikkerhed på niveau med standardtjenester, ansvar ligger hos kunden
Der kan forekomme nedbrud
Ingen SLA, kvaliteten er ikke garanteret
Support via e-mail
Backup er ikke obligatorisk
Kundeegenskaber
Meget bredt spektrum af applikationer.
Legacy applikationer, arvet i virksomheden.
Kompleks tilpasset arkitektur for hver kunde.
Affinity-regler.
Software fungerer uden afbrydelse i 7x24.
Backup-værktøjer "on-the-fly".
Forudsigelig cyklisk belastning for kunden.
Standard applikationer – netværksbalancering, Apache, WEB, VPN, SQL
Appen kan stoppe i en kort periode
Belastningsfordeling af VM i skyen er tilladt
Backup udføres af kunden
Forudsigelig belastning statistisk gennemsnitligt med mange kunder.
Konsekvenser for arkitekturen
Geoklustering
Centraliseret eller distribueret SAN
Reservede SRK
Lokal datalagring på computermoduler
Balanceringsmål
Jævn fordeling af belastning
Maksimal responsivitet af applikationer
Minimal forsinkelse ved balancering
Balancering kun i tilfælde af åbenbare behov
Udsættelse af dele af udstyret til forebyggende vedligeholdelse
Reduktion af omkostninger ved tjenesten og operatørens omkostninger
Deaktivering af dele af ressourcerne ved lav belastning
Energibesparelse
Nedbringelse af personaleomkostninger
Vi drager følgende konklusioner:
For private skyer, der leveres til store virksomhedskunder, kan DRS anvendes med forbehold for begrænsninger:
- informationssikkerhed og hensyntagen til affinity-regler ved balancering;
- tilstedeværelse af tilstrækkelige ressourcer i reserve i tilfælde af uheld;
- data fra virtuelle maskiner er placeret på en centraliseret eller distribueret SAN;
- spredning af administrative, backup- og belastningsbalanceringsprocedurer over tid;
- belastningsbalancering kun inden for aggregatet af kundens værter;
- belastningsbalancering kun ved stærk ubalance, de mest effektive og sikre VM-migrationer (for migrationen kan ende med at være mislykket);
- belastningsbalancering i forhold til 'stille' virtuelle maskiner (migration af 'støjende' virtuelle maskiner kan tage meget lang tid);
- belastningsbalancering med hensyn til 'omkostninger' — belastning på lagringssystem og netværk (ved tilpassede arkitekturer for store kunder);
- belastningsbalancering med hensyn til de individuelle adfærdsmønstre for hver VM;
- belastningsbalancering bør helst ske uden for arbejdstid (om natten, i weekenden, på helligdage).
For offentlige skyer, der leverer tjenester til små kunder, kan DRS anvendes langt oftere, med udvidede muligheder:
- mangel på restriktioner for informationssikkerhed og affinitetsregler;
- belastningsbalancering inden for skyen;
- belastningsbalancering til enhver rimelig tid;
- belastningsbalancering af enhver VM;
- belastningsbalancering af 'støjende' virtuelle maskiner (for ikke at forstyrre de andre);
- data for virtuelle maskiner findes ofte på lokale diske;
- overvejelse af den gennemsnitlige ydeevne for lagringssystemer og netværk (skyarkitekturen er ensartet);
- belastningsbalancering baseret på generelle regler og eksisterende adfærdsmønstre for datacentre.
Problemernes kompleksitet
Kompleksiteten ved belastningsbalancering ligger i, at DRS skal arbejde med mange ubestemte faktorer:
- brugernes adfærd i hver af kundens informationssystemer;
- algoritmerne for informationssystemernes servere;
- adfærden for databaserne servere;
- belastningen på beregningsressourcer, lagringssystemer, netværk;
- interaktionen mellem serverne i kampen om skyens ressourcer.
Belastningen fra et stort antal virtuelle applikations- og databaservere på skyens ressourcer opstår over tid, og konsekvenserne kan manifestere sig og overlappe hinanden med uforudsigelige effekter over uforudsigelig tid. Selv for styring af forholdsvis simple processer (for eksempel til styring af en motor, et vandopvarmningssystem i et hus) skal automatiserede regulatoriske systemer bruge komplekse algoritmer med feedback.
Vores opgave er mange gange mere kompleks, og der er en risiko for, at systemet ikke vil kunne gennemføre belastningsbalanceringen til etablerede værdier inden for rimelig tid, selvom der ikke opstår eksterne påvirkninger fra brugerne.
Historien om vores udviklinger
For at løse dette problem besluttede vi os for ikke at begynde fra bunden, men at bygge videre på eksisterende erfaringer og begyndte at samarbejde med specialister, der har erfaring inden for dette område. Heldigvis var vi fuldstændigt enige om problemstillingen.
Trin 1
Vi brugte et system baseret på neural netværksteknologi og forsøgte at optimere vores ressourcer på den baggrund.
Dette trin var interessant, da det indebar afprøvning af en ny teknologi, og dets betydning lå i anvendelsen af en ukonventionel tilgang til løsning af opgaven, hvor standardmetoder i næsten identiske vilkår næsten var udtømt.
Vi startede systemet, og vi oplevede faktisk belastningsbalancering. Omfanget af vores sky tillod os ikke at få de optimistiske resultater, som udviklerne havde angivet, men det var tydeligt, at balanceringen fungerede.
Vi havde dog nogle ret alvorlige begrænsninger:
- For at træne det neurale netværk er det nødvendigt, at de virtuelle maskiner fungerer uden væsentlige ændringer i flere uger eller måneder.
- Algoritmen er designet til at optimere baseret på analyse af tidligere 'historiske' data.
- For at træne det neurale netværk kræves der en ganske stor mængde data og beregningsressourcer.
- Optimering og belastningsbalancering kan gøres relativt sjældent – en gang hver par timer, hvilket åbenlyst ikke er tilstrækkeligt.
Trin 2
Da vi ikke var tilfredse med situationen, besluttede vi at modificere systemet og for dette at besvare det hovedspørgsmål – hvem laver vi det til?
Først og fremmest – til virksomhedskunder. Det betyder, at vi har brug for et system, der fungerer hurtigt, med de virksomhedsmæssige begrænsninger, der kun forenkler implementeringen.
Det andet spørgsmål – hvad mener vi med 'hurtigt'? Efter en kort debat besluttede vi, at vi kunne tage udgangspunkt i en reaktionstid på 5 – 10 minutter, så kortvarige udsving ikke bringer systemet i resonans.
Det tredje spørgsmål – hvilken størrelse af de balancerede servere skal vælges?
Dette spørgsmål løste sig selv. Som regel gør kunderne ikke serveraggregater meget store, og det er i overensstemmelse med anbefalingerne fra artiklen om at begrænse aggregater til 30-40 servere.
Desuden, ved at segmentere serverpuljen, forenkler vi opgaven for balanceringsalgoritmen.
Det fjerde spørgsmål – hvor passende er det for os at bruge et neuralt netværk med sin lange læringsproces og sjældne balanceringer? Vi har besluttet at opgive det til fordel for mere enkle operationelle algoritmer for at opnå resultater på sekunder.
Beskrivelse af systemet, der bruger sådanne algoritmer og dets mangler, kan findes her
Vi har implementeret og lanceret dette system og fået opmuntrende resultater – det analyserer regelmæssigt belastningen i skyen og giver anbefalinger om placering af virtuelle maskiner, som i betydelig grad viser sig at være korrekte. Selv nu er det tydeligt, at vi kan opnå en 10-15% frigivelse af ressourcer til nye virtuelle maskiner med forbedret kvalitet på de eksisterende.
Når der opdages ubalance i RAM eller CPU, giver systemet kommandoer til Tionix-planlæggeren om at udføre live-migreringen af de krævede virtuelle maskiner. Som det fremgår af overvågningssystemet, er den virtuelle maskine flyttet fra en (øverste) host til en anden (nederste) host og har frigivet hukommelse på den øverste host (markeret med gule cirkler) og optaget den på den nederste (markeret med hvide cirkler).
Vi prøver nu at vurdere effektiviteten af den nuværende algoritme mere præcist og forsøger at finde mulige fejl i den.
Trin 3
Det kunne synes, at vi kunne slappe af her, vente på dokumenterede resultater og afslutte emnet.
Men vi bliver presset til at gennemføre et nyt trin af de tydelige muligheder for optimering,
- Statistikker, for eksempel, og viser, at to- og fireprocessor-systemer er væsentligt langsommere end enprocessor-systemer. Dette betyder, at alle brugere får en betydeligt lavere ydelse af de CPU, RAM, SSD, LAN, FC, der er købt i multiprocessorsystemer, sammenlignet med enprocessorsystemer.
- Selve ressourceplanlæggerne kan have alvorlige fejl, om dette emne.
- De teknologier, som Intel og AMD tilbyder til overvågning af RAM og cache, muliggør studier af adfærden hos virtuelle maskiner og placering af dem, så "støjsende" naboer ikke forstyrrer de "rolige" virtuelle maskiner.
- Udvidelse af parametre (netværk, lager, prioritet for den virtuelle maskine, omkostninger ved migration, dens beredskab til migration).
I alt
Resultatet af vores arbejde med at forbedre balanceringsalgoritmerne er en entydig konklusion om, at nutidige algoritmer kan føre til betydelige ressourceoptimeringer (25-30%) i datacentre og samtidig forbedre kvaliteten af kundeservice.
Algoritmen, der baserer sig på neurale netværk, er uden tvivl interessant, men kræver yderligere udvikling og er på grund af eksisterende begrænsninger ikke velegnet til at løse denne type opgaver i de mængder, der er typiske for private skyer. I de offentlige skyer af betydelig størrelse har algoritmen dog vist gode resultater.
Vi vil uddybe mulighederne for processorer, planlæggere og høj-niveau belastningsbalancering i de kommende artikler.
Kilde: habr.com
