Balansiranje opterećenja u Openstacku

U velikim oblačnim sustavima posebno je akutno pitanje automatskog balansiranja ili izravnavanja opterećenja računalnih resursa. Tionix (razvojnik i operater usluga u oblaku, dio grupe tvrtki Rostelecom) također se pobrinuo za ovo pitanje.

A kako nam je glavna razvojna platforma Openstack, a mi smo, kao i svi ljudi, lijeni, odlučeno je odabrati neki gotov modul koji je već uključen u platformu. Naš izbor je pao na Watcher kojeg smo odlučili koristiti za svoje potrebe.
Balansiranje opterećenja u Openstacku
Prvo, pogledajmo pojmove i definicije.

Pojmovi i definicije

Cilj je čovjeku čitljiv, vidljiv i mjerljiv krajnji rezultat koji se mora postići. Postoji jedna ili više strategija za postizanje svakog cilja. Strategija je implementacija algoritma koji je sposoban pronaći rješenje za zadani cilj.

Akcijski je elementarni zadatak koji mijenja trenutno stanje ciljanog upravljanog resursa OpenStack klastera, kao što su: migracija virtualnog stroja (migracija), promjena stanja napajanja čvora (change_node_power_state), promjena stanja usluge nova (change_nova_service_state ), mijenjanje okusa (resize), registriranje NOP poruka (nop), nedostatak radnje određeno vrijeme - pauza (sleep), prijenos diska (volume_migrate).

Plan akcije - određeni tijek radnji koje se provode određenim redoslijedom kako bi se postigao određeni cilj. Akcijski plan također sadrži izmjereni globalni učinak sa skupom pokazatelja učinka. Nakon uspješne revizije Watcher generira akcijski plan, na temelju kojeg korištena strategija pronalazi rješenje za postizanje cilja. Akcijski plan sastoji se od popisa uzastopnih radnji.

Revizija je zahtjev za optimizaciju klastera. Optimizacija se provodi kako bi se postigao jedan cilj u zadanom klasteru. Za svaku uspješnu reviziju, Watcher generira akcijski plan.

Opseg revizije je skup resursa unutar kojih se provodi revizija (zone dostupnosti, agregatori čvorova, pojedinačni računalni čvorovi ili čvorovi za pohranu itd.). Opseg revizije definiran je u svakom predlošku. Ako opseg revizije nije naveden, revidira se cijeli klaster.

Predložak revizije — spremljen skup postavki za pokretanje revizije. Predlošci su potrebni za pokretanje revizija više puta s istim postavkama. Predložak mora nužno sadržavati svrhu revizije; ako strategije nisu navedene, tada se odabiru najprikladnije postojeće strategije.

Klastera je skup fizičkih strojeva koji pružaju računalne, pohranjivačke i mrežne resurse i kojima upravlja isti OpenStack upravljački čvor.

Model podataka klastera (CDM) je logičan prikaz trenutnog stanja i topologije resursa kojima upravlja klaster.

Indikator učinkovitosti - pokazatelj koji pokazuje kako se rješenje stvoreno pomoću ove strategije izvodi. Pokazatelji učinka specifični su za određeni cilj i obično se koriste za izračun globalne učinkovitosti rezultirajućeg akcijskog plana.

Specifikacija učinkovitosti je skup specifičnih značajki povezanih sa svakim ciljem koji definira različite pokazatelje uspješnosti koje strategija za postizanje odgovarajućeg cilja mora postići u svom rješenju. Doista, svako rješenje predloženo strategijom bit će provjereno u odnosu na specifikaciju prije izračuna njegove globalne učinkovitosti.

Motor za bodovanje je izvršna datoteka koja ima dobro definirane ulaze, dobro definirane izlaze i obavlja čisto matematički zadatak. Na ovaj način izračun je neovisan o okruženju u kojem se izvodi—dat će isti rezultat bilo gdje.

Watcher planer - dio mehanizma za donošenje odluka Watchera. Ovaj modul preuzima skup radnji generiranih strategijom i stvara plan tijeka rada koji specificira kako rasporediti ove različite radnje u vremenu i za svaku radnju, koji su preduvjeti.

Ciljevi i strategije promatrača

Cilj
strategija

Lažni gol
Dummy strategija 

Lažna strategija koja koristi uzorke mehanizama za bodovanje

Dummy strategija s promjenom veličine

Štednja energije
Strategija uštede energije

Konsolidacija poslužitelja
Osnovna izvanmrežna konsolidacija poslužitelja

