CAP teorém je základním kamenem teorie distribuovaných systémů. Kontroverze kolem toho samozřejmě neutichají: definice v něm nejsou kanonické a neexistuje žádný přísný důkaz... Nicméně, pevně stojíme na pozicích každodenního zdravého rozumu™, intuitivně chápeme, že teorém je pravdivý.
Jediné, co není zřejmé, je význam písmene „P“. Když je cluster rozdělen, rozhodne se, zda neodpoví, dokud nebude dosaženo kvora, nebo vrátí data, která jsou k dispozici. V závislosti na výsledcích této volby je systém klasifikován jako CP nebo AP. Cassandra se například může chovat jakkoli, v závislosti ani ne na nastavení clusteru, ale na parametrech každého konkrétního požadavku. Ale pokud systém není "P" a rozdělí se, tak co?
Odpověď na tuto otázku je poněkud neočekávaná: cluster CA se nemůže rozdělit.
Co je to za shluk, který se nemůže rozdělit?
Nepostradatelným atributem takového clusteru je sdílený systém ukládání dat. V naprosté většině případů to znamená připojení přes SAN, což omezuje použití CA řešení na velké podniky schopné udržovat infrastrukturu SAN. Aby více serverů mohlo pracovat se stejnými daty, je vyžadován clusterový souborový systém. Takové souborové systémy jsou dostupné v portfoliích HPE (CFS), Veritas (VxCFS) a IBM (GPFS).
Oracle RAC
Možnost Real Application Cluster se poprvé objevila v roce 2001 s vydáním Oracle 9i. V takovém clusteru pracuje několik instancí serveru se stejnou databází.
Oracle umí pracovat jak s clusterovým souborovým systémem, tak s vlastním řešením – ASM, Automatic Storage Management.
Každá kopie si vede svůj vlastní deník. Transakce je provedena a potvrzena jednou instancí. Pokud instance selže, jeden z přežívajících uzlů clusteru (instance) přečte svůj protokol a obnoví ztracená data – čímž zajistí dostupnost.
Všechny instance si udržují vlastní mezipaměť a stejné stránky (bloky) mohou být v mezipaměti více instancí současně. Navíc, pokud jedna instance potřebuje stránku a ta je v mezipaměti jiné instance, může ji získat od svého souseda pomocí mechanismu fúze mezipaměti namísto čtení z disku.
Co se ale stane, když jedna z instancí potřebuje změnit data?
Zvláštností Oracle je, že nemá vyhrazenou zamykací službu: pokud chce server uzamknout řádek, pak se záznam o zámku umístí přímo na stránku paměti, kde se zamčený řádek nachází. Díky tomuto přístupu je Oracle výkonnostním šampiónem mezi monolitickými databázemi: služba zamykání se nikdy nestane úzkým hrdlem. Ale v konfiguraci clusteru může taková architektura vést k intenzivnímu síťovému provozu a uváznutí.
Jakmile je záznam uzamčen, instance upozorní všechny ostatní instance, že stránka, která tento záznam ukládá, má výhradní blokování. Pokud jiná instance potřebuje změnit záznam na stejné stránce, musí počkat, dokud nebudou změny na stránce potvrzeny, to znamená, že se informace o změně zapíše do žurnálu na disku (a transakce může pokračovat). Může se také stát, že se stránka postupně změní o několik kopií a při zápisu stránky na disk pak budete muset zjistit, kdo ukládá aktuální verzi této stránky.
Náhodná aktualizace stejných stránek napříč různými uzly RAC způsobuje dramatický pokles výkonu databáze až do bodu, kdy může být výkon clusteru nižší než u jedné instance.
Správné použití Oracle RAC spočívá ve fyzickém rozdělení dat (například pomocí mechanismu dělené tabulky) a přístupu ke každé sadě oddílů prostřednictvím vyhrazeného uzlu. Hlavním účelem RAC nebylo horizontální škálování, ale zajištění odolnosti proti chybám.
Pokud uzel přestane reagovat na prezenční signál, uzel, který jej detekoval, nejprve spustí na disku hlasovací proceduru. Pokud zde chybějící uzel není uveden, pak jeden z uzlů přebírá odpovědnost za obnovu dat:
- „zmrazí“ všechny stránky, které byly v mezipaměti chybějícího uzlu;
- přečte protokoly (zopakuje) chybějícího uzlu a znovu použije změny zaznamenané v těchto protokolech a současně zkontroluje, zda ostatní uzly nemají novější verze stránek, které se mění;
- vrátí zpět čekající transakce.
Pro zjednodušení přepínání mezi uzly má Oracle koncept služby – virtuální instance. Instance může obsluhovat více služeb a služba se může pohybovat mezi uzly. Instance aplikace obsluhující určitou část databáze (například skupinu klientů) pracuje s jednou službou a služba zodpovědná za tuto část databáze se přesune do jiného uzlu, když uzel selže.
IBM Pure Data Systems for Transactions
Clusterové řešení pro DBMS se objevilo v portfoliu Blue Giant v roce 2009. Ideově jde o nástupce clusteru Parallel Sysplex, postaveného na „běžném“ vybavení. V roce 2009 byl DB2 pureScale vydán jako softwarový balík a v roce 2012 IBM nabídlo zařízení s názvem Pure Data Systems for Transactions. Nemělo by se zaměňovat s Pure Data Systems for Analytics, což není nic jiného než přejmenovaná Netezza.
Na první pohled je architektura pureScale podobná Oracle RAC: stejným způsobem je několik uzlů připojeno ke společnému systému ukládání dat a každý uzel provozuje vlastní instanci DBMS s vlastními paměťovými oblastmi a transakčními záznamy. Ale na rozdíl od Oracle má DB2 vyhrazenou uzamykací službu reprezentovanou sadou procesů db2LLM*. V konfiguraci clusteru je tato služba umístěna na samostatném uzlu, který se nazývá spojovací zařízení (CF) v Parallel Sysplex a PowerHA v Pure Data.
PowerHA poskytuje následující služby:
- správce zámků;
- globální vyrovnávací paměť;
- oblast meziprocesové komunikace.
Pro přenos dat z PowerHA do databázových uzlů a zpět se používá vzdálený přístup do paměti, takže propojení clusteru musí podporovat protokol RDMA. PureScale může používat Infiniband i RDMA přes Ethernet.
Pokud uzel potřebuje stránku a tato stránka není v mezipaměti, pak si uzel vyžádá stránku v globální mezipaměti, a pouze pokud tam není, načte ji z disku. Na rozdíl od Oracle jde požadavek pouze do PowerHA a ne do sousedních uzlů.
Pokud se instance chystá změnit řádek, uzamkne jej ve výhradním režimu a stránku, kde je řádek umístěn, ve sdíleném režimu. Všechny zámky jsou registrovány v globálním správci zámků. Po dokončení transakce odešle uzel zprávu správci zámků, který zkopíruje upravenou stránku do globální mezipaměti, uvolní zámky a zneplatní upravenou stránku v mezipaměti ostatních uzlů.
Pokud je stránka, na které se upravený řádek nachází, již zamčená, pak správce zámku načte upravenou stránku z paměti uzlu, který provedl změnu, uvolní zámek, zruší platnost změněné stránky v mezipaměti ostatních uzlů a dejte zámek stránky uzlu, který si to vyžádal.
„Dirty“, tedy změněné stránky, lze zapisovat na disk jak z běžného uzlu, tak z PowerHA (castout).
Pokud jeden z uzlů pureScale selže, obnova je omezena pouze na ty transakce, které v době selhání ještě nebyly dokončeny: stránky upravené tímto uzlem v dokončených transakcích jsou v globální mezipaměti PowerHA. Uzel se restartuje ve snížené konfiguraci na jednom ze serverů v clusteru, vrátí nevyřízené transakce a uvolní zámky.
PowerHA běží na dvou serverech a hlavní uzel synchronně replikuje svůj stav. Pokud primární uzel PowerHA selže, cluster pokračuje v provozu se záložním uzlem.
Samozřejmě, pokud přistupujete k datové sadě přes jediný uzel, bude celkový výkon clusteru vyšší. PureScale si dokonce může všimnout, že určitá oblast dat je zpracovávána jedním uzlem, a pak všechny zámky související s touto oblastí budou uzlem zpracovány lokálně bez komunikace s PowerHA. Jakmile se však aplikace pokusí získat přístup k těmto datům prostřednictvím jiného uzlu, zpracování centralizovaného zámku se obnoví.
Interní testy IBM při pracovní zátěži 90 % čtení a 10 % zápisu, což je velmi podobné pracovní zátěži v reálném světě, ukazují téměř lineární škálování až do 128 uzlů. Podmínky testu bohužel nejsou zveřejněny.
HPE NonStop SQL
Portfolio Hewlett-Packard Enterprise má také svou vlastní vysoce dostupnou platformu. Jedná se o platformu NonStop, která byla uvedena na trh v roce 1976 společností Tandem Computers. V roce 1997 společnost koupila společnost Compaq, která se v roce 2002 sloučila s Hewlett-Packard.
NonStop se používá k vytváření kritických aplikací – například zpracování HLR nebo bankovních karet. Platforma je dodávána ve formě softwarového a hardwarového komplexu (zařízení), který zahrnuje výpočetní uzly, systém ukládání dat a komunikační zařízení. Síť ServerNet (v moderních systémech - Infiniband) slouží jak pro výměnu mezi uzly, tak pro přístup do systému ukládání dat.
Dřívější verze systému používaly proprietární procesory, které byly vzájemně synchronizovány: všechny operace byly prováděny synchronně několika procesory, a jakmile jeden z procesorů udělal chybu, byl vypnut a druhý pokračoval v práci. Později systém přešel na konvenční procesory (nejprve MIPS, pak Itanium a nakonec x86) a k synchronizaci se začaly používat další mechanismy:
- zprávy: každý systémový proces má „stínové“ dvojče, kterému aktivní proces periodicky posílá zprávy o svém stavu; pokud hlavní proces selže, stínový proces začne pracovat od okamžiku určeného poslední zprávou;
- hlasování: úložný systém má speciální hardwarovou komponentu, která přijímá více identických přístupů a provádí je pouze v případě, že se přístupy shodují; Namísto fyzické synchronizace pracují procesory asynchronně a výsledky jejich práce se porovnávají pouze v I/O momentech.
Od roku 1987 běží na platformě NonStop relační DBMS – nejprve SQL/MP, později SQL/MX.
Celá databáze je rozdělena na části a každá část je zodpovědná za svůj vlastní proces Data Access Manager (DAM). Poskytuje záznam dat, ukládání do mezipaměti a zamykací mechanismy. Zpracování dat provádějí procesy Executor Server Processes běžící na stejných uzlech jako odpovídající správci dat. Plánovač SQL/MX rozděluje úkoly mezi spouštěče a agreguje výsledky. Pokud je nutné provést dohodnuté změny, použije se dvoufázový protokol potvrzení poskytovaný knihovnou TMF (Transaction Management Facility).
NonStop SQL může upřednostňovat procesy tak, aby dlouhé analytické dotazy nenarušovaly provádění transakce. Jeho účelem je však právě zpracování krátkých transakcí, nikoli analytika. Developer garantuje dostupnost NonStop clusteru na úrovni pěti „devítek“, tedy prostoje pouze 5 minut ročně.
SAP-HANA
První stabilní verze HANA DBMS (1.0) proběhla v listopadu 2010 a balíček SAP ERP přešel na HANA v květnu 2013. Platforma je založena na zakoupených technologiích: TREX Search Engine (vyhledávání ve sloupcovém úložišti), P*TIME DBMS a MAX DB.
Samotné slovo „HANA“ je zkratka, vysoce výkonné analytické zařízení. Tento DBMS je dodáván ve formě kódu, který lze spustit na libovolných x86 serverech, průmyslové instalace jsou však povoleny pouze na certifikovaném zařízení. Řešení dostupná od HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Některé konfigurace Lenova umožňují i provoz bez SAN – roli běžného úložného systému plní GPFS cluster na lokálních discích.
Na rozdíl od platforem uvedených výše je HANA in-memory DBMS, tj. obraz primárních dat je uložen v paměti RAM a na disk se zapisují pouze protokoly a pravidelné snímky pro obnovení v případě havárie.
Každý uzel clusteru HANA je zodpovědný za svou vlastní část dat a datová mapa je uložena ve speciální komponentě – Name Server, umístěném v uzlu koordinátora. Data se mezi uzly neduplikují. Informace o zamykání jsou také uloženy na každém uzlu, ale systém má globální detektor uváznutí.
Když se klient HANA připojí ke clusteru, stáhne si svou topologii a pak může přímo přistupovat k libovolnému uzlu v závislosti na tom, jaká data potřebuje. Pokud transakce ovlivňuje data jednoho uzlu, může být tímto uzlem provedena lokálně, ale pokud se změní data několika uzlů, iniciační uzel kontaktuje uzel koordinátora, který otevře a koordinuje distribuovanou transakci a provede ji pomocí optimalizovaný dvoufázový protokol odevzdání.
Koordinační uzel je duplikován, takže pokud koordinátor selže, okamžitě převezme záložní uzel. Ale pokud uzel s daty selže, pak jediný způsob, jak získat přístup k jeho datům, je restartovat uzel. Klastry HANA zpravidla udržují náhradní server, aby se na něm co nejrychleji restartoval ztracený uzel.
Zdroj: www.habr.com