Die CAP-stelling is die hoeksteen van verspreide sisteemteorie. Natuurlik bedaar die kontroversie rondom dit nie: die definisies daarin is nie kanonies nie, en daar is geen streng bewys nie... Nietemin, stewig op die standpunte van alledaagse gesonde verstand™, verstaan ons intuïtief dat die stelling waar is.
Die enigste ding wat nie duidelik is nie, is die betekenis van die letter "P". Wanneer die groep verdeel word, besluit dit of hy nie moet reageer totdat 'n kworum bereik is nie, of om die data wat beskikbaar is terug te gee. Afhangende van die resultate van hierdie keuse, word die stelsel as óf 'n CP óf 'n AP geklassifiseer. Cassandra, byvoorbeeld, kan enige manier optree, afhangende nie eers van die groepinstellings nie, maar van die parameters van elke spesifieke versoek. Maar as die stelsel nie "P" is nie en dit verdeel, wat dan?
Die antwoord op hierdie vraag is ietwat onverwags: 'n CA-kluster kan nie verdeel nie.
Watter soort tros is dit wat nie kan verdeel nie?
'n Onontbeerlike eienskap van so 'n groepering is 'n gedeelde databergingstelsel. In die oorgrote meerderheid van gevalle beteken dit om oor 'n SAN te koppel, wat die gebruik van CA-oplossings beperk tot groot ondernemings wat in staat is om 'n SAN-infrastruktuur te onderhou. Ten einde vir veelvuldige bedieners om met dieselfde data te werk, word 'n gegroepeerde lêerstelsel vereis. Sulke lêerstelsels is beskikbaar in die HPE (CFS), Veritas (VxCFS) en IBM (GPFS) portefeuljes.
Oracle RAC
Die Real Application Cluster-opsie het die eerste keer in 2001 verskyn met die vrystelling van Oracle 9i. In so 'n groep werk verskeie bedienergevalle met dieselfde databasis.
Oracle kan met beide 'n gegroepeerde lêerstelsel en sy eie oplossing werk - ASM, outomatiese bergingsbestuur.
Elke kopie hou sy eie joernaal. Die transaksie word deur een instansie uitgevoer en gepleeg. As 'n instansie misluk, lees een van die oorlewende cluster nodusse (gevalle) sy logboek en herstel die verlore data - om sodoende beskikbaarheid te verseker.
Alle gevalle handhaaf hul eie kas, en dieselfde bladsye (blokke) kan gelyktydig in die kas van verskeie gevalle wees. Verder, as een instansie 'n bladsy benodig en dit is in die kas van 'n ander instansie, kan dit dit van sy buurman kry deur die kassamesmeltingsmeganisme te gebruik in plaas daarvan om van skyf af te lees.
Maar wat gebeur as een van die gevalle data moet verander?
Die eienaardigheid van Oracle is dat dit nie 'n toegewyde sluitdiens het nie: as die bediener 'n ry wil sluit, word die slotrekord direk op die geheuebladsy geplaas waar die geslote ry geleë is. Danksy hierdie benadering is Oracle die prestasiekampioen onder monolitiese databasisse: die sluitdiens word nooit 'n bottelnek nie. Maar in 'n groepkonfigurasie kan so 'n argitektuur lei tot intense netwerkverkeer en dooiepunte.
Sodra 'n rekord gesluit is, stel 'n instansie alle ander gevalle in kennis dat die bladsy wat daardie rekord stoor 'n eksklusiewe houvas het. As 'n ander instansie 'n rekord op dieselfde bladsy moet verander, moet dit wag totdat die veranderinge aan die bladsy toegepas is, dit wil sê die veranderingsinligting word na 'n joernaal op skyf geskryf (en die transaksie kan voortgaan). Dit kan ook gebeur dat 'n bladsy opeenvolgend deur verskeie kopieë verander sal word, en wanneer jy die bladsy na skyf skryf, sal jy moet uitvind wie die huidige weergawe van hierdie bladsy stoor.
Die ewekansige opdatering van dieselfde bladsye oor verskillende RAC-nodusse veroorsaak dat databasiswerkverrigting dramaties daal, tot die punt waar groepwerkverrigting laer kan wees as dié van 'n enkele instansie.
Die korrekte gebruik van Oracle RAC is om die data fisies te partisieer (byvoorbeeld deur 'n gepartisioneerde tabelmeganisme) en toegang tot elke stel partisies deur 'n toegewyde nodus te verkry. Die hoofdoel van RAC was nie horisontale skaal nie, maar om fouttoleransie te verseker.
As 'n nodus ophou reageer op 'n hartklop, dan begin die nodus wat dit eerste opgespoor het 'n stemprosedure op die skyf. As die ontbrekende nodus nie hier aangeteken word nie, neem een van die nodusse die verantwoordelikheid vir dataherwinning op:
- "vries" alle bladsye wat in die kas van die vermiste nodus was;
- lees die logs (herdoen) van die ontbrekende nodus en pas die veranderinge wat in hierdie logs aangeteken is weer toe, en kyk terselfdertyd of ander nodusse meer onlangse weergawes het van die bladsye wat verander word;
- draai hangende transaksies terug.
Om oorskakeling tussen nodusse te vereenvoudig, het Oracle die konsep van 'n diens - 'n virtuele instansie. 'n Geval kan verskeie dienste bedien, en 'n diens kan tussen nodusse beweeg. 'n Toepassingsinstansie wat 'n sekere deel van die databasis bedien (byvoorbeeld 'n groep kliënte) werk met een diens, en die diens verantwoordelik vir hierdie deel van die databasis skuif na 'n ander nodus wanneer 'n nodus misluk.
IBM Pure Data Systems for Transactions
'n Trosoplossing vir DBBS het in 2009 in die Blue Giant-portefeulje verskyn. Ideologies is dit die opvolger van die Parallel Sysplex-kluster, gebou op "gewone" toerusting. In 2009 is DB2 pureScale as 'n sagtewarepakket vrygestel, en in 2012 het IBM 'n toestel genaamd Pure Data Systems for Transactions aangebied. Dit moet nie verwar word met Pure Data Systems for Analytics nie, wat niks meer as 'n hernoemde Netezza is nie.
Met die eerste oogopslag is die pureScale-argitektuur soortgelyk aan Oracle RAC: op dieselfde manier is verskeie nodusse aan 'n gemeenskaplike databergingstelsel gekoppel, en elke nodus bestuur sy eie DBMS-instansie met sy eie geheueareas en transaksielogboeke. Maar, anders as Oracle, het DB2 'n toegewyde sluitdiens wat deur 'n stel db2LLM*-prosesse verteenwoordig word. In 'n groepkonfigurasie word hierdie diens op 'n aparte nodus geplaas, wat koppelingsfasiliteit (CF) in Parallel Sysplex genoem word, en PowerHA in Pure Data.
PowerHA verskaf die volgende dienste:
- slotbestuurder;
- globale bufferkas;
- gebied van interproses kommunikasie.
Om data vanaf PowerHA na die databasisnodusse en terug oor te dra, word afstandgeheuetoegang gebruik, dus moet die klusterverbinding die RDMA-protokol ondersteun. PureScale kan beide Infiniband en RDMA oor Ethernet gebruik.
As 'n nodus 'n bladsy benodig, en hierdie bladsy is nie in die kas nie, dan versoek die nodus die bladsy in die globale kas, en slegs as dit nie daar is nie, lees dit vanaf skyf. Anders as Oracle, gaan die versoek slegs na PowerHA, en nie na naburige nodusse nie.
As 'n instansie 'n ry gaan verander, sluit dit dit in eksklusiewe modus, en die bladsy waar die ry geleë is in gedeelde modus. Alle slotte is geregistreer in die globale slotbestuurder. Wanneer die transaksie voltooi is, stuur die nodus 'n boodskap aan die slotbestuurder, wat die gewysigde bladsy na die globale kas kopieer, die slotte vrystel en die gewysigde bladsy in die kas van ander nodusse ongeldig maak.
As die bladsy waarin die gewysigde ry geleë is reeds gesluit is, sal die slotbestuurder die gewysigde bladsy lees uit die geheue van die nodus wat die verandering gemaak het, die slot losmaak, die gewysigde bladsy in die kas van ander nodusse ongeldig maak, en gee die bladsyslot aan die nodus wat dit versoek het.
"Vuil", dit wil sê, verander, bladsye kan vanaf 'n gewone nodus en vanaf PowerHA (castout) na skyf geskryf word.
As een van die pureScale-nodusse misluk, word herstel beperk tot slegs daardie transaksies wat nog nie voltooi was ten tyde van mislukking nie: die bladsye wat deur daardie nodus in voltooide transaksies gewysig is, is in die globale kas op PowerHA. Die nodus herbegin in 'n verminderde konfigurasie op een van die bedieners in die groepie, rol hangende transaksies terug en stel slotte vry.
PowerHA loop op twee bedieners en die hoofnodus herhaal sy toestand sinchronies. As die primêre PowerHA-nodus misluk, gaan die groep voort om met die rugsteunnodus te werk.
Natuurlik, as u toegang tot die datastel deur 'n enkele nodus verkry, sal die algehele werkverrigting van die groep hoër wees. PureScale kan selfs agterkom dat 'n sekere area van data deur een nodus verwerk word, en dan sal alle slotte wat met daardie area verband hou plaaslik deur die nodus verwerk word sonder om met PowerHA te kommunikeer. Maar sodra die toepassing probeer om toegang tot hierdie data deur 'n ander nodus te verkry, sal gesentraliseerde slotverwerking hervat word.
IBM se interne toetse op 'n werklading van 90% lees en 10% skryf, wat baie soortgelyk is aan werklike produksiewerkladings, toon byna lineêre skaal tot 128 nodusse. Toetstoestande word ongelukkig nie bekend gemaak nie.
HPE NonStop SQL
Die Hewlett-Packard Enterprise-portefeulje het ook sy eie hoogs beskikbare platform. Dit is die NonStop-platform, wat in 1976 deur Tandem Computers aan die mark vrygestel is. In 1997 is die maatskappy deur Compaq verkry, wat op sy beurt in 2002 met Hewlett-Packard saamgesmelt het.
NonStop word gebruik om kritieke toepassings te bou - byvoorbeeld HLR- of bankkaartverwerking. Die platform word gelewer in die vorm van 'n sagteware- en hardewarekompleks (toestel), wat rekenaarnodusse, 'n databergingstelsel en kommunikasietoerusting insluit. Die ServerNet-netwerk (in moderne stelsels - Infiniband) dien beide vir uitruiling tussen nodusse en vir toegang tot die databergingstelsel.
Vroeë weergawes van die stelsel het eie verwerkers gebruik wat met mekaar gesinchroniseer is: alle bewerkings is sinchronies deur verskeie verwerkers uitgevoer, en sodra een van die verwerkers 'n fout gemaak het, is dit afgeskakel, en die tweede het aanhou werk. Later het die stelsel oorgeskakel na konvensionele verwerkers (eers MIPS, toe Itanium en uiteindelik x86), en ander meganismes het begin om vir sinchronisasie gebruik te word:
- boodskappe: elke stelselproses het 'n "skaduwee"-tweeling, waarna die aktiewe proses periodiek boodskappe oor sy status stuur; as die hoofproses misluk, begin die skaduproses werk vanaf die oomblik wat deur die laaste boodskap bepaal is;
- stem: die stoorstelsel het 'n spesiale hardeware-komponent wat veelvuldige identiese toegange aanvaar en dit slegs uitvoer as die toegange ooreenstem; In plaas van fisiese sinchronisasie, werk verwerkers asinchroon, en die resultate van hul werk word slegs op I/O-oomblikke vergelyk.
Sedert 1987 word 'n relasionele DBBS op die NonStop-platform uitgevoer - eers SQL/MP, en later SQL/MX.
Die hele databasis is in dele verdeel, en elke deel is verantwoordelik vir sy eie Data Access Manager (DAM) proses. Dit bied data-opname, kas- en sluitmeganismes. Dataverwerking word uitgevoer deur Executor Server Processes wat op dieselfde nodusse as die ooreenstemmende databestuurders loop. Die SQL/MX skeduleerder verdeel take onder eksekuteurs en versamel die resultate. Wanneer dit nodig is om ooreengekome veranderinge aan te bring, word die twee-fase commit protokol wat deur die TMF (Transaction Management Facility) biblioteek verskaf word, gebruik.
NonStop SQL kan prosesse prioritiseer sodat lang analitiese navrae nie met transaksie-uitvoering inmeng nie. Die doel daarvan is egter juis die verwerking van kort transaksies, en nie ontledings nie. Die ontwikkelaar waarborg die beskikbaarheid van die NonStop-kluster op die vlak van vyf "nege", dit wil sê, stilstand is slegs 5 minute per jaar.
SAP-HANA
Die eerste stabiele vrystelling van die HANA DBMS (1.0) het in November 2010 plaasgevind, en die SAP ERP-pakket het in Mei 2013 na HANA oorgeskakel. Die platform is gebaseer op aangekoopte tegnologieë: TREX-soekenjin (soek in kolomberging), P*TIME DBMS en MAX DB.
Die woord "HANA" self is 'n akroniem, High performance ANAlytical Appliance. Hierdie DBBS word verskaf in die vorm van kode wat op enige x86-bedieners kan loop, maar industriële installasies word slegs op gesertifiseerde toerusting toegelaat. Oplossings beskikbaar by HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Sommige Lenovo-konfigurasies laat selfs werking sonder 'n SAN toe - die rol van 'n algemene bergingstelsel word deur 'n GPFS-groepering op plaaslike skywe gespeel.
Anders as die platforms hierbo gelys, is HANA 'n in-geheue DBMS, dit wil sê die primêre databeeld word in RAM gestoor, en slegs logs en periodieke kiekies word na skyf geskryf vir herstel in geval van 'n ramp.
Elke HANA-klusternodus is verantwoordelik vir sy eie deel van die data, en die datakaart word gestoor in 'n spesiale komponent - Naambediener, geleë op die koördineerderknooppunt. Data word nie tussen nodusse gedupliseer nie. Sluitinligting word ook op elke nodus gestoor, maar die stelsel het 'n globale dooiepuntdetektor.
Wanneer 'n HANA-kliënt aan 'n groep koppel, laai dit sy topologie af en kan dan direk toegang tot enige nodus verkry, afhangende van watter data dit benodig. As 'n transaksie die data van 'n enkele nodus affekteer, dan kan dit plaaslik deur daardie nodus uitgevoer word, maar as die data van verskeie nodusse verander, kontak die inisieerknoop die koördineerdernodus, wat die verspreide transaksie oopmaak en koördineer, en dit pleeg met behulp van 'n geoptimaliseerde twee-fase commit protokol.
Die koördineerdernodus word gedupliseer, so as die koördineerder misluk, neem die rugsteunnodus dadelik oor. Maar as 'n nodus met data misluk, dan is die enigste manier om toegang tot sy data te verkry om die nodus te herbegin. As 'n reël hou HANA-klusters 'n ekstra bediener in stand om 'n verlore nodus so vinnig as moontlik daarop te herbegin.
Bron: will.com