În sistemele cloud mari, problema echilibrării sau nivelării automate a sarcinii resurselor de calcul este deosebit de acută. De această problemă s-a ocupat și Tionix (un dezvoltator și operator de servicii cloud, parte a grupului de companii Rostelecom).
Și, deoarece platforma noastră principală de dezvoltare este Openstack, iar noi, ca toți oamenii, suntem leneși, s-a decis să selectăm un modul gata făcut, care este deja inclus în platformă. Alegerea noastră a căzut pe Watcher, pe care am decis să-l folosim pentru nevoile noastre.
În primul rând, să ne uităm la termeni și definiții.
Termeni și definiții
Scop este un rezultat final care poate fi citit de om, observabil și măsurabil, care trebuie atins. Există una sau mai multe strategii pentru a atinge fiecare obiectiv. O strategie este implementarea unui algoritm care este capabil să găsească o soluție pentru un anumit obiectiv.
Acțiune este o sarcină elementară care modifică starea curentă a resursei gestionate țintă a clusterului OpenStack, cum ar fi: migrarea unei mașini virtuale (migrare), modificarea stării de alimentare a unui nod (change_node_power_state), schimbarea stării serviciului nova (change_nova_service_state) ), schimbarea aromei (redimensionarea), înregistrarea mesajelor NOP (nop), lipsa acțiunii pentru o anumită perioadă de timp - pauză (sleep), transfer de disc (volume_migrate).
Plan de acțiune - un flux specific de acțiuni desfășurate într-o anumită ordine pentru atingerea unui anumit scop. Planul de acțiune conține, de asemenea, performanța globală măsurată cu un set de indicatori de performanță. Un plan de acțiune este generat de Watcher în urma unui audit de succes, în urma căruia strategia utilizată găsește o soluție pentru atingerea obiectivului. Un plan de acțiune constă dintr-o listă de acțiuni secvențiale.
Audit este o solicitare de optimizare a clusterului. Optimizarea este efectuată pentru a atinge un obiectiv într-un anumit cluster. Pentru fiecare audit reușit, Watcher generează un Plan de acțiune.
Domeniul auditului este un set de resurse în cadrul căruia se efectuează auditul (zone de disponibilitate, agregatoare de noduri, noduri de calcul individuale sau noduri de stocare etc.). Sfera de audit este definită în fiecare șablon. Dacă nu este specificat un domeniu de audit, întregul cluster este auditat.
Șablon de audit — un set salvat de setări pentru lansarea unui audit. Sunt necesare șabloane pentru a rula audituri de mai multe ori cu aceleași setări. Modelul trebuie să conțină în mod necesar scopul auditului; dacă strategiile nu sunt specificate, atunci sunt selectate cele mai potrivite strategii existente.
Cluster este o colecție de mașini fizice care oferă resurse de calcul, stocare și rețea și sunt gestionate de același nod de gestionare OpenStack.
Model de date cluster (CDM) este o reprezentare logică a stării curente și a topologiei resurselor gestionate de cluster.
Indicator de eficiență - un indicator care indică modul în care se realizează soluția creată folosind această strategie. Indicatorii de performanță sunt specifici unui anumit obiectiv și sunt utilizați de obicei pentru a calcula eficacitatea globală a planului de acțiune rezultat.
Specificație de eficacitate este un set de caracteristici specifice asociate fiecărui obiectiv care definește diferiții indicatori de performanță pe care o strategie pentru atingerea obiectivului corespunzător trebuie să-i atingă în soluția sa. Într-adevăr, fiecare soluție propusă de strategie va fi verificată în raport cu specificația înainte de a calcula eficiența sa globală.
Motor de scor este un fișier executabil care are intrări bine definite, ieșiri bine definite și îndeplinește o sarcină pur matematică. În acest fel, calculul este independent de mediul în care este efectuat - va da același rezultat oriunde.
Watcher Planner - parte a motorului decizional Watcher. Acest modul preia un set de acțiuni generate de o strategie și creează un plan de flux de lucru care specifică modul de programare a acestor acțiuni diferite în timp și pentru fiecare acțiune, care sunt condițiile preliminare.
Obiectivele și strategiile observatorului
Scop
strategie
Gol fals
Strategie dummy
Strategie inactivă folosind exemple de motoare de scor
Strategie simulată cu redimensionare
Economisirea energiei
Strategia de economisire a energiei
Consolidare server
Consolidare de bază a serverului offline
Strategia de consolidare a sarcinii de lucru VM
Echilibrarea sarcinii de lucru
Strategia de migrare a echilibrului sarcinilor de muncă
Strategia de echilibrare a capacității de stocare
Stabilizarea sarcinii de lucru
Vecinul zgomotos
Vecinul zgomotos
Optimizare termică
Strategie bazată pe temperatura de ieșire
Optimizarea fluxului de aer
Strategie uniformă de migrare a fluxului de aer
Intretinere hardware
Migrarea zonei
neclasificat
Servomotor
Gol fals — obiectiv rezervat care este utilizat în scopuri de testare.
Strategii înrudite: Strategie fictivă, Strategie fictivă folosind exemple de motoare de scor și strategie fictivă cu redimensionare. Strategia dummy este o strategie dummy folosită pentru testarea integrării prin Tempest. Această strategie nu oferă nicio optimizare utilă, singurul scop este utilizarea testelor Tempest.
Strategie inactivă utilizând exemple de motoare de scoring - strategia este similară cu cea anterioară, singura diferență este utilizarea unui eșantion de „motor de scoring” care efectuează calcule folosind metode de învățare automată.
Strategie dumy cu redimensionare - strategia este similară cu cea anterioară, singura diferență este utilizarea modificării aromei (migrare și redimensionare).
Nu este utilizat în producție.
Economisirea energiei - minimizarea consumului de energie. Strategia de economisire a energiei a acestui obiectiv, împreună cu strategia de consolidare a sarcinii de lucru VM (consolidare server), este capabilă de funcții de gestionare dinamică a energiei (DPM) care economisesc energie prin consolidarea dinamică a sarcinilor de lucru chiar și în perioadele de utilizare redusă a resurselor: mașinile virtuale sunt mutate în mai puține noduri. , iar nodurile inutile sunt dezactivate. După consolidare, strategia oferă o decizie privind pornirea/dezactivarea nodurilor în conformitate cu parametrii specificați: „min_free_hosts_num” - numărul de noduri activate libere care așteaptă încărcarea și „free_used_percent” - procentul de gazde activate gratuite pentru numărul de noduri care sunt ocupate de mașini. Pentru ca strategia să funcționeze trebuie să existe a activat și configurat Ironic pentru a gestiona ciclul de alimentare pe noduri.
Parametrii strategiei
parametru
тип
implicit
описание
free_used_percent
Număr
10.0
raportul dintre numărul de noduri de calcul libere și numărul de noduri de calcul cu mașini virtuale
min_free_hosts_num
Int
1
numărul minim de noduri de calcul libere
Cloud-ul trebuie să aibă cel puțin două noduri. Metoda folosită este schimbarea stării de putere a nodului (change_node_power_state). Strategia nu necesită colectarea de valori.
Consolidare server - minimizați numărul de noduri de calcul (consolidare). Are două strategii: Basic Offline Server Consolidation și VM Workload Consolidation Strategy.
Strategia Basic Offline Server Consolidation minimizează numărul total de servere utilizate și, de asemenea, minimizează numărul de migrări.
Strategia de bază necesită următoarele valori:
metrici
serviciu
pluginuri
comentariu
compute.node.cpu.procent
nici unul
cpu_util
nici unul
Parametri de strategie: migration_attempts - numărul de combinații pentru a căuta potențiali candidați pentru oprire (implicit, 0, fără restricții), perioadă - interval de timp în secunde pentru a obține agregarea statică din sursa de date metric (implicit, 700).
Metode utilizate: migrare, schimbarea stării serviciului nova (change_nova_service_state).
Strategia de consolidare a sarcinii de lucru VM se bazează pe o euristică de primă adaptare care se concentrează pe sarcina măsurată a CPU și încearcă să minimizeze nodurile care au încărcare prea mare sau prea mică, având în vedere constrângerile de capacitate a resurselor. Această strategie oferă o soluție care are ca rezultat o utilizare mai eficientă a resurselor clusterului, folosind următorii patru pași:
- Faza de descărcare - prelucrarea resurselor suprautilizate;
- Faza de consolidare - gestionarea resurselor subutilizate;
- Optimizarea solutiei - reducerea numarului de migrari;
- Dezactivarea nodurilor de calcul neutilizate.
Strategia necesită următoarele valori:
metrici
serviciu
pluginuri
comentariu
memorie
nici unul
dimensiunea.rădăcină.disc
nici unul
Următoarele valori sunt opționale, dar vor îmbunătăți acuratețea strategiei dacă sunt disponibile:
metrici
serviciu
pluginuri
comentariu
memorie.rezident
nici unul
cpu_util
nici unul
Parametrii strategiei: perioadă — interval de timp în secunde pentru a obține agregarea statică din sursa de date a metricii (implicit, 3600).
Folosește aceleași metode ca strategia anterioară. Mai multe detalii .
Echilibrarea sarcinii de lucru — echilibrarea sarcinii de lucru între nodurile de calcul. Scopul are trei strategii: Strategia de migrare a echilibrului sarcinii de lucru, Stabilizarea sarcinii de lucru, Strategia de echilibrare a capacității de stocare.
Workload Balance Migration Strategy rulează migrarea mașinilor virtuale bazate pe volumul de lucru al mașinii virtuale gazdă. O decizie de migrare este luată ori de câte ori procentul de utilizare a CPU sau RAM a unui nod depășește pragul specificat. În acest caz, mașina virtuală mutată ar trebui să aducă nodul mai aproape de volumul mediu de lucru al tuturor nodurilor.
Cerințe
- Utilizarea procesoarelor fizice;
- Cel puțin două noduri fizice de calcul;
- Am instalat și configurat componenta Ceilometer - ceilometer-agent-compute, care rulează pe fiecare nod de calcul și API-ul Ceilometer, precum și colectarea următoarelor valori:
metrici
serviciu
pluginuri
comentariu
cpu_util
nici unul
memorie.rezident
nici unul
Parametrii strategiei:
parametru
тип
implicit
описание
metrics
Şir
'cpu_util'
Valorile de bază sunt: „cpu_util”, „memory.resident”.
prag
Număr
25.0
Pragul de sarcină de muncă pentru migrare.
perioadă
Număr
300
Perioada de timp cumulativă Ceilometru.
Metoda folosită este migrarea.
Stabilizarea sarcinii de lucru este o strategie care vizează stabilizarea volumului de muncă folosind migrarea live. Strategia se bazează pe un algoritm de abatere standard și determină dacă există congestie în cluster și răspunde la aceasta declanșând migrarea mașinii pentru a stabiliza clusterul.
Cerințe
- Utilizarea procesoarelor fizice;
- Cel puțin două noduri fizice de calcul;
- Am instalat și configurat componenta Ceilometer - ceilometer-agent-compute, care rulează pe fiecare nod de calcul și API-ul Ceilometer, precum și colectarea următoarelor valori:
metrici
serviciu
pluginuri
comentariu
cpu_util
nici unul
memorie.rezident
nici unul
Strategia de echilibrare a capacității de stocare (strategie implementată începând cu Queens) - strategia transferă discuri în funcție de încărcarea piscinelor Cinder. O decizie de transfer este luată ori de câte ori rata de utilizare a pool-ului depășește un prag specificat. Discul mutat ar trebui să aducă piscina mai aproape de sarcina medie a tuturor piscinelor Cinder.
Cerințe și restricții
- Minim două piscine Cinder;
- Posibilitate de migrare a discului.
- Cluster data model - Cinder cluster data model collector.
Parametrii strategiei:
parametru
тип
implicit
описание
prag_volum
Număr
80.0
Valoarea prag a discurilor pentru echilibrarea volumelor.
Metoda folosită este migrarea discului (volume_migrate).
Vecinul zgomotos - Identificați și migrați un „vecin zgomotos” - o mașină virtuală cu prioritate scăzută care afectează negativ performanța unei mașini virtuale cu prioritate înaltă în ceea ce privește IPC, prin suprautilizarea Last Level Cache. Strategie proprie: Vecinul zgomotos (parametrul strategiei utilizat este cache_threshold (valoarea implicită este 35), când performanța scade la valoarea specificată, migrarea este pornită. Pentru ca strategia să funcționeze, este activată Valori LLC (Last Level Cache), cel mai recent server Intel cu suport CMT, precum și colectarea următoarelor valori:
metrici
serviciu
pluginuri
comentariu
cpu_l3_cache
nici unul
Este necesar Intel .
Model de date cluster (implicit): colector de modele de date cluster Nova. Metoda folosită este migrarea.
Lucrul cu acest obiectiv prin tabloul de bord nu este implementat pe deplin în Queens.
Optimizare termică — optimizarea regimului de temperatură. Temperatura de evacuare (aerul evacuat) este unul dintre sistemele importante de telemetrie termică pentru măsurarea stării termice/sarcină de lucru a unui server. Ținta are o strategie, strategia bazată pe temperatura de ieșire, care decide să migreze sarcinile de lucru către gazde favorabile termic (temperatura cea mai scăzută de ieșire) atunci când temperatura de ieșire a gazdelor sursă atinge un prag configurabil.
Pentru ca strategia să funcționeze, aveți nevoie de un server cu Intel Power Node Manager instalat și configurat , precum și colectarea următoarelor valori:
metrici
serviciu
pluginuri
comentariu
hardware.ipmi.node.outlet_temperature
IPMI
Parametrii strategiei:
parametru
тип
implicit
описание
prag
Număr
35.0
Pragul de temperatură pentru migrare.
perioadă
Număr
30
Intervalul de timp, în secunde, pentru a obține agregarea statistică din sursa de date metrice.
Metoda folosită este migrarea.
Optimizarea fluxului de aer — optimizați modul de ventilație. Strategie proprie - Flux de aer uniform folosind migrarea live. Strategia declanșează migrarea mașinii virtuale ori de câte ori fluxul de aer de la ventilatorul serverului depășește un prag specificat.
Pentru ca strategia să funcționeze, aveți nevoie de:
- Hardware: noduri de calcul < care acceptă NodeManager 3.0;
- Cel puțin două noduri de calcul;
- Componenta ceilometer-agent-compute și Ceilometer API instalate și configurate pe fiecare nod de calcul, care pot raporta cu succes valori precum fluxul de aer, puterea sistemului, temperatura de intrare:
metrici
serviciu
pluginuri
comentariu
hardware.ipmi.node.flux de aer
IPMI
hardware.ipmi.nod.temperatura
IPMI
hardware.ipmi.nod.putere
IPMI
Pentru ca strategia să funcționeze, aveți nevoie de un server cu Intel Power Node Manager 3.0 sau mai recent instalat și configurat.
Limitări: Conceptul nu este destinat producției.
Se propune utilizarea acestui algoritm cu audituri continue, deoarece este planificată migrarea unei singure mașini virtuale per iterație.
Migrațiile live sunt posibile.
Parametrii strategiei:
parametru
тип
implicit
описание
threshold_airflow
Număr
400.0
Pragul fluxului de aer pentru unitatea de migrare este de 0.1 CFM
threshold_inlet_t
Număr
28.0
Pragul de temperatură de intrare pentru decizia de migrare
putere_prag
Număr
350.0
Pragul de putere a sistemului pentru decizia de migrare
perioadă
Număr
30
Intervalul de timp, în secunde, pentru a obține agregarea statistică din sursa de date metrice.
Metoda folosită este migrarea.
Întreținerea hardware - întreținere hardware. Strategia legată de acest obiectiv este migrarea zonei. Strategia este un instrument pentru migrarea eficientă automată și minimă a mașinilor virtuale și a discurilor în cazul în care este nevoie de întreținere hardware. Strategia construiește un plan de acțiune în conformitate cu ponderi: un set de acțiuni care are mai multă pondere va fi planificat înaintea altora. Există două opțiuni de configurare: action_weights și paralelizare.
Limitări: greutățile acțiunii și paralelizarea trebuie configurate.
Parametrii strategiei:
parametru
тип
implicit
описание
compute_nodes
mulțime
Nici unul
Noduri de calcul pentru migrare.
bazine_de_stocare
mulțime
Nici unul
Noduri de stocare pentru migrare.
paralel_total
întreg
6
Numărul total de activități care trebuie executate în paralel.
paralel_per_nod
întreg
2
Numărul de acțiuni efectuate în paralel pentru fiecare nod de calcul.
paralel_per_pool
întreg
2
Numărul de acțiuni efectuate în paralel pentru fiecare pool de stocare.
prioritate
obiect
Nici unul
Lista de priorități pentru mașini virtuale și discuri.
cu_volum_atașat
boolean
Fals
Fals - mașinile virtuale vor fi migrate după ce toate discurile au fost migrate. Adevărat: mașinile virtuale vor fi migrate după ce toate discurile conectate au fost migrate.
Elemente ale matricei de noduri de calcul:
parametru
тип
implicit
описание
src_node
şir
Nici unul
Nodul de calcul de la care sunt migrate mașinile virtuale (obligatoriu).
dst_node
şir
Nici unul
Calculați nodul la care migrează mașinile virtuale.
Elemente de matrice de noduri de stocare:
parametru
тип
implicit
описание
src_pool
şir
Nici unul
Pool-ul de stocare de pe care sunt migrate discurile (obligatoriu).
dst_pool
şir
Nici unul
Pool-ul de stocare către care sunt migrate discurile.
tip_src
şir
Nici unul
Tipul de disc original (obligatoriu).
dst_type
şir
Nici unul
Tipul de disc rezultat (obligatoriu).
Elemente de prioritate a obiectului:
parametru
тип
implicit
описание
proiect
mulțime
Nici unul
Numele proiectelor.
compute_node
mulțime
Nici unul
Calculați numele nodurilor.
pool_stocare
mulțime
Nici unul
Numele pool-urilor de stocare.
calcula
enumerare
Nici unul
Parametrii mașinii virtuale [„vcpu_num”, „mem_size”, „disk_size”, „created_at”].
depozitare
enumerare
Nici unul
Parametrii discului [„size”, “created_at”].
Metodele utilizate sunt migrarea mașinii virtuale, migrarea discurilor.
neclasificat - un scop auxiliar folosit pentru a facilita procesul de elaborare a strategiei. Nu conține specificații și poate fi folosită ori de câte ori strategia nu este încă asociată cu un obiectiv existent. Acest obiectiv poate fi folosit și ca punct de tranziție. O strategie legată de acest obiectiv este Actuator.
Crearea unui nou obiectiv
Motorul de decizie Watcher are o interfață de plugin „obiectiv extern” care face posibilă integrarea unui obiectiv extern care poate fi atins folosind o strategie.
Înainte de a crea un nou obiectiv, ar trebui să vă asigurați că niciun obiectiv existent nu corespunde nevoilor dvs.
Crearea unui nou plugin
Pentru a crea o nouă țintă, trebuie să: extindeți clasa țintă, implementați o metodă de clasă get_name() pentru a returna ID-ul unic al noii ținte pe care doriți să o creați. Acest identificator unic trebuie să se potrivească cu numele punctului de intrare pe care îl declarați mai târziu.
În continuare, trebuie să implementați metoda clasei get_display_name() pentru a returna numele afișat tradus al țintei pe care doriți să o creați (nu utilizați o variabilă pentru a returna șirul tradus, astfel încât să poată fi colectat automat de instrumentul de traducere.).
Implementați o metodă de clasă get_translatable_display_name()pentru a returna cheia de traducere (de fapt, numele afișat în limba engleză) a noii dvs. ținte. Valoarea returnată trebuie să se potrivească cu șirul tradus în get_display_name().
Pune în aplicare metoda lui get_efficacy_specification()pentru a returna specificația de eficiență pentru ținta dvs. Metoda get_efficacy_specification() returnează instanța Unclassified() furnizată de Watcher. Această specificație de performanță este utilă în procesul de dezvoltare a obiectivului dvs. deoarece corespunde specificației goale.
→
Arhitectura Watcher (mai multe detalii) ).
Componente
API-ul Watcher - o componentă care implementează API-ul REST furnizat de Watcher. Mecanisme de interacțiune: CLI, plugin Horizon, Python SDK.
Watcher DB — Baza de date Watcher.
Aplicator Watcher — o componentă care implementează execuția unui plan de acțiune creat de componenta Watcher Decision Engine.
Motorul de decizie Watcher - Componenta responsabilă cu calcularea unui set de acțiuni potențiale de optimizare pentru atingerea scopului auditului. Dacă nu este specificată o strategie, componenta o selectează în mod independent pe cea mai potrivită.
Editorul Watcher Metrics - O componentă care colectează și calculează unele valori sau evenimente și le publică la punctul final CEP. Funcționalitatea componentei poate fi furnizată și de editorul Ceilometer.
Motor de procesare a evenimentelor complexe (CEP). — motor pentru procesarea evenimentelor complexe. Din motive de performanță, pot exista mai multe instanțe CEP Engine care rulează simultan, fiecare procesând un anumit tip de măsură/eveniment. În sistemul Watcher, CEP declanșează două tipuri de acțiuni: - înregistrarea evenimentelor/metricilor corespunzătoare în baza de date a seriilor temporale; - trimiteți evenimentele adecvate către Watcher Decision Engine când acest eveniment poate afecta rezultatul strategiei de optimizare curente, deoarece clusterul Openstack nu este un sistem static.
Componentele interacționează folosind protocolul AMQP.
→
Schema de interacțiune cu Watcher
Rezultatele testului Watcher
- Pe pagina Optimizare - Planuri de acțiune 500 (atât pe Queens pure, cât și pe un stand cu module Tionix), apare doar după ce se lansează auditul și se generează un plan de acțiune; cel gol se deschide normal.
- Există erori în fila Detalii acțiuni, nu este posibil să obțineți obiectivul și strategia de audit (atât pe Queens pure, cât și pe un stand cu module Tionix).
- Auditurile cu scopul Dummy (test) sunt create și lansate normal, sunt generate planuri de acțiune.
- Auditurile pentru obiectivul Neclasificat nu sunt create deoarece scopul nu este funcțional și este destinat configurației intermediare la crearea de noi strategii.
- Auditurile în scopul echilibrării sarcinii de lucru (strategia de echilibrare a capacității de stocare) sunt create cu succes, dar nu este generat un plan de acțiune. Nu este necesară optimizarea pool-ului de stocare.
- Auditurile pentru obiectivul de echilibrare a sarcinii de lucru (strategia de migrare a echilibrului sarcinii de lucru) sunt create cu succes, dar nu este generat un plan de acțiune.
- Auditurile pentru echilibrarea sarcinii de lucru (strategia de stabilizare a sarcinii de lucru) eșuează.
- Auditurile pentru ținta Nosy Neighbor sunt create cu succes, dar nu este generat un plan de acțiune.
- Auditurile în scopul întreținerii Hardware sunt create cu succes, planul de acțiune nu este generat integral (se generează indicatori de performanță, dar lista de acțiuni în sine nu este generată).
- Editările din configurațiile nova.conf (în secțiunea implicită compute_monitors = cpu.virt_driver) de pe nodurile de calcul și control nu corectează erorile.
- Auditurile care vizează consolidarea serverelor (strategia de bază) eșuează și ele.
- Auditurile în scopul consolidării serverului (strategia de consolidare a sarcinii de lucru VM) eșuează cu o eroare. În jurnalele există o eroare la obținerea datelor sursă. Discuție despre eroare, în special .
Am încercat să specificăm Watcher în fișierul de configurare (nu a ajutat - ca urmare a unei erori pe toate paginile de optimizare, revenirea la conținutul original al fișierului de configurare nu corectează situația): [watcher_strategies.basic] datasource = ceilometru, gnocchi - Auditurile pentru economisirea energiei eșuează. Judecând după jurnalele, problema este încă absența lui Ironic; nu va funcționa fără un serviciu complet.
- Auditurile pentru optimizarea termică eșuează. Traceback-ul este același ca pentru Server Consolidation (strategia de consolidare a sarcinii de lucru VM) (eroare de date sursă)
- Auditurile în scopul optimizării fluxului de aer eșuează cu o eroare.
De asemenea, sunt întâlnite următoarele erori de finalizare a auditului. Traceback în jurnalele decision-engine.log (starea clusterului nu este definită).
→ Discutarea erorii
Concluzie
Rezultatul cercetării noastre de două luni a fost concluzia fără echivoc că, pentru a obține un sistem complet de echilibrare a sarcinii de lucru, va trebui, în această parte, să lucrăm îndeaproape la perfecționarea instrumentelor pentru platforma Openstack.
Watcher s-a dovedit a fi un produs serios și în dezvoltare rapidă, cu un potențial enorm, a cărui utilizare completă va necesita multă muncă serioasă.
Dar mai multe despre asta în următoarele articole ale seriei.
Sursa: www.habr.com