Es muss nicht immer HANA sein Netapp-Speicher beschleunigen SAP-Projekte, so Netapp

Anbieter zum Thema

NetApp Deutschland GmbH

SAP Deutschland SE & Co. KG

Rittal GmbH & Co. KG

Das Abbilden SAP-spezifischer Anforderungen mit den Storage-System von Netapp war das Hauptthema eines Webinars des Storage-Spezialisten Netapp. Die Use Cases betreffen beschleunigte Projekte, einen einfachen Systembetrieb und eine hohe Agilität für hybride Betriebskonzepte. Autor Jürgen Frisch war für DataCenter-Insider dabei.

Auf SAP-Systemen laufen die wichtigsten geschäftskritischen Workloads von Unternehmen aller Größe. Der Storage-Spezialist Netapp arbeitet mit SAP zusammen, um die spezifischen Abläufe abzubilden und dabei eine Brücke zu schlagen zwischen der Infrastruktur und den SAP-Anwendungen.

Michael Schlosser, SAP Solution Architect bei Netapp, sagt: „Unsere Kunden sind überzeugt davon, den besten Speicher in ihrer SAP-Landschaft zu haben. Wir haben den Anspruch, die am besten geeigneten und sichersten Storage-Systeme zu liefern. Um das zu ermöglichen, schauen wir tief in die SAP-Systeme hinein.“ Bei den Use Cases für Netapp-Speicher in einer SAP-Landschaft verweist Schlosser auf drei Bereiche, nämlich beschleunigte Projekte, einen einfacheren Betrieb und eine gesteigerte Agilität für Multi-Cloud-Ansätze.

Die Projektbeschleunigung mit Netapp zeige sich sowohl beim Implementieren als eines SAP-Systems auch beim Upgrade auf eine neue Version. „In beiden Fällen ist jede Menge Testing erforderlich“, erläutert Schlosser. Dafür brauchen die Unternehmen immer einen definierten Stand ihres Systems. Mit unseren Applikationen lässt sich dieser quasi auf Knopfdruck automatisiert erstellen. Das beschleunigt die Projekte ebenso wie das parallele Testing.“

Vorteil in hybriden Umgebungen

Im Betrieb geht es darum, dass das System stabil läuft und sich möglichst einfach verwalten lässt. Nicht immer findet heute der Betrieb im hauseigenen Rechenzentrum statt. Viele Unternehmen betreiben ausgewählte Workloads in der Cloud, teilweise bei Hyperscalern wie Amazon oder Microsoft. „Wir verknüpfen die Systemteile im hauseigenen Rechenzentrum mit denen in der Cloud und sorgen außerdem dafür, dass ein Unternehmen ein ursprünglich für den Inhouse-Betrieb entwickeltes Modell Betriebsmodell eins zu eins in der Cloud übernehmen können“, berichtet Schlosser.

In einem hybriden Betriebskonzept laufen einige Systemteile on premises und andere in der Cloud. Einige Unternehmen betreiben beispielsweise die Kernsysteme im eigenen Haus, während unterstützende Systemteile wie Backup und Disaster Recovery aus der Cloud kommen.

Bei Backup und Recovery kommt die rasante Arbeit der Netapp-Systeme besonders zum Tragen, wie Schlosser an einem Beispiel aufzeigt. So dauert das Backup einer 4 Terabyte großen „SAP HANA“-Datenbank in der File-basierten Methode bei einem Datendurchsatz von 27 Megabyte pro Sekunde 4 Stunden und 5 Minuten.

Die Backup-Runtime reduziert sich um 99 Prozent

Bei der von Netapp verwendeten Snapshot-Methode ist diese Aktion hingegen bereits nach 1 Minute und 20 Sekunden abgeschlossen. Die Backup-Runtime hat sich also um 99 Prozent reduziert.

Ähnlich beeindruckend fällt der Unterschied beim Restore und Recovery aus: Während in der File-basierte Methode dafür 8 Stunden und 10 Minuten nötig sind, ist diese Aktion in der Snapshot-Methode bereits nach 1 Stunde und 40 Minuten abgeschlossen.

Ein weiteres Beispiel ist der technische Refresh eines SAP-Systems. Nach der File-basierten Methode benötigt diese Aktion 8 Stunden und 10 Minuten, in der Spapshot-Methode ist sie hingegen nach einer Stunde erledigt.

Rasantes Testing beschleunigt SAP Release Wechsel

Aus der Beschleunigung durch die Snapshot-Methode leiten sich laut Schlosser mehrere Use Cases ab. So schreibt die SAP beispielsweise bei einem SAP-Release-Wechsel mehrere Backup-Phasen vor. Ideal dafür ist ein schnelles Backup vor dem Upgrade und ein schnelles Restore, das im Fall einer Update-Panne das ursprüngliche System wiederherstellt.

Ein weitere Use Case sind schnellere Test-Zyklen. So schreiben die Regulatorien beispielsweise bei Pharma-Unternehmen, Versicherungen und Banken ein rigides Testing vor, dass die Unternehmen idealerweise automatisiert abbilden. Als Kundenbeispiel verweist Schlosser auf ein Unternehmen mit einer 10 Terabyte großen Datenbank, dass drei Wochen benötigt hat, um in einer Testserie neuen Programmcode für ein SAP-System in den produktiven Betrieb zu bringen.

In dem Szenario wurde3 die 10 Terabyte große Datenbank viermal neu befüllt und wiederhergestellt. „Mit Netapp hat diese Prozedur einen Tag gedauert“, glänzt Schlosser.

System Refresh und Recovery im laufenden Betrieb

Ein weiterer Use Case ist das Cloning für ein SAP System Refresh. Hierbei geht es darum, ein neues Volume auf Basis des Snapshots eines Produktivsystem zu erstellen, dieses dann mit dem Testsystem zu verknüpfen und schließlich die geänderten Daten in SAP HANA auf Basis des System Identifier Change wiederherzustellen.

Zum Einsatz kommt diese Methode dann, wenn ein beschädigtes SAP-System repariert werden muss, ohne es komplett herunterzufahren. Dann laufen zunächst weitere Daten in das beschädigte System. Im nächsten Schritt werden diese identifiziert und in die reparierte Instanz eingespielt.

Als vierten Use Case nennt Schlosser das Testing und das Disaster Recovery im laufenden Betrieb, das über eine Snap Mirror Replication abgebildet wird. Vor allem Unternehmen aus regulierten Branchen müssten diese Aktion einmal im Jahr oder sogar einmal alle sechs Monate durchführen. Die Beschleunigung entlaste den Systembetrieb deutlich.

Netapps AFF-C-Serie reicht in den meisten Fällen aus

Zum Abschluss seines Vortrags beleuchtet Schlosser die Frage, welche Storage-Systeme für SAP HANA zertifiziert sind, und welche Protokolle die SAP für den Datenaustausch unterstützt. „Alle unsere Systeme, die mit dem Betriebssystem 'Ontap' laufen, sind für SAP HANA zertifiziert“, erläutert Schlosser.

Als Protokolle für Datenbanken im Single Host- oder Multiple Host Betrieb unterstützt SAP 'NFS' via 10, 40 oder 100 Gigabyte Ethernet und 'XFS' via 16 oder 32 Gigabyte Fiber Channel. Geht es um die Frage, wie viele Solid State Drives nötig sind, um einen SAP HANA Knoten zu betreiben, fordert SAP Schlüsselkennzahlen für die Bandbreite ein. Netapp stellt in Best-Practice-Konfigurationen sicher, dass die maximale Anzahl der Knoten erreicht wird.

Auch die Modellauswahl beleuchtet bei den Storage-Systemen beleuchtet das Webinar: Netapp hat die AFF-C-Serie und die AFF-A Serie im Portfolio. „Die A-Serie hat eine höhere Bandbreite, dafür fallen aber höhere Kosten an“, sagt Schlosser.

Die C-Serie hingegen benötige beim Schreiben eine etwas höhere Latenz, sei dafür aber „sehr kostengünstig.“ Generell reiche in den allermeisten Fällen eine C-Serie aus: „Eine gut konfigurierte Datenbank bedient über 99 Prozent aller Anfragen aus dem Cache. SAP HANA bezieht daraus sogar alle Daten“, schließt der Netapp-Sap-Experte.

(ID:49796371)