Distribuované cachování

Z FI WIKI
Přejít na: navigace, hledání

Cluster, load balancing

Cluster

Jedná se o seskupení serverů, které spolu úzce spolupracují a navenek vystupují jako jeden. Celý proces vyřízení požadavku je pro uživatele transparentní. Uživatele nezajímá, který ze severů vykoná požadavek. Clusterování může probíhat ve dvou rovinách. První je zvyšování počtu softwarových serverů na jednom zařízení. V druhém případě dochazí k zvyšování počtu HW zařízení. Druhá možnost je sice dražší, ale zato výkonnější. Clustery jsou používány pro zvýšení výkonnosti, spolehlivosti a škálovatelnosti systému.Tento systém propojených počítačů je levnější než jeden počítač se srovnatelným systémem.

Load balancing

Jedná se o techniku, kdy se práce (výpočet) rozděluje mezi další počítače (procesy). Tímto způsobem dochází k optimalizaci využití zdrojů a snížení výpočetního času. Load balancing a clustery spolu velmi úzce souvisí. Zátěž je rozdělována load balancerem na jednotlivé počítače v clusteru.

Caching-balancing.png

Příkladem clusteru může být soubor aplikačních serverů se stejnou webovou aplikací. Load balancer vybere podle nastavené politiky (například nejmeně vytížený nebo další v pořadí) aplikační server, který zpracuje požadavek uživatele. Jeden fyzický server může pro zvýšení výkonnosti více instancí jedné aplikace. Každá instance běží v jedné JVM. Výsledný systém může nakonec vypadat následovně. Cluster obsahuje dva fyzické servery. V každém z nich běží tři JVM (tři instance aplikace). Celý systém pak obsahuje šest instancí jedné aplikace. Při návrhu aplikace je důležité brát v úvahu, zda aplikace bude běžet v clusteru serverů s load balancingem nebo nebude. Pokud běží více naprosto izolovaných aplikací, dochází k plýtvání zdrojů (například operační paměti). Návrh aplikace musí korespondovat s architekturou výpočetního systému. Typickým příkladem aplikace, u které se musí brát v uváhu clusterování, je aplikace používající vyrovnávací paměť. Existuje několik topologií návrhu těchto aplikací. Každá z topologií má své výhody i nevýhody a nelze zcela rozhodnout, že by některý přístup byl absolutně nejlepší.

Distribuované cachování

Topologie

Izolovaná topologie

V tomto případě obsahuje každá z aplikací svou vlastní vyrovnávací paměť. Jednotlivé cache spolu žádným způsobem nekomunikují a obsah závisí pouze na příslušné aplikaci. Je zcela jasné, že při tomto přístupu dochází k plýtvání operační (nebo jiné – závisí na typu cache) paměti. Výhodou je rychlost topologie při čtení. Dále zde není požadavek na sdílení informací mezi jednotlivými aplikacemi a tedy je i zápis do vyrovnávací paměti efektivní. Pokud aplikace obsahuje v cache přiměřený objem dat a tato data mají spíše statický charakter, může být tato topologie postačující.

Caching-izolated.png

Čtení objektu A z vyrovnávací paměti v JVM 1 a zápis objektu C do vyrovnávací paměti

Replikovaná topologie

Replikovaná topologie je základní případ distribuované vyrovnávací paměti. Její princip je velmi jednoduchý. Všechny prvky ve vyrovnávací paměti jsou replikovány do všech ostatních příslušných vyrovnávacích pamětí. Jedná se vlastně o synchronizaci mezi jednotlivými cache. Všechna cachovaná data jsou pak přístupná lokálně každé aplikaci. Tato topologie je výhodná zejména pro read-mostly systémy. Každá aplikace obsahuje stejná data lokálně, a proto je čtení velmi rychlé. Limitující pro tuto topologii je zápis a aktualizace. K tomuto problému lze přistoupit ze dvou hledisek. Zápis a aktualizace vyžaduje změnu ve všech ostatních cache, což muže snížit výkon celého systému. Druhým problémem je plýtvání zdrojů, zejména operační paměti, protože dochází k redundanci dat. Celkově lze říci, že se jedna o téměř totožnou topologii jako v prvním případě. Rozdílem je pouze sychnronizace vyrovnávacích pamětí.

Caching-replicated.png

Vložení objektu A do vyrovnávací paměti a následná replikace

Rozložená topologie

Vlastnictví dat se rozloží mezi jednotlivé servery v clusteru. V celém systému tedy existuje jenom jedna kopie dat a případně její záloha. Velikost cache lineárně vzroste v okamžiku, kdy se do clusteru přidá další server. V každé JVM je struktura cache už složitější než v předchozích dvou případech. Tvoří ji logická část, která obsahuje odkazy na všechny elementy v cache, dále primární a záložní úložiště, které obsahují samotné datové elementy. Problém nastává v okamžiku, kdy některý ze serverů (nebo JVM) vypadne. Ostatní musí nahradit jeho funkci a proto každá z cache obsahuje záložní část a při vhodném rozložení se zátěž po vypadlém serveru rovnoměrně rozdělí mezi ostatní. Pro takové situace se definuje plán obnovení z výpadku, kterým se systém při výpadku řídí. Zvláštním případem této topologie jsou servery v clusteru určené výhradně pro cachování. Jejich úkolem není obsluhovat požadavky na aplikaci, ale pouze poskytovat služby vyrovnávací paměti. Výhodou tohoto přístupu je téměř neomezená velikost cache, stačí pouze přidat nový server do clusteru. Výkon čtení a zápisu je fixní a topologie je vhodná i pro systémy s velkým počtem zápisů do vyrovnávací paměti. Z důvodu rozložení zátěže cache mezi všechny servery a lineárně rostoucí velikosti, je takto postavený systém dobře škálovatelný.

Caching-partioned1.png

Čtení probíhá z primárních umístění datových elementů. Pro aplikaci je celý proces transparentní. To znamená, že o data požádá cache, která je zpřistupní.

Caching-partioned2.png

Při zápisu je důležité, aby cache podle nastavené úrovně redundance a plánu obnovy zapsala data na všechna potřebná umístění.

Caching-partioned3.png

Při výpadku JVM 2 se element B vytvoří v JVM 3 ze zálohy a JVM 3 se stane primárním držitelem B.

Caching-partioned4.png

V tomto případě existují dedikované cachovací servery (JVM 2 a JVM 3). V případě výpadku primárního JVM 2 převezme řízení záložní JVM 3.

Blízká topologie

Rozložená topologie nemusí být zcela výkonná. Jednotlivé JVM mezi sebou musí neustálé komunikovat a celkové vytížení sítě má velký vliv na dobu odpovědi na požadavek. Z tohoto důvodu se zavádí další úroveň cache mezi distribuovanou cache a aplikaci. Častou používaná data obsahuje L1 cache, zatímco data používána méně často obsahuje distribuovaná L2 cache. Princip fungovaní paměti je velmi jednoduchý. Pokud data nejsou při čtení dostupná v L1 paměti, pokračuje požadavek na L2 paměť a pokud je třeba, výsledek se může uložit v L1 pro další požadavek. Zápis je trochu složitější. Předpokládejme, že před zápisem jsou data dostupná v L1. Pokud dojde ke změně, zápis se musí propagovat i do L2 paměti. Problém nastává v okamžiku, kdy jiné aplikace obsahují tyto data v L1 paměti. Musí dojít k zneplatnění těchto dat. K tomu existují dva mechanismy.

Mechanismus založený na událostech

L1 cache poslouchá všechny události v systému a pokud nastane situace, které se týká načtených dat, provede definovanou akci (např. zneplatnění)

Mechanismus založený vypršení platnosti

Každá data v L1 vyrovnávací paměti mají nastavenou dobu platnosti. Pokud tato doba uplyne, dojde automaticky k zneplatnění dat, případně k jejich znovunačtení.

Caching-near1.png

Caching-near2.png


Princip blízké topologie přináší vylepšení výkonu aplikace zejména pro hodně čtená data. Při zápisu ovšem dochází z důvodu reakcí na události nebo sledování času platnosti ke zpoždění. Tyto operace ovšem mohou běžet nezávisle na operaci zápisu, a proto zpoždění nemusí být kritické. Další výhody či nevýhody systému jsou stejné jako při rozložené topologii.

Architektura

Cache-aside

V tomto případě řídí vkládání dat do vyrovnávací paměti aplikace. Pokud nejsou při čtení data v cache, aplikace je vytvoří (například načte z databáze) a vloží do cache.

Cache-through

Přístup nebo vytvoření dat neřídí aplikace, ale přímo vyrovnávací paměť. Při čtení aplikace požádá vyrovnávací paměť o data a nestará se, jestli jsou data už načtená nebo musí nějakým způsobem získat.