CAP-teoremet er hjørnesteinen i teorien om distribuerte systemer. Selvsagt avtar ikke kontroversen rundt den: definisjonene i den er ikke kanoniske, og det er ingen strenge bevis... Likevel, fast på standpunktene til hverdagslig sunn fornuft™, forstår vi intuitivt at teoremet er sant.
Det eneste som ikke er åpenbart er betydningen av bokstaven "P". Når klyngen er delt, bestemmer den om den ikke skal svare før et quorum er nådd, eller å gi tilbake dataene som er tilgjengelige. Avhengig av resultatene av dette valget, er systemet klassifisert som enten en CP eller en AP. Cassandra, for eksempel, kan oppføre seg begge veier, ikke engang avhengig av klyngeinnstillingene, men av parameterne for hver spesifikke forespørsel. Men hvis systemet ikke er "P" og det deler seg, hva da?
Svaret på dette spørsmålet er noe uventet: en CA-klynge kan ikke dele seg.
Hva slags klynge er dette som ikke kan splittes?
En uunnværlig egenskap ved en slik klynge er et delt datalagringssystem. I de aller fleste tilfeller betyr dette tilkobling over et SAN, noe som begrenser bruken av CA-løsninger til store bedrifter som er i stand til å vedlikeholde en SAN-infrastruktur. For at flere servere skal fungere med samme data, kreves det et klynget filsystem. Slike filsystemer er tilgjengelige i porteføljene 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 fungerer flere serverforekomster med samme database.
Oracle kan jobbe med både et klynget filsystem og sin egen løsning – ASM, Automatic Storage Management.
Hvert eksemplar fører sin egen journal. Transaksjonen utføres og forpliktes av én instans. Hvis en forekomst mislykkes, leser en av de overlevende klyngenodene (forekomstene) loggen sin og gjenoppretter de tapte dataene - og sikrer dermed tilgjengelighet.
Alle forekomster opprettholder sin egen cache, og de samme sidene (blokkene) kan være i cachen til flere forekomster samtidig. Dessuten, hvis en forekomst trenger en side og den er i hurtigbufferen til en annen forekomst, kan den få den fra naboen ved å bruke bufferfusjonsmekanismen i stedet for å lese fra disk.
Men hva skjer hvis en av forekomstene må endre data?
Det særegne ved Oracle er at det ikke har en dedikert låsetjeneste: hvis serveren ønsker å låse en rad, plasseres låseposten direkte på minnesiden der den låste raden er plassert. Takket være denne tilnærmingen er Oracle prestasjonsmesteren blant monolittiske databaser: Låsetjenesten blir aldri en flaskehals. Men i en klyngekonfigurasjon kan en slik arkitektur føre til intens nettverkstrafikk og vranglåser.
Når en post er låst, varsler en forekomst alle andre forekomster om at siden som lagrer posten har et eksklusivt hold. Hvis en annen instans må endre en post på samme side, må den vente til endringene på siden er committed, det vil si at endringsinformasjonen skrives til en journal på disk (og transaksjonen kan fortsette). Det kan også skje at en side vil bli endret sekvensielt med flere kopier, og når du skriver siden til disk må du finne ut hvem som lagrer den gjeldende versjonen av denne siden.
Tilfeldig oppdatering av de samme sidene på tvers av forskjellige RAC-noder fører til at databaseytelsen faller dramatisk, til et punkt der klyngeytelsen kan være lavere enn for en enkelt forekomst.
Riktig bruk av Oracle RAC er å fysisk partisjonere dataene (for eksempel ved å bruke en partisjonert tabellmekanisme) og få tilgang til hvert sett med partisjoner gjennom en dedikert node. Hovedformålet med RAC var ikke horisontal skalering, men å sikre feiltoleranse.
Hvis en node slutter å svare på et hjerteslag, starter noden som oppdaget den først en stemmeprosedyre på disken. Hvis den manglende noden ikke er notert her, tar en av nodene på seg ansvaret for datagjenoppretting:
- "fryser" alle sider som var i hurtigbufferen til den manglende noden;
- leser loggene (redo) for den manglende noden og bruker endringene som er registrert i disse loggene på nytt, og sjekker samtidig om andre noder har nyere versjoner av sidene som endres;
- ruller tilbake ventende transaksjoner.
For å forenkle bytte mellom noder har Oracle konseptet med en tjeneste – en virtuell instans. En forekomst kan betjene flere tjenester, og en tjeneste kan flytte mellom noder. En applikasjonsforekomst som betjener en bestemt del av databasen (for eksempel en gruppe klienter) fungerer med én tjeneste, og tjenesten som er ansvarlig for denne delen av databasen, flytter til en annen node når en node svikter.
IBM Pure Data Systems for Transactions
En klyngeløsning for DBMS dukket opp i Blue Giant-porteføljen i 2009. Ideologisk sett er det etterfølgeren til Parallel Sysplex-klyngen, bygget på "vanlig" utstyr. I 2009 ble DB2 pureScale utgitt som en programvarepakke, og i 2012 tilbød IBM en enhet kalt Pure Data Systems for Transactions. Det må ikke forveksles med Pure Data Systems for Analytics, som ikke er noe mer enn en omdøpt Netezza.
Ved første øyekast ligner pureScale-arkitekturen Oracle RAC: på samme måte er flere noder koblet til et felles datalagringssystem, og hver node kjører sin egen DBMS-instans med egne minneområder og transaksjonslogger. Men i motsetning til Oracle har DB2 en dedikert låsetjeneste representert av et sett med db2LLM*-prosesser. I en klyngekonfigurasjon er denne tjenesten plassert på en egen node, som kalles coupling facility (CF) i Parallel Sysplex, og PowerHA i Pure Data.
PowerHA tilbyr følgende tjenester:
- lås manager;
- global buffer cache;
- område for kommunikasjon mellom prosesser.
For å overføre data fra PowerHA til databasenodene og tilbake, brukes ekstern minnetilgang, så klyngesammenkoblingen 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 er i cachen, ber noden om siden i den globale cachen, og bare hvis den ikke er der, leser den fra disken. I motsetning til Oracle, går forespørselen kun til PowerHA, og ikke til nabonoder.
Hvis en forekomst skal endre en rad, låser den den i eksklusiv modus, og siden der raden er plassert i delt modus. Alle låser er registrert i den globale låsbehandleren. Når transaksjonen er fullført, sender noden en melding til låseadministratoren, som kopierer den modifiserte siden til den globale cachen, frigjør låsene og ugyldiggjør den modifiserte siden i cachene til andre noder.
Hvis siden der den endrede raden er plassert allerede er låst, vil låseadministratoren lese den endrede siden fra minnet til noden som gjorde endringen, frigjøre låsen, ugyldiggjøre den endrede siden i cachen til andre noder, og gi sidelåsen til noden som ba om det.
"Dirty", det vil si endrede, sider kan skrives til disk både fra en vanlig node og fra PowerHA (castout).
Hvis en av pureScale-nodene mislykkes, er gjenoppretting begrenset til bare de transaksjonene som ennå ikke var fullført på feiltidspunktet: sidene som er modifisert av den noden i fullførte transaksjoner, er i den globale hurtigbufferen på PowerHA. Noden starter på nytt i redusert konfigurasjon på en av serverne i klyngen, ruller tilbake ventende transaksjoner og frigjør låser.
PowerHA kjører på to servere og masternoden replikerer tilstanden sin synkront. Hvis den primære PowerHA-noden svikter, fortsetter klyngen å operere med backupnoden.
Selvfølgelig, hvis du får tilgang til datasettet gjennom en enkelt node, vil den generelle ytelsen til klyngen være høyere. PureScale kan til og med legge merke til at et bestemt område med data blir behandlet av én node, og da vil alle låser relatert til det området bli behandlet lokalt av noden uten å kommunisere med PowerHA. Men så snart applikasjonen prøver å få tilgang til disse dataene gjennom en annen node, vil sentralisert låsebehandling gjenopptas.
IBMs interne tester på en arbeidsbelastning på 90 % lesing og 10 % skriving, som er veldig lik produksjonsbelastninger i den virkelige verden, viser nesten lineær skalering opp til 128 noder. Testforholdene er dessverre ikke avslørt.
HPE NonStop SQL
Hewlett-Packard Enterprise-porteføljen har også sin egen svært tilgjengelige plattform. Dette er NonStop-plattformen, utgitt på markedet i 1976 av Tandem Computers. I 1997 ble selskapet kjøpt opp av Compaq, som igjen fusjonerte med Hewlett-Packard i 2002.
NonStop brukes til å bygge kritiske applikasjoner – for eksempel HLR eller bankkortbehandling. Plattformen leveres i form av et programvare- og maskinvarekompleks (appliance), som inkluderer datanoder, et datalagringssystem og kommunikasjonsutstyr. ServerNet-nettverket (i moderne systemer - Infiniband) tjener både for utveksling mellom noder og for tilgang til datalagringssystemet.
Tidlige versjoner av systemet brukte proprietære prosessorer som var synkronisert med hverandre: alle operasjoner ble utført synkront av flere prosessorer, og så snart en av prosessorene gjorde en feil, ble den slått av, og den andre fortsatte å fungere. Senere byttet systemet til konvensjonelle prosessorer (først MIPS, deretter Itanium og til slutt x86), og andre mekanismer begynte å bli brukt for synkronisering:
- meldinger: hver systemprosess har en "skygge" tvilling, som den aktive prosessen med jevne mellomrom sender meldinger om statusen til; hvis hovedprosessen mislykkes, begynner skyggeprosessen å fungere fra øyeblikket bestemt av den siste meldingen;
- stemmegivning: lagringssystemet har en spesiell maskinvarekomponent som aksepterer flere identiske tilganger og utfører dem bare hvis tilgangene samsvarer; I stedet for fysisk synkronisering opererer prosessorer asynkront, og resultatene av arbeidet deres sammenlignes bare ved I/O-øyeblikk.
Siden 1987 har en relasjonell DBMS kjørt på NonStop-plattformen - først SQL/MP, og senere SQL/MX.
Hele databasen er delt inn i deler, og hver del er ansvarlig for sin egen Data Access Manager (DAM) prosess. Det gir dataregistrering, caching og låsemekanismer. Databehandling utføres av Executor Server Processes som kjører på de samme nodene som de tilsvarende databehandlerne. SQL/MX-planleggeren deler oppgaver mellom utførere og samler resultatene. Når det er nødvendig å foreta avtalte endringer, brukes to-fase commit-protokollen levert av TMF-biblioteket (Transaction Management Facility).
NonStop SQL kan prioritere prosesser slik at lange analytiske spørringer ikke forstyrrer transaksjonsutførelsen. Dens formål er imidlertid nettopp behandlingen av korte transaksjoner, og ikke analyser. Utvikleren garanterer tilgjengeligheten til NonStop-klyngen på nivået fem "nier", det vil si at nedetiden bare er 5 minutter per år.
SAP-HANA
Den første stabile utgivelsen av HANA DBMS (1.0) fant sted i november 2010, og SAP ERP-pakken byttet til HANA i mai 2013. Plattformen er basert på kjøpte teknologier: TREX Search Engine (søk i kolonnelager), P*TIME DBMS og MAX DB.
Selve ordet "HANA" er et akronym, High Performance ANAlytical Appliance. Dette DBMS leveres i form av kode som kan kjøres på alle x86-servere, men industrielle installasjoner er kun tillatt på sertifisert utstyr. Løsninger tilgjengelig fra HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Noen Lenovo-konfigurasjoner tillater til og med drift uten et SAN - rollen som et vanlig lagringssystem spilles av en GPFS-klynge på lokale disker.
I motsetning til plattformene som er oppført ovenfor, er HANA en DBMS i minnet, det vil si at det primære databildet lagres i RAM, og bare logger og periodiske øyeblikksbilder skrives til disken for gjenoppretting i tilfelle en katastrofe.
Hver HANA cluster node er ansvarlig for sin egen del av dataene, og datakartet lagres i en spesiell komponent – Name Server, plassert på koordinatornoden. Data dupliseres ikke mellom noder. Låseinformasjon lagres også på hver node, men systemet har en global vreklåsdetektor.
Når en HANA-klient kobler til en klynge, laster den ned topologien og kan deretter få tilgang til hvilken som helst node direkte, avhengig av hvilke data den trenger. Hvis en transaksjon påvirker dataene til en enkelt node, kan den utføres lokalt av den noden, men hvis dataene til flere noder endres, kontakter den initierende noden koordinatornoden, som åpner og koordinerer den distribuerte transaksjonen, og utfører den ved å bruke en optimalisert to-fase commit protokoll.
Koordinatornoden er duplisert, så hvis koordinatoren svikter, tar backupnoden umiddelbart over. Men hvis en node med data mislykkes, er den eneste måten å få tilgang til dataene på å starte noden på nytt. Som regel opprettholder HANA-klynger en reserveserver for å starte en tapt node på den på nytt så raskt som mulig.
Kilde: www.habr.com