CAP-satsen är en hörnsten i teorin om distribuerade system. Naturligtvis avtar inte kontroversen kring den: definitionerna i den är inte kanoniska, och det finns inga strikta bevis... Ändå, fast på ståndpunkterna för vardagligt sunt förnuft™, förstår vi intuitivt att satsen är sann.
Det enda som inte är uppenbart är innebörden av bokstaven "P". När ett kluster delas bestämmer det om det inte ska svara förrän ett kvorum har uppnåtts, eller om det ska lämna ut de data det har. Beroende på resultatet av detta val klassificeras systemet som antingen CP eller AP. Cassandra, till exempel, kan bete sig på båda sätten, beroende inte ens på klusterinställningarna, utan på parametrarna för varje specifik begäran. Men om systemet inte är "P" och det splittras, vad då?
Svaret på denna fråga är något oväntat: ett CA-kluster kan inte delas.
Vad är detta kluster som inte kan delas?
En viktig egenskap hos ett sådant kluster är ett delat datalagringssystem. I de allra flesta fall innebär detta anslutning via ett SAN, vilket begränsar användningen av CA-lösningar till stora företag som kan underhålla en SAN-infrastruktur. För att flera servrar För att arbeta med samma data krävs ett klusterfilsystem. Sådana filsystem finns tillgängliga i portföljerna från HPE (CFS), Veritas (VxCFS) och IBM (GPFS).
Oracle RAC
Alternativet Real Application Cluster dök först upp 2001 med lanseringen av Oracle 9i. I ett sådant kluster kan flera instanser server arbeta med samma databas.
Oracle kan arbeta med både ett klusterfilsystem och sin egen lösning – ASM, Automatic Storage Management.
Varje exemplar har sin egen journal. Transaktionen genomförs och genomförs i ett exemplar. Om en instans misslyckas läser en av de överlevande klusternoderna (instanserna) dess logg och återställer förlorad data, och säkerställer därmed tillgänglighet.
Alla instanser upprätthåller sin egen cache, och samma sidor (block) kan finnas i cachen för flera instanser samtidigt. Dessutom, om en sida behövs av en instans och den finns i en annan instanss cache, kan den hämta den från sin "granne" med hjälp av cachefusionsmekanismen istället för att läsa från disk.
Men vad händer om en av instanserna behöver ändra data?
Det speciella med Oracle är att det inte har en dedikerad låstjänst: om servern vill låsa en rad placeras låsposten direkt på minnessidan där raden som låses finns. Detta tillvägagångssätt gör Oracle till prestandamästaren bland monolitiska databaser: låstjänsten blir aldrig en flaskhals. Men i en klusterkonfiguration kan en sådan arkitektur leda till intensiv nätverkstrafik och dödlägen.
När en post är låst, meddelar instansen alla andra instanser att sidan som lagrar posten har varit exklusivt låst. Om en annan instans behöver ändra en post på samma sida, måste den vänta tills ändringarna på sidan är genomförda, det vill säga ändringsinformationen skrivs till diskloggen (medan transaktionen kan fortsätta). Det kan också hända att en sida ändras i följd med flera exemplar, och då när du skriver sidan till disk måste du ta reda på vem som har den aktuella versionen av denna sida.
Slumpmässig uppdatering av samma sidor över olika RAC-noder gör att databasprestanda försämras dramatiskt, till den punkt där klusterprestanda kan vara lägre än en enskild instans.
Den korrekta användningen av Oracle RAC är att fysiskt dela upp data (till exempel genom att använda en partitionerad tabellmekanism) och komma åt varje uppsättning partitioner via en dedikerad nod. Huvudsyftet med RAC var inte horisontell skalning, utan snarare att tillhandahålla feltolerans.
Om en nod slutar svara på ett hjärtslag, startar noden som först upptäckte detta en diskomröstningsprocedur. Om den saknade noden inte heller har checkat in här tar en av noderna på sig ansvaret för att återställa data:
- "fryser" alla sidor som fanns i cachen för den saknade noden;
- läser redo-loggarna för den saknade noden och återför ändringarna som registrerats i dessa loggar, samtidigt som de kontrollerar om andra noder har nyare versioner av sidorna som ändras;
- återställer ej slutförda transaktioner.
För att förenkla byte mellan noder har Oracle konceptet med en tjänst – en virtuell instans. En instans kan betjäna flera tjänster, och en tjänst kan flytta mellan noder. En applikationsinstans som betjänar en specifik del av databasen (till exempel en grupp klienter) fungerar med en tjänst, och tjänsten som ansvarar för denna del av databasen flyttar till en annan nod när noden misslyckas.
IBM Pure Data Systems for Transactions
Klusterlösningen för DBMS dök upp i Blue Giant-portföljen 2009. Ideologiskt är den efterföljaren till Parallel Sysplex-klustret, byggt på "vanlig" hårdvara. 2009 släpptes DB2 pureScale, en mjukvarusvit, och 2012 erbjöd IBM en hård- och mjukvarusvit (appliance) kallad Pure Data Systems for Transactions. Detta bör inte förväxlas med Pure Data Systems for Analytics, som inte är något annat än en omdöpt Netezza.
PureScale-arkitekturen liknar vid första anblicken Oracle RAC: på samma sätt är flera noder anslutna till ett gemensamt datalagringssystem, och varje nod kör sin egen DBMS-instans med sina egna minnesområden och transaktionsloggar. Men till skillnad från Oracle har DB2 en dedikerad låstjänst, representerad av en uppsättning db2LLM*-processer. I en klusterkonfiguration placeras denna tjänst på en separat nod, som i Parallel Sysplex kallas en kopplingsfunktion (CF), och i Pure Data – PowerHA.
PowerHA tillhandahåller följande tjänster:
- block manager;
- global buffertcache;
- området för interprocesskommunikation.
Fjärrminnesåtkomst används för att överföra data från PowerHA till DB-noderna och tillbaka, så klustersammankopplingen måste stödja RDMA-protokollet. PureScale kan använda både Infiniband och RDMA över Ethernet.
Om en nod behöver en sida och den sidan inte finns i cachen, begär noden sidan från den globala cachen, och bara om den inte finns där heller, läser den den från disken. Till skillnad från Oracle går begäran bara till PowerHA, inte till närliggande noder.
Om en instans ska ändra en rad låser den den i exklusivt läge och sidan där raden finns i delat läge. Alla lås registreras i den globala låshanteraren. När en transaktion slutförs skickar noden ett meddelande till låshanteraren, som kopierar den modifierade sidan till den globala cachen, släpper låsen och ogiltigförklarar den modifierade sidan i andra noders cacheminne.
Om sidan som innehåller raden som ändras redan är låst, kommer låshanteraren att läsa den modifierade sidan från minnet av noden som gjorde ändringen, släppa låset, ogiltigförklara den ändrade sidan i cachen på andra noder och returnera sidlåset till noden som begärde det.
"Dirty", det vill säga modifierade, sidor kan skrivas till disk från både en vanlig nod och från PowerHA (castout).
Om en pureScale-nod misslyckas begränsas återställningen till endast de transaktioner som ännu inte slutfördes vid tidpunkten för felet: sidorna som modifierats av den noden i slutförda transaktioner finns i den globala cachen på PowerHA. Noden startas om i en avskalad konfiguration på en av klusterservrarna, rullar tillbaka alla pågående transaktioner och släpper lås.
PowerHA körs på två servrar och den primära noden replikerar synkront sitt tillstånd. Om den primära noden misslyckas fortsätter PowerHA-klustret att fungera med backupnoden.
Naturligtvis, om du kommer åt en datamängd via en enda nod, kommer den totala prestandan för klustret att bli högre. PureScale kan till och med märka att ett visst dataområde bearbetas av en enda nod, och då kommer alla lås relaterade till det området att behandlas av noden lokalt utan att kommunicera med PowerHA. Men så snart applikationen försöker komma åt dessa data via en annan nod, kommer centraliserad låshantering att återupptas.
IBM:s interna tester på en 90% läs, 10% skrivarbetsbelastning, vilket är mycket likt verkliga produktionsbelastningar, visar nästan linjär skalning upp till 128 noder. Tyvärr avslöjas inte testförhållandena.
HPE NonStop SQL
Hewlett-Packard Enterprise har också en egen högtillgänglig plattform i sin portfölj. Detta är NonStop-plattformen, som introducerades på marknaden 1976 av Tandem Computers. 1997 förvärvades företaget av Compaq, som i sin tur slogs samman med Hewlett-Packard 2002.
NonStop används för att bygga verksamhetskritiska applikationer, såsom HLR eller bankkortsbehandling. Plattformen levereras i form av ett hård- och mjukvarukomplex (appliance), som inkluderar datornoder, ett datalagringssystem och kommunikationsutrustning. ServerNet-nätverket (i moderna system – Infiniband) tjänar både för utbyte mellan noder och för åtkomst till datalagringssystemet.
Tidiga versioner av systemet använde proprietära processorer som var synkroniserade med varandra: alla operationer utfördes synkront av flera processorer, och så snart en av processorerna gjorde ett misstag stängdes den av och den andra fortsatte att fungera. Senare bytte systemet till konventionella processorer (först MIPS, sedan Itanium och slutligen x86), och andra mekanismer började användas för synkronisering:
- meddelanden: varje systemprocess har en "skugg" tvilling, till vilken den aktiva processen regelbundet skickar meddelanden om dess status; Om huvudprocessen misslyckas, börjar skuggprocessen att fungera från det ögonblick som bestäms av det senaste meddelandet;
- röstning: datalagringssystemet har en speciell hårdvarukomponent som accepterar flera identiska förfrågningar och exekverar dem endast om förfrågningarna matchar; Istället för fysisk synkronisering arbetar processorer asynkront, och resultaten av deras arbete jämförs endast vid ingångs-/utgångsögonblick.
Sedan 1987 har NonStop-plattformen kört ett relationellt DBMS – först SQL/MP och senare SQL/MX.
Hela databasen är uppdelad i delar och varje del ansvarar för sin egen Data Access Manager (DAM) process. Den tillhandahåller datainspelning, cachning och låsmekanism. Databehandling utförs av exekutorprocesser (Executor Server Process), som körs på samma noder som motsvarande datahanterare. SQL/MX-schemaläggaren delar upp uppgifter mellan arbetare och kombinerar resultaten. När det är nödvändigt att göra överenskomna ändringar, används tvåfasprotokollet som tillhandahålls av TMF-biblioteket (Transaction Management Facility).
NonStop SQL kan prioritera processer så att långa analytiska frågor inte stör transaktionsexekveringen. Dess syfte är dock just att behandla korta transaktioner, inte analyser. Utvecklaren garanterar NonStop-klustertillgänglighet på nivån fem "nio", det vill säga driftstopp är bara 5 minuter per år.
SAP HANA
Den första stabila releasen av HANA DBMS (1.0) skedde i november 2010 och SAP ERP-paketet bytte till HANA i maj 2013. Plattformen är baserad på köpta teknologier: TREX Search Engine (sökning i kolumnlagring), P*TIME och MAX DB DBMS.
Själva ordet "HANA" är en akronym, High Performance ANalytical Appliance. Detta DBMS tillhandahålls i form av kod som kan köras på alla x86-servrar, dock är industriella installationer endast tillåtna på certifierad utrustning. Det finns lösningar från HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Vissa Lenovo-konfigurationer tillåter till och med drift utan ett SAN – rollen som det allmänna lagringssystemet spelas av ett GPFS-kluster på lokala diskar.
Till skillnad från plattformarna som listas ovan är HANA en DBMS i minnet, det vill säga den primära databilden lagras i RAM, och endast loggar och periodiska ögonblicksbilder skrivs till disken för återställning i händelse av en katastrof.
Varje HANA-klusternod ansvarar för sin egen del av datan, och datakartan lagras i en speciell komponent – Name Server, placerad på koordinatornoden. Data dupliceras inte mellan noder. Information om blockerat låsläge lagras också på varje nod, men systemet har en global dödlägesdetektor.
Vid anslutning till ett kluster laddar en HANA-klient ner sin topologi och kan sedan direkt komma åt vilken nod som helst beroende på vilken data den behöver. Om en transaktion påverkar data på en enskild nod kan den exekveras lokalt av den noden, men om data på flera noder ändras, kontaktar initiatornoden koordinatornoden, som öppnar och koordinerar den distribuerade transaktionen och utför den med hjälp av ett optimerat tvåfas commit-protokoll.
Koordinatornoden är duplicerad, så om samordnaren misslyckas tar backupnoden omedelbart över. Men om en nod med data misslyckas är det enda sättet att komma åt dess data att starta om noden. Vanligtvis har HANA-kluster en reservserver för att starta om en förlorad nod på den så snabbt som möjligt.
Källa: will.com
