CAP-sætningen er en hjørnesten 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 en klynge opdeles, beslutter den, om den ikke vil svare, før et kvorum er nået, eller om at udlevere de data, den har. Afhængigt af resultaterne af dette valg klassificeres systemet som enten CP eller AP. Cassandra, for eksempel, kan opføre sig på begge måder, 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 denne klynge, der ikke kan opdeles?
En væsentlig egenskab ved en sådan klynge er et delt datalagringssystem. I langt de fleste tilfælde betyder dette forbindelse via 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 For at arbejde med de samme data kræves et klyngefilsystem. Sådanne filsystemer er tilgængelige i porteføljerne fra HPE (CFS), Veritas (VxCFS) og IBM (GPFS).
Oracle RAC
Muligheden Real Application Cluster dukkede første gang op i 2001 med udgivelsen af Oracle 9i. I en sådan klynge kan flere instanser server arbejde med den samme database.
Oracle kan arbejde med både et klyngefilsystem og sin egen løsning – ASM, Automatic Storage Management.
Hvert eksemplar fører sin egen journal. Transaktionen udføres og forpligtes i ét eksemplar. Hvis en instans fejler, læser en af de overlevende klynge noder (instanser) sin log og gendanner de tabte data og sikrer derved tilgængelighed.
Alle forekomster vedligeholder deres egen cache, og de samme sider (blokke) kan ligge i flere forekomsters cache på samme tid. Desuden, hvis en side er nødvendig for en instans, og den er i cachen i en anden instans, kan den få den fra sin "nabo" ved at bruge cachefusionsmekanismen i stedet for at læse fra disk.
Men hvad sker der, hvis en af instanserne skal ændre dataene?
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 rækken, der låses, er placeret. Denne tilgang gør Oracle til præstationsmesteren blandt monolitiske databaser: låsetjenesten bliver aldrig en flaskehals. Men i en klyngekonfiguration kan en sådan arkitektur føre til intensiv netværkstrafik og dødvande.
Når en post er låst, giver forekomsten besked til alle andre forekomster om, at siden, der gemmer posten, udelukkende er blevet låst. Hvis en anden instans skal ændre en post på samme side, skal den vente, indtil ændringerne til siden er committet, dvs. ændringsoplysningerne skrives til diskloggen (mens transaktionen kan fortsætte). Det kan også ske, at en side ændres i rækkefølge med flere kopier, og så skal du, når du skriver siden til disk, finde ud af, hvem der har 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 forringes dramatisk, til det punkt, hvor klyngens ydeevne kan være lavere end en enkelt instans.
Den korrekte brug af Oracle RAC er fysisk at opdele dataene (for eksempel ved at bruge en partitioneret tabelmekanisme) og få adgang til hvert sæt partitioner gennem en dedikeret node. Hovedformålet med RAC var ikke horisontal skalering, men snarere at give fejltolerance.
Hvis en node holder op med at reagere på et hjerteslag, starter den node, der først opdagede dette, en diskafstemningsprocedure. Hvis den manglende node heller ikke har tjekket ind her, så påtager en af noderne sig ansvaret for at gendanne dataene:
- "fryser" alle sider, der var i cachen på den manglende node;
- læser redo-logfilerne for den manglende node og genanvender ændringerne, der er registreret i disse logfiler, mens det kontrolleres, om andre noder har nyere versioner af de sider, der ændres;
- ruller uafsluttede transaktioner tilbage.
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 specifik 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 noden svigter.
IBM Pure Data Systems for Transactions
Klyngeløsningen til DBMS dukkede op i Blue Giant-porteføljen i 2009. Ideologisk set er den efterfølgeren til Parallel Sysplex-klyngen, bygget på "almindelig" hardware. I 2009 blev DB2 pureScale, en softwarepakke, frigivet, og i 2012 tilbød IBM en hardware- og softwarepakke (apparat) kaldet Pure Data Systems for Transactions. Dette må ikke forveksles med Pure Data Systems for Analytics, som ikke er andet end en rebranded Netezza.
PureScale-arkitekturen ligner ved første øjekast 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 placeres denne service på en separat node, som i Parallel Sysplex kaldes en koblingsfacilitet (CF), og i Pure Data – PowerHA.
PowerHA leverer følgende tjenester:
- blok manager;
- global buffer cache;
- området for interproceskommunikation.
Fjernhukommelsesadgang bruges til at overføre data fra PowerHA til DB-noder og tilbage, 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 den side ikke er i cachen, anmoder noden om siden fra den globale cache, og kun hvis den heller ikke er der, læser den den fra disken. I modsætning til Oracle går anmodningen kun til PowerHA, ikke til naboknudepunkter.
Hvis en instans skal ændre en række, låser den den i eksklusiv tilstand og siden, hvor rækken ligger, i delt tilstand. Alle låse er registreret i den globale låsemanager. Når en transaktion er fuldført, sender noden en besked til låseadministratoren, som kopierer den ændrede side ind i den globale cache, frigiver låsene og ugyldiggør den ændrede side i andre noders cache.
Hvis siden, der indeholder rækken, der ændres, 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 returnere sidelåsen til den node, der anmodede om det.
"Dirty", det vil sige modificerede, sider kan skrives til disk fra både en almindelig node og fra PowerHA (castout).
Hvis en pureScale-node fejler, er gendannelse begrænset til kun de transaktioner, der endnu ikke var afsluttet på tidspunktet for fejlen: siderne, der er ændret af den node i afsluttede transaktioner, er i den globale cache på PowerHA. Noden genstartes i en strippet konfiguration på en af klyngeserverne, ruller eventuelle afventende transaktioner tilbage og frigiver låse.
PowerHA kører på to servere, og den primære node replikerer synkront sin tilstand. Hvis den primære knude svigter, fortsætter PowerHA-klyngen med at fungere med backup-knuden.
Selvfølgelig, hvis du får adgang til et datasæt gennem en enkelt node, vil klyngens samlede ydeevne være højere. PureScale kan endda bemærke, at et bestemt dataområde behandles af en enkelt node, og så vil alle låse relateret til dette område blive behandlet af noden lokalt uden at kommunikere med PowerHA. Men så snart applikationen forsøger at få adgang til disse data gennem en anden node, vil centraliseret låsehåndtering genoptages.
IBM's interne test på en 90 % læse-, 10 % skrive-arbejdsbelastning, som er meget lig den virkelige produktions-arbejdsbelastning, viser næsten lineær skalering op til 128 noder. Desværre er testbetingelserne ikke oplyst.
HPE NonStop SQL
Hewlett-Packard Enterprise har også sin egen yderst tilgængelige platform i sin portefølje. Dette er NonStop-platformen, introduceret 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 missionskritiske applikationer, såsom HLR eller bankkortbehandling. Platformen leveres i form af et hardware- og softwarekompleks (appliance), som omfatter computing noder, et datalagringssystem og kommunikationsudstyr. ServerNet-netværket (i moderne systemer – Infiniband) tjener både til udveksling mellem noder og til 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: datalagringssystemet har en speciel hardwarekomponent, der accepterer flere identiske anmodninger og udfører dem kun, hvis anmodningerne matcher; I stedet for fysisk synkronisering fungerer processorer asynkront, og resultaterne af deres arbejde sammenlignes kun ved input/output-øjeblikke.
Siden 1987 har NonStop-platformen kørt et relationelt DBMS – 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, caching og låsemekanisme. Databehandling udføres af eksekveringsprocesser (Executor Server Process), der kører på de samme noder som de tilsvarende dataadministratorer. SQL/MX-planlæggeren deler opgaver mellem arbejdere og kombinerer 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 at behandle korte transaktioner, ikke analyser. Udvikleren garanterer NonStop-klyngetilgængelighed på niveauet fem "nier", det vil sige, nedetiden er kun 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 og MAX DB DBMS.
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, dog er industrielle installationer kun tilladt på certificeret udstyr. Der er løsninger fra HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Nogle Lenovo-konfigurationer tillader endda drift uden et SAN - rollen som det generelle 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 særlig komponent – Name Server, placeret på koordinatorknudepunktet. Data duplikeres ikke mellem noder. Oplysninger om deadlocks gemmes også på hver node, men systemet har en global deadlock-detektor.
Når der oprettes forbindelse til en klynge, downloader en HANA-klient 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 data på en enkelt knude, kan den udføres lokalt af denne knude, men hvis data på flere knudepunkter ændres, kontakter initiatorknudepunktet koordinatorknudepunktet, som åbner og koordinerer den distribuerede transaktion, og begår den ved hjælp af en optimeret tofaset commit-protokol.
Koordinatorknudepunktet er duplikeret, så hvis koordinatoren fejler, overtager backupknudepunktet straks. Men hvis en node med data fejler, er den eneste måde at få adgang til dens data på at genstarte noden. Typisk vedligeholder HANA-klynger en ekstra server for at genstarte en tabt node på den så hurtigt som muligt.
Kilde: www.habr.com
