Home > Oracle Direct NFS > dNFS mit mehreren Pfaden

dNFS mit mehreren Pfaden

Oracle dNFS mit mehreren Pfaden

Oracle dNFS unterstützt das transparente verteilen der IO Last auf bis zu 4 unabhängige Pfade. Fällt einer dieser Pfade aus, nutzt Oracle automatisch die verbleibenden Wege. Ein anderer Weg mehrere Netzwerkkarten zu kombinieren wäre Bonding/Truncing (LACP Load Balancing) wie dies auf Linux (und anderen Betriebssystemen) durchaus nicht unüblich ist. Das Problem bei dieser Vorgehensweise ist aber, dass dadurch ein zusätzlicher Overhead entsteht und die Netzwerkkarten nicht gleichmäßig ausgelastet werden. Das mag bei einem Netzwerk über das die Anforderungen zur Datenbank gelangen durchaus OK sein (weil hier die Latenz weniger Rolle spielt und auch die Datenmengen meist geringer sind). In Richtung Storage kommt es aber sehr auf die Latenz an. Oracle hat zu diesem Thema übrigens schon im White Paper "Oracle Database 11g - Direct NFS" Stellung bezogen und auch Beispiele gebracht, die zeigen, dass Direct NFS deutlich mehr Durchsatz bei geringerer CPU Belastung bringt wie eine Lösung mit OS NFS Client und Bonding.

 

In diesem Artikel wollen wir die zwei möglichen Konfigurationen für mehrere Netzwerkkarten/Pfade zwischen dem Datenbank Server unter Linux und der NAS Storage aufzeigen. Oracle dNFS gibt es für alle Oracle Datenbanken unter UNIX sowie unter Windows - die Konfiguration ist grundsätzlich auf allen Plattformen gleich.

Beschreibung des Environments

  • Der Linux Datenbank Server "dbserver" und zwei Netzwerkkarten (eth0, eth1) im Datenbank Storage Lan.
  • Die NAS Storage "nasstorage" mit ebenfalls zwei Netzwerkkarten im Datenbank Storage Lan.
  • Die Datenbank liegt komplett im NFS Export: /vol/oracledb_orcl das unter /u01/app/oracle/oradata/orcl gemounted ist.

Oracle verlangt, dass unter Unix (nicht unter Windows) auch am Operating System ein NFS Mount für die Datenbank durchgeführt wird. Dieser sieht wie folgt aus:

Eintrag in /etc/fstab (Linux):
nasstorage:/vol/oracledb_orcl /u01/app/oracle/oradata/orcl rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,actimeo=0,vers=3,timeo=600 0 0

Des weiteren muss die Datenbank Software für die Nutzung von dNFS konfiguriert werden - die Anleitung dazu finden Sie in unserem Artikel: Oracle dNFS richtig konfigurieren.

Variante #1: dNFS mit mehreren IPs in verschiedenen Subnetzen (empfohlene Variante!)

Bei dieser Variante werden pro Pfad verschiedene IP (Sub)Netze verwendet. Das hat den Vorteil, dass man keine zusätzlichen Routing Einstellungen benötigt und der Datenfluss zwischen dbserver und nasstorage ganz klar erkennbar ist. Wenn Sie VLANs nutzen können wahlweise beide IP Netze im gleichen oder verschiedenen VLANs sein - es macht keinen Unterschied bei der Konfiguration oder im Betrieb.

Für diese Variante nehmen wir folgende IP Addresskonfiguration an:

dbserver eth0: 192.168.0.1 / 255.255.255.0
dbserver eth1: 192.168.1.1 / 255.255.255.0
nasstorage nic1: 192.168.0.101 / 255.255.255.0
nasstorage nic2: 192.168.1.101 / 255.255.255.0

Damit Oracle versteht, dass es mehrere Pfade für den Zugriff auf die Daten gibt, muss man die Konfigurationdatei oranfstab wie folgt erzeugen:

/etc/oranfstab
server: nasstorage
local: 192.168.0.1 path: 192.168.0.101
local: 192.168.1.1 path: 192.168.1.101
export: /vol/oracledb_orcl mount: /u01/app/oracle/oradata/orcl

Sobald mit die Oracle Datenbank startet, sollte man in der View v$dnfs_channels Einträge für beide Pfade zur Storage finden. In unserem Bespiel muss die folgende Query zwei Zeilen zurück bringen:

select SRVNAME, DIRNAME from v$dnfs_servers;
SRVNAME       DIRNAME
------------- ----------------------------
192.168.0.101 /u01/app/oracle/oradata/orcl
192.168.1.101 /u01/app/oracle/oradata/orcl

Wenn man jetzt Last auf der Oracle Datenbank erzeugt, wird man am Datenbank Server feststellen, dass beide Netzwerkkarte praktisch ident stark genutzt werden. In dem Beispiel sind nur eth0 und eth1 im Ergebnis enthalten:

