Stabile und anwendungskonsistente Snapshots in einer SAP-LandschaftZeit sparen und Nerven schonen mit Storage-Snapshots auf SAP

Für SAP-Anwendungsteams ist die gesamte Infrastruktur in der Regel nur eine Ware, insbesondere was Storage betrifft. Unter der SAP-Plattform kann die Storage-Infrastruktur erstmals eine Rolle spielen, wenn es um die Verwaltung der komplexen SAP-Schicht darüber geht.

In der heutigen Zeit sind es in der Regel keine Infrastrukturprobleme, die SAP-Systeme zum Absturz bringen – es sind die Mitarbeiter. Snapshots gewinnen an Bedeutung, um nach den häufigen, von Menschen verursachten Fehlern eine schnelle Wiederherstellung durchzuführen.

Besonders praktisch sind sie in einer Testumgebung, in der nicht unbedingt eine vollständige Datensicherung nötig ist und die mit einem absturzkonsistenten Snapshot auskommen können. Mit Pure lassen sich Snapshots planen und beliebig lange aufbewahren. Das bedeutet, dass falls jemand versehentlich eine Z-Tabelle löscht, man nur den groben Zeitrahmen kennen muss, in dem dies passiert ist, um die Snapshots zu durchsuchen.

Zudem ist es nicht erforderlich, das System zu überschreiben, um es wiederherzustellen. Die Wiederherstellung des Snapshots erfolgt einfach auf einem separaten System, ohne dass jemand gestört wird, der in der Testumgebung arbeitet.

Einfachere Datenkonvertierungen

Daten sind das Lebenselixier des SAP-Einsatzes. Die richtige Datenkonsistenz ist für eine erfolgreiche SAP-Plattform von größter Bedeutung. Wer mit SAP live geht – sei es ein Modul oder eine komplette Neuimplementierung – muss fast immer Datenkonvertierungen durchführen, um das SAP-System von einem Altsystem aus zu „befüllen“. Es kann kompliziert sein, eine Umgebung für diese Datenkonvertierungen vorzubereiten, da diese „Probeläufe“ in der Regel auch als eine Art Cutover für den tatsächlichen Produktivstart angesehen werden.

Infolgedessen gilt es jeden Testlauf zu überwachen, um sicherzustellen, dass alles innerhalb der vereinbarten Ausfallzeit läuft. Erschwerend kommt hinzu, dass diese Datenkonvertierungen in der Regel voneinander abhängig sind. Das bedeutet, dass sich zum Beispiel nicht alle Preisdaten importieren lassen, bevor das Material importiert wurde.

Wenn also bei dieser Materialkonvertierung etwas schiefgeht und nur 10 Prozent der Materialien den ETL-Prozess durchlaufen, wirkt sich das auch auf jedes vom Material abhängige Objekt aus. Wenn dies geschieht, müssen auch alle Daten, die bereits in das System geflossen sind, repariert werden, um den Mock erneut auszuführen, normalerweise von einem Backup. Bei diesem mühsamen und langwierigen Prozess wird sicherlich nicht gelingen, das Cutover-Fenster zu treffen.

Doch Snapshots können helfen, all diesen Ärger zu vermeiden: Durch das Hinzufügen von Snapshots mit sofortigen Wiederherstellungspunkten während dieses Prozesses sparen Administratoren nicht nur Zeit, um das Cutover-Fenster zu erreichen. Sie stellen auch sicher, dass so viele Daten wie möglich in die Zielumgebung fließen. Mock-Runs verwandeln diese Landschaften normalerweise in Testumgebungen.

Vermeiden zusätzlicher Ausfallzeiten

Die meisten Unternehmen planen größere Upgrades ihrer SAP-Landschaften im Voraus – in der Regel einmal pro Jahr. SAP veröffentlicht jedoch ständig Patches für Fehlerbehebungen. Manchmal gilt es Patches häufiger auf eine SAP-Landschaft anzuwenden, indem man ein geplantes Wartungsfenster nutzt, normalerweise monatlich oder vierteljährlich.

In den meisten Fällen, abhängig vom Unternehmen, sind Wochenenden die beste Zeit, um eine Anwendungssuite für das Einspielen von Patches herunterzufahren. So lassen sich Support-Packs und benutzerdefinierte Transporte anwenden und bei Bedarf manuelle Änderungen auf der Grundlage der Ergebnisse der Testphasen der Anwendung vornehmen. Sehr häufig ist ein vollständiges Backup erforderlich, um die Lösung zu sichern, falls etwas schiefgeht. Und wenn etwas schiefgeht, bedeutet dies, dass eine Wiederherstellung aus dem Backup erforderlich ist und am folgenden Wochenende ein erneuter Versuch fällig ist.

Das Einfügen von Snapshots in diesen Prozess kann wertvolle Zeit sparen und helfen, zusätzliche Ausfallzeiten zu vermeiden, wenn etwas schiefgeht. Anstatt beispielsweise auf die Fertigstellung eines vollständigen Backups zu warten, lässt sich zu Beginn des Prozesses ein anwendungskonsistentes Snapshot erstellen. Da man sich höchstwahrscheinlich bereits in einem Ausfallzeitfenster befindet, ist ein anwendungskonsistenter Snapshot sehr einfach zu erstellen.

Falls etwas schiefgeht, ist das System in Sekundenschnelle wieder einsatzbereit. Und anstatt sich auf einen seriellen Prozess zu verlassen, der bei einem Fehlschlag ganz an den Anfang zurückgehen muss, lässt sich einfach nach jedem erfolgreichen Schritt ein Snapshot ausführen als Sicherungspunkt. Auf diese Weise kann alles, was schiefgelaufen ist, innerhalb desselben Wartungsfensters behoben werden.

Daten besser verwaltbar machen

„Wo sind die Daten?“ Das ist die erste Frage, die ein ABAP-Entwickler stellt, wenn man einen Fehler in der Produktion meldet. Das Vorhandensein realer Geschäftsdaten in den Entwicklungs-/Testumgebungen ist ein absolutes Muss, um sicherzustellen, dass reale Geschäftsprobleme gelöst werden. Schließlich sind die Benutzer die besten Tester.

Es ist jedoch nicht einfach, all diese Daten in einer SAP-Landschaft zu verschieben. Werkzeuge wie TDMS bieten einige Möglichkeiten, Datenobjekte zwischen Landschaften zu replizieren, aber sie sind sehr komplex einzurichten. Eine große Abhängigkeit von benutzerdefinierten Objekten führt ebenfalls zu einer so großen Komplikation, dass sie selbst zu Projekten werden. Und sie replizieren unnötigerweise Daten zwischen Landschaften.

Snapshots können helfen, dieses Problem zu lösen. In Handumdrehen ist ein Snapshot der SAP-Datenbank (SAP HANA, Oracle, SQL Server usw.) erstellt, unabhängig von der Größe der Datenbank. Diese Daten gilt es dann in einer anderen Umgebung zu mounten, um ein voll funktionsfähiges SAP-System zu erhalten.

Es gehört jedoch mehr dazu, eine Umgebung „aufzufrischen“, als sie einfach mit einer völlig neuen Datenbank zu überschreiben. Es gibt Vorverarbeitungsschritte wie das Exportieren von Daten, die nicht überschrieben werden sollen, wie RFC-Destinationen oder Benutzer. Sobald der Snapshot die gesamte Datenbank überschreibt, müssen Administratoren diese Daten importieren und eine BDLS (logische Systemumstellung) ausführen. Einige Unternehmen haben den größten Teil dieses Prozesses automatisiert, aber die Komplexität in der Mitte anscheinend nicht umgehen können.

Pure Storage Snapshots sind eine mögliche Lösung. Diese lassen sich über eine Benutzeroberfläche direkt auf Storage-Volumes aufnehmen. Ebenso lässt sich eine OpenAPI verwenden, wenn die bestehende Automatisierung erweitern werden soll, um auch die Datenbank-Kopierverfahren zu handhaben. Es werden überhaupt keine Daten dupliziert, da Snapshots vollständig deduplizierte Arbeits-„Kopien“ sind. Diese werden nur dann Speicherplatz in Anspruch nehmen, wenn man anfängt, Deltas zwischen der Quelle und dem Ziel zu erstellen. Die Automatisierung dieses Prozesses mit OpenAPI, um einen Speicher-Snapshot zu erstellen und wiederherzustellen, spart viel Zeit. (rhh)

Pure Storage