De CAP-Theorem ass den Ecksteen vun der verdeelt Systemtheorie. Natierlech hëlt d'Kontrovers ronderëm net of: d'Definitioune dra sinn net kanonesch, an et gëtt kee strikte Beweis ... Trotzdem, fest op d'Positioune vum alldeegleche gesonde Mënscheverstand™, verstinn mir intuitiv datt den Theorem wouer ass.
Dat eenzegt wat net evident ass ass d'Bedeitung vum Bréif "P". Wann de Stärekoup opgedeelt ass, entscheet et ob net ze reagéieren bis e Quorum erreecht ass, oder d'Donnéeën zréckzeginn déi verfügbar sinn. Ofhängeg vun de Resultater vun dëser Wiel gëtt de System entweder als CP oder als AP klasséiert. Cassandra, zum Beispill, kann entweder Manéier behuelen, ofhängeg net emol op de Stärekoup Astellunge, mä op d'Parameteren vun all spezifesch Ufro. Awer wann de System net "P" ass an et trennt, wat dann?
D'Äntwert op dës Fro ass e bëssen onerwaart: e CA Cluster kann net opgedeelt ginn.
Wéi eng Cluster ass dëst deen net opdeelt?
Eng onverzichtbar Attribut vun esou engem Cluster ass e gemeinsame Datelagerungssystem. An der grousser Majoritéit vu Fäll bedeit dëst d'Verbindung iwwer e SAN, wat d'Benotzung vu CA-Léisungen op grouss Entreprisen limitéiert, déi fäeg sinn eng SAN-Infrastruktur z'erhalen. Fir datt verschidde Servere mat deene selwechte Daten funktionnéieren, ass e clusteréierte Dateiesystem erfuerderlech. Esou Dateiesystemer sinn an den HPE (CFS), Veritas (VxCFS) an IBM (GPFS) Portfolioen verfügbar.
Oracle RAC
D'Real Application Cluster Optioun ass fir d'éischt am Joer 2001 mat der Verëffentlechung vum Oracle 9i opgetaucht. An esou engem Cluster funktionnéiere verschidde Serverinstanzen mat der selwechter Datebank.
Oracle ka souwuel mat engem clusteréierte Dateiesystem wéi och mat senger eegener Léisung schaffen - ASM, Automatic Storage Management.
All Kopie hält säin eegene Journal. D'Transaktioun gëtt duerch eng Instanz ausgefouert an engagéiert. Wann eng Instanz feelt, liest ee vun den iwwerliewende Clusternoden (Instanzen) säi Log a restauréiert déi verluer Donnéeën - doduerch d'Disponibilitéit garantéiert.
All Instanzen erhalen hiren eegene Cache, an déiselwecht Säiten (Blöcke) kënnen an de Cache vu méi Instanzen zur selwechter Zäit sinn. Ausserdeem, wann eng Instanz eng Säit brauch an et ass am Cache vun enger anerer Instanz, kann se se vu sengem Noper kréien mat dem Cache Fusiounsmechanismus anstatt vun der Disk ze liesen.
Awer wat geschitt wann ee vun den Instanzen Daten muss änneren?
D'Besonderheet vum Oracle ass datt et keen dedizéierten Sperrservice huet: wann de Server eng Zeil späre wëllt, da gëtt de Spärrekord direkt op d'Erënnerungssäit plazéiert wou déi gespaarten Zeil läit. Dank dëser Approche ass Oracle de Performance-Champion tëscht monolitheschen Datenbanken: de Sperrservice gëtt ni e Flaschenhals. Awer an enger Clusterkonfiguratioun kann sou eng Architektur zu intensiven Netzwierkverkéier an Deadlocks féieren.
Wann e Rekord gespaart ass, informéiert eng Instanz all aner Instanzen datt d'Säit déi dee Rekord späichert en exklusive Empfang huet. Wann eng aner Instanz e Rekord op der selwechter Säit muss änneren, muss et waarden bis d'Ännerunge vun der Säit engagéiert sinn, dat heescht, d'Ännerungsinformatioun gëtt an e Journal op Disk geschriwwe (an d'Transaktioun ka weidergoen). Et kann och geschéien datt eng Säit sequenziell duerch e puer Exemplare geännert gëtt, an dann wann Dir d'Säit op Disk schreift, musst Dir erausfannen wien déi aktuell Versioun vun dëser Säit späichert.
Zoufälleg Aktualiséierung vun der selwechter Säiten iwwer verschidden RAC Wirbelen verursaacht d'Datebankleistung dramatesch ze falen, op de Punkt wou d'Clusterleistung méi niddereg ka sinn wéi déi vun enger eenzeger Instanz.
Déi korrekt Notzung vum Oracle RAC ass d'Donnéeën kierperlech ze partitionéieren (zum Beispill mat engem partitionéierten Dëschmechanismus) an Zougang zu all Set vu Partitionen duerch en dedizéierten Node. Den Haaptzweck vum RAC war net horizontal Skaléieren, mee d'Feeltoleranz ze garantéieren.
Wann e Node ophält op en Häerzschlag ze reagéieren, da fänkt de Node deen et fir d'éischt eng Ofstëmmungsprozedur op der Disk un. Wann de fehlend Node net hei bemierkt ass, dann iwwerhëlt ee vun den Noden d'Verantwortung fir d'Datenerhuelung:
- "afréiert" all Säiten déi am Cache vum fehlenden Node waren;
- liest d'Logbicher (Redo) vum fehlenden Node an applizéiert d'Ännerungen, déi an dëse Logbicher opgeholl goufen, gläichzäiteg iwwerpréift ob aner Noden méi rezent Versioune vun de Säiten hunn, déi geännert ginn;
- rullt zréck op Transaktiounen.
Fir de Wiessel tëscht Noden ze vereinfachen, huet Oracle d'Konzept vun engem Service - eng virtuell Instanz. Eng Instanz kann verschidde Servicer déngen, an e Service kann tëscht Noden réckelen. Eng Applikatioun Instanz, déi e bestëmmten Deel vun der Datebank servéiert (zum Beispill, e Grupp vu Clienten) funktionnéiert mat engem Service, an de Service verantwortlech fir dësen Deel vun der Datebank bewegt sech op en aneren Node wann e Node feelt.
IBM Pure Data Systemer fir Transaktiounen
Eng Clusterléisung fir DBMS erschéngt am Blue Giant Portfolio am Joer 2009. Ideologesch ass et den Nofolger vum Parallel Sysplex Stärekoup, gebaut op "regelméisseg" Ausrüstung. Am 2009 gouf DB2 pureScale als Software Suite verëffentlecht, an 2012 huet IBM en Apparat genannt Pure Data Systems for Transactions ugebueden. Et sollt net mat Pure Data Systems for Analytics verwiesselt ginn, wat näischt méi ass wéi en ëmbenannt Netezza.
Op den éischte Bléck ass d'pureScale-Architektur ähnlech wéi d'Oracle RAC: op déiselwecht Manéier si verschidde Wirbelen mat engem gemeinsamen Datelagerungssystem verbonnen, an all Node leeft seng eege DBMS-Instanz mat hiren eegene Gedächtnisberäicher an Transaktiounsprotokoller. Awer, am Géigesaz zu Oracle, huet DB2 en dedizéierten Sperrservice representéiert duerch eng Rei vun db2LLM * Prozesser. An enger Clusterkonfiguratioun gëtt dëse Service op engem getrennten Node gesat, deen Kupplungsanlag (CF) am Parallel Sysplex genannt gëtt, an PowerHA an Pure Data.
PowerHA bitt déi folgend Servicer:
- Spär Manager;
- globale Puffer Cache;
- Gebitt vun der Interprozesskommunikatioun.
Fir Daten aus PowerHA op d'Datebanknoden an zréck ze transferéieren, gëtt Remote Memory Access benotzt, sou datt de Cluster Interconnect den RDMA Protokoll ënnerstëtzen. PureScale ka souwuel Infiniband wéi och RDMA iwwer Ethernet benotzen.
Wann e Node eng Säit brauch, an dës Säit ass net am Cache, da freet de Node d'Säit am globalen Cache, an nëmmen wann et net do ass, liest se vun der Disk. Am Géigesaz zu Oracle geet d'Ufro nëmmen un PowerHA, an net op Nopeschnoden.
Wann eng Instanz eng Zeil ännere wäert, gespaart se am exklusive Modus, an d'Säit wou d'Zeil am gemeinsame Modus läit. All Schleisen sinn am globale Spär Manager registréiert. Wann d'Transaktioun ofgeschloss ass, schéckt de Node e Message un de Sperrmanager, deen déi geännert Säit an de globale Cache kopéiert, d'Spären verëffentlecht an déi geännert Säit an de Cache vun aneren Noden ongëlteg mécht.
Wann d'Säit an där déi geännert Zeil läit scho gespaart ass, da liest de Spärmanager déi geännert Säit aus der Erënnerung vum Node, deen d'Ännerung gemaach huet, de Sperre befreit, déi geännert Säit an de Cache vun anere Wirbelen ongëlteg maachen, an gitt d'Säitschloss un den Node deen et gefrot huet.
"Dirty", dat heescht geännert, Säiten kënnen op Scheif geschriwwe ginn souwuel vun engem normale Node wéi och vu PowerHA (castout).
Wann ee vun de pureScale Noden feelt, ass d'Erhuelung limitéiert op nëmmen déi Transaktiounen, déi nach net am Moment vum Echec ofgeschloss goufen: d'Säiten, déi vun deem Node an ofgeschlossene Transaktioune geännert goufen, sinn am globalen Cache op PowerHA. De Node restarts an enger reduzéierter Konfiguratioun op engem vun de Serveren am Stärekoup, rullt pendend Transaktiounen zréck a verëffentlecht Spären.
PowerHA leeft op zwee Serveren an de Master Node replizéiert säin Zoustand synchron. Wann de primäre PowerHA Node feelt, fiert de Cluster weider mam Backup Node.
Natierlech, wann Dir Zougang zu den Dateset duerch en eenzegen Node kritt, wäert d'Gesamtleeschtung vum Cluster méi héich sinn. PureScale ka souguer bemierken datt e bestëmmte Gebitt vun Daten vun engem Node veraarbecht gëtt, an da ginn all Spären am Zesummenhang mat deem Gebitt lokal vum Node veraarbecht ouni mat PowerHA ze kommunizéieren. Awer soubal d'Applikatioun probéiert dës Donnéeën duerch en aneren Node ze kréien, gëtt d'zentraliséiert Spärveraarbechtung erëm op.
IBM's intern Tester op enger Aarbechtslaascht vun 90% Liesen an 10% Schreiwen, wat ganz ähnlech wéi real-Welt Produktiounsaarbechtslaascht ass, weisen bal linear Skala bis zu 128 Noden. Testbedéngungen, leider, ginn net bekanntginn.
HPE NonStop SQL
Den Hewlett-Packard Enterprise Portfolio huet och seng eege héich verfügbar Plattform. Dëst ass d'NonStop Plattform, déi am Joer 1976 vun Tandem Computers op de Maart verëffentlecht gouf. Am Joer 1997 gouf d'Firma vum Compaq kaaft, deen am Joer 2002 mat Hewlett-Packard fusionéiert huet.
NonStop gëtt benotzt fir kritesch Uwendungen ze bauen - zum Beispill HLR oder Bankkaartveraarbechtung. D'Plattform gëtt a Form vun engem Software- an Hardwarekomplex (Apparat) geliwwert, deen Informatiknoden, en Datelagerungssystem a Kommunikatiounsausrüstung enthält. De ServerNet Netzwierk (a modernen Systemer - Infiniband) déngt souwuel fir den Austausch tëscht Wirbelen a fir Zougang zum Datelagerungssystem.
Fréier Versioune vum System hunn propriétaire Prozessoren benotzt, déi matenee synchroniséiert goufen: all Operatioune goufen synchron vu verschiddene Prozessoren duerchgefouert, a soubal ee vun de Prozessoren e Feeler gemaach huet, gouf et ausgeschalt, an déi zweet huet weider geschafft. Méi spéit ass de System op konventionell Prozessoren gewiesselt (éischt MIPS, duerno Itanium a schliisslech x86), an aner Mechanismen hunn ugefaang fir d'Synchroniséierung ze benotzen:
- Messagen: all Systemprozess huet e "Schatten" Zwilling, un deen den aktive Prozess periodesch Messagen iwwer säi Status schéckt; wann den Haaptprozess klappt, fänkt de Schattenprozess un ze schaffen aus dem Moment, deen duerch de leschte Message bestëmmt gëtt;
- Ofstëmmung: de Späichersystem huet e speziellen Hardwarekomponent, deen e puer identesch Zougang akzeptéiert an se nëmmen ausféiert wann d'Zougäng passen; Amplaz vu kierperlecher Synchroniséierung funktionnéieren d'Prozessoren asynchron, an d'Resultater vun hirer Aarbecht ginn nëmme bei I / O Momenter verglach.
Zënter 1987 leeft eng relational DBMS op der NonStop Plattform - éischt SQL/MP, a spéider SQL/MX.
Déi ganz Datebank ass an Deeler opgedeelt, an all Deel ass verantwortlech fir säin eegenen Data Access Manager (DAM) Prozess. Et bitt Datenopnam, Caching a Sperrmechanismus. D'Dateveraarbechtung gëtt duerch Executor Server Prozesser duerchgefouert, déi op déiselwecht Noden lafen wéi déi entspriechend Datemanager. De SQL / MX Scheduler deelt Aufgaben tëscht Exekutoren an aggregéiert d'Resultater. Wann et néideg ass ausgemaach Ännerungen ze maachen, gëtt den Zwee-Phase Verpflichtungsprotokoll zur Verfügung gestallt vun der TMF (Transaction Management Facility) Bibliothéik benotzt.
NonStop SQL kann Prozesser prioritär maachen sou datt laang analytesch Ufroen net mat der Transaktiounsausféierung stéieren. Wéi och ëmmer, säin Zweck ass präzis d'Veraarbechtung vu kuerzen Transaktiounen, an net d'Analyse. Den Entwéckler garantéiert d'Disponibilitéit vum NonStop-Cluster um Niveau vu fënnef "néng", dat heescht, d'Downtime ass nëmme 5 Minutten pro Joer.
SAP-HANA
Déi éischt stabil Verëffentlechung vum HANA DBMS (1.0) ass am November 2010 stattfonnt, an de SAP ERP Package ass am Mee 2013 op HANA gewiesselt. D'Plattform baséiert op kaaft Technologien: TREX Sichmotor (Sich a Kolumnlager), P*TIME DBMS a MAX DB.
D'Wuert "HANA" selwer ass en Akronym, High Performance Analytical Appliance. Dës DBMS gëtt a Form vu Code geliwwert, deen op all x86 Server kann lafen, awer industriell Installatiounen sinn nëmmen op zertifizéierter Ausrüstung erlaabt. Léisunge verfügbar vun HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. E puer Lenovo Konfiguratiounen erlaben souguer Operatioun ouni SAN - d'Roll vun engem gemeinsame Späichersystem gëtt vun engem GPFS-Cluster op lokalen Disken gespillt.
Am Géigesaz zu den uewe genannte Plattformen ass HANA en In-Memory DBMS, dh dat primär Datebild gëtt am RAM gespäichert, an nëmme Logbicher a periodesch Schnappschëss ginn op Disk geschriwwe fir Erhuelung am Fall vun enger Katastroph.
All HANA Cluster Node ass verantwortlech fir säin eegenen Deel vun den Donnéeën, an d'Datekaart gëtt an engem speziellen Komponent gespäichert - Numm Server, um Koordinator Node. Daten ginn net tëscht Noden duplizéiert. Spärinformatioun gëtt och op all Node gespäichert, awer de System huet e globalen Deadlock Detektor.
Wann en HANA Client un e Stärekoup verbënnt, luet se seng Topologie erof a kann dann op all Node direkt zougräifen, jee no wéi enge Daten et brauch. Wann eng Transaktioun d'Donnéeën vun engem eenzegen Node beaflosst, da kann se lokal vun deem Node ausgefouert ginn, awer wann d'Date vu verschiddenen Noden ännert, kontaktéiert den initiéierende Node de Koordinator Node, deen déi verdeelt Transaktioun opmaacht a koordinéiert, engagéiert se mat engem optimiséiert Zwee-Phase Verpflichtungsprotokoll.
De Koordinator Node gëtt duplizéiert, also wann de Koordinator fällt, iwwerhëlt de Backup Node direkt. Awer wann en Node mat Daten feelt, dann ass deen eenzege Wee fir op seng Donnéeën ze kommen, den Node nei ze starten. In der Regel behalen HANA Cluster e Ersatzserver fir e verluerene Node sou séier wéi méiglech opzemaachen.
Source: will.com