Analysieren von Strategien für die Migration von SAP-Systemen zu Microsoft Azure

  • 10 Minuten

Die Mehrzahl der Kunden, die eine Bereitstellung von SAP-Workloads in Azure erwägen, verfügen über eine vorhandene lokale SAP-Implementierung. Die Anzahl der Bereitstellungen ohne vorhandene Infrastruktur ist relativ klein.

In der Regel verwenden Unternehmen SAP-Systeme für Geschäftsfunktionen wie Enterprise Resource Planning (ERP), Global Trade, Business Intelligence (BI) und andere. Diese Systeme enthalten Umgebungen wie Sandbox, Entwicklung, Test und Produktion.

Diagram illustrating example environments.

Jede horizontale Zeile in der oben stehenden Abbildung ist eine Umgebung. Jede Spalte ist ein SAP-System für eine Geschäftsfunktion (z. B. ERP und BI).

Die Zeilen oder Ebenen im unteren Bereich sind Umgebungen mit geringerem Risiko und weniger kritisch. Umgebungen mit höherem Risiko sind kritischer und befinden sich weiter oben. Je weiter nach oben, desto risikobehafteter ist der Migrationsprozess. Daher ist die Produktion die kritischste Umgebung, und die Umgebung für Benutzerakzeptanztests (Testumgebung), die auch für die Geschäftskontinuität verwendet wird, folgt direkt dahinter an zweitwichtigster Stelle.

Die Systeme im unteren Bereich sind kleiner, da sie weniger Computeressourcen haben, die Anforderungen an Verfügbarkeit und Größe niedriger sind und der Durchsatz geringer ist. Sie verfügen jedoch über die gleiche Menge an Speicher wie die Produktionsdatenbank.

Horizontale Strategie

Bei einer horizontalen Strategie beginnen Sie am unteren Rand des Rasters, da dies eine sichere Möglichkeit zum Experimentieren mit Azure und zum Sammeln von Erfahrungen darstellt. Diese Strategie ist auch gut zum Neudefinieren Ihrer Betriebs-, Bereitstellungs- und Genehmigungsprozesse geeignet. Diese Prozesse ändern sich bei der Umstellung auf Azure. Die Strategie funktioniert wie folgt:

  • Um das Risiko zu begrenzen, beginnen Sie mit Sandbox- oder Schulungssystemen mit geringen Auswirkungen. Wenn etwas schief geht, ist die Gefahr gering, dass viele Benutzer oder unternehmenskritische Geschäftsfunktionen betroffen sind.
  • Wenn Sie dann Erfahrungen mit dem Ausführen, Hosten und Verwalten von SAP-Systemen in Azure erworben haben, wenden Sie das Gelernte auf Systeme auf der nächsten Ebene des Rasters an.
  • Schätzen Sie für jede Ebene die Kosten, mögliche Kosteneinsparungen, die Leistung und das Optimierungspotenzial, und nehmen Sie bei Bedarf Anpassungen vor.

Vertikale Strategie

Um Erfahrung mit Produktionssystemen in Azure zu sammeln, können Sie parallel zur horizontalen Strategie eine vertikale Strategie mit weniger risikobehafteten Systemen verwenden. Dies bietet auch die Möglichkeit, interne Prozesse für Azure anzupassen und Teammitglieder zu schulen. Dies ist eine sehr gute Möglichkeit, Probleme in der Produktion frühzeitig zu erkennen. Die Strategie funktioniert wie folgt:

  • Betrachten Sie die Auswirkungen auf Kosten, Kunden, Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) und gesetzliche Vorgaben. Verschieben Sie zunächst Systeme mit dem niedrigsten Risiko (von der Sandbox aufwärts bis zur Produktion): das Governance-, Risiko-, und Compliance-System und dann das OER-System (Object Event Repository, OER). Verschieben Sie dann die Systeme mit höheren Risiken (z. B. BI und ERP).
  • Wenn Sie ein neues SAP-System haben, beginnen Sie standardmäßig in Azure und nicht lokal, um es später zu verschieben. Im Diagramm ist OER ein entsprechendes Beispiel. OER ist ein neues System mit geringem Risiko. Nachdem Sie mit der horizontalen Strategie einige andere Systeme zu Azure verschoben haben, können Sie den gesamten vertikalen OER-Stapel (von der Sandbox bis zur Produktion) in Azure bereitstellen.
  • Verschieben Sie das kritischste System nie zuerst. Das letzte System, das Sie verschieben, ist das System mit dem höchsten Risiko, das besonders geschäftskritisch ist: das ERP-Produktionssystem. Hierzu benötigen Sie die leistungsstärksten VM-SKUs und den größten Speicher.
  • Verschieben Sie eigenständige Systeme zuerst. Einige Systeme sind eng mit anderen Systemen verbunden (z. B. unser ERP- und das GTS-System). Zwischen diesen beiden Systemen findet ein reger synchroner Datenverkehr in Echtzeit statt. Wenn Sie das ERP-System zu Azure verschieben, das GTS-System aber lokal belassen, wird die Leistung aufgrund der Netzwerklatenz beeinträchtigt. Verschieben Sie sie daher gemeinsam.
  • Wenn Sie mehrere SAP-Systeme haben, suchen Sie nach Upstream- und Downstreamabhängigkeiten (abhängig von einem anderen SAP-System oder abhängig von Apps außerhalb des SAP-Ökosystems). Überprüfen Sie die Datenverkehrsmuster und -bereiche, die latenzempfindlich sind.
  • Wenn Sie eng verbundene Systeme haben, führen Sie eine Leistungsanalyse durch, um festzustellen, welche Auswirkung eine Verschiebung auf diese Systeme haben wird. Wenn keine großen Auswirkungen feststellbar sind, verschieben Sie sie separat zu Azure (z. B. Business Warehouse unabhängig von ERP). Erstellen Sie andernfalls Migrationsgruppen, und verschieben Sie diese gemeinsam.
  • Denken Sie in einigen Fällen darüber nach, lieber zu warten. Manchmal sollten Sie bestimmte Systeme nicht sofort zu Azure verschieben. Dies könnte bei Größenanforderungen der Fall sein, wenn die Verarbeitungsanforderungen so hoch sind, dass die virtuellen Computer noch nicht groß genug sind. Führen Sie Tests aus, um sicherzustellen, dass sich das Verschieben dieser Systeme nicht auf die SLAs mit Kunden auswirkt.