CAP-sætningen er hjørnestenen i teorien om distribuerede systemer. Naturligvis aftager kontroversen omkring det ikke: definitionerne i den er ikke kanoniske, og der er ingen strenge beviser... Ikke desto mindre, fast på standpunkterne i hverdagens sunde fornuft™, forstår vi intuitivt, at teoremet er sandt.
Det eneste, der ikke er indlysende, er betydningen af bogstavet "P". Når klyngen er opdelt, beslutter den, om den ikke vil svare, før et kvorum er nået, eller om at give de tilgængelige data tilbage. Afhængigt af resultaterne af dette valg klassificeres systemet som enten en CP eller en AP. Cassandra, for eksempel, kan opføre sig begge veje, ikke engang afhængig af klyngeindstillingerne, men af parametrene for hver specifik anmodning. Men hvis systemet ikke er "P", og det splittes, hvad så?
Svaret på dette spørgsmål er noget uventet: en CA-klynge kan ikke opdeles.
Hvad er det for en klynge, der ikke kan opdeles?
En uundværlig egenskab ved en sådan klynge er et delt datalagringssystem. I langt de fleste tilfælde betyder dette tilslutning over et SAN, hvilket begrænser brugen af CA-løsninger til store virksomheder, der er i stand til at vedligeholde en SAN-infrastruktur. For at flere servere kan arbejde med de samme data, kræves der et klynget filsystem. Sådanne filsystemer er tilgængelige i porteføljerne HPE (CFS), Veritas (VxCFS) og IBM (GPFS).
Oracle RAC
Indstillingen Real Application Cluster dukkede første gang op i 2001 med udgivelsen af Oracle 9i. I en sådan klynge arbejder flere serverforekomster med den samme database.
Oracle kan arbejde med både et klynget filsystem og sin egen løsning - ASM, Automatic Storage Management.
Hvert eksemplar fører sin egen journal. Transaktionen udføres og begås af én instans. Hvis en instans fejler, læser en af de overlevende cluster noder (instanser) sin log og gendanner de tabte data - og sikrer derved tilgængelighed.
Alle instanser vedligeholder deres egen cache, og de samme sider (blokke) kan være i flere instansers cache på samme tid. Desuden, hvis en instans har brug for en side, og den er i cachen i en anden instans, kan den få den fra sin nabo ved at bruge cache-fusionsmekanismen i stedet for at læse fra disk.
Men hvad sker der, hvis en af instanserne skal ændre data?
Det særlige ved Oracle er, at det ikke har en dedikeret låsetjeneste: Hvis serveren ønsker at låse en række, placeres låseposten direkte på hukommelsessiden, hvor den låste række er placeret. Takket være denne tilgang er Oracle præstationsmesteren blandt monolitiske databaser: låsetjenesten bliver aldrig en flaskehals. Men i en klyngekonfiguration kan en sådan arkitektur føre til intens netværkstrafik og dødvande.
Når en post er låst, giver en forekomst besked til alle andre forekomster om, at siden, der gemmer posten, har et eksklusivt hold. Hvis en anden instans skal ændre en post på samme side, skal den vente, indtil ændringerne på siden er committet, det vil sige, at ændringsinformationen skrives til en journal på disken (og transaktionen kan fortsætte). Det kan også ske, at en side vil blive ændret sekventielt med flere kopier, og når du skriver siden til disk, skal du finde ud af, hvem der gemmer den aktuelle version af denne side.
Tilfældig opdatering af de samme sider på tværs af forskellige RAC-noder får databaseydeevnen til at falde dramatisk, til det punkt, hvor klyngens ydeevne kan være lavere end en enkelt instans.
Den korrekte brug af Oracle RAC er fysisk at partitionere dataene (for eksempel ved hjælp af en partitioneret tabelmekanisme) og få adgang til hvert sæt partitioner gennem en dedikeret node. Hovedformålet med RAC var ikke horisontal skalering, men at sikre fejltolerance.
Hvis en node holder op med at reagere på et hjerteslag, starter den node, der først har registreret den, en afstemningsprocedure på disken. Hvis den manglende node ikke er noteret her, påtager en af noderne sig ansvaret for datagendannelse:
- "fryser" alle sider, der var i cachen på den manglende node;
- læser logfilerne (redo) for den manglende node og genbruger ændringerne, der er registreret i disse logfiler, og kontrollerer samtidig, om andre noder har nyere versioner af siderne, der ændres;
- ruller tilbage afventende transaktioner.
For at forenkle skift mellem noder har Oracle konceptet med en tjeneste - en virtuel instans. En instans kan tjene flere tjenester, og en tjeneste kan flytte mellem noder. En applikationsforekomst, der betjener en bestemt del af databasen (f.eks. en gruppe klienter) arbejder med én tjeneste, og den service, der er ansvarlig for denne del af databasen, flytter til en anden node, når en node fejler.
IBM Pure Data Systems for Transactions
En klyngeløsning til DBMS dukkede op i Blue Giant-porteføljen i 2009. Ideologisk er det efterfølgeren til Parallel Sysplex-klyngen, bygget på "almindeligt" udstyr. I 2009 blev DB2 pureScale udgivet som en softwarepakke, og i 2012 tilbød IBM en enhed kaldet Pure Data Systems for Transactions. Det må ikke forveksles med Pure Data Systems for Analytics, som ikke er andet end en omdøbt Netezza.
Ved første øjekast ligner pureScale-arkitekturen Oracle RAC: På samme måde er flere noder forbundet til et fælles datalagringssystem, og hver node kører sin egen DBMS-instans med sine egne hukommelsesområder og transaktionslogfiler. Men i modsætning til Oracle har DB2 en dedikeret låsetjeneste repræsenteret af et sæt db2LLM*-processer. I en klyngekonfiguration er denne service placeret på en separat node, som kaldes koblingsfacilitet (CF) i Parallel Sysplex og PowerHA i Pure Data.
PowerHA leverer følgende tjenester:
- låsemanager;
- global buffer cache;
- område for interproceskommunikation.
For at overføre data fra PowerHA til databasenoderne og tilbage, bruges fjernhukommelsesadgang, så klyngesammenkoblingen skal understøtte RDMA-protokollen. PureScale kan bruge både Infiniband og RDMA over Ethernet.
Hvis en node har brug for en side, og denne side ikke er i cachen, så anmoder noden om siden i den globale cache, og kun hvis den ikke er der, læser den fra disken. I modsætning til Oracle går anmodningen kun til PowerHA og ikke til naboknudepunkter.
Hvis en instans skal ændre en række, låser den den i eksklusiv tilstand, og siden, hvor rækken er placeret, i delt tilstand. Alle låse er registreret i den globale låsemanager. Når transaktionen er fuldført, sender noden en besked til låseadministratoren, som kopierer den ændrede side til den globale cache, frigiver låsene og ugyldiggør den ændrede side i andre noders cache.
Hvis siden, hvor den ændrede række er placeret, allerede er låst, vil låseadministratoren læse den ændrede side fra hukommelsen på den node, der foretog ændringen, frigive låsen, ugyldiggøre den ændrede side i andre knudepunkters cache og giv sidelåsen til den node, der anmodede om den.
"Dirty", det vil sige ændrede, sider kan skrives til disk både fra en almindelig node og fra PowerHA (castout).
Hvis en af pureScale-noderne fejler, er gendannelse begrænset til kun de transaktioner, der endnu ikke var afsluttet på fejltidspunktet: siderne, der er ændret af den node i afsluttede transaktioner, er i den globale cache på PowerHA. Noden genstarter i en reduceret konfiguration på en af serverne i klyngen, ruller tilbage afventende transaktioner og frigiver låse.
PowerHA kører på to servere, og masternoden replikerer sin tilstand synkront. Hvis den primære PowerHA-knude svigter, fortsætter klyngen med at fungere med backup-knuden.
Selvfølgelig, hvis du får adgang til datasættet gennem en enkelt node, vil klyngens samlede ydeevne være højere. PureScale kan endda bemærke, at et bestemt dataområde behandles af én node, og så vil alle låse relateret til dette område blive behandlet lokalt af noden uden at kommunikere med PowerHA. Men så snart applikationen forsøger at få adgang til disse data gennem en anden node, genoptages centraliseret låsebehandling.
IBMs interne test med en arbejdsbelastning på 90 % læst og 10 % skrivning, hvilket er meget lig den virkelige verdens produktionsbelastninger, viser næsten lineær skalering op til 128 noder. Testbetingelser er desværre ikke oplyst.
HPE NonStop SQL
Hewlett-Packard Enterprise-porteføljen har også sin egen yderst tilgængelige platform. Dette er NonStop-platformen, frigivet på markedet i 1976 af Tandem Computers. I 1997 blev virksomheden opkøbt af Compaq, som igen fusionerede med Hewlett-Packard i 2002.
NonStop bruges til at bygge kritiske applikationer - for eksempel HLR eller bankkortbehandling. Platformen leveres i form af et software- og hardwarekompleks (appliance), som omfatter computing noder, et datalagringssystem og kommunikationsudstyr. ServerNet-netværket (i moderne systemer - Infiniband) tjener både til udveksling mellem noder og for adgang til datalagringssystemet.
Tidlige versioner af systemet brugte proprietære processorer, der var synkroniseret med hinanden: alle operationer blev udført synkront af flere processorer, og så snart en af processorerne lavede en fejl, blev den slukket, og den anden fortsatte med at fungere. Senere skiftede systemet til konventionelle processorer (først MIPS, derefter Itanium og til sidst x86), og andre mekanismer begyndte at blive brugt til synkronisering:
- beskeder: hver systemproces har en "skygge" tvilling, hvortil den aktive proces med jævne mellemrum sender beskeder om dens status; hvis hovedprocessen mislykkes, begynder skyggeprocessen at fungere fra det øjeblik, der er bestemt af den sidste besked;
- afstemning: lagersystemet har en speciel hardwarekomponent, der accepterer flere identiske adgange og udfører dem kun, hvis adgangene matcher; I stedet for fysisk synkronisering fungerer processorer asynkront, og resultaterne af deres arbejde sammenlignes kun ved I/O-øjeblikke.
Siden 1987 har et relationelt DBMS kørt på NonStop platformen - først SQL/MP, og senere SQL/MX.
Hele databasen er opdelt i dele, og hver del er ansvarlig for sin egen Data Access Manager (DAM) proces. Det giver dataoptagelse, cachelagring og låsemekanismer. Databehandling udføres af Executor Server Processes, der kører på de samme noder som de tilsvarende dataadministratorer. SQL/MX-planlæggeren opdeler opgaver mellem eksekvere og samler resultaterne. Når det er nødvendigt at foretage aftalte ændringer, bruges den to-fasede commit-protokol, der leveres af TMF-biblioteket (Transaction Management Facility).
NonStop SQL kan prioritere processer, så lange analytiske forespørgsler ikke forstyrrer transaktionsudførelsen. Dens formål er dog netop behandlingen af korte transaktioner og ikke analyser. Udvikleren garanterer tilgængeligheden af NonStop-klyngen på niveauet fem "ni", det vil sige, at nedetiden kun er 5 minutter om året.
SAP HANA
Den første stabile udgivelse af HANA DBMS (1.0) fandt sted i november 2010, og SAP ERP-pakken skiftede til HANA i maj 2013. Platformen er baseret på købte teknologier: TREX Search Engine (søg i kolonnelager), P*TIME DBMS og MAX DB.
Selve ordet "HANA" er et akronym, High Performance ANAlytical Appliance. Dette DBMS leveres i form af kode, der kan køre på alle x86-servere, men industrielle installationer er kun tilladt på certificeret udstyr. Løsninger tilgængelige fra HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Nogle Lenovo-konfigurationer tillader endda drift uden et SAN - rollen som et fælles lagersystem spilles af en GPFS-klynge på lokale diske.
I modsætning til de ovennævnte platforme er HANA et DBMS i hukommelsen, dvs. det primære databillede er gemt i RAM, og kun logfiler og periodiske snapshots skrives til disken til gendannelse i tilfælde af en katastrofe.
Hver HANA-klyndeknude er ansvarlig for sin egen del af dataene, og datakortet er gemt i en speciel komponent – Name Server, placeret på koordinatorknudepunktet. Data duplikeres ikke mellem noder. Låseoplysninger gemmes også på hver knude, men systemet har en global dødlåsdetektor.
Når en HANA-klient opretter forbindelse til en klynge, downloader den sin topologi og kan derefter få direkte adgang til enhver node, afhængigt af hvilke data den har brug for. Hvis en transaktion påvirker dataene for en enkelt node, så kan den udføres lokalt af den node, men hvis dataene for flere noder ændres, kontakter den initierende node koordinatorknuden, som åbner og koordinerer den distribuerede transaktion, og udfører den ved hjælp af en optimeret to-faset commit protokol.
Koordinatorknudepunktet er duplikeret, så hvis koordinatoren fejler, tager backupknuden straks over. Men hvis en node med data fejler, så er den eneste måde at få adgang til dens data på at genstarte noden. Som regel opretholder HANA-klynger en reserveserver for at genstarte en tabt node på den så hurtigt som muligt.
Kilde: www.habr.com