Oracle 11g Direct Network File System (dNFS) im Praxistest

Ohne Umwege ans Ziel

Die Entscheidung für eine Oracle Storage-Architektur fällt einem Administrator nicht leicht. In der Vergangenheit wurde in aller Regel auf Storage-Area-Network (SAN)-Technologie (Fiber Channel) gesetzt. Doch der Trend ändert sich. So findet die Technologie Network Attached Storage (NAS) zunehmend Einzug in viele IT-Abteilungen. Oracle Datenbanken, deren Speicherbereiche via NFS eingebunden werden, sind heute keine Seltenheit mehr. Auch Oracle unterstützt diesen Trend. Ab der Version 11g kann die Funktion "Direct NFS (dNFS)“ genutzt werden. In dNFS sind Oracle-eigene NFS-Treiber bereits in der Datenbank-Software integriert, sodass z. B. mühselige Parametereinstellungen entfallen. Zudem können Performance-Vorteile erreicht werden.

Abb. 1: NFS und dNFS im Vergleich. Oracle übernimmt die Herrschaft über die NFS-Mounts. Die Kontextwechsel entfallen, die Performance steigt. Vergrößern shell> cd $ORACLE_HOME/lib shell> mv libodm11.so libodm11.so_old shell> ln -s libnfsodm11.so libodm11.so Abb. 2. dNFS einrichten. server: MeinFiler.ordix.de path: 192.168.65.132 path: 192.168.65.131 export: /vol/oradata11g mount: /oracle/ora11g/data export: /vol/oralog11g mount: /oracle/ora11g/log export: /vol/oraarch11g mount: /oracle/ora11g/arch Abb. 3: Die orafstab liefert der Instanz die Informationen, welches Device von welchem Server einzubinden ist. 1* select SVRNAME, DIRNAME from v$dnfs_servers SQL> / SVRNAME DIRNAME ------------------------------ -------------------- 192.168.65.131 /vol/oradata11g 192.168.65.131 /vol/oralog11g SQL> alter system archive log current; System altered. SQL> select SVRNAME, DIRNAME from v$dnfs_servers 2 / SVRNAME DIRNAME ------------------------------ -------------------- 192.168.65.131 /vol/oradata11g 192.168.65.131 /vol/oralog11g 192.168.65.131 /vol/oraarch11g Abb. 4: View v$dnfs_server. select filename, nfs_read, nfs_write from v$dnfs_stats a, v$dnfs_files b where a.pnum=b.pnum SQL> / FILENAME NFS_READ NFS_WRITE -------------------------------------------------- --------- /oracle/ora11g/data/control01.ctl 945 1252 /oracle/ora11g/log/control02.ctl 945 1252 /oracle/ora11g/data/system01.dbf 24 117 /oracle/ora11g/data/sysaux01.dbf 24 117 /oracle/ora11g/data/undotbs01.dbf 24 117 /oracle/ora11g/data/users01.dbf 24 117 /oracle/ora11g/data/temp01.dbf 24 117 /oracle/ora11g/log/redo01.log 50 205 /oracle/ora11g/log/redo02.log 50 205 Abb. 5: NFS Statistiken.

Oracle und NFS

Um eine Oracle Datenbank per NFS zu betreiben, mussten bis zur Version 10g die jeweiligen Devices über die entsprechenden NFS-Treiber des Betriebssystems eingebunden werden. Da es sich bei NFS um ein generell verfügbares und genutztes Protokoll für unterschiedliche Anwendungen handelt, ist es verständlich, dass es nicht für den Betrieb einer Oracle Instanz optimiert wurde. Daher wurde in der Vergangenheit großes Augenmerk auf die Auswahl und Konfi guration der NFS Mount-Optionen gelegt. Viele Storage-Anbieter haben aus diesem Grund Best-Practice-Guides für die Anbindung ihrer Systeme veröffentlicht, z. B. die Firma NetApp für Oracle Single Instances unter Linux [1]. Um diese Anleitung nutzen zu können, benötigen Sie einen Account für das NetApp-Supportportal.

Oracle Direct NFS (dNFS)

Mit der Oracle Version 11g wurden nun eigene NFS-Treiber in die Datenbank-Software integriert. Dies erspart dem Administrator die Auswahl und "Einstellung“ der NFS-Parameter. Darüber hinaus bietet die Integration auch Performance-Vorteile. Fordert eine Oracle Instanz die Daten eines NFS-Devices an, so sind Kontextwechsel zwischen dem Benutzerund Kern-Modus die Folge. Diese Wechsel kosten Zeit. Natürlich resultieren daraus auch Schreibaktionen auf ein NFS-Device in diesen Kontextwechseln. Diese entfallen, wenn die Datenbank selbst die Verwaltung über die I/OOperationen übernimmt (siehe Abbildung 1).

Zusätzlich umgehen die Oracle Treiber den Betriebssystem-Cache für NFS I/O-Operationen. Bis dato wurden Oracle Daten oftmals im Cache des Betriebssystems und in der bereitgestellten System Global Area (SGA) der Instanz gehalten. Die daraus resultierenden Kopieraktionen zwischen diesen beiden Speicherbereichen belasteten neben dem Hauptspeicher des Servers auch die CPU.

NFS = need for speed?

Was bringt dNFS in der Praxis? Im Internet sind zum Thema Performance-Optimierung einige Erfahrungsberichte zu finden (z. B. von der Firma Oracle [2]). Eine wesentliche Grundaussage aus diesen Reports ist, dass dNFS wesentlich besser skaliert als das betriebssystemeigene NFS, wenn eine Kanalbündelung genutzt wird (ab 2 Kanälen). Wird lediglich ein Kanal vom Server zum Filer genutzt, bietet dNFS keinen Vorteil gegenüber der Betriebssystemvariante. Es bietet allerdings auch keinen Nachteil. Insofern lohnt sich der Einsatz von dNFS auch hier, da die Komplexität der Administration deutlich reduziert wird. Fehlerquellen bei der Auswahl der Mount-Optionen werden vermieden.

NFS und Windows

Da die NFS-Treiber nun Bestandteil der Datenbank sind, können auch Oracle Instanzen unter Windows via NFS auf NASDevices zugreifen. Ein weiterer Vorteil, der sich aus Sicht eines Administrators ergibt, ist die Tatsache, dass für alle Plattformen die NFS-Komponenten vom selben Hersteller kommen wie die Datenbank-Software. Dies erleichtert im Fehlerfall die Kommunikation und beschleunigt die Fehlerbeseitigung, da von nun an nicht mehr zwischen Betriebssystem- und Datenbankhersteller "vermittelt“ werden muss.

dNFS einrichten

Die Einrichtung von dNFS ist relativ einfach. Zunächst wird die Standard-Bibliothek ODM (Oracle Disk Manager) gegen den dNFSTreiber getauscht (siehe Abbildung 2).

Zusätzlich müssen die Mount-Anweisungen in einer eigenen Konfigurationsdatei (ähnlich der (v)fstab bei Linux/Solaris) bereitgestellt werden. Diese Datei wird per Default in den folgenden Pfaden gesucht:

• $ORACLE_HOME/dbs/orafstab
• /etc/orafstab
• /etc/mtab

ORAFSTAB

Damit die Instanz darüber informiert ist, welches Device von welchem Server einzubinden ist, sind die entsprechenden Informationen in der orafstab zu hinterlegen (siehe Abbildung 3).

Bevor die Instanz gestartet wird, sind die Devices per Hand konventionell – über die Betriebssystem-Treiber – einzubinden. Beim Starten der Instanz übernimmt dann Oracle mittels des dNFS-Clients die Kontrolle über die entsprechenden Devices. Die eingestellten Mount-Optionen (z. B. aus der /etc/fstab) spielen dann keine Rolle mehr für die weitere Kommunikation.

Aktuell können bis zu vier Pfade parallel konfiguriert werden. Im Beispiel in Abbildung 3 sind es lediglich zwei. Dies erhöht den Datendurchsatz (Load Balancing) und gewährleistet eine höhere Verfügbarkeit, falls eine der Verbindungen ausfällt.

NFS-Kontrolle

Um sich zu vergewissern, ob der dNFS-Client seine Arbeit auch zufriedenstellend erledigt, stellt Oracle vier Systemsichten zur Verfügung:

• v$dnfs_servers: Welche Filer sind per NFS angebunden?
• v$dnfs_files: Welche Dateien sind aktuell geöffnet?
• v$dnfs_channels: Über welchen Pfad werden die Server erreicht?
• v$dnfs_stats: Performance-Kennzahlen

Interessant ist die Tatsache, dass dNFS erst dann die Kontrolle über Devices übernimmt, wenn sie benötigt werden. Das erste SELECT-Statement (siehe Abbildung 4) zeigt den Zustand direkt nach dem Start der Instanz. Zu diesem Zeitpunkt wurden noch keine archivierten Redo-Logs in das dafür zuständige File-System geschrieben. Nachdem ein Archiv erzwungen wurde, kontrolliert die Instanz auch das für die Archive zuständige Volume (siehe zweites SELECT-Statement in Abbildung 4).

Die Statistik in Abbildung 5 zeigt, wie oft auf welche Datei lesend oder schreibend zugegriffen wurde.

Fazit

dNFS ist einfach zu konfigurieren und unproblematisch im Einsatz. Sicher wird diese Technologie mit dem anhaltenden Trend von NAS-Storage für Oracle Datenbanken und dem zunehmenden Verbreitungsgrad der Version 11g immer mehr Beachtung finden.

Matthias Jung (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen