Sa malalaking cloud system, ang isyu ng awtomatikong pagbabalanse o pag-level ng load sa mga mapagkukunan ng computing ay lalong talamak. Ang Tionix (isang developer at operator ng mga serbisyo sa cloud, bahagi ng pangkat ng mga kumpanya ng Rostelecom) ay nag-ingat din sa isyung ito.
At, dahil ang aming pangunahing platform sa pag-unlad ay ang Openstack, at kami, tulad ng lahat ng tao, ay tamad, napagpasyahan na pumili ng ilang nakahanda nang module na kasama na sa platform. Ang aming napili ay nahulog sa Watcher, na napagpasyahan naming gamitin para sa aming mga pangangailangan.
Una, tingnan natin ang mga termino at kahulugan.
Mga Tuntunin at Kahulugan
Layunin ay isang nababasa ng tao, napapansin at nasusukat na resulta na dapat makamit. Mayroong isa o higit pang mga diskarte upang makamit ang bawat layunin. Ang diskarte ay ang pagpapatupad ng isang algorithm na may kakayahang maghanap ng solusyon para sa isang partikular na layunin.
Aksyon ay isang elementarya na gawain na nagbabago sa kasalukuyang estado ng target na pinamamahalaang mapagkukunan ng OpenStack cluster, tulad ng: paglipat ng virtual machine (migration), pagbabago ng power state ng isang node (change_node_power_state), pagbabago ng estado ng nova service (change_nova_service_state ), pagpapalit ng lasa (resize), pagrerehistro ng mga NOP na mensahe (nop), kawalan ng pagkilos para sa isang tiyak na haba ng oras - pause (sleep), disk transfer (volume_migrate).
Plano ng Aksyon - isang tiyak na daloy ng mga aksyon na isinasagawa sa isang tiyak na pagkakasunud-sunod upang makamit ang isang tiyak na Layunin. Naglalaman din ang Action Plan ng nasusukat na pandaigdigang pagganap na may isang hanay ng mga tagapagpahiwatig ng pagganap. Ang isang plano ng aksyon ay nabuo ng Watcher sa isang matagumpay na pag-audit, bilang isang resulta kung saan ang diskarte na ginamit ay nakakahanap ng solusyon upang makamit ang layunin. Ang plano ng aksyon ay binubuo ng isang listahan ng mga sunud-sunod na aksyon.
Pag-audit ay isang kahilingan na i-optimize ang cluster. Isinasagawa ang pag-optimize upang makamit ang isang Layunin sa isang partikular na cluster. Para sa bawat matagumpay na pag-audit, ang Watcher ay bumubuo ng isang Action Plan.
Saklaw ng Audit ay isang hanay ng mga mapagkukunan kung saan isinasagawa ang pag-audit (mga available na zone, mga node aggregator, indibidwal na compute node o storage node, atbp.). Ang saklaw ng audit ay tinukoy sa bawat template. Kung hindi tinukoy ang saklaw ng pag-audit, a-audit ang buong cluster.
Template ng Audit — isang naka-save na hanay ng mga setting para sa paglulunsad ng audit. Kinakailangan ang mga template upang magpatakbo ng mga pag-audit nang maraming beses na may parehong mga setting. Ang template ay dapat na naglalaman ng layunin ng pag-audit; kung ang mga diskarte ay hindi tinukoy, pagkatapos ay ang pinaka-angkop na umiiral na mga diskarte ay pipiliin.
Cluster ay isang koleksyon ng mga pisikal na makina na nagbibigay ng compute, storage, at networking resources at pinamamahalaan ng parehong OpenStack management node.
Cluster Data Model (CDM) ay isang lohikal na representasyon ng kasalukuyang estado at topology ng mga mapagkukunan na pinamamahalaan ng cluster.
Tagapagpahiwatig ng Kahusayan - isang indicator na nagsasaad kung paano ginaganap ang solusyon na nilikha gamit ang diskarteng ito. Ang mga tagapagpahiwatig ng pagganap ay partikular sa isang partikular na layunin at karaniwang ginagamit upang kalkulahin ang pandaigdigang pagiging epektibo ng nagreresultang plano ng pagkilos.
Pagtutukoy ng Kahusayan ay isang hanay ng mga partikular na tampok na nauugnay sa bawat Layunin na tumutukoy sa iba't ibang mga tagapagpahiwatig ng pagganap na dapat makamit ng isang diskarte upang makamit ang kaukulang Layunin sa solusyon nito. Sa katunayan, ang bawat solusyon na iminungkahi ng diskarte ay susuriin laban sa detalye bago kalkulahin ang pagiging epektibo nito sa buong mundo.
Scoring Engine ay isang executable na file na may mahusay na tinukoy na mga input, mahusay na tinukoy na mga output, at gumaganap ng isang purong matematikal na gawain. Sa ganitong paraan, ang pagkalkula ay independiyente sa kapaligiran kung saan ito isinasagawa—magbibigay ito ng parehong resulta kahit saan.
Tagaplano ng Tagabantay - bahagi ng makina ng paggawa ng desisyon ng Watcher. Ang module na ito ay tumatagal ng isang hanay ng mga aksyon na nabuo ng isang diskarte at gumagawa ng isang workflow plan na tumutukoy kung paano iiskedyul ang iba't ibang mga aksyon sa oras at para sa bawat aksyon, kung ano ang mga paunang kundisyon.
Mga Layunin at Istratehiya ng Tagamasid
Layunin
estratehiya
Dummy layunin
Dummy Strategy
Dummy Strategy gamit ang sample Scoring Engines
Dummy diskarte na may resize
Saving Energy
Diskarte sa Pagtitipid ng Enerhiya
Pagsasama-sama ng Server
Pangunahing Offline Server Consolidation
Diskarte sa Pagsasama-sama ng Workload ng VM
Pagbalanse ng Workload
Diskarte sa Paglipat ng Balanse sa Trabaho
Diskarte sa Balanse ng Kapasidad ng Imbakan
Pagpapatatag ng workload
Maingay na Kapitbahay
Maingay na Kapitbahay
Thermal Optimization
Diskarte batay sa temperatura ng outlet
Pag-optimize ng Airflow
Uniform na diskarte sa paglipat ng airflow
Pagpapanatili ng hardware
Zone migration
Hindi na-classify
Actuator
Dummy layunin — nakalaan na layunin na ginagamit para sa mga layunin ng pagsubok.
Mga kaugnay na diskarte: Dummy Strategy, Dummy Strategy gamit ang sample na Scoring Engines at Dummy na diskarte na may resize. Ang dummy na diskarte ay isang dummy na diskarte na ginagamit para sa integration testing sa pamamagitan ng Tempest. Ang diskarte na ito ay hindi nagbibigay ng anumang kapaki-pakinabang na pag-optimize, ang tanging layunin nito ay gumamit ng mga pagsubok sa Tempest.
Dummy na diskarte gamit ang sample Scoring Engines - ang diskarte ay katulad ng nauna, ang pagkakaiba lang ay ang paggamit ng sample na "scoring engine" na nagsasagawa ng mga kalkulasyon gamit ang machine learning method.
Dummy na diskarte na may resize - ang diskarte ay katulad ng nauna, ang pagkakaiba lang ay ang paggamit ng pagpapalit ng lasa (migration at resize).
Hindi ginagamit sa produksyon.
Saving Energy — bawasan ang pagkonsumo ng enerhiya. Ang Saving Energy Strategy ng layuning ito, kasama ang VM Workload Consolidation Strategy (Server Consolidation), ay may kakayahang mga dynamic power management (DPM) na mga feature na nagtitipid ng enerhiya sa pamamagitan ng dynamic na pagsasama-sama ng mga workload kahit na sa panahon ng mababang paggamit ng mapagkukunan: ang mga virtual machine ay inililipat sa mas kaunting mga node , at ang mga hindi kinakailangang node ay hindi pinagana. Pagkatapos ng pagsasama-sama, ang diskarte ay nag-aalok ng desisyon sa pag-on/off ng mga node alinsunod sa tinukoy na mga parameter: “min_free_hosts_num” - ang bilang ng mga libreng pinaganang node na naghihintay ng pag-load, at “free_used_percent” - ang porsyento ng mga libreng pinaganang host sa bilang ng mga node na inookupahan ng mga makina. Para gumana ang diskarte dapat meron pinagana at na-configure ang Ironic para pangasiwaan ang power cycling sa mga node.
Mga parameter ng diskarte
parameter
uri ng
bilang default
описание
free_used_percent
Numero
10.0
ratio ng bilang ng mga libreng computing node sa bilang ng mga computing node na may mga virtual machine
min_free_hosts_num
Int
1
minimum na bilang ng mga libreng computing node
Ang ulap ay dapat magkaroon ng hindi bababa sa dalawang node. Ang ginamit na paraan ay ang pagbabago ng power state ng node (change_node_power_state). Ang diskarte ay hindi nangangailangan ng pagkolekta ng mga sukatan.
Server Consolidation - bawasan ang bilang ng mga computing node (consolidation). Mayroon itong dalawang diskarte: Basic Offline Server Consolidation at VM Workload Consolidation Strategy.
Pinaliit ng Basic Offline Server Consolidation na diskarte ang kabuuang bilang ng mga server na ginamit at pinapaliit din ang bilang ng mga paglilipat.
Ang pangunahing diskarte ay nangangailangan ng mga sumusunod na sukatan:
mga sukatan
serbisyo
mga plugin
komentaryo
compute.node.cpu.percent
wala
cpu_util
wala
Mga parameter ng diskarte: migration_attempts - bilang ng mga kumbinasyon upang maghanap ng mga potensyal na kandidato para sa pagsasara (default, 0, walang mga paghihigpit), tagal - pagitan ng oras sa mga segundo upang makakuha ng static na pagsasama-sama mula sa metric data source (default, 700).
Mga pamamaraang ginamit: paglipat, pagbabago ng estado ng serbisyo ng nova (change_nova_service_state).
Ang VM Workload Consolidation Strategy ay nakabatay sa isang first-fit na heuristic na nakatutok sa sinusukat na pag-load ng CPU at sinusubukang i-minimize ang mga node na may sobra o masyadong maliit na load dahil sa mga hadlang sa kapasidad ng mapagkukunan. Nagbibigay ang diskarteng ito ng solusyon na nagreresulta sa mas mahusay na paggamit ng mga mapagkukunan ng cluster gamit ang sumusunod na apat na hakbang:
- Unloading phase - pagpoproseso ng labis na paggamit ng mga mapagkukunan;
- Consolidation phase - paghawak ng hindi gaanong ginagamit na mga mapagkukunan;
- Pag-optimize ng solusyon - pagbabawas ng bilang ng mga paglilipat;
- Hindi pagpapagana ng hindi nagamit na mga compute node.
Ang diskarte ay nangangailangan ng mga sumusunod na sukatan:
mga sukatan
serbisyo
mga plugin
komentaryo
memorya
wala
disk.root.size
wala
Opsyonal ang mga sumusunod na sukatan ngunit mapapabuti ang katumpakan ng diskarte kung magagamit:
mga sukatan
serbisyo
mga plugin
komentaryo
alaala.residente
wala
cpu_util
wala
Mga parameter ng diskarte: panahon — agwat ng oras sa mga segundo upang makakuha ng static na pagsasama-sama mula sa metric data source (default, 3600).
Gumagamit ng parehong mga pamamaraan tulad ng nakaraang diskarte. Higit pang mga detalye .
Pagbalanse ng Workload — balansehin ang workload sa pagitan ng mga computing node. May tatlong diskarte ang layunin: Diskarte sa Paglipat ng Balanse sa Trabaho, Pag-stabilize ng Workload, Diskarte sa Balanse ng Kapasidad ng Imbakan.
Ang Diskarte sa Paglipat ng Balanse sa Trabaho ay nagpapatakbo ng mga paglilipat ng virtual machine batay sa workload ng virtual machine ng host. Ang isang desisyon sa paglipat ay ginagawa kapag ang % CPU o RAM na paggamit ng isang node ay lumampas sa tinukoy na threshold. Sa kasong ito, dapat ilapit ng inilipat na virtual machine ang node sa average na workload ng lahat ng node.
Kinakailangan sa
- Paggamit ng mga pisikal na processor;
- Hindi bababa sa dalawang pisikal na computing node;
- Na-install at na-configure ang bahagi ng Ceilometer - ceilometer-agent-compute, na tumatakbo sa bawat compute node, at ang Ceilometer API, pati na rin ang pagkolekta ng mga sumusunod na sukatan:
mga sukatan
serbisyo
mga plugin
komentaryo
cpu_util
wala
alaala.residente
wala
Mga parameter ng diskarte:
parameter
uri ng
bilang default
описание
sukatan
Pisi
'cpu_util'
Ang mga pinagbabatayan na sukatan ay: 'cpu_util', 'memory.resident'.
threshold
Numero
25.0
Workload threshold para sa paglipat.
panahon
Numero
300
Cumulative time period Ceilometer.
Ang paraan na ginamit ay migration.
Ang pag-stabilize ng workload ay isang diskarte na naglalayong i-stabilize ang workload gamit ang live na paglipat. Ang diskarte ay nakabatay sa isang standard deviation algorithm at tinutukoy kung mayroong congestion sa cluster at tumutugon dito sa pamamagitan ng pag-trigger ng machine migration upang patatagin ang cluster.
Kinakailangan sa
- Paggamit ng mga pisikal na processor;
- Hindi bababa sa dalawang pisikal na computing node;
- Na-install at na-configure ang bahagi ng Ceilometer - ceilometer-agent-compute, na tumatakbo sa bawat compute node, at ang Ceilometer API, pati na rin ang pagkolekta ng mga sumusunod na sukatan:
mga sukatan
serbisyo
mga plugin
komentaryo
cpu_util
wala
alaala.residente
wala
Diskarte sa Balanse ng Kapasidad ng Imbakan (istratehiya na ipinatupad simula sa Queens) - ang diskarte ay naglilipat ng mga disk depende sa load sa mga Cinder pool. Ginagawa ang desisyon sa paglipat kapag lumampas ang rate ng paggamit ng pool sa isang tinukoy na threshold. Ang disk na inililipat ay dapat maglalapit sa pool sa average na load ng lahat ng Cinder pool.
Mga kinakailangan at paghihigpit
- Minimum na dalawang Cinder pool;
- Posibilidad ng paglilipat ng disk.
- Modelo ng data ng cluster - Tagakolekta ng modelo ng data ng cluster ng Cinder.
Mga parameter ng diskarte:
parameter
uri ng
bilang default
описание
volume_threshold
Numero
80.0
Halaga ng threshold ng mga disk para sa mga volume ng pagbabalanse.
Ang paraan na ginamit ay disk migration (volume_migrate).
Noisy Neighbor - Tukuyin at i-migrate ang isang "maingay na kapitbahay" - isang mababang priyoridad na virtual machine na negatibong nakakaapekto sa pagganap ng isang mataas na priyoridad na virtual machine sa mga tuntunin ng IPC sa pamamagitan ng sobrang paggamit ng Last Level Cache. Sariling diskarte: Noisy Neighbor (parameter ng diskarte na ginamit ay cache_threshold (default na value ay 35), kapag bumaba ang performance sa tinukoy na halaga, magsisimula ang paglipat. Para gumana ang diskarte, pinagana LLC (Last Level Cache) na sukatan, pinakabagong Intel server na may suporta sa CMT, pati na rin ang pagkolekta ng mga sumusunod na sukatan:
mga sukatan
serbisyo
mga plugin
komentaryo
cpu_l3_cache
wala
Kinakailangan ng Intel .
Cluster data model (default): Nova cluster data model collector. Ang paraan na ginamit ay migration.
Ang pagtatrabaho sa layuning ito sa pamamagitan ng Dashboard ay hindi ganap na ipinapatupad sa Queens.
Thermal Optimization - i-optimize ang temperatura ng rehimen. Ang temperatura ng outlet (exhaust air) ay isa sa mga mahalagang thermal telemetry system para sukatin ang katayuan ng thermal/workload ng isang server. Ang target ay may isang diskarte, ang Outlet temperature based na diskarte, na nagpapasyang i-migrate ang mga workload sa thermally favorable hosts (pinakamababang outlet temperature) kapag ang outlet temperature ng source host ay umabot sa isang configurable threshold.
Para gumana ang diskarte, kailangan mo ng server na may naka-install at naka-configure na Intel Power Node Manager , pati na rin ang pagkolekta ng mga sumusunod na sukatan:
mga sukatan
serbisyo
mga plugin
komentaryo
hardware.ipmi.node.outlet_temperature
IPMI
Mga parameter ng diskarte:
parameter
uri ng
bilang default
описание
threshold
Numero
35.0
Temperatura threshold para sa paglipat.
panahon
Numero
30
Ang agwat ng oras, sa mga segundo, upang makuha ang statistical aggregation mula sa metric data source.
Ang paraan na ginamit ay migration.
Pag-optimize ng Airflow — i-optimize ang ventilation mode. Sariling diskarte - Uniform Airflow gamit ang live na paglipat. Ang diskarte ay nagti-trigger ng virtual machine migration sa tuwing ang airflow mula sa server fan ay lumampas sa isang tinukoy na threshold.
Para gumana ang diskarte kailangan mo:
- Hardware: compute nodes < sumusuporta sa NodeManager 3.0;
- Hindi bababa sa dalawang computing node;
- Ang ceilometer-agent-compute at Ceilometer API component na naka-install at na-configure sa bawat computing node, na maaaring matagumpay na mag-ulat ng mga sukatan gaya ng air flow, system power, inlet temperature:
mga sukatan
serbisyo
mga plugin
komentaryo
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperatura
IPMI
hardware.ipmi.node.power
IPMI
Para gumana ang diskarte, kailangan mo ng server na may Intel Power Node Manager 3.0 o mas bago na naka-install at naka-configure.
Mga Limitasyon: Ang konsepto ay hindi inilaan para sa produksyon.
Iminumungkahi na gamitin ang algorithm na ito na may tuluy-tuloy na pag-audit, dahil isang virtual machine lang ang pinaplanong i-migrate sa bawat pag-ulit.
Posible ang mga live na paglilipat.
Mga parameter ng diskarte:
parameter
uri ng
bilang default
описание
threshold_airflow
Numero
400.0
Ang threshold ng airflow para sa migration Unit ay 0.1CFM
threshold_inlet_t
Numero
28.0
Inlet temperature threshold para sa desisyon sa paglipat
threshold_power
Numero
350.0
System power threshold para sa desisyon sa paglipat
panahon
Numero
30
Ang agwat ng oras, sa mga segundo, upang makuha ang statistical aggregation mula sa metric data source.
Ang paraan na ginamit ay migration.
Pagpapanatili ng Hardware - pagpapanatili ng hardware. Ang diskarte na nauugnay sa layuning ito ay Zone migration. Ang diskarte ay isang tool para sa epektibong awtomatiko at minimal na paglipat ng mga virtual machine at disk kung sakaling kailanganin ang pagpapanatili ng hardware. Bumubuo ang Diskarte ng isang plano ng pagkilos alinsunod sa mga timbang: isang hanay ng mga aksyon na may higit na timbang ang paplanohan bago ang iba. Mayroong dalawang opsyon sa pagsasaayos: action_weights at parallelization.
Mga Limitasyon: kailangang i-configure ang mga timbang ng aksyon at parallelization.
Mga parameter ng diskarte:
parameter
uri ng
bilang default
описание
compute_nodes
ayos
Wala
Compute node para sa paglipat.
storage_pools
ayos
Wala
Mga storage node para sa paglipat.
parallel_total
kabuuan
6
Ang kabuuang bilang ng mga aktibidad na dapat isagawa nang magkatulad.
parallel_per_node
kabuuan
2
Ang bilang ng mga aksyon na isinagawa nang magkatulad para sa bawat compute node.
parallel_per_pool
kabuuan
2
Ang bilang ng mga pagkilos na isinagawa nang magkatulad para sa bawat storage pool.
karapatang mauna
bagay
Wala
Listahan ng priyoridad para sa mga virtual machine at disk.
with_attached_volume
boolean
Huwad
Mali—malilipat ang mga virtual machine pagkatapos mailipat ang lahat ng disk. True—malilipat ang mga virtual machine pagkatapos mailipat ang lahat ng konektadong disk.
Mga elemento ng hanay ng mga node sa pag-compute:
parameter
uri ng
bilang default
описание
src_node
pisi
Wala
Ang compute node kung saan inililipat ang mga virtual machine (kinakailangan).
dst_node
pisi
Wala
Kalkulahin ang node kung saan lumilipat ang mga virtual machine.
Mga elemento ng array ng storage node:
parameter
uri ng
bilang default
описание
src_pool
pisi
Wala
Ang storage pool kung saan inililipat ang mga disk (kinakailangan).
dst_pool
pisi
Wala
Ang storage pool kung saan inililipat ang mga disk.
src_type
pisi
Wala
Orihinal na uri ng disk (kinakailangan).
dst_type
pisi
Wala
Ang resultang uri ng disk (kinakailangan).
Mga elemento ng priority ng object:
parameter
uri ng
bilang default
описание
proyekto
ayos
Wala
Mga pangalan ng proyekto.
compute_node
ayos
Wala
I-compute ang mga pangalan ng node.
storage_pool
ayos
Wala
Mga pangalan ng storage pool.
compute
enum
Wala
Mga parameter ng virtual machine [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
imbakan
enum
Wala
Mga parameter ng disk ["laki", "nilikha_sa"].
Ang mga pamamaraan na ginamit ay virtual machine migration, disk migration.
Hindi na-classify - isang pantulong na layunin na ginagamit upang mapadali ang proseso ng pagbuo ng diskarte. Walang mga detalye at maaaring gamitin sa tuwing ang diskarte ay hindi pa nauugnay sa isang umiiral na layunin. Ang layuning ito ay maaari ding gamitin bilang isang transition point. Ang isang nauugnay na diskarte sa layuning ito ay Actuator.
Paglikha ng bagong layunin
Engine ng Desisyon ng Watcher ay may interface ng plugin na "panlabas na layunin" na ginagawang posible na isama ang isang panlabas na layunin na maaaring makamit gamit ang isang diskarte.
Bago ka gumawa ng bagong layunin, dapat mong tiyakin na walang mga umiiral na layunin ang nakakatugon sa iyong mga pangangailangan.
Paglikha ng bagong plugin
Upang lumikha ng bagong target, dapat mong: pahabain ang target na klase, magpatupad ng paraan ng klase get_name() upang ibalik ang natatanging ID ng bagong target na gusto mong gawin. Dapat tumugma ang natatanging identifier na ito sa pangalan ng entry point na idedeklara mo sa ibang pagkakataon.
Susunod na kailangan mong ipatupad ang pamamaraan ng klase get_display_name() para ibalik ang isinaling display name ng target na gusto mong gawin (huwag gumamit ng variable para ibalik ang isinaling string para awtomatiko itong makolekta ng tool sa pagsasalin.).
Magpatupad ng paraan ng klase get_translatable_display_name()upang ibalik ang translation key (talaga ang English na display name) ng iyong bagong target. Dapat tumugma ang return value sa string na isinalin sa get_display_name().
Ipatupad ang kanyang pamamaraan get_efficacy_specification()upang ibalik ang detalye ng kahusayan para sa iyong target. Ang get_efficacy_specification() method ay nagbabalik ng Unclassified() instance na ibinigay ng Watcher. Ang pagtutukoy ng pagganap na ito ay kapaki-pakinabang sa proseso ng pagbuo ng iyong layunin dahil tumutugma ito sa walang laman na detalye.
→
Arkitektura ng tagamasid (higit pang mga detalye) ).
Piraso
Watcher API - isang bahagi na nagpapatupad ng REST API na ibinigay ng Watcher. Mga mekanismo ng pakikipag-ugnayan: CLI, Horizon plugin, Python SDK.
Tagamasid DB — Database ng tagamasid.
Watcher Applier — isang bahagi na nagpapatupad ng pagpapatupad ng isang plano ng aksyon na ginawa ng bahagi ng Watcher Decision Engine.
Engine ng Desisyon ng Watcher - Ang bahaging responsable para sa pag-compute ng isang hanay ng mga potensyal na pagkilos sa pag-optimize upang makamit ang layunin ng pag-audit. Kung ang isang diskarte ay hindi tinukoy, ang bahagi ay hiwalay na pipili ng pinakaangkop.
Publisher ng Watcher Sukatan - Isang bahagi na nangongolekta at nagkalkula ng ilang sukatan o kaganapan at ini-publish ang mga ito sa endpoint ng CEP. Ang functionality ng component ay maaari ding ibigay ng Ceilometer publisher.
Complex Event Processing (CEP) Engine — engine para sa kumplikadong pagproseso ng kaganapan. Para sa mga kadahilanan ng pagganap, maaaring mayroong maraming mga instance ng CEP Engine na tumatakbo nang sabay-sabay, bawat isa ay nagpoproseso ng isang partikular na uri ng sukatan/kaganapan. Sa sistema ng Watcher, nagti-trigger ang CEP ng dalawang uri ng mga aksyon: - Itala ang mga kaukulang kaganapan / sukatan sa database ng serye ng oras; - magpadala ng mga naaangkop na kaganapan sa Watcher Decision Engine kapag ang kaganapang ito ay maaaring makaapekto sa resulta ng kasalukuyang diskarte sa pag-optimize, dahil ang Openstack cluster ay hindi isang static na sistema.
Ang mga bahagi ay nakikipag-ugnayan gamit ang AMQP protocol.
→
Scheme ng pakikipag-ugnayan sa Watcher
Mga resulta ng pagsubok ng tagamasid
- Sa pahina ng Optimization - Action plans 500 (kapwa sa purong Queens at sa isang stand na may mga Tionix modules), ito ay lilitaw lamang pagkatapos na ilunsad ang pag-audit at isang action plan ay nabuo; ang walang laman ay bumubukas nang normal.
- May mga error sa tab na Mga detalye ng aksyon, hindi posibleng makuha ang layunin at diskarte sa pag-audit (kapwa sa mga purong Queens at sa isang stand na may mga module ng Tionix).
- Ang mga pag-audit na may layunin ng Dummy (pagsubok) ay nilikha at inilunsad nang normal, ang mga plano sa pagkilos ay nabuo.
- Ang mga pag-audit para sa Unclassified na layunin ay hindi ginawa dahil ang layunin ay hindi gumagana at nilayon para sa intermediate na configuration kapag gumagawa ng mga bagong diskarte.
- Ang mga pag-audit para sa layunin ng Workload Balancing (Diskarte sa balanse ng Kapasidad ng Imbakan) ay matagumpay na nagawa, ngunit hindi nabuo ang isang plano ng pagkilos. Walang kinakailangang pag-optimize ng storage pool.
- Matagumpay na nagagawa ang mga pag-audit para sa layunin sa Pagbalanse ng Workload (Workload Balance Migration Strategy), ngunit hindi nabuo ang isang action plan.
- Nabigo ang mga pag-audit para sa Workload Balancing (Workload Stabilization Strategy).
- Matagumpay na nagawa ang mga pag-audit para sa target na Noisy Neighbor, ngunit hindi nakabuo ng plano ng pagkilos.
- Ang mga pag-audit para sa layunin ng pagpapanatili ng Hardware ay matagumpay na nalikha, ang plano ng pagkilos ay hindi nabuo nang buo (ang mga tagapagpahiwatig ng pagganap ay nabuo, ngunit ang listahan ng mga aksyon mismo ay hindi nabuo).
- Ang mga pag-edit sa nova.conf configs (sa default na seksyon na compute_monitors = cpu.virt_driver) sa compute at control node ay hindi nagwawasto sa mga error.
- Nabigo rin ang mga pag-audit na nagta-target sa Server Consolidation (Basic na diskarte).
- Ang mga pag-audit para sa layunin ng Server Consolidation (VM workload consolidation strategy) ay nabigo nang may error. Sa mga log mayroong error sa pagkuha ng source data. Talakayan ng error, sa partikular .
Sinubukan naming tukuyin ang Watcher sa config file (hindi ito nakatulong - bilang isang resulta ng isang error sa lahat ng mga pahina ng Optimization, ang pagbabalik sa orihinal na nilalaman ng config file ay hindi itama ang sitwasyon): [watcher_strategies.basic] datasource = ceilometer, gnocchi - Nabigo ang mga pag-audit para sa Pagtitipid ng Enerhiya. Sa paghusga sa mga log, ang problema ay ang kawalan pa rin ng Ironic; hindi ito gagana nang walang serbisyo ng baremetal.
- Nabigo ang mga pag-audit para sa Thermal Optimization. Ang traceback ay kapareho ng para sa Server Consolidation (VM workload consolidation strategy) (source data error)
- Nabigo ang mga pag-audit para sa layunin ng Airflow Optimization na may error.
Ang mga sumusunod na error sa pagkumpleto ng pag-audit ay nakatagpo din. Traceback sa mga log ng decision-engine.log (hindi tinukoy ang estado ng cluster).
→ Pagtalakay sa pagkakamali
Konklusyon
Ang resulta ng aming dalawang buwang pananaliksik ay ang malinaw na konklusyon na upang makakuha ng isang ganap, gumaganang sistema ng pagbabalanse ng load, magkakaroon kami, sa bahaging ito, na magtrabaho nang malapit sa pagpino ng mga tool para sa platform ng Openstack.
Ang Watcher ay napatunayang isang seryoso at mabilis na umuunlad na produkto na may napakalaking potensyal, ang buong paggamit nito ay mangangailangan ng maraming seryosong trabaho.
Ngunit higit pa tungkol dito sa susunod na mga artikulo ng serye.
Pinagmulan: www.habr.com