I stora molnsystem är frågan om automatisk balansering eller utjämning av belastningen på datorresurser särskilt akut. Tionix (en utvecklare och operatör av molntjänster, en del av företagsgruppen Rostelecom) har också tagit hand om denna fråga.
Och eftersom vår huvudsakliga utvecklingsplattform är Openstack, och vi, precis som alla andra, är lata, beslutade vi att välja någon färdig modul som redan ingår i plattformen. Vårt val föll på Watcher, som vi bestämde oss för att använda för våra behov.
Låt oss först titta på termerna och definitionerna.
Termer och definitioner
Mål är ett mänskligt läsbart, observerbart och mätbart slutresultat som måste uppnås. Det finns en eller flera strategier för att uppnå varje mål. En strategi är implementeringen av en algoritm som är kapabel att hitta en lösning för ett givet mål.
Handling är en elementär uppgift som ändrar det aktuella tillståndet för den målhanterade resursen för OpenStack-klustret, till exempel: migrera en virtuell maskin (migrering), ändra effekttillståndet för en nod (change_node_power_state), ändra tillståndet för nova-tjänsten (change_nova_service_state ), ändra smak (ändra storlek), registrera NOP-meddelanden (nop), brist på åtgärd under en viss tid - paus (sömn), disköverföring (volym_migrate).
Handlingsplan - ett specifikt flöde av åtgärder som utförs i en viss ordning för att uppnå ett specifikt mål. Handlingsplanen innehåller också uppmätta globala prestationer med en uppsättning resultatindikatorer. En handlingsplan genereras av Watcher vid en framgångsrik revision, som ett resultat av vilken strategin som används hittar en lösning för att uppnå målet. En handlingsplan består av en lista med sekventiella åtgärder.
Granska är en begäran om att optimera klustret. Optimering utförs för att uppnå ett mål i ett givet kluster. För varje framgångsrik revision genererar Watcher en handlingsplan.
Revisionens omfattning är en uppsättning resurser inom vilka granskningen utförs (tillgänglighetszon(er), nodaggregatorer, individuella beräkningsnoder eller lagringsnoder, etc.). Revisionens omfattning definieras i varje mall. Om ett revisionsomfång inte anges, granskas hela klustret.
Revisionsmall — en sparad uppsättning inställningar för att starta en granskning. Mallar behövs för att köra granskningar flera gånger med samma inställningar. Mallen måste nödvändigtvis innehålla syftet med revisionen, om strategier inte specificeras, väljs de mest lämpliga befintliga strategierna.
Klunga är en samling fysiska maskiner som tillhandahåller beräknings-, lagrings- och nätverksresurser och som hanteras av samma OpenStack-hanteringsnod.
Cluster Data Model (CDM) är en logisk representation av det aktuella tillståndet och topologin för de resurser som hanteras av klustret.
Effektivitetsindikator - en indikator som indikerar hur lösningen som skapats med denna strategi utförs. Prestationsindikatorer är specifika för ett visst mål och används vanligtvis för att beräkna den globala effektiviteten av den resulterande handlingsplanen.
Effektspecifikation är en uppsättning specifika funktioner associerade med varje mål som definierar de olika resultatindikatorer som en strategi för att uppnå motsvarande mål måste uppnå i sin lösning. Faktum är att varje lösning som föreslås av strategin kommer att kontrolleras mot specifikationen innan dess globala effektivitet beräknas.
Poängmotor är en körbar fil som har väldefinierade ingångar, väldefinierade utgångar och utför en rent matematisk uppgift. På så sätt är beräkningen oberoende av miljön där den utförs – den kommer att ge samma resultat var som helst.
Watcher Planner - en del av Watchers beslutsfattande motor. Denna modul tar en uppsättning åtgärder som genereras av en strategi och skapar en arbetsflödesplan som anger hur dessa olika åtgärder ska schemaläggas i tid och för varje åtgärd, vilka förutsättningarna är.
Watcher mål och strategier
Mål
strategi
Dummy mål
Dummy strategi
Dummy-strategi med exempel på poängmotorer
Dummy-strategi med storleksändring
Spara energi
Energisparstrategi
Serverkonsolidering
Grundläggande offlineserverkonsolidering
VM Workload Consolidation Strategi
Arbetsbelastningsbalansering
Arbetsbelastningsbalans migrationsstrategi
Lagringskapacitet Balansstrategi
Arbetsbelastningsstabilisering
Bullrig granne
Bullrig granne
Termisk optimering
Utloppstemperaturbaserad strategi
Luftflödesoptimering
Enhetlig luftflödesmigreringsstrategi
Hårdvara underhåll
Zonmigrering
oklassificerade
Ställdon
Dummy mål — reserverat mål som används för teständamål.
Relaterade strategier: Dummy-strategi, Dummy-strategi med exempel på poängmotorer och dummy-strategi med storleksändring. Dummy-strategi är en dummy-strategi som används för integrationstestning genom Tempest. Denna strategi ger ingen användbar optimering, dess enda syfte är att använda Tempest-tester.
Dummy-strategi med exempel på poängmotorer - strategin liknar den föregående, den enda skillnaden är användningen av ett exempel på "poängmotor" som utför beräkningar med hjälp av maskininlärningsmetoder.
Dummystrategi med storleksändring - strategin liknar den föregående, den enda skillnaden är användningen av att ändra smaken (migrering och storleksändring).
Används inte i produktionen.
Spara energi — minimera energiförbrukningen. Detta måls Saving Energy Strategy, tillsammans med VM Workload Consolidation Strategy (Server Consolidation), är kapabel till dynamiska energihanteringsfunktioner (DPM) som sparar energi genom att dynamiskt konsolidera arbetsbelastningar även under perioder med lågt resursutnyttjande: virtuella maskiner flyttas till färre noder , och onödiga noder är inaktiverade. Efter konsolidering erbjuder strategin ett beslut om att slå på/av noder i enlighet med de angivna parametrarna: "min_free_hosts_num" - antalet lediga aktiverade noder som väntar på laddning, och "free_used_percent" - procentandelen lediga aktiverade värdar till antal noder som är upptagna av maskiner. För att strategin ska fungera måste det finnas aktiverat och konfigurerat Ironic för att hantera power cycling på noder.
Strategiparametrar
parameter
тип
по умолчанию
описание
gratis_använd_procent
Antal
10.0
förhållandet mellan antalet lediga beräkningsnoder och antalet beräkningsnoder med virtuella maskiner
min_free_hosts_num
Int
1
minsta antal lediga beräkningsnoder
Molnet måste ha minst två noder. Metoden som används är att ändra effekttillståndet för noden (change_node_power_state). Strategin kräver inte insamling av mätvärden.
Serverkonsolidering - minimera antalet datornoder (konsolidering). Den har två strategier: Basic Offline Server Consolidation och VM Workload Consolidation Strategy.
Strategin Basic Offline Server Consolidation minimerar det totala antalet servrar som används och minimerar också antalet migreringar.
Den grundläggande strategin kräver följande mätvärden:
metrik
service
plugins
kommentar
compute.node.cpu.percent
ingen
cpu_util
ingen
Strategiparametrar: migration_attempts - antal kombinationer för att söka efter potentiella kandidater för avstängning (standard, 0, inga begränsningar), period - tidsintervall i sekunder för att erhålla statisk aggregering från den metriska datakällan (standard, 700).
Använda metoder: migrering, ändring av nova-tjänstens tillstånd (change_nova_service_state).
VM Workload Consolidation Strategy är baserad på en first-fit heuristik som fokuserar på uppmätt CPU-belastning och försök att minimera noder som har för mycket eller för lite belastning givet resurskapacitetsbegränsningar. Den här strategin ger en lösning som resulterar i en effektivare användning av klusterresurser genom att använda följande fyra steg:
- Avlastningsfas - bearbetning av överutnyttjade resurser;
- Konsolideringsfas - hantering av underutnyttjade resurser;
- Optimering av lösningen - minskning av antalet migrationer;
- Inaktiverar oanvända beräkningsnoder.
Strategin kräver följande mätvärden:
metrik
service
plugins
kommentar
minne
ingen
disk.rotstorlek
ingen
Följande mätvärden är valfria men kommer att förbättra strateginoggrannheten om de är tillgängliga:
metrik
service
plugins
kommentar
minne.bosatt
ingen
cpu_util
ingen
Strategiparametrar: period — tidsintervall i sekunder för att erhålla statisk aggregering från den metriska datakällan (standard, 3600).
Använder samma metoder som den tidigare strategin. Fler detaljer .
Arbetsbelastningsbalansering — balansera arbetsbelastningen mellan beräkningsnoder. Målet har tre strategier: Workload Balance Migration Strategy, Workload Stabilization, Storage Capacity Balance Strategy.
Workload Balance Migration Strategy kör virtuella maskinmigreringar baserat på den virtuella värdmaskinens arbetsbelastning. Ett migreringsbeslut fattas närhelst en nods procentuella CPU- eller RAM-användning överskrider den specificerade tröskeln. I det här fallet bör den flyttade virtuella maskinen föra noden närmare den genomsnittliga arbetsbelastningen för alla noder.
Krav
- Användning av fysiska processorer;
- Minst två fysiska beräkningsnoder;
- Installerade och konfigurerade Ceilometer-komponenten - ceilometer-agent-compute, som körs på varje beräkningsnod, och Ceilometer API, samt samlade in följande mätvärden:
metrik
service
plugins
kommentar
cpu_util
ingen
minne.bosatt
ingen
Strategiparametrar:
parameter
тип
по умолчанию
описание
metrik
Sträng
'cpu_util'
De underliggande måtten är: 'cpu_util', 'memory.resident'.
tröskelvärde
Antal
25.0
Arbetsbelastningströskel för migrering.
perioden
Antal
300
Kumulativ tidsperiod Ceilometer.
Metoden som används är migration.
Arbetsbelastningsstabilisering är en strategi som syftar till att stabilisera arbetsbelastningen med hjälp av direktmigrering. Strategin är baserad på en standardavvikelsealgoritm och avgör om det finns trängsel i klustret och svarar på det genom att utlösa maskinmigrering för att stabilisera klustret.
Krav
- Användning av fysiska processorer;
- Minst två fysiska beräkningsnoder;
- Installerade och konfigurerade Ceilometer-komponenten - ceilometer-agent-compute, som körs på varje beräkningsnod, och Ceilometer API, samt samlade in följande mätvärden:
metrik
service
plugins
kommentar
cpu_util
ingen
minne.bosatt
ingen
Lagringskapacitetsbalansstrategi (strategi implementerad från och med Queens) - strategin överför diskar beroende på belastningen på Cinder-poolerna. Ett överföringsbeslut fattas närhelst poolutnyttjandegraden överstiger en specificerad tröskel. Disken som flyttas bör föra poolen närmare den genomsnittliga belastningen för alla Cinder-pooler.
Krav och restriktioner
- Minst två Cinder-pooler;
- Möjlighet till diskmigrering.
- Klusterdatamodell - Cinder-klusterdatamodellsamlare.
Strategiparametrar:
parameter
тип
по умолчанию
описание
volymtröskel
Antal
80.0
Tröskelvärde för diskar för att balansera volymer.
Metoden som används är diskmigrering (volume_migrate).
Noisy Neighbor - Identifiera och migrera en "noisy neighbor" - en virtuell maskin med låg prioritet som negativt påverkar prestandan hos en högprioriterad virtuell maskin när det gäller IPC genom att överanvända Last Level Cache. Egen strategi: Noisy Neighbor (strategiparameter som används är cache_threshold (standardvärde är 35), när prestandan sjunker till det angivna värdet startas migreringen. För att strategin ska fungera aktiveras LLC (Last Level Cache) mätvärden, senaste Intel-server med CMT-stöd, samt samla in följande mätvärden:
metrik
service
plugins
kommentar
cpu_l3_cache
ingen
Intel krävs .
Klusterdatamodell (standard): Nova klusterdatamodellsamlare. Metoden som används är migration.
Att arbeta med detta mål genom Dashboard är inte fullt implementerat i Queens.
Termisk optimering — optimera temperaturregimen. Utloppstemperatur (frånluft) är ett av de viktiga termiska telemetrisystemen för att mäta en servers termiska/arbetsbelastningsstatus. Målet har en strategi, den utloppstemperaturbaserade strategin, som beslutar att migrera arbetsbelastningar till termiskt gynnsamma värdar (lägsta utloppstemperatur) när utloppstemperaturen för källvärdarna når en konfigurerbar tröskel.
För att strategin ska fungera behöver du en server med Intel Power Node Manager installerad och konfigurerad , samt samla in följande mätvärden:
metrik
service
plugins
kommentar
hardware.ipmi.node.outlet_temperature
IPMI
Strategiparametrar:
parameter
тип
по умолчанию
описание
tröskelvärde
Antal
35.0
Temperaturtröskel för migration.
perioden
Antal
30
Tidsintervallet, i sekunder, för att erhålla den statistiska aggregeringen från den metriska datakällan.
Metoden som används är migration.
Luftflödesoptimering — optimera ventilationsläget. Egen strategi - Enhetligt luftflöde med hjälp av direktmigrering. Strategin utlöser virtuell maskinmigrering när luftflödet från serverfläkten överstiger en angiven tröskel.
För att strategin ska fungera behöver du:
- Hårdvara: beräkningsnoder < som stöder NodeManager 3.0;
- Minst två beräkningsnoder;
- Ceilometer-agent-compute och Ceilometer API-komponenten installerad och konfigurerad på varje datornod, som framgångsrikt kan rapportera mätvärden som luftflöde, systemeffekt, inloppstemperatur:
metrik
service
plugins
kommentar
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperatur
IPMI
hardware.ipmi.node.power
IPMI
För att strategin ska fungera behöver du en server med Intel Power Node Manager 3.0 eller senare installerad och konfigurerad.
Begränsningar: Konceptet är inte avsett för produktion.
Det föreslås att denna algoritm används med kontinuerliga granskningar, eftersom endast en virtuell maskin är planerad att migreras per iteration.
Livemigreringar är möjliga.
Strategiparametrar:
parameter
тип
по умолчанию
описание
tröskel_luftflöde
Antal
400.0
Luftflödeströskel för migreringsenhet är 0.1 CFM
threshold_inlet_t
Antal
28.0
Inloppstemperaturtröskel för migrationsbeslut
tröskel_kraft
Antal
350.0
Systemeffekttröskel för migreringsbeslut
perioden
Antal
30
Tidsintervallet, i sekunder, för att erhålla den statistiska aggregeringen från den metriska datakällan.
Metoden som används är migration.
Hårdvara Underhåll — hårdvaruunderhåll. Strategin relaterad till detta mål är zonmigrering. Strategin är ett verktyg för effektiv automatisk och minimal migrering av virtuella maskiner och diskar vid behov av hårdvaruunderhåll. Strategi bygger en handlingsplan i enlighet med vikter: en uppsättning åtgärder som har större vikt kommer att planeras före andra. Det finns två konfigurationsalternativ: action_weights och parallellisering.
Begränsningar: åtgärdsvikter och parallellisering måste konfigureras.
Strategiparametrar:
parameter
тип
по умолчанию
описание
beräkna_noder
array
Ingen
Beräkna noder för migrering.
lagringspooler
array
Ingen
Lagringsnoder för migrering.
parallell_total
heltal
6
Det totala antalet aktiviteter som måste utföras parallellt.
parallell_per_nod
heltal
2
Antalet åtgärder som utförs parallellt för varje beräkningsnod.
parallell_per_pool
heltal
2
Antalet åtgärder som utförs parallellt för varje lagringspool.
prioritet
objektet
Ingen
Prioritetslista för virtuella maskiner och diskar.
with_attached_volym
boolean
Falsk
False – virtuella datorer kommer att migreras efter att alla diskar har migrerats. Sant – virtuella datorer kommer att migreras efter att alla anslutna diskar har migrerats.
Element i arrayen av beräkningsnoder:
parameter
тип
по умолчанию
описание
src_node
sträng
Ingen
Beräkningsnoden från vilken de virtuella maskinerna migreras (krävs).
dst_node
sträng
Ingen
Beräkna noden som de virtuella maskinerna migrerar till.
Lagringsnodsarrayelement:
parameter
тип
по умолчанию
описание
src_pool
sträng
Ingen
Lagringspoolen från vilken diskarna migreras (krävs).
dst_pool
sträng
Ingen
Lagringspoolen till vilken diskar migreras.
src_type
sträng
Ingen
Original disktyp (krävs).
dst_type
sträng
Ingen
Den resulterande disktypen (krävs).
Objektprioritetselement:
parameter
тип
по умолчанию
описание
projektet
array
Ingen
Projektnamn.
compute_node
array
Ingen
Beräkna nodnamn.
storage_pool
array
Ingen
Lagringspoolnamn.
beräkna
uppräkning
Ingen
Virtuella maskinparametrar ["vcpu_num", "mem_size", "disk_size", "created_at"].
förvaring
uppräkning
Ingen
Diskparametrar ["storlek", "created_at"].
Metoderna som används är virtuell maskinmigrering, diskmigrering.
oklassificerade - ett hjälpmål som används för att underlätta strategiutvecklingsprocessen. Innehåller inga specifikationer och kan användas när strategin ännu inte är kopplad till ett befintligt mål. Detta mål kan också användas som en övergångspunkt. En relaterad strategi till detta mål är Actuator.
Skapa ett nytt mål
Watcher Decision Engine har ett "externt mål" plugin-gränssnitt som gör det möjligt att integrera ett externt mål som kan uppnås med hjälp av en strategi.
Innan du skapar ett nytt mål bör du se till att inga befintliga mål uppfyller dina behov.
Skapar ett nytt plugin
För att skapa ett nytt mål måste du: utöka målklassen, implementera en klassmetod hämta namn() för att returnera det unika ID:t för det nya målet du vill skapa. Denna unika identifierare måste matcha ingångspunktens namn som du deklarerar senare.
Därefter måste du implementera klassmetoden get_display_name() för att returnera det översatta visningsnamnet för målet du vill skapa (använd inte en variabel för att returnera den översatta strängen så att den automatiskt kan samlas in av översättningsverktyget.).
Implementera en klassmetod get_translatable_display_name()för att returnera översättningsnyckeln (faktiskt det engelska visningsnamnet) för ditt nya mål. Returvärdet måste matcha strängen som översatts till get_display_name().
Implementera hans metod get_efficacy_specification()för att returnera effektivitetsspecifikationen för ditt mål. Metoden get_efficacy_specification() returnerar Unclassified()-instansen som tillhandahålls av Watcher. Den här prestationsspecifikationen är användbar i processen att utveckla ditt mål eftersom den motsvarar den tomma specifikationen.
→
Watcher-arkitektur (mer information) ).
Komponenter
Watcher API - en komponent som implementerar REST API från Watcher. Interaktionsmekanismer: CLI, Horizon plugin, Python SDK.
Watcher DB — Watcher-databas.
Watcher Applier — En komponent som implementerar genomförandet av en handlingsplan som skapats av Watcher Decision Engine-komponenten.
Watcher Decision Engine - Den komponent som ansvarar för att beräkna en uppsättning potentiella optimeringsåtgärder för att uppnå revisionsmålet. Om en strategi inte specificeras väljer komponenten självständigt den mest lämpliga.
Watcher Metrics Publisher - En komponent som samlar in och beräknar vissa mätvärden eller händelser och publicerar dem till CEP-slutpunkten. Funktionaliteten hos komponenten kan också tillhandahållas av Ceilometer-utgivaren.
Complex Event Processing (CEP) Engine — motor för komplex händelsebearbetning. Av prestandaskäl kan det finnas flera CEP Engine-instanser som körs samtidigt, var och en bearbetar en specifik typ av mätvärde/händelse. I Watcher-systemet utlöser CEP två typer av åtgärder: - registrera motsvarande händelser/mått i tidsseriedatabasen; - skicka lämpliga händelser till Watcher Decision Engine när denna händelse kan påverka resultatet av den aktuella optimeringsstrategin, eftersom Openstack-klustret inte är ett statiskt system.
Komponenterna interagerar med AMQP-protokollet.
→
Schema för interaktion med Watcher
Watcher testresultat
- På sidan Optimering - Handlingsplaner 500 (både på rena Queens och på en monter med Tionix-moduler) visas den först efter att revisionen har lanserats och en handlingsplan genererats, den tomma öppnas normalt.
- Det finns fel på fliken Action details, det går inte att få upp revisionsmålet och strategin (både på rena Queens och på en monter med Tionix-moduler).
- Revisioner med syfte att Dummy (test) skapas och startas normalt, handlingsplaner genereras.
- Revisioner för det Oklassificerade målet skapas inte eftersom målet inte är funktionellt och är avsett för mellankonfiguration när nya strategier skapas.
- Revisioner i syfte att balansera arbetsbelastning (Storage Capacity balansstrategi) skapas framgångsrikt, men en handlingsplan genereras inte. Ingen lagringspooloptimering krävs.
- Revisioner för målet Workload Balancing (Workload Balance Migration Strategy) skapas framgångsrikt, men en handlingsplan genereras inte.
- Revisioner för balansering av arbetsbelastning (Workload Stabilization Strategy) misslyckas.
- Revisioner för Noisy Neighbour-målet skapas framgångsrikt, men en handlingsplan genereras inte.
- Revisioner i syfte att underhålla hårdvara skapas framgångsrikt, handlingsplanen genereras inte i sin helhet (prestandaindikatorer genereras, men själva listan över åtgärder genereras inte).
- Redigeringar i nova.conf-konfigurationerna (i standardavsnittet compute_monitors = cpu.virt_driver) på beräknings- och kontrollnoderna korrigerar inte felen.
- Granskningar inriktade på serverkonsolidering (grundläggande strategi) misslyckas också.
- Granskningar för serverkonsolidering (VM-arbetsbelastningskonsolideringsstrategi) misslyckas med ett fel. I loggarna finns det ett fel när källdata hämtas. Diskussion om felet i synnerhet .
Vi försökte ange Watcher i konfigurationsfilen (det hjälpte inte - som ett resultat av ett fel på alla optimeringssidor, korrigerar inte situationen att återgå till det ursprungliga innehållet i konfigurationsfilen): [watcher_strategies.basic] datakälla = ceilometer, gnocchi - Revisioner för att spara energi misslyckas. Att döma av loggarna är problemet fortfarande frånvaron av Ironic, det kommer inte att fungera utan baremetal-service.
- Revisioner för termisk optimering misslyckas. Spårningen är densamma som för Server Consolidation (VM-arbetsbelastningskonsolideringsstrategi) (källdatafel)
- Revisioner för luftflödesoptimering misslyckas med ett fel.
Följande revisionsslutförandefel påträffas också. Traceback i decision-engine.log-loggar (klustertillstånd är inte definierat).
→ Diskussion om felet
Slutsats
Resultatet av vår två månader långa forskning var den otvetydiga slutsatsen att för att få ett fullfjädrat, fungerande lastbalanseringssystem måste vi i denna del arbeta nära med att förfina verktygen för Openstack-plattformen.
Watcher har visat sig vara en seriös och snabbt utvecklande produkt med enorm potential, vars fulla användning kommer att kräva mycket seriöst arbete.
Men mer om detta i nästa artiklar i serien.
Källa: will.com