IBM Cloud Docs
Häufig gestellte Fragen zum Versetzen von SAP-Workloads

Häufig gestellte Fragen zum Versetzen von SAP-Workloads

Wie wird eine vorhandene SAP-Workload zu IBM Cloud versetzt?

Für das Versetzen einer vorhandenen IBM Cloud® for SAP-Workload gibt es die folgenden Möglichkeiten:

  • Sie kann unverändert aus lokalen Rechenzentren nach Cloud IaaS versetzt werden. Dieses Verfahren wird häufig 'Lift-and-shift' genannt.
  • Sie kann von einem Anbieter oder einer Version auf einen anderen Anbieter bzw. eine andere Version migriert werden:
    • Der Anbieter oder die Version des Datenbankservers kann geändert werden (z. B. von IBM Db2 in SAP HANA).
    • Die Version des Anwendungsservers kann geändert werden (z. B. von SAP NetWeaver AS ABAP 7.0 in SAP NetWeaver AS ABAP 7.52).
    • Die Version der Geschäftsanwendung kann geändert werden (z. B. von SAP ECC in SAP S/4HANA).

Die Versetzung von Workloads ist eine Änderung auf Infrastrukturebene, die sich auf die SAP-Systeme auswirkt, da sie auch Änderungen für Netzbetrieb und Speicher beinhaltet.

Die Migration von Workloads ist eine Änderung auf Anwendungsebene, die sich auf die SAP-Systeminstallation auswirkt, da neue Software zum Einsatz kommt.

  • Für VMware-basierte SAP-Workloads, die in lokalen Rechenzentren ausgeführt werden, kann die Verlagerung dieser virtuellen Maschinen in IBM Cloud für VMware je nach vorhandener Konfiguration möglicherweise durch die Verwendung von VMware HCX vereinfacht werden

Wie wird eine vorhandene SAP HANA-Datenbank oder relationale Datenbank auf einen SAP HANA-zertifizierten Server in IBM Cloud versetzt?

Cloud Infrastructure as a Service (IaaS) beinhaltet keine Versetzungs- oder Migrationsservices.

Alle Versetzungs- oder Migrationsaktivitäten liegen ausschließlich in Ihrer Verantwortlichkeit.

IBM Cloud bietet zwar keine Services auf SAP-Anwendungsebene, aber die zahlreichen IBM Cloud Business Partners (inklusive IBM Services) stellen ihre Servicekompetenz durch Verwendung des IBM Cloud® for SAP-Portfolios zur Verfügung.

Die folgende Tabelle enthält eine kurze Liste der Services und der Typen von Business Partnern, die die Services für IBM Cloud® for SAP bereitstellen können:

Service-Partner-Typen
Service-Partner-Typ Bereitgestellt von Beschreibung
Beratung, Empfehlung und Implementierung SAP-Provider für 'Global Systems Integrator' (GSI) Diese Provider beraten bei Projekten für SAP-Implementierung und -Bereitstellung und führen diese Projekte aus.
Anwendungsmanagement SAP-Provider für 'Application Management Services' (AMS) Diese Provider steuern und verwalten eine bestehende Bereitstellung von SAP-Anwendungen (optional: inkrementelle Funktions- oder Entwicklungsänderungen).
Verwaltete End-to-End-Services SAP-Provider für 'Managed Services Providers' (MSP) Diese Provider nehmen die SAP-Implementierung und -Bereitstellung vor und verwalten die Infrastruktur, das Betriebssystem, die SAP-IT-Anwendungen und die SAP-Geschäftsanwendungen. Häufig umfassen diese Services keine inkrementellen Funktions- oder Entwicklungsänderungen.

Im Rahmen der Partnerschaft zwischen IBM Cloud und IBM Services sind unter anderem beispielsweise die folgenden Services verfügbar:

Welche Optionen gibt es generell für das Versetzen und Migrieren eines bestehenden SAP-Systems in die Cloud?

Die folgende Tabelle enthält eine allgemeine Liste der Optionen für das Versetzen und Migrieren von SAP-Systemen in die Cloud. Weitere Informationen erhalten Sie in der erforderlichen SAP-Dokumentation über das Versetzen und Migrieren von SAP-Workloads und bei Ihrem zuständigen Systemimplementierer für SAP.

Liste der Move-and-Migrate-Workload-Ansätze SAP
Verfahren zum Versetzen und Migrieren von SAP-Workloads Beschreibung Gängige Nutzung Ausfallzeit Tasks vor/nach Migration Datenübertragung
Heterogene Systemkopie mit Verwendung von SWPM Versetzung oder Plattformänderung in andere CPU-Architektur, anderes Betriebssystem oder andere Datenbank. Verwendet die Copy/Export-Funktion für Systeme von SWPM. Wird häufig verwendet, um den Datenbankserver vor einem größeren Wechsel zu ändern, beispielsweise beim Wechsel auf SAP HANA DB mit einer klassischen Migrationsstrategie. Ja Erfordert erhebliche Vor- und Nachverarbeitung. Speicherauszug für Systemkopie und -export
Homogene Systemkopie mit Verwendung von SWPM (Option nur für Systemkopien, die SAP HANA DB ausführen) Versetzung oder Plattformänderung auf neuere Betriebssystem- oder Datenbankversion. Kann nicht zum Wechsel der CPU-Architektur oder Endianness genutzt werden. Verwendet die SAP-Datenbanksicherung mit SWPM. Wechsel zu neuem SAP HANA-Ziel oder zu neuem Betriebssystemziel mit vorhandener AnyDB-Instanz. Wird ebenfalls eingesetzt, um neue Sandboxes eines vorhandenen Systems zu erstellen (mit oder ohne Namensänderung für das logische System). Ja. Geringe Ausfallzeit je nach Vorbereitung, Änderungsfixierung und Differenzänderungssynchronisierung (von Protokolldateien) bei Übergabe an Zielsystem möglich. Weniger Vorbereitung als bei heterogener Systemkopie; je nach Szenario moderate bis erhebliche Nachverarbeitung erforderlich (in den meisten Fällen wird der Name des logischen Systems geändert, z. b. BDLS). SAP-Datenbanksicherung
SAP HANA System Replication (HSR) mit replizierter Datenbankspiegelung in der Cloud Sekundäre Failover-Site wird in der Cloud gehostet Hochverfügbarkeits- und Disaster-Recovery-Szenarios Ja, minimal, abhängig von Design- und Failover-Faktoren (z. B. kostenoptimiert oder leistungsorientiert) Mit SAP Landscape Management (LaMa) kann die Konfiguration und Ausführung automatisiert werden. Protokoll- oder Speichertransport: Modi SYNCMEM, FULLSYNC, SYNC oder ASYNC
Systemverlagerung mit Verwendung von SAP LaMa zur Koordinierung des Wechsels Physische oder virtuelle Verlagerung von aktiven oder beendeten Instanzen. Verwendet SAP LaMa. SAP HANA DB-MDC-Tenants können nicht verlagert werden. Versetzung von einzelnen SAP-Instanzen in bereits eingerichtete neue Infrastrukturumgebung. Ja, minimal. Ausfallzeiten ergeben sich für aktive Systeme, wenn diese gestoppt, bereinigt, vorbereitet und gestartet werden. Mit SAP-LaMa kann die Verlagerung automatisiert werden. Netzübertragung von Paketen, die LaMa oder den LaMa-Adapter für VMware verwendet
DMO für SUM mit Systemversetzungsausführung (Kombiniert Migration, Unicode-Konvertierung, Upgrades und weitere Tasks) Unterstützt für Upgrade des Anwendungsservers (NetWeaver) oder für Datenbankkonvertierung in SAP HANA. Versetzt gleichzeitig den Datenbankserver von NW PAS + und führt Upgrade durch. Migrationen auf Business Suite unter SAP HANA oder Teil der SAP S/4HANA-Konvertierungsmigration (Brownfield) Ja. Sowohl PAS-Zielhost und Datenbankhost in der Zielumgebung (z. B. IBM Cloud) müssen vor DMO für SUM mit Systemversetzungsausführung bereit sein. Erfordert erhebliche Vorbereitung. Der Systemexport wird in der Quellenumgebung ausgeführt. Der Import wird in der Zielumgebung ausgeführt. Export und Import können auch parallel erfolgen.
Selektive Datenüberführung mit Shell-Konvertierung Erstellt Shell des SAP-Systems nur mit Anpassung und Entwicklung; anschließend Upgrade/Konvertierung auf entweder SAP ECC oder SAP S/4HANA. Migriert ausgewählte Daten aus ECC in das aktualisierte Shellsystem. Wird bei Projekten für Unternehmensteilungen (z. B. Veräußerungen) und Transformation/Konvertierung mit SAP S/4HANA eingesetzt. Ja, minimal. Das Ziel kann im voraus erstellt und getestet werden (wiederholte Testung der Konvertierungsschritte und Korrektur). Daten können im voraus auf dem Ziel repliziert werden, so dass eine Ausfallzeit nur für die Differenzdatensynchronisation und Ersetzung des alten Systems durch das Ziel benötigt wird. Erfordert erhebliche Vorbereitung. SAP Landscape Transformation Replication Server, wird durch direkte Einbindung von SAP abgewickelt.
Selective Data Transition mit Mix & Match Fusioniert zwei oder mehr Systemkonfigurationen zu einem neuen SAP-System mit der erforderlichen Konfiguration; anschließend Upgrade/Konvertierung nach SAP S/4HANA. Wird bei Projekten für Unternehmensfusionen (z. B. Firmenübernahmen), für die Konsolidierung mehrerer SAP-Systeme (z. B. ERPs für jede geografische Region oder Geschäftseinheit) und für Transformation/Konvertierung mit SAP S/4HANA genutzt. Ja, minimal. Das Ziel kann im voraus erstellt und getestet werden (wiederholte Testung der Konvertierungsschritte und Korrektur). Daten können im voraus auf dem Ziel repliziert werden, so dass eine Ausfallzeit nur für die Differenzdatensynchronisation und Ersetzung des alten Systems durch das Ziel benötigt wird. Erfordert erhebliche Vorbereitung. SAP Landscape Transformation Replication Server, wird durch direkte Einbindung von SAP abgewickelt.