Jämför Oracle RAC HA-lösning med Galera Cluster för MySQL eller MariaDB

Verksamheten har hela tiden önskat att få insikter från information för att fatta tillförlitliga, smartare, faktabaserade beslut i realtid. Eftersom företag förlitar sig mer på data och databaser är information och databehandling kärnan i många affärsverksamheter och affärsbeslut. Tron på databasen är total. Ingen av de dagliga företagstjänsterna kan köras utan de underliggande databasplattformarna. Som en konsekvens är nödvändigheten av skalbarhet och prestanda för databassystemprogramvaran mer kritisk än någonsin. De huvudsakliga fördelarna med det klustrade databassystemet är skalbarhet och hög tillgänglighet. I den här bloggen kommer vi att försöka jämföra Oracle RAC och Galera Cluster i ljuset av dessa två aspekter. Real Application Clusters (RAC) är Oracles premiumlösning för klustring av Oracle-databaser och ger hög tillgänglighet och skalbarhet. Galera Cluster är den mest populära klustringstekniken för MySQL och MariaDB.

Arkitekturöversikt

Oracle RAC använder programvaran Oracle Clusterware för att binda flera servrar. Oracle Clusterware är en klusterhanteringslösning som är integrerad med Oracle Database, men den kan även användas med andra tjänster, inte bara databasen. Oracle Clusterware är en extra programvara installerad på servrar som kör samma operativsystem, vilket gör att servrarna kan kedjas samman för att fungera som om de vore en server.

Oracle Clusterware övervakar instansen och startar om den automatiskt om en krasch inträffar. Om din applikation är väldesignad kanske du inte upplever något avbrott i tjänsten. Endast en grupp sessioner (de som är anslutna till den misslyckade instansen) påverkas av felet. Blackouten kan effektivt maskeras för slutanvändaren med hjälp av avancerade RAC-funktioner som Fast Application Notification och Oracle-klientens Fast Connection Failover. Oracle Clusterware styr nodmedlemskap och förhindrar delade hjärnsymptom där två eller flera instanser försöker kontrollera instansen.

Galera Cluster är en synkron aktiv-aktiv databasklustringsteknologi för MySQL och MariaDB. Galera Cluster skiljer sig från det som kallas Oracles MySQL Cluster - NDB. MariaDB-klustret är baserat på multi-master replikeringsplugin som tillhandahålls av Codership. Sedan version 5.5 är Galera-pluginet (wsrep API) en integrerad del av MariaDB. Percona XtraDB Cluster (PXC) är också baserat på Galera-plugin. Galera plugin-arkitekturen står på tre kärnlager:certifiering, replikering och gruppkommunikationsramverk. Certifieringsskiktet förbereder skrivuppsättningarna och gör certifieringskontrollerna av dem, vilket garanterar att de kan tillämpas. Replikeringsskiktet hanterar replikeringsprotokollet och tillhandahåller den totala beställningskapaciteten. Group Communication Framework implementerar en plugin-arkitektur som tillåter andra system att ansluta via gcomm back-end-schema.

För att hålla tillståndet identiskt över hela klustret använder wsrep API ett globalt transaktions-ID. GTID unik identifierare skapas och associeras med varje transaktion som utförs på databasnoden. I Oracle RAC delar olika databasinstanser åtkomst till resurser som datablock i buffertcachen för att ställa datablock i kö. Tillgången till de delade resurserna mellan RAC-instanser måste samordnas för att undvika konflikter. För att organisera delad åtkomst till dessa resurser, upprätthåller den distribuerade cachen information som datablock-ID, vilken RAC-instans som har den aktuella versionen av detta datablock och låsläget där varje instans innehåller datablocket.

Nyckelkoncept för datalagring

Oracle RAC förlitar sig på en distribuerad diskarkitektur. Databasfilerna, kontrollfilerna och onlineloggarna för omställning av databasen måste vara tillgängliga för varje nod i klustret. Det finns en variation av sätt att konfigurera delad lagring, inklusive direktanslutna diskar, Storage Area Networks (SAN) och Network Attached Storage (NAS) och Oracle ASM. Två mest populära är OCFS och ASM. Oracle Cluster File System (OCFS) är ett delat filsystem designat specifikt för Oracle RAC. OCFS eliminerar kravet på att Oracle-databasfiler ska vara anslutna till logiska enheter och gör det möjligt för alla noder att dela en enda Oracle Home ASM, RAW-enhet. Oracle ASM är Oracles rekommenderade lagringshanteringslösning som ger ett alternativ till konventionella volymhanterare, filsystem och råa enheter. Oracle ASM tillhandahåller ett virtualiseringslager mellan databasen och lagringen. Den behandlar flera diskar som en enda diskgrupp och låter dig lägga till eller ta bort enheter dynamiskt samtidigt som databaser underhålls online.

Det finns inget behov av att bygga sofistikerad delad disklagring för Galera, eftersom varje nod har sin fullständiga kopia av data. Det är dock en god praxis att göra lagringen tillförlitlig med batteristödda skrivcacher.

Klusternodkommunikation och cache

Oracle Real Application Clusters har en delad cache-arkitektur, den använder Oracle Grid Infrastructure för att möjliggöra delning av server- och lagringsresurser. Kommunikation mellan noder är den kritiska aspekten av klusterintegritet. Varje nod måste ha minst två nätverkskort eller nätverkskort:ett för det offentliga nätverksgränssnittet och ett för sammankopplingen. Varje klusternod är ansluten till alla andra noder via ett privat höghastighetsnätverk, även känt som klustersammankopplingen.

Det privata nätverket bildas vanligtvis med Gigabit Ethernet, men för miljöer med hög volym erbjuder många leverantörer lösningar med låg latens och hög bandbredd designade för Oracle RAC. Linux utökar också ett sätt att sammanfoga flera fysiska nätverkskort till ett enda virtuellt nätverkskort för att ge ökad bandbredd och tillgänglighet.

Medan standardmetoden för att ansluta Galera-noder är att använda ett enda NIC per värd, kan du ha mer än ett kort. ClusterControl kan hjälpa dig med en sådan installation. Den största skillnaden är bandbreddskravet på sammankopplingen. Oracle RAC skickar datablock mellan instanser, så det lägger en tyngre belastning på sammankopplingen jämfört med Galera-skrivuppsättningar (som består av en lista med operationer).

Med Redundant Interconnect Usage i RAC kan du identifiera flera gränssnitt att använda för det privata klusternätverket, utan att behöva använda bindning eller annan teknik. Denna funktion är tillgänglig från och med Oracle Database 11gR2. Om du använder Oracle Clusterware-funktionen för överdriven sammankoppling måste du använda IPv4-adresser för gränssnitten (UDP är standard).

För att hantera hög tillgänglighet tilldelas varje klusternod en virtuell IP-adress (VIP). I händelse av nodfel kan den misslyckade nodens IP-adress omtilldelas till en överlevande nod för att tillåta applikationer att fortsätta nå databasen via samma IP-adress.

Sofistikerad nätverksinstallation är nödvändig för att Oracles Cache Fusion-teknik ska koppla ihop det fysiska minnet i varje värd till en enda cache. Oracle Cache Fusion tillhandahåller data som lagras i cachen för en Oracle-instans som kan nås av vilken annan instans som helst genom att transportera den över det privata nätverket. Det skyddar också dataintegritet och cachekoherens genom att överföra låsnings- och kompletterande synkroniseringsinformation bortom klusternoder.

Utöver den beskrivna nätverkskonfigurationen kan du ställa in en enda databasadress för din applikation - Single Client Access Name (SCAN). Det primära syftet med SCAN är att tillhandahålla enkel anslutningshantering. Du kan till exempel lägga till nya noder i klustret utan att ändra din klientanslutningssträng. Denna funktionalitet beror på att Oracle automatiskt distribuerar förfrågningar i enlighet därmed baserat på SCAN-IP:erna som pekar på de underliggande VIP:erna. Scan-lyssnare gör bryggan mellan klienter och de underliggande lokala lyssnarna som är VIP-beroende.

För Galera Cluster skulle motsvarigheten till SCAN vara att lägga till en databasproxy framför Galera-noderna. Proxyn skulle vara en enda kontaktpunkt för applikationer, den kan svartlista misslyckade noder och dirigera frågor till friska noder. Själva proxyn kan göras redundant med Keepalved och Virtual IP.

Failover och dataåterställning

Den största skillnaden mellan Oracle RAC och MySQL Galera Cluster är att Galera delas ingenting-arkitektur. Istället för delade diskar använder Galera certifieringsbaserad replikering med gruppkommunikation och transaktionsbeställning för att uppnå synkron replikering. Ett databaskluster bör kunna överleva en förlust av en nod, även om det uppnås på olika sätt. När det gäller Galera är den kritiska aspekten antalet noder, Galera kräver ett kvorum för att förbli i drift. Ett kluster med tre noder kan överleva kraschen av en nod. Med fler noder i ditt kluster kommer din tillgänglighet att växa. Oracle RAC kräver inte ett kvorum för att förbli i drift efter en nodkrasch. Det är på grund av tillgången till distribuerad lagring som håller konsekvent information om klustertillstånd. Din datalagring kan dock vara en potentiell felpunkt i din plan för hög tillgänglighet. Även om det är en ganska enkel uppgift att ha Galera-klusternoder spridda över geolokaliseringsdatacenter, skulle det inte vara så lätt med RAC. Oracle RAC kräver ytterligare avancerad diskspegling, men grundläggande RAID-liknande redundans kan uppnås i en ASM-diskgrupp.

Låsscheman

I en enanvändardatabas kan en användare ändra data utan oro för andra sessioner som ändrar samma data samtidigt. Men i en multi-användar databas multi-nod miljö, detta blir mer knepigt. En fleranvändardatabas måste tillhandahålla följande:

• datasamtidighet – försäkran om att användare kan komma åt data samtidigt,
• datakonsistens – försäkran om att varje användare ser en konsekvent bild av data.

Klusterinstanser kräver tre huvudtyper av samtidighetslåsning:

• Data samtidighet läser på olika instanser,
• Data samtidighet läser och skriver på olika instanser,
• Data samtidighet skriver på olika instanser.

Oracle låter dig välja policy för låsning, antingen pessimistisk eller optimistisk, beroende på dina krav. För att erhålla samtidighetslåsning har RAC två extra buffertar. De är Global Cache Service (GCS) och Global Enqueue Service (GES). Dessa två tjänster täcker Cache Fusion-processen, resursöverföringar och resurseskaleringar bland instanserna. GES inkluderar cachelås, ordbokslås, transaktionslås och tabelllås. GCS upprätthåller blocklägena och blocköverföringar mellan instanserna.

I Galera-klustret har varje nod sin lagring och sina buffertar. När en transaktion startas är databasresurser lokala för den noden involverade. Vid commit sänds de operationer som ingår i den transaktionen som en del av en skrivuppsättning, till resten av gruppen. Eftersom alla noder har samma tillstånd kommer skrivuppsättningen antingen att lyckas på alla noder eller så kommer den att misslyckas på alla noder.

Galera Cluster använder på klusternivå optimistisk samtidighetskontroll, som kan förekomma i transaktioner som leder till att en COMMIT avbryts. Den första commit vinner. När avbrott inträffar på klusternivå ger Galera Cluster ett dödlägesfel. Detta kan eller kanske inte påverkar din applikationsarkitektur. Högt antal rader att replikera i en enda transaktion skulle påverka nodsvar, även om det finns tekniker för att undvika sådant beteende.

Krav på maskinvara och programvara

Att konfigurera båda klustrens hårdvara kräver inga kraftfulla resurser. Minimal Oracle RAC-klusterkonfiguration skulle tillgodoses av två servrar med två processorer, fysiskt minne på minst 1,5 GB RAM, en mängd swap-utrymme lika med mängden RAM och två Gigabit Ethernet NIC. Galeras minsta nodkonfiguration är tre noder (en av noderna kan vara en skiljedomare, gardb), var och en med 1GHz enkelkärnig CPU 512MB RAM, 100 Mbps nätverkskort. Även om dessa är de minimala, kan vi lugnt säga att du i båda fallen förmodligen skulle vilja ha mer resurser för ditt produktionssystem.

Varje nod lagrar programvara så du skulle behöva förbereda flera gigabyte av din lagring. Oracle och Galera har båda möjligheten att individuellt patcha noderna genom att ta ner dem en i taget. Denna rullande patch undviker ett fullständigt programavbrott eftersom det alltid finns databasnoder tillgängliga för att hantera trafik.

Vad som är viktigt att nämna är att ett produktions-Galera-kluster enkelt kan köras på virtuella datorer eller grundläggande ren metall, medan RAC skulle behöva investeringar i sofistikerad delad lagring och fiberkommunikation.

Övervakning och hantering

