Vergleich der Oracle RAC HA-Lösung mit Galera Cluster für MySQL oder MariaDB

Die Wirtschaft hat sich immer gewünscht, Erkenntnisse aus Informationen abzuleiten, um zuverlässige, intelligentere, faktenbasierte Entscheidungen in Echtzeit zu treffen. Da sich Unternehmen immer mehr auf Daten und Datenbanken verlassen, sind Informationen und Datenverarbeitung der Kern vieler Geschäftsvorgänge und Geschäftsentscheidungen. Das Vertrauen in die Datenbank ist total. Keiner der täglichen Unternehmensdienste kann ohne die zugrunde liegenden Datenbankplattformen ausgeführt werden. Infolgedessen ist die Notwendigkeit der Skalierbarkeit und Leistung von Datenbanksystemsoftware wichtiger denn je. Die Hauptvorteile des geclusterten Datenbanksystems sind Skalierbarkeit und Hochverfügbarkeit. In diesem Blog werden wir versuchen, Oracle RAC und Galera Cluster im Lichte dieser beiden Aspekte zu vergleichen. Real Application Clusters (RAC) ist die Premium-Lösung von Oracle zum Clustern von Oracle-Datenbanken und bietet Hochverfügbarkeit und Skalierbarkeit. Galera Cluster ist die beliebteste Clustering-Technologie für MySQL und MariaDB.

Architekturübersicht

Oracle RAC verwendet Oracle Clusterware-Software, um mehrere Server zu binden. Oracle Clusterware ist eine Cluster-Management-Lösung, die in Oracle Database integriert ist, aber auch mit anderen Diensten verwendet werden kann, nicht nur mit der Datenbank. Die Oracle Clusterware ist eine zusätzliche Software, die auf Servern mit demselben Betriebssystem installiert wird, wodurch die Server miteinander verkettet werden können, um so zu arbeiten, als wären sie ein Server.

Oracle Clusterware überwacht die Instanz und startet sie automatisch neu, wenn ein Absturz auftritt. Wenn Ihre Anwendung gut gestaltet ist, treten möglicherweise keine Dienstunterbrechungen auf. Nur eine Gruppe von Sitzungen (die mit der ausgefallenen Instanz verbunden sind) ist von dem Ausfall betroffen. Der Stromausfall kann dem Endbenutzer mit erweiterten RAC-Funktionen wie Fast Application Notification und dem Fast Connection Failover des Oracle-Clients effizient maskiert werden. Oracle Clusterware kontrolliert die Node-Mitgliedschaft und verhindert Split-Brain-Symptome, bei denen zwei oder mehr Instanzen versuchen, die Instanz zu kontrollieren.

Galera Cluster ist eine synchrone Aktiv-Aktiv-Datenbank-Clustering-Technologie für MySQL und MariaDB. Galera Cluster unterscheidet sich vom sogenannten MySQL Cluster – NDB von Oracle. Der MariaDB-Cluster basiert auf dem von Codership bereitgestellten Multi-Master-Replikations-Plugin. Seit Version 5.5 ist das Galera-Plugin (wsrep API) fester Bestandteil von MariaDB. Percona XtraDB Cluster (PXC) basiert ebenfalls auf dem Galera-Plugin. Die Galera-Plug-in-Architektur basiert auf drei Kernebenen:Zertifizierung, Replikation und Gruppenkommunikations-Framework. Die Zertifizierungsschicht bereitet die Schreibsätze vor und führt die Zertifizierungsprüfungen an ihnen durch, um sicherzustellen, dass sie angewendet werden können. Die Replikationsschicht verwaltet das Replikationsprotokoll und stellt die gesamte Bestellfunktion bereit. Group Communication Framework implementiert eine Plugin-Architektur, die es anderen Systemen ermöglicht, sich über das gcomm-Back-End-Schema zu verbinden.

