Home 
ORDIX News 4/2004
ORDIX News 4/2004
ORDIX News 4/2004
Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.
Bevor die Entscheidung für oder gegen RAC fällt, sollte das Projektteam detailliert die Vorteile und die Kosten gegeneinander abwägen. Zweimal 220 Volt gibt auch bei Oracle 380 Volt, aber ob Ihre Applikation tatsächlich einem Starkstromaggregat gleicht oder doch einem normalen Elektromotor ähnelt, dessen Spulen bei 380 Volt verglühen, bedarf in der Regel einer detaillierten Analyse.
Bei diesem Artikel steht die Technologie zum Einsatz von 10g auf Linux im Mittelpunkt. Schritt für Schritt erläutern wir das Vorgehen zum erfolgreichen Einsatz von RAC. Änderungen zu Oracle 9i erläutern wir an gegebener Stelle.
 |
| Abb. 1: Beispiel einer Oracle 10g RAC Architektur. |
Wie auch bei allen anderen Versionen, läuft 10g nur auf zertifizierten Systemen. Aufgrund der besonderen Komplexität stehen allerdings bei weitem nicht so viele Plattformen wie etwa für Single Instance Systeme zur Verfügung. Bis Ende Oktober konnte 10g unter Linux nur auf Redhat 2.1 Enterprise Server installiert werden. Inzwischen hat aber auch Suse Linux die Zertifizierung durchlaufen. De Facto stehen also bisher "magere" zwei zertifizierte Linux Systeme zur Verfügung. Die jeweils aktuelle Zertifizierungsmatrix finden Sie unter Links.
Wie üblich bei RAC ist ein Interconnect zwischen den beiden Servern notwendig, um mittels Cache Fusion Datenblöcke und andere Ressourcen zwischen den Instanzen auszutauschen. Mit 10g steht nun erstmalig auch die Zertifizierung von Infiniband – einer vielversprechenden Technologie – an.
Ebenfalls eine Neuerung: Mit 10g steht RAC auch in der Standard Edition zur Verfügung, sogar ohne Aufpreis. Allerdings werden dabei nur maximal vier Prozessoren im gesamten Cluster zugelassen.
 |
| Abb. 2: Konfiguration Secure Shell (ssh) auf beteiligten Cluster-Nodes. |
 |
| Abb. 3: Oracle 10g RAC Kernel-Parameter für Linux. |
Zur knotenübergreifenden Installation von RAC setzt Oracle eine konfigurierte Secure Shell (ssh) voraus. Abbildung 2 zeigt die hierzu notwendigen Schritte. Die erzeugten Dateien (authorized_keys) müssen "gegenseitig" auf jedem Knoten ins Verzeichnis ~oracle/.ssh kopiert werden, damit der sichere, gegenseitige Zugriff ohne Passwort möglich ist. Zur Überprüfung kann man z. B. das Kommando ssh <knoten1> date auf dem Knoten 2 ausführen, was erfolgreich ohne Ausgabe eines Passwortes laufen muss. Genauso aber auch umgekehrt.
Zum reibungslosen Betrieb der Datenbank ist die Anpassung zahlreicher Kernelparameter notwendig. Die wichtigsten sind in Abbildung 3 aufgeführt. Mit dem Linux Befehl sysctl –w (RedHat) können die Kernelparameter dynamisch geändert werden.
In der Datei /etc/sysctl.conf müssen die o. a. Parameter eingetragen werden. Dieses bewirkt bei jedem Reboot ein erneutes Setzen der entsprechenden Parameter.
Insbesondere falsch konfigurierte UDP Parameter können die Performance des RAC Systems dramatisch beeinflussen, ähnlich etwa wie die Sichtverhältnisse in einem geschlossenen Raum mit einer Leuchtstoffröhre von 180 Volt.
Auf die Oracle Datenbankdateien – Online Redo Log Files, Control Files und Data Files – muss der konkurrierende Zugriff von jeder Instanz, also von jedem Knoten, möglich sein. Hierzu muss ein zentraler Speicher, z. B. SAN, zur Verfügung stehen, auf dem prinzipiell folgende Zugriffsmöglichkeiten bestehen:
Unter Linux (Redhat 2.1 Enterprise Server) bleibt zunächst nur die Möglichkeit der Verwendung des OCFS oder des ASM (Automated Storage Management), da mit fdisk nur maximal 15 separate Partitionen (SCSI) angelegt werden können und zur Zeit auch die Unterstützung eines LVM nicht gegeben ist.
Die Installation des OCFS gestaltet sich recht einfach. Die notwendigen RPM Pakete stehen unter Links für die entsprechenden Linux- und Hardware-Plattformen zur Verfügung. Mit dem Werkzeug ocfstool lässt sich das OCFS konfigurieren (siehe Abbildung 4). Des Weiteren kann man u. a. über ocfstool die Oracle Cluster Filesysteme "mounten" beziehungsweise "unmounten".
 |
| Abb. 4: OCFS-Tool zur Konfiguration des Oracle Cluster Filesystems. |
Der Oracle Cluster Ready Service (CRS) ist die eigentliche Clusterware. Als Oberbegriff enthält dieser Dienst verschiedene Funktionalitäten. Hierzu gehören unter anderem die schon in 9i bekannten Dienste Global Service Daemon (GSD) und Oracle Cluster Manager.
Neu ist, dass Oracle mit dem CRS auch eine Clusterware für alle zertifizierten Plattformen liefert und sich hiermit unabhängig von proprietären Cluster Diensten (Service Guard, HACMP, RMS usw.) macht. Wird eine proprietäre Cluster Software verwendet, so kann diese optional auch verwendet werden.
Das Starten des CRS wird durch die inittab initiiert, das Herunterfahren durch ein entsprechendes rc-Skript.
Die weiteren Schritte erfolgen nahezu identisch wie schon unter Oracle 9i. Die Oracle Software wird mit der RAC Option installiert. Anschließend erfolgt die Konfiguration und Installation der Datenbank mit der entsprechenden Berücksichtigung von RAC.
Wie schon unter Oracle 9i besteht die größte Herausforderung in der sorgfältigen Umsetzung der zahlreichen Installationsschritte. Vorab ist die gesamte Hard- und Softwarekonfiguration mit der Kompatibilitätsmatrix zu überprüfen. Die Dokumentation lässt an einigen Stellen Wünsche offen. Insbesondere der neue Komplex Cluster Ready Service ist nur sehr spärlich beschrieben.
Beim Hantieren mit Starkstrom empfehlen wir eine gute Ausbildung. Besuchen Sie unsere RAC Schulung, damit Ihre Motoren mit 380 Volt ihre volle Leistung entfalten. Infos zu dem Seminar finden Sie in unserem Trainingsshop unter http://training.ordix.de.
Martin Hoermann, Guido Saxler (info@ordix.de).