ProHoster > Blogg > Administrasjon > Lastbalansering i Openstack

Lastbalansering i Openstack

I store skybaserte systemer er spÞrsmÄlet om automatisk lastbalansering eller justering av belastningen pÄ datakilder sÊrlig viktig. Dette spÞrsmÄlet har ogsÄ vÊrt tidligere pÄ agendaen hos Tionic (utvikler og operatÞr av skybaserte tjenester, som er en del av Rostelecom-gruppen).

Og siden vÄr hovedutviklingsplattform er Openstack, og vi, som alle mennesker, er late, ble det besluttet Ä finne en eksisterende modul som allerede er en del av plattformen. Valget falt pÄ Watcher, som vi bestemte oss for Ä bruke til vÄre behov.
Lastbalansering i Openstack
La oss fÞrst se nÊrmere pÄ begreper og definisjoner.

Begreper og definisjoner

MĂ„l — er et menneskelig lesbart, observerbart og mĂ„lbart endelig resultat som mĂ„ oppnĂ„s. For Ă„ oppnĂ„ hvert mĂ„l finnes det en eller flere strategier. En strategi er implementeringen av en algoritme som er i stand til Ă„ finne en lĂžsning for dette mĂ„let.

Handling (Action) — er en elementĂŠr oppgave som endrer den nĂ„vĂŠrende tilstanden til det mĂ„lrettede styrte resursen i OpenStack-klyngen, slik som: migrering av virtuell maskin (migration), endring av strĂžmkilde for noden (change_node_power_state), endring av tilstanden til nova-tjenesten (change_nova_service_state), endring av flavor (resize), registrering av NOP-melding (nop), ingen handlinger i en viss tidsperiode — pause (sleep), flytting av disk (volume_migrate).

Handlingsplan (Action Plan) — er en spesifikk strĂžm av handlinger utfĂžrt i en bestemt rekkefĂžlge for Ă„ oppnĂ„ et spesifikt mĂ„l. Handlingsplanen inneholder ogsĂ„ en anslĂ„tt global effektivitet med et sett av ytelsesmĂ„l. Handlingsplanen genereres av Watcher etter en vellykket revisjon, der den brukte strategien finner en lĂžsning for Ă„ oppnĂ„ mĂ„let. Handlingsplanen bestĂ„r av en liste med sekvensielle handlinger.

Revisjon (Audit) — er en forespĂžrsel om optimalisering av klyngen. Optimalisering utfĂžres for Ă„ oppnĂ„ ett mĂ„l i denne klyngen. For hver vellykket revisjon genererer Watcher en handlingsplan.

RevisjonsomrĂ„de (Audit Scope) — er en samling ressurser der revisjonen gjennomfĂžres (tilgjengelighetssone(r), nodeaggregatorer, individuelle databehandlingsnoder eller lagringsnoder osv.). RevisjonsomrĂ„det er definert i hver mal. Hvis revisjonsomrĂ„det ikke er angitt, revideres hele klyngen.

Revisjonsmal (Audit Template) — et lagret sett med innstillinger for Ă„ kjĂžre revisjonen. Malene er nĂždvendige for Ă„ kunne gjennomfĂžre revisjoner flere ganger med de samme innstillingene. Malen mĂ„ nĂždvendigvis inneholde revisjonsmĂ„let; hvis strategiene ikke oppgis, velges de mest passende fra eksisterende strategier.

Klynge (Cluster) — er et sett med fysiske maskiner som gir databehandlingsressurser, lagringsressurser og nettverksressurser, og som styres av samme OpenStack-kontrollnode.

Datamodell for klyngen (Cluster Data Model, CDM) — er en logisk representasjon av nĂ„vĂŠrende tilstand og topologi av de ressurser som administreres av klyngen.

