A CAP-tétel az elosztott rendszerek elméletének sarokköve. Természetesen a körülötte zajló vita nem csillapodik: a benne található definíciók nem kanonikusak, és nincs szigorú bizonyíték... Ennek ellenére, szilárdan a mindennapi józan ész™ álláspontjain állva, intuitív módon megértjük, hogy a tétel igaz.
Az egyetlen dolog, ami nem nyilvánvaló, az a "P" betű jelentése. Amikor a fürt fel van osztva, eldönti, hogy nem válaszol-e, amíg el nem éri a határozatképességet, vagy visszaadja a rendelkezésre álló adatokat. A választás eredményétől függően a rendszert CP vagy AP kategóriába sorolják. Cassandra például mindkét módon viselkedhet, még csak nem is a fürt beállításaitól, hanem az egyes kérések paramétereitől függően. De ha a rendszer nem "P" és szétválik, akkor mi van?
A kérdésre adott válasz némileg váratlan: a CA-fürt nem tud szétválni.
Milyen klaszter ez, ami nem tud szétválni?
Egy ilyen klaszter nélkülözhetetlen tulajdonsága a megosztott adattároló rendszer. Az esetek túlnyomó többségében ez SAN-on keresztüli csatlakozást jelent, ami a CA-megoldások használatát a SAN-infrastruktúrát fenntartani képes nagyvállalatokra korlátozza. Ahhoz, hogy több kiszolgáló ugyanazokkal az adatokkal működjön, fürtözött fájlrendszerre van szükség. Ilyen fájlrendszerek állnak rendelkezésre a HPE (CFS), a Veritas (VxCFS) és az IBM (GPFS) portfóliójában.
Oracle RAC
A Real Application Cluster opció először 2001-ben jelent meg az Oracle 9i kiadásával. Egy ilyen fürtben több kiszolgálópéldány működik ugyanazzal az adatbázissal.
Az Oracle fürtözött fájlrendszerrel és saját megoldással – ASM, Automatic Storage Management – egyaránt tud dolgozni.
Minden példány saját naplót vezet. A tranzakciót egy példány hajtja végre és véglegesíti. Ha egy példány meghibásodik, az egyik túlélő fürtcsomópont (példány) beolvassa a naplóját, és visszaállítja az elveszett adatokat – ezzel biztosítva a rendelkezésre állást.
Minden példány saját gyorsítótárat tart fenn, és ugyanazok az oldalak (blokkok) egyszerre több példány gyorsítótárában is lehetnek. Sőt, ha az egyik példánynak szüksége van egy oldalra, és az egy másik példány gyorsítótárában van, akkor a lemezről történő olvasás helyett a gyorsítótár-fúziós mechanizmus segítségével lekérheti azt szomszédjától.
De mi történik, ha az egyik példánynak módosítania kell az adatokat?
Az Oracle sajátossága, hogy nem rendelkezik dedikált zárolási szolgáltatással: ha a szerver zárolni akar egy sort, akkor a zárolási rekord közvetlenül arra a memóriaoldalra kerül, ahol a zárolt sor található. Ennek a megközelítésnek köszönhetően az Oracle a teljesítménybajnok a monolitikus adatbázisok között: a zárolási szolgáltatás soha nem válik szűk keresztmetszetté. A fürtkonfigurációban azonban egy ilyen architektúra intenzív hálózati forgalomhoz és holtpontokhoz vezethet.
Ha egy rekord zárolva van, egy példány értesíti az összes többi példányt, hogy az adott rekordot tároló oldal kizárólagos megőrzéssel rendelkezik. Ha egy másik példánynak meg kell változtatnia egy rekordot ugyanazon az oldalon, akkor meg kell várnia, amíg az oldalon végrehajtott módosítások véglegesítésre kerülnek, azaz a változási információk egy lemezen lévő naplóba kerülnek (és a tranzakció folytatódhat). Az is előfordulhat, hogy egy oldalt egymás után több példányban módosítanak, majd az oldal lemezre írásakor meg kell találni, hogy ki tárolja az oldal aktuális verzióját.
Ugyanazon oldalak véletlenszerű frissítése a különböző RAC-csomópontokon az adatbázis teljesítményének drámai csökkenését okozza, egészen addig a pontig, ahol a fürt teljesítménye alacsonyabb lehet, mint egyetlen példányé.
Az Oracle RAC helyes használata az adatok fizikai particionálása (például particionált tábla-mechanizmus használatával), és az egyes partíciók elérése egy dedikált csomóponton keresztül. A RAC fő célja nem a vízszintes skálázás volt, hanem a hibatűrés biztosítása.
Ha egy csomópont nem reagál a szívverésre, akkor az azt először észlelő csomópont szavazási eljárást indít a lemezen. Ha a hiányzó csomópont itt nincs feltüntetve, akkor az egyik csomópont átveszi az adat-helyreállítás felelősségét:
- „lefagyaszt” minden oldalt, amely a hiányzó csomópont gyorsítótárában volt;
- beolvassa a hiányzó csomópont naplóit (újra) és újra alkalmazza az ezekben a naplókban rögzített változtatásokat, egyidejűleg ellenőrzi, hogy más csomópontok rendelkeznek-e a módosítandó oldalak újabb verziójával;
- visszaállítja a függőben lévő tranzakciókat.
A csomópontok közötti váltás leegyszerűsítése érdekében az Oracle egy szolgáltatás – egy virtuális példány – koncepcióját használja. Egy példány több szolgáltatást is kiszolgálhat, és egy szolgáltatás mozoghat a csomópontok között. Az adatbázis egy bizonyos részét kiszolgáló alkalmazáspéldány (például ügyfelek egy csoportja) egy szolgáltatással működik, és az adatbázis ezen részéért felelős szolgáltatás egy másik csomópontba kerül, ha egy csomópont meghibásodik.
IBM Pure Data Systems for Transactions
A Blue Giant portfóliójában 2009-ben jelent meg egy fürtmegoldás a DBMS-hez. Ideológiailag a Parallel Sysplex klaszter utódja, amely „szokásos” berendezésekre épül. 2009-ben a DB2 pureScale szoftvercsomagként jelent meg, 2012-ben pedig az IBM egy Pure Data Systems for Transactions nevű készüléket kínált. Nem szabad összetéveszteni a Pure Data Systems for Analytics rendszerrel, amely nem más, mint egy átnevezett Netezza.
A pureScale architektúra első ránézésre hasonlít az Oracle RAC-hoz: ugyanígy több csomópont kapcsolódik egy közös adattároló rendszerhez, és mindegyik csomópont saját DBMS-példányt futtat saját memóriaterületekkel és tranzakciós naplókkal. Az Oracle-lel ellentétben azonban a DB2 rendelkezik egy dedikált zárolási szolgáltatással, amelyet db2LLM* folyamatok képviselnek. Fürtkonfigurációban ez a szolgáltatás egy külön csomóponton van elhelyezve, amelyet a Parallel Sysplexben csatolási lehetőségnek (CF), a Pure Data esetén pedig PowerHA-nak neveznek.
A PowerHA a következő szolgáltatásokat nyújtja:
- zárkezelő;
- globális puffer gyorsítótár;
- a folyamatok közötti kommunikáció területe.
Az adatok PowerHA-ból az adatbázis-csomópontokhoz és vissza átviteléhez távoli memória-hozzáférést használnak, így a fürt összekapcsolásának támogatnia kell az RDMA protokollt. A PureScale az Infinibandot és az RDMA-t is tudja használni Etherneten keresztül.
Ha egy csomópontnak szüksége van egy oldalra, és ez az oldal nincs a gyorsítótárban, akkor a csomópont kéri az oldalt a globális gyorsítótárban, és csak ha nincs ott, akkor olvassa be a lemezről. Az Oracle-lel ellentétben a kérés csak a PowerHA-hoz érkezik, a szomszédos csomópontokhoz nem.
Ha egy példány módosítani fog egy sort, akkor azt kizárólagos módba zárja, az oldalt pedig, ahol a sor található, megosztott módban. Minden zár regisztrálva van a globális zárkezelőben. Amikor a tranzakció befejeződik, a csomópont üzenetet küld a zárkezelőnek, amely a módosított oldalt a globális gyorsítótárba másolja, feloldja a zárolásokat, és érvényteleníti a módosított oldalt a többi csomópont gyorsítótárában.
Ha az oldal, amelyben a módosított sor található, már zárolva van, akkor a zárkezelő kiolvassa a módosított oldalt a módosítást végrehajtó csomópont memóriájából, feloldja a zárolást, érvényteleníti a módosított oldalt a többi csomópont gyorsítótárában, és adja meg az oldalzárat annak a csomópontnak, amelyik kérte.
„Dirty”, azaz megváltoztatott, lapok írhatók lemezre mind normál csomópontból, mind PowerHA-ból (castout).
Ha az egyik pureScale csomópont meghibásodik, a helyreállítás csak azokra a tranzakciókra korlátozódik, amelyek a meghibásodás időpontjában még nem fejeződtek be: az adott csomópont által a befejezett tranzakciókban módosított oldalak a PowerHA globális gyorsítótárában vannak. A csomópont csökkentett konfigurációban újraindul a fürt egyik kiszolgálóján, visszaállítja a függőben lévő tranzakciókat, és feloldja a zárolásokat.
A PowerHA két kiszolgálón fut, és a fő csomópont szinkron módon replikálja az állapotát. Ha az elsődleges PowerHA csomópont meghibásodik, a fürt továbbra is a tartalék csomóponttal működik.
Természetesen, ha egyetlen csomóponton keresztül éri el az adatkészletet, a fürt általános teljesítménye magasabb lesz. A PureScale még azt is észreveszi, hogy egy bizonyos adatterületet egy csomópont dolgoz fel, majd az adott területhez kapcsolódó összes zárolást helyileg dolgozza fel a csomópont anélkül, hogy kommunikálna a PowerHA-val. De amint az alkalmazás megpróbál hozzáférni ezekhez az adatokhoz egy másik csomóponton keresztül, a központi zárolási feldolgozás folytatódik.
Az IBM belső tesztjei 90%-os olvasási és 10%-os írási terhelésen, ami nagyon hasonlít a valós termelési terhelésekhez, szinte lineáris skálázást mutatnak 128 csomópontig. A tesztkörülményeket sajnos nem hozták nyilvánosságra.
HPE NonStop SQL
A Hewlett-Packard Enterprise portfóliónak is megvan a maga magasan elérhető platformja. Ez a NonStop platform, amelyet a Tandem Computers adott ki 1976-ban. 1997-ben a céget felvásárolta a Compaq, amely 2002-ben egyesült a Hewlett-Packarddal.
A NonStop kritikus alkalmazások létrehozására szolgál – például HLR vagy bankkártya-feldolgozás. A platform szoftver- és hardverkomplexum (appliance) formájában kerül szállításra, amely számítási csomópontokat, adattároló rendszert és kommunikációs berendezéseket foglal magában. A ServerNet hálózat (modern rendszerekben - Infiniband) a csomópontok közötti cserére és az adattároló rendszerhez való hozzáférésre egyaránt szolgál.
A rendszer korai verziói saját, egymással szinkronizált processzorokat használtak: minden műveletet több processzor szinkronban hajtott végre, és amint az egyik processzor hibát vétett, kikapcsolták, a második pedig tovább működött. Később a rendszer áttért a hagyományos processzorokra (először MIPS, majd Itanium és végül x86), és más mechanizmusokat is elkezdtek használni a szinkronizáláshoz:
- üzenetek: minden rendszerfolyamatnak van egy „árnyék” ikerpárja, amelynek az aktív folyamat időszakonként üzeneteket küld az állapotáról; ha a főfolyamat meghiúsul, az árnyékfolyamat az utolsó üzenet által meghatározott pillanattól kezdi meg működését;
- szavazás: a tárolórendszernek van egy speciális hardverkomponense, amely több azonos hozzáférést is elfogad, és csak akkor hajtja végre, ha a hozzáférések egyeznek; A processzorok fizikai szinkronizálás helyett aszinkron módon működnek, és munkájuk eredményét csak az I/O pillanatokban hasonlítják össze.
1987 óta egy relációs DBMS fut a NonStop platformon – először SQL/MP, majd később SQL/MX.
A teljes adatbázis részekre van osztva, és mindegyik rész felelős a saját Data Access Manager (DAM) folyamatáért. Adatrögzítési, gyorsítótárazási és zárolási mechanizmusokat biztosít. Az adatfeldolgozást az Executor Server Processes végzi, amely ugyanazokon a csomópontokon fut, mint a megfelelő adatkezelők. Az SQL/MX ütemező felosztja a feladatokat a végrehajtók között, és összesíti az eredményeket. Ha egyeztetett változtatásokra van szükség, akkor a TMF (Tranzakciókezelési Facility) könyvtár által biztosított kétfázisú véglegesítési protokollt használják.
A NonStop SQL képes prioritást adni a folyamatoknak, így a hosszú elemző lekérdezések nem zavarják a tranzakciók végrehajtását. Célja azonban éppen a rövid tranzakciók feldolgozása, nem pedig az elemzés. A fejlesztő a NonStop klaszter elérhetőségét öt „kilenc” szinten garantálja, vagyis az állásidő mindössze évi 5 perc.
SAP-HANA
A HANA DBMS (1.0) első stabil kiadására 2010 novemberében került sor, az SAP ERP csomag pedig 2013 májusában vált HANA-ra. A platform vásárolt technológiákon alapul: TREX Search Engine (keresés oszlopos tárolóban), P*TIME DBMS és MAX DB.
Maga a „HANA” szó egy mozaikszó, High performance Analytical Appliance. Ezt a DBMS-t olyan kód formájában szállítjuk, amely bármely x86-os szerveren futhat, azonban az ipari telepítés csak tanúsított berendezéseken engedélyezett. Megoldások elérhetők a HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC cégeknél. Egyes Lenovo konfigurációk akár SAN nélkül is működnek – a közös tárolórendszer szerepét a helyi lemezeken található GPFS-fürt tölti be.
A fent felsorolt platformokkal ellentétben a HANA egy memórián belüli DBMS, azaz az elsődleges adatkép a RAM-ban van tárolva, és csak a naplók és az időszakos pillanatképek kerülnek a lemezre katasztrófa esetén helyreállítás céljából.
Minden HANA-fürtcsomópont felelős az adatok saját részéért, és az adattérkép egy speciális komponensben – a koordinátor csomóponton található névszerverben – tárolódik. Az adatok nem duplikálódnak a csomópontok között. A zárolási információkat is tárolják minden csomóponton, de a rendszer rendelkezik globális holtpont-érzékelővel.
Amikor egy HANA-kliens egy fürthöz csatlakozik, letölti a topológiáját, majd közvetlenül hozzáférhet bármely csomóponthoz, attól függően, hogy milyen adatokra van szüksége. Ha egy tranzakció egyetlen csomópont adatait érinti, akkor azt az adott csomópont helyileg végrehajthatja, de ha több csomópont adatai megváltoznak, akkor a kezdeményező csomópont felveszi a kapcsolatot a koordinátor csomóponttal, amely megnyitja és koordinálja az elosztott tranzakciót, véglegesítve azt egy optimalizált kétfázisú véglegesítési protokoll.
A koordinátor csomópont duplikált, így ha a koordinátor meghibásodik, a tartalék csomópont azonnal átveszi az irányítást. De ha egy adatokat tartalmazó csomópont meghibásodik, akkor az adatokhoz való hozzáférés egyetlen módja a csomópont újraindítása. Általános szabály, hogy a HANA-fürtök tartalék szervert tartanak fenn, hogy a lehető leggyorsabban újraindítsák az elveszett csomópontot.
Forrás: will.com