Strategija konsolidacije radnog opterećenja VM-a

Uravnoteženje radnog opterećenja
Strategija migracije ravnoteže radnog opterećenja

Strategija ravnoteže kapaciteta pohrane

Stabilizacija radnog opterećenja

Bučni susjed
Bučni susjed

Toplinska optimizacija
Strategija temeljena na izlaznoj temperaturi

Optimizacija protoka zraka
Ujednačena strategija migracije protoka zraka

Održavanje hardvera
Zonska migracija

Neklasificirano
Pokretač

Lažni gol — rezervirani cilj koji se koristi za potrebe testiranja.

Povezane strategije: Dummy strategija, Dummy strategija koja koristi uzorke bodovnih mehanizama i Dummy strategija s promjenom veličine. Lažna strategija je lažna strategija koja se koristi za testiranje integracije putem Tempesta. Ova strategija ne pruža nikakvu korisnu optimizaciju, njena jedina svrha je korištenje Tempest testova.

Dummy strategija pomoću uzorka Scoring Engines - strategija je slična prethodnoj, jedina razlika je korištenje oglednog "scoring enginea" koji provodi izračune koristeći metode strojnog učenja.

Dummy strategija s promjenom veličine - strategija je slična prethodnoj, jedina razlika je korištenje promjene okusa (migracija i promjena veličine).

Ne koristi se u proizvodnji.

Štednja energije — smanjiti potrošnju energije. Strategija uštede energije ovog cilja, zajedno sa strategijom konsolidacije radnog opterećenja VM (konsolidacija poslužitelja), sposobna je za značajke dinamičkog upravljanja energijom (DPM) koje štede energiju dinamičkom konsolidacijom radnih opterećenja čak i tijekom razdoblja niske iskorištenosti resursa: virtualni strojevi se premještaju na manje čvorova , a nepotrebni čvorovi su onemogućeni. Nakon konsolidacije, strategija nudi odluku o uključivanju/isključivanju čvorova u skladu s navedenim parametrima: “min_free_hosts_num” - broj slobodnih omogućenih čvorova koji čekaju na učitavanje i “free_used_percent” - postotak slobodnih omogućenih hostova prema broj čvorova koje zauzimaju strojevi. Mora postojati da bi strategija funkcionirala omogućeno i konfigurirano Ironic za upravljanje ciklusima napajanja na čvorovima.

Parametri strategije

parametar
тип
prema zadanom
описание

besplatno_iskorišteno_postotak
Broj
10.0
omjer broja slobodnih računalnih čvorova prema broju računalnih čvorova s ​​virtualnim strojevima

min_free_hosts_num
Int
1
minimalan broj slobodnih računalnih čvorova

Oblak mora imati najmanje dva čvora. Korištena metoda je promjena stanja napajanja čvora (change_node_power_state). Strategija ne zahtijeva prikupljanje metrike.

Konsolidacija poslužitelja - smanjite broj računalnih čvorova (konsolidacija). Ima dvije strategije: Basic Offline Server Consolidation i VM Workload Consolidation Strategy.

Strategija Basic Offline Server Consolidation minimizira ukupan broj korištenih poslužitelja i također minimizira broj migracija.

Osnovna strategija zahtijeva sljedeće pokazatelje:

metrika
servis
dodaci
komentar

compute.node.cpu.percent
ceilometar
nijedan
 

cpu_util
ceilometar
nijedan
 

Parametri strategije: migration_attempts - broj kombinacija za traženje potencijalnih kandidata za gašenje (zadano, 0, bez ograničenja), period - vremenski interval u sekundama za dobivanje statičke agregacije iz izvora metričkih podataka (zadano, 700).

Korištene metode: migracija, promjena stanja usluge nova (change_nova_service_state).

Strategija konsolidacije radnog opterećenja VM-a temelji se na heuristici prvog uklapanja koja se fokusira na izmjereno opterećenje CPU-a i pokušava minimizirati čvorove koji imaju previše ili premalo opterećenja s obzirom na ograničenja kapaciteta resursa. Ova strategija pruža rješenje koje rezultira učinkovitijom upotrebom resursa klastera pomoću sljedeća četiri koraka:

  1. Faza rasterećenja - obrada prekomjerno iskorištenih resursa;
  2. Faza konsolidacije - rukovanje nedovoljno iskorištenim resursima;
  3. Optimizacija rješenja - smanjenje broja migracija;
  4. Onemogućavanje neiskorištenih računalnih čvorova.

