CAP-teoremet er hjĂžrnesteinen i teorien om distribuerte systemer. SelvfĂžlgelig gir debatten rundt den ingen tegn til Ă„ bli stille: definisjonene er ikke kanoniske, og det finnes ikke noe strengt bevis... Likevel, fast forankret i sunn fornuftâą, forstĂ„r vi intuitivt at teoremet er korrekt.
Det eneste som ikke er Ă„penbart, er betydningen av bokstaven «P». NĂ„r en klynge splittes, bestemmer den â om den skal ikke svare fĂžr det er oppnĂ„dd kvorum, eller om den skal gi de dataene den har. Avhengig av resultatene av dette valget klassifiseres systemet enten som CP eller AP. Cassandra, for eksempel, kan oppfĂžre seg bĂ„de slik og slik, avhengig ikke engang av klyngeinnstillingene, men av spesifikasjonene til hver enkelt forespĂžrsel. Men hvis systemet ikke er «P», og det har delt seg, hva skjer da?
Svaret pÄ dette spÞrsmÄlet er noe uventet: en CA-klynge kan ikke splitte.
Hva slags klynge er dette som ikke kan splitte?
Et uunngÄelig kjennetegn ved en slik klynge er et felles datalagringssystem. I det overveldende flertallet av tilfellene betyr dette tilkobling via SAN, noe som begrenser bruken av CA-lÞsninger til store selskaper som kan opprettholde SAN-infrastruktur. For at flere servere kan jobbe med de samme dataene, er en klyngefilessystem nÞdvendig. Slike filessystemer finnes i portefÞljene til HPE (CFS), Veritas (VxCFS) og IBM (GPFS).
Oracle RAC
Alternativet Real Application Cluster dukket fĂžrst opp i 2001 med utgivelsen av Oracle 9i. I en slik klynge jobber flere instanser serveren med samme database.
Oracle kan jobbe bĂ„de med klyngefilessystem og med sin egen lĂžsning â ASM, Automatic Storage Management.
Hver instans fĂžrer sin egen logg. En transaksjon blir utfĂžrt og registrert av Ă©n instans. Ved feil pĂ„ en instans leser en av de overlevende nodene i klyngen (instansene) loggen dens og gjenoppretter de tapte dataene â dette sikrer tilgjengelighet.
Alle instanser stÞtter sin egen cache, og de samme sidene (blokkene) kan befinne seg samtidig i cachen til flere instanser. Dessuten, hvis en instans trenger en side, og den finnes i cachen til en annen instans, kan den hente den fra «naboen» ved hjelp av mekanismen cache fusion, i stedet for Ä lese fra disken.
Men hva skjer hvis en av instansene trenger Ă„ endre dataene?
SÊregenheten til Oracle er at det ikke finnes noen dedikert lÄsetjeneste: hvis serveren Þnsker Ä lÄse en rad, blir informasjon om lÄsen plassert direkte pÄ den siden av minnet hvor den lÄste raden ligger. Takket vÊre denne tilnÊrmingen er Oracle en mester i ytelse blant monolittiske databaser: lÄsetjenesten blir aldri en flaskehals. Men i en klyngekonfigurasjon kan en slik arkitektur fÞre til intensiv nettverksutveksling og gjensidige lÄser.
SÄ snart en rad blir lÄst, varsler instansen alle de andre instansene om at siden som inneholder denne raden, er blitt tatt i monopolmodus. Hvis en annen instans trenger Ä endre raden pÄ den samme siden, mÄ den vente til endringene pÄ siden er blitt bekreftet, det vil si at informasjonen om endringen ikke er blitt skrevet til loggen pÄ disken (transaksjonen kan imidlertid fortsette). Det kan ogsÄ skje at siden ble endret sekvensielt av flere instanser, og nÄr siden skrives til disken, mÄ man finne ut hvem som har den gjeldende versjonen av siden.
Uforutsigbare oppdateringer av de samme sidene gjennom forskjellige RAC-noder fĂžrer til en dramatisk reduksjon i databasens ytelse â til og med sĂ„ mye at ytelsen til klyngen kan vĂŠre lavere enn ytelsen til en enkelt instans.
Riktig bruk av Oracle RAC er fysisk deling av data (for eksempel ved hjelp av mekanismen for partisjonerte tabeller) og tilgang til hvert sett med partisjoner gjennom en dedikert node. HovedformÄlet med RAC har blitt ikke horisontal skalerbarhet, men Ä sikre feilfri drift.
Hvis en node slutter Ä svare pÄ heartbeat, starter den noden som oppdager dette fÞrst, en stemmeprosess pÄ disken. Hvis den tapte noden heller ikke registrerer seg her, tar en av nodene over ansvaret for datagjenopprettelse:
- «fryser» alle sidene som var i hurtigbufferen til den tapte noden;
- leser loggene (redo) fra den tapte noden og anvender endringene som er registrert i disse loggene, samtidig som den sjekker om andre noder har nyere versjoner av de endrede sidene.
- ruller ufullfĂžrte transaksjoner.
For Ă„ forenkle overgangen mellom noder, har Oracle et konsept om tjeneste â en virtuell instans. En instans kan betjene flere tjenester, og en tjeneste kan flytte mellom noder. En applikasjonsinstans som betjener en bestemt del av databasen (for eksempel en gruppe kunder) arbeider med Ă©n tjeneste, og tjenesten som er ansvarlig for denne delen av databasen flytter til en annen node ved nodefeil.
IBM Pure Data Systems for Transactions
Klynge-lÞsningen for DBMS kom inn i portefÞljen til Den blÄ kjempen i 2009. Ideologisk er den en arv etter klyngen Parallel Sysplex, bygget pÄ 'vanlig' utstyr. I 2009 ble produktet DB2 pureScale lansert, som er en programvarepakke, og i 2012 tilbÞd IBM et programvare-hardware sett (appliance) kalt Pure Data Systems for Transactions. Det mÄ ikke forveksles med Pure Data Systems for Analytics, som er intet annet enn det omdÞpte Netezza.
Architekturen til pureScale ligner ved fĂžrste blikk pĂ„ Oracle RAC: pĂ„ samme mĂ„te som flere noder er koblet til et felles datasystem, kjĂžrer hver node sin egen DBMS-instans med sine egne minneomrĂ„der og transaksjonslogger. Men i motsetning til Oracle, har DB2 en dedikert lĂ„netjeneste, representert av en samling prosesser db2LLM*. I klyngekongfigurasjonen er denne tjenesten plassert pĂ„ en egen node, som i Parallel Sysplex kalles coupling facility (CF), og i Pure Data â PowerHA.
PowerHA tilbyr fĂžlgende tjenester:
- lÄneadministrator;
- global buffer-cache;
- omrÄde for mellomprosesskommunikasjon.
For Ä overfÞre data fra PowerHA til DB-noder og tilbake brukes fjernminnetilgang, sÄ klyngeinterconnecten mÄ stÞtte RDMA-protokollen. PureScale kan bruke bÄde Infiniband og RDMA over Ethernet.
Hvis en node trenger en side, og denne siden ikke finnes i cachen, vil noden be om siden i den globale cachen, og bare hvis den heller ikke finnes der, leses den fra disken. I motsetning til Oracle, gÄr forespÞrselen kun til PowerHA og ikke til nabonoder.
NÄr en instans skal endre en rad, blokkerer den den i eksklusiv modus, og siden der raden finnes, i delt modus. Alle lÄser registreres i den globale lÄsestyreren. NÄr transaksjonen er avsluttet, sender noden en melding til lÄsestyreren, som kopierer den endrede siden til den globale cachen, fjerner lÄsene og invalidere den endrede siden i cachene til de andre nodene.
Hvis siden som inneholder den endrede raden allerede er blokkert, vil lÄsestyreren lese den endrede siden fra minnet til noden som foretok endringene, fjerne lÄsen, invalidere den endrede siden i cachene til de andre nodene og gi lÄsen tilbake til noden som ba om den.
«Skitne», altsÄ endrede, sider kan skrives til disk bÄde fra en vanlig node og fra PowerHA (castout).
Ved svikt pÄ en av nodene er gjenopprettingen begrenset til de transaksjonene som pÄ tidspunktet for feilen ikke var avsluttet: sider endret av denne noden i avsluttede transaksjoner finnes i den globale cachen pÄ PowerHA. Noden restartes i en redusert konfigurasjon pÄ en av serverne i klyngen, ruller tilbake pÄbegynte transaksjoner og frigjÞr lÄser.
PowerHA opererer pÄ to servere, og hovednoden synkroniserer tilstanden sin. Ved svikt pÄ hovednoden fortsetter PowerHA-klyngen Ä fungere med reservnoden.
SelvfÞlgelig, hvis man fÄr tilgang til datasettet gjennom én node, vil den totale ytelsen til klyngen vÊre hÞyere. PureScale kan til og med merke at et bestemt datomrÄde blir behandlet av én node, og da vil alle lÄsene knyttet til dette omrÄdet bli hÄndtert lokalt av noden uten kommunikasjon med PowerHA. Men sÄ snart applikasjonen prÞver Ä fÄ tilgang til disse dataene gjennom en annen node, vil den sentraliserte behandling av lÄser bli gjenopptatt.
IBM's interne belastningstester, som bestod av 90% lesing og 10% skriving, noe som ligner pÄ reell industriell belastning, viser nesten lineÊr skalering opp til 128 noder. Testingens betingelser avslÞres dessverre ikke.
HPE NonStop SQL
Den egenhÞye tilgjengelighetsplattformen finnes ogsÄ i Hewlett-Packard Enterprise sin portefÞlje. Dette er NonStop-plattformen, som ble lansert pÄ markedet i 1976 av Tandem Computers. I 1997 ble selskapet oppkjÞpt av Compaq, som igjen ble en del av Hewlett-Packard i 2002.
NonStop brukes til Ă„ bygge kritiske applikasjoner â for eksempel HLR eller behandling av bankkort. Plattformen leveres som en programvare-hardware-enhet (appliance), som inkluderer beregningsnoder, datalagringssystem og kommunikasjonsutstyr. ServerNet-nettverket (i moderne systemer â Infiniband) brukes bĂ„de for kommunikasjon mellom noder og for tilgang til datalagringssystemet.
I de tidlige versjonene av systemet ble det brukt proprietÊre prosessorer som var synkronisert med hverandre: alle operasjoner ble utfÞrt synkront av flere prosessorer, og sÄ snart en av prosessorene feilet, ble den deaktivert, mens den andre fortsatte arbeidet. Senere overgikk systemet til vanlige prosessorer (fÞrst MIPS, deretter Itanium og til slutt x86), og for synkronisering ble det brukt andre mekanismer:
- meldinger: hver systemprosess har en tvilling-"skygge" som den aktive prosessen periodisk sender meldinger om sin tilstand; ved svikt av hovedprosessen begynner skyggeprosessen arbeidet fra siste meldte punkt;
- stemmegivning: datalagringssystemet har en spesifikk maskinvarekomponent som tar imot flere identiske forespĂžrselene og utfĂžrer dem kun dersom forespĂžrslene samsvarer; i stedet for fysisk synkronisering arbeider prosessorene asynkront, og resultatene av arbeidet deres sammenlignes kun ved inndata/utdata.
Siden 1987 har den relasjonsbaserte databasen SQL-Databases (DBMS) fungert pĂ„ NonStop-plattformen â fĂžrst SQL/MP, og senere SQL/MX.
Heile databasen deles inn i deler, og hver del hÄndteres av sin egen Data Access Manager (DAM). Den sikrer dataskriving, caching og en lÄsemekanisme. Databehandling utfÞres av executor prosesser (Executor Server Process) som kjÞrer pÄ de samme nodene som de tilknyttede datamanagerne. SQL/MX-scheduler deler oppgaver mellom utfÞrere og slÄr sammen resultater. For Ä gjÞre koordinerte endringer benyttes en to-fase commitsprotokoll, tilveiebrakt av TMF-biblioteket (Transaction Management Facility).
NonStop SQL kan prioritere prosesser slik at lange analytiske forespÞrselene ikke forstyrrer transaksjonsbehandling. Dens formÄl er imidlertid - nemlig behandling av korte transaksjoner, og ikke analyser. Utvikleren garanterer tilgjengeligheten til NonStop-klusteret pÄ nivÄ fem «niner», noe som betyr at nedetiden er bare 5 minutter i Äret.
SAP HANA
Den fÞrste stabile utgaven av databasen HANA (1.0) ble lansert i november 2010, og SAP ERP-pakken ble overfÞrt til HANA fra mai 2013. Plattformen er basert pÄ kjÞpte teknologier: TREX sÞkemotor (for sÞk i kolonne-lagring), P*TIME database og MAX DB.
Selve ordet «HANA» er et akronym for High performance ANalytical Appliance. Denne databasen leveres i form av kode som kan kjÞre pÄ enhver x86-server, men industrielle installasjoner er kun tillatt pÄ sertifisert utstyr. Det finnes lÞsninger fra HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Noen konfigurasjoner fra Lenovo tillater til og med drift uten SAN - der GPFS-klusteret pÄ lokale disker fungerer som delt lagringssystem.
I motsetning til de nevnte plattformene, er HANA en minne-database, det vil si at den primĂŠre datamodellen lagres i RAM, og bare logger og periodiske snapshots skrives til disk - for gjenoppretting i tilfelle krasj.
Hver node i HANA-klyngen er ansvarlig for sin del av dataene, og datakartet lagres i en spesialkomponent - Name Server, som ligger pÄ koordinator-noden. Dataene mellom nodene dupliseres ikke. Informasjonen om lÄsene lagres ogsÄ pÄ hver node, men det finnes en global deadlock-detektor i systemet.
HANA-klienten laster opp topologien til klyngen ved tilkobling, og kan deretter henvende seg direkte til hvilken som helst node avhengig av hvilke data han trenger. Hvis transaksjonen berĂžrer data fra en enkelt node, kan den utfĂžres lokalt av denne noden, men hvis data fra flere noder endres, kontakter initiator-noden koordinator-noden, som Ă„pner og koordinerer den distribuerte transaksjonen, og forplikter den ved hjelp av en optimalisert to-fase forpliktelsesprotokoll.
Koordinator-noden er duplisert, sÄ hvis koordinatoren svikter, trer en reserve-node umiddelbart inn. Men hvis en node med data svikter, er den eneste mÄten Ä fÄ tilgang til dataene dens, Ä starte noden pÄ nytt. Vanligvis holder HANA-klynger en reserve-server for raskt Ä kunne starte den tapte noden pÄ nytt.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish