Home 
ORDIX News 3/2007 Datenbanken
ORDIX News 3/2007 Datenbanken
ORDIX News 3/2007 Datenbanken
Entscheider, Entwickler und Projektmanager.
| CRS Cluster Ready Service. Eigenständige Oracle Cluster Ware, die seit Oracle 10g mit ausgeliefert wird. Die Oracle Cluster Ware ist Voraussetzung für den Einsatz von Oracle RAC. Sie übernimmt die Verwaltung und die Überwachung aller beteiligten Cluster-Knoten. |
| OCR Disk Oracle Cluster Registry Disk. Die OCR Disk ist eine Datei, in der die Oracle Cluster Ware die gesamte Cluster-Konfiguration abspeichert. |
| GCS/GES Global Cache Service/Global Enqueue Service. Der Global Cache Service bildet zusammen mit dem Global Enqueue Service die Cache Fusion Technology von RAC. Sie verwalten die Oracle-Blöcke, die sich aktuell in einer oder mehreren System Global Areas (SGA) befinden und koordinieren die Zugriffe auf diese Blöcke. |
| ASM Automatic Storage Management. Der ASM ist ein im Oracle Kernel integrierter Volume Manager. Er ist ab Oracle 10g verfügbar. Er arbeitet nach dem SAME-Prinzip (stripe and mirror everything). |
| TAF Transparent Application Failover. Automatischer Session Failover einer Datenbank-Session. Für die Anwendung verhält sich das transparent. Sessions werden z. B. bei einem Ausfall eines Cluster-Knotens auf einen anderen Cluster-Knoten „re-connected". |
 |
| Abb. 1: Schematische Darstellung einer RAC Umgebung mit 2 Knoten. |
 |
| Abb. 2: Beispielhafte Darstellung des RAC Loadbalancing- und Failover-Mechanismus. |
 |
| Abb. 3: Darstellung des Oracle RAC Hard-/Software Stacks. (vergrößern) |
 |
| Abb. 4: Beispiel für ein Storage Layout, verteilt über 2 Rechenzentren. (vergrößern) |
Bei Oracle RAC handelt es sich um eine Aktiv-Aktiv-Cluster-Lösung auf Basis einer "shared all"-Disk-Architektur. Das bedeutet, dass sich mehrere Oracle-Instanzen, welche auf unterschiedlichen Knoten aktiv sind, eine zentrale Datenbank teilen (siehe Abbildung 1).
Abbildung 2 veranschaulicht die beiden Vorteile eine Oracle RAC Systems. Die Vorteile sind im Allgemeinen:
In Sachen Performance gilt jedoch, Folgendes zu beachten: Skaliert eine Anwendung nicht auf einer Oracle Single-Instanz, so skaliert sie auch nicht unter Oracle RAC. D. h. es sollte vor dem Einsatz eines RAC-Systems immer eine detaillierte Analyse der Anwendung erfolgen, damit es nachträglich nicht zu ungewollten Ergebnissen kommt.
Der Preis für die Vorteile eines RAC ist nicht nur monetär zu beziffern, sondern auch in Form einer Erhöhung der Soft- und Hardware- Komplexität. So sind diverse Hard- und Software-Voraussetzungen für ein RAC-System zu erfüllen. In Abbildung 3 wird der Hard- und Software Stack eines RAC-Systems dargestellt.
Im Folgenden werden die einzelnen Komponenten daraus kurz beschrieben:
Wie bereits erwähnt, handelt es sich bei RAC um eine "shared all“-Architektur. Somit stehen zur Datenhaltung nur die folgenden Storage Systeme zur Verfügung.
Die Datensicherheit und -redundanz ist auf Storage-Ebene zu gewährleisten. Hierfür stehen die altbekannten RAID-Methoden (z. B. RAID 5, RAID 1+0) zur Verfügung.
Eine weitere, wichtige Erhöhung der Speicherverfügbarkeit bietet das Host Based Mirroring. Dabei wird mittels eines Cluster Volume Managers oder auch ASM (mittels Failgroups) auf Volumes aus der gleichen oder auch auf Volumes einer weiteren Storage Box gespiegelt. In Abbildung 4 wird eine solche Lösung dargestellt. Die Vorteile hierbei sind, dass das RAC-System sogar bei Komplettausfall einer Storage Box zur Verfügung steht. Nachteile dieser Lösung sind hingegen die sehr hohen Speicherplatzanforderungen und die Anforderungen an ein entsprechend schnelles Netzwerk.
Wie auch bei der Oracle Single Instanz Architektur ist Oracle RAC unter den meisten Betriebssystemplattformen freigegeben. Jedoch sind in diesem Zusammenhang auch weitere hard- und software-technische Anforderungen abzuklären. Eine aktuelle Übersicht über die von Oracle zertifizierten Plattformen finden Sie auf den Oracle Webseiten [1].
Hier können Sie den Zertifizierungsstatus je nach Oracle Release oder auch nach der Betriebssystemplattform abfragen. Neben der Betrachtung des Betriebssystems müssen die Anforderungen an das Netzwerk berücksichtigt werden.
Für die Cluster-Kommunikation und vor allem für den Cache Fusion Mechanismus wird ein privates Netzwerk, der so genannte "Cluster Interconnect“, benötigt. Er verbindet alle beteiligten RAC-Knoten direkt miteinander. Für den Cluster Interconnect können u. a. folgende Technologien eingesetzt werden:
Mit Oracle RAC 10g Release 1 wurde eine eigenständige Cluster Ware integriert, der Oracle CRS (Cluster Ready Service). Ab Oracle 10g Release 2 wurde das Produkt in Oracle Cluster Ware umbenannt.
Bei der Oracle Cluster Ware handelt es sich um eine voll funktionsfähige Cluster Ware. Somit ist ein Zukauf einer 3rd Party Cluster Ware, wie z. B. bei Oracle RAC 9i, nicht mehr unbedingt notwendig. Die Oracle Cluster Ware übernimmt die folgenden Aufgaben:
Die Cluster Informationen werden von der Oracle Cluster Ware in die Cluster Registry Datei geschrieben und dort verwaltet (OCR Disk = Oracle Cluster Registry Disk). Diese muss ebenfalls im Shared Disk Bereich und somit für alle Cluster-Knoten zugänglich hinterlegt werden. Mit Oracle 10g Release 2 ist es nun ebenfalls möglich, die OCR Disk und die Voting Disk mit Oracle Cluster Ware Mitteln zu spiegeln. Dieses war mit Oracle 10g Release 1 noch nicht möglich.
Für die Oracle Cluster Ware fallen keine weiteren Lizenzgebühren an. Sie ist im RAC-Lieferumfang enthalten. Die Installation erfolgt in ein separates Oracle Cluster Ware Home-Verzeichnis (ORA_CRS_HOME).
Eine Kombination mit einer 3rd Party Cluster Ware (z. B Sun Cluster, Veritas Cluster) ist natürlich nach wie vor möglich und unter bestimmten Gesichtspunkten auch notwendig.
Ebenfalls neu ab Oracle 10g ist der ASM (Automatic Storage Manager). Hiermit liefert Oracle einen clusterfähigen Volume Manager aus, der in den Oracle Kernel integriert wurde. Die Leistungsfähigkeit des ASM ähnelt dem eines beliebigen Unix Volume Managers. ASM arbeitet nach dem SAME-Prinzip (SAME = Stripe And Mirror Everything). Ab Oracle 10g Release 2 ist neben der Administration über SQL*Plus und Grid Control nun eine Administration von ASM über ein weiteres Kommandozeilen-Tool (asmcmd) möglich. Die Funktionsweise einer ASM-Instanz in Verbindung mit RAC ist in Abbildung 5 zu sehen.
|
| Abb. 5: Automatic Storage Management in Verbindung mit RAC. |
Für die Verwaltung des Storage stehen die folgenden Möglichkeiten zur Verfügung:
Das Oracle Cluster File System unterliegt der GPL-Lizenzierung. Weitere Informationen zum OCFS erhalten Sie vorab auf den Oracle Webseiten [2]. In einem der nächsten Artikel werden wir das OCFS noch einmal detailliert beleuchten.
Auf dieser Ebene befinden sich die RAC-Instanzen. Viele Datenbankinstanzen teilen sich eine zentrale Datenbank. Die SGAs werden quasi über alle beteiligten Instanzen hinweg “ge-shared”. Die Grundlage hierfür bildet die Cache Fusion Technology.
Cache Fusion besteht im Wesentlichen aus dem Global Cache Service (GCS) und dem Global Enqueue Service (GES). Über den GCS werden u. a. alle Datenbankblöcke, die sich in einer lokalen SGA befinden, nach Anfrage allen anderen Instanzen zur Verfügung gestellt. Dieses geschieht über den Cluster Interconnect. Bei der Auswahl der Cluster Interconnect Technology kommt es nicht ausschließlich auf den Durchsatz (Throughput) an. Genauso wichtig ist die Betrachtung der Latenzzeit.
Mit der Integration einer eigenständigen Oracle Cluster Ware wurde das Thema Oracle Services für RAC erweitert. Die Verbindung zur Datenbank wird, wie bereits in früheren Oracle RAC Releases, über den Service-Namen hergestellt. Services können mittels der neuen Cluster Ware umgeschaltet bzw. auf andere Knoten übernommen werden. Anwendungen und Anwendungsbereiche (OLTP, Batch-Jobs) lassen sich somit gruppieren und wenn notwendig auch auf unterschiedlichen Knoten ausführen. Dadurch wird RAC seinem Namen “Real Application Cluster” tatsächlich gerecht.
Aus dem Nutzen der oben beschriebenen Layer ergeben sich die beiden Vorteile Hochverfügbarkeit und Verbesserung der Performance.
Oracle RAC unterscheidet zwischen Connect Time Failover und Session Time Failover. Connect Time Failover bedeutet, dass bereits beim Verbindungsaufbau eine Verbindung zur Zielinstanz nicht möglich war. Somit wird zu einer anderen, laufenden Instanz verbunden. Session Time Failover bedeutet hingegen, dass eine bestehende Verbindung, z. B. aufgrund eines Instanz-Crashs oder eines Media-Fehlers, verloren geht. Hierbei wird ein "re-connect" durchgeführt und die Client-Verbindung automatisch zu einer anderen RAC-Instanz verbunden. Für die Anwendung sind beide Fälle völlig transparent, jedoch spielt der Oracle Client hier eine wichtige Rolle. Die gesamte Konfiguration wird daher auch als TAF-Konfiguration (Transparent Application Failover) bezeichnet.
Der Oracle RAC Loadbalancing-Mechanismus verteilt die Last (Client Sessions) über die RAC-Instanzen. Eine Performance-Steigerung kann hierbei erreicht werden, muss allerdings nicht! Vor jedem Einsatz von RAC ist eine Analyse der Anwendung zu empfehlen, auch wenn RAC sich zur Anwendung transparent verhält.
Oracle RAC unterscheidet standardmäßig die folgenden Loadbalancing-Mechanismen:
Die Komplexität einer RAC-Umgebung liegt in der Vielzahl der einzelnen Hard- und Software-Komponenten, die ineinandergreifen müssen. Die Grundlage für jedes erfolgreiche RAC-Projekt sind zum einen eine ausgedehnte Planungsphase und zum anderen eine kompetente Beratung.
Ansonsten könnte es vorkommen, dass sich diverse Konfigurationen zwar als "Powerpoint-kompatibel" darstellen, jedoch als nicht praxistauglich herausstellen. Im nächsten Teil werden wir Ihnen die erste RAC-Komponente "OS-Netzwerk Layer/Cluster Ware Layer" detailliert vorstellen und Ihnen natürlich auch unsere Praxiserfahrung nicht vorenthalten.
Guido Saxler (info@ordix.de).