ifconfig | grep 'RX bytes'
RX bytes:408752260 (389.8 MiB) TX bytes:224249764 (213.8 MiB)
RX bytes:408752914 (389.8 MiB) TX bytes:224267246 (213.8 MiB)

Wie Sie sehen ist die Vorgangsweise und Konfiguration in dieser Variante relativ einfach. Fehler in der Konfiguration bzw. bei Komponenten können ebenfalls einfach erkannt werden - meist reicht schon ein einfaches "ping" um zu erkennen ob und wo es Probleme gibt.

Variante #2: dNFS mit mehrere IPs im gleichen Subnetz (nicht empfohlen, nur eine Notlösung!)

Bei dieser Variante gibt es gleich mehrere Probleme:

  • Wenn ein Server zwei Netzwerkkarten im gleichen IP Netzwerk hat, wählt der TCP Stack selbsständig aus über welche IP Adresse er spricht - beispielsweise kann ein PING vom dbserver zum nasserver wahlweise über eth0 oder eth1 erfolgen - damit load balancing funktioniert muss man dies verhindern!
  • Nicht bei jedem Betriebsystem kann man konfigurieren über welche IP Adresse mit welcher Zieladresse gesprochen wird (das Bedarf dann umfangreicherer Konfiguration im Kernel oder IO Subsystem)
  • Fehlkonfiguration sind schwerer/komplexer zu erkennen.

Aus diesem Grund raten wir von dieser Vorgangsweise explizit ab!

Für diese Variante nehmen wir folgende IP Addresskonfiguration an:

dbserver eth0: 192.168.0.1 / 255.255.255.0
dbserver eth1: 192.168.0.2 / 255.255.255.0
nasstorage nic1: 192.168.0.101 / 255.255.255.0
nasstorage nic2: 192.168.0.102 / 255.255.255.0

Wie man sieht, sind alle IP Adressen im gleichen IP Subnetz. Wenn man jetzt am dbserver folgenden Befehl ansetzt, kann man (noch) nicht sagen welche IP Adresse (192.168.0.1 oder 192.168.0.2) genutzt wird:

ping 192.168.0.101

Um dieses Problem zu beheben, gibt es mehrere Lösungswege

Zusätzliche Einträge in der oranfstab

Dieser Weg funktioniert nicht auf allen Oracle Datenbank Versionen (beispielsweise 11.1.0.6) und auch unter Windows ist dieser Weg nicht möglich.

/etc/oranfstab
server: nasstorage
local: 192.168.0.1 path: 192.168.0.101
local: 192.168.0.2 path: 192.168.0.102
dontroute
mnt_timeout: 3600
export: /vol/oracledb_orcl mount: /u01/app/oracle/oradata/orcl

Die Konfigurationsoption "dontroute" sagt Oracle, dass der Zugriff von 192.168.0.1 nur auf 192.168.0.101, bzw von 192.168.0.2 auf 192.168.0.101 erfolgen soll. Ob dies wirklich so ist, kann man nicht verifizieren!

Statische Routen am Operating System

Bei dieser Variante erzeugt man statische Host Routen am Operating System. Der Nachteil dabei, wenn man an der IP Konfiguration etwas ändert, kann dies zu Problemen führen und/oder dazu führen, dass nur noch ein Pfad genutzt wird.

echo "192.168.0.101 via 192.168.0.1" >> /etc/sysconfig/network-scripts/route-eth0
echo "192.168.0.102 via 192.168.0.2" >> /etc/sysconfig/network-scripts/route-eth1

Bei älteren Linux Kernel (bzw. ohne NetzwerkManager) muss man diese Routen noch aktivieren:

/etc/sysconfig/network-scripts/ifup-routes eth0
/etc/sysconfig/network-scripts/ifup-routes eth1

Alternativ kann man diese Routen auch dynamisch mittels "route add" anlegen, sinnvollerweise via script in /etc/rc.local.

route add -net 192.168.0.101 netmask 255.255.255.255 dev eth0
route add -net 192.168.0.102 netmask 255.255.255.255 dev eth1

Beide Variante sind aufwändiger und fehleranfälliger als die empfohlene Variante mit verschiedenen IP Subnetzen. Da die Einstellungen nur am Client erfolgen, wird stillschweigend vorausgesetzt, dass die NAS Storage immer über die gleiche IP Adresse antwortet, über die die Anfrage eingetroffen ist. Das ist aber nicht garantiert! Somit kann es passieren, dass trotz korrekter Konfiguration auf der Datenbank Server Seite auf der Storage Seite nur eine Netzwerkkarte/IP (und somit nur ein Pfad) genutzt wird!

Zusammenfassung

Grundsätzlich unterstützt Oracle dNFS ein Load Balancing über bis zu vier Netzwerkkarten. Die einfachere und aus unserer Sicht sinnvollere Variante ist, dass man für jede Netzwerkkarte eine IP Adresse in einem eigenen IP Subnetz nutzt - nur damit ist 100% sichergestellt, dass wirklich alle Pfade gleichmäßig von Oracle genutzt werden können.

Quellen Referenz