Strategija zahtijeva sljedeće metrike:

metrika
servis
dodaci
komentar

memorija
ceilometar
nijedan
 

disk.korijen.veličina
ceilometar
nijedan
 

Sljedeći podaci nisu obavezni, ali će poboljšati točnost strategije ako su dostupni:

metrika
servis
dodaci
komentar

memorija.stanovnik
ceilometar
nijedan
 

cpu_util
ceilometar
nijedan
 

Parametri strategije: razdoblje — vremenski interval u sekundama za dobivanje statičke agregacije iz izvora metričkih podataka (zadano, 3600).

Koristi iste metode kao prethodna strategija. Više detalja здесь.

Uravnoteženje radnog opterećenja — uravnotežiti radno opterećenje između računalnih čvorova. Cilj ima tri strategije: strategija migracije ravnoteže radnog opterećenja, stabilizacija radnog opterećenja, strategija ravnoteže kapaciteta pohrane.

Workload Balance Migration Strategy pokreće migracije virtualnog stroja na temelju radnog opterećenja glavnog virtualnog stroja. Odluka o migraciji se donosi svaki put kada % CPU ili RAM iskorištenja čvora premaši navedeni prag. U ovom slučaju, premješteni virtualni stroj trebao bi približiti čvor prosječnom opterećenju svih čvorova.

Zahtjevi

  • Korištenje fizičkih procesora;
  • Najmanje dva fizička računalna čvora;
  • Instalirana je i konfigurirana komponenta Ceilometer - ceilometer-agent-compute, koja radi na svakom računskom čvoru, i Ceilometer API, kao i prikupljanje sljedećih metrika:

metrika
servis
dodaci
komentar

cpu_util
ceilometar
nijedan
 

memorija.stanovnik
ceilometar
nijedan
 

Parametri strategije:

parametar
тип
prema zadanom
описание

metrika
Niz
'cpu_util'
Temeljne metrike su: 'cpu_util', 'memory.resident'.

prag
Broj
25.0
Prag radnog opterećenja za migraciju.

razdoblje
Broj
300
Kumulativno vremensko razdoblje Ceilometer.

Metoda koja se koristi je migracija.

Stabilizacija radnog opterećenja strategija je usmjerena na stabilizaciju radnog opterećenja korištenjem žive migracije. Strategija se temelji na algoritmu standardne devijacije i utvrđuje postoji li zagušenje u klasteru i reagira na to pokretanjem migracije stroja za stabilizaciju klastera.

Zahtjevi

  • Korištenje fizičkih procesora;
  • Najmanje dva fizička računalna čvora;
  • Instalirana je i konfigurirana komponenta Ceilometer - ceilometer-agent-compute, koja radi na svakom računskom čvoru, i Ceilometer API, kao i prikupljanje sljedećih metrika:

metrika
servis
dodaci
komentar

cpu_util
ceilometar
nijedan
 

memorija.stanovnik
ceilometar
nijedan
 

Strategija ravnoteže kapaciteta pohrane (strategija implementirana počevši od Queensa) - strategija prenosi diskove ovisno o opterećenju Cinder skupova. Odluka o prijenosu se donosi svaki put kada stopa iskorištenosti bazena premaši određeni prag. Disk koji se pomiče trebao bi približiti bazen prosječnom opterećenju svih Cinder bazena.

Zahtjevi i ograničenja

  • Minimalno dva Cinder bazena;
  • Mogućnost migracije diska.
  • Model podataka klastera - sakupljač modela podataka klastera Cinder.

Parametri strategije:

parametar
тип
prema zadanom
описание

volumen_prag
Broj
80.0
Vrijednost praga diskova za balansiranje volumena.

Korištena metoda je migracija diska (volume_migrate).

