Veta CAP je základným kameňom teórie distribuovaných systémov. Samozrejme, kontroverzia okolo toho neutícha: definície v nej nie sú kanonické a neexistuje žiadny prísny dôkaz... Napriek tomu, pevne stojaci na pozíciách každodenného zdravého rozumu™, intuitívne chápeme, že veta je pravdivá.
Jediné, čo nie je zrejmé, je význam písmena „P“. Keď sa klaster rozdelí, rozhodne, či neodpovie, kým sa nedosiahne kvórum, alebo vráti údaje, ktoré sú k dispozícii. V závislosti od výsledkov tejto voľby je systém klasifikovaný ako CP alebo AP. Cassandra sa napríklad môže správať tak či onak, v závislosti ani nie od nastavení klastra, ale od parametrov každej konkrétnej požiadavky. Ale ak systém nie je "P" a rozdelí sa, čo potom?
Odpoveď na túto otázku je trochu neočakávaná: klaster CA sa nemôže rozdeliť.
Čo je to za zhluk, ktorý sa nemôže rozdeliť?
Nevyhnutným atribútom takéhoto klastra je zdieľaný systém ukladania dát. V drvivej väčšine prípadov to znamená pripojenie cez SAN, čo obmedzuje používanie CA riešení na veľké podniky schopné udržiavať infraštruktúru SAN. Aby viacero serverov mohlo pracovať s rovnakými údajmi, je potrebný klastrovaný súborový systém. Takéto súborové systémy sú dostupné v portfóliách HPE (CFS), Veritas (VxCFS) a IBM (GPFS).
Oracle RAC
Možnosť Real Application Cluster sa prvýkrát objavila v roku 2001 s vydaním Oracle 9i. V takomto klastri pracuje niekoľko inštancií servera s rovnakou databázou.
Oracle dokáže pracovať ako s klastrovaným súborovým systémom, tak aj s vlastným riešením – ASM, Automatic Storage Management.
Každá kópia si vedie svoj vlastný denník. Transakcia je vykonaná a potvrdená jednou inštanciou. Ak inštancia zlyhá, jeden z prežívajúcich klastrových uzlov (inštancií) prečíta svoj protokol a obnoví stratené údaje – čím zabezpečí dostupnosť.
Všetky inštancie si udržiavajú svoju vlastnú vyrovnávaciu pamäť a tie isté stránky (bloky) môžu byť súčasne vo vyrovnávacej pamäti viacerých inštancií. Navyše, ak jedna inštancia potrebuje stránku a je vo vyrovnávacej pamäti inej inštancie, môže ju získať od svojho suseda pomocou mechanizmu vyrovnávacej pamäte namiesto čítania z disku.
Čo sa však stane, ak jedna z inštancií potrebuje zmeniť údaje?
Zvláštnosťou Oracle je, že nemá vyhradenú uzamykaciu službu: ak chce server uzamknúť riadok, záznam o uzamknutí sa umiestni priamo na stránku pamäte, kde sa nachádza uzamknutý riadok. Vďaka tomuto prístupu je Oracle výkonným šampiónom medzi monolitickými databázami: uzamykacia služba sa nikdy nestane prekážkou. Ale v konfigurácii klastra môže takáto architektúra viesť k intenzívnej sieťovej prevádzke a zablokovaniu.
Keď je záznam uzamknutý, inštancia upozorní všetky ostatné inštancie, že stránka, na ktorej je uložený záznam, má výhradné zadržanie. Ak iná inštancia potrebuje zmeniť záznam na tej istej stránke, musí počkať, kým sa zmeny na stránke nepotvrdia, to znamená, že informácie o zmene sa zapíšu do žurnálu na disku (a transakcia môže pokračovať). Môže sa tiež stať, že sa stránka postupne zmení o niekoľko kópií a potom pri zápise stránky na disk budete musieť zistiť, kto ukladá aktuálnu verziu tejto stránky.
Náhodná aktualizácia rovnakých stránok v rôznych uzloch RAC spôsobuje dramatický pokles výkonu databázy až do bodu, kedy môže byť výkon klastra nižší ako výkon jednej inštancie.
Správnym použitím Oracle RAC je fyzické rozdelenie údajov (napríklad pomocou mechanizmu rozdelenej tabuľky) a prístup ku každej sade oddielov prostredníctvom vyhradeného uzla. Hlavným účelom RAC nebolo horizontálne škálovanie, ale zabezpečenie odolnosti voči chybám.
Ak uzol prestane reagovať na tlkot srdca, uzol, ktorý ho detegoval, ako prvý spustí hlasovaciu procedúru na disku. Ak tu nie je uvedený chýbajúci uzol, potom jeden z uzlov preberá zodpovednosť za obnovu údajov:
- „zmrazí“ všetky stránky, ktoré boli vo vyrovnávacej pamäti chýbajúceho uzla;
- prečíta protokoly (zopakuje) chýbajúceho uzla a znova použije zmeny zaznamenané v týchto protokoloch, pričom súčasne skontroluje, či iné uzly majú novšie verzie stránok, ktoré sa menia;
- vráti späť čakajúce transakcie.
Na zjednodušenie prepínania medzi uzlami má Oracle koncept služby – virtuálnej inštancie. Inštancia môže slúžiť viacerým službám a služba sa môže pohybovať medzi uzlami. Inštancia aplikácie obsluhujúca určitú časť databázy (napríklad skupinu klientov) pracuje s jednou službou a služba zodpovedná za túto časť databázy sa presunie do iného uzla, keď uzol zlyhá.
IBM Pure Data Systems for Transactions
Clusterové riešenie pre DBMS sa objavilo v portfóliu Blue Giant v roku 2009. Ideovo ide o nástupcu klastra Parallel Sysplex, postaveného na „bežnom“ vybavení. V roku 2009 bol DB2 pureScale vydaný ako softvérový balík a v roku 2012 IBM ponúklo zariadenie s názvom Pure Data Systems for Transactions. Nemalo by sa to zamieňať s Pure Data Systems for Analytics, čo nie je nič iné ako premenovaná Netezza.
Na prvý pohľad je architektúra pureScale podobná Oracle RAC: rovnakým spôsobom je niekoľko uzlov pripojených k spoločnému systému ukladania údajov a každý uzol prevádzkuje vlastnú inštanciu DBMS s vlastnými pamäťovými oblasťami a protokolmi transakcií. Ale na rozdiel od Oracle má DB2 vyhradenú uzamykaciu službu, ktorú predstavuje súbor procesov db2LLM*. V klastrovej konfigurácii je táto služba umiestnená na samostatnom uzle, ktorý sa nazýva spojovací prostriedok (CF) v Parallel Sysplex a PowerHA v Pure Data.
PowerHA poskytuje nasledujúce služby:
- správca zámkov;
- globálna vyrovnávacia pamäť;
- oblasť medziprocesovej komunikácie.
Na prenos údajov z PowerHA do databázových uzlov a späť sa používa vzdialený prístup do pamäte, takže prepojenie klastra musí podporovať protokol RDMA. PureScale môže používať Infiniband aj RDMA cez Ethernet.
Ak uzol potrebuje stránku a táto stránka nie je vo vyrovnávacej pamäti, uzol si vyžiada stránku v globálnej vyrovnávacej pamäti a iba ak tam nie je, načíta ju z disku. Na rozdiel od Oracle, požiadavka smeruje iba do PowerHA a nie do susedných uzlov.
Ak sa inštancia chystá zmeniť riadok, uzamkne ho vo exkluzívnom režime a stránka, kde sa riadok nachádza, v zdieľanom režime. Všetky zámky sú registrované v globálnom správcovi zámkov. Po dokončení transakcie uzol odošle správu správcovi zámkov, ktorý skopíruje upravenú stránku do globálnej vyrovnávacej pamäte, uvoľní zámky a zneplatní upravenú stránku v vyrovnávacej pamäti ostatných uzlov.
Ak je stránka, v ktorej sa upravený riadok nachádza, už zamknutá, správca zámkov prečíta upravenú stránku z pamäte uzla, ktorý vykonal zmenu, uvoľní zámok, zruší platnosť upravenej stránky v cache iných uzlov a dať zámok stránky uzlu, ktorý si to vyžiadal.
„Špinavé“, teda zmenené stránky, je možné zapisovať na disk z bežného uzla aj z PowerHA (castout).
Ak jeden z uzlov pureScale zlyhá, obnova sa obmedzí len na tie transakcie, ktoré v čase zlyhania ešte neboli dokončené: stránky upravené týmto uzlom v dokončených transakciách sú v globálnej vyrovnávacej pamäti na PowerHA. Uzol sa reštartuje v redukovanej konfigurácii na jednom zo serverov v klastri, vráti späť čakajúce transakcie a uvoľní zámky.
PowerHA beží na dvoch serveroch a hlavný uzol synchrónne replikuje svoj stav. Ak primárny uzol PowerHA zlyhá, klaster bude naďalej fungovať so záložným uzlom.
Samozrejme, ak pristupujete k množine údajov cez jeden uzol, celkový výkon klastra bude vyšší. PureScale si dokonca môže všimnúť, že určitá oblasť údajov je spracovávaná jedným uzlom, a potom všetky zámky súvisiace s touto oblasťou budú spracované lokálne uzlom bez komunikácie s PowerHA. Akonáhle sa však aplikácia pokúsi získať prístup k týmto údajom cez iný uzol, spracovanie centralizovaného zámku sa obnoví.
Interné testy IBM pri pracovnom zaťažení 90 % čítania a 10 % zápisu, čo je veľmi podobné pracovnému zaťaženiu v reálnom svete, ukazujú takmer lineárne škálovanie až do 128 uzlov. Podmienky testu, žiaľ, nie sú zverejnené.
HPE NonStop SQL
Portfólio Hewlett-Packard Enterprise má tiež svoju vlastnú vysoko dostupnú platformu. Toto je platforma NonStop, ktorá bola uvedená na trh v roku 1976 spoločnosťou Tandem Computers. V roku 1997 spoločnosť získala spoločnosť Compaq, ktorá sa v roku 2002 zlúčila s Hewlett-Packard.
NonStop sa používa na vytváranie kritických aplikácií - napríklad spracovanie HLR alebo bankových kariet. Platforma je dodávaná vo forme softvérového a hardvérového komplexu (zariadenia), ktorý zahŕňa výpočtové uzly, systém na ukladanie dát a komunikačné vybavenie. Sieť ServerNet (v moderných systémoch - Infiniband) slúži ako na výmenu medzi uzlami, tak aj na prístup k systému ukladania dát.
Skoré verzie systému používali proprietárne procesory, ktoré boli navzájom synchronizované: všetky operácie vykonávalo synchrónne niekoľko procesorov a akonáhle jeden z procesorov urobil chybu, bol vypnutý a druhý pokračoval v práci. Neskôr systém prešiel na konvenčné procesory (najskôr MIPS, potom Itanium a nakoniec x86) a na synchronizáciu sa začali používať ďalšie mechanizmy:
- správy: každý systémový proces má „tieňového“ dvojča, ktorému aktívny proces pravidelne posiela správy o svojom stave; ak hlavný proces zlyhá, tieňový proces začne pracovať od okamihu určeného poslednou správou;
- hlasovanie: úložný systém má špeciálny hardvérový komponent, ktorý akceptuje viacero identických prístupov a vykoná ich iba vtedy, ak sa prístupy zhodujú; Namiesto fyzickej synchronizácie pracujú procesory asynchrónne a výsledky ich práce sa porovnávajú iba v I/O momentoch.
Od roku 1987 na platforme NonStop beží relačný DBMS – najprv SQL/MP, neskôr SQL/MX.
Celá databáza je rozdelená na časti a každá časť je zodpovedná za svoj vlastný proces Data Access Manager (DAM). Poskytuje zaznamenávanie údajov, ukladanie do vyrovnávacej pamäte a uzamykacie mechanizmy. Spracovanie údajov vykonávajú procesy Executor Server Processes bežiace na rovnakých uzloch ako príslušní správcovia údajov. Plánovač SQL/MX rozdeľuje úlohy medzi vykonávateľov a agreguje výsledky. Keď je potrebné vykonať dohodnuté zmeny, použije sa dvojfázový protokol odovzdania, ktorý poskytuje knižnica TMF (Transaction Management Facility).
NonStop SQL dokáže uprednostniť procesy tak, aby dlhé analytické dotazy nezasahovali do vykonávania transakcie. Jeho účelom je však práve spracovanie krátkych transakcií a nie analytika. Developer garantuje dostupnosť NonStop klastra na úrovni piatich „deviatok“, čiže prestoje sú len 5 minút ročne.
SAP-HANA
Prvé stabilné vydanie HANA DBMS (1.0) sa uskutočnilo v novembri 2010 a balík SAP ERP prešiel na HANA v máji 2013. Platforma je založená na zakúpených technológiách: TREX Search Engine (vyhľadávanie v stĺpcovom úložisku), P*TIME DBMS a MAX DB.
Samotné slovo „HANA“ je skratka, vysokovýkonné analytické zariadenie. Tento DBMS je dodávaný vo forme kódu, ktorý môže bežať na ľubovoľných x86 serveroch, avšak priemyselné inštalácie sú povolené len na certifikovaných zariadeniach. Riešenia dostupné od HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Niektoré konfigurácie Lenova umožňujú aj prevádzku bez SAN – úlohu bežného úložného systému zohráva GPFS cluster na lokálnych diskoch.
Na rozdiel od platforiem uvedených vyššie je HANA in-memory DBMS, t. j. primárny dátový obraz je uložený v RAM a na disk sa zapisujú iba protokoly a pravidelné snímky na obnovenie v prípade havárie.
Každý uzol klastra HANA je zodpovedný za svoju vlastnú časť údajov a mapa údajov je uložená v špeciálnom komponente – Name Server, ktorý sa nachádza v uzle koordinátora. Údaje sa medzi uzlami neduplikujú. Informácie o uzamknutí sú tiež uložené v každom uzle, ale systém má globálny detektor zablokovania.
Keď sa klient HANA pripojí ku klastru, stiahne si svoju topológiu a potom môže priamo pristupovať k akémukoľvek uzlu v závislosti od toho, aké údaje potrebuje. Ak transakcia ovplyvňuje údaje jedného uzla, môže byť vykonaná lokálne týmto uzlom, ale ak sa zmenia údaje niekoľkých uzlov, iniciačný uzol kontaktuje koordinačný uzol, ktorý otvorí a koordinuje distribuovanú transakciu a vykoná ju pomocou optimalizovaný dvojfázový protokol odovzdania.
Koordinačný uzol je duplikovaný, takže ak koordinátor zlyhá, okamžite prevezme záložný uzol. Ale ak uzol s údajmi zlyhá, potom jediný spôsob, ako získať prístup k jeho údajom, je reštartovať uzol. Klastre HANA spravidla udržiavajú náhradný server, aby sa na ňom čo najrýchlejšie reštartoval stratený uzol.
Zdroj: hab.com