Home > Konzepte und Infrastruktur > SALK - dNFS Einführung

SALK - dNFS Einführung

SALK Logo

 

Erfolgreiche Umstellung von SAN auf dNFS bei den SALK

Ernst Berger, DBA bei den SALK, Salzburger Landeskliniken zum Projekt

Der eigentliche Auslöser des Projekts war ein Migrationsprojekt von HP-UX Itanium mit EVA8000 Storage auf Linux Serversysteme und NetApp Storage. Im Rahmen dieses Projekts kam von DB Masters die Empfehlung von einer SAN Lösung mit Veritas Storage Foundation HA auf Oracle dNFS umzusteigen.

Einer der Vorteile dieser Umstellung wäre auch, dass man beim Einsatz von NFS anstatt dem Veritas Filesystem die NetApp Snapshotting Technologie für Oracle Datenbank-Backups nutzen könnte. Da immer wieder der Bedarf für eine "Kopie" der Produktionsdatenbank im Raum stand, war auch aus diesem Grund Oracle dNFS sehr interessant.

Details zum Projekt

Im Rahmen des Projekts mussten neben der technischen Umsetzung auch viele Herausforderungen durch entsprechende Beweise widerlegt werden. Neben den üblichen "Never Change a Running System" Syndrom und unbegründeten Bedenken des Applikationsherstellers musste das Projekt in vielen kleinen Schritten mit entsprechenden Proof of Concepts durchgeführt werden.

Dieses aufteilen in mehrere kleine Schritte hat nicht nur geholfen die Herausforderungen durch entsprechende Nachweise zu wiederlegen, es hat auch geholfen, die Vorteile von Oracle dNFS im Bereich Ressourcenverbrauch und Performance ganz genau heraus zu arbeiten.

Erste Schritte: die Voraussetzungen schaffen

Damit man Oracle dNFS performant nutzen kann, wurde ein eigenes Datacenter-Netzwerk für die Storageanbindung mit 10GBit und Jumbo Frames geschaffen, die technischen Voraussetzungen dafür waren bereits vorhanden. Da das Thema Oracle dNFS schon vom Beginn des Projekts an mit eingeplant war, war dies letztendlich der einfachste Schritt.
Mit der ersten Test-Datenbank mit Oracle dNFS konnte diese Technologie hausintern vorgestellt werden, die Vorteile herausgearbeitet (Performance, Backup mit SnapManager für Oracle,...) und letztendlich die verschiedenen Applikationen auf dNFS validiert werden. Dabei wurde unter anderem der Status von dNFS Support bei SAP und anderen Applikationsherstellern ermittelt und dokumentiert. Den Abschluss bildete eine Präsentation der Testergebnisse.

Ergebnisse mit Oracle I/O Calibrate

Alle Messungen wurden mehrfach - allerdings während normalen Betriebs - durchgeführt. Dadurch ist es zu deutlichen Schwankungen in den Messergebnissen gekommen, es wird immer der schlechteste und der beste Wert angegeben.

System IOPS SAN IOPS dNFS Bemerkung
INF1 N/A ca. 90.000 Kleine Datenbank, die ins Cache der NetApp Storage gepasst hat. Dieser Test zeigt das Performancelimit der NetApp aus dem Cache heraus.
PRE 6.000 bis 10.000 18.000 bis 22.000 Die Umstellung auf Oracle dNFS hat den Durchsatz mehr wie verdoppelt.
TST 8.000 bis 10.000 18.000 bis 26.0000 Daten SAN: Sep 2013, Daten NAS: Sep 2014
und das obwohl in dem Zeitraum die gesamte Last auf den Systemen deutlich gestiegen ist!

Wie diese Tabelle sehr beeindruckend zeigt, ist der Durchsatz mit Oracle dNFS immer zumindest um den Faktor zwei besser als die Variante mit FC-SAN und dem Veritas Volume Manager bzw. Filesystem. Das wirft aber gleich die nächste Frage auf: welche Auswirkung hat dies auf die CPU-Auslastung der Server?

Zweiter Schritt: Beweisen, dass die CPU dadurch nicht stärker belastet wird.

Dies haben wir bei einer unserer Kernapplikationen ermittelt, wobei man dazu sagen muss, dass die Applikation selbst nicht so datenbanklastig ist, sondern eher die Applikationsserver belastet.

Vor der Umstellung auf Oracle dNFS lag die durchschnittliche CPU Auslastung am Datenbank Server bei 5 bis 10 Prozent mit Peaks (ausgenommen Backup) auf maximal 20 bis 25 Prozent. Nach der Umstellung liegt die durchschnittliche CPU Auslastung bei 2 % und der größte Peak war bei 8 %!
Konservativ gesagt: Vom Veritas Filesystem auf Oracle dNFS sparen wir zwei Drittel der CPU.

Das ist jetzt für diese Datenbank alleine nicht wirklich relevant, aber durch die deutliche CPU Ersparnis können wir mehr Datenbanken auf weniger Systeme konsolidieren.

Dritter Schritt: Nachweisen dass der Datendurchsatz durch die Umstellung verbessert und die Latenz reduziert wurde

Dazu wurde eine der wichtigsten Datenbanken am Wochenende (wenn die Systemlast auf den Servern und der Storage am niedrigsten waren) nochmals mit I/O Calibrate vermessen. Es wurde dabei darauf geachtet, dass möglichst keine Störfaktoren wie Batchverarbeitungen, Backups,... in diesem Zeitbereich gefallen sind.

Messung SAN / FC Oracle dNFS Verbesserung Bemerkung
Max. IOPS 18.114 32.214 Rund 80% mehr I/Os pro Sekunde -
Max. MBPS 332 382 Rund 15% mehr MB pro Sekunde Durchsatz Hier liegt der Engpass in der Anzahl der HDDs in der Storage.
Latenz bei DBF I/O großteils zwischen 8 und 16ms großteils zwischen 4 und 8ms 50% niedrigere Latenz! Da Oracle nicht genauer auflöst, können nur die groben Werte wiedergegeben werden.

Die deutlichen besseren Ergebnisse sind schon einmal nicht schlecht, aber wie wirkt sich das letztendlich aus?

Vierter Schritt: Nachweis, dass davon auch etwas in der Verarbeitung merkbar ist

Das nachweisen innerhalb der Applikation hat immer eine gewisse Unschärfe: "Was befindet sich schon im Cache der Instanz?" bzw. "Wie hoch ist die aktuelle Last in der Instanz?" oder "Hat sich die Datenmenge vielleicht zwischen den Messzeitpunkten verändert".

Aus diesem Grund haben wir RMAN Backups der Datenbank als Messkriterium herangezogen, da dies nachweislich vor und nach der Umstellung die gleichen Datenmengen angreift und nicht vom Caching der Instanz profitiert. Bei beiden Messungen war sowohl die Datenbank als auch die Backup Destination auf den gleichen Disken in der Storage als auch mit der gleichen Technologie - also SAN bzw. NAS - angebunden.

Datenbankgröße Laufzeit SAN Laufzeit dNFS
500GB ca. 90 Minuten ca. 30 Minuten
2TB über 3 Stunden knapp über einer Stunde

Das bedeutet, dass die Backupdauer auf 1/3 gefallen ist. Gleichzeitig war die Auswirkung bei dNFS für die Benutzer weniger spürbar.

Letzer Schritt: Nutzen der Technologie

Nach dem erfolgreichen Umstieg auf Oracle dNFS konnten endlich die Vorteile der NetApp Snapshot Techologie mit dem SnapManager für Oracle nutzbar gemacht werden.

Wir können jetzt Testdatenbanken mittels Cloning für verschiedene Aufgaben wie Schulung, Entwicklung,... innerhalb von wenigen Minuten zur Verfügung stellen, die auf dem Storage praktisch keinen Platz verbrauchen und die Produktivsysteme während der Kopie nicht belasten. Dadurch ergeben sich beträchtliche Storageeinsparungen sowie die Möglichkeit die Kopie jederzeit durchzuführen.

Ergebnis der Migration auf Oracle dNFS

  • Deutlich bessere Performance und bessere Antwortzeiten für die Benutzer.
  • Geringere CPU Belastung auf den Datenbank Servern, somit ist eine weitere Konsolidierung möglich.
  • Durch die Verwendung von Datenbank Clonen und der damit verbundenen Einsparungen im Storage Bereich, muss der Storage erst zu einem späteren Zeitpunkt erweitert werden.
  • Massive Reduktion der Backupzeiten
  • Deutlich Vereinfachung der Administration (NFS Mounts versus SAN/Veritas Storage Foundation Administration, Backup und Recovery, erzeugen von Testdatenbanken,...)

Zusammenfassung durch Ernst Berger

Die Umstellung auf Oracle dNFS war eines der erfolgreichsten Projekte der letzten Zeit. Wir konnten die Performance und Skalierbarkeit ohne zusätzliche Kosten im Bereich Storage, Server steigern und benötigten entspreche Erweiterungen/Upgrades erst zu einem späteren Zeitpunkt. Die Einsparung in der Administration durch den Wegfall von LUN´s und Veritas Filesystem ist beträchtlich, dadurch gewinnen wir Zeit für andere Dinge. Gleichzeitig ist der Aufbau eines neuen Systems mit NFS viel einfacher als mit LUN´s und FC, damit steigt auch die Zuverlässigkeit des Gesamtsystems.

Inzwischen haben wir auch alle SAP-Systeme unter Linux auf dNFS umgestellt, NFS mit Linux und Oracle hat sich als Standard etabliert, neue Systeme werden mit dieser Technologie umgesetzt.