Sammenligning af Oracle RAC HA-løsning med Galera Cluster til MySQL eller MariaDB

Virksomheden har hele tiden ønsket at udlede indsigt fra information for at træffe pålidelige, smartere, faktabaserede beslutninger i realtid. Da virksomheder er mere afhængige af data og databaser, er information og databehandling kernen i mange forretningsaktiviteter og forretningsbeslutninger. Troen på databasen er total. Ingen af ​​de daglige virksomhedstjenester kan køre uden de underliggende databaseplatforme. Som en konsekvens heraf er nødvendigheden af ​​skalerbarhed og ydeevne af databasesystemsoftware mere kritisk end nogensinde. De vigtigste fordele ved det klyngede databasesystem er skalerbarhed og høj tilgængelighed. I denne blog vil vi forsøge at sammenligne Oracle RAC og Galera Cluster i lyset af disse to aspekter. Real Application Clusters (RAC) er Oracles førsteklasses løsning til at klynge Oracle-databaser og giver høj tilgængelighed og skalerbarhed. Galera Cluster er den mest populære klyngeteknologi til MySQL og MariaDB.

Arkitekturoversigt

Oracle RAC bruger Oracle Clusterware-software til at binde flere servere. Oracle Clusterware er en klyngestyringsløsning, der er integreret med Oracle Database, men den kan også bruges med andre tjenester, ikke kun databasen. Oracle Clusterware er en ekstra software installeret på servere, der kører det samme operativsystem, som lader serverne kædes sammen for at fungere, som om de var én server.

Oracle Clusterware overvåger forekomsten og genstarter den automatisk, hvis der opstår et nedbrud. Hvis din applikation er godt designet, vil du muligvis ikke opleve nogen tjenesteafbrydelse. Kun en gruppe sessioner (dem, der er forbundet til den mislykkede instans) er berørt af fejlen. Blackoutet kan effektivt maskeres til slutbrugeren ved hjælp af avancerede RAC-funktioner som Fast Application Notification og Oracle-klientens Fast Connection Failover. Oracle Clusterware kontrollerer nodemedlemskab og forhindrer splitte hjernesymptomer, hvor to eller flere instanser forsøger at kontrollere instansen.

Galera Cluster er en synkron aktiv-aktiv databaseklyngeteknologi til MySQL og MariaDB. Galera Cluster adskiller sig fra det, der er kendt som Oracles MySQL Cluster - NDB. MariaDB-klyngen er baseret på multi-master-replikeringsplugin'et leveret af Codership. Siden version 5.5 er Galera-plugin'et (wsrep API) en integreret del af MariaDB. Percona XtraDB Cluster (PXC) er også baseret på Galera plugin. Galera plugin-arkitekturen står på tre kernelag:certificering, replikering og gruppekommunikationsramme. Certificeringslaget forbereder skrivesættene og udfører certificeringstjek på dem, hvilket garanterer, at de kan anvendes. Replikeringslaget styrer replikeringsprotokollen og giver den samlede bestillingskapacitet. Group Communication Framework implementerer en plugin-arkitektur, som gør det muligt for andre systemer at oprette forbindelse via gcomm backend-skema.

For at holde tilstanden identisk på tværs af klyngen bruger wsrep API et globalt transaktions-id. GTID unikke identifikator er oprettet og knyttet til hver transaktion begået på databasen noden. I Oracle RAC deler forskellige databaseinstanser adgang til ressourcer såsom datablokke i buffercachen for at sætte datablokke i kø. Adgang til de delte ressourcer mellem RAC-instanser skal koordineres for at undgå konflikt. For at organisere delt adgang til disse ressourcer vedligeholder den distribuerede cache information såsom datablok-id, hvilken RAC-instans der har den aktuelle version af denne datablok, og låsetilstanden, hvor hver instans indeholder datablokken.

Nøglekoncepter for datalagring

