В mluvili jsme o našich pokusech používat Watcher a poskytli jsme testovací zprávu. Tyto testy pravidelně 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 problému může vyžadovat několik článků k popisu našeho projektu. Dnes publikujeme druhý článek ze série, věnovaný balancování virtuálních strojů v cloudu.
Nějaká terminologie
Společnost VmWare představila nástroj DRS (Distributed Resource Scheduler), který má vyvážit zátěž virtualizačního prostředí, které vyvinula a nabídla.
Podle
„VMware DRS (Distributed Resource Scheduler) je nástroj, který vyvažuje výpočetní zátěž s dostupnými zdroji ve virtuálním prostředí. Nástroj je součástí virtualizační sady s názvem VMware Infrastructure.
S VMware DRS uživatelé definují pravidla pro distribuci fyzických prostředků mezi virtuální stroje (VM). Nástroj lze nakonfigurovat pro ruční nebo automatické ovládání. Fondy prostředků VMware lze snadno přidávat, odebírat nebo reorganizovat. V případě potřeby lze fondy zdrojů izolovat mezi různými obchodními jednotkami. Pokud se zátěž na jednom nebo více virtuálních strojích dramaticky změní, VMware DRS přerozdělí virtuální stroje mezi fyzické servery. Pokud se celkové vytížení sníží, některé fyzické servery mohou být dočasně odpojeny a zátěž konsolidována."
Proč je potřeba vyvážení?
DRS je podle nás cloudová funkce, kterou musíte mít, i když to neznamená, že DRS je nutné používat vždy a všude. V závislosti na účelu a potřebách cloudu mohou existovat různé požadavky na DRS a metody vyvažování. Mohou nastat situace, kdy vyvažování není vůbec potřeba. Nebo dokonce škodlivé.
Abychom lépe porozuměli tomu, kde a pro které klienty je DRS potřeba, podívejme se na jejich cíle a záměry. Cloudy lze rozdělit na veřejné a soukromé. Zde jsou hlavní rozdíly mezi těmito cloudy a cíli zákazníků.
Privátní cloudy / klienti pro velké podniky
Veřejné cloudy / Střední a malé firmy, lidé
Hlavní kritérium a cíle provozovatele
Poskytování spolehlivé služby nebo produktu
Snížení nákladů na služby v boji na konkurenčním trhu
Požadavky na služby
Spolehlivost na všech úrovních a ve všech prvcích systému
Zaručený výkon
Upřednostněte virtuální stroje do několika kategorií
Zabezpečení informací a fyzických dat
SLA a nepřetržitá podpora
Maximální jednoduchost příjmu služby
Relativně jednoduché služby
Odpovědnost za data nese klient
Není vyžadována žádná priorita virtuálních počítačů
Informační bezpečnost na úrovni standardních služeb, zodpovědnost na klientovi
Mohou se vyskytnout závady
Žádná SLA, kvalita není zaručena
E-mailová podpora
Zálohování není nutné
Funkce klienta
Velmi široká škála aplikací.
Starší aplikace zděděné ve společnosti.
Komplexní vlastní architektury pro každého klienta.
Pravidla afinity.
Software funguje bez zastavení v režimu 7x24.
Zálohovací nástroje za běhu.
Předvídatelné cyklické zatížení zákazníků.
Typické aplikace – vyvažování sítě, Apache, WEB, VPN, SQL
Aplikace se může na chvíli zastavit
Umožňuje libovolnou distribuci virtuálních počítačů v cloudu
Záloha klienta
Předvídatelná statisticky zprůměrovaná zátěž s velkým počtem klientů.
Důsledky pro architekturu
Geoclustering
Centralizované nebo distribuované úložiště
Rezervováno IBS
Lokální úložiště dat na výpočetních uzlech
Vyvážení cílů
Rovnoměrné rozložení zátěže
Maximální odezva aplikace
Minimální doba zpoždění pro vyvážení
Vyvažování pouze v nezbytně nutných případech
Přineste nějaké zařízení na preventivní údržbu
Snížení nákladů na služby a nákladů na operátora
Zakázání některých zdrojů v případě nízké zátěže
Úspora energie
Snížení osobních nákladů
Sami pro sebe vyvozujeme následující závěry:
Pro privátní cloudyposkytované velkým korporátním zákazníkům lze DRS používat za následujících omezení:
- informační bezpečnost a zohlednění pravidel afinity při vyvažování;
- dostupnost dostatečných zdrojů v rezervě pro případ havárie;
- data virtuálního stroje jsou umístěna v centralizovaném nebo distribuovaném úložném systému;
- časové oddělení procedur administrace, zálohování a vyvažování;
- balancování pouze v rámci skupiny klientských hostitelů;
- vyvažování pouze při silné nerovnováze, nejúčinnější a nejbezpečnější migrace VM (migrace může selhat);
- vyvážení relativně „tichých“ virtuálních strojů (migrace „hlučných“ virtuálních strojů může trvat velmi dlouho);
- vyvažování zohledňující „náklady“ – zatížení úložného systému a sítě (s přizpůsobenými architekturami pro velké klienty);
- vyvažování zohledňující individuální charakteristiky chování každého VM;
- Balancování se přednostně provádí v mimopracovní době (noci, víkendy, svátky).
Pro veřejné cloudyposkytující služby malým zákazníkům lze DRS používat mnohem častěji s pokročilými funkcemi:
- absence omezení bezpečnosti informací a pravidel afinity;
- balancování v rámci cloudu;
- vyvažování v jakoukoli rozumnou dobu;
- vyvažování jakéhokoli VM;
- vyvážení „hlučných“ virtuálních strojů (aby nerušily ostatní);
- data virtuálního stroje jsou často umístěna na místních discích;
- zohlednění průměrného výkonu úložných systémů a sítí (cloudová architektura je jednotná);
- vyvažování podle obecných pravidel a dostupných statistik chování datových center.
Složitost problému
Obtížnost vyvažování spočívá v tom, že DRS musí pracovat s velkým počtem nejistých faktorů:
- chování uživatelů jednotlivých informačních systémů klientů;
- Algoritmy pro provoz serverů informačních systémů;
- chování serverů DBMS;
- zatížení výpočetních zdrojů, úložných systémů, sítě;
- interakce serverů mezi sebou v boji o cloudové zdroje.
K zatížení velkého množství virtuálních aplikačních serverů a databází na cloudových zdrojích dochází v průběhu času, důsledky se mohou projevit a vzájemně se překrývat s nepředvídatelným efektem v nepředvídatelnou dobu. Dokonce i pro řízení relativně jednoduchých procesů (například pro řízení motoru, systému ohřevu vody v domácnosti) potřebují automatické řídicí systémy používat složité algoritmy se zpětnou vazbou.
Náš úkol je o mnoho řádů složitější a hrozí, že systém nebude schopen v rozumném čase vyrovnat zátěž na stanovené hodnoty, a to i v případě nepřítomnosti vnějších vlivů ze strany uživatelů.
Historie našeho vývoje
Abychom tento problém vyřešili, rozhodli jsme se nezačít od nuly, ale stavět na stávajících zkušenostech a začali jsme komunikovat se specialisty se zkušenostmi v této oblasti. Naštěstí se naše chápání problému zcela shodovalo.
Krok 1
Použili jsme systém založený na technologii neuronových sítí a snažili jsme se na jeho základě optimalizovat naše zdroje.
Zájmem této etapy bylo testování nové technologie a její význam spočíval v aplikaci nestandardního přístupu k řešení problému, kde se za jinak stejných podmínek standardní přístupy prakticky vyčerpaly.
Spustili jsme systém a skutečně jsme začali balancovat. Rozsah našeho cloudu nám neumožnil získat optimistické výsledky uváděné vývojáři, ale bylo jasné, že vyvažování funguje.
Zároveň jsme měli docela vážná omezení:
- Aby bylo možné trénovat neuronovou síť, musí virtuální stroje běžet bez výrazných změn týdny nebo měsíce.
- Algoritmus je navržen pro optimalizaci na základě analýzy dřívějších „historických“ dat.
- Trénink neuronové sítě vyžaduje poměrně velké množství dat a výpočetních zdrojů.
- Optimalizaci a vyvážení lze provádět poměrně zřídka – jednou za pár hodin, což zjevně nestačí.
Krok 2
Protože jsme nebyli spokojeni se stavem věcí, rozhodli jsme se systém upravit a k tomu odpovědět hlavní otázka – pro koho to děláme?
První – pro firemní klientelu. To znamená, že potřebujeme systém, který funguje rychle, s těmi firemními omezeními, která pouze zjednodušují implementaci.
Druhá otázka – co myslíte slovem „okamžitě“? Na základě krátké debaty jsme se rozhodli, že můžeme začít s dobou odezvy 5–10 minut, aby krátkodobé přepětí neuvedlo systém do rezonance.
Třetí otázka – jakou velikost vyváženého počtu serverů zvolit?
Tento problém se vyřešil sám. Klienti obvykle nedělají agregace serverů příliš velké, což je v souladu s doporučeními v článku omezit agregace na 30–40 serverů.
Segmentováním serverového fondu navíc zjednodušujeme úlohu vyvažovacího algoritmu.
Čtvrtá otázka – jak vhodná je pro nás neuronová síť se svým dlouhým procesem učení a vzácným balancováním? Rozhodli jsme se to opustit ve prospěch jednodušších operačních algoritmů, abychom získali výsledky během několika sekund.
Lze nalézt popis systému, který takovéto algoritmy používá, a jeho nevýhody
Tento systém jsme implementovali a spustili a obdrželi jsme povzbudivé výsledky – nyní pravidelně analyzuje zatížení cloudu a dává doporučení pro přesun virtuálních strojů, která jsou z velké části správná. Již nyní je jasné, že můžeme dosáhnout 10-15% uvolnění zdrojů pro nové virtuální stroje a zároveň zlepšit kvalitu práce těch stávajících.
Když je zjištěna nerovnováha v RAM nebo CPU, systém vydá příkazy plánovači Tionix, aby provedl živou migraci požadovaných virtuálních strojů. Jak je patrné z monitorovacího systému, virtuální stroj se přesunul z jednoho (horního) na druhého (nižšího) hostitele a uvolnil paměť na horním hostiteli (zvýrazněno žlutými kroužky), respektive obsadil ji na spodním (zvýrazněno bíle kruhy).
Nyní se snažíme přesněji posoudit efektivitu současného algoritmu a snažíme se v něm najít možné chyby.
Krok 3
Zdálo by se, že se na to dá uklidnit, počkat na prokázanou účinnost a téma uzavřít.
K provedení nové etapy nás však nutí následující zřejmé možnosti optimalizace
- Statistiky např. и ukazuje, že dvou- a čtyřprocesorové systémy mají výrazně nižší výkon než jednoprocesorové systémy. To znamená, že všichni uživatelé dostávají výrazně méně výstupu z CPU, RAM, SSD, LAN, FC zakoupených ve víceprocesorových systémech ve srovnání s jednoprocesorovými systémy.
- Samotné plánovače zdrojů mohou mít vážné chyby, na toto téma.
- Technologie nabízené společnostmi Intel a AMD pro monitorování RAM a mezipaměti umožňují studovat chování virtuálních strojů a umístit je tak, aby „hluční“ sousedé nerušili „tiché“ virtuální stroje.
- Rozšíření sady parametrů (síť, úložný systém, priorita virtuálního stroje, náklady na migraci, jeho připravenost k migraci).
Celkem
Výsledkem naší práce na vylepšení balančních algoritmů byl jednoznačný závěr, že pomocí moderních algoritmů je možné dosáhnout výrazné optimalizace zdrojů datového centra (25-30 %) a zároveň zlepšit kvalitu zákaznických služeb.
Algoritmus založený na neuronových sítích je samozřejmě zajímavým řešením, ale potřebuje další vývoj a vzhledem k existujícím omezením není vhodný pro řešení tohoto druhu problémů na objemech typických pro privátní cloudy. Algoritmus zároveň ukázal dobré výsledky ve veřejných cloudech významné velikosti.
Více o možnostech procesorů, plánovačů a vyvažování na vysoké úrovni vám povíme v následujících článcích.
Zdroj: www.habr.com