De CAP-stelling is de hoeksteen van de gedistribueerde systeemtheorie. Natuurlijk neemt de controverse eromheen niet af: de definities erin zijn niet canoniek, en er is geen strikt bewijs... Niettemin, terwijl we stevig vasthouden aan de standpunten van het alledaagse gezond verstand™, begrijpen we intuïtief dat de stelling waar is.
Het enige dat niet duidelijk is, is de betekenis van de letter "P". Wanneer het cluster wordt verdeeld, beslist het of het niet reageert totdat een quorum is bereikt, of dat het de beschikbare gegevens teruggeeft. Afhankelijk van de resultaten van deze keuze wordt het systeem geclassificeerd als CP of AP. Cassandra kan zich bijvoorbeeld op beide manieren gedragen, niet eens afhankelijk van de clusterinstellingen, maar van de parameters van elk specifiek verzoek. Maar als het systeem niet "P" is en zich splitst, wat dan?
Het antwoord op deze vraag is enigszins onverwacht: een CA-cluster kan niet splitsen.
Wat voor soort cluster is dit dat niet kan splitsen?
Een onmisbaar kenmerk van zo’n cluster is een gedeeld dataopslagsysteem. In de overgrote meerderheid van de gevallen betekent dit verbinding maken via een SAN, waardoor het gebruik van CA-oplossingen wordt beperkt tot grote ondernemingen die in staat zijn een SAN-infrastructuur te onderhouden. Om meerdere servers met dezelfde gegevens te laten werken, is een geclusterd bestandssysteem vereist. Dergelijke bestandssystemen zijn beschikbaar in de portfolio's HPE (CFS), Veritas (VxCFS) en IBM (GPFS).
Oracle-RAC
De Real Application Cluster-optie verscheen voor het eerst in 2001 met de release van Oracle 9i. In zo’n cluster werken meerdere serverinstances met dezelfde database.
Oracle kan werken met zowel een geclusterd bestandssysteem als een eigen oplossing: ASM, Automatic Storage Management.
Elk exemplaar houdt zijn eigen dagboek bij. De transactie wordt uitgevoerd en vastgelegd door één instantie. Als een exemplaar faalt, leest een van de overgebleven clusterknooppunten (instances) het logboek en herstelt de verloren gegevens, waardoor de beschikbaarheid wordt gegarandeerd.
Alle instanties behouden hun eigen cache, en dezelfde pagina's (blokken) kunnen zich tegelijkertijd in de caches van meerdere instanties bevinden. Bovendien, als een instantie een pagina nodig heeft en deze zich in de cache van een andere instantie bevindt, kan deze deze van de buurman ophalen met behulp van het cachefusiemechanisme in plaats van vanaf schijf te lezen.
Maar wat gebeurt er als een van de instanties gegevens moet wijzigen?
De bijzonderheid van Oracle is dat het geen speciale vergrendelingsservice heeft: als de server een rij wil vergrendelen, wordt het vergrendelingsrecord rechtstreeks op de geheugenpagina geplaatst waar de vergrendelde rij zich bevindt. Dankzij deze aanpak is Oracle de prestatiekampioen onder monolithische databases: de vergrendelingsservice wordt nooit een knelpunt. Maar in een clusterconfiguratie kan een dergelijke architectuur leiden tot intensief netwerkverkeer en impasses.
Zodra een record is vergrendeld, meldt een exemplaar aan alle andere exemplaren dat de pagina waarop dat record is opgeslagen een exclusieve bewaarplicht heeft. Als een ander exemplaar een record op dezelfde pagina moet wijzigen, moet het wachten totdat de wijzigingen op de pagina zijn vastgelegd, dat wil zeggen dat de wijzigingsinformatie naar een journaal op schijf wordt geschreven (en de transactie kan worden voortgezet). Het kan ook gebeuren dat een pagina achtereenvolgens door meerdere kopieën wordt gewijzigd, en dat u bij het schrijven van de pagina naar schijf moet uitzoeken wie de huidige versie van deze pagina opslaat.
Het willekeurig bijwerken van dezelfde pagina's over verschillende RAC-knooppunten zorgt ervoor dat de databaseprestaties dramatisch afnemen, tot het punt waarop de clusterprestaties lager kunnen zijn dan die van een enkele instantie.
Het juiste gebruik van Oracle RAC is het fysiek partitioneren van de gegevens (bijvoorbeeld met behulp van een gepartitioneerd tabelmechanisme) en toegang tot elke set partities via een speciaal knooppunt. Het belangrijkste doel van RAC was niet horizontaal schalen, maar het garanderen van fouttolerantie.
Als een knooppunt niet meer reageert op een hartslag, start het knooppunt dat het heeft gedetecteerd eerst een stemprocedure op de schijf. Als het ontbrekende knooppunt hier niet wordt vermeld, neemt een van de knooppunten de verantwoordelijkheid voor gegevensherstel op zich:
- “bevriest” alle pagina’s die zich in de cache van het ontbrekende knooppunt bevonden;
- leest de logs (opnieuw) van het ontbrekende knooppunt en past de wijzigingen die in deze logs zijn vastgelegd opnieuw toe, waarbij tegelijkertijd wordt gecontroleerd of andere knooppunten recentere versies hebben van de pagina's die worden gewijzigd;
- draait lopende transacties terug.
Om het schakelen tussen knooppunten te vereenvoudigen, heeft Oracle het concept van een service: een virtuele instantie. Een instance kan meerdere services leveren, en een service kan tussen knooppunten bewegen. Een applicatie-instantie die een bepaald deel van de database bedient (bijvoorbeeld een groep clients) werkt met één service, en de service die verantwoordelijk is voor dit deel van de database verplaatst zich naar een ander knooppunt wanneer een knooppunt uitvalt.
IBM Pure Data Systems voor transacties
In 2009 verscheen een clusteroplossing voor DBMS in het Blue Giant-portfolio. Ideologisch gezien is het de opvolger van het Parallel Sysplex-cluster, gebouwd op ‘gewone’ apparatuur. In 2009 werd DB2 pureScale uitgebracht als softwaresuite en in 2012 bood IBM een apparaat aan met de naam Pure Data Systems for Transactions. Het moet niet worden verward met Pure Data Systems for Analytics, dat niets meer is dan een hernoemde Netezza.
Op het eerste gezicht lijkt de pureScale-architectuur op Oracle RAC: op dezelfde manier zijn verschillende knooppunten verbonden met een gemeenschappelijk gegevensopslagsysteem, en voert elk knooppunt zijn eigen DBMS-instantie uit met zijn eigen geheugengebieden en transactielogboeken. Maar in tegenstelling tot Oracle beschikt DB2 over een speciale vergrendelingsservice die wordt vertegenwoordigd door een reeks db2LLM*-processen. In een clusterconfiguratie wordt deze dienst op een apart knooppunt geplaatst, dat in Parallel Sysplex koppelingsfaciliteit (CF) wordt genoemd en in Pure Data PowerHA.
PowerHA levert de volgende diensten:
- sluisbeheerder;
- globale buffercache;
- gebied van interprocescommunicatie.
Om gegevens van PowerHA naar de databaseknooppunten en terug over te dragen, wordt externe geheugentoegang gebruikt, dus de clusterverbinding moet het RDMA-protocol ondersteunen. PureScale kan zowel Infiniband als RDMA via Ethernet gebruiken.
Als een knooppunt een pagina nodig heeft en deze pagina bevindt zich niet in de cache, dan vraagt het knooppunt de pagina op in de globale cache, en alleen als deze er niet is, leest hij deze van schijf. In tegenstelling tot Oracle gaat het verzoek alleen naar PowerHA en niet naar aangrenzende knooppunten.
Als een instantie een rij gaat wijzigen, wordt deze vergrendeld in de exclusieve modus, en de pagina waarop de rij zich bevindt in de gedeelde modus. Alle sloten worden geregistreerd in de global lock manager. Wanneer de transactie is voltooid, stuurt het knooppunt een bericht naar de slotbeheerder, die de gewijzigde pagina naar de globale cache kopieert, de vergrendelingen vrijgeeft en de gewijzigde pagina ongeldig maakt in de caches van andere knooppunten.
Als de pagina waarop de gewijzigde rij zich bevindt al is vergrendeld, zal de slotmanager de gewijzigde pagina lezen uit het geheugen van het knooppunt dat de wijziging heeft aangebracht, de vergrendeling vrijgeven, de gewijzigde pagina ongeldig maken in de caches van andere knooppunten, en geef de paginavergrendeling aan het knooppunt dat erom heeft gevraagd.
"Dirty", dat wil zeggen, gewijzigd, pagina's kunnen zowel vanaf een gewoon knooppunt als vanaf PowerHA (castout) naar schijf worden geschreven.
Als een van de pureScale-knooppunten faalt, is het herstel beperkt tot alleen die transacties die nog niet waren voltooid op het moment van de mislukking: de pagina's die door dat knooppunt in voltooide transacties zijn gewijzigd, bevinden zich in de globale cache op PowerHA. Het knooppunt start opnieuw op in een beperkte configuratie op een van de servers in het cluster, draait lopende transacties terug en geeft vergrendelingen vrij.
PowerHA draait op twee servers en het masterknooppunt repliceert zijn status synchroon. Als het primaire PowerHA-knooppunt uitvalt, blijft het cluster werken met het back-upknooppunt.
Als u via één knooppunt toegang krijgt tot de dataset, zullen de algehele prestaties van het cluster uiteraard hoger zijn. PureScale kan zelfs merken dat een bepaald gegevensgebied door één knooppunt wordt verwerkt, en vervolgens worden alle vergrendelingen die verband houden met dat gebied lokaal door het knooppunt verwerkt zonder met PowerHA te communiceren. Maar zodra de applicatie via een ander knooppunt toegang probeert te krijgen tot deze gegevens, wordt de gecentraliseerde vergrendelingsverwerking hervat.
De interne tests van IBM op een werklast van 90% lezen en 10% schrijven, wat sterk lijkt op productiewerklasten in de echte wereld, laten een vrijwel lineaire opschaling zien tot 128 knooppunten. Testomstandigheden worden helaas niet bekendgemaakt.
HPE NonStop SQL
Het Hewlett-Packard Enterprise-portfolio beschikt ook over een eigen, zeer beschikbaar platform. Dit is het NonStop-platform, dat in 1976 door Tandem Computers op de markt werd gebracht. In 1997 werd het bedrijf overgenomen door Compaq, dat op zijn beurt in 2002 fuseerde met Hewlett-Packard.
NonStop wordt gebruikt om kritische applicaties te bouwen, bijvoorbeeld HLR of bankkaartverwerking. Het platform wordt geleverd in de vorm van een software- en hardwarecomplex (apparaat), dat computerknooppunten, een gegevensopslagsysteem en communicatieapparatuur omvat. Het ServerNet-netwerk (in moderne systemen - Infiniband) dient zowel voor uitwisseling tussen knooppunten als voor toegang tot het gegevensopslagsysteem.
Vroege versies van het systeem gebruikten eigen processors die met elkaar waren gesynchroniseerd: alle bewerkingen werden synchroon uitgevoerd door verschillende processors, en zodra een van de processors een fout maakte, werd deze uitgeschakeld en bleef de tweede werken. Later schakelde het systeem over op conventionele processors (eerst MIPS, daarna Itanium en ten slotte x86), en begonnen andere mechanismen te worden gebruikt voor synchronisatie:
- berichten: elk systeemproces heeft een “schaduw”-tweeling, waarnaar het actieve proces periodiek berichten over zijn status verzendt; als het hoofdproces faalt, begint het schaduwproces te werken vanaf het moment bepaald door het laatste bericht;
- stemmen: het opslagsysteem heeft een speciale hardwarecomponent die meerdere identieke toegangen accepteert en deze alleen uitvoert als de toegangen overeenkomen; In plaats van fysieke synchronisatie werken processors asynchroon en worden de resultaten van hun werk alleen op I/O-momenten vergeleken.
Sinds 1987 draait er een relationeel DBMS op het NonStop-platform: eerst SQL/MP en later SQL/MX.
De gehele database is opgedeeld in delen en elk deel is verantwoordelijk voor zijn eigen Data Access Manager (DAM)-proces. Het biedt gegevensregistratie, caching en vergrendelingsmechanismen. De gegevensverwerking wordt uitgevoerd door Executor Server Processes die op dezelfde knooppunten draaien als de overeenkomstige gegevensbeheerders. De SQL/MX-planner verdeelt de taken onder de uitvoerders en voegt de resultaten samen. Wanneer het nodig is om overeengekomen wijzigingen aan te brengen, wordt het tweefasige commit-protocol gebruikt dat wordt geleverd door de TMF-bibliotheek (Transaction Management Facility).
NonStop SQL kan processen prioriteren, zodat lange analytische queries de uitvoering van transacties niet verstoren. Het doel ervan is echter juist de verwerking van korte transacties, en niet de analyse. De ontwikkelaar garandeert de beschikbaarheid van het NonStop-cluster op het niveau van vijf "negen", dat wil zeggen dat de downtime slechts 5 minuten per jaar bedraagt.
SAP HANA
De eerste stabiele release van het HANA DBMS (1.0) vond plaats in november 2010 en het SAP ERP-pakket schakelde in mei 2013 over naar HANA. Het platform is gebaseerd op aangekochte technologieën: TREX Search Engine (zoeken in kolomopslag), P*TIME DBMS en MAX DB.
Het woord “HANA” zelf is een acroniem, High performance ANAlytical Appliance. Dit DBMS wordt geleverd in de vorm van code die op elke x86-server kan draaien, maar industriële installaties zijn alleen toegestaan op gecertificeerde apparatuur. Oplossingen beschikbaar van HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Sommige Lenovo-configuraties maken zelfs werking zonder SAN mogelijk - de rol van een gemeenschappelijk opslagsysteem wordt gespeeld door een GPFS-cluster op lokale schijven.
In tegenstelling tot de hierboven genoemde platforms is HANA een DBMS in het geheugen, dat wil zeggen dat de primaire gegevensafbeelding wordt opgeslagen in het RAM en dat alleen logboeken en periodieke snapshots naar schijf worden geschreven voor herstel in geval van een ramp.
Elk HANA-clusterknooppunt is verantwoordelijk voor zijn eigen deel van de gegevens en de datakaart wordt opgeslagen in een speciale component – Name Server, die zich op het coördinatorknooppunt bevindt. Gegevens worden niet gedupliceerd tussen knooppunten. Vergrendelingsinformatie wordt ook op elk knooppunt opgeslagen, maar het systeem beschikt over een globale deadlock-detector.
Wanneer een HANA-client verbinding maakt met een cluster, downloadt deze de topologie ervan en heeft deze vervolgens rechtstreeks toegang tot elk knooppunt, afhankelijk van de gegevens die hij nodig heeft. Als een transactie de gegevens van een enkel knooppunt beïnvloedt, kan deze lokaal door dat knooppunt worden uitgevoerd, maar als de gegevens van verschillende knooppunten veranderen, neemt het initiërende knooppunt contact op met het coördinatorknooppunt, dat de gedistribueerde transactie opent en coördineert, en deze vastlegt met behulp van een geoptimaliseerd tweefasig commit-protocol.
Het coördinatorknooppunt is gedupliceerd, dus als de coördinator faalt, neemt het back-upknooppunt het onmiddellijk over. Maar als een knooppunt met gegevens uitvalt, is de enige manier om toegang te krijgen tot de gegevens het opnieuw opstarten van het knooppunt. HANA-clusters onderhouden in de regel een reserveserver om een verloren knooppunt daarop zo snel mogelijk opnieuw op te starten.
Bron: www.habr.com