München, Starnberg, 27. Juli 2020 - Stabile anwendungskonsistente Snapshots innerhalb der SAP-Landschaft mit Pure Storage AllFlash; Datenkonsistenz ist entscheidend...
Zum Hintergrund: Für SAP-Anwendungsteams (SAP-Basis-Administratoren, SAP-Anwendungsadministratoren und SAP-Anwendungseigentümer) ist die gesamte Infrastruktur in der Regel nur eine „Verbrauchsware", insbesondere was den Storage betrifft. Unter der SAP-Plattform kann die Storage-Infrastruktur jedoch eine wichtige Rolle spielen, wenn es um die Verwaltung der komplexen Applikations-Schicht darüber geht. Snapshots gewinnen an Bedeutung, um vor allem nach Bedienfehlern eine schnelle Wiederherstellung zu erreichen. Besonders hilfreich sind sie dabei in einer Testumgebung, in der nicht unbedingt eine vollständige Datensicherung nötig ist und die mit einem absturz-konsistenten Snapshot auskommen kann.
Snapshots planen und 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. Ebenso 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. Mit Pure Storage lassen sich laut Entwickler die Snapshots planen und beliebig lange aufbewahren. (1)
Einfachere Datenkonvertierungen
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.
-
Hier die gute Nachricht: 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. SAP Mock-Runs verwandeln diese Landschaften normalerweise in Testumgebungen.
Vermeiden von zusätzlichen 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. In den meisten Fällen ist ein vollständiges Backup erforderlich, um die Lösung zu sichern, falls etwas schiefgeht. Und wenn etwas schiefgeht (und das ist oft der Fall), 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.
Meine Daten besser verwalten
„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 danach 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.
Fazit:
Da jede Implementierung anders ist, sind dies nur einige der Verwendungsmöglichkeiten für Snapshots, die helfen sollen, das Beste aus den Infrastrukturinvestition herauszuholen.
(1) Quelle:
-
Pure Storage Blogpost > https://blog.purestorage.com/storage-snapshots-sap
Weitere Querverweise:
-
Unser Beitrag > Herausforderungen bei der S/4HANA-Migration haben Auswirkungen auf IT und Business
-
Unser Beitrag > Umstieg auf S/4 HANA: Die Zeit für eine Migration drängt
-
Unser Beitrag > Auch in der SAP-Welt stehen die Weichen auf Hybride Cloud