В hovorili sme o našich pokusoch používať Watcher a poskytli sme testovaciu správu. Takéto testy pravidelne vykonávame na vyváženie a iné kritické funkcie veľkého podniku alebo operátorského cloudu.
Vysoká zložitosť riešeného problému môže vyžadovať niekoľko článkov na popis nášho projektu. Dnes uverejňujeme druhý článok zo série venovaný balansovaniu virtuálnych strojov v cloude.
Nejaká terminológia
Spoločnosť VmWare predstavila utilitu DRS (Distributed Resource Scheduler) na vyváženie zaťaženia virtualizačného prostredia, ktoré vyvinuli a ponúkali.
Ako píše
„VMware DRS (Distributed Resource Scheduler) je nástroj, ktorý vyrovnáva výpočtovú záťaž s dostupnými zdrojmi vo virtuálnom prostredí. Nástroj je súčasťou virtualizačného balíka s názvom VMware Infrastructure.
Pomocou VMware DRS používatelia definujú pravidlá pre distribúciu fyzických zdrojov medzi virtuálne stroje (VM). Nástroj je možné nakonfigurovať na manuálne alebo automatické ovládanie. Fondy zdrojov VMware možno jednoducho pridávať, odstraňovať alebo reorganizovať. V prípade potreby možno fondy zdrojov izolovať medzi rôznymi obchodnými jednotkami. Ak sa pracovná záťaž na jednom alebo viacerých virtuálnych strojoch dramaticky zmení, VMware DRS prerozdelí virtuálne stroje medzi fyzické servery. Ak sa celková pracovná záťaž zníži, niektoré fyzické servery môžu byť dočasne prepnuté do režimu offline a pracovné zaťaženie sa skonsoliduje."
Prečo je potrebná rovnováha?
Podľa nášho názoru je DRS nevyhnutnou cloudovou funkciou, aj keď to neznamená, že DRS sa musí používať vždy a všade. V závislosti od účelu a potrieb cloudu môžu existovať rôzne požiadavky na DRS a metódy vyvažovania. Môžu nastať situácie, keď balansovanie vôbec nie je potrebné. Alebo dokonca škodlivé.
Aby sme lepšie porozumeli tomu, kde a pre ktorých klientov je DRS potrebná, zvážme ich ciele a zámery. Cloudy možno rozdeliť na verejné a súkromné. Tu sú hlavné rozdiely medzi týmito cloudmi a cieľmi zákazníkov.
Privátne cloudy / klienti pre veľkých podnikov
Verejné cloudy / Stredné a malé firmy, ľudia
Hlavné kritérium a ciele prevádzkovateľa
Poskytovanie spoľahlivej služby alebo produktu
Znižovanie nákladov na služby v boji na konkurenčnom trhu
Požiadavky na služby
Spoľahlivosť na všetkých úrovniach a vo všetkých systémových prvkoch
Zaručený výkon
Uprednostnite virtuálne stroje do niekoľkých kategórií
Bezpečnosť informácií a fyzických údajov
SLA a XNUMX/XNUMX podpora
Maximálna jednoduchosť prijímania služby
Relatívne jednoduché služby
Zodpovednosť za údaje nesie klient
Nevyžaduje sa žiadne uprednostňovanie virtuálnych počítačov
Informačná bezpečnosť na úrovni štandardných služieb, zodpovednosť na klientovi
Môžu sa vyskytnúť poruchy
Žiadna SLA, kvalita nie je zaručená
E-mailová podpora
Zálohovanie nie je potrebné
Vlastnosti klienta
Veľmi široká škála aplikácií.
Staršie aplikácie zdedené v spoločnosti.
Komplexné vlastné architektúry pre každého klienta.
Pravidlá afinity.
Softvér funguje bez zastavenia v režime 7x24.
Zálohovacie nástroje za chodu.
Predvídateľné cyklické zaťaženie zákazníkov.
Typické aplikácie – vyvažovanie siete, Apache, WEB, VPN, SQL
Aplikácia sa môže na chvíľu zastaviť
Umožňuje ľubovoľnú distribúciu virtuálnych počítačov v cloude
Záloha klienta
Predvídateľné štatisticky spriemerované zaťaženie pri veľkom počte klientov.
Dôsledky pre architektúru
Geoklastrovanie
Centralizované alebo distribuované úložisko
Vyhradené IBS
Lokálne ukladanie dát vo výpočtových uzloch
Vyváženie cieľov
Rovnomerné rozloženie zaťaženia
Maximálna odozva aplikácie
Minimálny čas oneskorenia pre vyváženie
Vyvažovanie len vtedy, keď je to jednoznačne nevyhnutné
Prineste nejaké vybavenie na preventívnu údržbu
Zníženie servisných nákladov a nákladov operátora
Zakázanie niektorých zdrojov v prípade nízkej záťaže
Úspora energie
Zníženie osobných nákladov
Vyvodzujeme pre seba nasledujúce závery:
Pre privátne cloudyposkytovaná veľkým korporátnym zákazníkom, je možné DRS používať s nasledujúcimi obmedzeniami:
- informačná bezpečnosť a zohľadnenie pravidiel afinity pri bilancovaní;
- dostupnosť dostatočných zdrojov v rezerve v prípade nehody;
- dáta virtuálneho stroja sú umiestnené v centralizovanom alebo distribuovanom úložnom systéme;
- časovo náročné postupy správy, zálohovania a vyrovnávania;
- vyvažovanie iba v rámci skupiny klientskych hostiteľov;
- vyrovnávanie len vtedy, keď existuje silná nerovnováha, najefektívnejšie a najbezpečnejšie migrácie VM (migrácia môže napokon zlyhať);
- vyváženie relatívne „tichých“ virtuálnych strojov (migrácia „hlučných“ virtuálnych strojov môže trvať veľmi dlho);
- vyváženie s prihliadnutím na „náklady“ - zaťaženie úložného systému a siete (s prispôsobenými architektúrami pre veľkých klientov);
- vyváženie s prihliadnutím na individuálne charakteristiky správania každého VM;
- Bilancovanie sa prednostne vykonáva v mimopracovných hodinách (noci, víkendy, sviatky).
Pre verejné cloudypri poskytovaní služieb malým zákazníkom je možné DRS využívať oveľa častejšie s pokročilými funkciami:
- absencia obmedzení informačnej bezpečnosti a pravidiel afinity;
- vyrovnávanie v rámci cloudu;
- vyváženie v akomkoľvek primeranom čase;
- vyváženie akéhokoľvek VM;
- vyváženie „hlučných“ virtuálnych strojov (aby nerušili ostatných);
- dáta virtuálneho stroja sa často nachádzajú na lokálnych diskoch;
- berúc do úvahy priemerný výkon úložných systémov a sietí (cloudová architektúra je jednotná);
- vyváženie podľa všeobecných pravidiel a dostupných štatistík správania sa dátových centier.
Zložitosť problému
Problém vyvažovania je v tom, že DRS musí pracovať s veľkým počtom neistých faktorov:
- správanie používateľov každého informačného systému klienta;
- Algoritmy na prevádzku serverov informačných systémov;
- správanie serverov DBMS;
- zaťaženie výpočtových zdrojov, úložných systémov, siete;
- vzájomná interakcia serverov v boji o cloudové zdroje.
K zaťaženiu veľkého množstva virtuálnych aplikačných serverov a databáz na cloudových zdrojoch dochádza v priebehu času, dôsledky sa môžu prejaviť a vzájomne sa prekrývať s nepredvídateľným efektom v nepredvídateľnom čase. Dokonca aj na riadenie relatívne jednoduchých procesov (napríklad na riadenie motora, systému ohrevu vody v domácnostiach) musia automatické riadiace systémy používať zložité algoritmy so spätnou väzbou.
Naša úloha je o mnoho rádov zložitejšia a existuje riziko, že systém nebude schopný v primeranom čase vyrovnať záťaž na stanovené hodnoty, a to aj bez vonkajších vplyvov používateľov.
História nášho vývoja
Aby sme tento problém vyriešili, rozhodli sme sa nezačínať od nuly, ale stavať na existujúcich skúsenostiach a začali sme komunikovať so špecialistami so skúsenosťami v tejto oblasti. Našťastie sa naše chápanie problému úplne zhodovalo.
Krok 1
Použili sme systém založený na technológii neurónových sietí a snažili sme sa na jeho základe optimalizovať naše zdroje.
Záujmom tejto etapy bolo testovanie novej technológie a jej dôležitosť spočívala v aplikovaní neštandardného prístupu k riešeniu problému, kde sa za ostatných okolností štandardné prístupy prakticky vyčerpali.
Spustili sme systém a skutočne sme začali bilancovať. Rozsah nášho cloudu nám neumožnil získať optimistické výsledky, ktoré uviedli vývojári, ale bolo jasné, že vyvažovanie funguje.
Zároveň sme mali dosť vážne obmedzenia:
- Na trénovanie neurónovej siete musia virtuálne stroje bežať bez výrazných zmien niekoľko týždňov alebo mesiacov.
- Algoritmus je navrhnutý pre optimalizáciu založenú na analýze skorších „historických“ údajov.
- Trénovanie neurónovej siete vyžaduje pomerne veľké množstvo dát a výpočtových zdrojov.
- Optimalizáciu a vyváženie je možné vykonať pomerne zriedkavo – raz za niekoľko hodín, čo zjavne nestačí.
Krok 2
Keďže sme neboli spokojní so stavom veci, rozhodli sme sa systém upraviť a k tomu odpovedať hlavná otázka – pre koho to robíme?
Prvý - pre firemných klientov. To znamená, že potrebujeme systém, ktorý funguje rýchlo, s tými podnikovými obmedzeniami, ktoré len zjednodušujú implementáciu.
Druhá otázka – čo myslíš pod slovom „okamžite“? Na základe krátkej debaty sme sa rozhodli, že by sme mohli začať s dobou odozvy 5–10 minút, aby krátkodobé rázy neuviedli systém do rezonancie.
Tretia otázka – akú veľkosť vyváženého počtu serverov zvoliť?
Tento problém sa vyriešil sám. Klienti zvyčajne nerobia veľké agregácie serverov, čo je v súlade s odporúčaniami v článku obmedziť agregácie na 30 až 40 serverov.
Okrem toho segmentovaním serverového fondu zjednodušujeme úlohu vyrovnávacieho algoritmu.
Štvrtá otázka – ako vhodná je pre nás neurónová sieť s jej dlhým procesom učenia a vzácnym balansovaním? Rozhodli sme sa ho opustiť v prospech jednoduchších operačných algoritmov, aby sme dosiahli výsledky v priebehu niekoľkých sekúnd.
Je možné nájsť popis systému, ktorý používa takéto algoritmy a jeho nevýhody
Tento systém sme implementovali a spustili a dosiahli sme povzbudivé výsledky – teraz pravidelne analyzuje zaťaženie cloudu a dáva odporúčania na presun virtuálnych strojov, ktoré sú z veľkej časti správne. Už teraz je jasné, že môžeme dosiahnuť 10-15% uvoľnenie zdrojov pre nové virtuálne stroje a zároveň zlepšiť kvalitu práce tých existujúcich.
Keď sa zistí nerovnováha v RAM alebo CPU, systém vydá príkazy plánovaču Tionix, aby vykonal živú migráciu požadovaných virtuálnych strojov. Ako je zrejmé z monitorovacieho systému, virtuálny stroj sa presunul z jedného (horného) na druhého (dolného) hostiteľa a uvoľnil pamäť na hornom hostiteľovi (zvýraznený žltými krúžkami), respektíve obsadil ho na spodnom hostiteľovi (zvýraznený bielou farbou). kruhy).
Teraz sa snažíme presnejšie posúdiť efektivitu súčasného algoritmu a snažíme sa v ňom nájsť možné chyby.
Krok 3
Zdá sa, že sa na to dá upokojiť, počkať na preukázanú účinnosť a uzavrieť tému.
K uskutočneniu novej etapy nás však tlačia nasledujúce zrejmé možnosti optimalizácie
- Štatistiky napr. и ukazuje, že dvoj- a štvorprocesorové systémy majú výrazne nižší výkon ako jednoprocesorové systémy. To znamená, že všetci používatelia dostávajú podstatne menej výstupu z CPU, RAM, SSD, LAN, FC zakúpených vo viacprocesorových systémoch v porovnaní s jednoprocesorovými systémami.
- Samotné plánovače zdrojov môžu mať vážne chyby, na túto tému.
- Technológie ponúkané spoločnosťami Intel a AMD na monitorovanie RAM a vyrovnávacej pamäte umožňujú študovať správanie virtuálnych strojov a umiestniť ich tak, aby „hluční“ susedia nezasahovali do „tichých“ virtuálnych strojov.
- Rozšírenie množiny parametrov (sieť, úložný systém, priorita virtuálneho stroja, náklady na migráciu, jeho pripravenosť na migráciu).
Celkom
Výsledkom našej práce na zdokonaľovaní balančných algoritmov bol jednoznačný záver, že pomocou moderných algoritmov je možné dosiahnuť výraznú optimalizáciu zdrojov dátového centra (25-30%) a zároveň zlepšiť kvalitu zákazníckeho servisu.
Algoritmus založený na neurónových sieťach je určite zaujímavým riešením, ktoré si však vyžaduje ďalší vývoj a vzhľadom na existujúce obmedzenia nie je vhodný na riešenie tohto druhu problémov na objemoch typických pre privátne cloudy. Algoritmus zároveň ukázal dobré výsledky vo verejných oblakoch významnej veľkosti.
Viac o možnostiach procesorov, plánovačov a vyvažovaní na vysokej úrovni vám povieme v nasledujúcich článkoch.
Zdroj: hab.com