Diese Prüfliste ist für Kunden vorgesehen, die SAP-Anwendungen nach Azure-Infrastructure-as-a-Service verschieben. SAP-Anwendungen in diesem Dokument stellen SAP-Produkte dar, die den SAP-Kernel ausführen, einschließlich SAP NetWeaver, S/4HANA, BW und BW/4 und anderen. Während der gesamten Projektdauer sollte diese Prüfliste von einem Partner des Kunden und/oder SAP-Partner überprüft werden. Es ist wichtig festzuhalten, dass viele der Überprüfungen am Anfang des Projekts und in der Planungsphase durchgeführt werden. Nach Abschluss der Bereitstellung können eigentlich geradlinige Änderungen an bereitgestellter Azure-Infrastruktur oder SAP-Softwarereleases äußerst komplex werden.
Überprüfen Sie die Prüfliste während Ihres Projekts bei Erreichen wichtiger Meilensteine. Auf diese Weise können Sie kleine Probleme erkennen, bevor sie zu großen Problemen werden. Außerdem gewinnen Sie dadurch die erforderliche Zeit, um alle notwendigen Änderungen neu zu entwickeln und zu testen. Betrachten Sie diese Prüfliste nicht als abgeschlossen. Abhängig von Ihrer Situation müssen Sie möglicherweise noch weitere Überprüfungen vornehmen.
Die Prüfliste umfasst keine Aufgaben, die nicht mit Azure zusammenhängen. Beispielsweise ändern sich die Schnittstellen von SAP-Anwendungen während des Umzugs auf die Azure-Plattform oder zu einem Hostinganbieter. SAP-Dokumentation und -Supporthinweise enthalten auch weitere Aufgaben, die nicht Azure-spezifisch sind, aber Teil Ihrer gesamten Planungsprüfliste sein müssen.
Diese Prüfliste kann auch auf Systeme angewandt werden, die bereits bereitgestellt wurden. Neue Features oder geänderte Empfehlungen können für Ihre Umgebung gelten. Es ist sinnvoll, die Prüfliste in regelmäßigen Abständen durchzugehen, um neue Funktionen der Azure-Plattform umsetzen zu können.
Der Hauptinhalt in diesem Dokument ist in Registerkarten in der chronologischen Reihenfolge eines typischen Projekts angeordnet. Sehen Sie sich den Inhalt der einzelnen Registerkarten an, und berücksichtigen Sie die jeweils nächste Registerkarte, um auf den in der vorherigen Phase durchgeführten Aktionen und erworbenen Erkenntnissen aufzubauen. Bei der Produktionsmigration muss der Inhalt aller Registerkarten und nicht nur der Registerkarte „Produktion“ berücksichtigt werden. Informationen zum Zuordnen typischer Projektphasen mit der in diesem Artikel verwendeten Phasendefinition finden Sie in der folgenden Tabelle.
| Phasen der Bereitstellungsprüfliste |
Beispielprojektphasen oder Meilensteine |
| Vorbereitungs- und Planungsphase |
Projektstart-/-entwurfs- und -definitionsphase |
| Pilotphase |
Frühe Validierung/Proof of Concept/Pilot |
| Nicht-Produktionsphase |
Abschluss der detaillierten Entwurfs-/Nicht-Produktionsumgebungs-Builds/Testphase |
| Vorbereitungsphase für die Produktion |
Generalprobe/Benutzerakzeptanztests/Mock-Cut-Over/Aktivierungsprüfungen |
| Aktivierungsphase |
Produktionsübernahme und Liveschaltung |
| Nachbearbeitungsphase |
Hypercare/Übergang zu „Business as usual“ |
Projektvorbereitungs- und -planungsphase
In dieser Phase planen Sie die Migration Ihrer SAP-Workload zur Azure-Plattform. Dokumente wie Planungshandbuch für SAP in Azure und Cloud Adoption Framework für SAP decken viele Themen ab und dienen als Informationen bei der Vorbereitung. In dieser Phase müssen Sie zumindest die folgenden Dokumente erstellen und folgende Elemente der Migration definieren und erörtern:
Allgemeines Entwurfsdokument
Dieses Dokument sollte Folgendes enthalten:
- Den aktuellen Bestand an SAP-Komponenten und -Anwendungen und einen Zielbestand an Anwendungen für Azure
- Eine Matrix der Zuständigkeiten (RACI), in der die Zuständigkeiten und Aufgaben der verschiedenen Beteiligten definiert sind. Beginnen Sie auf der allgemeinen Ebene, und arbeiten Sie sich bei der Planung und den ersten Bereitstellungen nach und nach zu den Detailebenen vor.
- Eine allgemeine Lösungsarchitektur Bewährte Methoden und Beispielarchitekturen aus dem Azure Architecture Center sollten konsultiert werden.
- Eine Entscheidung zu den Azure-Regionen, in denen die Bereitstellung erfolgen soll. Sehen Sie sich die Liste der Azure-Regionen und die Liste der Regionen mit Support für Verfügbarkeitszonen an. Unter Verfügbare Produkte nach Region erfahren Sie, welche Dienste in welcher Region verfügbar sind.
- Eine Netzwerkarchitektur für Verbindungen von lokalen Standorten zu Azure. Machen Sie sich mit dem Konzept Azure-Zielzonen auf Unternehmensebene vertraut.
- Sicherheitsprinzipien für die Ausführung geschäftskritischer Daten in Azure. Wenn Sie mehr über die Datensicherheit erfahren möchten, beginnen Sie mit der Azure-Sicherheitsdokumentation.
- Speicherstrategie zur Abdeckung von Blockgeräten (verwalteter Datenträger) und freigegebenen Dateisystemen (z. B. Azure Files oder Azure NetApp Files), die im technischen Entwurfsdokument für Dateisystemgrößen und -layouts weiter verfeinert werden soll.
Technisches Entwurfsdokument
Dieses Dokument sollte Folgendes enthalten:
- Ein Blockdiagramm für die Lösung, das SAP- und externe Anwendungen und Dienste zeigt
- Ein SAP Quicksizer-Projekt, das auf dem Volumen von Geschäftsdokumenten basiert. Die Ausgabe von Quicksizer wird dann Compute-, Speicher- und Netzwerkkomponenten in Azure zugeordnet. Eine Alternative zu SAP Quicksizer ist die sorgfältige Dimensionierung basierend auf der aktuellen Workload der SAP-Quellsysteme. Unter Berücksichtigung der verfügbaren Informationen, z. B. DBMS-Workloadberichte, SAP EarlyWatch-Berichte, Compute- und Speicherleistungsindikatoren.
- BCDR-Architektur (Business Continuity & Disaster Recovery, Geschäftskontinuität und Notfallwiederherstellung)
- Ausführliche Informationen zu den Supportpaketversionen für Betriebssystem, Datenbank, Kernel und SAP. Es kann nicht unbedingt davon ausgegangen werden, dass jede von SAP NetWeaver oder S/4HANA unterstützte Betriebssystemversion auch von Azure-VMs unterstützt wird. Gleiches gilt auch für DBMS-Versionen. Überprüfen Sie die folgenden Quellen, um SAP-Versionen, DMBS-Versionen und Betriebssystemversionen aneinander auszurichten und ggf. zu aktualisieren, um Unterstützung von SAP und in Azure sicherzustellen. Sie benötigen Versionskombinationen, die von SAP und Azure unterstützt werden, um vollständige Unterstützung von SAP und Microsoft zu erhalten. Ggf. müssen Sie ein Upgrade einiger Softwarekomponenten einplanen. Weitere Einzelheiten zur unterstützten SAP-, Betriebssystem- und DBMS-Software sind hier dokumentiert:
Außerdem sollten in denselben technischen Dokumenten enthalten sein:
- Allgemeine Speicherarchitektur-Entscheidungen basierend auf Azure-Speichertypen für SAP-Workload
- Verwaltete Datenträger, die an VMs angefügt sind
- Dateisystemlayouts und Größenanpassung
- Layout und Größen des SMB- und/oder NFS-Volumes, ggf. Bereitstellungspunkte
- Hochverfügbarkeits-, Sicherungs- und Notfallwiederherstellungs-Architektur
- Definieren Sie auf der Grundlage von RTO und RPO, wie die Architektur für Hochverfügbarkeit und Notfallwiederherstellung aussehen muss.
- Grundlegendes zur Verwendung verschiedener Bereitstellungstypen für einen optimalen Schutz.
- Überlegungen zu Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workloads und verwandte Dokumente. Die Verwendung einer Konfiguration freigegebener Datenträger als DBMS-Schicht, wie z. B. für SQL Server beschrieben, wird nicht unterstützt. Verwenden Sie stattdessen Lösungen wie
- Um Informationen zur Notfallwiederherstellung über die Grenzen von Azure-Regionen hinweg zu erhalten, prüfen Sie die von den verschiedenen DBMS-Anbietern angebotenen Lösungen. Die meisten unterstützen die asynchrone Replikation oder den Protokollversand.
- Bestimmen Sie für die SAP-Anwendungsschicht, ob Sie die Regressionstestsysteme für Ihr Unternehmen, die idealerweise Replikate Ihrer Produktionsbereitstellungen sind, in derselben Azure-Region oder in Ihrer Region für die Notfallwiederherstellung ausführen möchten. Im zweiten Fall können Sie dieses Geschäftsregressionssystem als Ziel für die Notfallwiederherstellung für Ihre Produktionsbereitstellungen festlegen.
- Informieren Sie sich über Azure Site Recovery als Methode für die Replikation der SAP-Anwendungsschicht in die Azure-Region für die Notfallwiederherstellung. Weitere Informationen finden Sie unter Einrichten der Notfallwiederherstellung für die Bereitstellung einer SAP NetWeaver-App mit mehreren Ebenen.
- Für Projekte, die aus Compliancegründen in einer einzelnen Region verbleiben müssen, sollten Sie eine kombinierte HADR-Konfiguration mithilfe von Azure-Verfügbarkeitszonen in Erwägung ziehen.
- Eine Bestandsaufnahme aller SAP-Schnittstellen und der verbundenen Systeme (SAP und Nicht-SAP).
- Den Entwurf der erforderlichen Grunddienste. Dieser Entwurf sollte die folgenden Elemente enthalten, von denen viele vom Zielzonenbeschleuniger für SAP abgedeckt werden:
- Netzwerktopologie in Azure und Zuweisung der unterschiedlichen SAP-Umgebungen
- Active Directory- und DNS-Entwurf
- Identitätsverwaltungslösung für Endbenutzer und Verwaltung
- Struktur für die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) für Teams, die Infrastruktur und SAP-Anwendungen in Azure verwalten.
- Strategie für die Benennung von Azure-Ressourcen
- Sicherheitsvorgänge für Azure-Ressourcen und -Workloads
- Sicherheitskonzept zum Schutz Ihrer SAP-Workload. Dies sollte alle Aspekte umfassen – Netzwerk- und Umkreisüberwachung, Anwendungs- und Datenbanksicherheit, Sicherung von Betriebssystemen und alle erforderlichen Infrastrukturmaßnahmen wie Verschlüsselung. Identifizieren Sie die Anforderungen mit Ihren Compliance- und Sicherheitsteams.
- Microsoft empfiehlt einen Professional Direct-, Premier- oder Unified Support-Vertrag. Identifizieren Sie Ihre Eskalationspfade und Kontakte für den Support mit Microsoft. Informationen zu den Supportanforderungen von SAP finden Sie im SAP-Hinweis 2015553.
- Die Anzahl der Azure-Abonnements und das Kernkontingent für die Abonnements.
Erstellen Sie ggf. Supportanfragen, um Kontingente von Azure-Abonnements zu erhöhen.
- Plan zur Datenverringerung und -migration für die Migration von SAP-Daten zu Azure. Für SAP NetWeaver-Systeme stellt SAP Richtlinien zum Einschränken des Volumens bei großen Datenmengen bereit. Lesen Sie diese SAP-Anleitung zum Datenmanagement in SAP-ERP-Systemen. Ein Teil des Inhalts gilt auch allgemein für NetWeaver- und S/4HANA-Systeme.
- Einen Ansatz für automatisierte Bereitstellung. Viele Kunden beginnen mit Skripts, die eine Kombination aus PowerShell, CLI, Ansible und Terraform verwenden.
Von Microsoft entwickelte Lösungen für die Automatisierung der SAP-Bereitstellung:
Hinweis
Festlegen einer regelmäßigen Überprüfung von Entwurf und Bereitstellung zwischen Ihnen als Kunde, dem Systemintegrator, Microsoft und anderen beteiligten Parteien.
Pilotphase (dringend empfohlen)
Sie können einen Pilotversuch vor oder während der Projektplanung und -vorbereitung ausführen. Sie können die Pilotphase außerdem verwenden, um Ansätze und Entwürfe aus der Planungs- und Vorbereitungsphase zu testen. Und Sie können die Pilotphase erweitern, um sie zu einem echten Proof of Concept zu machen.
Es empfiehlt sich, im Rahmen einer Pilotbereitstellung eine vollständige HADR-Lösung und einen vollständigen Sicherheitsentwurf einzurichten und zu validieren. Einige Kunden führen in dieser Phase auch Tests auf Skalierbarkeit durch. Andere Kunden verwenden in der Pilotphase Bereitstellungen von SAP-Sandboxsystemen. Wir gehen davon aus, dass Sie für den Pilotversuch bereits ein System bestimmt haben, das Sie zu Azure migrieren möchten.
- Optimieren der Datenübertragung zu Azure. Die optimale Wahl hängt stark vom spezifischen Szenario ab. Wenn für die Datenbankreplikation private Konnektivität erforderlich ist, ist Azure ExpressRoute am schnellsten, wenn die ExpressRoute-Leitung über genügend Bandbreite verfügt. In jedem anderen Szenario ist die Übertragung über das Internet schneller. Verwenden Sie optional ein dediziertes Migrations-VPN für die private Konnektivität mit Azure. Jeder Migrationsnetzwerkpfad während des Pilotprojekts sollte die Verwendung für zukünftige Produktionssysteme spiegeln, wodurch alle Auswirkungen auf SAP- oder externe Workloads vermieden werden, die bereits in Azure ausgeführt werden.
- Im Fall einer heterogenen SAP-Migration, die mit einem Export und Import von Daten einhergeht, sollten Sie die Export- und Importphasen testen und ggf. optimieren. Wenden Sie zur Migration großer SAP-Umgebungen die verfügbaren bewährten Methoden an. Verwenden Sie das geeignete Tool für das Migrationsszenario, abhängig von Ihren Quell- und Zielversionen von SAP, DBMS und bei Kombination der Migration mit anderen Aufgaben, z. B. Releaseupgrade oder sogar Unicode- oder S/4HANA-Konvertierung. SAP bietet Migrationsmonitor/SWPM, SAP DMO oder DMO mit Systemverschiebung sowie andere Ansätze zur Minimierung von Ausfallzeiten, die als separater Dienst von SAP verfügbar sind. In den neuesten Versionen von SAP DMO mit Systemverschiebung wird auch die Verwendung von azcopy für die Datenübertragung über das Internet unterstützt, wodurch der schnellste Netzwerkpfad nativ ermöglicht wird.
Migrieren sehr großer Datenbanken (VLDB) zu Azure für SAP
Technische Validierung
Zusätzliche Überprüfungen für die Pilotphase
Nicht-Produktionsphase
In dieser Phase wird davon ausgegangen, dass Sie nach einem erfolgreichen Pilotprojekt oder einem Proof of Concept (POC) damit beginnen, SAP-Systeme, die nicht für die Produktion vorgesehen sind, in Azure bereitzustellen. Integrieren Sie alle Erkenntnisse aus der POC-Phase in diese Bereitstellung. Alle Kriterien und Schritte, die für POCs aufgeführt sind, gelten auch für diese Bereitstellung.
In dieser Phase stellen Sie in der Regel Entwicklungssysteme, Komponententestsysteme und Regressionstestsysteme in Azure bereit. Es ist empfehlenswert, für mindestens ein Nicht-Produktionssystem einer SAP-Anwendungsreihe die gesamte Hochverfügbarkeitskonfiguration einzurichten, die auch für das zukünftige Produktionssystem verwendet werden soll. Hier finden Sie einige Aufgaben, die Sie in dieser Phase ausführen müssen:
- Sammeln Sie Ressourcenverbrauchsdaten, wie CPU-Auslastung, Speicherdurchsatz und IOPS-Daten, bevor Sie Systeme von der alten Plattform zu Azure verschieben. Erfassen Sie diese Daten insbesondere für Einheiten der DBMS-Schicht, aber auch für Einheiten der Anwendungsschicht. Messen Sie außerdem die Latenz von Netzwerk und Speicher. Passen Sie Größe und Entwurf an die erfassten Daten an. Tools wie syststat, KSAR, nmon und nmon Analyzer für Excel sollten verwendet werden, um die Ressourcenauslastung in Spitzenzeiten zu erfassen und darzustellen.
- Zeichnen Sie die Nutzungszeitmuster Ihrer Systeme für Verfügbarkeit auf. Das Ziel besteht darin, zu bestimmen, ob Nicht-Produktionssysteme täglich rund um die Uhr verfügbar sein müssen oder während bestimmter Phasen einer Woche oder eines Monats heruntergefahren werden können
- Bewerten Sie Ihre Betriebssystem-Image-Auswahl, die VM-Generierung (Generation 2 in der gesamten SAP-Landschaft) und die Betriebssystem-Patchstrategie neu.
- Achten Sie darauf, dass Sie den Anforderungen an SAP-Unterstützung für Microsoft-Supportverträge gerecht werden. Weitere Informationen finden Sie im SAP-Hinweis 2015553.
- Lesen Sie die SAP-Hinweise im Zusammenhang mit Azure, z. B. den Hinweis 1928533 zu neuen VM-SKUs und neuen unterstützten Betriebssystem- und DBMS-Releases. Vergleichen Sie die Preise für neue VM-Typen mit denen für ältere, damit Sie virtuelle Computer mit dem besten Preis-Leistungs-Verhältnis bereitstellen können.
- Überprüfen Sie regelmäßig die SAP-Supporthinweise, das SAP HANA-Hardwareverzeichnis und das SAP PAM. Vergewissern Sie sich, dass es keine Änderungen an unterstützten VMs für Azure, unterstützten Betriebssystemversionen für diese VMs und unterstützten SAP- und DBMS-Versionen gegeben hat.
- Prüfen Sie auf neue HANA-zertifizierte SKUs in Azure auf der SAP-Website. Vergleichen Sie die Preise neuer SKUs mit denen, deren Einsatz Sie geplant haben. Nehmen Sie ggf. die erforderlichen Änderungen vor, um die SKUs mit dem besten Preis-Leistungsverhältnis zu verwenden.
- Passen Sie die Bereitstellungsautomatisierung für die Verwendung neuer VM-Typen und die Einbeziehung neuer Azure-Funktionen an, die Sie nutzen möchten.
- Testen und evaluieren Sie nach der Bereitstellung der Infrastruktur die Netzwerklatenz zwischen VMs der SAP-Anwendungsebene und DBMS-VMs gemäß dem SAP-Hinweis 500235. Werten Sie die Ergebnisse anhand der Hinweise zur Netzwerklatenz im SAP-Hinweis 1100926 aus. Die Netzwerklatenz sollte in einem mittleren oder guten Bereich liegen. Neben Tools wie Niping, sockperf oder ethr können Sie auch das HCMT-Tool von SAP für Netzwerkmessungen zwischen HANA-VMs für horizontales Skalieren oder die Systemreplikation verwenden.
- Stellen Sie sicher, dass für Ihre Bereitstellung keine der Einschränkungen in Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workloads und SAP HANA-Infrastrukturkonfigurationen und -Vorgänge in Azure gelten.
- Wenn sie eine höhere als erwartete Latenz zwischen VMs sehen, sollten Sie die Anleitungen im Artikel Szenarien zur Näherungsplatzierung beachten.
- Führen Sie vor dem Anwenden der Workload alle anderen Überprüfungen durch, die für die Pilotphase (Proof of Concept) aufgeführt werden.
- Zeichnen Sie beim Anwenden der Workload den Ressourcenverbrauch der Systeme in Azure auf. Vergleichen Sie diesen Verbrauch mit Aufzeichnungen aus Ihrer alten Plattform. Passen Sie die VM-Dimensionierung künftiger Bereitstellungen an, wenn Sie große Unterschiede verzeichnen. Beachten Sie, dass beim Downsizing auch die Speicher- und Netzwerkbandbreite von virtuellen Computern reduziert wird.
- Experimentieren Sie mit Systemfunktionen und -prozessen für das Kopieren. Das Ziel besteht darin, Ihnen das Kopieren eines Bereitstellungssystems oder Testsystems zu erleichtern, damit Projektteams schnell an neue Systeme gelangen können.
- Optimieren und verfeinern Sie den rollenbasierten Zugriff, die Berechtigungen und die Prozesse Ihres Teams in Azure, um eine sichere Trennung der Aufgaben zu erreichen. Vergewissern Sie sich im gleichen Zug, dass alle Teams ihre Aufgaben in der Azure-Infrastruktur verrichten können.
- Überprüfen, testen und dokumentieren Sie die Verfahren für Hochverfügbarkeit und Notfallwiederherstellung, damit Ihre Mitarbeiter diese Aufgaben ausführen können. Identifizieren Sie Mängel, und übernehmen Sie neue Azure-Funktionen in Ihre Bereitstellungen
Vorbereitungsphase für die Produktion
Sammeln Sie in dieser Phase alle Ihre Erkenntnisse aus den Nicht-Produktionsbereitstellungen, und wenden Sie sie auf künftige Produktionsbereitstellungen an.
- Schließen Sie vor dem Verschieben nach Azure die erforderlichen SAP-Versionsupgrades Ihrer Produktionssysteme ab.
- Stimmen Sie sich mit den Geschäftsinhabern zu den Funktions- und Geschäftstests ab, die nach der Migration des Produktionssystems durchgeführt werden müssen.
- Stellen Sie sicher, dass alle diese Tests mit den Quellsystemen am aktuellen Hostingstandort abgeschlossen werden. Vermeiden Sie es, Tests erstmalig nach dem Verschieben des Systems nach Azure durchzuführen.
- Testen Sie den Prozess der Migration von Produktionssystemen zu Azure. Falls Sie nicht alle Produktionssysteme in einem Durchgang nach Azure verschieben, erstellen Sie Gruppen von Produktionssystemen, die am gleichen Standort gehostet werden müssen. Testen Sie die Datenmigration, einschließlich verbundener Nicht-SAP-Anwendungen und -Schnittstellen.
Hier folgen einige gebräuchliche Methoden:
- Verwenden Sie DBMS-Methoden wie Sicherung/Wiederherstellung in Verbindung mit SQL Server Always On, HANA-Systemreplikation oder Protokollversand für das Seeding und die Synchronisierung von Datenbankinhalten in Azure.
- Verwenden Sie Sicherung/Wiederherstellung für kleinere Datenbanken
- Verwenden Sie den SAP DMO-Prozess für unterstützte Szenarien, um sie zu verschieben, oder falls Sie Ihre Migration mit einem SAP-Releaseupgrade und/oder einem Wechsel zu HANA kombinieren müssen. Bedenken Sie, dass nicht alle Kombinationen von Quell- und Ziel-DBMS unterstützt werden. Weitere Informationen finden Sie in den spezifischen SAP-Supporthinweisen zu den verschiedenen DMO-Releases. Beispielsweise in Database Migration Option (DMO) für SUM 2.0 SP15.
- Testen Sie, ob der Durchsatz der Datenübertragung über das Internet oder über ExpressRoute besser ist, für den Fall dass Sie Sicherungen oder SAP-Exportdateien verschieben müssen. Falls Sie Daten über das Internet übertragen, müssen Sie möglicherweise einige Regeln Ihrer Netzwerksicherheitsgruppen/Anwendungssicherheitsgruppen ändern, die Sie für zukünftige Produktionssysteme benötigen.
- Bevor Sie Systeme von ihrer alten Plattform zu Azure verschieben, erfassen Sie Daten zum Ressourcenverbrauch. Zu den nützlichen Daten zählen CPU-Auslastung, Speicherdurchsatz und IOPS-Daten. Erfassen Sie diese Daten insbesondere für Einheiten der DBMS-Schicht, aber auch für Einheiten der Anwendungsschicht. Messen Sie außerdem die Latenz von Netzwerk und Speicher.
- Überprüfen Sie die SAP-Hinweise sowie die erforderlichen Betriebssystemeinstellungen, das SAP HANA-Hardwareverzeichnis und die SAP PAM. Vergewissern Sie sich, dass es keine Änderungen an unterstützten VMs für Azure, unterstützten Betriebssystemversionen für diese VMs und unterstützten SAP- und DBMS-Versionen gegeben hat.
- Aktualisieren Sie Ihre Bereitstellungsautomatisierung, um die neuesten Entscheidungen zu berücksichtigen, die Sie zu VM-Typen und Azure-Funktionen getroffen haben.
- Erstellen Sie ein Playbook für das Reagieren auf geplante Wartungsereignisse in Azure. Bestimmen Sie die Reihenfolge, in der Systeme und VMs bei der geplanten Wartung neu gestartet werden sollen.
- Üben, testen und dokumentieren Sie Verfahren zur Hochverfügbarkeit und Notfallwiederherstellung, damit Ihre Mitarbeiter diese Aufgaben während der Migration und unmittelbar nach der Go-Live-Entscheidung ausführen können.
Aktivierungsphase
Während der Aktivierungsphase sollten Sie unbedingt den Playbooks folgen, die Sie in früheren Phasen entwickelt haben. Führen Sie die Schritte aus, die Sie getestet und trainiert haben. Lassen Sie keine kurzfristigen Änderungen an Konfigurationen und Prozessen mehr zu. Führen Sie außerdem diese Schritte aus:
- Vergewissern Sie sich, dass die Überwachung im Azure-Portal und andere Überwachungstools funktionieren. Verwenden Sie Azure-Tools wie Azure Monitor für die Infrastrukturüberwachung.
Azure Monitor für SAP für eine Kombination aus Betriebssystem- und Anwendungs-KPIs, damit Sie alle in ein Dashboard integrieren können, um die Sichtbarkeit während und nach der Liveschaltung zu gewährleisten.
Für Schlüsselleistungsindikatoren des Betriebssystems:
- Führen Sie nach der Datenmigration alle Validierungstests durch, die Sie mit den Geschäftsinhabern vereinbart haben. Akzeptieren Sie Ergebnisse von Validierungstests nur, wenn Sie über Ergebnisse für die ursprünglichen Quellsysteme verfügen.
- Überprüfen Sie, ob die Schnittstellen funktionieren und ob andere Anwendungen mit den neu bereitgestellten Produktionssystemen kommunizieren können.
- Überprüfen Sie das Transport- und Korrektursystem über Transaktions-STMS für SAP.
- Führen Sie Datenbanksicherungen aus, nachdem das System für die Produktion freigegeben wurde.
- Führen Sie VM-Sicherungen für die virtuellen Computer auf der SAP-Anwendungsschicht aus, nachdem das System für die Produktion freigegeben wurde.
- Für SAP-Systeme, die nicht Bestandteil der aktuellen Aktivierungsphase sind, aber mit den SAP-Systemen, die Sie in dieser Aktivierungsphase nach Azure verschoben haben, kommunizieren, müssen Sie den Hostnamenpuffer in SM51 zurücksetzen. Dadurch werden alte zwischengespeicherte IP-Adressen, die den Namen der nach Azure verschobenen Anwendungsinstanzen zugeordnet sind, gelöscht.
Nachbearbeitung
In dieser Phase geht es um Überwachung, Betrieb und Verwaltung des Systems. Aus SAP-Sicht sind dies die gleichen üblichen Aufgaben, die Sie auch an Ihrem alten Hostingstandort ausführen mussten. Führen Sie außerdem diese Azure-spezifischen Aufgaben aus:
- Überprüfen von Azure-Rechnungen, um Systeme mit hohen Gebühren zu ermitteln Installieren Sie eine FinOps-Kultur, und erstellen Sie eine Azure-Kostenoptimierungsfunktion in Ihrer Organisation.
- Optimieren des Preis-Leistungs-Verhältnisses auf Seiten der virtuellen Computer und des Speichers
- Nachdem sich SAP in Azure stabilisiert hat, muss sich Ihr Fokus auf eine Kultur der kontinuierlichen Größenanpassung und Kapazitätsüberprüfungen richten. Im Gegensatz zur lokalen Umgebung mit langfristiger Dimensionierung ist die korrekte Dimensionierung ein wichtiger Vorteil der Ausführung von SAP in Azure-Workloads. Zudem ist eine sorgfältige Kapazitätsplanung von entscheidender Bedeutung.
- Optimieren der Uhrzeiten, zu denen Systeme heruntergefahren werden können.
- Nachdem sich Ihre Lösung in Azure stabilisiert hat, sollten Sie erwägen, von einem kommerziellen Modell mit nutzungsbasierter Bezahlung und zu reservierten Azure-Instanzen zu wechseln.
- Planen Sie regelmäßiger Notfallwiederherstellungsübungen, und führen Sie diese durch.
- Definieren und implementieren Sie Ihre Strategie für „Ever-Greeneing“, um Ihre eigene Roadmap an der SAP in Azure-Roadmap von Microsoft auszurichten, um von der Weiterentwicklung der Technologie zu profitieren.
Checkliste für die SAP in Azure-Infrastruktur
Überprüfen Sie nach der Bereitstellung von Infrastruktur und Anwendungen und vor Beginn jeder Migration Folgendes:
- Es wurden die richtigen VM-Typen mit den korrekten Attributen und Speicherkonfigurationen bereitgestellt.
- Die VMs befinden sich auf einem aktuellen Betriebssystem, DBMS- und SAP Kernel-Release und Patch sowie Betriebssystem-, DB- und SAP-Kernel-Uniform in der gesamten Landschaft.
- VMs werden nach Bedarf und in einheitlicher Weise in der jeweiligen Umgebung gesichert und gehärtet.
- VMs wurden in einem flexiblen Skalierungssatz mit FD=1 über Verfügbarkeitszonen oder in einer Verfügbarkeitsgruppebereitgestellt.
- VMs der Generation 2 wurden bereitgestellt. VMs der Generation 1 sollten nicht für neue Bereitstellungen verwendet werden.
- Azure Storage Premium oder Storage Premium v2 wird für Datenträger mit spezifischen Anforderungen an die Latenz oder mit einer SLA von 99,9 % für Einzel-VMs verwendet.
- Stellen Sie sicher, dass innerhalb der VMs Speicherplätze oder Stripesätze ordnungsgemäß über Dateisysteme hinweg erstellt wurden, die mehr als Datenträger erfordern, z. B. DBMS-Daten- und Protokollbereiche.
- Die richtige Stripegröße und Dateisystemblockierung werden verwendet, sofern in den entsprechenden DBMS-Leitfäden angegeben.
- Azure-VM-Speicher und -Zwischenspeicher werden ordnungsgemäß verwendet
- Stellen Sie sicher, dass nur Datenträger mit DBMS-Onlineprotokollen mit der Schreibbeschleunigung „None+“ zwischengespeichert werden.
- Andere Datenträger mit Storage Premium verwenden je nach Nutzung die Cacheeinstellungen „None“ oder „ReadOnly“.
- Überprüfen Sie die Konfiguration von LVM unter Linux VMs in Azure.
- NFS-Volumes für verwaltete Azure-Datenträger oder Azure NetApp Files werden ausschließlich für DBMS-VMs verwendet.
- Für Azure NetApp Files werden die richtigen Einbindungsoptionen verwendet, und Volumes werden auf der richtigen Speicherebene entsprechend dimensioniert.
- Verwenden von Azure-Diensten – Azure Files oder Azure NetApp Files – für alle SMB- oder NFS-Volumes oder -Freigaben. NFS-Volumes oder SMB-Freigaben sind von der jeweiligen SAP-Umgebung oder einzelnen SAP-Systemen erreichbar. Das Netzwerkrouting an den NFS/SMB-Server erfolgt über den privaten Netzwerkadressraum und verwendet bei Bedarf einen privaten Endpunkt.
-
Der beschleunigte Azure-Netzwerkbetrieb ist auf jeder Netzwerkschnittstelle für alle SAP-VMs aktiviert.
- Es befinden sich keine virtuellen Netzwerkgeräte im Kommunikationspfad zwischen der SAP-Anwendung und der DBMS-Ebene von SAP-Systemen, die auf SAP NetWeaver oder der ABAP-Plattform aufbauen.
- Alle Lastenausgleichsmodule für hochverfügbare SAP-Komponenten verwenden Load Balancer Standard mit aktivierten Floating IP- und HA-Ports.
- SAP-Anwendungen und DBMS-VMs befinden sich in demselben oder unterschiedlichen Subnetzen eines virtuellen Netzwerks oder in virtuellen Netzwerken, die direkt mit Peering verknüpft sind.
- Die Regeln von Anwendungs- und Netzwerksicherheitsgruppen erlauben die Kommunikation wie gewünscht und geplant und blockieren die Kommunikation, wo dies erforderlich ist.
- Die Timeouteinstellungen wurden ordnungsgemäß festgelegt, wie weiter oben beschrieben.
- Wenn Sie Näherungsplatzierungsgruppen verwenden, überprüfen Sie, ob die Verfügbarkeitsgruppen und ihre VMs in der richtigen PPG bereitgestellt werden.
- Die Netzwerklatenz zwischen VMs der SAP-Anwendungsebene und DBMS-VMs wurde getestet und überprüft, wie in den SAP-Hinweisen 500235 und 1100926 beschrieben. Werten Sie die Ergebnisse anhand der Hinweise zur Netzwerklatenz im SAP-Hinweis 1100926 aus. Die Netzwerklatenz sollte in einem mittleren oder guten Bereich liegen.
- Es wurde Verschlüsselung mit den geeigneten Verschlüsselungsmethoden implementiert, wo dies erforderlich ist.
- Eigene Verschlüsselungsschlüssel sind vor Verlust, Zerstörung oder missbräuchlicher Nutzung geschützt.
- Schnittstellen und andere Anwendungen können eine Verbindung mit der neu bereitgestellten Infrastruktur herstellen.
Automatisierte Überprüfungen und Erkenntnisse in der SAP-Landschaft
Einige der oben genannten Überprüfungen werden mit SAP on Azure Quality Check Tool automatisiert durchgeführt. Diese Überprüfungen können mit dem bereitgestellten Open-Source-Projekt automatisiert durchgeführt werden. Obwohl keine automatische Problembehebung durchgeführt wird, warnt das Tool vor der Konfiguration entgegen Empfehlungen von Microsoft.
Weitere Tools, um einfachere Bereitstellungsprüfungen und Dokumentergebnisse zu ermöglichen, die nächsten Korrekturschritte zu planen und im Allgemeinen Ihre SAP in Azure-Landschaft zu optimieren:
-
Bewertung des Azure Well-Architected Frameworks Eine Bewertung Ihrer Workload mit Schwerpunkt auf den fünf Hauptsäulen Zuverlässigkeit, Sicherheit, Kostenoptimierung, Betriebsleistung und Leistungseffizienz. Unterstützt SAP-Workloads und wird empfohlen, um eine Überprüfung am Start und nach jeder Projektphase auszuführen.
-
Azure Inventory Checks for SAP Eine Open Source Azure Monitor-Arbeitsmappe, die Ihren Azure-Bestand mit Intelligence zeigt, um Konfigurationsabweichungen hervorzuheben und die Qualität zu verbessern.
Nächste Schritte
Informationen hierzu finden Sie in diesen Artikeln: