Anwenderbericht: Oracle auf NFS für maximale Flexibilität

Das Erstellen einer Architektur einer Storage-Umgebung für Oracle kann eine kniffelige Angelegenheit sein. Es gibt zwar keine Lösung „von der Stange“, aber es gibt eine Vielzahl von Informationen für jeden, der Oracle mit NetApp Storage einsetzen möchte, wobei viele dieser Informationen direkt von den Erfahrungen der Kunden stammen. Dieser Artikel geht genauer auf einen NetApp Kunden ein, der sich für NFS entschieden hat, um seine Oracle Storage-Anforderungen zu erfüllen.

Ich arbeite für ein regionales medizinisches Center mit insgesamt fast 15.000 Mitarbeitern, die über drei Krankenhäuser, ein Rehabilitationszentrum, Kliniken für die primäre Grundversorgung, Zentren für erweiterte medizinische Versorgung, ein Forschungsinstitut und ein Hospizzentrum verteilt sind. Zu den medizinischen Mitarbeitern zählen 3.100 Ärzte für mehr als 91 medizinische und chirurgische Fachgebiete.

Wir verwenden Oracle als Backend für unsere Anwendungen für die klinische Versorgung und die Finanzverwaltung, daher kommt es entscheidend auf die Performance und Verfügbarkeit der Oracle Umgebung an. Ein knappes IT-Budget in Verbindung mit einem wachsenden Bedarf an Storage – sowohl für Oracle als auch für andere Anwendungen – hat uns vor erhebliche Herausforderungen gestellt.

NetApp Storage in Verbindung mit NFS hat uns geholfen, unsere wachsenden Storage-Anforderungen ohne ein Überschreiten des Budgets zu erfüllen. Mit unserer NetApp Infrastruktur können wir schneller auf Änderungen reagieren als mit anderen Storage-Lösungen. In diesem Artikel werde ich beschreiben, wie wir Oracle für die Ausführung über NFS konfigurieren, unsere Strategie für Datensicherung und Disaster Recovery erläutern und die Vorteile erklären, die wir durch dieses Konzept erzielen.

Oracle Umgebung immer in Veränderung
Wie auch viele andere geschäftige Oracle-Abteilungen sind auch wir keineswegs statisch. Wir entwickeln uns ständig weiter, ändern etwas oder fügen etwas hinzu, um die Unternehmensanforderungen zu erfüllen. Wir benutzen die E-Business Suite ebenso wie eine Reihe von Anwendungen für Patientenverwaltung, Rechnungsstellung und Archivierung. Wir haben Datenbankinstanzen auf Oracle Datenbanken 8i, 9i und 10g laufen.

Vor zwei Jahren waren alle unsere Oracle Server noch monolithisch HP und Sun Server mit Host-basierter Hochverfügbarkeit. Inzwischen gehen wir zu Oracle Real Application Clusters (RAC) über und ersetzen oder ergänzen allmählich unsere Riesen-Server durch Cluster aus kostengünstigen Linux Servern.

Heute haben wir insgesamt etwa 24 Datenbankinstanzen und wir fügen etwa 1 TB an neuem Storage pro Monat für Oracle und andere Zwecke hinzu. Und hier kommt NFS ins Spiel. Wir fügen fortwährend Storage hinzu und ändern unsere Storage-Konfigurationen ständig, und NFS und NetApp machen diesen gesamten Prozess wesentlich einfacher, als wenn wir SAN Storage verwenden würden.

Warum Oracle auf NFS?
Der Hauptgrund dafür, dass wir NFS für Oracle bevorzugen, besteht darin, dass es uns Anpassungen einfacher macht. Wir können ein NFS Filesystem schnell erweitern oder verkleinern, um geänderte Anforderungen zu erfüllen. So kann ich z.B. ein 1 TB Aggregat nehmen und jeder von acht Anwendungen 100 GB geben, während ich 200 GB in Reserve behalte. Wir können dann jedes dieser NFS Volumes in wenigen Minuten erweitern (oder verkleinern) – und das ohne Unterbrechung des laufenden Betriebs. Wir können Veränderungen vornehmen, wann immer dies erforderlich ist, und das ohne großen Aufwand.

Wie die meisten IT-Abteilungen benutzen auch wir Storage-Systeme von unterschiedlichen Anbietern. Bei unserer SAN Hardware ist die Erweiterung eines Volumes erheblich aufwendiger. Eine Erweiterung dauert mindestens acht Stunden und es gibt keine Möglichkeit, ein Volume automatisch zu verkleinern. Bei SAN Storage-Systemen wird man häufig zu viel Storage-Kapazität bereitstellen, um zu vermeiden, dass man die Kapazität umständlich erweitern muss, was bei NetApp so einfach ist.

Ein weiterer Vorteil von NAS gegenüber SAN ist der geringere Administrationsaufwand. TCP/IP-Karten funktionieren direkt mit den Standardeinstellungen. Wir brauchen nicht viel Zeit mit der Aktualisierung von Treibern und Firmware zu verbringen, wie es bei HBA-Adaptern erforderlich wäre. Unsere DBAs bevorzugen eindeutig die NFS-Umgebung, weil sie ihnen wesentlich mehr Autonomie erlaubt. Man kann Oracle Tablespaces und Datendateien vergrößern, Snapshot Kopien von NetApp Volumes anlegen oder wiederherstellen, ohne einen Storage-Administrator hinzuziehen zu müssen, und man kann die benötigten Daten auf jedem Host (oder mehreren Hosts) unterbringen, und zwar mit einem einfachen NFS-Mount, was ein besonderer Vorteil von Oracle RAC ist.

Derzeit haben wir insgesamt zwölf NetApp Storage Systeme mit einer Rohkapazität von 190 TB. Zusätzlich zum Storage für unsere Datenbank/Applikations-Anforderungen haben wir kürzlich NearStore R200 hinzugefügt, um unsere radiologische und mammographische Bildarchivierung (PACS) zu unterstützen, und wir haben eine NetApp FAS3070 für externes Vaulting mit SnapVault eingerichtet, um unser Ziel zu erreichen, Tape Backups vollständig aus unserer Umgebung zu eliminieren.

Konfigurieren von NFS für Oracle
Anfangs hatten alle die Befürchtung, dass die Performance ein Problem darstellen würde, aber wenn man die Umgebung korrekt einrichtet, sollte dies nicht der Fall sein. Wenn wir eine NAS-Umgebung für Oracle konfigurieren, wenden wir im Prinzip dieselben Regeln an wie bei einem SAN. Wir richten ein privates Netzwerk ein und verwenden redundante Switches, um ein redundantes Fabric zu erstellen. Da Fibre Channel-SAN mit 2 GBit/s oder schneller läuft, erreichen oder übertreffen wir diesen Performancegrad durch Aggregieren mehrerer Gigabit-Ethernet-Verbindungen, so dass wir je nach Anwendung eine Bandbreite von 2 bis 6 GBit/s erzielen. Im Prinzip erstellen wir ein spezielles SAN, nur dass es mit einem anderen Protokoll läuft.

Um die bestmögliche Performance zu erzielen, ist noch etwas Tuning beim TCP/IP-Stack und bei NFS erforderlich. Glücklicherweise bietet NetApp einige hervorragende Ressourcen, aus denen exakt hervorgeht, was man tun muss. (Erfahren Sie mehr aus einem Tech OnTap Artikel in einer der letzten Ausgaben. (Englisch))

Datensicherung und Disaster Recovery
Egal, ob man sich für NAS oder SAN für Oracle entscheidet, Datensicherung und DR sind auf jeden Fall dabei entscheidende Erwägungen. Für unsere Oracle Umgebung haben wir einen RPO (Recovery Point Objective) von fünf Minuten und einen RTO (Recovery Time Objective) von vier Stunden für jede Datenbank festgelegt. Diese Ziele erreichen wir mit einer Kombination aus NetApp SnapVault und NetApp SnapMirror, so dass wir sowohl Datensicherung als auch Disaster Recovery mit einer vollständig bandfreien Lösung bereitstellen.