Effektivitetsindikator (Efficacy Indicator) — er en indikator som viser hvordan lĂžsningen, laget med denne strategien, fungerer. Effektivitetsindikatorer er spesifikke for et bestemt mĂ„l og brukes vanligvis til Ă„ beregne den globale effektiviteten til den endelige handlingsplanen.

Effektivitets spesifikasjon (Efficacy Specification) — er et sett med spesifikke egenskaper knyttet til hvert mĂ„l som definerer ulike effektivitetsindikatorer som strategien som sikrer oppnĂ„elsen av det aktuelle mĂ„let, mĂ„ oppfylle i sin lĂžsning. Hver lĂžsning foreslĂ„tt av strategien vil faktisk bli sjekket mot spesifikasjonen fĂžr den globale effektiviteten beregnes.

“Scoringsmotor” (Scoring Engine) — er en kjþrbar fil som har klart definerte inngangsdata, klart definerte utgangsdata og utfþrer en ren matematisk oppgave. Dermed er beregningen uavhengig av miljþet der den kjþres — den gir samme resultat hvor som helst.

Watcher-planlegger (Watcher Planner) — en del av beslutningsmekanismen Watcher. Denne modulen mottar et sett med handlinger generert av strategien og lager en arbeidsplan som definerer hvordan disse forskjellige handlingene skal planlegges over tid, samt hvilke forhĂ„ndsbetingelser som gjelder for hver handling.

MĂ„l og strategier for Watcher

MĂ„l
Strategier

Dummy mÄl
Dummy strategi 

Dummy strategi med eksempel pÄ vurderingsmotorer

Dummy strategi med endring av stĂžrrelse

Energisparing
Energisparingsstrategi

Serverkonsolidering
Grunnleggende offline serverkonsolidering

VM arbeidsbelastningskonsolideringsstrategi

Arbeidsbelastningsbalansering
Strategi for arbeidsbelastningsbalanseoverfĂžring

Strategi for balanse av lagringskapasitet

Stabilisering av arbeidsbelastning

StĂžyende nabo
StĂžyende nabo

Termisk optimalisering
Strategi basert pÄ utgangstemperatur

LuftstrĂžmsoptimalisering
Strategi for enhetlig luftstrĂžmsoverfĂžring

Maskinvarevedlikehold
SoneoverfĂžring

Ikke klassifisert
Aktuator

Dummy mĂ„l — et reservert mĂ„l som brukes til testing.

Tilknyttede strategier: Dummy strategi, Dummy strategi med eksempel pÄ vurderingsmotorer og Dummy strategi med endring av stÞrrelse. Dummy strategi er en fiktiv strategi som brukes for integrasjonstesting gjennom Tempest. Strategien gir ingen nyttig optimalisering; dens eneste formÄl er Ä brukes i Tempest-tester.

Dummy strategi med eksempel pĂ„ vurderingsmotorer — strategien er lik den forrige, men skiller seg ut ved Ă„ bruke eksempel pĂ„ «vurderingsmotor» som teller med metoder for maskinlĂŠring.

Dummy strategi med endring av stĂžrrelse — strategien er lik den forrige, men skiller seg ut ved Ă„ bruke endring av smak (migrasjon og endring av stĂžrrelse).

Brukes ikke i produksjon.

Energisparing — minimere energiforbruket. Strategien for dette mĂ„let, Energibesparingsstrategi, sammen med strategien for VM arbeidsbelastningskonsolidering (Serverkonsolidering), er i stand til Ă„ utfĂžre dynamisk energihĂ„ndtering (DPM). Denne funksjonen sparer elektrisitet ved Ă„ konsolidere arbeidsbelastninger dynamisk, selv i perioder med lav ressursbelastning: virtuelle maskiner flyttes til fĂŠrre noder, og unĂždvendige noder slĂ„s av. Etter konsolidering tilbyr strategien en lĂžsning for Ă„ slĂ„ noder av/pĂ„ i henhold til gitte parametre: “min_free_hosts_num” — antall frie noder som er pĂ„slĂ„tt og venter pĂ„ last, og “free_used_percent” — prosentandelen frie noder som brukes i forhold til hvor mange noder som er opptatt av maskiner. For at strategien skal fungere, mĂ„ Ironic vĂŠre aktivert og konfigurert for Ă„ hĂ„ndtere pĂ„- og avskrivning av strĂžm pĂ„ noder.

Strategiparametere

parameter
type
som standard
beskrivelse

free_used_percent
Nummer
10.0
forholdet mellom antall ledige beregningsnoder og antall beregningsnoder med virtuelle maskiner

min_free_hosts_num
Int
1
minimum antall ledige beregningsnoder

Det mÄ vÊre minst to noder i skyen. Den brukte metoden er Ä endre strÞmtilstanden til noden (change_node_power_state). Strategien for innsamling av metrikker krever ikke noe.

Serverkonsolidering — minimere antallet beregningsnoder (konsolidering). Den har to strategier: Basic Offline Server Consolidation og VM Workload Consolidation Strategy.

Strategien Basic Offline Server Consolidation minimerer det totale antallet brukte servere, samt minimerer antallet migrasjoner.

Den grunnleggende strategien krever fĂžlgende metrikker:

metrikker
tjeneste
plugins
kommentar

compute.node.cpu.percent
ceilometer
none
 

cpu_util
ceilometer
none
 

Strategiinnstillinger: migration_attempts — antall kombinasjoner for Ă„ sĂžke etter potensielle kandidater for avstenging (standard, 0, ingen begrensninger), period — tidsintervall i sekunder for Ă„ hente statisk aggregat fra datakilden til metrikken (standard, 700).

Brukte metoder: migrasjon, endring av tilstanden til nova-tjenesten (change_nova_service_state).

Strategien VM Workload Consolidation Strategy er basert pÄ en heuristisk fÞrste passende algoritme (first-fit), som fokuserer pÄ mÄlt CPU-belastning og forsÞker Ä minimere noder som har for hÞy eller for lav belastning med hensyn til ressurskapasitetsbegrensningene. Denne strategien gir en lÞsning som fÞrer til mer effektiv ressursutnyttelse av klyngen, ved Ä bruke fÞlgende fire faser:

  1. Avlastningsfase — behandling av overforbrukte ressurser;
  2. Konsolideringsfase — behandling av utilstrekkelig utnyttede ressurser;
  3. Optimalisering av lþsningen — reduksjon av antall migrasjoner;
  4. AvslÄing av uutnyttede beregningsnoder.

Strategien krever fĂžlgende metrikker:

metrikker
tjeneste
plugins
kommentar

memory
ceilometer
none
 

disk.root.size
ceilometer
none
 

FĂžlgende metrikker er ikke obligatoriske, men Ăžker nĂžyaktigheten til strategien, hvis tilgjengelig:

metrikker
tjeneste
plugins
kommentar

memory.resident
ceilometer
none
 

cpu_util
ceilometer
none
 

Strategiinnstillinger: period — tidsintervall i sekunder for Ă„ hente statisk aggregat fra datakilden til metrikken (standard, 3600).

Bruker de samme metodene som den forrige strategien. Mer info her.

Arbeidsbelastningsbalansering — balansere arbeidsmengden mellom beregningsnoder. MĂ„let har tre strategier: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.

Workload Balance Migration Strategy starter migreringer av virtuelle maskiner basert pÄ arbeidsbelastningen til nodenes virtuelle maskiner. Beslutningen om Ä flytte tas hver gang % CPU- eller RAM-bruk pÄ noden overskrider angitt terskel. Den flyttede virtuelle maskinen mÄ bringe noden nÊr den gjennomsnittlige arbeidsbelastningen for alle noder.

Krav

  • Bruk av fysiske prosessorer;
  • Minst to fysiske beregningsnoder;
  • Installerte og konfigurerte Ceilometer-komponenter — ceilometer-agent-compute, som kjĂžrer pĂ„ hver beregningsnode, og Ceilometer API, samt innsamling av fĂžlgende metrikker:

