В we spraken over onze pogingen om Watcher te gebruiken en leverden een testrapport op. We voeren periodiek dergelijke tests uit voor het balanceren en andere kritieke functies van een grote onderneming of operatorcloud.
De hoge complexiteit van het probleem dat wordt opgelost, vereist mogelijk meerdere artikelen om ons project te beschrijven. Vandaag publiceren we het tweede artikel in de serie, gewijd aan het balanceren van virtuele machines in de cloud.
Een beetje terminologie
Het bedrijf VmWare introduceerde het hulpprogramma DRS (Distributed Resource Scheduler) om de belasting van de virtualisatieomgeving die zij ontwikkelden en aanboden te verdelen.
Zoals hij schrijft
“VMware DRS (Distributed Resource Scheduler) is een hulpprogramma dat de computerbelasting in evenwicht brengt met de beschikbare bronnen in een virtuele omgeving. Het hulpprogramma maakt deel uit van een virtualisatiesuite genaamd VMware Infrastructure.
Met VMware DRS definiëren gebruikers regels voor het verdelen van fysieke bronnen over virtuele machines (VM's). Het hulpprogramma kan worden geconfigureerd voor handmatige of automatische besturing. VMware-resourcepools kunnen eenvoudig worden toegevoegd, verwijderd of gereorganiseerd. Indien gewenst kunnen resourcepools tussen verschillende bedrijfseenheden worden geïsoleerd. Als de werklast op een of meer virtuele machines dramatisch verandert, verdeelt VMware DRS de virtuele machines opnieuw over fysieke servers. Als de totale werklast afneemt, kunnen sommige fysieke servers tijdelijk offline worden gehaald en de werklast worden geconsolideerd."
Waarom is balanceren nodig?
Wat ons betreft is DRS een onmisbare cloudfunctie, al betekent dit niet dat DRS altijd en overal gebruikt moet worden. Afhankelijk van het doel en de behoeften van de cloud kunnen er verschillende vereisten zijn voor DRS en balanceringsmethoden. Er kunnen zich situaties voordoen waarin balanceren helemaal niet nodig is. Of zelfs schadelijk.
Laten we, om beter te begrijpen waar en voor welke klanten DRS nodig is, hun doelen en doelstellingen bekijken. Clouds kunnen worden onderverdeeld in openbaar en privé. Dit zijn de belangrijkste verschillen tussen deze clouds en klantdoelen.
Privéclouds / Grote zakelijke klanten
Publieke clouds / Middelgrote en kleine bedrijven, mensen
Het belangrijkste criterium en de doelen van de operator
Het leveren van een betrouwbare dienst of product
Het verlagen van de kosten van diensten in de strijd op een concurrerende markt
Servicevereisten
Betrouwbaarheid op alle niveaus en in alle systeemelementen
Gegarandeerde prestaties
Prioriteer virtuele machines in verschillende categorieën
Informatie- en fysieke gegevensbeveiliging
SLA en XNUMX/XNUMX ondersteuning
Maximaal gemak bij het ontvangen van de service
Relatief eenvoudige diensten
De verantwoordelijkheid voor de gegevens ligt bij de opdrachtgever
Geen VM-prioriteit vereist
Informatiebeveiliging op het niveau van standaard dienstverlening, verantwoordelijkheid bij de klant
Er kunnen storingen optreden
Geen SLA, kwaliteit niet gegarandeerd
E-mail ondersteuning
Back-up is niet nodig
Functies van de klant
Zeer breed scala aan toepassingen.
Oudere applicaties die in het bedrijf zijn geërfd.
Complexe maatwerkarchitecturen voor elke klant.
Affiniteitsregels.
De software werkt zonder te stoppen in de 7x24-modus.
On-the-fly back-uptools.
Voorspelbare cyclische klantenbelasting.
Typische toepassingen – netwerkbalancering, Apache, WEB, VPN, SQL
Het kan zijn dat de toepassing een tijdje stopt
Maakt willekeurige distributie van VM's in de cloud mogelijk
Back-up van de klant
Voorspelbare statistisch gemiddelde belasting bij een groot aantal cliënten.
Implicaties voor de architectuur
Geoclustering
Gecentraliseerde of gedistribueerde opslag
Gereserveerde IBS
Lokale gegevensopslag op rekenknooppunten
Evenwichtige doelen
Gelijkmatige verdeling van de belasting
Maximale responsiviteit van applicaties
Minimale vertragingstijd voor balancering
Alleen balanceren als dat duidelijk nodig is
Even wat apparatuur meenemen voor preventief onderhoud
Verlaging van de servicekosten en operatorkosten
Sommige bronnen uitschakelen bij lage belasting
Energiebesparend
Het verlagen van de personeelskosten
Wij trekken voor onszelf de volgende conclusies:
Voor privécloudsDRS wordt aangeboden aan grote zakelijke klanten en kan worden gebruikt met de volgende beperkingen:
- informatiebeveiliging en het rekening houden met affiniteitsregels bij het balanceren;
- beschikbaarheid van voldoende reservemiddelen in geval van een ongeval;
- gegevens van virtuele machines bevinden zich op een gecentraliseerd of gedistribueerd opslagsysteem;
- gespreide beheer-, back-up- en balanceringsprocedures in de loop van de tijd;
- alleen balanceren binnen een aggregaat van clienthosts;
- alleen balanceren als er sprake is van een sterke onbalans, de meest effectieve en veilige VM-migraties (migratie kan immers mislukken);
- het balanceren van relatief ‘stille’ virtuele machines (de migratie van ‘luidruchtige’ virtuele machines kan erg lang duren);
- balanceren rekening houdend met “kosten” – de belasting van het opslagsysteem en netwerk (met op maat gemaakte architecturen voor grote klanten);
- balancering waarbij rekening wordt gehouden met de individuele gedragskenmerken van elke VM;
- Het balanceren gebeurt bij voorkeur buiten werktijd (nachten, weekends, feestdagen).
Voor openbare cloudsDoor diensten te leveren aan kleine klanten, kan DRS veel vaker worden gebruikt, met geavanceerde mogelijkheden:
- afwezigheid van informatiebeveiligingsbeperkingen en affiniteitsregels;
- balanceren binnen de cloud;
- balanceren op elk redelijk tijdstip;
- het balanceren van elke VM;
- het balanceren van “luidruchtige” virtuele machines (om anderen niet te storen);
- gegevens van virtuele machines bevinden zich vaak op lokale schijven;
- rekening houdend met de gemiddelde prestaties van opslagsystemen en netwerken (de cloudarchitectuur is uniform);
- balanceren volgens algemene regels en beschikbare gedragsstatistieken van datacenters.
Complexiteit van het probleem
De moeilijkheid bij het balanceren is dat DRS met een groot aantal onzekere factoren moet werken:
- gedrag van gebruikers van elk van de informatiesystemen van de klant;
- algoritmen voor de werking van informatiesysteemservers;
- gedrag van DBMS-servers;
- belasting van computerbronnen, opslagsystemen, netwerk;
- interactie van servers met elkaar in de strijd om cloudbronnen.
De belasting van een groot aantal virtuele applicatieservers en databases op cloudbronnen vindt in de loop van de tijd plaats, de gevolgen kunnen zich manifesteren en elkaar overlappen met een onvoorspelbaar effect gedurende een onvoorspelbare tijd. Zelfs om relatief eenvoudige processen te besturen (bijvoorbeeld om een motor of een waterverwarmingssysteem thuis te besturen), moeten automatische besturingssystemen gebruik maken van complexe algoritmen met feedback.
Onze taak is vele ordes van grootte complexer en het risico bestaat dat het systeem de belasting niet binnen een redelijke tijd in evenwicht kan brengen met de vastgestelde waarden, zelfs als er geen externe invloeden van gebruikers zijn.
Geschiedenis van onze ontwikkelingen
Om dit probleem op te lossen, besloten we niet helemaal opnieuw te beginnen, maar voort te bouwen op bestaande ervaringen, en begonnen we te communiceren met specialisten met ervaring op dit gebied. Gelukkig viel ons begrip van het probleem volledig samen.
Stage 1
We gebruikten een systeem gebaseerd op neurale netwerktechnologie en probeerden op basis daarvan onze bronnen te optimaliseren.
Het belang van deze fase lag in het testen van een nieuwe technologie, en het belang ervan lag in het toepassen van een niet-standaardbenadering bij het oplossen van een probleem waar, onder overigens gelijke omstandigheden, de standaardbenaderingen zichzelf praktisch hadden uitgeput.
We lanceerden het systeem en we zijn echt begonnen met balanceren. Door de omvang van onze cloud konden we niet de optimistische resultaten behalen die door de ontwikkelaars waren aangegeven, maar het was duidelijk dat de balans werkte.
Tegelijkertijd hadden we behoorlijk ernstige beperkingen:
- Om een neuraal netwerk te trainen, moeten virtuele machines weken of maanden zonder noemenswaardige veranderingen draaien.
- Het algoritme is ontworpen voor optimalisatie op basis van de analyse van eerdere ‘historische’ gegevens.
- Het trainen van een neuraal netwerk vereist een vrij grote hoeveelheid gegevens en computerbronnen.
- Optimalisatie en balancering kunnen relatief zelden worden uitgevoerd: eens in de paar uur, wat duidelijk niet voldoende is.
Stage 2
Omdat we niet tevreden waren met de stand van zaken, hebben we besloten het systeem aan te passen, en om dit te doen, te beantwoorden belangrijkste vraag – voor wie maken we het?
Ten eerste - voor zakelijke klanten. Dit betekent dat we een systeem nodig hebben dat snel werkt, met bedrijfsbeperkingen die de implementatie alleen maar vereenvoudigen.
Tweede vraag – wat bedoel je met het woord “onmiddellijk”? Als resultaat van een kort debat hebben we besloten dat we konden beginnen met een responstijd van 5 à 10 minuten, zodat kortetermijnpieken het systeem niet in resonantie zouden brengen.
Derde vraag – welke grootte van het evenwichtige aantal servers moet u kiezen?
Dit probleem heeft zichzelf opgelost. Doorgaans maken clients de serveraggregaties niet erg groot, en dit komt overeen met de aanbevelingen in het artikel om aggregaties te beperken tot 30-40 servers.
Door de serverpool te segmenteren, vereenvoudigen we bovendien de taak van het balanceringsalgoritme.
vierde vraag – hoe geschikt is een neuraal netwerk voor ons met zijn lange leerproces en zeldzame balancering? We hebben besloten om het op te geven ten gunste van eenvoudigere operationele algoritmen om binnen enkele seconden resultaten te krijgen.
U kunt een beschrijving vinden van een systeem dat dergelijke algoritmen gebruikt en de nadelen ervan
We hebben dit systeem geïmplementeerd en gelanceerd en hebben bemoedigende resultaten ontvangen - nu analyseert het regelmatig de cloudbelasting en doet het aanbevelingen voor het verplaatsen van virtuele machines, die grotendeels correct zijn. Zelfs nu is het duidelijk dat we 10-15% van de middelen voor nieuwe virtuele machines kunnen vrijgeven, terwijl we de kwaliteit van het werk van bestaande machines kunnen verbeteren.
Wanneer er een disbalans in RAM of CPU wordt gedetecteerd, geeft het systeem opdrachten aan de Tionix-planner om live migratie van de vereiste virtuele machines uit te voeren. Zoals uit het monitoringsysteem blijkt, verplaatste de virtuele machine zich van de ene (bovenste) naar een andere (lagere) host en maakte geheugen vrij op de bovenste host (gemarkeerd in gele cirkels), respectievelijk bezet het deze op de onderste (gemarkeerd in wit cirkels).
Nu proberen we de effectiviteit van het huidige algoritme nauwkeuriger te beoordelen en proberen we mogelijke fouten daarin te vinden.
Stage 3
Het lijkt erop dat je hierover kunt kalmeren, wachten op bewezen effectiviteit en het onderwerp kunt sluiten.
Maar we worden gedwongen een nieuwe fase in te gaan door de volgende voor de hand liggende optimalisatiemogelijkheden
- Statistieken, bijvoorbeeld и laat zien dat systemen met twee en vier processors aanzienlijk minder presteren dan systemen met één processor. Dit betekent dat alle gebruikers aanzienlijk minder output ontvangen van CPU, RAM, SSD, LAN, FC gekocht in systemen met meerdere processors vergeleken met systemen met één processor.
- De resourceplanners zelf kunnen ernstige fouten bevatten, over dit thema.
- Technologieën aangeboden door Intel en AMD voor het monitoren van RAM en cache maken het mogelijk om het gedrag van virtuele machines te bestuderen en deze zo te plaatsen dat ‘luidruchtige’ buren de ‘stille’ virtuele machines niet hinderen.
- Uitbreiding van de set parameters (netwerk, opslagsysteem, prioriteit van de virtuele machine, migratiekosten, gereedheid voor migratie).
In totaal
Het resultaat van ons werk om de balanceringsalgoritmen te verbeteren was de duidelijke conclusie dat het met behulp van moderne algoritmen mogelijk is om een aanzienlijke optimalisatie van de datacenterbronnen (25-30%) te bereiken en tegelijkertijd de kwaliteit van de klantenservice te verbeteren.
Een algoritme gebaseerd op neurale netwerken is zeker een interessante oplossing, maar wel een die verdere ontwikkeling behoeft, en vanwege de bestaande beperkingen niet geschikt is om dit soort problemen op te lossen op de volumes die typisch zijn voor private clouds. Tegelijkertijd liet het algoritme goede resultaten zien in publieke clouds van aanzienlijke omvang.
In de volgende artikelen vertellen we u meer over de mogelijkheden van processors, planners en balancering op hoog niveau.
Bron: www.habr.com