Oracle Enterprise Manager är det favoritsätt som används för att övervaka Oracle RAC och Oracle Clusterware. Oracle Enterprise Manager är ett Oracle webbaserat enhetligt hanteringssystem för övervakning och administrering av din databasmiljö. Det är en del av Oracle Enterprise License och bör installeras på en separat server. Klusterkontrollövervakning och hantering görs via kombination på crsctl- och srvctl-kommandon som är en del av klusterbinärfiler. Nedan hittar du ett par exempel på kommandon.

Clusterware Resource Status Check:

    crsctl status resource -t (or shorter: crsctl stat res -t)

Exempel:

$ crsctl stat res ora.test1.vip
NAME=ora.test1.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=ONLINE on test1

Kontrollera statusen för Oracle Clusterware-stacken:

    crsctl check cluster

Exempel:

$ crsctl check cluster -all
*****************************************************************
node1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
*****************************************************************
node2:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Kontrollera statusen för Oracle High Availability Services och Oracle Clusterware-stacken på den lokala servern:

    crsctl check crs

Exempel:

$ crsctl check crs
CRS-4638: Oracle High Availablity Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Stoppa Oracle High Availability Services på den lokala servern.

    crsctl stop has

Stoppa Oracle High Availability Services på den lokala servern.

    crsctl start has

Visar status för nodapplikationer:

    srvctl status nodeapps

Visar konfigurationsinformation för alla SCAN VIPs

    srvctl config scan

Exempel:

srvctl config scan -scannumber 1
SCAN name: testscan, Network: 1
Subnet IPv4: 192.51.100.1/203.0.113.46/eth0, static
Subnet IPv6: 
SCAN 1 IPv4 VIP: 192.51.100.195
SCAN VIP is enabled.
SCAN VIP is individually enabled on nodes:
SCAN VIP is individually disabled on nodes:

Cluster Verification Utility (CVU) utför systemkontroller som förberedelse för installation, patchuppdateringar eller andra systemändringar:

    cluvfy comp ocr

Exempel:

Verifying OCR integrity
Checking OCR integrity...
Checking the absence of a non-clustered configurationl...
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc"...
OCR config file “/etc/oracle/ocr.loc" check successful
Disk group for ocr location “+DATA" available on all the nodes
NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck' as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

Galera-noder och klustret kräver att wsrep API rapporterar flera statusar, vilket är exponerat. Det finns för närvarande 34 dedikerade statusvariabler som kan ses med SHOW STATUS-satsen.

mysql> SHOW STATUS LIKE 'wsrep_%';

Administrationen av MySQL Galera Cluster är i många aspekter väldigt lik. Det finns bara några få undantag som att starta upp klustret från den initiala noden eller återställa noder via SST- eller IST-operationer.

Bootstrapping-kluster:

$ service mysql bootstrap # sysvinit
$ service mysql start --wsrep-new-cluster # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

Den motsvarande webbaserade lösningen för att hantera och övervaka Galera Cluster är ClusterControl. Det tillhandahåller ett webbaserat gränssnitt för att distribuera kluster, övervakar nyckeltal, tillhandahåller databasrådgivare och tar hand om hanteringsuppgifter som säkerhetskopiering och återställning, automatisk patchning, trafikkryptering och tillgänglighetshantering.

Begränsningar av arbetsbelastning

Oracle tillhandahåller SCAN-teknik som vi hittade saknas i Galera Cluster. Fördelen med SCAN är att klientens anslutningsinformation inte behöver ändras om du lägger till eller tar bort noder eller databaser i klustret. När du använder SCAN ansluter Oracle-databasen slumpmässigt till en av de tillgängliga SCAN-lyssnarna (vanligtvis tre) på ett round robin-sätt och balanserar kopplingarna mellan dem. Två typer av lastbalansering kan konfigureras:klientsida, belastningsbalansering för ansluten tid och på serversidan, körtidsbelastningsbalansering. Även om det inte finns något liknande inom själva Galera-klustret, kan samma funktionalitet hanteras med ytterligare programvara som ProxySQL, HAProxy, Maxscale kombinerat med Keepalved.

När det kommer till applikationsarbetsbelastningsdesign för Galera Cluster bör du undvika motstridiga uppdateringar på samma rad, eftersom det leder till dödlägen i klustret. Undvik massinlägg eller uppdateringar, eftersom dessa kan vara större än den maximalt tillåtna skrivuppsättningen. Det kan också orsaka klusterstopp.

När du designar Oracle HA med RAC måste du komma ihåg att RAC endast skyddar mot serverfel, och du måste spegla lagringen och ha nätverksredundans. Moderna webbapplikationer kräver åtkomst till platsoberoende datatjänster, och på grund av RAC:s lagringsarkitekturbegränsningar kan det vara svårt att uppnå. Du behöver också lägga en anmärkningsvärd tid på att skaffa relevant kunskap för att hantera miljön; det är en lång process. På applikationens arbetsbelastningssida finns det några nackdelar. Att distribuera separerade läs- eller skrivoperationer på samma datauppsättning är inte optimalt eftersom latens läggs till genom extra internoddatautbyte. Saker som partitionering, sekvenscache och sorteringsoperationer bör granskas innan du migrerar till RAC.

Redundans för flera datacenter

Enligt Oracle-dokumentationen kan det maximala avståndet mellan två boxar anslutna på ett punkt-till-punkt-sätt och som körs synkront endast vara 10 km. Med hjälp av specialiserade enheter kan detta avstånd ökas till 100 km.

Galera Cluster är välkänt för sina replikeringsmöjligheter för flera datacenter. Den har rikt stöd för Wider Area Networks nätverksinställningar. Den kan konfigureras för hög nätverkslatens genom att ta RTT-mätningar (Round-Trip Time) mellan klusternoder och justera nödvändiga parametrar. Parametrarna wsrep_provider_options låter dig konfigurera inställningar som suspect_timeout, interactive_timeout, join_retrans_timouts och många fler.

Använda Galera och RAC i molnet

Enligt Oracle-anteckning www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf uppfyller inget tredjepartsmoln för närvarande Oracles krav angående inbyggt delad lagring. "Native" i detta sammanhang betyder att molnleverantören måste stödja delad lagring som en del av sin infrastruktur enligt Oracles supportpolicy.

Tack vare dess delade ingenting-arkitektur, som inte är bunden till en sofistikerad lagringslösning, kan Galera-klustret enkelt distribueras i en molnmiljö. Saker som:

• optimerat nätverksprotokoll,
• topologimedveten replikering,
• trafikkryptering,
• detektering och automatisk eviction av opålitliga noder,

gör molnmigreringsprocessen mer tillförlitlig.

Licenser och dolda kostnader

Oracle-licensiering är ett komplext ämne och skulle kräva en separat bloggartikel. Klusterfaktorn gör det ännu svårare. Kostnaden ökar då vi måste lägga till några alternativ för att licensiera en komplett RAC-lösning. Här vill vi bara belysa vad vi kan förvänta oss och var du kan hitta mer information.

RAC är en funktion i Oracle Enterprise Edition-licensen. Oracle Enterprise-licensen är uppdelad i två typer, per namngiven användare och per processor. Om du överväger Enterprise Edition med per kärnlicens är kostnaden för en kärna RAC 23 000 USD + Oracle DB EE 47 500 USD, och du måste fortfarande lägga till en supportavgift på ~22 %. Vi skulle vilja hänvisa till en bra blogg om prissättning som finns på https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba beräknade priset på en Oracle RAC med fyra noder. Det totala beloppet var 902 400 USD plus ytterligare 595 584 USD för tre års DB-underhåll, och det inkluderar inte funktioner som partitionering eller minnesdatabas, allt det med 60 % Oracle-rabatt.

Galera Cluster är en öppen källkodslösning som alla kan köra gratis. Prenumerationer är tillgängliga för produktionsimplementeringar som kräver leverantörssupport. En bra TCO-beräkning finns på https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Slutsats

Även om det finns betydande skillnader i arkitektur, delar båda klustren huvudprinciperna och kan uppnå liknande mål. Oracle företagsprodukt kommer med allt ur kartongen (och dess pris). Med en kostnad i intervallet>1 M USD som ses ovan är det en avancerad lösning som många företag inte skulle ha råd med. Galera Cluster kan beskrivas som en anständig lösning med hög tillgänglighet för massorna. I vissa fall kan Galera mycket väl vara ett mycket bra alternativ till Oracle RAC. En nackdel är att du måste bygga din egen stack, även om det kan automatiseras helt med ClusterControl. Vi vill gärna höra dina tankar om detta.