Noisy Neighbor - Identificirajte i migrirajte "bučnog susjeda" - virtualni stroj niskog prioriteta koji negativno utječe na performanse virtualnog stroja visokog prioriteta u smislu IPC-a pretjeranom upotrebom predmemorije zadnje razine. Vlastita strategija: Noisy Neighbor (korišteni parametar strategije je cache_threshold (zadana vrijednost je 35), kada izvedba padne na navedenu vrijednost, pokreće se migracija. Da bi strategija radila, omogućeno LLC (Last Level Cache) metrika, najnoviji Intelov poslužitelj s CMT podrškom, kao i prikupljanje sljedećih metrika:

metrika
servis
dodaci
komentar

cpu_l3_cache
ceilometar
nijedan
Potreban Intel CMT.

Model podataka klastera (zadano): Nova sakupljač modela podataka klastera. Metoda koja se koristi je migracija.

Rad s ovim ciljem putem nadzorne ploče nije u potpunosti implementiran u Queensu.

Toplinska optimizacija — optimizirati temperaturni režim. Izlazna temperatura (ispušnog zraka) jedan je od važnih toplinskih telemetrijskih sustava za mjerenje statusa topline/radnog opterećenja poslužitelja. Cilj ima jednu strategiju, strategiju temeljenu na izlaznoj temperaturi, koja odlučuje premjestiti radna opterećenja na toplinski povoljne hostove (najniža izlazna temperatura) kada izlazna temperatura izvornih hostova dosegne konfigurabilni prag.

Da bi strategija funkcionirala, potreban vam je poslužitelj s instaliranim i konfiguriranim Intel Power Node Managerom 3.0 ili noviji, kao i prikupljanje sljedećih metrika:

metrika
servis
dodaci
komentar

hardware.ipmi.node.outlet_temperature
ceilometar
IPMI
 

Parametri strategije:

parametar
тип
prema zadanom
описание

prag
Broj
35.0
Temperaturni prag za migraciju.

razdoblje
Broj
30
Vremenski interval, u sekundama, za dobivanje statističke agregacije iz izvora metričkih podataka.

Metoda koja se koristi je migracija.

Optimizacija protoka zraka — optimizirajte način ventilacije. Vlastita strategija - Ujednačen protok zraka korištenjem žive migracije. Strategija pokreće migraciju virtualnog stroja kad god protok zraka iz ventilatora poslužitelja prijeđe određeni prag.

Da bi strategija funkcionirala potrebno vam je:

  • Hardver: računalni čvorovi < podržavaju NodeManager 3.0;
  • Najmanje dva računalna čvora;
  • Ceilometer-agent-compute i Ceilometer API komponenta instalirana i konfigurirana na svakom računskom čvoru, koja može uspješno prijaviti metrike kao što su protok zraka, snaga sustava, ulazna temperatura:

metrika
servis
dodaci
komentar

hardver.ipmi.čvor.protok zraka
ceilometar
IPMI
 

hardver.ipmi.čvor.temperatura
ceilometar
IPMI
 

hardver.ipmi.čvor.snaga
ceilometar
IPMI
 

Da bi strategija funkcionirala, potreban vam je poslužitelj s instaliranim i konfiguriranim Intel Power Node Manager 3.0 ili novijim.

Ograničenja: Koncept nije namijenjen za proizvodnju.

Predlaže se korištenje ovog algoritma s kontinuiranim revizijama, budući da se samo jedno virtualno računalo planira migrirati po iteraciji.

Moguće su žive migracije.

Parametri strategije:

parametar
тип
prema zadanom
описание

prag_strujanja zraka
Broj
400.0
Prag protoka zraka za jedinicu migracije je 0.1 CFM

prag_ulaz_t
Broj
28.0
Prag ulazne temperature za odluku o migraciji

snaga_praga
Broj
350.0
Prag snage sustava za odluku o migraciji

razdoblje
Broj
30
Vremenski interval, u sekundama, za dobivanje statističke agregacije iz izvora metričkih podataka.

Metoda koja se koristi je migracija.

Održavanje hardvera — održavanje hardvera. Strategija povezana s ovim ciljem je Zonska migracija. Strategija je alat za učinkovitu automatsku i minimalnu migraciju virtualnih strojeva i diskova u slučaju potrebe za održavanjem hardvera. Strategija gradi plan akcije u skladu s težinama: skup radnji koji ima veću težinu planirat će se prije ostalih. Postoje dvije opcije konfiguracije: action_weights i paralelizacija.

Ograničenja: potrebno je konfigurirati težine radnji i paralelizaciju.

Parametri strategije:

parametar
тип
prema zadanom
описание

računski_čvorovi
poredak
nijedan
Računalni čvorovi za migraciju.

skladišni_bazeni
poredak
nijedan
Čvorovi pohrane za migraciju.

paralelno_ukupno
cijeli
6
Ukupan broj aktivnosti koje se moraju izvršiti paralelno.

paralelno_po_čvoru
cijeli
2
Broj radnji izvedenih paralelno za svaki računski čvor.

paralelno_po_bazenu
cijeli
2
Broj radnji izvedenih paralelno za svaki prostor za pohranu.

prioritet
objekt
nijedan
Lista prioriteta za virtualne strojeve i diskove.

sa_priloženim_sveskom
boolean
Lažan
False—virtualni strojevi bit će migrirani nakon što se migriraju svi diskovi. Istina—virtualni strojevi bit će migrirani nakon što se migriraju svi povezani diskovi.

Elementi niza računalnih čvorova:

parametar
тип
prema zadanom
описание

src_čvor
niz
nijedan
Računalni čvor s kojeg se migriraju virtualni strojevi (obavezno).

dst_čvor
niz
nijedan
Izračunajte čvor na koji migriraju virtualni strojevi.

Elementi niza čvorova za pohranu:

parametar
тип
prema zadanom
описание

src_bazen
niz
nijedan
Skup za pohranu iz kojeg se diskovi migriraju (obavezno).

dst_pool
niz
nijedan
Spremište u koje se migriraju diskovi.

tip_src
niz
nijedan
Izvorni tip diska (obavezno).

dst_tip
niz
nijedan
Rezultirajuća vrsta diska (obavezno).

Elementi prioriteta objekta:

parametar
тип
prema zadanom
описание

projekt
poredak
nijedan
Imena projekata.

računski_čvor
poredak
nijedan
Izračunajte nazive čvorova.

skladišni_bazen
poredak
nijedan
Imena spremišta za pohranu.

izračunati
nabrajanje
nijedan
Parametri virtualnog stroja [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].

skladištenje
nabrajanje
nijedan
Parametri diska ["size", "created_at"].

Metode koje se koriste su migracija virtualnog stroja, migracija diska.

Neklasificirano - pomoćni cilj koji se koristi za olakšavanje procesa razvoja strategije. Ne sadrži specifikacije i može se koristiti kad god strategija još nije povezana s postojećim ciljem. Ovaj se cilj također može koristiti kao prijelazna točka. Strategija povezana s ovim ciljem je Actuator.   

Stvaranje novog cilja

Watcher Decision Engine ima sučelje dodatka za "vanjski cilj" koje omogućuje integraciju vanjskog cilja koji se može postići pomoću strategije.

Prije nego što stvorite novi cilj, trebali biste se uvjeriti da postojeći ciljevi ne zadovoljavaju vaše potrebe.

Izrada novog dodatka

Da biste stvorili novi cilj, morate: proširiti ciljnu klasu, implementirati metodu klase get_name() da biste vratili jedinstveni ID novog cilja koji želite stvoriti. Ovaj jedinstveni identifikator mora odgovarati nazivu ulazne točke koju kasnije deklarirate.

Zatim trebate implementirati metodu klase get_display_name() da biste vratili prevedeno ime za prikaz cilja koji želite stvoriti (nemojte koristiti varijablu za vraćanje prevedenog niza tako da ga alat za prevođenje može automatski prikupiti.).

Implementirajte metodu klase get_translatable_display_name()da biste vratili ključ prijevoda (zapravo englesko ime za prikaz) vašeg novog cilja. Povratna vrijednost mora odgovarati nizu prevedenom u get_display_name().

Provedite njegovu metodu get_efficacy_specification()da biste vratili specifikaciju učinkovitosti za vaš cilj. Metoda get_efficacy_specification() vraća Unclassified() instancu koju pruža Watcher. Ova specifikacija izvedbe korisna je u procesu razvoja vašeg cilja jer odgovara praznoj specifikaciji.

Pročitajte više ovdje

Arhitektura promatrača (više detalja) здесь).

