Home 
ORDIX News 4/2007 Datenbanken
ORDIX News 4/2007 Datenbanken
ORDIX News 4/2007 Datenbanken
und
Entwickler, die Oracle RAC
aufsetzen und betreiben.
| Interconnect Der Interconnect ist eine private Netzwerkverbindung zwischen den Knoten eines Clusters. |
| OCFS Das Oracle Cluster File System ist ein Dateisystem, das simultanes Lesen und Schreiben von mehreren Knoten ermöglicht. |
| ASM Automatic Storage Management ist ein Oracle Volume Manager, der das Striping, Mirroring und Load Balancing übernimmt. ASM kann als zentraler Speicher für RAC-Systeme verwendet werden. |
| Load Balancing Mechanismus zur Lastverteilung von Aufgaben auf mehrere Komponenten eines Systems - in der Regel eines Clusters. |
| OCR Die Oracle Cluster Registry ist eine Datei, die die Konfiguration der Oracle Clusterware und seiner Applikationen enthält. Die OCR kann seit der Version 10gR2 auf mehrere Dateien gespiegelt werden. |
| 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. Ab 10g wurde CRS in Oracle Clusterware umbenannt. Ab Oracle 10gR2 ist CRS nur noch eine Teilkomponente der Oracle Clusterware. |
| FAN Fast Application Notification. Mechanismus, um Applikationsprozesse über den Status von Services und Knoten zu informieren. Dieser Mechanismus wird verwendet, um Failover und Load Balancing für RAC-Systeme auf Applikationsebene zu programmieren. |
| DBCA Database Configuration Assistant. Grafischer Assistent zur Erstellung und Konfiguration von Oracle Datenbanken. |
Die Voraussetzungen zur Installation und zum Betrieb der RAC Clusterware lassen sich in folgende Bereiche unterteilen:
Mit der Version 10gR2 steht für jede Plattform ein separater Installation Guide zur Verfügung. Es wird dringend empfohlen, die jeweils aktuellen Dokumente vor dem Einlegen des Installationsmediums zu studieren.
Bezüglich des Netzwerks verlangt die Clusterware jeweils zwei Netzwerkkarten pro Knoten. Die erste Netzwerkkarte dient dem herkömmlichen Anschluss an das öffentliche Netz, über den die Rechner erreicht werden. Auf dieser Netzwerkkarte bindet Oracle auch die virtuellen IP-Adressen, über die sich die Clients mit den Datenbanken verbinden. Die zweite Netzwerkkarte dient dem cluster-internen Netz, dem so genannten Interconnect.
Obwohl bei einem Cluster mit zwei Knoten auch ein Crossover-Kabel für das cluster-interne Netz grundlegend funktioniert, wird dies weder von Oracle unterstützt, noch ist dies für produktive Systeme oder wichtige Testsysteme zu empfehlen. Aus diesem Grund ist also noch ein aktives Netzwerkelement, z. B. ein Switch, für das cluster-interne Netz notwendig.
Die aktuell gängige Auslegung des Interconnect ist Gigabit Ethernet. Die kleinere Variante mit 100 Mbit ist für viele Testsysteme sicherlich ausreichend, für ein High End Cluster stehen inzwischen aber auch schon 10 Gbit Ethernet oder InfiniBand-Technologien zur Verfügung. Relevant ist ein hoher Durchsatz zum Übertragen der Blöcke und eine kurze Latenzzeit zum schnellen Austausch von Nachrichten zwischen den Knoten.
Die virtuellen IP-Adressen müssen im Netzwerk bekannt sein, jedoch dürfen diese nicht vom Administrator gebunden werden. Diese Aufgabe übernimmt, wie auch bei anderen Cluster-Produkten, die Software.
Verfügt der Cluster über mehr als zwei Knoten, so entscheidet die Clusterware, auf welchen Knoten die virtuelle IP-Adresse im Fehlerfall geschwenkt wird. Eine Einflussnahme ist nur sehr begrenzt möglich. Bei einem Zwei-Knoten-Cluster stellt diese Restriktion naturgemäß kein Problem dar.
Die Voraussetzungen für das Betriebssystem beziehen sich lediglich auf den Haupt- und Festplattenspeicher sowie auf die Erreichbarkeit der Server untereinander. Die Voraussetzungen für Single-Instance-Datenbanken, z. B. bezüglich der Kernelparameter, gelten auch für RAC-Datenbanken.
 |
