CAP teoreem on hajutatud süsteemide teooria nurgakivi. Muidugi ei vaibu selle ümber käiv poleemika: selles sisalduvad definitsioonid ei ole kanoonilised ja puudub ka range tõestus... Sellegipoolest, seistes kindlalt igapäevase terve mõistuse™ seisukohtadel, saame intuitiivselt aru, et teoreem vastab tõele.
Ainus asi, mis pole ilmne, on tähe "P" tähendus. Kui klaster on jagatud, otsustab see, kas mitte vastata enne kvoorumi saavutamist või tagastada saadaolevad andmed. Sõltuvalt selle valiku tulemustest klassifitseeritakse süsteem kas CP-ks või AP-ks. Näiteks Cassandra võib käituda mõlemal viisil, sõltudes isegi mitte klastri sätetest, vaid iga konkreetse päringu parameetritest. Aga kui süsteem pole "P" ja see jaguneb, mis siis?
Vastus sellele küsimusele on mõnevõrra ootamatu: CA-klastrit ei saa jagada.
Mis tüüpi klaster see on, mis ei saa jaguneda?
Sellise klastri asendamatu atribuut on jagatud andmesalvestussüsteem. Enamikul juhtudel tähendab see ühenduse loomist SAN-i kaudu, mis piirab CA-lahenduste kasutamist suurettevõtetega, kes on võimelised SAN-infrastruktuuri hooldama. Selleks, et samade andmetega töötaks mitu serverit, on vaja rühmitatud failisüsteemi. Sellised failisüsteemid on saadaval HPE (CFS), Veritas (VxCFS) ja IBM (GPFS) portfellis.
Oracle RAC
Valik Real Application Cluster ilmus esmakordselt 2001. aastal Oracle 9i väljalaskmisega. Sellises klastris töötavad sama andmebaasiga mitu serverieksemplari.
Oracle saab töötada nii rühmitatud failisüsteemiga kui ka oma lahendusega – ASM, Automatic Storage Management.
Iga eksemplar peab oma päevikut. Tehingu teostab ja paneb toime üks eksemplar. Kui eksemplar ebaõnnestub, loeb üks säilinud klastri sõlmedest (eksemplaridest) selle logi ja taastab kaotatud andmed – tagades seeläbi kättesaadavuse.
Kõik eksemplarid säilitavad oma vahemälu ja samad lehed (plokid) võivad olla korraga mitme eksemplari vahemälus. Veelgi enam, kui üks eksemplar vajab lehte ja see on teise eksemplari vahemälus, saab ta selle hankida oma naabrilt, kasutades vahemälu liitmismehhanismi, mitte kettalt lugemist.
Mis saab aga siis, kui üks eksemplaridest peab andmeid muutma?
Oracle'i eripäraks on see, et sellel puudub spetsiaalne lukustusteenus: kui server soovib rida lukustada, siis lukukirje paigutatakse otse sellele mälulehele, kus lukustatud rida asub. Tänu sellele lähenemisele on Oracle jõudluse meister monoliitsete andmebaaside seas: lukustamisteenus ei muutu kunagi kitsaskohaks. Kuid klastri konfiguratsioonis võib selline arhitektuur põhjustada intensiivset võrguliiklust ja ummikseisu.
Kui kirje on lukustatud, teavitab eksemplar kõiki teisi juhtumeid, et seda kirjet salvestaval lehel on eksklusiivne ootel. Kui mõni teine eksemplar peab samal lehel kirjet muutma, peab ta ootama, kuni lehe muudatused on tehtud, st muudatusteave kirjutatakse kettal olevasse ajakirja (ja tehing võib jätkuda). Samuti võib juhtuda, et lehte muudetakse järjestikku mitme eksemplari võrra ja siis tuleb lehe kettale kirjutamisel välja selgitada, kes selle lehe praeguse versiooni talletab.
Samade lehtede juhuslik värskendamine erinevates RAC-sõlmedes põhjustab andmebaasi jõudluse järsu languse, kuni punktini, kus klastri jõudlus võib olla madalam kui ühe eksemplari oma.
Oracle RAC-i õige kasutamine seisneb andmete füüsilises sektsioonis (näiteks partitsioonitabeli mehhanismi abil) ja igale partitsioonikomplektile juurdepääsuks spetsiaalse sõlme kaudu. RAC-i peamine eesmärk ei olnud horisontaalne skaleerimine, vaid veataluvuse tagamine.
Kui sõlm lakkab südamelöökidele reageerimast, alustab sõlm, mis selle esimesena tuvastas, kettal hääletusprotseduuri. Kui puuduvat sõlme siin ei märgita, võtab üks sõlmedest vastutuse andmete taastamise eest:
- "külmutab" kõik lehed, mis olid puuduva sõlme vahemälus;
- loeb puuduva sõlme logisid (teha uuesti) ja rakendab uuesti nendesse logidesse salvestatud muudatused, kontrollides samaaegselt, kas teistel sõlmedel on muudetavate lehtede uuemad versioonid;
- tühistab ootel olevad tehingud.
Sõlmede vahel vahetamise lihtsustamiseks kasutab Oracle teenuse kontseptsiooni – virtuaalset eksemplari. Eksemplar võib teenindada mitut teenust ja teenus võib liikuda sõlmede vahel. Andmebaasi teatud osa teenindav rakenduse eksemplar (näiteks klientide rühm) töötab ühe teenusega ja selle andmebaasi osa eest vastutav teenus liigub sõlme rikke korral teise sõlme.
IBM Pure Data Systems tehingute jaoks
DBMS-i kobarlahendus ilmus Blue Giant portfelli 2009. aastal. Ideoloogiliselt on see Parallel Sysplexi klastri järeltulija, mis on üles ehitatud "tavalistele" seadmetele. 2009. aastal ilmus DB2 pureScale tarkvarakomplektina ja 2012. aastal pakkus IBM seadet nimega Pure Data Systems for Transactions. Seda ei tohiks segi ajada Pure Data Systems for Analyticsiga, mis pole midagi muud kui ümbernimetatud Netezza.
Esmapilgul sarnaneb pureScale arhitektuur Oracle RAC-iga: samamoodi on mitu sõlme ühendatud ühise andmesalvestussüsteemiga ning iga sõlm käitab oma DBMS-i eksemplari koos oma mälualade ja tehingulogidega. Kuid erinevalt Oracle'ist on DB2-l spetsiaalne lukustusteenus, mida esindab db2LLM* protsesside komplekt. Klastri konfiguratsioonis paigutatakse see teenus eraldi sõlme, mida Parallel Sysplexis nimetatakse sidumisvõimaluseks (CF) ja Pure Data puhul PowerHA-ks.
PowerHA pakub järgmisi teenuseid:
- lukuhaldur;
- globaalne puhvri vahemälu;
- protsessidevahelise side valdkond.
Andmete edastamiseks PowerHA-st andmebaasi sõlmedesse ja tagasi kasutatakse kaugjuurdepääsu mälule, seega peab klastri ühendus toetama RDMA-protokolli. PureScale saab Etherneti kaudu kasutada nii Infinibandi kui ka RDMA-d.
Kui sõlm vajab lehte ja seda lehte pole vahemälus, siis küsib sõlm seda lehte globaalses vahemälus ja ainult siis, kui seda seal pole, loeb seda kettalt. Erinevalt Oracle'ist edastatakse päring ainult PowerHA-le, mitte naabersõlmedele.
Kui eksemplar kavatseb rida muuta, lukustab see eksklusiivse režiimi ja lehe, kus rida asub, jagatud režiimis. Kõik lukud registreeritakse globaalses lukuhalduris. Kui tehing on lõpule viidud, saadab sõlm teate lukuhaldurile, mis kopeerib muudetud lehe globaalsesse vahemällu, vabastab lukud ja muudab muudetud lehe kehtetuks teiste sõlmede vahemäludes.
Kui leht, millel muudetud rida asub, on juba lukustatud, loeb lukuhaldur muudetud lehe muudatuse teinud sõlme mälust, vabastab luku, tühistab muudetud lehe teiste sõlmede vahemäludes ja andke lehe lukk seda taotlenud sõlmele.
“Määrdunud”, st muudetud, lehti saab kettale kirjutada nii tavalisest sõlmest kui ka PowerHA-st (castout).
Kui üks pureScale'i sõlmedest ebaõnnestub, piirdub taastamine ainult nende tehingutega, mida tõrke ajal veel lõpule ei viidud: selle sõlme poolt lõpetatud tehingutes muudetud lehed on PowerHA globaalses vahemälus. Sõlm taaskäivitub vähendatud konfiguratsioonis ühes klastri serveris, tühistab ootel olevad tehingud ja vabastab lukud.
PowerHA töötab kahes serveris ja põhisõlm kordab selle olekut sünkroonselt. Kui esmane PowerHA-sõlm ebaõnnestub, jätkab klaster tööd varusõlmega.
Muidugi, kui pääsete andmekogumile juurde ühe sõlme kaudu, on klastri üldine jõudlus suurem. PureScale võib isegi märgata, et teatud andmepiirkonda töötleb üks sõlm ja seejärel töötleb sõlm kõiki selle alaga seotud lukke lokaalselt, ilma PowerHA-ga suhtlemata. Kuid niipea, kui rakendus proovib neile andmetele mõne teise sõlme kaudu juurde pääseda, jätkub tsentraliseeritud lukutöötlus.
IBM-i sisetestid 90% lugemis- ja 10% kirjutamiskoormusega, mis on väga sarnased tegelike tootmistöökoormustega, näitavad peaaegu lineaarset skaleerimist kuni 128 sõlmeni. Kahjuks katsetingimusi ei avalikustata.
HPE NonStop SQL
Hewlett-Packardi ettevõtte portfellil on ka oma kõrgetasemeline platvorm. See on NonStop platvorm, mille andis turule 1976. aastal Tandem Computers. 1997. aastal omandas ettevõtte Compaq, mis omakorda ühines 2002. aastal Hewlett-Packardiga.
NonStopi kasutatakse kriitiliste rakenduste loomiseks – näiteks HLR või pangakaarditöötlus. Platvorm tarnitakse tarkvara- ja riistvarakompleksi (seadme) kujul, mis sisaldab arvutussõlme, andmesalvestussüsteemi ja sideseadmeid. ServerNeti võrk (kaasaegsetes süsteemides - Infiniband) on mõeldud nii sõlmedevaheliseks teabevahetuseks kui ka juurdepääsuks andmesalvestussüsteemile.
Süsteemi varased versioonid kasutasid patenteeritud protsessoreid, mis olid üksteisega sünkroonitud: kõik toimingud sooritasid sünkroonselt mitu protsessorit ja niipea, kui üks protsessoritest tegi vea, lülitati see välja ja teine jätkas tööd. Hiljem läks süsteem üle tavalistele protsessoritele (esmalt MIPS, siis Itanium ja lõpuks x86) ning sünkroonimiseks hakati kasutama muid mehhanisme:
- teated: igal süsteemiprotsessil on "vari" kaksik, millele aktiivne protsess saadab perioodiliselt teateid oma oleku kohta; kui põhiprotsess ebaõnnestub, hakkab variprotsess tööle viimase sõnumiga määratud hetkest;
- hääletamine: salvestussüsteemil on spetsiaalne riistvarakomponent, mis aktsepteerib mitut identset juurdepääsu ja teostab neid ainult siis, kui juurdepääsud ühtivad; Füüsilise sünkroniseerimise asemel töötavad protsessorid asünkroonselt ning nende töö tulemusi võrreldakse vaid I/O-hetkedel.
Alates 1987. aastast töötab NonStop platvormil relatsiooniline DBMS – algul SQL/MP ja hiljem SQL/MX.
Kogu andmebaas on jagatud osadeks ja iga osa vastutab oma Data Access Manageri (DAM) protsessi eest. See pakub andmete salvestamise, vahemällu salvestamise ja lukustamise mehhanisme. Andmetöötlust teostavad Executor Server Processes, mis töötavad vastavate andmehalduritega samades sõlmedes. SQL/MX planeerija jagab ülesanded täitjate vahel ja koondab tulemused. Kui on vaja teha kokkulepitud muudatusi, kasutatakse TMF (Transaction Management Facility) teegi pakutavat kahefaasilist commit protokolli.
NonStop SQL suudab protsesse prioritiseerida, nii et pikad analüütilised päringud ei sega tehingute täitmist. Selle eesmärk on aga just lühikeste tehingute töötlemine, mitte analüütika. Arendaja tagab NonStop klastri kättesaadavuse viie “üheksa” tasemel, see tähendab, et seisakuid on vaid 5 minutit aastas.
SAP-HANA
HANA DBMS-i (1.0) esimene stabiilne väljalase toimus 2010. aasta novembris ja SAP ERP pakett läks 2013. aasta mais üle HANA-le. Platvorm põhineb ostetud tehnoloogiatel: TREX Search Engine (otsing veergude mälus), P*TIME DBMS ja MAX DB.
Sõna "HANA" ise on akronüüm High Performance Analytical Appliance. Seda DBMS-i tarnitakse koodina, mis võib töötada mis tahes x86-serveris, kuid tööstuslikud paigaldused on lubatud ainult sertifitseeritud seadmetele. HP, Lenovo, Cisco, Delli, Fujitsu, Hitachi, NEC lahendused. Mõned Lenovo konfiguratsioonid võimaldavad isegi töötada ilma SAN-ita – ühise salvestussüsteemi rolli täidab kohalikel ketastel olev GPFS-klaster.
Erinevalt ülaltoodud platvormidest on HANA mälusisene DBMS, st esmane andmepilt salvestatakse RAM-i ning kettale kirjutatakse katastroofi korral taastamiseks ainult logid ja perioodilised hetktõmmised.
Iga HANA klastri sõlm vastutab oma osa andmete eest ja andmekaarti hoitakse spetsiaalses komponendis - Name Server, mis asub koordinaatorsõlmel. Andmeid sõlmede vahel ei dubleerita. Igasse sõlme salvestatakse ka lukustusinfo, kuid süsteemil on globaalne ummikseisu detektor.
Kui HANA klient loob ühenduse klastriga, laadib see alla selle topoloogia ja pääseb seejärel otse igale sõlmele, olenevalt sellest, milliseid andmeid see vajab. Kui tehing mõjutab ühe sõlme andmeid, siis saab selle sõlme lokaalselt teostada, kuid kui mitme sõlme andmed muutuvad, võtab algatav sõlm ühendust koordinaatorsõlmega, mis avab ja koordineerib hajutatud tehingu, sooritades selle optimeeritud kahefaasiline kinnistamisprotokoll.
Koordinaatori sõlm on dubleeritud, nii et kui koordinaator ebaõnnestub, võtab varusõlm kohe üle. Kuid kui andmetega sõlm ebaõnnestub, on ainus viis selle andmetele juurde pääseda sõlme taaskäivitamine. HANA klastrid hoiavad reeglina varuserverit, et sellel kadunud sõlm võimalikult kiiresti taaskäivitada.
Allikas: www.habr.com