Jede Nacht um 1:00 Uhr versetzen wir alle unsere Oracle Datenbanken in den Hot-Backup-Modus und erstellen von jeder eine Snapshot-Kopie mit einem speziell dafür geschriebenen Script. Dies dauert etwa 10 Minuten. Um 1:15 Uhr läuft dann SnapVault und sichert alle diese Veränderungen auf unseren DR-Standort. Wir drosseln die Performance auf 20 MBit/s, so dass wir keine Produktionsanwendungen beeinträchtigen. Dadurch erhalten wir praktisch jede Nacht ein vollständiges Backup jeder Datenbank einschließlich externer Speicherung. Wir halten die nächtlichen Backups der jeweils letzten 20 Tage online. Bei Datenbankanwendungen muss man nicht Jahre zurückgehen. Wir müssen uns nur vor möglichen Anwendungsfehlern schützen, die ein Rollback erfordern würden.

Unsere sämtlichen Archivierungslogdateien sind auf separaten Volumes gespeichert, und wir verwenden NetApp SnapMirror, um diese Volumes alle fünf Minuten mit dem DR-Standort zu synchronisieren. Die Kombination dieser beiden Systeme sorgt dafür, dass wir unseren RPO von fünf Minuten und unseren RTO von vier Stunden erreichen.

Zum Wiederherstellen kopieren wir das SnapVault Backup auf ein Volume mit Lese- und Schreibrechten und spielen dann die Archivierungslogdateien ein, die wir mit Hilfe von SnapMirror gespeichert haben. Wir verwenden SnapVault anstelle von SnapMirror zum Schutz der Oracle-Daten-Volumes und der gemeinsam genutzten Abteilungsdaten, um die Storage-Kosten zu reduzieren. Unsere primären Volumes befinden sich auf Fibre-Channel-Festplatte und unsere SnapVault Volumes auf SATA-Festplatten. Wir behalten fünf Tage an Snapshot-Kopien auf dem Primärspeicher und 20 Tage an Snapshot-Kopien am DR-Standort. Wir sind außerdem dabei, NetApp Deduplizierung für unsere gesicherten Daten bereitzustellen, um noch mehr Speicherplatz einsparen zu können.

Immer einen Schritt weiter
Mein Unternehmen ist immer sehr aktiv, wenn es um Effizienz geht. Wir verfügen bei uns über Geschäftprozess-Analysten, welche die Arbeitsabläufe überprüfen und überlegen, wie einzelne Dinge interagieren sollten. Sie überarbeiten die Abläufe, ehe wir eine Applikation einsetzen, um sicherzustellen, dass wir neue Software und Hardware möglichst effizient verwenden.

Wie jeder im IT-Bereich müssen wir uns ständig bemühen, mit den Anforderungen und dem Wachstum Schritt zu halten. Wir verfügen über drei DBAs und drei Administratoren speziell für UNIX- und Linux Server und Storage. Weil unsere NetApp Storage-Systeme, die für NAS konfiguriert sind, so einfach zu verwalten sind, ist weniger als ein Vollzeitadministrator für deren gesamte Verwaltung erforderlich, wodurch Ressourcen für andere Arbeiten freigesetzt werden. Im Verlauf der letzten Jahre ist unsere gesamte NetApp Storage-Infrastruktur um 80 TB gewachsen, aber wir mussten für deren Verwaltung keine zusätzlichen Mitarbeiter einstellen. Dank NetApp können wir mehr in kürzerer Zeit erledigen – und das mit weniger Mitarbeitern.

Jess Carruthers
Project Manager

Seit neun Jahren verwaltet Jess Carruthers Storage-Systeme von NetApp und Mitbewerbern, die Oracle ERP, Finanzdatenbanken, klinische Datenbanken, Dokumenten- und PACS- Bildverarbeitungsumgebungen unterstützen. 2005 konsoliderten Jess und sein Team als Beta-Installation für Data ONTAP 7G 28 TB Oracle- und CIFS-Storage von neun NetApp Systemen auf einen FAS960c- und ein NearStore System mit SnapVault. Die Auslastung stieg von 50% auf 76%. Das Team erweitert derzeit die Umgebung um drei FAS Cluster, drei NearStore Systeme und eine FAS3070 an einem Remote-DR-Standort.

Explore