SAN versus NAS - Datenbank Performance

Dieses Webinar finden Sie auch auf unserem Youtube Webinar Channel.

Server und Storage für diesen Vergleich

Für die Performancetests haben wir eine HP ProLiant DL360e Gen8 mit Dual Intel® Xeon® Processor E5-2407 mit je 4 Cores @ 2.2GHz eingesetzt. Für die SAN tests haben wir einen Qlogic ISP2532 HBA Dual 8GBit genutzt und für die NFS Tests eine Intel® X520-DA2 NIC mit 2* 10 Gbit (PCIe 2.0, x8). Da der Server nur einen PCIe 3.0 x8 Port besitzt, haben wir die Karten zwischen den Tests jeweils umgebaut.

Als Storage ist eine NetApp FAS 8020 mit zwei Heads (Kontrollern) genutzt worden, die über jeweils 24GB Cache verfügen und SAN mit 2mal 8GBit und NAS mit 2 mal 10GBit - jeweils pro Head - zur Verfügung stellt.

Die Infrastruktur Komponenten bestehen aus einer SAN Fabric in Form eines Brocade 300 (mit 8GBit Ports) sowie einem Cisco Nexus 3172 LAN Switch mit 10GBit SFP+.

Datenbank Konfiguration

Die Tests wurden mit Oracle 19c (19.10) und drei jeweils 12GB großen Datenbanken auf SAN (ASM und Filesystem) sowie NAS (Oracle dNFS) durchgeführt. Da die Datenbank viel kleiner als das Storage Cache war, lag diese während der Tests komplett im Memory der Storage. Um eine optimale Performance zu erreichen, wurde der Instance Parameter FILESYSTEMIO_OPTIONS auf SETALL gesetzt.

Die SAN Tests haben wir einmal mit 2 LUNs (eine LUN pro Storage Head) und einmal mit 10 LUNs (5 LUNS pro Storage Head) durchgeführt, wobei im ASM pro Storage Head eine DISKGROUP mit EXTERNAL REDUNDANCY eingesetzt wurde. Beim Filesystem wurde ein LVM pro Storage Head genutzt und im Fall von 5 LUNS mit LVM Striping konfiguriert.

Für Oracle dNFS wurden zwei IP Netzwerke genutzt, damit Oracle dNFS selbst Load Balancing durchführen kann. Damit dies korrekt funktioniert, wurde folgende ORANFSTAB genutzt:

server: dbmdemodb04
local: 10.146.1.49 path: 10.146.3.17
local: 10.147.1.49 path: 10.147.3.17
export: /nfs49_data1 mount: /u01/app/oracle/oradata/NFSDB/data1

server: dbmdemodb05
local: 10.147.1.49 path: 10.147.3.18
local: 10.146.1.49 path: 10.146.3.18
export: /nfs49_data2 mount: /u01/app/oracle/oradata/NFSDB/data2

Die Messungen

Wurden mit IO Calibrate durchgeführt, dass zuerst viele random reads durchführt um die maximalen IOPS zu ermitteln und danach auf sequential reads für die MBPS Ermittlung einsetzt. Mehr Informationen zu I/O Calibrate in unseren Webinaren zu diesem Thema.

Ergebnisse mit einer LUN pro Storage Head

ASM Datenbank

• max_iops = 104.580
• latency = 0,11 ms
• max_mbps = 1.394

FileSystem Datenbank

• max_iops = 120.071
• latency = 0,24 ms
• max_mbps = 1.400

NFS Datenbank

• max_iops = 149.600
• latency = 0,22 ms
• max_mbps = 1.994 und damit am physischen Limit von 2 mal 10GBit LAN

Wie man hier sehr deutlich erkennt, ist NFS sowohl bei den IOPS als auch bei den MBPS deutlich in Führung. Mit zwei LUNs im SAN Bereich kann man die maximale Performance einfach nicht abrufen - man braucht dafür einfach mehr LUNs.

Ergebnisse mit fünf LUN pro Storage Head

ASM Datenbank

• max_iops = 173.911
• latency = 0,8 ms
• max_mbps = 1.537 und damit am physischen Limit von 2 mal 8GBit SAN

FileSystem Datenbank

• max_iops = 198.682 und damit am physischen Limit von 2 mal 8GBit SAN
• latency = 0,52 ms
• max_mbps = 1.537 und damit am physischen Limit von 2 mal 8GBit SAN

Mit mehr LUNs schafft man zwar etwas mehr Durchsatz wie bei NFS mit zwei Mounts, der Aufwand dafür ist aber beträchtlich. Natürlich kann man auch mehr NFS Exports zur Verfügung stellen, das hab wir aber nicht getestet, weil es in der Realität praktisch nicht vorkommt.

CPU Auslastung am DB Server

Hier sieht man, dass speziell die random reads (IOPS) den Datenbank Server an die Leistungsgrenzen getrieben haben. Das erklärt auch, warum die Latenz bei mehr LUNs angestiegen ist - der Server war im Überlastbereich der CPU. Im Fall von ASM und dNFS lagen dei Context Switches bei unter 10k/sec beim Filesystem teilweise über 100k/sec. Jeder Context Switch ist eine CPU Last, die auf die Datenbank Performance negative Einflüsse hat.

CPU Auslastung auf der Storage

Die CPU Auslastung war über alle Tests im Bereich von 80-90%, die Storage Latenz selbst lag aber bei unter 0.1ms - außer im ASM Bereich, wo diese teilweise bis auf 0.15ms gestiegen ist.

Zusammenfassung

• Oracle dNFS weist mit Abstand die geringsten I/O Latenzen auf und braucht am DB Server weniger CPU im Vergleich zu ASM. Das liegt an dem “direct to wire“ dNFS Protokol.
• Wenn man im SAN Bereich nur wenige LUNs nutzt, läuft man in Limitationen.
• Die Datenbank am Filesystem hat sehr gut abgeschnitten, weil wir den Engpass „Disk Queue“ durch die Nutzung von 10 LUNs ausgeglichen haben.
• Bei NFS ist der Administrationsaufwand deutlich geringer – mehr dazu in unserem Webinar

Interesse an diesem Webinar geweckt?

Dann schauen Sie es sich doch direkt auf unserem Youtube Channel an: DB Masters Webinar: SAN versus NAS - Oracle Datenbank Performance.

Vergessen Sie nicht unseren Youtube Channel zu abonnieren, damit Sie keines unserer Videos verpassen!