В vi pratade om våra försök att använda Watcher och gav en testrapport. Vi utför regelbundet sådana tester för balansering och andra kritiska funktioner i ett stort företag eller operatörsmoln.
Den höga komplexiteten i det problem som löses kan kräva flera artiklar för att beskriva vårt projekt. Idag publicerar vi den andra artikeln i serien, dedikerad till att balansera virtuella maskiner i molnet.
Några terminologier
VmWare-företaget introducerade verktyget DRS (Distributed Resource Scheduler) för att balansera belastningen av virtualiseringsmiljön de utvecklade och erbjöd.
När han skriver
"VMware DRS (Distributed Resource Scheduler) är ett verktyg som balanserar datorbelastningar med tillgängliga resurser i en virtuell miljö. Verktyget är en del av en virtualiseringssvit som heter VMware Infrastructure.
Med VMware DRS definierar användare regler för distribution av fysiska resurser mellan virtuella maskiner (VM). Verktyget kan konfigureras för manuell eller automatisk styrning. VMware-resurspooler kan enkelt läggas till, tas bort eller omorganiseras. Om så önskas kan resurspooler isoleras mellan olika affärsenheter. Om arbetsbelastningen på en eller flera virtuella maskiner förändras dramatiskt omfördelar VMware DRS de virtuella maskinerna över fysiska servrar. Om den totala arbetsbelastningen minskar kan vissa fysiska servrar tillfälligt tas offline och arbetsbelastningen konsolideras."
Varför behövs balansering?
Enligt vår åsikt är DRS en måste-ha molnfunktion, även om det inte betyder att DRS måste användas alltid och överallt. Beroende på molnets syfte och behov kan det finnas olika krav på DRS och balanseringsmetoder. Det kan finnas situationer där balansering inte alls behövs. Eller till och med skadligt.
För att bättre förstå var och för vilka kunder DRS behövs, låt oss överväga deras mål och mål. Moln kan delas in i offentliga och privata. Här är de viktigaste skillnaderna mellan dessa moln och kundmål.
Privata moln / Stora företagskunder
Offentliga moln / Medelstora och små företag, människor
Operatörens huvudsakliga kriterium och mål
Tillhandahålla en pålitlig tjänst eller produkt
Minska kostnaderna för tjänster i kampen på en konkurrensutsatt marknad
Servicekrav
Tillförlitlighet på alla nivåer och i alla systemelement
Garanterad prestanda
Prioritera virtuella maskiner i flera kategorier
Information och fysisk datasäkerhet
SLA och XNUMX/XNUMX support
Maximal lätthet att ta emot tjänsten
Relativt enkla tjänster
Ansvaret för uppgifterna ligger hos kunden
Ingen VM-prioritering krävs
Informationssäkerhet på nivå med standardtjänster, ansvar på uppdragsgivaren
Det kan finnas fel
Ingen SLA, kvalitet inte garanterad
E-postsupport
Säkerhetskopiering är inte nödvändigt
Klientfunktioner
Mycket brett utbud av applikationer.
Äldre applikationer som ärvts i företaget.
Komplexa anpassade arkitekturer för varje kund.
Affinitetsregler.
Programvaran fungerar utan att stoppa i 7x24-läge.
Verktyg för säkerhetskopiering i farten.
Förutsägbar cyklisk kundbelastning.
Typiska applikationer – nätverksbalansering, Apache, WEB, VPN, SQL
Applikationen kan stoppa ett tag
Tillåter godtycklig distribution av virtuella datorer i molnet
Klient backup
Förutsägbar statistiskt genomsnittlig belastning med ett stort antal klienter.
Konsekvenser för arkitektur
Geoklustring
Centraliserad eller distribuerad lagring
Reserverad IBS
Lokal datalagring på beräkningsnoder
Balanserande mål
Jämn lastfördelning
Maximal applikationslyhördhet
Minsta fördröjningstid för balansering
Balansering endast när det är klart nödvändigt
Ta fram lite utrustning för förebyggande underhåll
Minska servicekostnader och operatörskostnader
Inaktiverar vissa resurser vid låg belastning
Energi sparande
Minska personalkostnader
Vi drar följande slutsatser för oss själva:
För privata molntillhandahålls till stora företagskunder, kan DRS användas med följande begränsningar:
- informationssäkerhet och beaktande av affinitetsregler vid balansering;
- tillgång till tillräckliga resurser i reserv i händelse av en olycka;
- virtuell maskindata finns på ett centraliserat eller distribuerat lagringssystem;
- häpnadsväckande administration, säkerhetskopiering och balansering över tid;
- balansering endast inom ett aggregat av klientvärdar;
- balanserar endast när det finns en stark obalans, de mest effektiva och säkra VM-migreringarna (trots allt kan migreringen misslyckas);
- balansera relativt "tysta" virtuella maskiner (migrering av "bullriga" virtuella maskiner kan ta mycket lång tid);
- balansering med hänsyn till "kostnad" - belastningen på lagringssystemet och nätverket (med anpassade arkitekturer för stora kunder);
- balansering med hänsyn till varje virtuell dators individuella beteendeegenskaper;
- Balansering sker företrädesvis under arbetsfri tid (nätter, helger, helgdagar).
För offentliga molntillhandahåller tjänster till små kunder, DRS kan användas mycket oftare, med avancerade funktioner:
- avsaknad av informationssäkerhetsbegränsningar och affinitetsregler;
- balansera i molnet;
- balansering vid någon rimlig tidpunkt;
- balansera valfri virtuell dator;
- balansera "bullriga" virtuella maskiner (för att inte störa andra);
- virtuell maskindata finns ofta på lokala diskar;
- med hänsyn till den genomsnittliga prestandan för lagringssystem och nätverk (molnarkitekturen är enhetlig);
- balansering enligt allmänna regler och tillgänglig statistik över datacenterbeteende.
Problemets komplexitet
Svårigheten att balansera är att DRS måste arbeta med ett stort antal osäkra faktorer:
- beteende hos användare av var och en av klienternas informationssystem;
- Algoritmer för drift av informationssystemservrar;
- beteende hos DBMS-servrar;
- belastning på datorresurser, lagringssystem, nätverk;
- взаимодействие серверов между собой в борьбе за ресурсы облака.
Belastningen av ett stort antal virtuella applikationsservrar och databaser på molnresurser sker över tid, konsekvenserna kan manifestera sig och överlappa varandra med en oförutsägbar effekt under en oförutsägbar tid. Även för att styra relativt enkla processer (till exempel för att styra en motor, ett vattenvärmesystem hemma), måste automatiska styrsystem använda komplexa algoritmer med feedback.
Vår uppgift är många storleksordningar mer komplex och det finns en risk att systemet inte kommer att kunna balansera belastningen till fastställda värden inom rimlig tid, även om det inte finns någon yttre påverkan från användarna.
Historien om vår utveckling
För att lösa detta problem bestämde vi oss för att inte börja om från början, utan att bygga på befintlig erfarenhet, och började interagera med specialister med erfarenhet inom detta område. Lyckligtvis sammanföll vår förståelse av problemet helt.
Steg 1
Vi använde ett system baserat på neural nätverksteknik och försökte optimera våra resurser utifrån det.
Intresset för detta skede var att testa en ny teknik, och dess betydelse var att tillämpa ett icke-standardiserat tillvägagångssätt för att lösa ett problem där, allt annat lika, standardmetoder praktiskt taget hade uttömt sig själva.
Vi lanserade systemet och vi började verkligen balansera. Omfattningen av vårt moln tillät oss inte att få de optimistiska resultaten som utvecklarna angav, men det var tydligt att balanseringen fungerade.
Samtidigt hade vi ganska allvarliga begränsningar:
- För att träna ett neuralt nätverk måste virtuella maskiner köras utan betydande förändringar i veckor eller månader.
- Algoritmen är designad för optimering baserat på analys av tidigare "historiska" data.
- Att träna ett neuralt nätverk kräver en ganska stor mängd data och datorresurser.
- Optimering och balansering kan göras relativt sällan – en gång med några timmars mellanrum, vilket uppenbarligen inte räcker.
Steg 2
Eftersom vi inte var nöjda med läget beslutade vi att modifiera systemet och för att göra detta, svara huvudfrågan – för vem gör vi det?
Först - för företagskunder. Det betyder att vi behöver ett system som fungerar snabbt, med de företagsrestriktioner som bara förenklar implementeringen.
Andra frågan – vad menar du med ordet "prompt"? Som ett resultat av en kort debatt beslutade vi att vi kunde börja med en svarstid på 5–10 minuter, så att kortvariga överspänningar inte skulle föra in systemet i resonans.
Tredje frågan – vilken storlek på det balanserade antalet servrar att välja?
Detta problem löste sig själv. Vanligtvis gör klienter inte serveraggregationer särskilt stora, och detta överensstämmer med artikelns rekommendationer om att begränsa aggregering till 30-40 servrar.
Dessutom, genom att segmentera serverpoolen, förenklar vi uppgiften för balanseringsalgoritmen.
Fjärde frågan – hur passande är ett neuralt nätverk för oss med sin långa inlärningsprocess och sällsynta balansering? Vi bestämde oss för att överge det till förmån för enklare operationella algoritmer för att få resultat på några sekunder.
En beskrivning av ett system som använder sådana algoritmer och dess nackdelar kan hittas
Vi implementerade och lanserade det här systemet och fick uppmuntrande resultat - nu analyserar det regelbundet molnbelastningen och ger rekommendationer för att flytta virtuella maskiner, som i stort sett är korrekta. Redan nu är det tydligt att vi kan uppnå 10-15% frisläppning av resurser för nya virtuella maskiner samtidigt som vi förbättrar kvaliteten på arbetet för befintliga.
När en obalans i RAM eller CPU upptäcks, utfärdar systemet kommandon till Tionix-schemaläggaren för att utföra direktmigrering av de nödvändiga virtuella maskinerna. Som man kan se från övervakningssystemet flyttade 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), respektive ockuperade den på den nedre (markerad i vitt) cirklar).
Nu försöker vi att mer exakt bedöma effektiviteten av den aktuella algoritmen och försöker hitta möjliga fel i den.
Steg 3
Det verkar som att man kan lugna ner sig på detta, vänta på bevisad effektivitet och stänga ämnet.
Men vi pressas att genomföra en ny etapp av följande uppenbara optimeringsmöjligheter
- Statistik, till exempel, и visar att två- och fyraprocessorsystem har betydligt lägre prestanda än enprocessorsystem. Detta innebär att alla användare får betydligt mindre utdata från CPU, RAM, SSD, LAN, FC köpta i flerprocessorsystem jämfört med enprocessor.
- Resursplanerarna själva kan ha allvarliga fel, om detta ämne.
- Teknik som erbjuds av Intel och AMD för att övervaka RAM och cache gör det möjligt att studera beteendet hos virtuella maskiner och placera dem på ett sådant sätt att "bullriga" grannar inte stör "tysta" virtuella maskiner.
- Utökning av uppsättningen parametrar (nätverk, lagringssystem, prioritet för den virtuella maskinen, kostnad för migrering, dess beredskap för migrering).
Totalt
Resultatet av vårt arbete med att förbättra balanseringsalgoritmerna var den tydliga slutsatsen att med moderna algoritmer är det möjligt att uppnå betydande optimering av datacenterresurser (25-30%) och samtidigt förbättra kvaliteten på kundservice.
En algoritm baserad på neurala nätverk är förvisso en intressant lösning, men en som behöver vidareutvecklas, och på grund av befintliga begränsningar är den inte lämplig för att lösa den här typen av problem på de volymer som är typiska för privata moln. Samtidigt visade algoritmen goda resultat i offentliga moln av betydande storlek.
Vi kommer att berätta mer om funktionerna hos processorer, schemaläggare och högnivåbalansering i följande artiklar.
Källa: will.com