| Abb. 1: Darstellung des Oracle RAC Hard-/Software Stacks. (vergrößern) |
Darüber hinaus gibt es einige Ergänzungen, wie zum Beispiel die Parameter zur Anpassung der UDPPaketgrößen. Interessant an dieser Stelle ist die Erreichbarkeit der Server untereinander. Neben der korrekten Netzwerkkonfiguration muss ein Remotezugriff ohne Passworteingabe zur Verteilung der Installation konfiguriert werden. Dies ist plattformabhängig zum Beispiel ssh oder rsh.
Als Letztes muss sich der Administrator über einen zentralen Speicherplatz Gedanken machen. Die Clusterware benötigt Platz für zwei Dateiarten. Als erstes ist die Oracle Cluster Registry (OCR) zu nennen. In dieser Datei verwaltet die Clusterware die gesamte Konfiguration. Ab der Version 10gR2 kann und sollte die Datei gespiegelt werden. Mit einer Größe von 100 MB haben auch sehr große Konfigurationen genügend Kapazität.
Die zweite Datei ist die Voting Disk, aus anderen Produkten auch als Quorum Disk bekannt. Die Voting Disk dient beim so genannten Split Brain (gleichzeitige Unterbrechung aller Zwischenverbindungen zwischen den Clusterteilen) als Entscheidungshilfe, welcher Teil vom Cluster der Aktive bleibt. Für die Voting Disk ist eine Größe von 20 MB ausreichend. Auch die Voting Disk kann und sollte mit dem Release 2 gespiegelt werden.
Zum Speichern der OCR und der Voting Disk stehen Raw-Devices oder ein Cluster-Dateisystem, z. B. OCFS 2, als Option zur Verfügung. ASM lässt sich nicht verwenden. Ein dritter Spiegel einer Voting Disk lässt sich auch über NFS anschließen.
Die Oracle Clusterware dient zur Steigerung der Verfügbarkeit von Datenbanken und anderen Softwarekomponenten im Cluster. Die von der Clusterware verwalteten Ressourcen sind zum Beispiel die virtuellen IP-Adressen, Datenbank-Instanzen, ASM-Instanzen, Net-Services und Listener.
Ein Cluster besteht aus mindestens zwei Servern, welche in diesem Kontext Knoten genannt werden. Die Clusterware startet alle RAC-Komponenten sowie weitere, konfigurierte Softwareprodukte beim Systemstart des Knotens oder im Falle des unerwarteten Absturzes einer Komponente.
Fällt ein Teil des Clusters aus, so entscheidet die Clusterware, welcher Teil des Clusters welche Aufgaben übernimmt. Beim Ausfall schaltet die Clusterware die virtuelle IP-Adresse des betroffenen Rechners auf einen anderen Knoten. Anschließend werden Services und andere konfigurierte Softwareprodukte ebenfalls auf den anderen Knoten geschwenkt.
Im Gegensatz zu herkömmlichen Cluster-Produkten berücksichtigt die Oracle Clusterware die Besonderheiten eines RAC-Systems. Dies beinhaltet z. B., dass das Umschalten einer RAC- oder ASM-Instanz sowie des Listeners nicht notwendig ist, da diese ja schon hochverfügbar auf allen Knoten laufen. Dafür werden datenbankinterne Mechanismen verwaltet, wie beispielsweise die Umschaltung von Oracle Net Services.
Eine besondere Eigenart der Clusterware ist der Neustart eines Knotens, falls dieser wesentliche Cluster-Ressourcen nicht erreichen kann. Mit diesem Verfahren setzt die Software auf eine "Selbstheilung" durch einen Neustart.
Die Clusterware, in Release 1 noch "Cluster Ready Services" genannt, besteht aus zusätzlichen Prozessen, die die Funktionalität der Clusterware implementieren. Der Oracle Cluster Synchronisation Service (OCSS) stellt die Basis für die Kommunikation zwischen den Knoten dar. Der OCSS bindet einen Knoten beim Systemstart in die aktuelle Clusterkonfiguration ein und entfernt diesen beim Herunterfahren oder beim Absturz. Die Cluster Ready Services (CRS) bilden darüber das Hochverfügbarkeits-Framework.
Der Oracle Notification Service (ONS) ist ein Prozess, der Applikationen über die aktuelle Last des Systems informiert. Über die dahinter liegenden Auswertungen ist es möglich, ein Load Balancing auf Applikationsebene durchzuführen. Das Load Balancing mittels Oracle Net wirkt sich nur beim Verbindungsaufbau aus. Über den ONS funktioniert das Load Balancing auch zur Laufzeit bei einer bestehenden Verbindung. Der Mechanismus, der dieses Load Balancing verwendet, heißt Fast Application Notification (FAN). Um FAN zu nutzen, muss auf der Client-Seite noch zusätzliche Funktionalität programmiert werden.
Die Konfiguration der Clusterware erfolgt mit dem Database Configuration Assistant (DBCA). Sind alle Voraussetzungen sorgfältig überprüft, so läuft der Konfigurationsprozess oft unproblematisch. Doch selbst das Erfüllen aller nötigen Voraussetzungen schützt leider dennoch nicht vor verschiedenen Problemen, wie zum Beispiel dem Bug 4437727, der alle IP-Adressen mit dem Muster 172.16.x.x, 192.168.x.x und 10.x.x.x als Private einstuft und nicht als öffentliche IP-Adressen erkennt.
Zum Starten und Stoppen der Clusterware selbst dient das Skript init.crs. Hierüber lässt sich für Wartungsarbeiten auch die gesamte Clusterware aktivieren und deaktivieren. Mit dem Programm crs_stat lässt sich der Status der einzelnen Ressourcen des Clusters anzeigen.
Bei Änderungen der Konfiguration des Clusters, wie z. B. der privaten IP-Adressen oder bei Fehleranalysen, muss sich der Administrator mit diversen anderen Werkzeugen beschäftigen. Hierzu zählen unter anderem:
Viele dieser Werkzeuge sind mit dem Root- Benutzer zu bedienen. Die Standardkonfiguration einer Clusterware beinhaltet im Wesentlichen nur die virtuellen IP-Adressen und den ONS. Mit der Installation der ersten RAC-Datenbank kommen dann diverse Ressourcen wie DB-Instanzen, Listener, Oracle-Net-Services und andere hinzu. Über diese Standardkonfiguration hinaus ist die Clusterware von Oracle auch weitergehend konfigurierbar.
Es können verschiedene Softwareprodukte in die Clusterware eingehängt werden. Beispielsweise kann mit der Clusterware auch eine Single Instance Datenbank hochverfügbar gestaltet werden. Hierzu sind einige Konfigurationsarbeiten durchzuführen, sowie verschiedene Skripte zu erstellen und anzupassen.
Last but not least sollte der Administrator dringend ein K-Backup-Szenario erarbeiten, da sich das Thema Backup und Recovery mit der Oracle Clusterware deutlich erweitert.
Mit der Clusterware bietet Oracle eine Software an, die mit Oracle RAC zwingend zu verwenden ist. Darüber hinaus kann die Software jedoch auch andere Softwarekomponenten hochverfügbar gestalten. Der Kauf einer meist sehr teuren, externen Clusterware ist nur noch optional. Notwendig kann die Verwendungen einer externen Clusterware aufgrund anderer Restriktionen sein. So benötigt zum Beispiel das QFS-Filesystem von SUN unter Umständen den Solaris Volume Manager. Die Kombination zweier Clusterware-Produkte erhöht natürlich die Komplexität des Systems.
Nach der Installation der Datenbank muss sich der erfahrene Oracle-Administrator an einige Änderungen gewöhnen. Die Verwaltung der Instanzen erfolgt nicht mehr über die bekannten Werkzeuge, sondern über das Programm srvctl. Mit diesem Programm kann der Administrator unter anderem ASM- und Datenbank-Instanzen sowie Listener und Services starten, stoppen, aktivieren oder deaktivieren. Das Programm srvctl stellt die Schnittstelle zwischen den Oracle-Programmen und den Ressourcen der Clusterware dar.
Wie auch bei anderen Cluster-Softwareprodukten erhöht die Oracle Clusterware die Komplexität des Datenbankbetriebs enorm. Bei der Verwendung von RAC gibt es allerdings auch keine Alternative zur Oracle Clusterware. Eine gute Ausbildung und eine intensive Beschäftigung mit dem Produkt ermöglichen einen signifikanten Schritt hin zu einer höheren Verfügbarkeit.
Martin Hoermann (info@ordix.de).