Um den Status im gesamten Cluster identisch zu halten, verwendet die wsrep-API eine globale Transaktions-ID. Eindeutiger GTID-Identifizierer wird erstellt und jeder Transaktion zugeordnet, die auf dem Datenbankknoten festgeschrieben wird. In Oracle RAC teilen sich verschiedene Datenbankinstanzen den Zugriff auf Ressourcen wie Datenblöcke im Puffercache, um Datenblöcke in die Warteschlange einzureihen. Der Zugriff auf die gemeinsam genutzten Ressourcen zwischen RAC-Instanzen muss koordiniert werden, um Konflikte zu vermeiden. Um den gemeinsamen Zugriff auf diese Ressourcen zu organisieren, verwaltet der verteilte Cache Informationen wie die Datenblock-ID, welche RAC-Instanz die aktuelle Version dieses Datenblocks enthält und den Sperrmodus, in dem jede Instanz den Datenblock enthält.

Schlüsselkonzepte der Datenspeicherung

Oracle RAC basiert auf einer verteilten Festplattenarchitektur. Die Datenbankdateien, Steuerdateien und Online-Redo-Protokolle für die Datenbank müssen für jeden Knoten im Cluster zugänglich sein. Es gibt verschiedene Möglichkeiten, gemeinsam genutzten Speicher zu konfigurieren, einschließlich direkt angeschlossener Festplatten, Storage Area Networks (SAN) und Network Attached Storage (NAS) und Oracle ASM. Die zwei beliebtesten sind OCFS und ASM. Oracle Cluster File System (OCFS) ist ein gemeinsam genutztes Dateisystem, das speziell für Oracle RAC entwickelt wurde. OCFS eliminiert die Anforderung, dass Oracle-Datenbankdateien mit logischen Laufwerken verbunden werden müssen, und ermöglicht es allen Knoten, ein einzelnes Oracle Home ASM, RAW Device, gemeinsam zu nutzen. Oracle ASM ist die von Oracle empfohlene Speicherverwaltungslösung, die eine Alternative zu herkömmlichen Volume-Managern, Dateisystemen und Raw-Geräten bietet. Das Oracle ASM stellt eine Virtualisierungsschicht zwischen der Datenbank und dem Speicher bereit. Es behandelt mehrere Laufwerke als eine einzige Laufwerksgruppe und ermöglicht Ihnen das dynamische Hinzufügen oder Entfernen von Laufwerken, während Datenbanken online bleiben.

Es besteht keine Notwendigkeit, für Galera einen ausgeklügelten gemeinsam genutzten Plattenspeicher zu erstellen, da jeder Knoten über seine vollständige Kopie der Daten verfügt. Es empfiehlt sich jedoch, den Speicher mit batteriegestützten Schreibcaches zuverlässig zu machen.

Cluster-Knoten-Kommunikation und Cache

Oracle Real Application Clusters verfügt über eine gemeinsam genutzte Cache-Architektur und nutzt die Oracle Grid-Infrastruktur, um die gemeinsame Nutzung von Server- und Speicherressourcen zu ermöglichen. Die Kommunikation zwischen Knoten ist der entscheidende Aspekt der Clusterintegrität. Jeder Knoten muss über mindestens zwei Netzwerkadapter oder Netzwerkschnittstellenkarten verfügen:eine für die öffentliche Netzwerkschnittstelle und eine für die Verbindung. Jeder Clusterknoten ist mit allen anderen Knoten über ein privates Hochgeschwindigkeitsnetzwerk verbunden, das auch als Clusterverbindung bezeichnet wird.

Das private Netzwerk wird normalerweise mit Gigabit-Ethernet gebildet, aber für Umgebungen mit hohem Volumen bieten viele Anbieter Lösungen mit geringer Latenz und hoher Bandbreite an, die für Oracle RAC entwickelt wurden. Linux erweitert auch die Möglichkeit, mehrere physische NICs zu einer einzigen virtuellen NIC zu verbinden, um eine erhöhte Bandbreite und Verfügbarkeit bereitzustellen.

Während der Standardansatz zum Verbinden von Galera-Knoten darin besteht, eine einzelne NIC pro Host zu verwenden, können Sie mehr als eine Karte haben. ClusterControl kann Sie bei einer solchen Einrichtung unterstützen. Der Hauptunterschied besteht in der Bandbreitenanforderung auf der Verbindung. Oracle RAC verschickt Datenblöcke zwischen Instanzen, sodass die Verbindung stärker belastet wird als die Write-Sets von Galera (die aus einer Liste von Operationen bestehen).

Mit Redundant Interconnect Usage in RAC können Sie mehrere Schnittstellen zur Verwendung für das private Cluster-Netzwerk identifizieren, ohne Bonding oder andere Technologien verwenden zu müssen. Diese Funktionalität ist ab Oracle Database 11gR2 verfügbar. Wenn Sie die Excessive Interconnect-Funktion von Oracle Clusterware verwenden, müssen Sie IPv4-Adressen für die Schnittstellen verwenden (UDP ist eine Standardeinstellung).

Zur Verwaltung der Hochverfügbarkeit wird jedem Cluster-Knoten eine virtuelle IP-Adresse (VIP) zugewiesen. Im Falle eines Knotenausfalls kann die IP-Adresse des ausgefallenen Knotens einem überlebenden Knoten neu zugewiesen werden, damit Anwendungen die Datenbank weiterhin über dieselbe IP-Adresse erreichen können.

Für die Cache-Fusion-Technologie von Oracle ist eine ausgeklügelte Netzwerkeinrichtung erforderlich, um den physischen Speicher in jedem Host in einem einzigen Cache zu koppeln. Oracle Cache Fusion stellt im Cache einer Oracle-Instanz gespeicherte Daten bereit, auf die von jeder anderen Instanz zugegriffen werden kann, indem sie über das private Netzwerk transportiert werden. Es schützt auch die Datenintegrität und Cache-Kohärenz, indem Sperr- und zusätzliche Synchronisationsinformationen über Cluster-Knoten hinaus übertragen werden.

Zusätzlich zu der beschriebenen Netzwerkeinrichtung können Sie eine einzelne Datenbankadresse für Ihre Anwendung festlegen – Single Client Access Name (SCAN). Der Hauptzweck von SCAN besteht darin, eine einfache Verbindungsverwaltung bereitzustellen. Beispielsweise können Sie dem Cluster neue Knoten hinzufügen, ohne Ihre Client-Verbindungszeichenfolge zu ändern. Diese Funktionalität liegt daran, dass Oracle Anfragen automatisch entsprechend basierend auf den SCAN-IPs verteilt, die auf die zugrunde liegenden VIPs verweisen. Scan-Listener bilden die Brücke zwischen Clients und den zugrunde liegenden lokalen Listenern, die VIP-abhängig sind.

Für Galera Cluster wäre das Äquivalent von SCAN das Hinzufügen eines Datenbank-Proxy vor den Galera-Knoten. Der Proxy wäre ein einziger Kontaktpunkt für Anwendungen, er kann ausgefallene Knoten auf die schwarze Liste setzen und Anfragen an fehlerfreie Knoten weiterleiten. Der Proxy selbst kann mit Keepalived und Virtual IP redundant gemacht werden.

Failover und Datenwiederherstellung

Der Hauptunterschied zwischen Oracle RAC und MySQL Galera Cluster besteht darin, dass Galera eine Shared-Nothing-Architektur ist. Anstelle gemeinsam genutzter Festplatten verwendet Galera eine zertifizierungsbasierte Replikation mit Gruppenkommunikation und Transaktionsreihenfolge, um eine synchrone Replikation zu erreichen. Ein Datenbank-Cluster sollte in der Lage sein, den Verlust eines Knotens zu überstehen, obwohl dies auf unterschiedliche Weise erreicht wird. Im Fall von Galera ist der kritische Aspekt die Anzahl der Knoten, Galera benötigt ein Quorum, um betriebsbereit zu bleiben. Ein Cluster mit drei Knoten kann den Absturz eines Knotens überleben. Mit mehr Knoten in Ihrem Cluster wächst Ihre Verfügbarkeit. Oracle RAC benötigt kein Quorum, um nach einem Knotenabsturz betriebsbereit zu bleiben. Dies liegt am Zugriff auf den verteilten Speicher, der konsistente Informationen über den Clusterstatus bereitstellt. Ihr Datenspeicher könnte jedoch ein potenzieller Fehlerpunkt in Ihrem Hochverfügbarkeitsplan sein. Während es eine ziemlich einfache Aufgabe ist, Galera-Cluster-Knoten über Geolokalisierungs-Rechenzentren zu verteilen, wäre es mit RAC nicht so einfach. Oracle RAC erfordert zusätzliche High-End-Datenträgerspiegelung, jedoch kann grundlegende RAID-ähnliche Redundanz innerhalb einer ASM-Datenträgergruppe erreicht werden.

Schließschemata

In einer Einzelbenutzerdatenbank kann ein Benutzer Daten ändern, ohne Rücksicht darauf zu nehmen, dass andere Sitzungen dieselben Daten zur gleichen Zeit ändern. In einer Mehrbenutzer-Datenbankumgebung mit mehreren Knoten wird dies jedoch schwieriger. Eine Mehrbenutzerdatenbank muss Folgendes bereitstellen:

• Datenparallelität – die Zusicherung, dass Benutzer gleichzeitig auf Daten zugreifen können,
• Datenkonsistenz – die Gewissheit, dass jeder Benutzer eine konsistente Ansicht der Daten sieht.

Clusterinstanzen erfordern drei Haupttypen von Parallelitätssperren:

• Gleichzeitiges Lesen von Daten auf verschiedenen Instanzen
• Gleichzeitiges Lesen und Schreiben von Daten auf verschiedenen Instanzen
• Gleichzeitiges Schreiben von Daten auf verschiedenen Instanzen.

Oracle lässt Sie die Richtlinie für das Sperren auswählen, entweder pessimistisch oder optimistisch, je nach Ihren Anforderungen. Um Parallelitätssperre zu erhalten, hat RAC zwei zusätzliche Puffer. Sie sind Global Cache Service (GCS) und Global Enqueue Service (GES). Diese beiden Dienste decken den Cache Fusion-Prozess, Ressourcenübertragungen und Ressourceneskalationen zwischen den Instanzen ab. GES umfassen Cache-Sperren, Wörterbuchsperren, Transaktionssperren und Tabellensperren. GCS verwaltet die Blockmodi und Blockübertragungen zwischen den Instanzen.

Im Galera-Cluster hat jeder Knoten seinen Speicher und seine Puffer. Wenn eine Transaktion gestartet wird, sind lokale Datenbankressourcen für diesen Knoten beteiligt. Beim Festschreiben werden die Operationen, die Teil dieser Transaktion sind, als Teil eines Schreibsatzes an den Rest der Gruppe gesendet. Da alle Knoten den gleichen Zustand haben, wird der Write-Set entweder auf allen Knoten erfolgreich sein oder auf allen Knoten fehlschlagen.

Galera Cluster verwendet auf Clusterebene eine optimistische Nebenläufigkeitskontrolle, die in Transaktionen auftreten kann, die zu einem COMMIT-Abbruch führen. Der erste Commit gewinnt. Wenn Abbrüche auf Cluster-Ebene auftreten, gibt Galera Cluster einen Deadlock-Fehler aus. Dies kann sich auf Ihre Anwendungsarchitektur auswirken oder auch nicht. Eine hohe Anzahl von Zeilen, die in einer einzelnen Transaktion repliziert werden müssen, würde sich auf die Antworten der Knoten auswirken, obwohl es Techniken gibt, um ein solches Verhalten zu vermeiden.

Hardware- und Softwareanforderungen

Die Konfiguration beider Cluster-Hardware erfordert keine starken Ressourcen. Die minimale Oracle RAC-Clusterkonfiguration würde durch zwei Server mit zwei CPUs, physischem Speicher von mindestens 1,5 GB RAM, einer Menge an Auslagerungsspeicher gleich der Menge an RAM und zwei Gigabit-Ethernet-NICs erfüllt. Die minimale Knotenkonfiguration von Galera besteht aus drei Knoten (einer der Knoten kann ein Vermittler sein, gardb), jeder mit 1 GHz Single-Core-CPU, 512 MB RAM, 100 Mbit/s Netzwerkkarte. Obwohl dies das Minimum ist, können wir mit Sicherheit sagen, dass Sie in beiden Fällen wahrscheinlich mehr Ressourcen für Ihr Produktionssystem haben möchten.

Jeder Knoten speichert Software, sodass Sie mehrere Gigabyte Ihres Speichers vorbereiten müssten. Oracle und Galera haben beide die Möglichkeit, die Knoten einzeln zu patchen, indem sie einzeln heruntergefahren werden. Dieser fortlaufende Patch vermeidet einen vollständigen Anwendungsausfall, da immer Datenbankknoten verfügbar sind, um den Datenverkehr zu verarbeiten.

Wichtig zu erwähnen ist, dass ein Produktions-Cluster von Galera problemlos auf VMs oder einfachem Bare-Metal ausgeführt werden kann, während RAC Investitionen in anspruchsvolle gemeinsam genutzte Speicher und Glasfaserkommunikation erfordern würde.

Überwachung und Verwaltung

Oracle Enterprise Manager ist der bevorzugte Ansatz zur Überwachung von Oracle RAC und Oracle Clusterware. Oracle Enterprise Manager ist ein webbasiertes einheitliches Verwaltungssystem von Oracle zur Überwachung und Verwaltung Ihrer Datenbankumgebung. Es ist Teil der Oracle Enterprise-Lizenz und sollte auf einem separaten Server installiert werden. Die Überwachung und Verwaltung der Clustersteuerung erfolgt über die Kombination der crsctl- und srvctl-Befehle, die Teil der Cluster-Binärdateien sind. Nachfolgend finden Sie einige Beispielbefehle.

Prüfung des Clusterware-Ressourcenstatus:

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

Beispiel:

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

Überprüfen Sie den Status des Oracle Clusterware-Stacks:

    crsctl check cluster

Beispiel:

$ 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

Überprüfen Sie den Status von Oracle High Availability Services und dem Oracle Clusterware-Stack auf dem lokalen Server:

    crsctl check crs

Beispiel:

$ 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

Beenden Sie Oracle High Availability Services auf dem lokalen Server.

    crsctl stop has

Beenden Sie Oracle High Availability Services auf dem lokalen Server.

    crsctl start has

Zeigt den Status von Knotenanwendungen an:

    srvctl status nodeapps

Zeigt die Konfigurationsinformationen für alle SCAN-VIPs an

    srvctl config scan

Beispiel:

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:

Das Cluster Verification Utility (CVU) führt Systemprüfungen in Vorbereitung auf die Installation, Patch-Updates oder andere Systemänderungen durch:

    cluvfy comp ocr

Beispiel:

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-Knoten und der Cluster erfordern, dass die wsrep-API mehrere Status meldet, die offengelegt werden. Es gibt derzeit 34 dedizierte Statusvariablen, die mit der SHOW STATUS-Anweisung angezeigt werden können.

mysql> SHOW STATUS LIKE 'wsrep_%';

Die Administration von MySQL Galera Cluster ist in vielen Aspekten sehr ähnlich. Es gibt nur wenige Ausnahmen wie das Bootstrapping des Clusters vom ursprünglichen Knoten oder das Wiederherstellen von Knoten über SST- oder IST-Operationen.

Bootstrapping-Cluster:

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

Die gleichwertige webbasierte, sofort einsatzbereite Lösung zur Verwaltung und Überwachung von Galera Cluster ist ClusterControl. Es bietet eine webbasierte Schnittstelle zum Bereitstellen von Clustern, überwacht Schlüsselmetriken, stellt Datenbankberater bereit und kümmert sich um Verwaltungsaufgaben wie Sicherung und Wiederherstellung, automatisches Patchen, Datenverkehrsverschlüsselung und Verfügbarkeitsverwaltung.

Einschränkungen der Arbeitsbelastung

Oracle stellt SCAN-Technologie zur Verfügung, die wir im Galera-Cluster vermisst haben. Der Vorteil von SCAN besteht darin, dass die Verbindungsinformationen des Clients nicht geändert werden müssen, wenn Sie Knoten oder Datenbanken im Cluster hinzufügen oder entfernen. Bei der Verwendung von SCAN verbindet sich die Oracle-Datenbank nach dem Zufallsprinzip mit einem der verfügbaren SCAN-Listener (normalerweise drei) im Round-Robin-Verfahren und gleicht die Verbindungen zwischen ihnen aus. Es können zwei Arten von Load Balancing konfiguriert werden:clientseitig Load Balancing zur Verbindungszeit und serverseitig Load Balancing zur Laufzeit. Obwohl es innerhalb des Galera-Clusters selbst nichts Vergleichbares gibt, kann die gleiche Funktionalität mit zusätzlicher Software wie ProxySQL, HAProxy, Maxscale in Kombination mit Keepalived erreicht werden.

Wenn es um das Anwendungs-Workload-Design für Galera Cluster geht, sollten Sie widersprüchliche Aktualisierungen in derselben Zeile vermeiden, da dies zu Blockaden im gesamten Cluster führt. Vermeiden Sie Masseneinfügungen oder -aktualisierungen, da diese möglicherweise größer als der maximal zulässige Writeset sind. Das kann auch Cluster-Stalls verursachen.

Beim Entwerfen von Oracle HA mit RAC müssen Sie bedenken, dass RAC nur vor Serverausfällen schützt und Sie den Speicher spiegeln und über Netzwerkredundanz verfügen müssen. Moderne Webanwendungen erfordern Zugriff auf standortunabhängige Datendienste, und aufgrund der Einschränkungen der Speicherarchitektur von RAC kann dies schwierig zu erreichen sein. Sie müssen auch viel Zeit aufwenden, um sich relevante Kenntnisse zum Management der Umgebung anzueignen; es ist ein langer Prozess. Auf der Anwendungs-Workload-Seite gibt es einige Nachteile. Das Verteilen getrennter Lese- oder Schreiboperationen auf demselben Datensatz ist nicht optimal, da Latenz durch zusätzlichen Datenaustausch zwischen den Knoten hinzugefügt wird. Dinge wie Partitionierung, Sequenz-Cache und Sortiervorgänge sollten vor der Migration zu RAC überprüft werden.

Multi-Rechenzentrum-Redundanz

Laut Oracle-Dokumentation darf die maximale Entfernung zwischen zwei Punkt-zu-Punkt-Verbindungen, die synchron laufen, nur 10 km betragen. Mit speziellen Geräten kann diese Distanz auf 100 km erhöht werden.

