De CAP-stelling is de hoekstien fan de teory fan ferdielde systemen. Fansels, de kontroverse der omhinne ferdwynt net: de definysjes dêryn binne net kanonike, en d'r is gjin strikt bewiis ... Dochs, fêst steande op 'e posysjes fan it deistich sûn ferstân™, begripe wy yntuïtyf dat de stelling wier is.
It iennichste ding dat net dúdlik is, is de betsjutting fan 'e letter "P". As it kluster ferdield is, beslút it om net te reagearjen oant in kworum is berikt, of de gegevens werom te jaan dy't beskikber binne. Ofhinklik fan 'e resultaten fan dizze kar, wurdt it systeem klassifisearre as in CP of in AP. Cassandra, bygelyks, kin op beide manieren gedrage, ôfhinklik net iens fan 'e klusterynstellingen, mar op' e parameters fan elke spesifike oanfraach. Mar as it systeem net "P" is en it splitst, wat dan?
It antwurd op dizze fraach is wat ûnferwachts: in CA-kluster kin net splitse.
Hokker soarte fan kluster is dit dat kin net spjalte?
In ûnmisbere attribút fan sa'n kluster is in dielde gegevens opslachsysteem. Yn 'e grutte mearderheid fan' e gefallen betsjut dit ferbining oer in SAN, wat it gebrûk fan CA-oplossingen beheint foar grutte bedriuwen dy't in SAN-ynfrastruktuer kinne behâlde. Om meardere servers mei deselde gegevens te wurkjen, is in klustere bestânsysteem nedich. Sokke bestânssystemen binne beskikber yn 'e portefúljes HPE (CFS), Veritas (VxCFS) en IBM (GPFS).
Oracle RAC
De opsje Real Application Cluster ferskynde earst yn 2001 mei de frijlitting fan Oracle 9i. Yn sa'n kluster wurkje ferskate servereksimplaren mei deselde databank.
Oracle kin wurkje mei sawol in klustere bestânsysteem as in eigen oplossing - ASM, Automatic Storage Management.
Elk eksimplaar hâldt in eigen tydskrift. De transaksje wurdt útfierd en ynset troch ien eksimplaar. As in eksimplaar mislearret, lêst ien fan 'e oerbleaune klusterknooppunten (ynstânsjes) syn log en herstelt de ferlerne gegevens - en garandearret dêrmei beskikberens.
Alle eksimplaren behâlde har eigen cache, en deselde siden (blokken) kinne tagelyk yn 'e caches fan meardere eksimplaren wêze. Boppedat, as ien eksimplaar in side nedich is en it is yn 'e cache fan in oare eksimplaar, kin it it fan syn buorman krije mei it cache-fúzjemeganisme ynstee fan te lêzen fan skiif.
Mar wat bart der as ien fan 'e gefallen gegevens moat feroarje?
De eigenaardichheid fan Oracle is dat it gjin tawijde beskoatteltsjinst hat: as de tsjinner in rigel beskoattelje wol, dan wurdt it slotrekord direkt op 'e ûnthâldside pleatst wêr't de beskoattele rige leit. Mei tank oan dizze oanpak is Oracle de prestaasjekampioen ûnder monolityske databases: de beskoatteltsjinst wurdt nea in knelpunt. Mar yn in klusterkonfiguraasje kin sa'n arsjitektuer liede ta yntinsyf netwurkferkear en deadlocks.
Sadree't in record is beskoattele, in eksimplaar meldt alle oare gefallen dat de side dy't opslaat dat record hat in eksklusyf hold. As in oare eksimplaar moat feroarje in rekord op deselde side, it moat wachtsje oant de feroarings oan de side wurde ynset, dat is, de feroaring ynformaasje wurdt skreaun nei in tydskrift op skiif (en de transaksje kin trochgean). It kin ek barre dat in side opienfolgjend wizige wurdt troch ferskate kopyen, en dan moatte jo by it skriuwen fan de side nei skiif útfine wa't de aktuele ferzje fan dizze side opslaan.
It willekeurich bywurkjen fan deselde siden oer ferskate RAC-knooppunten feroarsaket databankprestaasjes dramatysk sakke, oant it punt dêr't klusterprestaasjes leger kinne wêze as dy fan in inkele eksimplaar.
It juste gebrûk fan Oracle RAC is om de gegevens fysyk te dielen (bygelyks mei in partitioned tabelmeganisme) en tagong ta elke set partysjes fia in tawijd knooppunt. It haaddoel fan RAC wie net horizontale skaalfergrutting, mar soargje foar fouttolerânsje.
As in knooppunt ophâldt te reagearjen op in hertslach, dan begjint de knoop dy't it ûntdutsen earst in stimproseduere op 'e skiif. As it ûntbrekkende knooppunt hjir net wurdt notearre, nimt ien fan 'e knooppunten de ferantwurdlikens op foar gegevensherstel:
- "befriest" alle siden dy't yn 'e cache fan' e ûntbrekkende knooppunt wiene;
- lêst de logs (opnij) fan it ûntbrekkende knooppunt en past de wizigingen opnij oan dy't yn dizze logs opnommen binne, tagelyk kontrolearje oft oare knooppunten mear resinte ferzjes hawwe fan 'e siden dy't wizige wurde;
- rôlet werom yn ôfwachting fan transaksjes.
Om it wikseljen tusken knopen te ferienfâldigjen, hat Oracle it konsept fan in tsjinst - in firtuele eksimplaar. In eksimplaar kin meardere tsjinsten tsjinje, en in tsjinst kin ferpleatse tusken knopen. In applikaasje eksimplaar betsjinnet in bepaald part fan de databank (Bygelyks, in groep kliïnten) wurket mei ien tsjinst, en de tsjinst ferantwurdlik foar dit diel fan de databank ferhuzet nei in oare node as in node mislearret.
IBM Pure Data Systems foar Transaksjes
In klusteroplossing foar DBMS ferskynde yn 'e Blue Giant-portefúlje yn 2009. Ideologysk is it de opfolger fan it Parallel Sysplex-kluster, boud op "gewoane" apparatuer. Yn 2009 waard DB2 pureScale útbrocht as softwaresuite, en yn 2012 bea IBM in apparaat oan mei de namme Pure Data Systems for Transactions. It moat net betize wurde mei Pure Data Systems for Analytics, dat is neat mear as in omneamd Netezza.
Op it earste each is de pureScale-arsjitektuer fergelykber mei Oracle RAC: op deselde wize binne ferskate knooppunten ferbûn mei in mienskiplik gegevensopslachsysteem, en elke knooppunt rint in eigen DBMS-eksimplaar mei syn eigen ûnthâldgebieten en transaksjelogs. Mar, yn tsjinstelling ta Oracle, hat DB2 in tawijd beskoatteljen tsjinst fertsjintwurdige troch in set fan db2LLM * prosessen. Yn in kluster konfiguraasje wurdt dizze tsjinst pleatst op in apart knooppunt, dat hjit coupling facility (CF) yn Parallel Sysplex, en PowerHA yn Pure Data.
PowerHA leveret de folgjende tsjinsten:
- slot manager;
- globale buffer cache;
- gebiet fan ynterproseskommunikaasje.
Om gegevens oer te dragen fan PowerHA nei de databankknooppunten en werom, wurdt tagong op ôfstân brûkt, sadat de klusterferbining it RDMA-protokol moat stypje. PureScale kin sawol Infiniband as RDMA oer Ethernet brûke.
As in knooppunt in side nedich is, en dizze side is net yn 'e cache, dan freget it knooppunt de side yn' e globale cache, en allinich as it der net is, lêst it fan skiif. Oars as Oracle giet it fersyk allinich nei PowerHA, en net nei oanbuorjende knopen.
As in eksimplaar in rige sil feroarje, slút it yn eksklusive modus, en de side wêr't de rige yn dielde modus leit. Alle slûzen wurde registrearre yn de globale slot manager. As de transaksje is foltôge, stjoert de knooppunt in berjocht nei de slûsbehearder, dy't de wizige side kopiearret nei de globale cache, de slûzen frijlit, en de wizige side yn 'e caches fan oare knooppunten ûnjildich makket.
As de side wêryn't de wizige rige leit al beskoattele is, dan sil de slûsbehearder de wizige side lêze út it ûnthâld fan 'e knooppunt dy't de wiziging makke, it slot loslitte, de wizige side ûnjildich meitsje yn 'e caches fan oare knooppunten, en jou de sideslot oan it knooppunt dat it frege hat.
"Dirty", dat is feroare, siden kinne wurde skreaun nei skiif sawol fan in gewoane knooppunt as fan PowerHA (castout).
As ien fan 'e pureScale-knooppunten mislearret, wurdt herstel beheind ta allinich dy transaksjes dy't noch net foltôge wiene op it stuit fan mislearring: de siden dy't troch dat knooppunt yn foltôge transaksjes wizige binne, binne yn 'e globale cache op PowerHA. It knooppunt start op 'e nij yn in fermindere konfiguraasje op ien fan' e tsjinners yn it kluster, rôlet werom yn ôfwachting fan transaksjes en lit slûzen los.
PowerHA rint op twa tsjinners en de master knooppunt replicates syn steat syngroan. As de primêre PowerHA-knooppunt mislearret, bliuwt it kluster wurkje mei it reservekopyknooppunt.
Fansels, as jo tagong krije ta de gegevensset fia ien inkelde knooppunt, sil de totale prestaasjes fan it kluster heger wêze. PureScale kin sels fernimme dat in bepaald gebiet fan gegevens wurdt ferwurke troch ien knooppunt, en dan sille alle slûzen relatearre oan dat gebiet lokaal wurde ferwurke troch de knooppunt sûnder kommunikaasje mei PowerHA. Mar sa gau as de applikaasje besiket tagong te krijen ta dizze gegevens fia in oare knooppunt, sil sintralisearre slûsferwurking opnij begjinne.
IBM's ynterne tests op in wurkdruk fan 90% lêzen en 10% skriuwe, wat heul gelyk is oan wurkdruk yn 'e echte wrâld, litte hast lineêre skaalfergrutting sjen oant 128 knopen. Testbetingsten wurde spitigernôch net iepenbiere.
HPE NonStop SQL
De portefúlje fan Hewlett-Packard Enterprise hat ek in eigen heech beskikber platfoarm. Dit is it NonStop-platfoarm, útbrocht op 'e merke yn 1976 troch Tandem Computers. Yn 1997 waard it bedriuw oernaam troch Compaq, dat op syn beurt yn 2002 fusearre mei Hewlett-Packard.
NonStop wurdt brûkt om krityske applikaasjes te bouwen - bygelyks HLR of bankkaartferwurking. It platfoarm wurdt levere yn 'e foarm fan in software- en hardwarekompleks (apparaat), dat komputerknooppunten, in dataopslachsysteem en kommunikaasjeapparatuer omfettet. ServerNet netwurk (yn moderne systemen - Infiniband) tsjinnet sawol foar útwikseling tusken knooppunten en foar tagong ta de gegevens opslach systeem.
Iere ferzjes fan it systeem brûkt proprietêre processors dy't waarden syngronisearre mei elkoar: alle operaasjes waarden útfierd syngroan troch ferskate processors, en sa gau as ien fan de processors makke in flater, it waard útskeakele, en de twadde bleau te wurkjen. Letter skeakele it systeem oer nei konvinsjonele processors (earst MIPS, dan Itanium en úteinlik x86), en oare meganismen begûnen te brûken foar syngronisaasje:
- berjochten: elk systeem proses hat in "skaad" twilling, dêr't it aktive proses periodyk stjoert berjochten oer syn status; as it haadproses mislearret, begjint it skaadproses te wurkjen fanôf it momint bepaald troch it lêste berjocht;
- stimmen: it opslachsysteem hat in spesjale hardware-komponint dy't meardere identike tagongen akseptearret en allinich útfiert as de tagongen oerienkomme; Yn stee fan fysike syngronisaasje wurkje processors asynchronous, en de resultaten fan harren wurk wurde fergelike allinnich op I / O mominten.
Sûnt 1987 is in relaasje DBMS op it NonStop-platfoarm draaid - earst SQL/MP, en letter SQL/MX.
De hiele databank is ferdield yn dielen, en elk diel is ferantwurdlik foar syn eigen Data Access Manager (DAM) proses. It biedt meganismen foar opname, caching en beskoatteljen fan gegevens. Gegevensferwurking wurdt útfierd troch Executor Server Processes dy't rinne op deselde knopen as de oerienkommende gegevensbehearders. De SQL/MX-planner dielt taken ûnder útfierers en aggregearret de resultaten. As it nedich is om ôfpraat wizigingen oan te bringen, wurdt it twa-faze commitprotokol brûkt troch de TMF (Transaction Management Facility) bibleteek.
NonStop SQL kin prosessen prioritearje sadat lange analytyske queries net ynterferearje mei transaksje-útfiering. It doel is lykwols krekt de ferwurking fan koarte transaksjes, en net analytyk. De ûntwikkelder garandearret de beskikberens fan it NonStop-kluster op it nivo fan fiif "njoggen", dat is, downtime is mar 5 minuten per jier.
SAP-HANA
De earste stabile release fan 'e HANA DBMS (1.0) fûn plak yn novimber 2010, en it SAP ERP-pakket skeakele yn maaie 2013 oer nei HANA. It platfoarm is basearre op kocht technologyen: TREX Search Engine (sykje yn kolom opslach), P * TIME DBMS en MAX DB.
It wurd "HANA" sels is in akronym, High performance ANAlytical Appliance. Dizze DBMS wurdt levere yn 'e foarm fan koade dy't kin rinne op alle x86-tsjinners, lykwols binne yndustriële ynstallaasjes allinich tastien op sertifisearre apparatuer. Oplossings beskikber fan HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Guon Lenovo-konfiguraasjes tastean sels operaasje sûnder SAN - de rol fan in mienskiplik opslachsysteem wurdt spile troch in GPFS-kluster op lokale skiven.
Oars as de hjirboppe neamde platfoarms, is HANA in DBMS yn it ûnthâld, d.w.s. de primêre gegevensôfbylding wurdt opslein yn RAM, en allinich logs en periodike snapshots wurde op skiif skreaun foar herstel yn gefal fan in ramp.
Elke HANA-klusterknooppunt is ferantwurdlik foar har eigen diel fan 'e gegevens, en de gegevenskaart wurdt opslein yn in spesjale komponint - Name Server, lizzend op it koördinatorknooppunt. Gegevens wurde net duplikearre tusken knopen. Beskoatteljen ynformaasje wurdt ek opslein op elke knooppunt, mar it systeem hat in globale deadlock detector.
As in HANA-kliïnt ferbynt mei in kluster, downloadt it syn topology en kin dan direkt tagong krije ta elke knooppunt, ôfhinklik fan hokker gegevens it nedich is. As in transaksje de gegevens fan in inkele knooppunt beynfloedet, dan kin it lokaal útfierd wurde troch dat knooppunt, mar as de gegevens fan ferskate knooppunten wizigje, kontaktet de inisjearjende knooppunt de koördinatorknooppunt, dy't de ferdielde transaksje iepenet en koördineart, en it begean mei in optimalisearre twa-fase commit protokol.
It koördinatorknooppunt wurdt duplikearre, dus as de koördinator mislearret, nimt de reservekopyknoop daliks oer. Mar as in knooppunt mei gegevens mislearret, dan is de iennichste manier om tagong te krijen ta syn gegevens is it knooppunt opnij te begjinnen. HANA-klusters ûnderhâlde yn 'e regel in reservetsjinner om in ferlern knooppunt dêrop sa gau mooglik opnij te begjinnen.
Boarne: www.habr.com