metrikker
tjeneste
plugins
kommentar

cpu_util
ceilometer
none
 

memory.resident
ceilometer
none
 

Strategi parametere:

parameter
type
som standard
beskrivelse

metrics,
Streng
'cpu_util'
Metrikker som ligger til grunn: ‘cpu_util’, ‘memory.resident’.

terskel
Nummer
25.0
Terskelverdi for arbeidsbelastning for migrering.

periode
Nummer
300
Den totale tiden for Ceilometer.

Brukt metode — migrering.

Workload stabilisering — en strategi for Ă„ stabilisere arbeidsbelastningen ved hjelp av live migrering. Strategien er basert pĂ„ standardavvik-algoritmen og bestemmer om det er overbelastning i klyngen, og reagerer pĂ„ dette ved Ă„ starte migrering av maskiner for Ă„ stabilisere klyngen.

Krav

  • Bruk av fysiske prosessorer;
  • Minst to fysiske beregningsnoder;
  • Installerte og konfigurerte Ceilometer-komponenter — ceilometer-agent-compute, som kjĂžrer pĂ„ hver beregningsnode, og Ceilometer API, samt innsamling av fĂžlgende metrikker:

metrikker
tjeneste
plugins
kommentar

cpu_util
ceilometer
none
 

memory.resident
ceilometer
none
 

Storage Capacity Balance Strategy (strategien ble implementert fra Queens) — strategien flytter disker avhengig av belastningen pĂ„ Cinder-poolene. Beslutningen om Ă„ flytte tas hver gang bruken av poolen overskrider angitt terskel. Den flyttede disken bĂžr bringe poolen nĂŠr gjennomsnittlig belastning for alle Cinder-pooler.

Krav og begrensninger

  • Minst to Cinder-pooler;
  • Mulighet for migrering av disker.
  • Modell for klynge-data — Cinder cluster data model collector.

Strategi parametere:

parameter
type
som standard
beskrivelse

volume_threshold
Nummer
80.0
Terskelverdi for disker for balansering av volum.

Brukt metode — disk migrering (volume_migrate).

