Ve velkých cloudových systémech se zvláště vyvstává otázka automatického vyvažování nebo vyrovnávání zátěže na procesní zdroje. Tímto problémem se zabýváme také my v Tionixu (vývojář a provozovatel cloudových služeb, součást skupiny Rostelecom).
A protože naší hlavní vývojovou platformou je Openstack, a jsme jako všichni lidé líní, rozhodli jsme se vybrat nějaký hotový modul, který je již součástí platformy. Naším výběrem byl Watcher, který jsme se rozhodli použít pro naše potřeby.
Nejprve se podíváme na termíny a definice.
Termíny a definice
Cíl — to je pro člověka čitelný, pozorovatelný a měřitelný konečný výsledek, který má být dosažen. Pro každou cíli existuje jedna nebo více strategií. Strategie je implementace algoritmu, který je schopen nalézt řešení pro daný cíl.
Akce (Action) — to je elementární úkol, který mění aktuální stav cílového řízeného zdroje clustera OpenStack, jako např.: migrace virtuálního stroje (migration), změna stavu napájení uzlu (change_node_power_state), změna stavu služby nova (change_nova_service_state), změna flavoru (resize), registrace NOP zprávy (nop), absence akcí po určitou dobu — pauza (sleep), přesun disku (volume_migrate).
Plán akcí (Action Plan) — specifický tok akcí prováděných v určitém pořadí k dosažení konkrétního cíle. Plán akcí také obsahuje odhadovanou globální efektivitu s sadou ukazatelů výkonnosti. Plán akcí vygeneruje Watcher po úspěšně provedeném auditu, při kterém použité strategie nalézají řešení pro dosažení cíle. Plán akcí se skládá ze seznamu sekvenčních akcí.
Audit (Audit) — to je žádost o optimalizaci clustera. Optimalizace se provádí za účelem dosažení jednoho cíle v daném clusteru. Po každém úspěšném auditu Watcher generuje plán akcí.
Oblast auditu (Audit Scope) — je soubor zdrojů, v rámci kterých se provádí audit (oblast(e) dostupnosti, agregátory uzlů, jednotlivé výpočetní uzly nebo uzly úložiště atd.). Oblast auditu je definována v každé šabloně. Pokud oblast auditu není uvedena, provádí se audit celého clusteru.
Šablona auditu (Audit Template) — uložená sada nastavení pro spuštění auditu. Šablony jsou nezbytné k tomu, aby bylo možné opakovaně spouštět audity se stejnými nastaveními. Šablona musí vždy obsahovat cíl auditu; pokud nejsou uvedeny strategie, vybírají se nejvhodnější z existujících strategií.
Cluster (Klastr) — je soubor fyzických strojů, které poskytují výpočetní zdroje, zdroje úložiště a síťové zdroje a jsou spravovány jedním a tím samým řídicím uzlem OpenStack.
Model dat clusteru (Cluster Data Model, CDM) — je logické zobrazení aktuálního stavu a topologie spravovaných clusterem zdrojů.
Ukazatel efektivity (Efficacy Indicator) — ukazatel, který ukazuje, jak bylo dosaženo řešení vytvořeného pomocí této strategie. Ukazatele efektivity jsou specifické pro konkrétní cíl a obvykle se používají k výpočtu globální efektivity konečného plánu akcí.
Specifikace efektivity (Efficacy Specification) — je soubor specifických rysů spojených s každým cílem, který určuje různé ukazatele efektivity, které strategie zajišťující dosažení příslušného cíle musí v návrhu zajišťovat. Každé řešení, které strategie navrhne, bude skutečně před jeho vyhodnocením globální efektivity zkontrolováno, zda vyhovuje specifikaci.
„Scoring“ engine (Podstatný engine) — je spustitelný soubor, který má přesně definované vstupy, přesně definované výstupy a vykonává čistě matematický úkol. Takže výpočet nezávisí na prostředí, ve kterém se provádí — dává stejný výsledek kdekoli.
Watcher planner (Watcher Planner) — část mechanismu rozhodování Watcher. Tento modul přijímá sadu akcí vygenerovaných strategií a vytváří pracovní plán, který určuje, jak v čase plánovat tyto různé akce a pro každou akci, jaké jsou předpoklady.
Cíle a strategie Watcher
Cíl
Strategie
Dummy cíl
Dummy Strategie
Dummy Strategie využívající vzorové hodnotící enginy
Dummy strategie s přeškálováním
Úspora energie
Strategie úspory energie
Konsolidace serverů
Základní offline konsolidace serverů
Strategie konsolidace pracovních zátěží VM
Vyvážení pracovních zátěží
Strategie migrace vyvážení pracovních zátěží
Strategie vyvážení kapacity úložiště
Stabilizace pracovních zátěží
Hlučný soused
Hlučný soused
Tepelná optimalizace
Strategie založená na teplotě výstupu
Optimalizace proudění vzduchu
Strategie migrace rovnoměrného proudění vzduchu
Údržba hardwaru
Migrace zón
Nezařazeno
Aktuátor
Dummy cíl — rezervovaný cíl, který se používá pro testování (reserved goal that is used for testing purposes).
Související strategie: Dummy Strategie, Dummy Strategie využívající vzorové hodnotící enginy a Dummy strategie s přeškálováním. Dummy strategie — fiktivní strategie používaná pro integrační testování pomocí Tempest. Tato strategie neposkytuje žádnou užitečnou optimalizaci, její jediný cíl je provádět testy Tempest.
Dummy strategie využívající vzorové hodnotící enginy — strategie, která je podobná předchozí, liší se pouze využitím vzoru “hodnotícího enginu”, který provádí výpočty pomocí metod strojového učení.
Dummy strategie s přeškálováním — strategie, která je podobná předchozí, liší se pouze využitím změny flavoru (migrace a přeškálování).
Není používána v produkci.
Úspora energie — minimalizovat spotřebu energie. Strategie cíle úspory energie společně se strategií konsolidace pracovních zátěží VM (Server Consolidation) je schopna vykonávat funkce dynamického řízení napájení (DPM), které šetří elektřinu díky dynamické konsolidaci pracovních zátěží i během období nízkého zatížení zdrojů: virtuální stroje se přenášejí na menší počet uzlů a nepotřebné uzly se vypínají. Po konsolidaci strategie navrhuje řešení pro zapnutí/vypnutí uzlů podle zadaných parametrů: “min_free_hosts_num” — počet volných zapnutých uzlů čekajících na zátěž, a “free_used_percent” — procentuální poměr volných zapnutých uzlů k počtu uzlů, které jsou obsazeny stroji. Pro fungování strategie musí být aktivován a nastaven Ironic pro práci se zapínáním/vypínáním napájení na uzlech.
Parametry strategie
parametr
typ
ve výchozím nastavení
popis
free_used_percent
Číslo
10.0
poměr počtu volných výpočetních uzlů k počtu výpočetních uzlů s virtuálními stroji
min_free_hosts_num
Int
1
minimální počet volných výpočetních uzlů
V cloudu musí být minimálně dva uzly. Použitá metoda je změna stavu napájení uzlu (change_node_power_state). Sbírání metrik strategie není potřeba.
Server Consolidation – minimalizace počtu výpočetních uzlů (konsolidace). Má dvě strategie: Basic Offline Server Consolidation a VM Workload Consolidation Strategy.
Strategie Basic Offline Server Consolidation minimalizuje celkové množství používaných serverů a také minimalizuje počet migrací.
Základní strategie vyžaduje následující metriky:
metrika
služba
plugins
komentář
compute.node.cpu.percent
none
cpu_util
none
Parametry strategie: migration_attempts – počet kombinací pro hledání potenciálních kandidátů na vypnutí (výchozí, 0, bez omezení), period – časový interval v sekundách pro získání statické agregace z datového zdroje metriky (výchozí, 700).
Používané metody: migrace, změna stavu služby nova (change_nova_service_state).
Strategie VM Workload Consolidation Strategy je založena na heuristickém algoritmu prvního vyhovujícího (first-fit), který se zaměřuje na měřenou zátěž CPU a snaží se minimalizovat uzly, které mají příliš velkou nebo příliš malou zátěž s ohledem na omezení kapacity zdrojů. Tato strategie poskytuje řešení, které vede k efektivnějšímu využití zdrojů clusteru, používající následující čtyři fáze:
- Fáze odlehčení – zpracování přečerpávaných zdrojů;
- Fáze konsolidace – zpracování nedostatečně využívaných zdrojů;
- Optimalizace řešení – snížení počtu migrací;
- Vypnutí nevyužívaných výpočetních uzlů.
Strategie vyžaduje následující metriky:
metrika
služba
plugins
komentář
memory
none
disk.root.size
none
Následující metriky nejsou povinné, ale zvyšují přesnost strategie, pokud jsou dostupné:
metrika
služba
plugins
komentář
memory.resident
none
cpu_util
none
Parametry strategie: period – časový interval v sekundách pro získání statické agregace z datového zdroje metriky (výchozí, 3600).
Používá ty samé metody jako předchozí strategie. Více informací .
Vyvážení pracovních zátěží – vyvážit pracovní zatížení mezi výpočetními uzly. Cíl má tři strategie: Workload Balance Migration Strategy, Workload stabilization, Storage Capacity Balance Strategy.
Strategie migrace na základě zatížení spouští migrace virtuálních strojů na základě zatížení virtuálních strojů uzlů. Rozhodnutí o přesunu se dělá vždy, když % využití CPU nebo RAM uzlu překročí stanovený práh. Přitom se přesouvaný virtuální stroj musí přiblížit průměrnému zatížení všech uzlů.
Požadavky
- Použití fyzických procesorů;
- Minimálně dva fyzické výpočetní uzly;
- Nainstalovaná a nakonfigurovaná součást Ceilometer — ceilometer-agent-compute fungující na každém výpočetním uzlu, a API Ceilometer, stejně jako sběr následujících metrik:
metrika
služba
plugins
komentář
cpu_util
none
memory.resident
none
Parametry strategie:
parametr
typ
ve výchozím nastavení
popis
metrics
Řetězec
'cpu_util'
Metriky, které jsou základem: 'cpu_util', 'memory.resident'.
threshold
Číslo
25.0
Práh zátěže pro migraci.
period
Číslo
300
Celková doba trvání Ceilometeru.
Použitá metoda — migrace.
Stabilizace zatížení — strategie zaměřená na stabilizaci zatížení pomocí živé migrace. Strategie je založena na algoritmu standardní odchylky a určuje, zda v clusteru dochází k přetížení, a reaguje na něj spuštěním migrace strojů za účelem stabilizace clusteru.
Požadavky
- Použití fyzických procesorů;
- Minimálně dva fyzické výpočetní uzly;
- Nainstalovaná a nakonfigurovaná součást Ceilometer — ceilometer-agent-compute fungující na každém výpočetním uzlu, a API Ceilometer, stejně jako sběr následujících metrik:
metrika
služba
plugins
komentář
cpu_util
none
memory.resident
none
Strategie vyrovnání kapacity úložiště (strategii je možné realizovat od verze Queens) — strategie přesouvá disky na základě zatížení Cinder poolů. Rozhodnutí o přesunu se dělá vždy, když poměr využití poolu překročí stanovený práh. Přesouvaný disk musí přiblížit pool k průměrné zátěži všech Cinder poolů.
Požadavky a omezení
- Minimálně dva Cinder pooly;
- Možnost migrace disků.
- Model dat clusteru — sběrač dat modelu Cinder cluster.
Parametry strategie:
parametr
typ
ve výchozím nastavení
popis
volume_threshold
Číslo
80.0
Práhová hodnota disků pro vyvážení objemů.
Použitá metoda — migrace disku (volume_migrate).
Noisy Neighbor — identifikovat a přesunout "hlukového souseda" — virtuálním strojům s nízkou prioritou, která negativně ovlivňuje výkon virtuálních strojů s vysokou prioritou z pohledu IPC, nadměrně využívající Last Level Cache. Vlastní strategie: Noisy Neighbor (používaný parametr strategie — cache_threshold (výchozí hodnota — 35), při poklesu výkonu na stanovenou hodnotu se spustí migrace. Pro fungování strategie jsou nutné zapnuté LLC (Last Level Cache) metriky, poslední server Intel s podporou CMT, stejně jako sběr následujících metrik:
metrika
služba
plugins
komentář
cpu_l3_cache
none
Nutný Intel .
Model datového klastru (výchozí): Nova cluster data model collector. Použitá metoda — migrace.
Práce s tímto cílem prostřednictvím Dashboardu nebyla plně implementována v Queens.
Tepelná optimalizace — optimalizovat teplotní režim. Teplota na výstupu (odtahový vzduch) je jedním z důležitých tepelných telemetrických systémů pro měření stavu tepelného / provozního zatížení serveru. Pro tento cíl existuje jedna strategie — Outlet temperature based strategy, která rozhoduje o přesouvání pracovních zátěží na uzly s příznivým teplotním režimem (nejnižší teplota na výstupu), když teplota na výstupu původních hostitelů dosáhne nastavitelného prahu.
Pro fungování strategie je potřebný server s nainstalovaným a nakonfigurovaným Intel Power Node Manager , stejně jako sběr následujících metrik:
metrika
služba
plugins
komentář
hardware.ipmi.node.outlet_temperature
IPMI
Parametry strategie:
parametr
typ
ve výchozím nastavení
popis
threshold
Číslo
35.0
Teplotní práh pro migraci.
period
Číslo
30
Časový interval v sekundách pro získání statistické agregace z datového zdroje metriky.
Použitá metoda — migrace.
Optimalizace proudění vzduchu — optimalizovat režim větrání. Vlastní strategie — Uniform Airflow using live migration. Tato strategie spouští migraci virtuálního stroje vždy, když vzdušný tok z ventilátoru serveru překročí stanovený práh.
Pro fungování strategie jsou potřebné:
- Hardware: výpočetní uzly <s podporou NodeManager 3.0;
- Minimálně dva výpočetní uzly;
- Nainstalovaný a nastavený komponent ceilometer-agent-compute na každém výpočetním uzlu a Ceilometer API, které může úspěšně oznamovat metriky jako průtok vzduchu, výkon systému, teplota na vstupu:
metrika
služba
plugins
komentář
hardware.ipmi.node.airflow
IPMI
hardware.ipmi.node.temperature
IPMI
hardware.ipmi.node.power
IPMI
Pro fungování strategie je potřebný server s nainstalovaným a nakonfigurovaným Intel Power Node Manager 3.0 nebo novější.
Omezení: Koncept není určen pro produkci.
Doporučuje se tento algoritmus používat s kontinuálními audity, protože během jedné iterace se plánuje migrace pouze jednoho virtuálního stroje.
Jsou možné živé migrace.
Parametry strategie:
parametr
typ
ve výchozím nastavení
popis
threshold_airflow
Číslo
400.0
Práh průtoku vzduchu pro migraci Jednotka je 0.1 CFM
threshold_inlet_t
Číslo
28.0
Práh teploty na vstupu pro rozhodování o migraci
threshold_power
Číslo
350.0
Práh výkonu systému pro rozhodování o migraci
period
Číslo
30
Časový interval v sekundách pro získání statistické agregace z datového zdroje metriky.
Použitá metoda — migrace.
Údržba hardwaru — údržba hardwaru. Strategie související s tímto cílem je migrace zóny. Tato strategie je nástrojem pro efektivní automatickou a minimální migraci virtuálních strojů a disků v případě potřeby provedení technické údržby hardwaru. Strategie stanovuje plán akcí podle vah: akce s větší vahou budou naplánovány dříve než ostatní. Existují dva konfigurační parametry: váhy akcí (action_weights) a paralelizace (parallelization).
Omezení: je nutné nastavit váhy akcí a paralelizaci.
Parametry strategie:
parametr
typ
ve výchozím nastavení
popis
výpočetní_uzly
pole
None
Výpočetní uzly pro migraci.
úložiště_pools
pole
None
Úložiště uzlů pro migraci.
celkový_paralelní
celé číslo
6
Celkový počet akcí, které by měly být prováděny paralelně.
paralelně_na_uzel
celé číslo
2
Počet akcí prováděných paralelně pro každý výpočetní uzel.
paralelně_na_pool
celé číslo
2
Počet akcí prováděných paralelně pro každý úložiště pool.
priority
objekt
None
Seznam priorit pro virtuální stroje a disky.
s_připojeným_objem
boolean
Při provádění scénáře Nornir se do konzole vyprodukují podrobné logy.
False — virtuální stroje budou převedeny po přesunu všech disků. True — virtuální stroje budou převedeny po migraci všech připojených disků.
Prvky pole výpočetních uzlů:
parametr
typ
ve výchozím nastavení
popis
zdrojový_uzel
string
None
Výpočetní uzel, ze kterého se migrují virtuální stroje (povinné).
cílový_uzel
string
None
Výpočetní uzel, na který se migrují virtuální stroje.
Prvky pole úložiště uzlů:
parametr
typ
ve výchozím nastavení
popis
zdrojový_pool
string
None
Úložiště pool, ze kterého se migrují disky (povinné).
cílový_pool
string
None
Úložiště pool, na který se migrují disky.
zdrojový_typ
string
None
Typ disku (povinné).
cílový_typ
string
None
Konečný typ disku (povinné).
Prvky objektů s prioritou:
parametr
typ
ve výchozím nastavení
popis
projekt
pole
None
Názvy projektů.
výpočetní_uzel
pole
None
Názvy výpočetních uzlů.
úložiště_pool
pole
None
Názvy úložišť pool.
výpočetní
enum
None
Parametry virtuálního stroje [“vcpu_num”, “mem_size”, “disk_size”, “created_at”].
úložiště
enum
None
Parametry disků [“size”, “created_at”].
Používané metody — migrace virtuálních strojů, migrace disků.
Nezařazeno — pomocný cíl, který se používá ke zjednodušení procesu vývoje strategie. Neobsahuje specifikace a může být použit kdykoli, když strategie ještě není spojena se stávajícím cílem. Tento cíl může být také použit jako přechodná fáze. Strategií spojenou s tímto cílem je Akční člen.
Vytváření nového cíle
Watcher Decision Engine má rozhraní pluginu „externí cíl“, které umožňuje integrovat externí cíl, který může být dosažen pomocí strategie.
Než vytvoříte nový cíl, měli byste se ujistit, že žádný z existujících cílů neodpovídá vašim potřebám.
Vytvoření nového pluginu
Abyste vytvořili nový cíl, musíte: rozšířit třídu cíle, implementovat metodu třídy get_name () , která vrátí unikátní identifikátor nového cíle, který chcete vytvořit. Tento unikátní identifikátor by měl odpovídat názvu vstupního bodu, který později deklarujete.
Dále je třeba implementovat metodu třídy get_display_name () , která vrátí přeložené zobrazené jméno cíle, který chcete vytvořit (nepoužívejte proměnnou k vracení přeloženého řetězce, aby mohla být automaticky sestavena nástrojem pro překlad.).
Implementujte metodu třídy get_translatable_display_name (), abyste vrátili klíč překladu (vlastně anglické zobrazené jméno) vašeho nového cíle. Vrácená hodnota by měla odpovídat řetězci, který je přeložen v get_display_name ().
Implementujte jeho metodu get_efficacy_specification (), abyste vrátili specifikaci účinnosti pro váš cíl. Metoda get_efficacy_specification () vrací instanci Unclassified (), kterou poskytuje Watcher. Tato specifikace účinnosti je užitečná během vývoje vašeho cíle, protože odpovídá prázdné specifikaci.
→
Architektura Watcher (více ).
Komponenty
Watcher API — komponenta implementující REST API poskytované Watcherem. Mechanismy interakce: CLI, plugin Horizon, Python SDK.
Watcher DB — databáze Watcher.
Watcher Applier — komponenta, která implementuje provádění plánu akcí vytvořeného komponentou Watcher Decision Engine.
Watcher Decision Engine — komponenta zodpovědná za výpočet souboru potenciálních akcí optimalizace k provedení auditu cíle. Pokud není strategie určena, komponenta si sama vybere nejvhodnější.
Watcher Metrics Publisher — komponenta, která shromažďuje a počítá určité metriky nebo události a publikuje je na koncovém bodě CEP. Funkčnost komponenty může být zajištěna také publikátorem Ceilometer.
Engin pro zpracování složitých událostí (CEP) — motor pro komplexní zpracování událostí. Z hlediska výkonu může být několik instancí CEP Engine běžících současně, z nichž každá zpracovává určitý typ metriky / událostí. V systému Watcher CEP spouští dva typy akcí: — zapisovat příslušné události / metriky do databáze časových řad; — posílat příslušné události do komponenty Watcher Decision Engine, když tato událost může ovlivnit výsledek aktuální strategie optimalizace, protože cluster Openstack není statickým systémem.
Interakce komponentů probíhá protokolem AMQP.
→
Schéma interakce s Watcher
Výsledky testování Watcher
- Na stránce Optimalizace — Akční plány se objeví chyba 500 (jak na čistém Queens, tak na stojanu s moduly Tionix), což se stává pouze po spuštění auditu a generování akčního plánu, prázdná stránka se otevírá normálně.
- Na kartě Detaily akce se objevují chyby, nelze získat cíl a strategii auditu (jak na čistém Queens, tak na stojanu s moduly Tionix).
- Audity s cílem Dummy (testovací) se vytvářejí a spouštějí normálně, generují se akční plány.
- Audity s cílem Unclassified se nevytvářejí, protože cíl není funkční a je určen pro mezistupňové nastavení při vytváření nových strategií.
- Audity s cílem Workload Balancing (strategie Storage Capacity balance) se úspěšně vytvářejí, avšak akční plán se nežene. Optimalizace úložišť není nutná.
- Audity s cílem Workload Balancing (strategie Workload Balance Migration Strategy) se úspěšně vytvářejí, avšak akční plán se nežene.
- Audity s cílem Workload Balancing (strategie Workload Stabilization Strategy) končí chybou.
- Audity s cílem Noisy Neighbor se úspěšně vytvářejí, avšak akční plán se nežene.
- Audity s cílem Hardware maintenance se úspěšně vytvářejí, akční plán se generuje neúplně (výkonnostní ukazatele se generují, ale seznam akcí sám se nevytváří).
- Úpravy v konfiguračních souborech nova.conf (v sekci default compute_monitors = cpu.virt_driver) na výpočetních a řídicích uzlech neodstraňují chyby.
- Audity s cílem Server Consolidation (strategie Basic) také končí chybou.
- Audity s cílem Server Consolidation (strategie VM workload consolidation) končí chybou. V logách se objevuje chyba při získávání zdrojových dat. Diskuze o chybě, konkrétně, .
Snažili jsme se upravit konfigurační soubor Watcher (nepomohlo - výsledkem jsou chyby na všech stránkách Optimalizace, návrat k původnímu obsahu konfiguračního souboru situaci neřeší):[watcher_strategies.basic]
datasource = ceilometer, gnocchi - Audity s cílem Úspory energie končí chybou. Podle logů problém skutečně spočívá v absenci Ironic, bez baremetal služby to nebude fungovat.
- Audity s cílem Tepelné optimalizace končí chybou. Traceback je stejný jako u Konsolidace serverů (strategie konsolidace pracovní zátěže VM) (chyba vstupních dat)
- Audity s cílem Optimalizace Airflow končí chybou.
Objevují se také následující chyby při ukončení auditu. Traceback v logách decision-engine.log (stav clusteru není určen).
→ Diskuze k chybě
Závěr
Výsledkem našich dvouměsíčních výzkumů je jednoznačný závěr, že k dosažení plnohodnotného, funkčního systému vyvažování zatížení se budeme muset v této oblasti intenzivně věnovat vylepšení nástrojů pro platformu Openstack.
Watcher se ukázal jako seriózní a rychle se vyvíjející produkt s obrovským potenciálem, pro jehož plnohodnotné využití bude zapotřebí velké a důkladné práce.
Ale o tom - v následujících článcích cyklu.
Zdroj: habr.com
