Oracle RAC

Oracle RAC (Oracle Real Application Clusters) ist eine zusätzliche Option des Datenbankmanagementsystems der Firma Oracle. Oracle RAC ermöglicht Ausfallsicherheit, indem mehrere Knoten eines Rechnerverbundes (englisch Cluster) auf dieselbe Datenbank zugreifen und für Clientrechner Datenbankdienste zur Verfügung stellen. Fällt einer der Knoten aus, übernehmen die anderen dessen Funktionalität. Zusätzlich kann Oracle Real Application Cluster als Möglichkeit der Skalierung eingesetzt werden: Reicht die Kapazität eines Datenbankservers nicht aus, kann diese durch einen weiteren Rechnerknoten ergänzt werden. Um eine optimale Skalierung im Oracle Datenbankcluster erreichen zu können, muss jedoch das Anwendungsdesign an die Anforderungen paralleler Clusterzugriffe angepasst werden. Das Oracle Real Application Cluster dient als Basis des Oracle Grid im Datenbank-Backend.

Architektur

Bei Nutzung des Oracle Real Application Clusters sind im Normalbetrieb zwei oder mehr Rechnerknoten in einem Cluster (Rechnerverbund) aktiviert und greifen auf denselben Datenbestand zu. Jeder Knoten betreibt zwar eine eigenständige Datenbankinstanz, die jedoch über die Cache-Fusion-Technologie mit den Datenbankcaches aller am Cluster beteiligten Rechner zusammengeschaltet ist. So macht es für den Nutzer nahezu keinen Unterschied, auf welchem Knoten sein Zugriff tatsächlich ankommt.

Der Vorteil: Fällt ein Rechner aus, so können sich Clients unmittelbar und ohne Wiederanlaufzeit auf einen verbleibenden Rechnerknoten verbinden. Zudem können Lasten auf alle Clusterknoten verteilt werden. Langlaufende Operationen können mittels Parallel-Slave-Prozessen auch über den gesamten Cluster parallelisiert werden. So ist neben der erhöhten Verfügbarkeit auch das Thema Skalierung eine der Stärken des Real Application Clusters. Redundante Hardware wird nicht nur im Fehlerfall eingesetzt, sondern kann – anders als bei Failover-Clustern – im Normalbetrieb genutzt werden.

Ähnlich wie in einem Oracle Failover Cluster wird auch hier ein Private-Network für den Cluster-Heartbeat sowie ein davon separiertes Public-Network benötigt. Allerdings wird im Oracle Real Application Cluster konkurrierend auf die Datenbank-Dateien eines Shared-Storages zugegriffen. Dies erfordert zusätzlichen Kommunikationsaufwand zwischen den Knoten, der zur Abstimmung von Sperren und veränderten Block-Images nötig ist. Diese Cluster-Kommunikation erfolgt über das Private-Network. In Real-Application-Cluster-Umgebungen ist es daher wichtig, einen möglichst schnellen privaten Cluster-Interconnect zu nutzen. Mindestens Gigabit-Ethernet sollte eingesetzt werden. Besser noch sind spezielle, oft proprietäre Lösungen mit höherer Bandbreite. Beispiele sind Memory-Channel (alphabasierte HP-Cluster), Myrinet (Linux-Systeme), Scalable-Coherent-Interconnect (SUN), Veritas LLT (verschiedene Plattformen) oder HP Hyper-Fabric HMP.

Inzwischen gibt es auch Hersteller-Lösungen wie die Oracle Exadata, die auf den Einsatz von RAC abgestimmt sind.

Komponenten

Notwendige Komponenten für den Einsatz eines Oracle Real Application Clusters sind:

Vor- und Nachteile

Vorteile eines Oracle Real Application Clusters

  • Übernahme der Funktionalität bei Ausfall eines Servers ohne administrativen Eingriff
  • Geringer Zeitaufwand für Wiederanlauf, Client-Reconnect (erneute Verbindungsaufnahme zur Datenbank über einen anderen Datenbankserver im Cluster) erfolgt für den Anwender bzw. die Applikation während SELECT-Statements transparent und innerhalb einiger Sekunden auf den Ersatzknoten
  • Die komplette Hardware kann – anders als beim Failover-Cluster – auch während des Normalbetriebs genutzt werden.
  • Parallelisierung über alle Clusterknoten hinweg realisierbar
  • Dynamische Zuordnung von Services möglich
  • Kompensation eines Rechenzentrumsverlustes, wenn der RAC und sein Shared Media entsprechend verteilt wurde („Stretched Cluster“, bis ca. 2000 m)

Nachteile eines Oracle Real Application Clusters

  • Stretching des Clusters über ca. 2000 m nicht mehr möglich (Latenzprobleme). Bei Ausfall des Rechenzentrums (zum Beispiel durch einen Brand) fällt der gesamte Cluster aus. Dieser Fehlerfall kann bei Bedarf durch Einsatz einer zusätzlichen Standby-Datenbank in Kombination mit Oracle Real Application Clusters oder aber durch Metro-Clustering abgefangen werden.
  • Kein oder nur eingeschränktes Abfangen von logischen Fehlern möglich (Block corruption, Bedienfehler). Diese Fehler können durch eine zeitverzögerte Standby-Datenbank (Oracle Dataguard), Datensicherung und Datenwiederherstellung verbunden mit einem Roll-Forward oder auch in vielen Fällen durch Oracle Flashback abgefangen werden.
  • Jedes Mal, wenn eine Instanz ausfällt, ist die ganze Datenbank nicht verfügbar, und zwar solange, bis das GRD (Global Resource Directory) neu gestartet wurde und SMON alle für Instanz-Recovery erforderlichen Blöcke ermittelt und bekommen hat. Erst ab diesem Punkt wird es möglich, auf alle Blöcke außer den für das Recovery nötigen zuzugreifen. Erst wenn das Instanz-Recovery komplett fertig ist, sind alle Daten vollständig verfügbar.
  • Werden zur gleichen Zeit bzw. kurz aufeinander folgend auf mehreren Instanzen des Clusters Daten angefordert, die in denselben Datenbank-Blöcken liegen, so werden diese zwischen den Buffer-Caches der betroffenen Instanzen transferiert. In Extremfällen kann das dazu führen, dass die Datenbank sich nur damit beschäftigt, die Blöcke hin und her zu schieben.

Werkzeuge zur Verwaltung

Oracle Real Application Cluster wird durch folgende Administrationswerkzeuge unterstützt:

Siehe auch

Literatur

Einzelnachweise

  1. ↑ iX. Abgerufen am 2. September 2018.
  2. ↑ Database Licensing Information User Manual. Abgerufen am 8. April 2019 (amerikanisches Englisch).