Noisy Neighbor — identifisere og flytte 'stĂžytende nabo' — en virtuell maskin med lav prioritet som negativt pĂ„virker ytelsen til en virtuell maskin med hĂžy prioritet med hensyn til IPC, som overforbruker Last Level Cache. Egen strategi: Noisy Neighbor (brukte parameter for strategien — cache_threshold (standardverdi — 35), nĂ„r ytelsen faller til det angitte nivĂ„et, startes migreringen. For at strategien skal fungere, mĂ„ fĂžlgende vĂŠre aktivert: LLC (Last Level Cache) metrikker, den siste Intel-serveren med stĂžtte for CMT, samt innsamling av fĂžlgende metrikker:

metrikker
tjeneste
plugins
kommentar

cpu_l3_cache
ceilometer
none
Krever Intel CMT.

Datamodell for klyngen (standard): Nova klynge datamodell samler inn. Metoden som brukes er migrering.

Arbeid med dette formÄlet gjennom Dashboard er ikke helt implementert i Queens.

Termisk optimalisering — optimalisere temperaturforholdene. Temperatur pĂ„ utlĂžpet (avtrekksluft) er et av de viktige termiske telemetrisystemene for Ă„ mĂ„le tilstanden til den termiske / arbeidsbelastningen pĂ„ serveren. Det finnes en strategi for dette formĂ„let — Outlet temperature based strategy, som tar avgjĂžrelser om Ă„ flytte arbeidsbelastninger til noder med gunstige temperaturforhold (laveste utlĂžpstemperatur), nĂ„r utlĂžpstemperaturen pĂ„ kildevert-maskinene nĂ„r en justerbar terskel.

For at strategien skal fungere, er det nĂždvendig med en server med installert og konfigurert Intel Power Node Manager. 3.0 eller nyere versjon, samt innsamling av fĂžlgende metrikker:

metrikker
tjeneste
plugins
kommentar

hardware.ipmi.node.outlet_temperature
ceilometer
IPMI
 

Strategi parametere:

parameter
type
som standard
beskrivelse

terskel
Nummer
35.0
Temperaturgrense for migrering.

periode
Nummer
30
Tidsintervall i sekunder for Ă„ hente statistisk aggregasjon fra datakilde for metrikker.

Brukt metode — migrering.

Luftstrþmsoptimalisering — optimalisere ventilasjonsmodus. Egen strategi — Uniform Airflow using live migration. Strategien iverksetter migrering av virtuell maskin hver gang luftstrþmmen fra serverviften overstiger en angitt terskel.

For at strategien skal fungere, er det nĂždvendig med:

  • Maskinvare: beregningsnoder <som stĂžtter NodeManager 3.0;
  • Minimum to beregningsnoder;
  • Installert og konfigurert komponent ceilometer-agent-compute og Ceilometer API pĂ„ hver beregningsnode, som kan rapportere om metrikker som luftstrĂžm, systemkraft, inntemperatur:

metrikker
tjeneste
plugins
kommentar

hardware.ipmi.node.airflow
ceilometer
IPMI
 

hardware.ipmi.node.temperature
ceilometer
IPMI
 

hardware.ipmi.node.power
ceilometer
IPMI
 

For at strategien skal fungere, er det nĂždvendig med en server med installert og konfigurert Intel Power Node Manager 3.0 eller nyere versjon.

Begrensninger: Konseptet er ikke ment for produksjon.

Det anbefales Ă„ bruke denne algoritmen med kontinuerlige revisjoner, ettersom det er planlagt Ă„ migrere kun Ă©n virtuell maskin per iterasjon.

Live-migreringer er mulig.

Strategi parametere:

parameter
type
som standard
beskrivelse

threshold_airflow
Nummer
400.0
LuftstrĂžm terskel for migreringen Enhet er 0.1CFM

threshold_inlet_t
Nummer
28.0
Inntemperatur terskel for migreringsbeslutning

threshold_power
Nummer
350.0
Systemkraft terskel for migreringsbeslutning

periode
Nummer
30
Tidsintervall i sekunder for Ă„ hente statistisk aggregasjon fra datakilde for metrikker.

Brukt metode — migrering.

Maskinvarevedlikehold — maskinvare vedlikehold. Strategien relatert til dette mĂ„let er Zone migration. Strategien fungerer som et verktĂžy for effektiv, automatisk og minimal migrasjon av virtuelle maskiner og disker ved behov for maskinvarevedlikehold. Strategien utformer en handlingsplan basert pĂ„ vekter: handlingssett med hĂžyere vekt blir planlagt fĂžr andre. Det finnes to konfigurasjonsparametere: handlingsvekter (action_weights) og parallellisering (parallelization).

Begrensninger: nĂždvendig Ă„ konfigurere handlingsvekter og parallellisering.

Strategi parametere:

parameter
type
som standard
beskrivelse

compute_nodes
array
None
Beregningsnoder for migrasjon.

storage_pools
array
None
Lagringsnoder for migrasjon.

parallel_total
integer
6
Det totale antallet handlinger som skal utfĂžres parallelt.

parallel_per_node
integer
2
Antall handlinger som utfĂžres parallelt for hver beregningsnode.

parallel_per_pool
integer
2
Antall handlinger som utfĂžres parallelt for hver lagringspool.

priority
object
None
Liste over prioriteringer for virtuelle maskiner og disker.

with_attached_volume
boolean
False
False — virtuelle maskiner vil bli overfþrt etter at alle disker er overfþrt. True — virtuelle maskiner vil bli overfþrt etter at alle tilknyttede disker er migrert.

Elementer i arrayet av beregningsnoder:

parameter
type
som standard
beskrivelse

src_node
strengen
None
Beregningstype som virtuelle maskiner overfĂžres fra (obligatorisk).

dst_node
strengen
None
Beregningstype som virtuelle maskiner migreres til.

Elementer i arrayet av lagringsnoder:

parameter
type
som standard
beskrivelse

src_pool
strengen
None
Lagringspool som disker overfĂžres fra (obligatorisk).

dst_pool
strengen
None
Lagringspool som disker overfĂžres til.

src_type
strengen
None
Kildetype for disk (obligatorisk).

dst_type
strengen
None
MĂ„ltype for disk (obligatorisk).

Elementer i objektsprioritering:

parameter
type
som standard
beskrivelse

prosjekt
array
None
Prosjektnavn.

compute_node
array
None
Navn pÄ beregningsnoder.

storage_pool
array
None
Navn pÄ lagringspooler.

compute
enum
None
Parametere for virtuelle maskiner [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].

storage
enum
None
Diskparametere [“size”, “created_at”].

Brukte metoder — migrasjon av virtuelle maskiner, migrasjon av disker.

Ikke klassifisert — et hjelpemĂ„l brukt for Ă„ lette utviklingsprosessen av strategien. Inneholder ingen spesifikasjoner og kan brukes nĂ„r strategien ikke er knyttet til et eksisterende mĂ„l. Dette mĂ„let kan ogsĂ„ brukes som et overgangsstadium. Strategien knyttet til dette mĂ„let er Actuator.   

Oppretting av et nytt mÄl

Watcher Decision Engine har et grensesnitt for en "ekstern mÄl"-plugin som gir mulighet for Ä integrere et eksternt mÄl som kan nÄ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 behovene dine.

Oppretting av ny plugin

For Ä opprette et nytt mÄl mÄ du: utvide mÄlklassen, implementere klassens metode get_name () for Ä returnere den unike identifikatoren for det nye mÄlet du Þnsker Ä opprette. Denne unike identifikatoren mÄ samsvare med navnet pÄ inngangspunktet som du vil deklarere senere.

Deretter mÄ du implementere klassens metode get_display_name () for Ä returnere det oversatte visningsnavnet for mÄlet du Þnsker Ä opprette (ikke bruk en variabel for Ä returnere den oversatte strengen, slik at den kan samles automatisk av oversettelsesverktÞyet.).

Implementer klassens metode get_translatable_display_name (), for Ä returnere oversettelsesnÞkkelen (faktisk det engelske visningsnavnet) for ditt nye mÄl. Returverdien mÄ samsvare med strengen som er oversatt i get_display_name ().

Implementer sin metode get_efficacy_specification (), for Ä returnere spesifikasjonen for effektiviteten for mÄlet ditt. Metoden get_efficacy_specification () returnerer en instans av Unclassified (), gitt av Watcher. Denne spesifikasjonen for effektivitet er nyttig i utviklingen av mÄlet ditt, ettersom den samsvarer med en tom spesifikasjon.

→ Les mer her

Watcher-arkitekturen (les mer her).

Lastbalansering i Openstack

Komponenter

Lastbalansering i Openstack

Watcher API — komponent som implementerer REST API levert av Watcher. Interaksjonsmekanismer: CLI, Horizon-plugin, Python SDK.

Watcher DB — Watcher-databasen.

Watcher Applier — komponent som implementerer utfþrelsen av handlingsplanen laget av Watcher Decision Engine.

Watcher Decision Engine — komponent som er ansvarlig for Ă„ beregne settet av potensielle optimaliseringshandlinger for Ă„ oppnĂ„ revisjonsmĂ„let. Hvis det ikke angis noen strategi, velger komponenten selv den mest passende.

Watcher Metrics Publisher — komponent som samler og beregner noen metrikker eller hendelser og publiserer dem til CEP-endepunktet. Komponentens funksjonalitet kan ogsĂ„ tilbys av Ceilometer-publisher.

Complex Event Processing (CEP) Engine — motor for comprehensive event processing. For performance reasons, there may be multiple instances of the CEP Engine running simultaneously, each processing a specific type of metric/event. In the Watcher system, the CEP executes two types of actions: — record the corresponding events/metrics in the time-series database; — send relevant events to the Watcher Decision Engine component when this event may affect the outcome of the current optimization strategy, as the OpenStack cluster is not a static system.

Interaction between components is carried out via the AMQP protocol.

→ Configuring the Watcher

Interaction scheme with Watcher

Lastbalansering i Openstack

Watcher testing results

  1. On the Optimization — Action plans page, a 500 error occurs (both on a clean Queens and on a setup with Tyonix modules), which only appears after an audit is initiated and an action plan is generated; an empty one opens normally.
  2. On the Action details tab, errors occur, unable to retrieve the target and audit strategy (both on a clean Queens and on a setup with Tyonix modules).
  3. Audits with the Dummy target (test audits) are created and run normally, and action plans are generated.
  4. Audits with the Unclassified target are not created, as the target is non-functional and intended for intermediate tuning when creating new strategies.
  5. Audits with the Workload Balancing target (Storage Capacity balance strategy) are created successfully, however, no action plan is generated. Optimization of storage pools is not required.
  6. Audits with the Workload Balancing target (Workload Balance Migration Strategy) are created successfully, however, no action plan is generated.
  7. Audits with the Workload Balancing target (Workload Stabilization Strategy) end with an error.
  8. Audits with the Noisy Neighbor target are created successfully, however, no action plan is generated.
  9. Audits with the Hardware maintenance target are created successfully, but the action plan is not generated completely (performance indicators are generated, but the actual list of actions is not).
  10. Changes in the configs nova.conf (in the default section compute_monitors = cpu.virt_driver) on the compute and controller node do not fix the errors.
  11. Audits with the Server Consolidation target (Basic strategy) also end in error.
  12. Audits with the Server Consolidation target (VM workload consolidation strategy) end with an error. The logs indicate an error in obtaining the raw data. Discussion of the error, in particular, her.
    Vi prĂžvde Ă„ angi i konfigurasjonsfilen for Watcher (gjorde ikke noe — som et resultat av feil pĂ„ alle sidene i Optimalisering, tilbakefĂžring til den opprinnelige konfigurasjonsfilen lĂžser ikke problemet):

    [watcher_strategies.basic]
    datasource = ceilometer, gnocchi

  13. Revisjoner med mÄl om Energibesparelse avsluttes med feil. IfÞlge loggene er problemet fortsatt fravÊret av Ironic; det vil ikke fungere uten bare-metal tjenesten.
  14. Revisjoner med mÄl om Termisk Optimalisering avsluttes med feil. Traceback er den samme som for Server Konsolidering (strategi for VM arbeidsbelastningskonsolidering) (feil i kilde dataene)
  15. Revisjoner med mÄl om Airflow Optimalisering avsluttes med feil.

Det forekommer ogsÄ fÞlgende feil ved avslutning av revisjonen. Traceback i loggene decision-engine.log (tilstand pÄ klyngen er ikke definert).

→ Diskusjon av feil her

Konklusjon

Resultatet av vÄre to mÄneders undersÞkelser er en klar konklusjon om at for Ä fÄ et fullverdig, fungerende belastningsbalanseringssystem, mÄ vi i denne delen tett arbeide med videreutvikling av verktÞyene for Openstack-plattformen.

Watcher har vist seg Ă„ vĂŠre et seriĂžst og raskt utviklende produkt med enormt potensial, for full utnyttelse av det vil det kreves betydelig og grundig arbeid.

Men mer om dette – i de kommende artiklene i serien.

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster