I store cloud-systemer er spørgsmålet om automatisk balancering eller udjævning af belastningen på computerressourcer særligt akut. Tionix (en udvikler og operatør af cloud-tjenester, en del af Rostelecom-koncernen) har også taget sig af dette problem.
Og da vores vigtigste udviklingsplatform er Openstack, og vi, som alle andre, er dovne, blev det besluttet at vælge et færdigt modul, der allerede er inkluderet i platformen. Vores valg faldt på Watcher, som vi besluttede at bruge til vores behov.
Lad os først se på begreberne og definitionerne.
Begreber og definitioner
mål er et menneskelæsbart, observerbart og målbart slutresultat, som skal opnås. Der er en eller flere strategier til at nå hvert mål. En strategi er implementeringen af en algoritme, der er i stand til at finde en løsning til et givet mål.
Handling er en elementær opgave, der ændrer den aktuelle tilstand for den målstyrede ressource i OpenStack-klyngen, såsom: migrering af en virtuel maskine (migrering), ændring af en nodes strømtilstand (change_node_power_state), ændring af tilstanden for nova-tjenesten (change_nova_service_state) ), ændring af smag (ændre størrelse), registrering af NOP-meddelelser (nop), manglende handling i et vist tidsrum - pause (sleep), diskoverførsel (volume_migrate).
Handlingsplan - et specifikt flow af handlinger udført i en bestemt rækkefølge for at nå et specifikt mål. Handlingsplanen indeholder også målte globale præstationer med et sæt præstationsindikatorer. En handlingsplan genereres af Watcher ved en succesfuld audit, hvorved den anvendte strategi finder en løsning til at nå målet. En handlingsplan består af en liste over sekventielle handlinger.
Revidere er en anmodning om at optimere klyngen. Optimering udføres for at opnå ét mål i en given klynge. For hver vellykket audit genererer Watcher en handlingsplan.
Revisionsomfang er et sæt ressourcer, inden for hvilke revisionen udføres (tilgængelighedszoner, nodeaggregatorer, individuelle beregningsknuder eller lagernoder osv.). Revisionsomfanget er defineret i hver skabelon. Hvis der ikke er angivet et revisionsomfang, revideres hele klyngen.
Revision skabelon — et gemt sæt indstillinger til at starte en revision. Skabeloner er nødvendige for at køre revisioner flere gange med de samme indstillinger. Skabelonen skal nødvendigvis indeholde formålet med revisionen, hvis strategier ikke er specificeret, så vælges de bedst egnede eksisterende strategier.
Klynge er en samling af fysiske maskiner, der leverer computer-, lager- og netværksressourcer og administreres af den samme OpenStack-administrationsknude.
Cluster Data Model (CDM) er en logisk repræsentation af den aktuelle tilstand og topologi for de ressourcer, der administreres af klyngen.
Effektivitetsindikator - en indikator, der angiver, hvordan den løsning, der er oprettet ved hjælp af denne strategi, udføres. Præstationsindikatorer er specifikke for et bestemt mål og bruges typisk til at beregne den samlede effektivitet af den resulterende handlingsplan.
Effektspecifikation er et sæt specifikke funktioner forbundet med hvert mål, der definerer de forskellige præstationsindikatorer, som en strategi for at opnå det tilsvarende mål skal opnå i sin løsning. Faktisk vil hver løsning foreslået af strategien blive kontrolleret i forhold til specifikationen, før dens globale effektivitet beregnes.
Scoring Engine er en eksekverbar fil, der har veldefinerede input, veldefinerede output og udfører en rent matematisk opgave. På denne måde er beregningen uafhængig af det miljø, den udføres i - den vil give det samme resultat overalt.
Watcher Planner - en del af Watchers beslutningsmotor. Dette modul tager et sæt handlinger genereret af en strategi og opretter en arbejdsgangsplan, der definerer, hvordan disse forskellige handlinger skal planlægges i tide og for hver handling, hvad forudsætningerne er.
Watcher mål og strategier
mål
strategi
Dummy mål
Dummy strategi
Dummy-strategi ved hjælp af prøvescoremotorer
Dummy-strategi med ændring af størrelse
Saving Energy
Energibesparelsesstrategi
Serverkonsolidering
Grundlæggende offline serverkonsolidering
VM Workload Consolidation Strategy
Arbejdsbelastningsbalancering
Workload Balance Migration Strategi
Lagerkapacitetsbalancestrategi
Stabilisering af arbejdsbelastning
Støjende nabo
Støjende nabo
Termisk optimering
Udgangstemperatur baseret strategi
Luftstrømsoptimering
Ensartet luftstrømsmigreringsstrategi
Hardware vedligeholdelse
Zone migration
Uklassificeret
Aktuator
Dummy mål — reserveret mål, der bruges til testformål.
Relaterede strategier: Dummy-strategi, Dummy-strategi ved hjælp af prøvescoremotorer og Dummy-strategi med ændring af størrelse. Dummy-strategi er en dummy-strategi, der bruges til integrationstest gennem Tempest. Denne strategi giver ikke nogen brugbar optimering, dens eneste formål er at bruge Tempest-tests.
Dummy-strategi ved hjælp af prøvescoringsmotorer - strategien ligner den forrige, den eneste forskel er brugen af en prøve "scoremotor", der udfører beregninger ved hjælp af maskinlæringsmetoder.
Dummy-strategi med ændring af størrelse - strategien ligner den forrige, den eneste forskel er brugen af at ændre smagen (migrering og ændring af størrelse).
Ikke brugt i produktionen.
Saving Energy — minimere energiforbruget. Dette måls Saving Energy Strategy er sammen med VM Workload Consolidation Strategy (Server Consolidation) i stand til dynamiske strømstyringsfunktioner (DPM), der sparer energi ved dynamisk at konsolidere arbejdsbelastninger, selv i perioder med lav ressourceudnyttelse: virtuelle maskiner flyttes til færre noder , og unødvendige noder er deaktiveret. Efter konsolidering tilbyder strategien en beslutning om at tænde/slukke noder i overensstemmelse med de specificerede parametre: "min_free_hosts_num" - antallet af ledige aktiverede noder, der venter på belastning, og "free_used_percent" - procentdelen af gratis aktiverede værter til antal knudepunkter, der er optaget af maskiner. For at strategien skal virke, skal der være aktiveret og konfigureret Ironic til at håndtere power cycling på noder.
Strategiparametre
parameter
typen
по умолчанию
описание
gratis_brugt_procent
nummer
10.0
forholdet mellem antallet af ledige computernoder og antallet af computernoder med virtuelle maskiner
min_free_hosts_num
Int
1
minimum antal ledige computerknudepunkter
Skyen skal have mindst to noder. Den anvendte metode er at ændre nodens effekttilstand (change_node_power_state). Strategien kræver ikke indsamling af metrics.
Serverkonsolidering - minimer antallet af computernoder (konsolidering). Den har to strategier: Basic Offline Server Consolidation og VM Workload Consolidation Strategy.
Strategien Basic Offline Server Consolidation minimerer det samlede antal brugte servere og minimerer også antallet af migreringer.
Den grundlæggende strategi kræver følgende metrics:
målinger
service
plugins
kommentar
compute.node.cpu.percent
ingen
cpu_util
ingen
Strategiparametre: migration_attempts - antal kombinationer til at søge efter potentielle kandidater til nedlukning (standard, 0, ingen begrænsninger), periode - tidsinterval i sekunder for at opnå statisk aggregering fra den metriske datakilde (standard, 700).
Anvendte metoder: migration, ændring af nova-tjenestetilstanden (change_nova_service_state).
VM Workload Consolidation Strategy er baseret på en first-fit heuristik, der fokuserer på målt CPU-belastning og forsøg på at minimere noder, der har for meget eller for lidt belastning givet ressourcekapacitetsbegrænsninger. Denne strategi giver en løsning, der resulterer i mere effektiv brug af klyngressourcer ved hjælp af følgende fire trin:
- Aflæsningsfase - behandling af overudnyttede ressourcer;
- Konsolideringsfase - håndtering af underudnyttede ressourcer;
- Optimering af løsningen - reduktion af antallet af migrationer;
- Deaktivering af ubrugte beregningsnoder.
Strategien kræver følgende metrics:
målinger
service
plugins
kommentar
hukommelse
ingen
disk.rodstørrelse
ingen
Følgende metrics er valgfrie, men vil forbedre strateginøjagtigheden, hvis de er tilgængelige:
målinger
service
plugins
kommentar
hukommelse.resident
ingen
cpu_util
ingen
Strategiparametre: periode — tidsinterval i sekunder for at opnå statisk aggregering fra den metriske datakilde (standard, 3600).
Bruger samme metoder som den tidligere strategi. Flere detaljer .
Arbejdsbelastningsbalancering — afbalancere arbejdsbyrden mellem computerknudepunkter. Målet har tre strategier: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.
Workload Balance Migration Strategy kører virtuelle maskine-migreringer baseret på den virtuelle værtsmaskines arbejdsbelastning. En migreringsbeslutning træffes, når % CPU- eller RAM-udnyttelsen af en node overstiger den specificerede tærskel. I dette tilfælde skal den flyttede virtuelle maskine bringe noden tættere på den gennemsnitlige arbejdsbyrde for alle noder.
Krav
- Brug af fysiske processorer;
- Mindst to fysiske computerknudepunkter;
- Installerede og konfigurerede Ceilometer-komponenten - ceilometer-agent-compute, der kører på hver compute node, og Ceilometer API'et, samt indsamlede følgende metrics:
målinger
service
plugins
kommentar
cpu_util
ingen
hukommelse.resident
ingen
Strategiparametre:
parameter
typen
по умолчанию
описание
målinger
String
'cpu_util'
De underliggende metrics er: 'cpu_util', 'memory.resident'.
tærskel
nummer
25.0
Arbejdsbelastningstærskel for migrering.
periode
nummer
300
Kumulativ tidsperiode Ceilometer.
Den anvendte metode er migration.
Stabilisering af arbejdsbyrden er en strategi, der har til formål at stabilisere arbejdsbyrden ved hjælp af direkte migration. Strategien er baseret på en standardafvigelsesalgoritme og bestemmer om der er overbelastning i klyngen og reagerer på det ved at udløse maskinmigrering for at stabilisere klyngen.
Krav
- Brug af fysiske processorer;
- Mindst to fysiske computerknudepunkter;
- Installerede og konfigurerede Ceilometer-komponenten - ceilometer-agent-compute, der kører på hver compute node, og Ceilometer API'et, samt indsamlede følgende metrics:
målinger
service
plugins
kommentar
cpu_util
ingen
hukommelse.resident
ingen
Storage Capacity Balance Strategy (strategi implementeret startende med Queens) - strategien overfører diske afhængigt af belastningen på Cinder-puljerne. En overførselsbeslutning træffes, når pooludnyttelsesgraden overstiger en specificeret tærskel. Disken, der flyttes, bør bringe poolen tættere på den gennemsnitlige belastning af alle Cinder-puljer.
Krav og restriktioner
- Minimum to Cinder pools;
- Mulighed for diskmigrering.
- Klyngedatamodel - Cinder-klyngedatamodelopsamler.
Strategiparametre:
parameter
typen
по умолчанию
описание
volume_threshold
nummer
80.0
Tærskelværdi for diske til balancering af volumener.
Den anvendte metode er diskmigrering (volume_migrate).
Støjende nabo - Identificer og migrér en "støjende nabo" - en virtuel maskine med lav prioritet, der negativt påvirker ydeevnen af en virtuel maskine med høj prioritet med hensyn til IPC ved at overbruge Last Level Cache. Egen strategi: Noisy Neighbor (den anvendte strategiparameter er cache_threshold (standardværdien er 35), når ydeevnen falder til den angivne værdi, startes migreringen. For at strategien skal fungere, aktiveres LLC (Last Level Cache) metrics, nyeste Intel-server med CMT-understøttelse, samt indsamling af følgende metrics:
målinger
service
plugins
kommentar
cpu_l3_cache
ingen
Intel påkrævet .
Klyngedatamodel (standard): Nova-klyngedatamodelopsamler. Den anvendte metode er migration.
At arbejde med dette mål gennem Dashboard er ikke fuldt implementeret i Queens.
Termisk optimering — optimere temperaturregimet. Udgangstemperatur (udsugningsluft) er et af de vigtige termiske telemetrisystemer til at måle den termiske/arbejdsbelastningsstatus for en server. Målet har én strategi, den udgangstemperaturbaserede strategi, som beslutter at migrere arbejdsbelastninger til termisk gunstige værter (laveste udgangstemperatur), når udgangstemperaturen for kildeværterne når en konfigurerbar tærskel.
For at strategien skal fungere, skal du have en server med Intel Power Node Manager installeret og konfigureret , samt indsamling af følgende metrics:
målinger
service
plugins
kommentar
hardware.ipmi.node.outlet_temperature
IPMI
Strategiparametre:
parameter
typen
по умолчанию
описание
tærskel
nummer
35.0
Temperaturgrænse for migration.
periode
nummer
30
Tidsintervallet, i sekunder, for at opnå den statistiske aggregering fra den metriske datakilde.
Den anvendte metode er migration.
Luftstrømsoptimering — optimer ventilationstilstanden. Egen strategi - Ensartet luftstrøm ved hjælp af live migration. Strategien udløser virtuel maskinmigrering, når luftstrømmen fra serverblæseren overstiger en specificeret tærskel.
For at strategien skal fungere, har du brug for:
- Hardware: beregningsnoder < understøtter NodeManager 3.0;
- Mindst to computerknudepunkter;
- Ceilometer-agent-compute og Ceilometer API-komponenten installeret og konfigureret på hver computerknude, som med succes kan rapportere metrikker såsom luftstrøm, systemeffekt, indløbstemperatur:
målinger
service
plugins
kommentar
hardware.ipmi.node.luftstrøm
IPMI
hardware.ipmi.node.temperatur
IPMI
hardware.ipmi.node.power
IPMI
For at strategien skal fungere, skal du have en server med Intel Power Node Manager 3.0 eller nyere installeret og konfigureret.
Begrænsninger: Konceptet er ikke beregnet til produktion.
Det foreslås at bruge denne algoritme med kontinuerlige revisioner, da kun én virtuel maskine er planlagt til at blive migreret pr. iteration.
Live migrationer er mulige.
Strategiparametre:
parameter
typen
по умолчанию
описание
threshold_airflow
nummer
400.0
Luftstrømstærskel for migration Enhed er 0.1 CFM
threshold_inlet_t
nummer
28.0
Indløbstemperaturtærskel for migrationsbeslutning
threshold_power
nummer
350.0
Systemeffekttærskel for migreringsbeslutning
periode
nummer
30
Tidsintervallet, i sekunder, for at opnå den statistiske aggregering fra den metriske datakilde.
Den anvendte metode er migration.
Hardware Vedligeholdelse — hardwarevedligeholdelse. Strategien relateret til dette mål er Zone migration. Strategien er et værktøj til effektiv automatisk og minimal migrering af virtuelle maskiner og diske i tilfælde af behov for hardwarevedligeholdelse. Strategi bygger en handlingsplan i overensstemmelse med vægte: et sæt handlinger, der har større vægt, vil blive planlagt før andre. Der er to konfigurationsmuligheder: action_weights og parallelisering.
Begrænsninger: handlingsvægte og parallelisering skal konfigureres.
Strategiparametre:
parameter
typen
по умолчанию
описание
compute_nodes
matrix
Ingen
Beregn noder til migrering.
storage_pools
matrix
Ingen
Lagerknudepunkter til migrering.
parallel_total
heltal
6
Det samlede antal aktiviteter, der skal udføres parallelt.
parallel_per_node
heltal
2
Antallet af handlinger udført parallelt for hver beregningsknude.
parallel_per_pool
heltal
2
Antallet af handlinger, der udføres parallelt for hver lagerpulje.
prioritet
objekt
Ingen
Prioritetsliste for virtuelle maskiner og diske.
with_attached_volume
boolean
False
Falsk – virtuelle maskiner vil blive migreret efter alle diske er blevet migreret. Sandt – virtuelle maskiner vil blive migreret, efter at alle tilsluttede diske er blevet migreret.
Elementer i rækken af computerknudepunkter:
parameter
typen
по умолчанию
описание
src_node
streng
Ingen
Den beregningsknude, hvorfra de virtuelle maskiner migreres (påkrævet).
dst_node
streng
Ingen
Beregn den node, som de virtuelle maskiner migrerer til.
Lagerknude array-elementer:
parameter
typen
по умолчанию
описание
src_pool
streng
Ingen
Lagerpuljen, hvorfra diskene migreres (påkrævet).
dst_pool
streng
Ingen
Lagerpuljen, som diske migreres til.
src_type
streng
Ingen
Original disktype (påkrævet).
dst_type
streng
Ingen
Den resulterende disktype (påkrævet).
Objektprioritetselementer:
parameter
typen
по умолчанию
описание
projekt
matrix
Ingen
Projektnavne.
compute_node
matrix
Ingen
Beregn nodenavne.
storage_pool
matrix
Ingen
Navne på lagerpool.
beregne
enum
Ingen
Virtuel maskine-parametre ["vcpu_num", "mem_size", "disk_size", "created_at"].
opbevaring
enum
Ingen
Diskparametre ["størrelse", "created_at"].
De anvendte metoder er virtuel maskinmigrering, diskmigrering.
Uklassificeret - et hjælpemål, der bruges til at lette strategiudviklingsprocessen. Indeholder ingen specifikationer og kan bruges, når strategien endnu ikke er knyttet til et eksisterende mål. Dette mål kan også bruges som et overgangspunkt. En relateret strategi til dette mål er Actuator.
At skabe et nyt mål
Watcher Decision Engine har en "eksternt mål" plugin interface, der gør det muligt at integrere et eksternt mål, der kan opnås ved hjælp af en strategi.
Før du opretter et nyt mål, bør du sikre dig, at ingen eksisterende mål opfylder dine behov.
Oprettelse af et nyt plugin
For at oprette et nyt mål skal du: udvide målklassen, implementere en klassemetode get_name() for at returnere det unikke ID for det nye mål, du vil oprette. Denne unikke identifikator skal matche det indgangspunktsnavn, du angiver senere.
Dernæst skal du implementere klassemetoden get_display_name() for at returnere det oversatte visningsnavn på det mål, du vil oprette (brug ikke en variabel til at returnere den oversatte streng, så den automatisk kan indsamles af oversættelsesværktøjet.).
Implementer en klassemetode get_translatable_display_name()for at returnere oversættelsesnøglen (faktisk det engelske visningsnavn) for dit nye mål. Returværdien skal matche strengen, der er oversat til get_display_name().
Implementer hans metode get_efficacy_specification()for at returnere effektivitetsspecifikationen for dit mål. Metoden get_efficacy_specification() returnerer Unclassified()-forekomsten leveret af Watcher. Denne præstationsspecifikation er nyttig i processen med at udvikle dit mål, fordi den svarer til den tomme specifikation.
→
Watcher-arkitektur (flere detaljer) ).
Komponenter
Watcher API - en komponent, der implementerer REST API'en leveret af Watcher. Interaktionsmekanismer: CLI, Horizon plugin, Python SDK.
Watcher DB — Watcher-database.
Watcher Applier — en komponent, der implementerer udførelsen af en handlingsplan oprettet af Watcher Decision Engine-komponenten.
Watcher Decision Engine - Den komponent, der er ansvarlig for at beregne et sæt potentielle optimeringshandlinger for at nå revisionsmålet. Hvis en strategi ikke er specificeret, vælger komponenten uafhængigt den mest passende.
Watcher Metrics Publisher - En komponent, der indsamler og beregner nogle metrics eller hændelser og udgiver dem til CEP-slutpunktet. Funktionaliteten af komponenten kan også leveres af Ceilometer-udgiveren.
Complex Event Processing (CEP) Engine — motor til kompleks hændelsesbehandling. Af ydeevnemæssige årsager kan der være flere CEP Engine-forekomster, der kører samtidigt, og hver behandler en bestemt type metric/hændelse. I Watcher-systemet udløser CEP to typer handlinger: - optag de tilsvarende hændelser/metrikker i tidsseriedatabasen; - send passende hændelser til Watcher Decision Engine, når denne hændelse kan påvirke resultatet af den aktuelle optimeringsstrategi, da Openstack-klyngen ikke er et statisk system.
Komponenterne interagerer ved hjælp af AMQP-protokollen.
→
Interaktionsskema med Watcher
Watcher test resultater
- På siden Optimering - Handlingsplaner 500 (både på rene Queens og på en stand med Tionix-moduler) vises den først, efter at revisionen er lanceret og en handlingsplan er genereret; den tomme åbner normalt.
- Der er fejl på fanen Handlingsdetaljer, det er ikke muligt at få revisionsmål og strategi (både på rene Queens og på en stand med Tionix-moduler).
- Audits med det formål at Dummy (test) oprettes og lanceres normalt, handlingsplaner genereres.
- Revisioner for det uklassificerede mål oprettes ikke, fordi målet ikke er funktionelt og er beregnet til mellemkonfiguration ved oprettelse af nye strategier.
- Audits med henblik på Workload Balancing (Storage Capacity balance-strategi) oprettes med succes, men en handlingsplan genereres ikke. Der kræves ingen lagerpooloptimering.
- Audits for Workload Balancing-målet (Workload Balance Migration Strategy) oprettes med succes, men der genereres ikke en handlingsplan.
- Audits for Workload Balancing (Workload Stabilization Strategy) mislykkes.
- Audits for Noisy Neighbour-målet oprettes med succes, men der genereres ikke en handlingsplan.
- Audits med henblik på hardwarevedligeholdelse oprettes med succes, handlingsplanen genereres ikke fuldt ud (ydelsesindikatorer genereres, men selve listen over handlinger genereres ikke).
- Redigeringer i nova.conf-konfigurationerne (i standardafsnittet compute_monitors = cpu.virt_driver) på beregnings- og kontrolnoderne retter ikke fejlene.
- Revisioner rettet mod serverkonsolidering (grundlæggende strategi) mislykkes også.
- Revisioner med henblik på serverkonsolidering (VM-arbejdsbelastningskonsolideringsstrategi) mislykkes med en fejl. I logfilerne er der en fejl ved indhentning af kildedata. Diskussion af fejlen, især .
Vi forsøgte at specificere Watcher i konfigurationsfilen (det hjalp ikke - som et resultat af en fejl på alle optimeringssider, retter tilbagevenden til det oprindelige indhold af konfigurationsfilen ikke situationen): [watcher_strategies.basic] datakilde = ceilometer, gnocchi - Audits for at spare energi mislykkes. At dømme efter logfilerne er problemet stadig fraværet af Ironic; det vil ikke fungere uden baremetal-service.
- Audits for termisk optimering mislykkes. Sporingen er den samme som for Server Consolidation (VM workload konsolidering strategi) (kildedatafejl)
- Audits med henblik på luftstrømsoptimering mislykkes med en fejl.
Følgende revisionsudførelsesfejl er også stødt på. Traceback i decision-engine.log logs (klyngetilstand er ikke defineret).
→ Diskussion af fejlen
Konklusion
Resultatet af vores to-måneders research var den utvetydige konklusion, at for at opnå et fuldgyldigt, fungerende lastbalanceringssystem, skal vi i denne del arbejde tæt sammen om at forfine værktøjerne til Openstack-platformen.
Watcher har vist sig at være et seriøst og hurtigt udviklende produkt med et enormt potentiale, hvis fulde brug vil kræve en masse seriøst arbejde.
Men mere om dette i de næste artikler i serien.
Kilde: www.habr.com