Oracle RAC er afhængig af en distribueret diskarkitektur. Databasefilerne, kontrolfilerne og online-redo-logfilerne for databasen skal være tilgængelige for hver node i klyngen. Der er en variation af måder at konfigurere delt lager på, herunder direkte tilsluttede diske, Storage Area Networks (SAN) og Network Attached Storage (NAS) og Oracle ASM. To mest populære er OCFS og ASM. Oracle Cluster File System (OCFS) er et delt filsystem designet specifikt til Oracle RAC. OCFS eliminerer kravet om, at Oracle-databasefiler skal forbindes til logiske drev og gør det muligt for alle noder at dele en enkelt Oracle Home ASM, RAW-enhed. Oracle ASM er Oracles anbefalede lagerstyringsløsning, der giver et alternativ til konventionelle volumenadministratorer, filsystemer og råenheder. Oracle ASM giver et virtualiseringslag mellem databasen og lageret. Den behandler flere diske som en enkelt diskgruppe og lader dig dynamisk tilføje eller fjerne drev, mens du vedligeholder databaser online.

Der er ingen grund til at bygge sofistikeret delt disklager til Galera, da hver node har sin fulde kopi af data. Det er dog en god praksis at gøre lagringen pålidelig med batteriunderstøttede skrivecaches.

Klyndeknudekommunikation og cache

Oracle Real Application Clusters har en delt cache-arkitektur, den bruger Oracle Grid Infrastructure til at muliggøre deling af server- og lagerressourcer. Kommunikation mellem noder er det kritiske aspekt af klyngeintegritet. Hver node skal have mindst to netværksadaptere eller netværkskort:en til den offentlige netværksgrænseflade og en til sammenkoblingen. Hver klynge node er forbundet med alle andre noder via et privat højhastighedsnetværk, også anerkendt som klynge sammenkoblingen.

Det private netværk er typisk dannet med Gigabit Ethernet, men til højvolumenmiljøer tilbyder mange leverandører løsninger med lav latens og høj båndbredde designet til Oracle RAC. Linux udvider også et middel til at forbinde flere fysiske NIC'er til et enkelt virtuelt NIC for at give øget båndbredde og tilgængelighed.

Mens standardtilgangen til at forbinde Galera-noder er at bruge et enkelt NIC pr. vært, kan du have mere end ét kort. ClusterControl kan hjælpe dig med en sådan opsætning. Den største forskel er båndbreddekravet på sammenkoblingen. Oracle RAC sender datablokke mellem instanser, så det lægger en større belastning på sammenkoblingen sammenlignet med Galera-skrivesæt (som består af en liste over operationer).

Med Redundant Interconnect Usage i RAC kan du identificere flere grænseflader til brug for det private klyngenetværk uden behov for at bruge bonding eller andre teknologier. Denne funktionalitet er tilgængelig fra og med Oracle Database 11gR2. Hvis du bruger Oracle Clusterware overdreven sammenkoblingsfunktion, skal du bruge IPv4-adresser til grænsefladerne (UDP er en standard).

For at administrere høj tilgængelighed tildeles hver klynge node en virtuel IP-adresse (VIP). I tilfælde af knudefejl kan den mislykkede knudes IP-adresse omtildeles til en overlevende knude for at tillade, at applikationer fortsætter med at nå databasen via den samme IP-adresse.

Sofistikeret netværksopsætning er nødvendig for at Oracles Cache Fusion-teknologi kan koble den fysiske hukommelse i hver vært til en enkelt cache. Oracle Cache Fusion leverer data, der er lagret i cachen på én Oracle-instans, som kan tilgås af enhver anden instans ved at transportere dem på tværs af det private netværk. Det beskytter også dataintegritet og cache-kohærens ved at transmittere låse- og supplerende synkroniseringsoplysninger ud over klyngeknudepunkter.

Oven i den beskrevne netværksopsætning kan du indstille en enkelt databaseadresse til din applikation - Single Client Access Name (SCAN). Det primære formål med SCAN er at give nem forbindelsesadministration. For eksempel kan du tilføje nye noder til klyngen uden at ændre din klientforbindelsesstreng. Denne funktionalitet skyldes, at Oracle automatisk vil distribuere anmodninger i overensstemmelse hermed baseret på SCAN-IP'erne, som peger på de underliggende VIP'er. Scan-lyttere danner broen mellem klienter og de underliggende lokale lyttere, som er VIP-afhængige.

For Galera Cluster ville det, der svarer til SCAN, være at tilføje en databaseproxy foran Galera-knuderne. Proxyen ville være et enkelt kontaktpunkt for applikationer, den kan sortliste mislykkede noder og dirigere forespørgsler til sunde noder. Selve proxyen kan gøres overflødig med Keepalved og Virtual IP.

Failover og datagendannelse

Den største forskel mellem Oracle RAC og MySQL Galera Cluster er, at Galera er delt ingenting-arkitektur. I stedet for delte diske bruger Galera certificeringsbaseret replikering med gruppekommunikation og transaktionsbestilling for at opnå synkron replikering. En databaseklynge bør kunne overleve et tab af en node, selvom det opnås på forskellige måder. I tilfælde af Galera er det kritiske aspekt antallet af noder, Galera kræver et kvorum for at forblive operationelt. En klynge med tre knudepunkter kan overleve sammenbruddet af en knude. Med flere noder i din klynge vil din tilgængelighed vokse. Oracle RAC kræver ikke et kvorum for at forblive operationelt efter et knudenedbrud. Det er på grund af adgangen til distribueret lager, der holder konsistente oplysninger om klyngetilstand. Din datalagring kan dog være et potentielt fejlpunkt i din plan med høj tilgængelighed. Selvom det er en rimelig ligetil opgave at have Galera-klyndeknuder spredt på tværs af geolokationsdatacentre, ville det ikke være så nemt med RAC. Oracle RAC kræver yderligere avanceret diskspejling, men grundlæggende RAID-lignende redundans kan opnås inde i en ASM-diskgruppe.

Låseskemaer

I en enkeltbrugerdatabase kan en bruger ændre data uden bekymring for andre sessioner, der ændrer de samme data på samme tid. Men i et multi-bruger database multi-node miljø bliver dette mere vanskeligt. En flerbrugerdatabase skal give følgende:

• data samtidighed - sikkerheden for, at brugere kan få adgang til data på samme tid,
• datakonsistens - forsikringen om, at hver bruger ser en ensartet visning af dataene.

Klyngeforekomster kræver tre hovedtyper af samtidighedslåsning:

• Data samtidighed læser på forskellige forekomster,
• Data samtidighed læser og skriver på forskellige forekomster,
• Data samtidighed skriver på forskellige forekomster.

Oracle lader dig vælge politikken for låsning, enten pessimistisk eller optimistisk, afhængigt af dine krav. For at opnå samtidighedslåsning har RAC to ekstra buffere. De er Global Cache Service (GCS) og Global Enqueue Service (GES). Disse to tjenester dækker Cache Fusion-processen, ressourceoverførsler og ressourceeskaleringer blandt instanserne. GES omfatter cachelåse, ordbogslåse, transaktionslåse og bordlåse. GCS vedligeholder bloktilstande og blokoverførsler mellem forekomsterne.

I Galera-klyngen har hver node sit lager og buffere. Når en transaktion startes, er databaseressourcer lokale for den node involveret. Ved commit udsendes de operationer, der er en del af denne transaktion, som en del af et skrivesæt til resten af ​​gruppen. Da alle noder har den samme tilstand, vil skrivesættet enten være vellykket på alle noder, eller det vil fejle på alle noder.

Galera Cluster bruger på klyngeniveau optimistisk samtidighedskontrol, som kan forekomme i transaktioner, der resulterer i en COMMIT-afbrydelse. Den første commit vinder. Når der sker afbrydelser på klyngeniveau, giver Galera Cluster en deadlock-fejl. Dette kan eller kan ikke påvirke din applikationsarkitektur. Et højt antal rækker, der skal replikeres i en enkelt transaktion, vil påvirke nodesvar, selvom der er teknikker til at undgå sådan adfærd.

Hardware- og softwarekrav

Konfiguration af begge klyngers hardware kræver ikke kraftige ressourcer. Minimal Oracle RAC-klyngekonfiguration ville blive tilfredsstillet af to servere med to CPU'er, fysisk hukommelse på mindst 1,5 GB RAM, en mængde swap-plads svarende til mængden af ​​RAM og to Gigabit Ethernet NIC'er. Galeras minimum nodekonfiguration er tre noder (en af ​​noderne kan være en voldgiftsdommer, gardb), hver med 1GHz single-core CPU 512MB RAM, 100 Mbps netværkskort. Selvom disse er de minimale, kan vi roligt sige, at du i begge tilfælde sandsynligvis gerne vil have flere ressourcer til dit produktionssystem.

