В vi talte om vores forsøg på at bruge Watcher og leverede en testrapport. Vi udfører periodisk sådanne tests for balancering og andre kritiske funktioner i en stor virksomhed eller operatørsky.
Den høje kompleksitet af det problem, der skal løses, kan kræve flere artikler for at beskrive vores projekt. I dag udgiver vi den anden artikel i serien, dedikeret til at balancere virtuelle maskiner i skyen.
Noget terminologi
VmWare-virksomheden introducerede DRS-værktøjet (Distributed Resource Scheduler) for at balancere belastningen af det virtualiseringsmiljø, de udviklede og tilbød.
Ifølge
"VMware DRS (Distributed Resource Scheduler) er et værktøj, der balancerer computerbelastninger med tilgængelige ressourcer i et virtuelt miljø. Hjælpeprogrammet er en del af en virtualiseringspakke kaldet VMware Infrastructure.
Med VMware DRS definerer brugerne regler for fordeling af fysiske ressourcer mellem virtuelle maskiner (VM'er). Hjælpeprogrammet kan konfigureres til manuel eller automatisk styring. VMware-ressourcepuljer kan nemt tilføjes, fjernes eller omorganiseres. Hvis det ønskes, kan ressourcepuljer isoleres mellem forskellige forretningsenheder. Hvis arbejdsbelastningen på en eller flere virtuelle maskiner ændrer sig dramatisk, omdistribuerer VMware DRS de virtuelle maskiner på tværs af fysiske servere. Hvis den samlede arbejdsbyrde falder, kan nogle fysiske servere midlertidigt blive taget offline, og arbejdsbyrden konsolideres."
Hvorfor er balancering nødvendig?
Efter vores mening er DRS en must-have funktion i skyen, selvom det ikke betyder, at DRS skal bruges altid og overalt. Afhængig af skyens formål og behov kan der være forskellige krav til DRS og balanceringsmetoder. Der kan være situationer, hvor balancering slet ikke er nødvendig. Eller endda skadeligt.
For bedre at forstå, hvor og for hvilke kunder DRS er nødvendigt, lad os overveje deres mål og målsætninger. Skyer kan opdeles i offentlige og private. Her er de vigtigste forskelle mellem disse skyer og kundemål.
Private skyer / Store virksomhedskunder
Offentlige skyer / mellemstore og små virksomheder, mennesker
Operatørens vigtigste kriterium og mål
At levere en pålidelig service eller et produkt
Reduktion af omkostningerne til tjenester i kampen på et konkurrencepræget marked
Servicekrav
Pålidelighed på alle niveauer og i alle systemelementer
Garanteret ydeevne
Prioriter virtuelle maskiner i flere kategorier
Information og fysisk datasikkerhed
SLA og XNUMX/XNUMX support
Maksimal nem at modtage servicen
Relativt simple tjenester
Ansvaret for data ligger hos kunden
Ingen VM-prioritering påkrævet
Informationssikkerhed på niveau med standardydelser, ansvar på klienten
Der kan være fejl
Ingen SLA, kvalitet ikke garanteret
E-mail support
Sikkerhedskopiering er ikke nødvendig
Klientfunktioner
Meget bred vifte af applikationer.
Ældre applikationer nedarvet i virksomheden.
Komplekse tilpassede arkitekturer for hver klient.
Affinitetsregler.
Softwaren fungerer uden stop i 7x24-tilstand.
On-the-fly værktøjer til sikkerhedskopiering.
Forudsigelig cyklisk kundebelastning.
Typiske applikationer – netværksbalancering, Apache, WEB, VPN, SQL
Applikationen kan stoppe i et stykke tid
Tillader vilkårlig distribution af VM'er i skyen
Klient backup
Forudsigelig statistisk gennemsnitsbelastning med et stort antal klienter.
Implikationer for arkitektur
Geoclustering
Centraliseret eller distribueret opbevaring
Reserveret IBS
Lokal datalagring på compute noder
Balancerende mål
Jævn belastningsfordeling
Maksimal applikationsrespons
Minimum forsinkelsestid for balancering
Afbalancering kun, når det er klart nødvendigt
Tag noget udstyr frem til forebyggende vedligeholdelse
Reduktion af serviceomkostninger og operatøromkostninger
Deaktivering af nogle ressourcer i tilfælde af lav belastning
Sparer energi
Reduktion af personaleomkostninger
Vi drager følgende konklusioner for os selv:
Til private skyerleveret til store erhvervskunder, kan DRS bruges med følgende begrænsninger:
- informationssikkerhed og hensyntagen til affinitetsregler ved balancering;
- tilgængelighed af tilstrækkelige ressourcer i reserve i tilfælde af en ulykke;
- virtuelle maskindata er placeret på et centraliseret eller distribueret lagersystem;
- svimlende administrations-, backup- og balanceringsprocedurer over tid;
- kun balancering inden for et aggregat af klientværter;
- kun balancere, når der er en stærk ubalance, de mest effektive og sikre VM-migreringer (migrering kan trods alt mislykkes);
- balancering af relativt "stille" virtuelle maskiner (migrering af "støjende" virtuelle maskiner kan tage meget lang tid);
- balancering under hensyntagen til "omkostningerne" - belastningen på lagersystemet og netværket (med tilpassede arkitekturer til store kunder);
- balancering under hensyntagen til de individuelle adfærdskarakteristika for hver VM;
- Afbalancering sker fortrinsvis i ikke-arbejdstid (aftener, weekender, helligdage).
Til offentlige skyerleverer tjenester til små kunder, kan DRS bruges meget oftere med avancerede funktioner:
- fravær af informationssikkerhedsrestriktioner og affinitetsregler;
- balance i skyen;
- balancering på ethvert rimeligt tidspunkt;
- balancering af enhver VM;
- balancering af "støjende" virtuelle maskiner (for ikke at forstyrre andre);
- virtuelle maskine data er ofte placeret på lokale diske;
- under hensyntagen til den gennemsnitlige ydeevne af lagersystemer og netværk (sky-arkitekturen er samlet);
- balancering i henhold til generelle regler og tilgængelige datacenteradfærdsstatistikker.
Problemets kompleksitet
Det svære ved at balancere er, at DRS skal arbejde med en lang række usikre faktorer:
- adfærd hos brugere af hver af kundernes informationssystemer;
- Algoritmer til drift af informationssystemservere;
- opførsel af DBMS-servere;
- belastning på computerressourcer, lagersystemer, netværk;
- interaktion mellem servere med hinanden i kampen om cloud-ressourcer.
Belastningen af et stort antal virtuelle applikationsservere og databaser på cloud-ressourcer sker over tid, konsekvenserne kan manifestere sig og overlappe hinanden med en uforudsigelig effekt over en uforudsigelig tid. Selv for at styre relativt simple processer (for eksempel at styre en motor, et vandvarmesystem derhjemme), skal automatiske kontrolsystemer bruge komplekse algoritmer med feedback.
Vores opgave er mange størrelsesordener mere kompleks, og der er en risiko for, at systemet ikke vil være i stand til at afbalancere belastningen til fastlagte værdier inden for rimelig tid, selvom der ikke er ydre påvirkninger fra brugerne.
Historien om vores udvikling
For at løse dette problem besluttede vi ikke at starte fra bunden, men at bygge videre på eksisterende erfaring og begyndte at interagere med specialister med erfaring på dette område. Heldigvis faldt vores forståelse af problemet fuldstændig sammen.
Trin 1
Vi brugte et system baseret på neural netværksteknologi og forsøgte at optimere vores ressourcer baseret på det.
Interessen for denne fase var at teste en ny teknologi, og dens betydning var at anvende en ikke-standard tilgang til at løse et problem, hvor standardtilgange, alt andet lige, praktisk talt var udtømt.
Vi lancerede systemet, og vi begyndte virkelig at balancere. Skalaen af vores sky tillod os ikke at få de optimistiske resultater, som udviklerne sagde, men det var tydeligt, at balanceringen virkede.
Samtidig havde vi ganske alvorlige begrænsninger:
- For at træne et neuralt netværk skal virtuelle maskiner køre uden væsentlige ændringer i uger eller måneder.
- Algoritmen er designet til optimering baseret på analyse af tidligere "historiske" data.
- Træning af et neuralt netværk kræver en ret stor mængde data og computerressourcer.
- Optimering og afbalancering kan foretages relativt sjældent – en gang med få timers mellemrum, hvilket tydeligvis ikke er nok.
Trin 2
Da vi ikke var tilfredse med tingenes tilstand, besluttede vi at ændre systemet, og for at gøre dette, svare hovedspørgsmål – hvem laver vi det til?
Først - for erhvervskunder. Det betyder, at vi har brug for et system, der fungerer hurtigt, med de virksomhedsbegrænsninger, der kun forenkler implementeringen.
Andet spørgsmål – hvad mener du med ordet "prompt"? Som et resultat af en kort debat besluttede vi, at vi kunne starte med en responstid på 5-10 minutter, så kortvarige stigninger ikke ville bringe systemet i resonans.
Tredje spørgsmål – hvilken størrelse af det balancerede antal servere at vælge?
Dette problem løste sig selv. Typisk gør klienter ikke serveraggregationer særlig store, og det er i overensstemmelse med artiklens anbefalinger om at begrænse aggregation til 30-40 servere.
Derudover forenkler vi balanceringsalgoritmens opgave ved at segmentere serverpuljen.
Fjerde spørgsmål – hvor velegnet er et neuralt netværk for os med dets lange læreproces og sjældne balancering? Vi besluttede at opgive det til fordel for enklere operationelle algoritmer for at få resultater på få sekunder.
En beskrivelse af et system, der bruger sådanne algoritmer, og dets ulemper kan findes
Vi implementerede og lancerede dette system og fik opmuntrende resultater - nu analyserer det regelmæssigt skybelastningen og giver anbefalinger til flytning af virtuelle maskiner, som stort set er korrekte. Allerede nu er det klart, at vi kan opnå 10-15% frigivelse af ressourcer til nye virtuelle maskiner og samtidig forbedre kvaliteten af arbejdet på de eksisterende.
Når der opdages en ubalance i RAM eller CPU, udsteder systemet kommandoer til Tionix-planlæggeren om at udføre live-migrering af de nødvendige virtuelle maskiner. Som det kan ses fra overvågningssystemet, flyttede den virtuelle maskine fra en (øverste) til en anden (nedre) vært og frigjorde hukommelse på den øverste vært (fremhævet i gule cirkler), henholdsvis optog den på den nederste (fremhævet med hvidt) cirkler).
Nu forsøger vi mere præcist at vurdere effektiviteten af den nuværende algoritme og forsøger at finde mulige fejl i den.
Trin 3
Det ser ud til, at man kan falde til ro på dette, vente på bevist effektivitet og lukke emnet.
Men vi bliver presset til at gennemføre en ny fase af følgende åbenlyse optimeringsmuligheder
- Statistik kan f.eks. и viser, at systemer med to og fire processorer er væsentligt lavere i ydeevne end systemer med enkelt processor. Det betyder, at alle brugere får væsentligt mindre output fra CPU, RAM, SSD, LAN, FC købt i multiprocessorsystemer sammenlignet med enkeltprocessorsystemer.
- Selve ressourceplanlæggerne kan have alvorlige fejl, om dette emne.
- Teknologier, der tilbydes af Intel og AMD til overvågning af RAM og cache, gør det muligt at studere virtuelle maskiners adfærd og placere dem på en sådan måde, at "støjende" naboer ikke forstyrrer "stille" virtuelle maskiner.
- Udvidelse af sættet af parametre (netværk, lagersystem, prioritet af den virtuelle maskine, omkostninger ved migrering, dens parathed til migrering).
I alt
Resultatet af vores arbejde med at forbedre balanceringsalgoritmer var den klare konklusion, at ved hjælp af moderne algoritmer er det muligt at opnå betydelig optimering af datacenterressourcer (25-30%) og samtidig forbedre kvaliteten af kundeservice.
En algoritme baseret på neurale netværk er bestemt en interessant løsning, men en der skal udvikles yderligere, og på grund af eksisterende begrænsninger er den ikke egnet til at løse denne form for problemer på de volumener, der er typiske for private skyer. Samtidig viste algoritmen gode resultater i offentlige skyer af betydelig størrelse.
Vi vil fortælle dig mere om mulighederne for processorer, planlæggere og balancering på højt niveau i de følgende artikler.
Kilde: www.habr.com