CAP-satsen är hörnstenen 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 klustret är uppdelat bestämmer det om det inte ska svara förrän ett kvorum har uppnåtts, eller att lämna tillbaka den data som är tillgänglig. Beroende på resultatet av detta val klassificeras systemet som antingen en CP eller en AP. Cassandra, till exempel, kan bete sig hur som helst, inte ens beroende 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 det för slags kluster som inte kan delas?
En oumbärlig egenskap hos ett sådant kluster är ett delat datalagringssystem. I de allra flesta fall innebär detta anslutning över 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 ska kunna arbeta med samma data krävs ett klustrat filsystem. Sådana filsystem är tillgängliga i portföljerna HPE (CFS), Veritas (VxCFS) och IBM (GPFS).
Oracle RAC
Alternativet Real Application Cluster dök upp först 2001 med lanseringen av Oracle 9i. I ett sådant kluster fungerar flera serverinstanser med samma databas.
Oracle kan arbeta med både ett klustrat filsystem och sin egen lösning - ASM, Automatic Storage Management.
Varje exemplar har sin egen journal. Transaktionen genomförs och begås av en instans. Om en instans misslyckas läser en av de överlevande klusternoderna (instanserna) sin logg och återställer förlorad data - och säkerställer därmed tillgänglighet.
Alla instanser har sin egen cache, och samma sidor (block) kan finnas i flera instansers cache samtidigt. Dessutom, om en instans behöver en sida 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 den låsta raden finns. Tack vare detta tillvägagångssätt är Oracle 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 en instans alla andra instanser att sidan som lagrar den posten har en exklusiv spärr. 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 en journal på disk (och transaktionen kan fortsätta). Det kan också hända att en sida kommer att ändras sekventiellt med flera kopior, och när du skriver sidan till disk måste du ta reda på vem som lagrar den aktuella versionen av denna sida.
Slumpmässig uppdatering av samma sidor över olika RAC-noder gör att databasprestanda sjunker dramatiskt, till den punkt där klusterprestanda kan vara lägre än för en enskild instans.
Den korrekta användningen av Oracle RAC är att fysiskt partitionera 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 att säkerställa feltolerans.
Om en nod slutar svara på ett hjärtslag, startar noden som upptäckte den först en omröstningsprocedur på disken. Om den saknade noden inte noteras här, tar en av noderna på sig ansvaret för dataåterställning:
- "fryser" alla sidor som fanns i cachen för den saknade noden;
- läser loggarna (gör om) 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 väntande 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 viss 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 en nod misslyckas.
IBM Pure Data Systems for Transactions
En klusterlösning för DBMS dök upp i Blue Giant-portföljen 2009. Ideologiskt är det efterföljaren till Parallel Sysplex-klustret, byggt på "vanlig" utrustning. 2009 släpptes DB2 pureScale som en mjukvarusvit och 2012 erbjöd IBM en apparat som heter Pure Data Systems for Transactions. Det bör inte förväxlas med Pure Data Systems for Analytics, som inte är något annat än en omdöpt Netezza.
Vid första anblicken liknar pureScale-arkitekturen 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 som representeras av en uppsättning db2LLM*-processer. I en klusterkonfiguration placeras denna tjänst på en separat nod, som kallas coupling facility (CF) i Parallel Sysplex, och PowerHA i Pure Data.
PowerHA tillhandahåller följande tjänster:
- låshanterare;
- global buffertcache;
- område för interprocesskommunikation.
För att överföra data från PowerHA till databasnoderna och tillbaka, används fjärrminnesåtkomst, 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 här sidan inte finns i cachen, begär noden sidan i den globala cachen, och endast om den inte finns där, läser den från disken. Till skillnad från Oracle går begäran bara till PowerHA och 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 ligger i delat läge. Alla lås registreras i den globala låshanteraren. När transaktionen är slutförd 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 där den ändrade raden finns redan är låst, kommer låshanteraren att läsa den ändrade sidan från minnet av noden som gjorde ändringen, släppa låset, ogiltigförklara den ändrade sidan i andra noders cacheminne och ge sidlåset till noden som begärde det.
"Dirty", det vill säga ändrade, sidor kan skrivas till disk både från en vanlig nod och från PowerHA (castout).
Om en av pureScale-noderna 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 startar om i en reducerad konfiguration på en av servrarna i klustret, rullar tillbaka väntande transaktioner och släpper lås.
PowerHA körs på två servrar och huvudnoden replikerar sitt tillstånd synkront. Om den primära PowerHA-noden misslyckas fortsätter klustret att fungera med backupnoden.
Naturligtvis, om du kommer åt datamängden 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 nod, och då kommer alla lås relaterade till det området att behandlas lokalt av noden utan att kommunicera med PowerHA. Men så snart applikationen försöker komma åt dessa data via en annan nod, kommer centraliserad låsbearbetning att återupptas.
IBM:s interna tester med en arbetsbelastning på 90 % läsning och 10 % skrivning, vilket är mycket likt verkliga produktionsbelastningar, visar nästan linjär skalning upp till 128 noder. Testförhållanden avslöjas tyvärr inte.
HPE NonStop SQL
Hewlett-Packard Enterprise-portföljen har också en egen högtillgänglig plattform. Detta är NonStop-plattformen som släpptes 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 kritiska applikationer - till exempel HLR eller bankkortsbehandling. Plattformen levereras i form av ett mjukvaru- och hårdvarukomplex (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 fel 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 sista meddelandet;
- röstning: lagringssystemet har en speciell hårdvarukomponent som accepterar flera identiska åtkomster och exekverar dem endast om åtkomsterna matchar; Istället för fysisk synkronisering arbetar processorer asynkront, och resultaten av deras arbete jämförs endast vid I/O-ögonblick.
Sedan 1987 har ett relationellt DBMS körts på NonStop-plattformen - 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. Det tillhandahåller datainspelning, cachning och låsmekanismer. Databehandling utförs av Executor Server Processes som körs på samma noder som motsvarande datahanterare. SQL/MX-schemaläggaren delar upp uppgifter mellan utförare och aggregerar 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 bearbetning av korta transaktioner, och inte analyser. Utvecklaren garanterar tillgängligheten av NonStop-klustret på nivån fem "nio", det vill säga driftstopp är bara 5 minuter per år.
SAP HANA
Den första stabila versionen av HANA DBMS (1.0) ägde rum 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 DBMS och MAX DB.
Själva ordet "HANA" är en förkortning, High Performance ANalytical Appliance. Detta DBMS tillhandahålls i form av kod som kan köras på alla x86-servrar, men industriella installationer är endast tillåtna på certifierad utrustning. Lösningar tillgängliga från HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Vissa Lenovo-konfigurationer tillåter till och med drift utan ett SAN - rollen som ett gemensamt lagringssystem 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. Låsinformation lagras också på varje nod, men systemet har en global dödlägesdetektor.
När en HANA-klient ansluter till ett kluster, laddar den ner dess topologi och kan sedan komma åt valfri nod direkt, beroende på vilken data den behöver. Om en transaktion påverkar data från en enskild nod, kan den exekveras lokalt av den noden, men om data från flera noder ändras, kontaktar den initierande noden koordinatornoden, som öppnar och koordinerar den distribuerade transaktionen och utför den med hjälp av en 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. Som regel upprätthåller HANA-kluster en reservserver för att starta om en förlorad nod på den så snabbt som möjligt.
Källa: will.com