Balansiranje opterećenja u Openstacku

Komponente

Balansiranje opterećenja u Openstacku

API promatrača - komponenta koja implementira REST API koju osigurava Watcher. Mehanizmi interakcije: CLI, Horizon plugin, Python SDK.

Promatrač DB — Baza podataka promatrača.

Watcher Applier — komponenta koja implementira izvršenje akcijskog plana kreiranog komponentom Watcher Decision Engine.

Watcher Decision Engine - Komponenta odgovorna za izračunavanje skupa potencijalnih radnji optimizacije za postizanje cilja revizije. Ako strategija nije navedena, komponenta samostalno odabire najprikladniju.

Watcher Metrics Publisher - Komponenta koja prikuplja i izračunava neke metrike ili događaje i objavljuje ih krajnjoj točki CEP-a. Funkcionalnost komponente također može osigurati izdavač Ceilometer.

Motor za obradu složenih događaja (CEP). — mehanizam za složenu obradu događaja. Zbog performansi, može postojati više instanci CEP Enginea koje se izvode istovremeno, a svaka obrađuje određenu vrstu metrike/događaja. U sustavu Watcher, CEP pokreće dvije vrste radnji: - bilježi odgovarajuće događaje / metrike u bazi podataka vremenskih serija; - poslati odgovarajuće događaje u Watcher Decision Engine kada ovaj događaj može utjecati na rezultat trenutne strategije optimizacije, budući da Openstack klaster nije statički sustav.

Komponente međusobno djeluju koristeći AMQP protokol.

Konfiguriranje Watchera

Shema interakcije s Watcherom

Balansiranje opterećenja u Openstacku

Rezultati testa promatrača

  1. Na stranici Optimization - Action plans 500 (i na čistim Queenima i na postolju s Tionix modulima) pojavljuje se tek nakon pokretanja audita i generiranja akcijskog plana, prazan se otvara normalno.
  2. Postoje greške na kartici Action details, nije moguće dobiti cilj revizije i strategiju (i na čistom Queensu i na postolju s Tionix modulima).
  3. Auditi sa svrhom Dummy (test) se kreiraju i pokreću normalno, generiraju se akcijski planovi.
  4. Revizije za Neklasificirani cilj se ne kreiraju jer cilj nije funkcionalan i namijenjen je za međukonfiguraciju pri izradi novih strategija.
  5. Revizije u svrhu balansiranja radnog opterećenja (strategija balansiranja kapaciteta pohrane) su uspješno kreirane, ali se akcijski plan ne generira. Nije potrebna optimizacija skladišnog prostora.
  6. Revizije za cilj uravnoteženja radnog opterećenja (strategija migracije ravnoteže radnog opterećenja) uspješno su stvorene, ali se akcijski plan ne generira.
  7. Revizije za uravnoteženje radnog opterećenja (strategija stabilizacije radnog opterećenja) ne uspijevaju.
  8. Revizije za cilj Noisy Neighbor uspješno su stvorene, ali akcijski plan nije generiran.
  9. Revizije za potrebe održavanja hardvera su uspješno kreirane, akcijski plan nije generiran u cijelosti (generirani su indikatori uspješnosti, ali nije generirana sama lista radnji).
  10. Uređivanja u nova.conf konfiguracijama (u zadanom odjeljku compute_monitors = cpu.virt_driver) na računalnim i kontrolnim čvorovima ne ispravljaju pogreške.
  11. Revizije usmjerene na konsolidaciju poslužitelja (osnovna strategija) također ne uspijevaju.
  12. Revizije u svrhu konsolidacije poslužitelja (strategija konsolidacije radnog opterećenja VM-a) ne uspijevaju s pogreškom. U zapisima postoji pogreška u dobivanju izvornih podataka. Osobito rasprava o pogrešci здесь.
    Pokušali smo navesti Watcher u konfiguracijskoj datoteci (nije pomoglo - kao rezultat pogreške na svim stranicama optimizacije, vraćanje na originalni sadržaj konfiguracijske datoteke ne ispravlja situaciju):

    [watcher_strategies.basic] izvor podataka = mjerač visine, njoki
  13. Revizije za uštedu energije nisu uspjele. Sudeći po logovima, još uvijek je problem nedostatak Ironic-a, neće raditi bez baremetal servisa.
  14. Revizije za toplinsku optimizaciju nisu uspjele. Traceback je isti kao za konsolidaciju poslužitelja (strategija konsolidacije radnog opterećenja VM-a) (pogreška izvornih podataka)
  15. Revizije u svrhu optimizacije protoka zraka ne uspijevaju s pogreškom.

Također se susreću sljedeće pogreške dovršetka revizije. Povratno praćenje u zapisnicima decision-engine.log (stanje klastera nije definirano).

→ Rasprava o pogrešci здесь

Zaključak

Rezultat našeg dvomjesečnog istraživanja bio je nedvosmislen zaključak da ćemo u ovom dijelu morati blisko surađivati ​​na usavršavanju alata za Openstack platformu kako bismo dobili potpuni, radni sustav za uravnoteženje opterećenja.

Watcher se pokazao kao ozbiljan i brzo razvijajući proizvod s ogromnim potencijalom, za čije će potpuno iskorištavanje biti potrebno puno ozbiljnog rada.

Ali više o tome u sljedećim člancima iz serije.

Izvor: www.habr.com

Dodajte komentar