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.[1]

Komponenten

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

  • Shared Storage für alle beteiligten Cluster-Nodes (gemeinsamer Zugriff auf SCSI-, SAN- oder NAS-Device von jedem der Rechner im Cluster)
  • Verwendung eines Cluster-Dateisystems, ASM oder Raw Devices auf dem Shared Storage
  • Für jeden Cluster-Node mindestens je zwei Private- und zwei Public-Network-Interfaces
  • Oracle Cluster Ready Services muss ab Version 10g immer eingesetzt werden. Zusätzlich kann eine Cluster Management Software eines anderen Herstellers installiert werden.
  • Ab 11g wird der Cluster vom „Oracle Grid“ verwaltet. Eine zusätzliche Clustersoftware ist nicht gestattet!
  • Ab 19c (12.2.0.3) wird das RAC Feature nicht mehr Bestandteil der Standard Edition 2 sein![2]

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 Korruptionen 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:

  • Database Configuration Assistant (kurz: DBCA) zur Erstellung und Basiskonfiguration von Clusterdatenbanken mit Oracle
  • Oracle Enterprise Manager Grid Control: Graphische Bedienoberfläche zur Verwaltung eines Oracle-Grids inklusive Oracle Real Application Cluster
  • Server Control Utility: Kommandozeilenorientiertes Werkzeug zur Verwaltung von Datenbanken, Services und Applikationen in einem Real Application Cluster

Siehe auch

Literatur

  • Kristien Hens, Michael Loebmann: Creating Highly Available Database Solutions, Sprache: Englisch, Prentice Hall PTR, 2005, ISBN 0-13-186390-8
  • Tim Donar: Tru64 UNIX-Oracle 9i Cluster Quick Reference, Sprache: Englisch – Butterworth-Heinemann, 2002, ISBN 1-55558-272-9
  • Murali Vallath: Oracle Real Application Clusters, Sprache: Englisch – Digital Press, 2004, ISBN 1-55558-288-5
  • Andrea Held; Oracle 10g Hochverfügbarkeit mit RAC, Data Guard und Flashback, m. CD-ROM, Sprache: Deutsch – Addison-Wesley, München 2004, ISBN 3-8273-2163-8
  • Octavian Lascu, Mustafa Mah, Michel Passet, Harald Hammershøi, SeongLul Son, Maciej Przepiórka: Deploying Oracle 10g RAC on AIX V5 with GPFS, Sprache: Englisch – IBM, 2008, ISBN 0-7384-8583-7
  • Matthew Hart, Scott Jesse: Oracle Database 10g High Availability with RAC, Flashback & Data Guard, Sprache: Englisch – Osborne/McGraw-Hill, 2004, ISBN 0-07-225428-9
  • Andrea Held: Oracle 11g – Neue Features, Sprache: Deutsch, gebundene Ausgabe – Hanser-Verlag, München, Erscheinungsdatum: Mai 2008, ISBN 3-446-41198-4
  • Larissa Janssen: Hochleistungs-Datenbanksysteme: Theorie und Praxis, Sprache: Deutsch, Books on Demand, 2008, ISBN 978-3-8334-9326-3
  • Mike Ault, Madhu Tumma, Ranko Mosic: Oracle 10g Grid & Real Application Cluster, Sprache: Englisch, Rampant Tech Press, 2004, ISBN 0-9744355-4-6

Weblinks

Einzelnachweise

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