I Vi har diskuterat vÄra försök att anvÀnda Watcher och presenterat en testrapport. SÄdana tester genomför vi regelbundet för lastbalansering och andra kritiska funktioner i stora företags- eller operatormoln.
Den höga komplexiteten hos uppgiften vi löser kan krÀva flera artiklar för att beskriva vÄrt projekt. I dag publicerar vi den andra artikeln i serien, som handlar om lastbalansering av virtuella maskiner i molnet.
Lite terminologi
Företaget VmWare har introducerat verktyget DRS (Distributed Resource Scheduler) för att balansera lasterna i den miljö för virtualisering som de har utvecklat och erbjuder.
Som skrivet av
«VMware DRS (Distributed Resource Scheduler) Àr ett verktyg som balanserar datorkrafter med tillgÀngliga resurser i en virtuell miljö. Verktyget Àr en del av en virtualiseringspaket som kallas VMware Infrastructure.
Med VMware DRS definierar anvÀndare regler för fördelning av fysiska resurser mellan virtuella maskiner (VM). Verktyget kan konfigureras för manuell eller automatisk hantering. Resursgrupper i VMware kan enkelt lÀggas till, tas bort eller omorganiseras. Om sÄ önskas kan resursgrupper isoleras mellan olika affÀrsenheter. Om arbetsbelastningen pÄ en eller flera virtuella maskiner förÀndras kraftigt, omfördelar VMware DRS de virtuella maskinerna mellan fysiska servrar. Om den totala arbetsbelastningen minskar kan vissa fysiska servrar tillfÀlligt stÀngas av, och arbetsbelastningen konsolideras.»
Varför behövs lastbalansering?
Enligt vÄr Äsikt Àr DRS en nödvÀndig funktion i molnet, Àven om det inte betyder att DRS alltid och överallt mÄste anvÀndas. Beroende pÄ syftet och behoven hos molnet kan det finnas olika krav pÄ DRS och metoder för lastbalansering. Det kan finnas situationer dÀr lastbalansering inte alls behövs, eller till och med Àr skadlig.
För att förstÄ bÀttre var och för vilka kunder DRS behövs, lÄt oss övervÀga deras mÄl och uppgifter. Moln kan delas in i offentliga och privata. HÀr Àr de viktigaste skillnaderna mellan dessa moln och kundernas mÄl.
Privata moln / Stora företagskunder
Offentliga moln / Medel och smÄ företag, individer
Huvudkriteriet och mÄlen för operatören
Att tillhandahÄlla en pÄlitlig tjÀnst eller produkt
Minskning av kostnader för tjÀnster i kampen pÄ den konkurrensutsatta marknaden
Krav pÄ tjÀnsten
Tillförlitlighet pÄ alla nivÄer och i alla systemets element
Garantit för prestanda
Prioritering av virtuella maskiner i flera kategorierÂ
Informations- och fysisk sÀkerhet för data
SLA och support dygnet runt
Maximal enkelhet att fÄ tjÀnsten
Relativt enkla tjÀnster
Ansvar för data ligger hos kunden
Prioritering av VM behövs inte
InformationssÀkerhet pÄ nivÄn av standardtjÀnster, ansvar hos kunden
Förseningar kan intrÀffa
Ingen SLA, kvalitet garanteras inte
Support via e-post
Backup Àr inte obligatorisk
Kundens specifika behov
Mycket brett spektrum av applikationer.
Legacy-applikationer, Àrvda inom företaget.
Komplexa anpassade arkitekturer för varje kund.
Affinitetsregler.
Programvaran fungerar utan avbrott i 7x24-lĂ€ge.Â
Backupverktyg "on-the-fly".
FörutsÀgbar cyklisk belastning frÄn kunden.
Standardapplikationer â nĂ€tverksbalansering, Apache, WEB, VPN, SQL
Möjlig nedstÀngning av applikationen under en tid
Fria placeringar av VM i molnet
Backup utförd av kunden
FörutsÀgbar statistiskt genomsnittlig belastning med mÄnga kunder.
Konsekvenser för arkitekturen
Geokluster
Centraliserad eller distribuerad lagringslösning
Reservkraft
Lokal lagring av data pÄ databehandlingsnoder
MÄl för balansering
JÀmn fördelning av belastning
Maximal responsivitet för applikationerÂ
Minimal fördröjningstid vid balansering
Balansering endast vid tydligt behov
Uppdrag av viss utrustning för underhÄll
Minskning av kostnader för tjĂ€nsten och operatörens kostnaderÂ
AvstÀngning av vissa resurser vid lÄg belastning
Energibesparing
Minskade personalkostnader
Vi drar följande slutsatser:
För privata moln, som tillhandahÄlls stora företagskunder, kan DRS tillÀmpas med hÀnsyn till begrÀnsningar:
- informationssÀkerhet och beaktande av affinitetsregler vid balansering;
- tillgÄng till tillrÀckliga resurser i reserv vid en olycka;
- data frÄn virtuella maskiner lagras pÄ en centraliserad eller distribuerad lagringslösning;
- tidsfördelning av administrations-, backup- och balanseringsprocedurer;
- balansering endast inom kundens hostaggregat;
- balansering endast vid stark obalans, de mest effektiva och sÀkra VM-migreringarna (eftersom migrering kan misslyckas);
- balansering i förhÄllande till "lugna" virtuella maskiner (migrering av "bullriga" virtuella maskiner kan ta vÀldigt lÄng tid);
- balansering med hĂ€nsyn till "kostnaden" â belastningen pĂ„ lagringssystemet och nĂ€tverket (vid anpassade arkitekturer för stora kunder);
- balansering med hÀnsyn till de individuella beteendeegenskaperna hos varje VM;
- balansering helst under icke-arbetstid (natt, helger, högtider).
För offentliga moln, som tillhandahÄller tjÀnster till smÄ kunder, kan DRS tillÀmpas mycket oftare, med utökade möjligheter:
- frÄnvaro av begrÀnsningar för informationssÀkerhet och affinitetsregler;
- balansering inom molnet;
- balansering vid all rimlig tid;
- balansering av vilken VM som helst;
- balansering av "bullriga" virtuella maskiner (för att inte störa de andra);
- data frÄn virtuella maskiner finns ofta pÄ lokala diskar;
- beaktande av den genomsnittliga prestandan hos lagringssystemet och nÀtverket (molnets arkitektur Àr en enhet);
- balansering enligt generella regler och befintlig statistik över datacenterbeteende.
Problemets komplexitet
Komplexiteten i balanseringen ligger i det faktum att DRS mÄste arbeta med ett stort antal osÀkra faktorer:
- anvÀndarbeteende i varje kunds informationssystem;
- algoritmer för servernas arbete i informationssystem;
- beteendet hos databasservere;
- belastning pÄ berÀkningsresurser, lagringssystem och nÀtverk;
- interaktion mellan servrar i kampen om molnets resurser.
Belastningen av ett stort antal virtuella applikations- och databasservrar pĂ„ molnresurser sker över tid, och konsekvenserna kan manifestera sig och överlappa varandra med oförutsĂ€gbara effekter över en oförutsĂ€gbar tidsperiod. Ăven för att hantera relativt enkla processer (till exempel för att styra en motor, ett system för vattenuppvĂ€rmning i hemmet) mĂ„ste automatiska regleringssystem anvĂ€nda komplexa algoritmer med Ă„terkoppling.
VÄr uppgift Àr flera nivÄer mer komplicerad, och det finns en risk att systemet inte kan genomföra belastningsbalansering till stabiliserade vÀrden inom rimlig tid, Àven om externa pÄtryckningar frÄn anvÀndare inte uppstÄr.
Historien om vÄra utvecklingar
För att lösa detta problem beslutade vi oss för att inte börja om frÄn början, utan istÀllet bygga pÄ den befintliga kunskapen, och vi började samarbeta med specialister inom detta omrÄde. Lyckligtvis sammanföll vÄr förstÄelse av problematiken helt.
Steg 1
Vi anvÀnde ett system baserat pÄ neuronnÀtsteknik och försökte optimera vÄra resurser utifrÄn det.
Intresset för detta skede lÄg i att pröva en ny teknik, och dess betydelse lÄg i tillÀmpningen av en ovanlig metod för att lösa problemet, dÀr standardmetoderna i övrigt nÀstan hade uttömt sina möjligheter.
Vi lanserade systemet, och vi sÄg verkligen en belastningsbalansering. Storleken pÄ vÄrt moln gjorde att vi inte fick de optimistiska resultaten som utlovades av utvecklarna, men det var tydligt att balanseringen fungerade.
Samtidigt hade vi ganska allvarliga begrÀnsningar:
- För att trÀna neuronnÀtet Àr det nödvÀndigt att de virtuella maskinerna fungerar utan betydande förÀndringar under veckor eller mÄnader.
- Algoritmen Àr utformad för optimering baserat pÄ analys av tidigare "historiska" data.
- För att trÀna neuronnÀtet krÀvs en tillrÀckligt stor mÀngd data och berÀkningsresurser.
- Optimering och balansering kan göras relativt sĂ€llan â en gĂ„ng var flera timmar, vilket uppenbarligen Ă€r otillrĂ€ckligt.
Steg 2
Eftersom vi inte var nöjda med situationen beslutade vi att modifiera systemet, och för detta behövde vi svara pĂ„ den huvudsakliga frĂ„gan â för vem gör vi det?
Först och frĂ€mst â för företagskunder. Det innebĂ€r att vi behöver ett system som fungerar snabbt, med de företagsbegrĂ€nsningar som bara förenklar genomförandet.
Den andra frĂ„gan â vad menar vi med "snabbt"? Efter korta diskussioner beslutade vi att vi kunde utgĂ„ frĂ„n en reaktionstid pĂ„ 5â10 minuter, sĂ„ att kortvariga toppar inte stör systemet.
Den tredje frĂ„gan â vilken storlek pĂ„ det balanseterade antalet servrar ska vi vĂ€lja?
Detta problem löste sig sjÀlvt. Som regel gör inte kunderna serveraggregat sÀrskilt stora, och detta överensstÀmmer med rekommendationerna i artikeln om att begrÀnsa aggregat till 30-40 servrar.
Dessutom, genom att segmentera serverpoolen förenklar vi algoritmens balansjobb.
Den fjĂ€rde frĂ„gan â hur lĂ€mplig Ă€r en neuronnĂ€tverk med dess lĂ„nga inlĂ€rningsprocess och sĂ€llsynta balanseringar för oss? Vi har beslutat att avstĂ„ frĂ„n det till förmĂ„n för enklare operationella algoritmer för att fĂ„ resultat pĂ„ sekunder.
Du kan bekanta dig med systembeskrivningen som anvÀnder sÄdana algoritmer och dess nackdelar
Vi implementerade och lanserade detta system och fick lovande resultat â nu analyserar det regelbundet belastningen i molnet och ger rekommendationer för flyttning av virtuella maskiner, vilket ofta Ă€r korrekt. Redan nu Ă€r det tydligt att vi kan uppnĂ„ 10-15 % frigöring av resurser för nya virtuella maskiner med förbĂ€ttrad kvalitet pĂ„ de befintliga.
Vid upptÀckten av obalans i RAM eller CPU ger systemet kommandon till Tionyx-schemalÀggaren för att genomföra levande migration av de nödvÀndiga virtuella maskinerna. Som syns i övervakningssystemet, flyttades den virtuella maskinen frÄn en (övre) till en annan (nedre) vÀrd och frigjorde minne pÄ den övre vÀrden (markerad i gula cirklar), och tog det motsvarande pÄ den nedre (markerad i vita cirklar).
Just nu försöker vi mer noggrant bedöma effektiviteten av den nuvarande algoritmen och letar efter möjliga fel i den.
Steg 3
Det skulle tyckas att vi kan nu lugna oss, vÀnta pÄ bevisad effektivitet och stÀnga Àmnet.
Men följande uppenbara optimeringsmöjligheter driver oss till att genomföra ett nytt steg
- Statistik, till exempel, och visar att tvÄ- och fyrprocessorsystem presterar betydligt sÀmre Àn enprocessor-system. Det betyder att alla anvÀndare fÄr en mycket mindre avkastning frÄn inköpta CPU, RAM, SSD, LAN, FC i flerprocessor-system jÀmfört med enprocessor-system.
- SjÀlva resursschemalÀggarna kan arbeta med betydande fel, om detta Àmne.
- De teknologier som erbjuds av Intel och AMD för övervakning av RAM och cache gör det möjligt att studera beteendet hos virtuella maskiner och placera dem pÄ ett sÀtt sÄ att "brusiga" grannar inte stör "lugna" virtuella maskiner.
- Utöka uppsÀttningen av parametrar (nÀtverk, lagringssystem, prioritet för virtuella maskiner, kostnad för migrering, beredskap för migrering).
Sammanfattningsvis
Resultatet av vÄrt arbete med att förbÀttra balansalgoritmerna har lett till en tydlig slutsats att genom moderna algoritmer kan man uppnÄ betydande resurseffektivisering (25-30%) i datacenter och samtidigt höja kvaliteten pÄ kundservicen.
Algoritmen som Àr baserad pÄ neurala nÀtverk Àr utan tvekan intressant, men krÀver vidareutveckling och Àr pÄ grund av befintliga begrÀnsningar inte lÀmplig för uppgifter av den storlek som Àr typiska för privata moln. I offentliga moln av betydande storlek har algoritmen emellertid visat goda resultat.
Mer om processorer, schemalÀggare och högre nivÄ av balansning kommer vi att berÀtta i kommande artiklar.
KĂ€lla: habr.com
