Suurissa pilvijärjestelmissä laskentaresurssien kuormituksen automaattinen tasapainottaminen tai tasoitus on erityisen akuutti. Myös Tionix (pilvipalveluiden kehittäjä ja operaattori, osa Rostelecom-konsernia) on hoitanut asian.
Ja koska pääkehitysalustamme on Openstack ja me, kuten kaikki ihmiset, olemme laiskoja, päätettiin valita jokin valmis moduuli, joka on jo mukana alustassa. Valintamme osui Watcheriin, jota päätimme käyttää tarpeisiimme.
Katsotaanpa ensin termejä ja määritelmiä.
Termit ja määritelmät
Tavoite on ihmisen luettavissa oleva, havaittavissa oleva ja mitattavissa oleva lopputulos, joka on saavutettava. Jokaisen tavoitteen saavuttamiseksi on yksi tai useampi strategia. Strategia on sellaisen algoritmin toteutus, joka pystyy löytämään ratkaisun tiettyyn tavoitteeseen.
Toiminta on perustehtävä, joka muuttaa OpenStack-klusterin kohdehallitun resurssin nykyistä tilaa, kuten: virtuaalikoneen siirto (migration), solmun tehotilan muuttaminen (change_node_power_state), nova-palvelun tilan muuttaminen (change_nova_service_state). ), maun muuttaminen (muuta kokoa), NOP-viestien rekisteröinti (nop), toiminnan puute tietyn ajan - tauko (lepotila), levyn siirto (volume_migrate).
Toimintasuunnitelma - tiettyjen toimien määrä tietyssä järjestyksessä tietyn tavoitteen saavuttamiseksi. Toimintasuunnitelma sisältää myös mitattua maailmanlaajuista suorituskykyä suoritusindikaattoreineen. Onnistuneen auditoinnin jälkeen Watcher luo toimintasuunnitelman, jonka tuloksena käytetty strategia löytää ratkaisun tavoitteen saavuttamiseen. Toimintasuunnitelma koostuu luettelosta peräkkäisistä toimista.
Tarkastaa on pyyntö klusterin optimoimiseksi. Optimointi suoritetaan yhden tavoitteen saavuttamiseksi tietyssä klusterissa. Jokaisesta onnistuneesta auditoinnista Watcher luo toimintasuunnitelman.
Tarkastuksen laajuus on joukko resursseja, joissa auditointi suoritetaan (saatavuusvyöhykkeet, solmuaggregaattorit, yksittäiset laskentasolmut tai tallennussolmut jne.). Tarkastuksen laajuus määritellään jokaisessa mallissa. Jos tarkastuksen laajuutta ei ole määritetty, koko klusteri tarkastetaan.
Tarkastusmalli — tallennettu asetussarja tarkastuksen käynnistämistä varten. Malleja tarvitaan, jotta tarkastukset suoritetaan useita kertoja samoilla asetuksilla. Mallissa on välttämättä oltava auditoinnin tarkoitus, jos strategioita ei ole määritelty, valitaan sopivimmat olemassa olevat strategiat.
Klusteri on kokoelma fyysisiä koneita, jotka tarjoavat laskenta-, tallennus- ja verkkoresursseja ja joita hallinnoi sama OpenStack-hallintasolmu.
Cluster Data Model (CDM) on looginen esitys klusterin hallinnoimien resurssien nykytilasta ja topologiasta.
Tehokkuusindikaattori - indikaattori, joka osoittaa, kuinka tällä strategialla luotu ratkaisu suoritetaan. Suorituskykyindikaattorit ovat tietylle tavoitteelle ominaisia, ja niitä käytetään tyypillisesti tuloksena olevan toimintasuunnitelman maailmanlaajuisen tehokkuuden laskemiseen.
Tehokkuusspesifikaatio on joukko jokaiseen tavoitteeseen liittyviä erityisominaisuuksia, jotka määrittelevät erilaiset suorituskykyindikaattorit, jotka vastaavan tavoitteen saavuttamiseksi strategian on saavutettava ratkaisussaan. Itse asiassa jokainen strategiassa ehdotettu ratkaisu tarkistetaan spesifikaatioiden perusteella ennen sen maailmanlaajuisen tehokkuuden laskemista.
Pisteytysmoottori on suoritettava tiedosto, jolla on hyvin määritellyt tulot, hyvin määritellyt lähdöt ja joka suorittaa puhtaasti matemaattisen tehtävän. Tällä tavalla laskenta on riippumaton ympäristöstä, jossa se suoritetaan – se antaa saman tuloksen kaikkialla.
Watcher Planner - osa Watcherin päätöksentekomoottoria. Tämä moduuli ottaa joukon strategian tuottamia toimia ja luo työnkulkusuunnitelman, jossa määritellään kuinka nämä eri toimet ajoitetaan ajoissa ja kullekin toiminnolle, mitkä ovat edellytykset.
Watcherin tavoitteet ja strategiat
Tavoite
strategia
Tyhmä maali
Nukke strategia
Dummy-strategia mallipisteytyskoneilla
Tyhjä strategia koon muutoksilla
Energian säästäminen
Energiansäästöstrategia
Palvelimen yhdistäminen
Basic Offline Server Consolidation
VM-työkuorman konsolidointistrategia
Työkuormien tasapainotus
Työkuorman tasapainon siirtostrategia
Varastointikapasiteetin tasapainostrategia
Työkuorman vakauttaminen
Meluisa naapuri
Meluisa naapuri
Lämpöoptimointi
Lähtölämpötilaan perustuva strategia
Ilmavirran optimointi
Yhtenäinen ilmavirran siirtymisstrategia
Laitteiston huolto
Alueen siirto
Luokittelematon
toimilaite
Tyhmä maali — varattu tavoite, jota käytetään testaustarkoituksiin.
Aiheeseen liittyvät strategiat: Dummy-strategia, nuken strategia, jossa käytetään esimerkkipisteytysmoottoreita ja nuken strategia koon muutoksilla. Dummy-strategia on dummy-strategia, jota käytetään integraatiotestaukseen Tempestin kautta. Tämä strategia ei tarjoa hyödyllistä optimointia, sen ainoa tarkoitus on käyttää Tempest-testejä.
Tekevä strategia mallipisteytyskoneilla - strategia on samanlainen kuin edellinen, ainoa ero on mallin "pisteytysmoottorin" käyttö, joka suorittaa laskelmia koneoppimismenetelmillä.
Nukkestrategia koon muuttamiseen - strategia on samanlainen kuin edellinen, ainoa ero on makun muuttamisen käyttö (migraatio ja koon muuttaminen).
Ei käytössä tuotannossa.
Energian säästäminen - minimoi energiankulutus. Tämän tavoitteen Saving Energy Strategy yhdessä VM Workload Consolidation Strategy (Server Consolidation) kanssa kykenee dynaamisiin virranhallinnan (DPM) ominaisuuksiin, jotka säästävät energiaa yhdistämällä dynaamisesti työkuormituksia myös silloin, kun resurssien käyttö on vähäistä: virtuaalikoneita siirretään harvempaan solmuun. , ja tarpeettomat solmut poistetaan käytöstä. Konsolidoinnin jälkeen strategia tarjoaa päätöksen solmujen kytkemisestä päälle/pois määritettyjen parametrien mukaisesti: "min_free_hosts_num" - vapaiden käytössä olevien solmujen määrä, jotka odottavat latausta, ja "free_used_percent" - vapaasti käytössä olevien isäntien prosenttiosuus koneiden käyttämien solmujen määrä. Jotta strategia toimisi, sen on oltava käytössä ja määritetty Ironic käsittelemään virran jaksotusta solmuissa.
Strategian parametrit
parametri
tyyppi
oletuksena
описание
vapaa_käytetty_prosentti
numero
10.0
vapaiden laskentasolmujen lukumäärän suhde virtuaalikoneita sisältävien laskentasolmujen määrään
min_free_hosts_num
Int
1
vähimmäismäärä ilmaisia laskentasolmuja
Pilvessä on oltava vähintään kaksi solmua. Käytetty menetelmä on muuttaa solmun tehotilaa (change_node_power_state). Strategia ei vaadi mittareiden keräämistä.
Palvelimen yhdistäminen - minimoi laskennan solmujen lukumäärä (konsolidointi). Siinä on kaksi strategiaa: Basic Offline Server Consolidation ja VM Workload Consolidation Strategy.
Basic Offline Server Consolidation -strategia minimoi käytettävien palvelimien kokonaismäärän ja minimoi myös siirtojen määrän.
Perusstrategia edellyttää seuraavia mittareita:
mittareita
palvelu
laajennuksia
kommentti
compute.node.cpu.percent
ei mitään
cpu_util
ei mitään
Strategian parametrit: migration_attempts - yhdistelmien määrä mahdollisten sammutusehdokkaiden etsimiseksi (oletus, 0, ei rajoituksia), ajanjakso - aikaväli sekunneissa staattisen koosteen saamiseksi metriikkatietolähteestä (oletus, 700).
Käytetyt menetelmät: migraatio, nova-palvelun tilan muuttaminen (change_nova_service_state).
VM Workload Consolidation Strategy perustuu ensisovitus-heuristiikkaan, joka keskittyy mitattuun suorittimen kuormitukseen ja yrittää minimoida solmut, joilla on liian paljon tai liian vähän kuormitusta resurssikapasiteettirajoitusten vuoksi. Tämä strategia tarjoaa ratkaisun, joka johtaa tehokkaampaan klusteriresurssien käyttöön seuraavien neljän vaiheen avulla:
- Purkuvaihe - ylikäytettyjen resurssien käsittely;
- Konsolidointivaihe – vajaakäyttöisten resurssien käsittely;
- Ratkaisun optimointi - siirtymien määrän vähentäminen;
- Käyttämättömien laskentasolmujen poistaminen käytöstä.
Strategia edellyttää seuraavia mittareita:
mittareita
palvelu
laajennuksia
kommentti
muisti
ei mitään
disk.root.size
ei mitään
Seuraavat tiedot ovat valinnaisia, mutta ne parantavat strategian tarkkuutta, jos ne ovat saatavilla:
mittareita
palvelu
laajennuksia
kommentti
muisti.asukas
ei mitään
cpu_util
ei mitään
Strategian parametrit: jakso — aikaväli sekunteina staattisen koosteen saamiseksi metriikkatietolähteestä (oletus, 3600).
Käyttää samoja menetelmiä kuin edellinen strategia. Lisätietoja .
Työkuormien tasapainotus — Tasapainottaa työtaakkaa laskentasolmujen välillä. Tavoitteella on kolme strategiaa: Työkuorman tasapainon siirtostrategia, Työkuorman vakauttaminen, Tallennuskapasiteetin tasapainostrategia.
Workload Balance Migration Strategy suorittaa virtuaalikoneen siirrot isäntävirtuaalikoneen työkuorman perusteella. Siirtopäätös tehdään aina, kun solmun prosessorin tai RAM:n käyttöaste ylittää määritetyn kynnyksen. Tässä tapauksessa siirretyn virtuaalikoneen tulisi tuoda solmu lähemmäksi kaikkien solmujen keskimääräistä työmäärää.
Vaatimukset
- Fyysisten prosessorien käyttö;
- Vähintään kaksi fyysistä laskentasolmua;
- Asennettu ja konfiguroitu Ceilometer-komponentti - ceilometer-agent-compute, joka toimii kussakin laskentasolmussa, ja Ceilometer API sekä kerätä seuraavat tiedot:
mittareita
palvelu
laajennuksia
kommentti
cpu_util
ei mitään
muisti.asukas
ei mitään
Strategian parametrit:
parametri
tyyppi
oletuksena
описание
mittarit
jono
'cpu_util'
Taustalla olevat mittarit ovat: 'cpu_util', 'memory.resident'.
kynnys
numero
25.0
Siirron työmäärän kynnys.
aika
numero
300
Kumulatiivinen aikajakso Celometer.
Käytetty menetelmä on migraatio.
Työkuorman vakauttaminen on strategia, jonka tarkoituksena on vakauttaa työkuormaa reaaliaikaisen migraation avulla. Strategia perustuu standardipoikkeamaalgoritmiin ja määrittää, onko klusterissa ruuhkaa ja reagoi siihen käynnistämällä koneen migraation klusterin vakauttamiseksi.
Vaatimukset
- Fyysisten prosessorien käyttö;
- Vähintään kaksi fyysistä laskentasolmua;
- Asennettu ja konfiguroitu Ceilometer-komponentti - ceilometer-agent-compute, joka toimii kussakin laskentasolmussa, ja Ceilometer API sekä kerätä seuraavat tiedot:
mittareita
palvelu
laajennuksia
kommentti
cpu_util
ei mitään
muisti.asukas
ei mitään
Storage Capacity Balance Strategy (strategia toteutettu Queensista alkaen) - strategia siirtää levyjä Cinder-poolien kuormituksesta riippuen. Siirtopäätös tehdään aina, kun poolin käyttöaste ylittää tietyn kynnyksen. Siirrettävän levyn pitäisi tuoda pooli lähemmäksi kaikkien Cinder-poolien keskimääräistä kuormitusta.
Vaatimukset ja rajoitukset
- Vähintään kaksi Cinder-allasta;
- Mahdollisuus levyn siirtoon.
- Klusteritietomalli - Cinder-klusterin tietomallin kerääjä.
Strategian parametrit:
parametri
tyyppi
oletuksena
описание
volume_threshold
numero
80.0
Levyjen kynnysarvo tilavuuksien tasapainottamiseksi.
Käytetty menetelmä on levyn siirto (volume_migrate).
Noisy Neighbor – Tunnista ja siirrä "meluisa naapuri" – matalan prioriteetin virtuaalikone, joka vaikuttaa negatiivisesti korkean prioriteetin virtuaalikoneen suorituskykyyn IPC:n suhteen käyttämällä liikaa viime tason välimuistia. Oma strategia: Noisy Neighbor (käytetty strategiaparametri on cache_threshold (oletusarvo on 35), kun suorituskyky putoaa määritettyyn arvoon, siirto aloitetaan. Jotta strategia toimisi, käytössä LLC (Last Level Cache) -mittarit, uusin Intel-palvelin CMT-tuella, sekä kerätä seuraavat tiedot:
mittareita
palvelu
laajennuksia
kommentti
cpu_l3_cache
ei mitään
Intel vaaditaan .
Klusteritietomalli (oletus): Nova-klusteritietomallin kerääjä. Käytetty menetelmä on migraatio.
Tämän tavoitteen saavuttaminen Dashboardin kautta ei ole täysin toteutettu Queensissa.
Lämpöoptimointi — Optimoi lämpötilajärjestelmä. Poistoilman lämpötila on yksi tärkeimmistä lämpötelemetriajärjestelmistä palvelimen lämmön/työkuormituksen tilan mittaamiseksi. Kohteessa on yksi strategia, ulostulolämpötilaan perustuva strategia, joka päättää siirtää työkuormat lämpösuotuisiin isänteihin (alhaisin ulostulolämpötila), kun lähdeisäntien ulostulolämpötila saavuttaa konfiguroitavan kynnyksen.
Jotta strategia toimisi, tarvitset palvelimen, johon on asennettu ja määritetty Intel Power Node Manager , sekä kerätä seuraavat tiedot:
mittareita
palvelu
laajennuksia
kommentti
hardware.ipmi.node.outlet_temperature
IPMI
Strategian parametrit:
parametri
tyyppi
oletuksena
описание
kynnys
numero
35.0
Lämpötilakynnys siirtymiselle.
aika
numero
30
Aikaväli sekunteina tilastollisen koosteen saamiseksi metritietolähteestä.
Käytetty menetelmä on migraatio.
Ilmavirran optimointi — optimoida ilmanvaihtotila. Oma strategia - Uniform Airflow reaaliaikaista siirtoa käyttäen. Strategia laukaisee virtuaalikoneen siirron aina, kun palvelimen tuulettimen ilmavirta ylittää tietyn kynnyksen.
Jotta strategia toimisi, tarvitset:
- Laitteisto: laskentasolmut < tukevat NodeManager 3.0:aa;
- Vähintään kaksi laskentasolmua;
- Kuhunkin laskentasolmuun asennettu ja konfiguroitu ceilometer-agent-compute ja Ceilometer API -komponentti, joka voi onnistuneesti raportoida mittareita, kuten ilmavirran, järjestelmän tehon ja tulolämpötilan:
mittareita
palvelu
laajennuksia
kommentti
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Jotta strategia toimisi, tarvitset palvelimen, johon on asennettu ja määritetty Intel Power Node Manager 3.0 tai uudempi.
Rajoitukset: Konseptia ei ole tarkoitettu tuotantoon.
Tätä algoritmia ehdotetaan käytettäväksi jatkuvien auditointien kanssa, koska vain yksi virtuaalikone suunnitellaan siirrettäväksi per iteraatio.
Elävät siirrot ovat mahdollisia.
Strategian parametrit:
parametri
tyyppi
oletuksena
описание
threshold_airflow
numero
400.0
Siirtymäyksikön ilmavirran kynnys on 0.1CFM
threshold_inlet_t
numero
28.0
Sisääntulon lämpötilan kynnys siirtopäätöstä varten
kynnysteho
numero
350.0
Järjestelmän tehon kynnys siirtopäätökselle
aika
numero
30
Aikaväli sekunteina tilastollisen koosteen saamiseksi metritietolähteestä.
Käytetty menetelmä on migraatio.
Laitteiston ylläpito - laitteiston huolto. Tähän tavoitteeseen liittyvä strategia on Zone migration. Strategia on työkalu virtuaalikoneiden ja levyjen tehokkaaseen automaattiseen ja minimaaliseen migraatioon laitteiston ylläpidon tarpeessa. Strategia rakentaa painojen mukaan toimintasuunnitelman: enemmän painoarvoa saava toimenpidekokonaisuus suunnitellaan ennen muita. On olemassa kaksi konfigurointivaihtoehtoa: action_weights ja rinnakkain.
Rajoitukset: toimintojen painot ja rinnakkaisasetukset on määritettävä.
Strategian parametrit:
parametri
tyyppi
oletuksena
описание
compute_nodes
ryhmä
Ei eristetty
Laske solmut siirtoa varten.
varastointialtaat
ryhmä
Ei eristetty
Tallennussolmut siirtoa varten.
rinnakkainen_yhteensä
kokonaisluku
6
Rinnakkain suoritettavien toimintojen kokonaismäärä.
parallel_per_node
kokonaisluku
2
Rinnakkaisten toimintojen määrä kullekin laskentasolmulle.
parallel_per_pool
kokonaisluku
2
Rinnakkain suoritettujen toimintojen määrä kullekin tallennusvarastolle.
prioriteetti
objekti
Ei eristetty
Prioriteettiluettelo virtuaalikoneita ja levyjä varten.
kanssa_liitetyt_volume
boolean
Väärä
False—virtuaaliset koneet siirretään, kun kaikki levyt on siirretty. Totta – virtuaaliset koneet siirretään, kun kaikki kytketyt levyt on siirretty.
Laskentasolmujen joukon elementit:
parametri
tyyppi
oletuksena
описание
src_node
jono
Ei eristetty
Laskentasolmu, josta virtuaalikoneita siirretään (pakollinen).
dst_node
jono
Ei eristetty
Laske solmu, johon virtuaalikoneet siirtyvät.
Tallennussolmutaulukon elementit:
parametri
tyyppi
oletuksena
описание
src_pool
jono
Ei eristetty
Tallennusvarasto, josta levyjä siirretään (pakollinen).
dst_pool
jono
Ei eristetty
Tallennusvarasto, johon levyt siirretään.
src_type
jono
Ei eristetty
Alkuperäinen levytyyppi (pakollinen).
dst_type
jono
Ei eristetty
Tuloksena oleva levytyyppi (pakollinen).
Objektin prioriteettielementit:
parametri
tyyppi
oletuksena
описание
projekti
ryhmä
Ei eristetty
Projektien nimet.
compute_node
ryhmä
Ei eristetty
Laske solmujen nimet.
varaston_allas
ryhmä
Ei eristetty
Tallennuspoolien nimet.
laskea
ENUM
Ei eristetty
Virtuaalikoneen parametrit ["vcpu_num", "mem_size", "disk_size", "created_at"].
Levytila
ENUM
Ei eristetty
Levyn parametrit ["size", "created_at"].
Käytetyt menetelmät ovat virtuaalikoneen siirto, levyn siirto.
Luokittelematon - lisätavoite, jota käytetään helpottamaan strategian kehittämisprosessia. Ei sisällä määrityksiä, ja sitä voidaan käyttää aina, kun strategiaa ei ole vielä liitetty olemassa olevaan tavoitteeseen. Tätä tavoitetta voidaan käyttää myös siirtymäkohtana. Tähän tavoitteeseen liittyvä strategia on Actuator.
Uuden tavoitteen luominen
Watcher Decision Engine sisältää "ulkoisen tavoitteen" liitännäisen, jonka avulla voidaan integroida ulkoinen tavoite, joka voidaan saavuttaa strategian avulla.
Ennen kuin luot uuden tavoitteen, sinun tulee varmistaa, etteivät olemassa olevat tavoitteet täytä tarpeitasi.
Luodaan uutta laajennusta
Uuden kohteen luomiseksi sinun tulee: laajentaa kohdeluokkaa, toteuttaa luokkametodi hanki_nimi() palauttaaksesi luotavan uuden kohteen yksilöllisen tunnuksen. Tämän yksilöllisen tunnisteen on vastattava myöhemmin ilmoittamaasi aloituspisteen nimeä.
Seuraavaksi sinun on toteutettava luokkamenetelmä hanki_näyttönimi() palauttaaksesi luotavan kohteen käännetyn näyttönimen (älä käytä muuttujaa käännetyn merkkijonon palauttamiseen, jotta käännöstyökalu voi kerätä sen automaattisesti.).
Toteuta luokkametodi get_translable_display_name()palauttaaksesi uuden kohteen käännösavaimen (itse asiassa englanninkielisen näyttönimen). Palautusarvon on vastattava merkkijonoa, joka on käännetty muotoon get_display_name().
Toteuta hänen menetelmänsä get_efficiacy_specification()palauttaaksesi tavoitteesi tehokkuusmäärityksen. Get_efficiacy_specification()-metodi palauttaa Watcherin toimittaman Unclassified()-instanssin. Tämä suorituskykyspesifikaatio on hyödyllinen tavoitteesi kehittämisprosessissa, koska se vastaa tyhjää määritystä.
→
Watcher-arkkitehtuuri (lisätietoja) ).
Компоненты
Watcher API - komponentti, joka toteuttaa Watcherin tarjoaman REST API:n. Vuorovaikutusmekanismit: CLI, Horizon-laajennus, Python SDK.
Watcher DB — Watcher-tietokanta.
Watcher Applier — komponentti, joka toteuttaa Watcher Decision Engine -komponentin luoman toimintasuunnitelman.
Watcher Decision Engine - Komponentti, joka vastaa mahdollisten optimointitoimenpiteiden laskemisesta tarkastuksen tavoitteen saavuttamiseksi. Jos strategiaa ei ole määritelty, komponentti valitsee itsenäisesti sopivimman.
Watcher Metrics -julkaisija - Komponentti, joka kerää ja laskee joitain mittareita tai tapahtumia ja julkaisee ne CEP-päätepisteeseen. Komponentin toiminnallisuuden voi tarjota myös Ceilometer-julkaisija.
Complex Event Processing (CEP) -moottori — moottori monimutkaiseen tapahtumien käsittelyyn. Suorituskykysyistä useita CEP Engine -esiintymiä voi olla käynnissä samanaikaisesti, joista jokainen käsittelee tietyntyyppistä mittaria/tapahtumaa. Watcher-järjestelmässä CEP laukaisee kahden tyyppisiä toimia: - tallentaa vastaavat tapahtumat / mittarit aikasarjatietokantaan; - lähettää asianmukaiset tapahtumat Watcher Decision Enginelle, kun tämä tapahtuma voi vaikuttaa nykyisen optimointistrategian tulokseen, koska Openstack-klusteri ei ole staattinen järjestelmä.
Komponentit toimivat vuorovaikutuksessa AMQP-protokollan avulla.
→
Vuorovaikutussuunnitelma Watcherin kanssa
Watcher testitulokset
- Optimointi - Toimintasuunnitelmat 500 -sivulla (sekä puhtaissa Queensissa että Tionix-moduuleilla varustetussa telineessä) se tulee näkyviin vasta auditoinnin käynnistämisen ja toimintasuunnitelman luomisen jälkeen, tyhjä avautuu normaalisti.
- Action details -välilehdellä on virheitä, tarkastuksen tavoitetta ja strategiaa ei ole mahdollista saada (sekä puhtaissa Queensissa että Tionix-moduuleilla varustetussa telineessä).
- Dummy (testi) -tarkoituksessa tehdyt auditoinnit luodaan ja käynnistetään normaalisti, toimintasuunnitelmat luodaan.
- Luokittelemattoman tavoitteen tarkastuksia ei luoda, koska tavoite ei ole toimiva ja se on tarkoitettu välimäärittelyyn uusia strategioita luotaessa.
- Työkuorman tasapainottamista (Storage Capacity Balancing Strategia) koskevat auditoinnit luodaan onnistuneesti, mutta toimintasuunnitelmaa ei luoda. Tallennusvaraston optimointia ei tarvita.
- Työkuorman tasapainotustavoitteen (Työkuorman tasapainotusstrategian) tarkastukset on luotu onnistuneesti, mutta toimintasuunnitelmaa ei luoda.
- Työkuormituksen tasapainottamisen (työkuorman tasapainotusstrategian) tarkastukset epäonnistuvat.
- Noisy Neighbor -kohteen auditoinnit on luotu onnistuneesti, mutta toimintasuunnitelmaa ei luoda.
- Laitteiston ylläpitoa varten tehdyt auditoinnit luodaan onnistuneesti, toimintasuunnitelmaa ei generoida kokonaisuudessaan (suoritusindikaattorit luodaan, mutta itse toimintoluetteloa ei luoda).
- Muokkaukset nova.conf-konfiguraatioissa (oletusosiossa compute_monitors = cpu.virt_driver) laskenta- ja ohjaussolmuissa eivät korjaa virheitä.
- Myös palvelimen yhdistämiseen (perusstrategia) kohdistetut tarkastukset epäonnistuvat.
- Palvelinkonsolidointia (VM-työkuormien konsolidointistrategiaa) varten tehtävät tarkastukset epäonnistuvat virheen vuoksi. Lokeissa on virhe lähdetietojen hankinnassa. Keskustelua virheestä erityisesti .
Yritimme määrittää Watcherin asetustiedostossa (se ei auttanut - kaikilla optimointisivuilla tapahtuneen virheen seurauksena asetustiedoston alkuperäiseen sisältöön paluu ei korjaa tilannetta): [watcher_strategies.basic] tietolähde = korkeusmittari, gnocchi - Energiansäästötarkastukset epäonnistuvat. Lokien perusteella ongelmana on edelleen Ironicin puuttuminen; se ei toimi ilman paljaat huoltoa.
- Lämpöoptimoinnin tarkastukset epäonnistuvat. Jäljitys on sama kuin Server Consolidation (VM-työkuormien konsolidointistrategia) (lähdetietovirhe)
- Ilmavirran optimointia varten tehtävät tarkastukset epäonnistuvat virheen vuoksi.
Myös seuraavat tarkastuksen suorittamisen virheet havaitaan. Traceback Decision-engine.log-lokeissa (klusterin tilaa ei ole määritetty).
→ Keskustelua virheestä
Johtopäätös
Kaksi kuukautta kestäneen tutkimuksemme tuloksena oli yksiselitteinen johtopäätös, että täysimittaisen, toimivan kuormantasausjärjestelmän saamiseksi joudumme tässä osassa työskentelemään tiiviisti Openstack-alustan työkalujen jalostamisen kanssa.
Watcher on osoittautunut vakavaksi ja nopeasti kehittyväksi tuotteeksi, jolla on valtava potentiaali ja jonka täysi hyödyntäminen vaatii paljon vakavaa työtä.
Mutta lisää tästä sarjan seuraavissa artikkeleissa.
Lähde: will.com