V Informovali jsme o pokusech využívat Watcher a představili jsme zprávu o testech. Tyto testy občas provádíme pro vyvážení a další kritické funkce velkého podnikového nebo operátorského cloudu.
Vysoká složitost řešeného úkolu si může vyžádat několik článků k popisu našeho projektu. Dnes publikujeme druhý článek cyklu, věnovaný vyvažování virtuálních strojů v cloudu.
Trochu terminologie
Společnost VmWare zavedla nástroj DRS (Distributed Resource Scheduler) pro vyvažování zátěže v jejich navrženém a nabízeném prostředí virtualizace.
Jak píše
„VMware DRS (Plánovač distribuovaných zdrojů) je nástroj, který vyvažuje výpočetní zátěže s dostupnými prostředky ve virtuálním prostředí. Nástroj je součástí balíčku virtualizace nazvaného VMware Infrastructure.
Pomocí VMware DRS uživatelé definují pravidla pro rozdělení fyzických zdrojů mezi virtuálními stroji (VM). Nástroj může být nastaven na manuální nebo automatické řízení. Skupiny zdrojů VMware lze snadno přidávat, odstraňovat nebo reorganizovat. Při přání mohou být skupiny zdrojů izolovány mezi různými obchodními jednotkami. Pokud se zátěž na jednom nebo více virtuálních strojích náhle změní, VMware DRS převezme virtuální stroje mezi fyzickými servery. Pokud celková zátěž klesá, některé fyzické servery mohou být dočasně vypnuty a zátěž konsolidována.
Proč je potřeba vyvažování?
Podle našeho názoru je DRS nezbytnou funkcí cloudu, což však neznamená, že DRS musí být používáno vždy a všude. V závislosti na určení a potřebách cloudu mohou existovat různé požadavky na DRS a metody vyvažování. Může existovat situace, kdy vyvažování není vůbec potřeba. Nebo dokonce může být škodlivé.
Aby bylo lépe pochopeno, kde a pro jaké klienty je DRS potřeba, podívejme se na jejich cíle a úkoly. Cloudu lze rozdělit na veřejné a soukromé. Zde jsou hlavní rozdíly mezi těmito cloudy a cíli klientů.
Soukromé cloudy / Velké podnikové klienty
Veřejné cloudy / Střední a malé podniky, lidé
Hlavní kritérium a cíle operátora
Poskytování spolehlivých služeb nebo produktů
Snížení nákladů na služby ve konkurenceschopném trhu
Požadavky na službu
Spolehlivost na všech úrovních a ve všech prvcích systému
Zaručený výkon
Prioritizace virtuálních strojů do několika kategorií
Informační a fyzická bezpečnost dat
SLA a nepřetržitá podpora
Maximální jednoduchost získání služby
Relativně jednoduché služby
Odpovědnost za data leží na klientovi
Prioritizace VM není požadována
Informační bezpečnost na úrovni standardních služeb, odpovědnost na klientovi
Mohou nastat výpadky
Žádné SLA, kvalita není zaručena
Podpora e-mailem
Zálohování není povinné
Specifika klienta
Velmi široké spektrum aplikací.
Legacy aplikace, zděděné ve společnosti.
Složitá přizpůsobená architektura pro každého klienta.
Affinity pravidla.
Fungování softwaru bez přerušení v režimu 7x24.
Zálohování "za chodu".
Předvídatelná cyklická zátěž klienta.
Standardní aplikace – vyvažování sítě, Apache, WEB, VPN, SQL
Aplikace mohou být zastaveny na určitou dobu
Povoleno libovolné rozdělení VM v cloudu
Zálohování prováděné klientem
Předvídatelná statisticky průměrná zátěž při velkém počtu klientů.
Důsledky pro architekturu
Geoklastr
Centralizované nebo distribuované úložiště dat
Rezervované SD
Místní ukládání dat na výpočetních uzlech
Cíle vyvažování
Rovnoměrné rozložení zátěže
Maximální reakční schopnost aplikací
Minimální doba zpoždění při vyvažování
Vyvažování pouze v případě jednoznačné nutnosti
Vypnutí části zařízení na údržbu
Snížení nákladů na službu a nákladů operátora
Vypnutí části zdrojů v případě nízké zátěže
Úspora elektrické energie
Snížení nákladů na personál
Děláme si následující závěry:
Pro privátní cloudy, poskytované velkým korporátním zákazníkům, může být DRS používán s ohledem na následující omezení:
- informační bezpečnost a zohlednění affinity pravidel při vyvažování;
- dostatečné množství rezervních zdrojů v případě havárie;
- data virtuálních strojů se nacházejí na centralizovaném nebo distribuovaném úložišti.
- rozložení administrativních, zálohovacích a vyvažovacích procedur v čase;
- vyvažování pouze uvnitř aglomerace hostitelů klienta;
- vyvažování pouze při silném nerovnováze, nejúčinnější a nejbezpečnější migrace VM (protože migrace může skončit neúspěšně);
- vyvažování vzhledem k „klidným“ virtuálním strojům (migrace „rušných“ virtuálních strojů může trvat velmi dlouho);
- vyvažování s ohledem na „náklady“ — zátěž na úložné systémy a síť (při přizpůsobených architekturách pro velké klienty);
- vyvažování s ohledem na individuální chování každé VM;
- vyvažování ideálně během nepracovního času (v noci, o víkendech, během svátků).
Pro veřejné cloudy, které poskytují služby malým zákazníkům, může být DRS aplikováno mnohem častěji, s rozšířenými možnostmi:
- absence omezení informační bezpečnosti a pravidel afinity;
- vyvažování v rámci cloudu;
- vyvažování kdykoliv rozumně;
- vyvažování jakékoliv VM;
- vyvažování „rušných“ virtuálních strojů (aby neobtěžovaly ostatní);
- data virtuálních strojů často leží na lokálních discích;
- zohlednění průměrného výkonu úložných systémů a sítě (architektura cloudu je jednotná);
- vyvažování podle obecných pravidel a dostupné statistiky chování datových center.
Složitost problému
Složitost vyvažování spočívá v tom, že DRS musí pracovat s velkým množstvím neznámých faktorů:
- chování uživatelů každého z informačních systémů klientů;
- algoritmy chování serverů informačních systémů;
- chování serverů databázových systémů;
- zatížení výpočetních zdrojů, úložných systémů, sítě;
- vzájemné interakce serverů v boji o zdroje cloudu.
Zatížení velkého množství virtuálních serverů aplikací a databází na zdroje cloudu probíhá v průběhu času, následky se mohou projevovat a navzájem se překrývat s nepředvídatelným efektem v nepředvídatelném čase. I pro řízení poměrně jednoduchých procesů (například pro řízení motoru, systému vodního vytápění domu) musí systémy automatické regulace používat složité algoritmy se zpětnou vazbou.
Náš úkol je mnohem složitější a existuje riziko, že systém nebude schopen během rozumného času provést vyvážení zátěže na ustálené hodnoty, i když nebudou vznikat vnější vlivy od uživatelů.
Historie našich vývojů
Pro vyřešení tohoto problému jsme se rozhodli nezačínat od nuly, ale vycházet z existujících zkušeností, a začali jsme spolupracovat s odborníky, kteří mají zkušenosti v této oblasti. Naštěstí naše porozumění problematice se zcela shodovalo.
Fáze 1
Použili jsme systém založený na technologii neuronových sítí a pokusili jsme se optimalizovat naše zdroje na jeho základě.
Zájem této fáze spočíval v otestování nové technologie, její důležitost pak spočívala v aplikaci netradičního přístupu k řešení úkolu, kde za jinak stejných podmínek standardní přístupy prakticky vyčerpaly své možnosti.
Spustili jsme systém a skutečně nám začalo vyvážení fungovat. Měřítko našeho cloudu nám nedovolilo dosáhnout optimistických výsledků, jaké slibovali vývojáři, ale bylo vidět, že vyvážení funguje.
Přitom jsme měli dost vážná omezení:
- Aby neuronová síť mohla být vyučována, je třeba, aby virtuální stroje pracovaly bez podstatných změn po týdny nebo měsíce.
- Algoritmus je navržen pro optimalizaci na základě analýzy předchozích "historických" dat.
- Pro vyučování neuronové sítě je potřeba dostatečně velký objem dat a výpočetní zdroje.
- Optimalizaci a vyvážení lze provádět relativně zřídka – jednou za několik hodin, což je zjevně nedostatečné.
Fáze 2
Protože nás neuspokojovalo stávající postavení, rozhodli jsme se systém modifikovat, a proto odpovědět na hlavní otázku – pro koho to děláme?
Nejprve – pro firemní klienty. To znamená, že potřebujeme systém, který pracuje operativně, s těmi firemními omezeními, která jen usnadňují realizaci.
Druhá otázka – co chápat pod slovem „operativně“? Po krátkých debatách jsme se shodli, že můžeme vycházet z doby reakce 5 – 10 minut, aby krátkodobé skoky nezpůsobily, že se systém dostane do rezonance.
Třetí otázka – jakou velikost vyvažovaného počtu serverů zvolit?
Tato otázka se vyřešila sama. Obvykle klienti nedělají agregáty serverů příliš velké, a to odpovídá doporučením z článku o omezení agregátů na 30-40 serverů.
Dále segmentováním serverového poolu zjednodušujeme úkol pro vyvažovací algoritmus.
Čtvrtá otázka – jak moc nám vyhovuje neurální síť s jejím dlouhým procesem učení a vzácnými vyvažováními? Rozhodli jsme se od ní upustit ve prospěch jednodušších operativních algoritmů, abychom dosáhli výsledků během několika sekund.
S popisem systému, který využívá takové algoritmy a jeho nedostatků, se můžete seznámit
Implementovali jsme a spustili tento systém a získali povzbudivé výsledky – nyní pravidelně analyzuje zátěž cloudu a poskytuje doporučení na přesun virtuálních strojů, která jsou v podstatě správná. Už nyní je jasné, že můžeme dosáhnout uvolnění 10-15 % zdrojů pro nové virtuální stroje s zlepšením kvality práce existujících.
Při detekci nerovnováhy v RAM nebo CPU systém zasílá příkazy plánovači Tionix k provedení živé migrace potřebných virtuálních strojů. Jak ukazuje monitorovací systém, virtuální stroj se přesunul z jednoho (horního) na jiný (dolní) host a uvolnil paměť na horním hostu (označeno žlutými kruhy), čímž ji obsadil na dolním (označeno bílými kruhy).
Nyní se snažíme přesněji zhodnotit účinnost stávajícího algoritmu a pokoušíme se v něm najít možné chyby.
Fáze 3
Na první pohled by se mohlo zdát, že na tom můžeme skončit, počkat na prokázanou účinnost a uzavřít téma.
Ale nás k provedení nového kola vyzývají následující zřejmé možnosti optimalizace
- Statistika například a ukazuje, že dvou- a čtyřprocesorové systémy mají ve svém výkonu výrazně nižší výsledky než jednoproc. To znamená, že všichni uživatelé získávají zCPU, RAM, SSD, LAN, FC nakoupené v víceprocesorových systémech mnohem menší výkon ve srovnání s jednoproc.
- Sami plánovače zdrojů mohou pracovat s vážnými chybami, na toto téma.
- Technologie monitorování RAM a cache, nabízené společnostmi Intel a AMD, umožňují zkoumat chování virtuálních strojů a umisťovat je tak, aby "hlasití" sousedé nerušili "pokojné" virtuální stroje.
- Rozšíření souboru parametrů (síť, úložné systémy, priorita virtuálního stroje, náklady na migraci, připravenost na migraci).
Celkem
Výsledkem naší práce na vylepšení algoritmů vyvažování je jednoznačný závěr, že současné algoritmy mohou výrazně optimalizovat zdroje (25-30%) datových center a zároveň zlepšit kvalitu služeb pro zákazníky.
Algoritmus založený na neuronových sítích je bezesporu zajímavým, avšak vyžadujícím další rozvoj řešením, a vzhledem k existujícím omezením není vhodný pro řešení tohoto druhu úloh v objemech charakteristických pro soukromé cloudy. Na veřejných cloudech významných rozměrů však algoritmus vykázal dobré výsledky.
Podrobněji o možnostech procesorů, plánovačů a vysoceúrovňového vyvažování budeme hovořit v následujících článcích.
Zdroj: habr.com
