I store skysystemer er spørsmålet om automatisk balansering eller utjevning av belastningen på dataressurser spesielt akutt. Tionix (en utvikler og operatør av skytjenester, en del av Rostelecom-gruppen) har også tatt seg av denne problemstillingen.
Og siden vår hovedutviklingsplattform er Openstack, og vi, som alle andre, er late, ble det besluttet å velge en ferdig modul som allerede er inkludert i plattformen. Vårt valg falt på Watcher, som vi bestemte oss for å bruke for våre behov.
La oss først se på begrepene og definisjonene.
Begreper og definisjoner
target er et menneskelesbart, observerbart og målbart sluttresultat som må oppnås. Det er en eller flere strategier for å nå hvert mål. En strategi er implementering av en algoritme som er i stand til å finne en løsning for et gitt mål.
Handling er en elementær oppgave som endrer den nåværende tilstanden til den målstyrte ressursen til OpenStack-klyngen, for eksempel: migrere en virtuell maskin (migrering), endre strømtilstanden til en node (change_node_power_state), endre tilstanden til nova-tjenesten (change_nova_service_state ), endring av smak (endre størrelse), registrering av NOP-meldinger (nop), manglende handling i en viss tidsperiode - pause (sleep), diskoverføring (volume_migrate).
Handlingsplan - en spesifikk flyt av handlinger utført i en bestemt rekkefølge for å oppnå et spesifikt mål. Handlingsplanen inneholder også målt global ytelse med et sett med resultatindikatorer. En handlingsplan genereres av Watcher ved en vellykket revisjon, som et resultat av at strategien som brukes finner en løsning for å nå målet. En handlingsplan består av en liste over sekvensielle handlinger.
Revidere er en forespørsel om å optimalisere klyngen. Optimalisering utføres for å oppnå ett mål i en gitt klynge. For hver vellykket revisjon genererer Watcher en handlingsplan.
Revisjonsomfang er et sett med ressurser som revisjonen utføres innenfor (tilgjengelighetssone(r), nodeaggregatorer, individuelle beregningsnoder eller lagringsnoder osv.). Revisjonsomfanget er definert i hver mal. Hvis det ikke er spesifisert revisjonsomfang, revideres hele klyngen.
Revisjonsmal — et lagret sett med innstillinger for å starte en revisjon. Maler er nødvendig for å kjøre revisjoner flere ganger med de samme innstillingene. Malen må nødvendigvis inneholde formålet med revisjonen, hvis strategier ikke er spesifisert, velges de best egnede eksisterende strategiene.
Klynge er en samling av fysiske maskiner som gir databehandling, lagring og nettverksressurser og administreres av den samme OpenStack-administrasjonsnoden.
Cluster Data Model (CDM) er en logisk representasjon av den nåværende tilstanden og topologien til ressursene som administreres av klyngen.
Effektivitetsindikator - en indikator som indikerer hvordan løsningen opprettet ved hjelp av denne strategien utføres. Ytelsesindikatorer er spesifikke for et bestemt mål og brukes vanligvis til å beregne den globale effektiviteten til den resulterende handlingsplanen.
Effektspesifikasjon er et sett med spesifikke funksjoner knyttet til hvert mål som definerer de ulike ytelsesindikatorene som en strategi for å oppnå det tilsvarende målet må oppnå i sin løsning. Faktisk vil hver løsning foreslått av strategien bli kontrollert mot spesifikasjonen før dens globale effektivitet beregnes.
Scoringsmotor er en kjørbar fil som har veldefinerte innganger, veldefinerte utganger og utfører en rent matematisk oppgave. På denne måten er beregningen uavhengig av miljøet den utføres i – den vil gi samme resultat hvor som helst.
Watcher Planner - en del av Watchers beslutningsmotor. Denne modulen tar et sett med handlinger generert av en strategi og lager en arbeidsflytplan som spesifiserer hvordan disse ulike handlingene skal planlegges i tide og for hver handling, hva forutsetningene er.
Watcher mål og strategier
target
strategi
Dummy mål
Dummy-strategi
Dummy-strategi ved hjelp av prøvescoremotorer
Dummy-strategi med endring av størrelse
Sparer energi
Spare energistrategi
Serverkonsolidering
Grunnleggende frakoblet serverkonsolidering
VM Workload Consolidation Strategy
Arbeidsbelastningsbalansering
Arbeidsbelastningsbalanse-migreringsstrategi
Lagringskapasitet Balansestrategi
Stabilisering av arbeidsbelastning
Støyende nabo
Støyende nabo
Termisk optimalisering
Utløpstemperaturbasert strategi
Optimalisering av luftstrøm
Ensartet luftstrømmigrasjonsstrategi
Vedlikehold av maskinvare
Sonemigrering
Unclassified
Actuator
Dummy mål — reservert mål som brukes til testformål.
Beslektede strategier: Dummy-strategi, Dummy-strategi ved å bruke prøvescoremotorer og dummy-strategi med endring av størrelse. Dummy-strategi er en dummy-strategi som brukes for integrasjonstesting gjennom Tempest. Denne strategien gir ingen nyttig optimalisering, dens eneste formål er å bruke Tempest-tester.
Dummy-strategi ved bruk av prøvescoremotorer - strategien ligner den forrige, den eneste forskjellen er bruken av en prøve "scoremotor" som utfører beregninger ved hjelp av maskinlæringsmetoder.
Dummy-strategi med endring av størrelse - strategien er lik den forrige, den eneste forskjellen er bruken av å endre smaken (migrering og endre størrelse).
Ikke brukt i produksjon.
Sparer energi – minimere energiforbruket. Dette målets Saving Energy Strategy, sammen med VM Workload Consolidation Strategy (Server Consolidation), er i stand til funksjoner for dynamisk strømstyring (DPM) som sparer energi ved å dynamisk konsolidere arbeidsbelastninger selv i perioder med lav ressursutnyttelse: virtuelle maskiner flyttes til færre noder , og unødvendige noder er deaktivert. Etter konsolidering tilbyr strategien en avgjørelse om å slå av/på noder i samsvar med de spesifiserte parameterne: "min_free_hosts_num" - antall ledige aktiverte noder som venter på last, og "free_used_percent" - prosentandelen av gratis aktiverte verter til antall noder som er okkupert av maskiner. For at strategien skal fungere må det finnes aktivert og konfigurert Ironic for å håndtere strømsykling på noder.
Strategiparametere
parameter
typen
som standard
описание
gratis_brukt_prosent
Nr
10.0
forholdet mellom antall ledige datanoder og antall databehandlingsnoder med virtuelle maskiner
min_free_hosts_num
int
1
minimum antall ledige datanoder
Skyen må ha minst to noder. Metoden som brukes er å endre strømtilstanden til noden (change_node_power_state). Strategien krever ikke innsamling av beregninger.
Serverkonsolidering - minimer antall databehandlingsnoder (konsolidering). Den har to strategier: Basic Offline Server Consolidation og VM Workload Consolidation Strategy.
Strategien Basic Offline Server Consolidation minimerer det totale antallet servere som brukes og minimerer også antallet migreringer.
Den grunnleggende strategien krever følgende beregninger:
beregninger
service
plugins
комментарий
compute.node.cpu.percent
none
cpu_util
none
Strategiparametere: migration_attempts - antall kombinasjoner for å søke etter potensielle kandidater for avslutning (standard, 0, ingen begrensninger), periode - tidsintervall i sekunder for å få statisk aggregering fra den metriske datakilden (standard, 700).
Metoder som brukes: migrering, endring av nova-tjenestetilstanden (change_nova_service_state).
VM Workload Consolidation Strategy er basert på en first-fit heuristikk som fokuserer på målt CPU-belastning og forsøk på å minimere noder som har for mye eller for liten belastning gitt ressurskapasitetsbegrensninger. Denne strategien gir en løsning som resulterer i mer effektiv bruk av klyngressursene ved å bruke følgende fire trinn:
- Lossefase - behandling av overbrukte ressurser;
- Konsolideringsfase - håndtering av underutnyttede ressurser;
- Optimalisering av løsningen - redusere antall migrasjoner;
- Deaktivering av ubrukte databehandlingsnoder.
Strategien krever følgende beregninger:
beregninger
service
plugins
комментарий
minne
none
disk.rotstørrelse
none
Følgende beregninger er valgfrie, men vil forbedre strateginøyaktigheten hvis tilgjengelig:
beregninger
service
plugins
комментарий
minne.bosatt
none
cpu_util
none
Strategiparametere: periode — tidsintervall i sekunder for å oppnå statisk aggregering fra den metriske datakilden (standard, 3600).
Bruker de samme metodene som forrige strategi. Mer informasjon .
Arbeidsbelastningsbalansering — balansere arbeidsbelastningen mellom databehandlingsnoder. Målet har tre strategier: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.
Workload Balance Migration Strategy kjører virtuell maskinmigrering basert på den virtuelle vertsmaskinens arbeidsbelastning. En migreringsbeslutning tas når % CPU- eller RAM-utnyttelse av en node overskrider den angitte terskelen. I dette tilfellet bør den flyttede virtuelle maskinen bringe noden nærmere den gjennomsnittlige arbeidsbelastningen for alle noder.
Krav
- Bruk av fysiske prosessorer;
- Minst to fysiske databehandlingsnoder;
- Installerte og konfigurerte Ceilometer-komponenten - ceilometer-agent-compute, kjører på hver beregningsnode, og Ceilometer API, i tillegg til å samle inn følgende beregninger:
beregninger
service
plugins
комментарий
cpu_util
none
minne.bosatt
none
Strategiparametere:
parameter
typen
som standard
описание
beregninger
String
'cpu_util'
De underliggende beregningene er: 'cpu_util', 'memory.resident'.
terskel
Nr
25.0
Arbeidsbelastningsterskel for migrering.
perioden
Nr
300
Kumulativ tidsperiode Ceilometer.
Metoden som brukes er migrasjon.
Arbeidsbelastningsstabilisering er en strategi som tar sikte på å stabilisere arbeidsbelastningen ved hjelp av direkte migrering. Strategien er basert på en standardavviksalgoritme og bestemmer om det er overbelastning i klyngen og reagerer på det ved å utløse maskinmigrering for å stabilisere klyngen.
Krav
- Bruk av fysiske prosessorer;
- Minst to fysiske databehandlingsnoder;
- Installerte og konfigurerte Ceilometer-komponenten - ceilometer-agent-compute, kjører på hver beregningsnode, og Ceilometer API, i tillegg til å samle inn følgende beregninger:
beregninger
service
plugins
комментарий
cpu_util
none
minne.bosatt
none
Lagringskapasitetsbalansestrategi (strategi implementert fra Queens) - strategien overfører disker avhengig av belastningen på Cinder-bassengene. En overføringsbeslutning tas hver gang poolutnyttelsesgraden overstiger en spesifisert terskel. Disken som flyttes bør bringe bassenget nærmere gjennomsnittsbelastningen for alle Cinder-bassenger.
Krav og restriksjoner
- Minimum to Cinder bassenger;
- Mulighet for diskmigrering.
- Klyngedatamodell – Cinder-klyngedatamodellsamler.
Strategiparametere:
parameter
typen
som standard
описание
volumterskel
Nr
80.0
Terskelverdi på disker for å balansere volumer.
Metoden som brukes er diskmigrering (volume_migrate).
Noisy Neighbor - Identifiser og migrér en "støyende nabo" - en virtuel maskin med lav prioritet som negativt påvirker ytelsen til en høyprioritet virtuell maskin når det gjelder IPC ved å overbruke Last Level Cache. Egen strategi: Noisy Neighbor (strategiparameteren som brukes er cache_threshold (standardverdien er 35), når ytelsen faller til den angitte verdien, startes migrering. For at strategien skal fungere, aktiveres LLC (Last Level Cache)-beregninger, nyeste Intel-server med CMT-støtte, i tillegg til å samle inn følgende beregninger:
beregninger
service
plugins
комментарий
cpu_l3_cache
none
Intel kreves .
Klyngedatamodell (standard): Nova-klyngedatamodellsamler. Metoden som brukes er migrasjon.
Å jobbe med dette målet gjennom Dashboard er ikke fullt implementert i Queens.
Termisk optimalisering — optimalisere temperaturregimet. Utløpstemperatur (avtrekksluft) er et av de viktige termiske telemetrisystemene for å måle den termiske/arbeidsbelastningsstatusen til en server. Målet har én strategi, den utløpstemperaturbaserte strategien, som bestemmer seg for å migrere arbeidsbelastninger til termisk gunstige verter (laveste utløpstemperatur) når utløpstemperaturen til kildevertene når en konfigurerbar terskel.
For at strategien skal fungere, trenger du en server med Intel Power Node Manager installert og konfigurert , i tillegg til å samle inn følgende beregninger:
beregninger
service
plugins
комментарий
hardware.ipmi.node.outlet_temperature
IPMI
Strategiparametere:
parameter
typen
som standard
описание
terskel
Nr
35.0
Temperaturterskel for migrasjon.
perioden
Nr
30
Tidsintervallet, i sekunder, for å hente den statistiske aggregeringen fra den metriske datakilden.
Metoden som brukes er migrasjon.
Optimalisering av luftstrøm — optimalisere ventilasjonsmodusen. Egen strategi - Ensartet luftstrøm ved bruk av direkte migrering. Strategien utløser virtuell maskinmigrering når luftstrømmen fra serverviften overskrider en spesifisert terskel.
For at strategien skal fungere trenger du:
- Maskinvare: beregningsnoder < støtter NodeManager 3.0;
- Minst to datanoder;
- Ceilometer-agent-compute og Ceilometer API-komponenten installert og konfigurert på hver databehandlingsnode, som kan rapportere beregninger som luftstrøm, systemeffekt, innløpstemperatur:
beregninger
service
plugins
комментарий
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperatur
IPMI
hardware.ipmi.node.power
IPMI
For at strategien skal fungere, trenger du en server med Intel Power Node Manager 3.0 eller nyere installert og konfigurert.
Begrensninger: Konseptet er ikke beregnet for produksjon.
Det foreslås å bruke denne algoritmen med kontinuerlige revisjoner, siden bare én virtuell maskin er planlagt migrert per iterasjon.
Live migrasjoner er mulig.
Strategiparametere:
parameter
typen
som standard
описание
terskel_luftstrøm
Nr
400.0
Luftstrømterskel for migreringsenhet er 0.1 CFM
threshold_inlet_t
Nr
28.0
Innløpstemperaturterskel for migrasjonsbeslutning
terskel_kraft
Nr
350.0
Systemkraftterskel for migreringsbeslutning
perioden
Nr
30
Tidsintervallet, i sekunder, for å hente den statistiske aggregeringen fra den metriske datakilden.
Metoden som brukes er migrasjon.
Maskinvarevedlikehold — maskinvarevedlikehold. Strategien knyttet til dette målet er Zone migration. Strategien er et verktøy for effektiv automatisk og minimal migrering av virtuelle maskiner og disker ved behov for maskinvarevedlikehold. Strategi bygger en handlingsplan i samsvar med vekter: et sett med handlinger som har større vekt vil bli planlagt før andre. Det er to konfigurasjonsalternativer: action_weights og parallellisering.
Begrensninger: handlingsvekter og parallellisering må konfigureres.
Strategiparametere:
parameter
typen
som standard
описание
compute_nodes
matrise
none
Beregn noder for migrering.
lagringsbassenger
matrise
none
Lagringsnoder for migrering.
parallell_total
heltall
6
Det totale antallet aktiviteter som må utføres parallelt.
parallell_per_node
heltall
2
Antall handlinger som utføres parallelt for hver beregningsnode.
parallel_per_pool
heltall
2
Antall handlinger som utføres parallelt for hver lagringspool.
prioritet
objekt
none
Prioriteringsliste for virtuelle maskiner og disker.
med_vedlagt_volum
boolean
Falsk
False – virtuelle maskiner vil bli migrert etter at alle disker er migrert. Sant – virtuelle maskiner vil bli migrert etter at alle tilkoblede disker er migrert.
Elementer i utvalget av databehandlingsnoder:
parameter
typen
som standard
описание
src_node
string
none
Datamaskinnoden som de virtuelle maskinene blir migrert fra (obligatorisk).
dst_node
string
none
Beregn noden som de virtuelle maskinene migrerer til.
Elementer for lagringsnoder:
parameter
typen
som standard
описание
src_pool
string
none
Lagringsbassenget som diskene blir migrert fra (obligatorisk).
dst_pool
string
none
Lagringsbassenget som diskene migreres til.
src_type
string
none
Original disktype (påkrevd).
dst_type
string
none
Den resulterende disktypen (påkrevd).
Objektprioriterte elementer:
parameter
typen
som standard
описание
prosjekt
matrise
none
Prosjektnavn.
compute_node
matrise
none
Beregn nodenavn.
storage_pool
matrise
none
Navn på lagerbassenger.
beregne
enum
none
Virtuelle maskinparametere ["vcpu_num", "mem_size", "disk_size", "created_at"].
lagring
enum
none
Diskparametere ["størrelse", "skapt_på"].
Metodene som brukes er virtuell maskinmigrering, diskmigrering.
Unclassified - et hjelpemål som brukes for å lette strategiutviklingsprosessen. Inneholder ingen spesifikasjoner og kan brukes når strategien ennå ikke er knyttet til et eksisterende mål. Dette målet kan også brukes som et overgangspunkt. En relatert strategi til dette målet er Actuator.
Skaper et nytt mål
Watcher Decision Engine har et "eksternt mål" plugin-grensesnitt som gjør det mulig å integrere et eksternt mål som kan oppnås ved hjelp av en strategi.
Før du oppretter et nytt mål, bør du sørge for at ingen eksisterende mål oppfyller dine behov.
Opprette en ny plugin
For å opprette et nytt mål, må du: utvide målklassen, implementere en klassemetode get_name() for å returnere den unike ID-en til det nye målet du vil opprette. Denne unike identifikatoren må samsvare med navnet på inngangspunktet du oppgir senere.
Deretter må du implementere klassemetoden get_display_name() for å returnere det oversatte visningsnavnet til målet du vil opprette (ikke bruk en variabel for å returnere den oversatte strengen slik at den automatisk kan samles inn av oversettelsesverktøyet.).
Implementer en klassemetode get_translatable_display_name()for å returnere oversettelsesnøkkelen (faktisk det engelske visningsnavnet) til det nye målet. Returverdien må samsvare med strengen som er oversatt til get_display_name().
Implementer metoden hans get_efficacy_specification()for å returnere effektivitetsspesifikasjonen for målet ditt. Metoden get_efficacy_specification() returnerer Unclassified()-forekomsten levert av Watcher. Denne ytelsesspesifikasjonen er nyttig i prosessen med å utvikle målet ditt fordi det samsvarer med den tomme spesifikasjonen.
→
Watcher-arkitektur (mer detaljer) ).
Komponenter
Watcher API - en komponent som implementerer REST API levert av Watcher. Interaksjonsmekanismer: CLI, Horizon plugin, Python SDK.
Watcher DB — Watcher-database.
Watcher Applier — en komponent som implementerer gjennomføringen av en handlingsplan opprettet av Watcher Decision Engine-komponenten.
Watcher Decision Engine - Komponenten som er ansvarlig for å beregne et sett med potensielle optimaliseringshandlinger for å nå revisjonsmålet. Hvis en strategi ikke er spesifisert, velger komponenten uavhengig den mest passende.
Watcher Metrics Publisher - En komponent som samler inn og beregner noen beregninger eller hendelser og publiserer dem til CEP-endepunktet. Funksjonaliteten til komponenten kan også leveres av Ceilometer-utgiveren.
Complex Event Processing (CEP)-motor — motor for kompleks hendelsesbehandling. Av ytelsesgrunner kan det være flere CEP Engine-forekomster som kjører samtidig, og hver behandler en bestemt type metrikk/hendelse. I Watcher-systemet utløser CEP to typer handlinger: - registrer de tilsvarende hendelsene / beregningene i tidsseriedatabasen; - send passende hendelser til Watcher Decision Engine når denne hendelsen kan påvirke resultatet av den gjeldende optimaliseringsstrategien, siden Openstack-klyngen ikke er et statisk system.
Komponentene samhandler ved hjelp av AMQP-protokollen.
→
Interaksjonsskjema med Watcher
Watcher testresultater
- På Optimalisering - Handlingsplaner 500-siden (både på rene Queens og på et stativ med Tionix-moduler), vises det først etter at revisjonen er lansert og en handlingsplan er generert; den tomme åpnes normalt.
- Det er feil på fanen Handlingsdetaljer, det er ikke mulig å få revisjonsmålet og strategien (både på rene Queens og på stand med Tionix-moduler).
- Tilsyn med formålet Dummy (test) opprettes og lanseres normalt, handlingsplaner genereres.
- Tilsyn for det uklassifiserte målet opprettes ikke fordi målet ikke er funksjonelt og er ment for mellomkonfigurasjon ved opprettelse av nye strategier.
- Revisjon for formålet med arbeidsbelastningsbalansering (Storage Capacity-balansestrategi) opprettes vellykket, men en handlingsplan genereres ikke. Ingen lagringsbassengoptimalisering er nødvendig.
- Revisjoner for arbeidsbelastningsbalanseringsmålet (Workload Balance Migration Strategy) opprettes vellykket, men en handlingsplan genereres ikke.
- Revisjon av arbeidsbelastningsbalansering (arbeidsbelastningsstabiliseringsstrategi) mislykkes.
- Revisjoner for Noisy Neighbor-målet er opprettet med suksess, men en handlingsplan blir ikke generert.
- Revisjoner for vedlikehold av maskinvare er opprettet på en vellykket måte, handlingsplanen genereres ikke i sin helhet (ytelsesindikatorer genereres, men selve handlingslisten genereres ikke).
- Redigeringer i nova.conf-konfigurasjonene (i standarddelen compute_monitors = cpu.virt_driver) på beregnings- og kontrollnodene retter ikke feilene.
- Revisjon rettet mot serverkonsolidering (grunnleggende strategi) mislykkes også.
- Revisjon for formålet med serverkonsolidering (VM-arbeidsbelastningskonsolideringsstrategi) mislykkes med en feil. I loggene er det en feil ved innhenting av kildedata. Spesielt diskusjon om feilen .
Vi prøvde å spesifisere Watcher i konfigurasjonsfilen (det hjalp ikke - som et resultat av en feil på alle optimaliseringssider, korrigerer ikke situasjonen ved å gå tilbake til det opprinnelige innholdet i konfigurasjonsfilen): [watcher_strategies.basic] datakilde = ceilometer, gnocchi - Tilsyn for å spare energi mislykkes. Etter loggene å dømme er problemet fortsatt fraværet av Ironic; det vil ikke fungere uten baremetal-service.
- Tilsyn for termisk optimalisering mislykkes. Tilbakesporingen er den samme som for Server Consolidation (VM-arbeidsbelastningskonsolideringsstrategi) (kildedatafeil)
- Revisjoner for luftstrømoptimalisering mislykkes med en feil.
Følgende revisjonsfullføringsfeil oppstår også. Traceback i decision-engine.log-logger (klyngetilstand er ikke definert).
→ Diskusjon av feilen
Konklusjon
Resultatet av vår to måneder lange forskning var den entydige konklusjonen at for å få et fullverdig, fungerende lastbalanseringssystem, må vi i denne delen jobbe tett med å foredle verktøyene for Openstack-plattformen.
Watcher har vist seg å være et seriøst og raskt utviklende produkt med et enormt potensial, hvis full bruk vil kreve mye seriøst arbeid.
Men mer om dette i de neste artiklene i serien.
Kilde: www.habr.com