Willkommen im Automatisierungs-Hub der SAP-Basis! Es gibt kaum eine Aufgabe, die in großen SAP-Infrastrukturen so viel operative Zeit frisst wie der regelmäßige System Refresh (die homogene Systemkopie). Die Produktionstestsysteme (QA/QAS) müssen mit frischen Daten aus der Produktion (PRD) versorgt werden. Der klassische Weg: Datenbank-Backups ziehen, Terabytes an Daten über das Netzwerk kopieren, R3load anwerfen und tagelange manuelle Nacharbeiten.
Mitte 2025 ist dieser manuelle Prozess in Enterprise-Umgebungen nicht mehr vertretbar. Die Lösung ist die Kombination aus SAP Landscape Management (LaMa) Enterprise Edition und cloud-nativen Speicher-APIs auf AWS. Heute analysieren wir die Architektur einer vollautomatisierten Storage-basierten Systemkopie, die Tage in Minuten verwandelt.
Das Architektur-Paradigma: Block-Level Storage Snapshots
SAP LaMa agiert als zentraler Orchestrator. Der Schlüssel zum Geschwindigkeitsvorteil liegt darin, dass LaMa nicht mehr mit der SAP-Software selbst arbeitet, um Daten zu kopieren, sondern direkt mit den Infrastruktur-APIs des Cloud-Providers (AWS) kommuniziert.
Das Setup sieht architektonisch so aus:
-
Quiesce der Datenbank: LaMa friert die produktive S/4HANA-Datenbank für wenige Sekundenbruchteile ein (I/O wird pausiert), um Anwendungskonsistenz zu garantieren.
-
AWS API Call: Über den SAP LaMa AWS Adapter feuert das Tool einen nativen API-Call an AWS, um einen EBS Snapshot (Elastic Block Store) der HANA-Data- und Log-Volumes zu erstellen.
-
Un-Quiesce: Die Produktion läuft sofort normal weiter.
-
Volume Clone & Attach: AWS erstellt aus dem Snapshot innerhalb von Sekunden neue EBS-Volumes (z.B. io2 oder gp3). LaMa orchestriert das Mounten (Attach) dieser neuen Festplatten an die EC2-Instanz des QA-Systems.
Durch diesen Block-Level-Ansatz ist es völlig egal, ob die Datenbank 500 GB oder 15 Terabyte groß ist – die reine "Kopie" der Daten dauert nur wenige Momente.
Post-Copy Automation (PCA): Das Ende von manuellen Basis-Skripten
Das Kopieren der Daten ist nur die halbe Miete. Was passiert mit den logischen Systemnamen, den RFC-Verbindungen und den User-Berechtigungen? Wenn das QA-System startet, glaubt es noch, es sei das Produktivsystem (gleiche SID).
Hier greift die Post-Copy Automation (PCA) von SAP LaMa:
-
System Rename: LaMa ändert über den integrierten Software Provisioning Manager (SWPM) vollautomatisch die System-ID (SID) und die Schema-Namen auf Datenbankebene.
-
BDLS-Lauf: Die logischen Systemnamen werden in allen Tabellen der SAP-Datenbank angepasst.
-
Sicherheits-Bereinigung: Zertifikate (
STRUST), SecStore-Einträge und RFC-Destinationen (SM59), die auf externe Banken- oder HR-Schnittstellen zeigen, werden automatisch gelöscht oder umgeschrieben, damit das QA-System nicht versehentlich Echtzeit-E-Mails an echte Kunden schickt.
📢 SAP & AWS ARCHITEKTUR-NEWS-TICKER (Stand: Juni 2025) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔹 EBS io2 Block Express Integration: AWS und SAP LaMa unterstützen nun nativ die Bereitstellung von io2 Block Express Volumes für Systemkopien. Das bedeutet Sub-Millisekunden-Latenzzeiten direkt out-of-the-box für die frisch geklonten QA-Systeme, exakt wie in der Produktion. 🔹 Automatischer Instanz-Typ-Wechsel: Ein neues Feature erlaubt es, bei der Systemkopie in LaMa einen "Downsize" der EC2-Instanz vorzunehmen. So kann das 12TB-Produktivsystem (x1e.32xlarge) für einen kurzen Entwicklungs-Test auf eine deutlich günstigere R5-Instanz geklont werden (sofern der belegte RAM dies zulässt).
Fazit für Enterprise Architekten
SAP Landscape Management (LaMa) in Kombination mit AWS EBS-Snapshots ist das absolute Endspiel für den SAP-Basis-Betrieb. Es entkoppelt die Datengröße von der Dauer der Systemkopie. Für uns IT-Architekten und Basis-Admins bedeutet das: Routineaufgaben werden auf Knopfdruck ("One-Click-Refresh") automatisiert. Das reduziert menschliche Fehler bei der Nacharbeit auf null und setzt massive Ressourcen frei, um sich auf strategische Themen wie Clean Core und Cloud-Sicherheit zu konzentrieren.