RAC Features Teil III:

Über welchen Interconnect wird eigentlich gearbeitet?

Seit der Einführung von Oracle 9i ist der sogenannte High Speed Interconnect, die Verbindung zwischen den Clusterknoten, für die Übertragung der Daten extrem wichtig geworden. Durch die neue Cache Fusion Technologie werden die Daten zwischen den Rechnern nicht mehr über die Platte, sondern über den Interconnect ausgetauscht, wodurch die entscheidende Performanceverbesserung erreicht wird. Somit ist natürlich nicht ganz unwichtig, über welche Netzverbindung zwischen den Rechnern gearbeitet wird. Da die Rechner in der Regel in einem LAN stehen, kann auch die LAN-Verbindung als "Interconnect" dienen, was natürlich ein Porsche mit angezogener Handbremse sein kann, wenn die LAN Verbindung für anderen Datentransfer stark genutzt wird. Somit sollte man bei performance-relevanten Systemen auf jeden Fall einen eigenen Interconnect physikalisch aufbauen und entsprechend konfigurieren. Nur nutzt das System diesen Interconnect nicht automatisch, sondern (betriebssystemabhängig und abhängig von der Rechnerkonfiguration) wird eher das LAN als Default für den Interconnect genutzt.

Der Default ergibt sich vermutlich daraus, dass Oracle den "uname" der Maschine abfragt und diesen als "gethostbyname" oder "getaddrbyname" verifiziert und dann als Verbindung zwischen den beiden Instanzen festlegt.

Im folgenden wird anhand eines HP-Systems gezeigt, wie ein zusätzlicher Interconnect "gesehen" und konfiguriert werden kann.

Zunächst wird geschaut, welche Verbindungen zur Verfügung stehen.

Der Rechner ora1 ist so konfiguriert, dass auf lan1 der Heartbeat (ora1hb) und auf lan4 der Interconnect (ora1ic) liegt.

Anschließend wird über den Befehl "lanscan" nochmals die Hardware Konfiguration gescannt und die Verbindung verifiziert (siehe Abb. 1: Durch den Befehl "lanscan" erzeugte Ausgabe.).

Status aus der Sicht von Oracle

Es gibt einen konfigurierten Interconnect für Oracle RAC auf lan4, der jedoch nicht genutzt wird.

Über verschiedene Netzwerk-Befehle, wie z. B. den "lanadmin", kann man erkennen, dass kein Verkehr auf der Verbindung läuft.

Über den oradebug Aufruf unter sqlplus kann man endgültig prüfen, welcher Interconnect von Oracle genutzt wird. Man startet sqlplus und verbindet sich als Benutzer sys.

Über die folgenden oradebug Befehle bekommt man eine Tracedatei, in der der Interconnect genannt wird.

oradebug setmypid
oradebug ipc
oradebug tracefile_name

Dem Auszug aus dem Dump vom oradebug (siehe Abb. 2: Auszug aus dem Dump vom oradebug.) kann man entnehmen, dass der Datentransfer zwischen den Instanzen zur Zeit über das LAN (IP: 10.154.64.209) läuft.

Konfiguration des Interconnects

Der Interconnect kann über den init.ora Parameter cluster_interconnects explizit konfiguriert werden. Über diesen Parameter wird die Interconnect Adresse auf die dafür vorgesehene Verbindung gelegt.

auf der ora1
cluster_interconnects = 192.168.101.1
auf der ora2
cluster_interconnects = 192.168.101.2

Nach dem Restart der Datenbank ergibt die erneute Auswertung des oradebug, wie zu erwarten war, die neue Adresse aus (siehe Abb. 3: Auswertung des oradebug nach der Rekonfiguration.).

Es läuft ...

Über verschiedene Netzwerk-Befehle kann der Datenverkehr von RAC auf dem explizit dafür vorgesehenen Interface sehr detailliert verifiziert werden.

Wie oben schon erwähnt, wird von Oracle sehr viel Wert auf die Performance des sogenannten High Speed Interconnect gelegt. Relevant wird ein eigener Interconnect vor allem dann, wenn das "normale" LAN extrem unter Last gerät, wie beispielsweise bei Datensicherungen, etc.

Bei Datenbank-Lasttests zeigt sich, dass eher die CPUs und vor allem der Platten I/O zum Engpass werden als der Interconnect, wenn er - wie oben konfiguriert - explizit für Oracle zur Verfügung steht. Zu diesen Ergebnissen werden wir dann in der nächsten ORDIX News ausführlich berichten.

Christoph Lafeld (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen