Belastningsbalansering i Openstack (Del 2)

I forrige artikkel Vi har omtalt forsøket på å bruke Watcher og presentert testrapporten. Slike tester gjennomfører vi periodisk for å balansere og for andre kritiske funksjoner i store bedrifts- eller operatørskyer.

Den høye kompleksiteten i oppgaven kan kreve flere artikler for å beskrive prosjektet vårt. I dag publiserer vi den andre artikkelen i serien, som omhandler balansering av virtuelle maskiner i skyen.

Litt terminologi

VmWare har introdusert verktøyet DRS (Distributed Resource Scheduler) for belastningsbalansering i miljøet deres for virtualisering.

Som det står skrevet searchvmware.techtarget.com/definition/VMware-DRS
«VMware DRS (Distributed Resource Scheduler) er et verktøy som balanserer beregningsbelastninger med tilgjengelige ressurser i et virtuelt miljø. Verktøyet er en del av virtualiseringspakken kalt VMware Infrastructure.

Med VMware DRS kan brukerne definere regler for fordeling av fysiske ressurser mellom virtuelle maskiner (VM). Verktøyet kan konfigureres for manuell eller automatisk styring. VMware-resurspuljer kan enkelt legges til, fjernes eller reorganiseres. Ved behov kan ressurspuljer isoleres mellom ulike forretningsenheter. Hvis arbeidsbelastningen på en eller flere virtuelle maskiner endres drastisk, fordeler VMware DRS de virtuelle maskinene mellom de fysiske serverne. Hvis den samlede arbeidsbelastningen avtar, kan noen fysiske servere midlertidig slås av, og arbeidsbelastningen konsolideres.

Hvorfor er balansering nødvendig?

Vi mener at DRS er en obligatorisk funksjon i skyen, selv om det ikke betyr at DRS må brukes alltid og overalt. Avhengig av formålet og behovene til skyen kan det være forskjellige krav til DRS og metodene for balansering. Det kan også finnes situasjoner der balansering ikke er nødvendig i det hele tatt. Eller til og med kan være skadelig.

For å bedre forstå hvor og for hvilke kunder DRS er nødvendig, la oss vurdere deres mål og oppgaver. Skyr kan deles inn i offentlige og private. Her er hovedforskjellene mellom disse skyene og kundenes mål.

Private skyer / Store bedriftskunder
Offentlige skyer / Små og mellomstore bedrifter, enkeltpersoner

Hovedkriteriet og målsetningen til operatøren
Tilby pålitelig tjeneste eller produkt
Reduksjon av kostnadene for tjenester i konkurransen på markedet

Krav til tjenesten
Pålitelighet på alle nivåer og i alle systemkomponenter

Garanti for ytelse

Prioritering av virtuelle maskiner i flere kategorier 

Informasjons- og fysisk datasikkerhet

SLA og døgnåpen støtte
Maksimal enkelhet i å få tilgang til tjenesten

Relativt enkle tjenester

Ansvar for data ligger hos kunden

Prioritering av VM er ikke nødvendig

Informasjonssikkerhet på nivå med typiske tjenester, ansvar ligger hos kunden

Det kan oppstå avbrudd

Ingen SLA, kvaliteten er ikke garantert

Støtte via e-post

Sikkerhetskopiering er ikke obligatorisk

Kundeegenskaper
Et svært bredt spekter av applikasjoner.

Legacy-applikasjoner, arvet fra selskapet.

Komplekse tilpassede arkitekturer for hver kunde.

Affinitet regler.

Programvare opererer uten stopp i 7x24-modus. 

Sikkerhetskopieringsverktøy "i sanntid."

Forutsigbar syklisk belastning fra kunden.
Typiske applikasjoner – nettverksbalansering, Apache, WEB, VPN, SQL

Applikasjonen kan stoppes for en kort periode

Vil tillate vilkårlig distribusjon av VM i skyen

Sikkerhetskopiering utført av kunden

Forutsigbar statistisk gjennomsnittlig belastning ved mange kunder.

Konsekvenser for arkitekturen
Geokluster

Sentralisert eller distribuert lagringssystem

Reserverbar lagringskontroller
Lokal datalagring på databehandlingsnoder

Mål med balanselegging
Jevn fordeling av belastning

Maksimal responsivitet for applikasjoner 

Minimalt ventetid ved balanselegging

Balansering kun ved åpenbar nødvendighet

Ta deler av utstyret ut for vedlikehold
Reduksjon av kostnadene for tjenesten og operatørens utgifter 

Frakobling av deler av ressursene ved lav belastning

Energibesparelse

Reduksjon av personalkostnader

Vi trekker følgende konklusjoner:

For private skyer, levert til store bedriftskunder, kan DRS brukes med hensyn til begrensninger:

• informasjonssikkerhet og hensyn til affinitetsregler ved balanselegging;
• tilgjengelighet av tilstrekkelig ressurser i reserve ved ulykker;
• data fra virtuelle maskiner ligger på sentraliserte eller distribuerte lagringssystemer;
• skjelettene av administrasjonsprosedyrer, sikkerhetskopiering og lastbalansering;
• lastbalansering kun innenfor klientens samling av verter;
• lastbalansering kun ved stor ubalanse, de mest effektive og trygge migrasjonene av virtuelle maskiner (fordi migreringen kan mislykkes);
• lastbalansering relatert til «rolige» virtuelle maskiner (migrering av «støyende» virtuelle maskiner kan ta lang tid);
• lastbalansering med hensyn til «kostnad» — belastning på spesialiserte lagringssystemer og nettverk (ved tilpassede arkitekturer for store kunder);
• lastbalansering med hensyn til de individuelle atferdsmønstrene til hver virtuell maskin;
• lastbalansering helst i ikke-arbeidstid (natt, helger, høytider).

For offentlige skyer, som tilbyr tjenester til små kunder, kan DRS brukes mye oftere, med utvidede funksjoner:

• ingen begrensninger for informasjonssikkerhet og affinitetsregler;
• lastbalansering innenfor skyen;
• lastbalansering til enhver rimelig tid;
• lastbalansering av enhver virtuell maskin;
• lastbalansering av «støyende» virtuelle maskiner (for å unngå å forstyrre de andre);
• data fra virtuelle maskiner ligger ofte på lokale disker;
• håndtering av gjennomsnittlig ytelse av spesialiserte lagringssystemer og nettverk (arkitekturen av skyen er enhetlig);
• lastbalansering etter generelle regler og eksisterende statistikk for oppførselen i datasenteret.

Problemens kompleksitet

Kompleksiteten ved lastbalansering er at DRS må håndtere et stort antall usikre faktorer:

• oppførselen til brukerne av hvert av kundens informasjonssystemer;
• algoritmer for drift av servere i informasjonssystemer;
• oppførselen til databasen sine servere;
• belastning på beregningsressurser, lagringssystemer, nettverk;
• samspillet mellom serverne i kampen om ressursene i skyen.

Belastningen fra mange virtuelle applikasjons- og databaseservere på skyressursene skjer over tid, og konsekvensene kan manifestere seg og overlappe hverandre med uforutsigbare effekter over uforutsigbar tid. Selv for å håndtere relativt enkle prosesser (for eksempel å kontrollere en motor, et vannoppvarmingssystem i et hus) må automatiserte reguleringssystemer bruke kompliserte proportional-integral-derivative algoritmer med tilbakemelding.

Oppdraget vårt er betydelig mer komplisert, og det finnes en risiko for at systemet ikke vil kunne balansere lasten til etablerte verdier innen rimelig tid, selv om det ikke oppstår eksterne påvirkninger fra brukere.

Historien om våre utviklinger

For å løse dette problemet bestemte vi oss for å ikke starte fra bunnen av, men heller bygge videre på eksisterende erfaringer, og begynte å samarbeide med spesialister som hadde erfaring på dette området. Heldigvis var vår forståelse av problematikken helt på linje.

Trinn 1

Vi brukte et system basert på nevralnettverksteknologi, og prøvde på den måten å optimalisere ressursene våre.

Interessen ved dette stadiet besto i å teste ut en ny teknologi, mens viktigheten lå i å anvende en utradisjonell tilnærming til problemløsning, der standardmetoder knapt hadde nådd sitt metningspunkt under ellers like forhold.

Vi lanserte systemet, og vi begynte faktisk å oppnå balanse. Størrelsen på skyen vår gjorde at vi ikke fikk optimale resultater som utviklerne hadde meldt, men det var tydelig at balansen fungerte.

Samtidig hadde vi betydelige begrensninger:

• For å trene nevralnettverket er det nødvendig at virtuelle maskiner fungerer uten vesentlige endringer i flere uker eller måneder.
• Algoritmen er utviklet for optimalisering basert på analysen av tidligere "historiske" data.
• For å trene nevralnettverket kreves det en betydelig mengde data og beregningsressurser.
• Optimalisering og balanse kan gjøres relativt sjelden – hver few timer, noe som er åpenbart utilstrekkelig.

Trinn 2

Ettersom vi ikke var fornøyd med situasjonen, bestemte vi oss for å modifisere systemet, og for dette måtte vi svare på det viktigste spørsmålet – hvem lager vi det for?

Først og fremst – for bedriftskunder. Det betyr at vi trenger et system som fungerer raskt, med de bedriftsmessige begrensningene som bare forenkler implementeringen.

Det andre spørsmålet – hva menes med ordet «raskt»? Etter korte debatter bestemte vi oss for at vi kunne forholde oss til en responstid på 5 – 10 minutter, slik at kortvarige topper ikke ville føre systemet inn i resonans.

Det tredje spørsmålet – hvilken størrelse på antall servere skal balanseres?
Dette problemet løste seg selv. Som regel gjør ikke kunder serveraggregater veldig store, og det er i samsvar med anbefalingene i artikkelen om å begrense aggregatene til 30-40 servere.

I tillegg forenkler vi oppgaven for balansealgoritmen ved å segmentere serverpoolen.

Det fjerde spørsmålet – hvor godt passer et nevralt nettverk med sin lange læringsprosess og sjeldne balanseringer for oss? Vi har besluttet å gå bort fra det til fordel for enklere operative algoritmer, slik at vi kan få resultater på sekunder.

Du kan finne beskrivelsen av systemet som bruker slike algoritmer og dets ulemper here

Vi har implementert og lansert dette systemet og fått lovende resultater – nå analyserer det regelmessig belastningen i skyen og gir anbefalinger om å flytte virtuelle maskiner, som i stor grad er korrekte. Selv nå er det synlig at vi kan oppnå 10-15% frigjøring av ressurser for nye virtuelle maskiner med forbedring av kvaliteten på de eksisterende.

Ved oppdagelse av ubalanse i RAM eller CPU gir systemet kommandoer til Tionix-planleggeren om å utføre levende migrasjon av nødvendige virtuelle maskiner. Som det fremgår av overvåkningssystemet, flyttet den virtuelle maskinen fra en (øvre) vert til en annen (nedre) vert og frigjorde minne på den øvre verten (markert med gule sirkler), og okkuperte det tilsvarende på den nedre (markert med hvite sirkler).

Akkurat nå prøver vi å vurdere effektiviteten til den gjeldende algoritmen mer nøyaktig og leter etter mulige feil.

Trinn 3

Man skulle tro at vi kunne roe oss ned, vente på bevist effektivitet og avslutte emnet.
Men vi blir drevet til å gjennomføre et nytt trinn av følgende åpenbare optimaliseringsmuligheter

1. Statistikken, for eksempel, here og here viser at to- og fireprosessor-systemer er betydelig dårligere enn enkeltprosessor-systemer i ytelse. Dette betyr at alle brukere får betydelig lavere avkastning fra CPU, RAM, SSD, LAN, FC i kjøpte multiprosessorsystemer sammenlignet med enkeltprosessor-systemer.
2. Selve ressursplanleggerne kan operere med alvorlige feil, her er en av artiklene om dette emnet.
3. Teknologiane som tilbys av Intel og AMD for overvåking av RAM og cache gjør det mulig å studere atferden til virtuelle maskiner og plassere dem slik at «bråkete» naboer ikke forstyrrer de «rolige» virtuelle maskinene.
4. Utvidelse av parametrene (nettverk, lagringssystem, prioritet for virtuell maskin, kostnad ved migrering, samt klarhet for migrering).

Totalt

Resultatet av vårt arbeid med å forbedre balanseringsalgoritmene har ført til en tydelig konklusjon om at moderne algoritmer kan oppnå betydelig optimalisering av ressurser (25-30%) i datasentre, samtidig som kvaliteten på kundeservicen forbedres.

Algoritmen basert på nevrale nettverk er uten tvil interessant, men nødvendig med videre utvikling, og på grunn av eksisterende begrensninger er den ikke passende for denne typen oppgaver på volum som er karakteristisk for private skyer. Imidlertid har algoritmen vist gode resultater i offentlige skyer av betydelig størrelse.

Mer informasjon om prosessorer, planleggere og høy-nivå balansering vil bli delt i de følgende artiklene.

Kilde: habr.com