Galera Cluster ist bekannt für seine Replikationsfunktionen für mehrere Rechenzentren. Es bietet umfassende Unterstützung für die Netzwerkeinstellungen von Wide Area Networks. Es kann für eine hohe Netzwerklatenz konfiguriert werden, indem Messungen der Round-Trip-Zeit (RTT) zwischen Cluster-Knoten durchgeführt und die erforderlichen Parameter angepasst werden. Mit den wsrep_provider_options-Parametern können Sie Einstellungen wie „suspekt_timeout“, „interactive_timeout“, „join_retrans_timouts“ und viele mehr konfigurieren.

Verwendung von Galera und RAC in der Cloud

Laut Oracle-Hinweis www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf erfüllt derzeit keine Drittanbieter-Cloud die Anforderungen von Oracle in Bezug auf nativ bereitgestellten gemeinsam genutzten Speicher. „Nativ“ bedeutet in diesem Zusammenhang, dass der Cloud-Anbieter Shared Storage als Teil seiner Infrastruktur gemäß der Support-Richtlinie von Oracle unterstützen muss.

Dank seiner Shared-Nothing-Architektur, die nicht an eine ausgeklügelte Speicherlösung gebunden ist, kann der Galera-Cluster problemlos in einer Cloud-Umgebung bereitgestellt werden. Dinge wie:

• optimiertes Netzwerkprotokoll,
• topologiebewusste Replikation,
• Verkehrsverschlüsselung,
• Erkennung und automatische Entfernung unzuverlässiger Knoten,

macht den Cloud-Migrationsprozess zuverlässiger.

Lizenzen und versteckte Kosten

Die Oracle-Lizenzierung ist ein komplexes Thema und würde einen separaten Blog-Artikel erfordern. Der Clusterfaktor macht es noch schwieriger. Die Kosten steigen, da wir einige Optionen hinzufügen müssen, um eine vollständige RAC-Lösung zu lizenzieren. Hier möchten wir nur hervorheben, was Sie erwartet und wo Sie weitere Informationen finden.

RAC ist eine Funktion der Oracle Enterprise Edition-Lizenz. Die Oracle Enterprise-Lizenz ist in zwei Typen unterteilt, pro Named User und pro Prozessor. Wenn Sie die Enterprise Edition mit Pro-Core-Lizenz in Betracht ziehen, betragen die Einzelkernkosten 23.000 USD für RAC + 47.500 USD für Oracle DB EE, und Sie müssen noch eine Supportgebühr von ~ 22 % hinzufügen. Wir möchten auf einen großartigen Blog zur Preisgestaltung verweisen, der unter https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/ zu finden ist.

Flashdba hat den Preis für einen Oracle RAC mit vier Knoten berechnet. Der Gesamtbetrag betrug 902.400 USD plus zusätzliche 595.584 USD für drei Jahre DB-Wartung, und das beinhaltet keine Funktionen wie Partitionierung oder In-Memory-Datenbank, all das mit 60 % Oracle-Rabatt.

Galera Cluster ist eine Open-Source-Lösung, die jeder kostenlos ausführen kann. Abonnements sind für Produktionsimplementierungen verfügbar, die Herstellerunterstützung erfordern. Eine gute TCO-Berechnung finden Sie unter https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Schlussfolgerung

Obwohl es erhebliche Unterschiede in der Architektur gibt, teilen beide Cluster die Hauptprinzipien und können ähnliche Ziele erreichen. Das Enterprise-Produkt von Oracle bietet alles, was sofort einsatzbereit ist (und seinen Preis). Mit Kosten im Bereich von>1 Mio. USD, wie oben gezeigt, handelt es sich um eine High-End-Lösung, die sich viele Unternehmen nicht leisten könnten. Galera Cluster kann als ordentliche Hochverfügbarkeitslösung für die breite Masse bezeichnet werden. In bestimmten Fällen kann Galera durchaus eine sehr gute Alternative zu Oracle RAC sein. Ein Nachteil ist, dass Sie Ihren eigenen Stack bauen müssen, obwohl dies mit ClusterControl vollständig automatisiert werden kann. Wir würden gerne Ihre Meinung dazu hören.