Hver node gemmer software, så du skal forberede flere gigabyte af dit lager. Oracle og Galera har begge mulighed for individuelt at patche noderne ved at tage dem ned én ad gangen. Denne rullende patch undgår et komplet programafbrydelse, da der altid er databasenoder tilgængelige til at håndtere trafik.

Det, der er vigtigt at nævne, er, at en Galera-produktionsklynge nemt kan køre på VM'er eller basisk metal, mens RAC ville have brug for investering i sofistikeret delt lagring og fiberkommunikation.

Overvågning og styring

Oracle Enterprise Manager er den foretrukne tilgang til overvågning af Oracle RAC og Oracle Clusterware. Oracle Enterprise Manager er et Oracle webbaseret unified management system til overvågning og administration af dit databasemiljø. Det er en del af Oracle Enterprise License og bør installeres på en separat server. Klyngekontrolovervågning og -styring udføres via kombination på crsctl- og srvctl-kommandoer, som er en del af klyngebinære filer. Nedenfor kan du finde et par eksempler på kommandoer.

Kontrol af Clusterware-ressourcestatus:

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

Eksempel:

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

Tjek status for Oracle Clusterware-stakken:

    crsctl check cluster

Eksempel:

$ 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

Tjek status for Oracle High Availability Services og Oracle Clusterware-stakken på den lokale server:

    crsctl check crs

Eksempel:

$ 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

Stop Oracle High Availability Services på den lokale server.

    crsctl stop has

Stop Oracle High Availability Services på den lokale server.

    crsctl start has

Viser status for nodeapplikationer:

    srvctl status nodeapps

Viser konfigurationsoplysningerne for alle SCAN VIP'er

    srvctl config scan

Eksempel:

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) udfører systemtjek som forberedelse til installation, patchopdateringer eller andre systemændringer:

    cluvfy comp ocr

Eksempel:

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 og klyngen kræver, at wsrep-API'en rapporterer flere statusser, som er afsløret. Der er i øjeblikket 34 dedikerede statusvariabler, der kan ses med VIS STATUS-erklæring.

mysql> SHOW STATUS LIKE 'wsrep_%';

Administrationen af ​​MySQL Galera Cluster er i mange aspekter meget ens. Der er kun få undtagelser som bootstrapping af klyngen fra den oprindelige node eller gendannelse af noder via SST- eller IST-operationer.

Bootstrapping-klynge:

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

Den tilsvarende webbaserede, ud af boksen løsning til at administrere og overvåge Galera Cluster er ClusterControl. Det giver en webbaseret grænseflade til at implementere klynger, overvåger nøglemålinger, leverer databaserådgivere og tager sig af administrationsopgaver som backup og gendannelse, automatisk patching, trafikkryptering og tilgængelighedsstyring.

Begrænsninger for arbejdsbyrde

Oracle leverer SCAN-teknologi, som vi fandt mangler i Galera Cluster. Fordelen ved SCAN er, at klientens forbindelsesoplysninger ikke behøver at ændres, hvis du tilføjer eller fjerner noder eller databaser i klyngen. Når du bruger SCAN, forbinder Oracle-databasen tilfældigt til en af ​​de tilgængelige SCAN-lyttere (typisk tre) på en round robin-måde og afbalancerer forbindelserne mellem dem. Der kan konfigureres to slags belastningsbalancering:klientside, tilslutningstid belastningsbalancering og på serversiden, køretidsbelastningsbalancering. Selvom der ikke er noget lignende i selve Galera-klyngen, kan den samme funktionalitet løses med yderligere software som ProxySQL, HAProxy, Maxscale kombineret med Keepalved.

Når det kommer til design af applikationsbelastning for Galera Cluster, bør du undgå modstridende opdateringer på samme række, da det fører til dødvande på tværs af klyngen. Undgå masseindsættelser eller opdateringer, da disse kan være større end det maksimalt tilladte skrivesæt. Det kan også forårsage klyngestop.

