Skip to main content
NetApp Solutions SAP
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Anwendungsfälle für Systemaktualisierung und Klonen

Beitragende

Es gibt verschiedene Szenarien, in denen Daten aus einem Quellsystem zu Test- oder Schulungszwecken einem Zielsystem zur Verfügung gestellt werden müssen. Diese Test- und Trainingssysteme müssen regelmäßig mit Daten des Quellsystems aktualisiert werden, um sicherzustellen, dass die Test- und Schulungsmaßnahmen mit dem aktuellen Datensatz durchgeführt werden.

Diese Systemaktualisierungen bestehen aus mehreren Aufgaben auf Infrastruktur-, Datenbank- und Applikationsebene und können je nach Automatisierungsgrad mehrere Tage dauern.

Die folgende Abbildung zeigt die SAP Systemaktualisierung, den Kopiervorgang und den Klonvorgängen.

Fehler: Fehlendes Grafikbild

Mit SnapCenter Klon-Workflows werden die erforderlichen Aufgaben an der Infrastruktur und auf Datenbankebene beschleunigt und automatisiert. Anstatt ein Backup vom Quellsystem auf das Zielsystem wiederherzustellen, verwendet SnapCenter NetApp Snapshot Kopie und NetApp FlexClone Technologie. Damit können erforderliche Aufgaben bis zu einer gestarteten HANA Datenbank innerhalb von Minuten anstatt Stunden ausgeführt werden, wie in der folgenden Abbildung dargestellt. Der für das Klonen erforderliche Zeitaufwand ist unabhängig von der Größe der Datenbank, sodass selbst sehr große Systeme innerhalb weniger Minuten erstellt werden können.

Die folgende Abbildung zeigt eine Datenaktualisierung von QA-, Test-, Sandbox- oder Schulungssystemen.

Fehler: Fehlendes Grafikbild

Der Workflow für Systemaktualisierungen wird im Abschnitt beschrieben "„SAP HANA-Systemaktualisierung mit SnapCenter.“"

Beseitigung logischer Beschädigungen

Logische Beschädigungen können durch Softwarefehler, menschliche Fehler oder Sabotage verursacht werden. Leider können logische Beschädigungen oft nicht mit standardmäßigen Hochverfügbarkeits- und Disaster Recovery-Lösungen behoben werden. Daher können abhängig von Schicht, Applikation, Filesystem oder Storage mit einer logischen Beschädigung minimale Ausfallzeiten und maximale Datenverluste nicht erfüllt werden.

Schlimmstenfalls ist die SAP-Anwendung logisch beschädigt. SAP Applikationen laufen oft in einer Landschaft, in der verschiedene Applikationen miteinander kommunizieren und Daten austauschen. Daher wird die Wiederherstellung eines SAP-Systems, bei dem eine logische Beschädigung aufgetreten ist, nicht empfohlen. Wenn Sie das System auf einen Zeitpunkt vor der Beschädigung wiederherstellen, führt dies zu Datenverlust. Außerdem würde die SAP-Landschaft nicht mehr synchron sein und eine zusätzliche Nachbearbeitung erfordern.

Anstatt das SAP-System wiederherzustellen, ist es besser, den logischen Fehler innerhalb des Systems zu beheben, indem das Problem in einem separaten Reparatursystem analysiert wird. Zur Ursachenanalyse ist die Einbindung des Geschäftsprozesses und der Applikationseigentümer erforderlich. Für dieses Szenario erstellen Sie ein Reparatursystem (ein Klon des Produktionssystems) auf Basis der Daten, die vor dem Auftreten der logischen Beschädigung gespeichert wurden. Innerhalb des Reparatursystems können die erforderlichen Daten exportiert und in das Produktionssystem importiert werden. Bei diesem Ansatz muss das Produktionssystem nicht angehalten werden. Im besten Fall gehen keine Daten oder nur ein Bruchteil der Daten verloren.

Bei der Einrichtung des Reparatursystems sind Flexibilität und Geschwindigkeit entscheidend. Mit NetApp Storage-basierten Snapshot Backups stehen mehrere konsistente Datenbank-Images zur Verfügung, um mit NetApp FlexClone Technologie einen Klon des Produktionssystems zu erstellen. Dies wird in der folgenden Abbildung dargestellt. Die Erstellung von FlexClone Volumes dauert nur wenige Sekunden, anstatt mehrerer Stunden, wenn zum Einrichten des Reparatursystems eine umgeleitete Wiederherstellung aus einem dateibasierten Backup verwendet wird.

Fehler: Fehlendes Grafikbild

Der Arbeitsablauf der Erstellung des Reparatursystems wird im Abschnitt beschrieben "„SAP Systemklon mit SnapCenter.“"

Disaster Recovery-Tests

Für eine effiziente Disaster Recovery-Strategie müssen die erforderlichen Workflows getestet werden. Die Tests zeigen, ob die Strategie funktioniert und ob die interne Dokumentation ausreichend ist. Darüber hinaus können Administratoren die erforderlichen Verfahren Schulen.

Die Storage-Replizierung mit SnapMirror ermöglicht die Ausführung von Disaster-Recovery-Tests ohne Risiko von RTO und RPO. Disaster-Recovery-Tests können ohne Unterbrechung der Datenreplizierung durchgeführt werden.

Disaster Recovery-Tests für asynchronen und synchronen SnapMirror verwenden Snapshot Backups und FlexClone Volumes am Disaster Recovery-Ziel.

In der folgenden Abbildung sind Disaster-Recovery-Tests aufgeführt.

Fehler: Fehlendes Grafikbild

Eine detaillierte Schritt-für-Schritt-Beschreibung finden Sie im technischen Bericht "Technischer Bericht: SAP HANA Disaster Recovery with Storage Replication".