Når du designer Oracle HA med RAC, skal du huske på, at RAC kun beskytter mod serverfejl, og du skal spejle lageret og have netværksredundans. Moderne webapplikationer kræver adgang til lokationsuafhængige datatjenester, og på grund af RACs lagerarkitekturbegrænsninger kan det være vanskeligt at opnå. Du skal også bruge en bemærkelsesværdig mængde tid på at få relevant viden til at styre miljøet; det er en lang proces. På applikationsarbejdsbelastningssiden er der nogle ulemper. At distribuere adskilte læse- eller skriveoperationer på det samme datasæt er ikke optimalt, fordi latency tilføjes ved supplerende internode-dataudveksling. Ting som partitionering, sekvenscache og sorteringsoperationer bør gennemgås før migrering til RAC.

Multidatacenterredundans

Ifølge Oracle-dokumentationen kan den maksimale afstand mellem to bokse, der er forbundet på en punkt-til-punkt måde og køre synkront, kun være 10 km. Ved hjælp af specialiserede enheder kan denne afstand øges til 100 km.

Galera Cluster er kendt for sine multi-datacenter-replikeringsmuligheder. Det har rig understøttelse af Wider Area Networks netværksindstillinger. Den kan konfigureres til høj netværksforsinkelse ved at tage RTT-målinger (Round-Trip Time) mellem klyngeknuder og justere nødvendige parametre. Parametrene wsrep_provider_options giver dig mulighed for at konfigurere indstillinger som suspect_timeout, interactive_timeout, join_retrans_timouts og mange flere.

Brug af Galera og RAC i Cloud

I henhold til Oracle-note www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf opfylder ingen tredjepartssky i øjeblikket Oracles krav vedrørende indbygget delt lagring. "Native" betyder i denne sammenhæng, at cloud-udbyderen skal understøtte delt lagring som en del af deres infrastruktur i henhold til Oracles supportpolitik.

Takket være dens delte ingenting-arkitektur, som ikke er bundet til en sofistikeret lagringsløsning, kan Galera-klyngen nemt implementeres i et cloudmiljø. Ting som:

• optimeret netværksprotokol,
• topologi-bevidst replikering,
• trafikkryptering,
• detektering og automatisk udsættelse af upålidelige noder,

gør cloud-migreringsprocessen mere pålidelig.

Licenser og skjulte omkostninger

Oracle-licenser er et komplekst emne og vil kræve en separat blogartikel. Klyngefaktoren gør det endnu sværere. Omkostningerne stiger, da vi er nødt til at tilføje nogle muligheder for at licensere en komplet RAC-løsning. Her vil vi blot fremhæve, hvad man kan forvente, og hvor man kan finde mere information.

RAC er en funktion i Oracle Enterprise Edition-licensen. Oracle Enterprise-licensen er opdelt i to typer, pr. navngiven bruger og pr. processor. Hvis du overvejer Enterprise Edition med per kerne-licens, så er den enkelte kerne-pris RAC 23.000 USD + Oracle DB EE 47.500 USD, og ​​du skal stadig tilføje et supportgebyr på ~22 %. Vi vil gerne henvise til en fantastisk blog om priser fundet på https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba beregnede prisen på en Oracle RAC med fire noder. Det samlede beløb var 902.400 USD plus yderligere 595.584 USD for tre års DB-vedligeholdelse, og det inkluderer ikke funktioner som partitionering eller in-memory database, alt det med 60 % Oracle-rabat.

Galera Cluster er en open source-løsning, som alle kan køre gratis. Abonnementer er tilgængelige for produktionsimplementeringer, der kræver leverandørsupport. En god TCO-beregning kan findes på https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Konklusion

Selvom der er betydelige forskelle i arkitektur, deler begge klynger hovedprincipperne og kan opnå lignende mål. Oracle enterprise-produkt kommer med alt ud af æsken (og det er prisen). Med en omkostning i størrelsesordenen>1 mio. USD som set ovenfor, er det en avanceret løsning, som mange virksomheder ikke ville have råd til. Galera Cluster kan beskrives som en anstændig høj tilgængelighedsløsning for masserne. I visse tilfælde kan Galera meget vel være et meget godt alternativ til Oracle RAC. En ulempe er, at du skal bygge din egen stak, selvom det kan automatiseres fuldstændigt med ClusterControl. Vi vil meget gerne høre dine tanker om dette.