Prüfliste für die Planung und Bereitstellung von SAP-Workloads in Azure
Artikel
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
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 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 Details zu unterstützten SAP-, Betriebssystem- und DBMS-Software finden Sie hier:
SAP-Hinweis 2039619. In diesem Hinweis ist die Oracle-Unterstützungsmatrix für Azure definiert. Oracle unterstützt nur Windows und Oracle Linux als Gastbetriebssysteme auf Azure für SAP-Workloads. Dieser Supporthinweis gilt ebenfalls für die SAP-Anwendungsschicht, in der die SAP-Instanzen ausgeführt werden, sofern diese Oracle Client enthalten.
Von SAP HANA unterstützte Azure-VMs sind auf der SAP-Website aufgeführt. Details für jeden Eintrag enthalten Besonderheiten und Anforderungen, einschließlich der unterstützten Betriebssystemversion. Dies entspricht möglicherweise nicht der neuesten Betriebssystemversion gemäß SAP-Hinweis 2235581.
Layout und Größen des SMB- und/oder NFS-Volumes, ggf. Bereitstellungspunkte
Hochverfügbarkeits-, Sicherungs- und Notfallwiederherstellungsarchitektur
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.
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. Dieses Design sollte die folgenden Elemente enthalten, von denen viele vom Zielzonenbeschleuniger für SAP abgedeckt sind:
Netzwerktopologie in Azure und Zuweisung der unterschiedlichen SAP-Umgebungen
Active Directory- und DNS-Entwurf
Identitätsverwaltungslösung für Endbenutzer und Verwaltung
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.
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.
Microsoft entwickelte Lösungen für die SAP-Bereitstellungsautomatisierung sind:
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
Compute-/VM-Typen
Arbeiten Sie die Ressourcen in den SAP-Supporthinweisen, im SAP HANA-Hardwareverzeichnis und im SAP PAM erneut durch. Stellen Sie sicher, dass sie den unterstützten VMs für Azure, unterstützten Betriebssystemversionen für diese Typen von virtuellen Computern und unterstützten SAP- und DBMS-Versionen entsprechen.
Überprüfen Sie erneut die Größe Ihrer Anwendung und die Infrastruktur, die Sie in Azure bereitstellen. Falls Sie vorhandene Anwendungen verschieben, können Sie die erforderlichen SAPS häufig über die verwendete Infrastruktur und die Benchmark-Webseite von SAP ableiten und sie mit der Anzahl von SAPS vergleichen, die im SAP-Hinweis 1928533 aufgeführt ist. Berücksichtigen Sie außerdem diesen Artikel zu SAPS-Bewertungen.
Bewerten und testen Sie die Größe Ihrer Azure-VMs für maximalen Speicher- und Netzwerkdurchsatz der verschiedenen VM-Typen, die Sie während der Planungsphase ausgewählt haben. Details der VM-Leistungsgrenzwerte sind verfügbar. Für den Speicher ist es wichtig, den maximalen Durchsatz von nicht zwischengespeicherten Datenträgern für die Größenanpassung zu berücksichtigen. Berücksichtigen Sie die Auswirkungen der Größenanpassung und temporären Auswirkungen von Bursting auf Datenträger- und VM-Ebene.
Testen und bestimmen Sie, ob Sie eigene Betriebssystemimages für Ihre VMs in Azure erstellen oder ein Image aus der Azure Compute Gallery (früher als Azure Shared Image Gallery bezeichnet) verwenden möchten. Wenn Sie ein Image aus der Azure Compute Gallery verwenden, achten Sie darauf, ein Image zu verwenden, das dem Supportvertrag mit Ihrem Betriebssystemanbieter entspricht. Bei manchen Betriebssystemanbietern können Sie Ihre eigenen Lizenzimages in die Azure Compute Gallery hochladen. Bei anderen Betriebssystemimages ist er Support bereits im für Azure angegebenen Preis enthalten.
Mithilfe eigener Betriebssystemimages können Sie erforderliche Unternehmensabhängigkeiten wie Sicherheits-Agents, Härtungen und Anpassungen direkt im Image speichern. Auf diese Weise werden sie sofort mit jedem virtuellen Computer bereitgestellt. Wenn Sie sich entscheiden, eigene Betriebssystemimages zu erstellen, finden Sie dokumentationen in den folgenden Artikeln:
Wenn Sie Linux-Images aus der Azure Compute Gallery verwenden und Härtung als Teil Ihrer Bereitstellungspipeline hinzufügen, müssen Sie die für SAP geeigneten Images verwenden, die von den Linux-Anbietern bereitgestellt werden.
Die Auswahl eines Betriebssystemimage bestimmt den Typ der Azure-VM-Generation. Azure unterstützt Virtuelle Computer der Hyper-V-Generation 1 und 2. Einige VM-Familien sind nur als Generation 2 verfügbar, einige VM-Familien sind nur für die SAP-Verwendung als Generation 2 zertifiziert (SAP-Hinweis 1928533), auch wenn Azure beide Generationen zulässt. Es wird empfohlen, für jeden virtuellen Computer der SAP-Landschaft die Generation 2 zu verwenden.
Verwenden Sie mindestens Azure SSD-Standardspeicher für VMs, die SAP-Anwendungsschichten darstellen, und für nicht leistungskritische DBMS-Bereitstellungen. Beachten Sie, dass verschiedene Azure-Speichertypen die SLA für die Verfügbarkeit einzelner VM beeinflussen.
Im Allgemeinen empfehlen wir die Verwendung von Azure HDD-Standard-Datenträgern nicht.
Überprüfen Sie für die verschiedenen DBMS-Typen die allgemeine SAP-bezogene DBMS-Dokumentation und die DBMS-spezifische Dokumentation, auf die das erste Dokument verweist. Verwenden Sie Datenträgerstriping für mehrere Datenträger mit Storage Premium (v1 oder v2) für Datenbankdaten und den Protokollbereich. Überprüfen Sie mit dem Befehl „lvs -a -o+lv_layout,lv_role,stripes,stripe_size,devices“ unter Linux, ob LVM-Datenträgerstriping aktiv ist und die korrekte Stripegröße aufweist. Weitere Informationen finden Sie unter „Eigenschaften von Speicherplätzen unter Windows“.
Verwenden Sie LVM für alle Datenträger auf Linux-VMs, da dies eine einfachere Verwaltung und Onlineerweiterung ermöglicht. Dies schließt Volumes auf einzelnen Datenträgern ein, z. B. /usr/sap.
Netzwerk
Testen und evaluieren Sie Ihre virtuelle Netzwerkinfrastruktur und die Verteilung Ihrer SAP-Anwendungen auf die oder innerhalb der unterschiedlichen virtuellen Azure-Netzwerke.
Bewerten Sie den Ansatz der Hub-and-Spoke- oder Virtual WAN-Architektur mit diskreten Spokes für virtuelle Netzwerke für SAP-Workload. Für eine kleinere Skalierung wird der Ansatz der Mikrosegmentierung innerhalb eines einzelnen virtuellen Azure-Netzwerks verwendet. Basieren Sie auf dieser Bewertung auf:
Vorteile einer schnellen Trennung des Peerings zwischen virtuellen Azure-Netzwerken im Vergleich mit dem Wechsel der Netzwerksicherheitsgruppe zum Isolieren eins Subnetzes innerhalb eines virtuellen Netzwerks. Diese Bewertung ist für Fälle vorgesehen, in denen Anwendungen oder VMs, die in einem Subnetz des virtuellen Netzwerks gehostet sind, zu einem Sicherheitsrisiko werden.
Zentrale Protokollierung und Überwachung des Netzwerkdatenverkehrs zwischen dem lokalen Standort, externen Systemen und dem virtuellen Rechenzentrum, das Sie in Azure erstellt haben.
Bewerten und testen Sie den Datenpfad zwischen der SAP-Anwendungsschicht und der SAP-DBMS-Schicht.
Die Platzierung von virtuellen Azure-Netzwerkgeräten im Kommunikationspfad zwischen der SAP-Anwendung und der DBMS-Ebene von SAP-Systemen, die den SAP-Kernel ausführen, wird nicht unterstützt.
Die Platzierung der SAP-Anwendungsschicht und von SAP-DBMS in verschiedenen virtuellen Azure-Netzwerken, die nicht mittels Peering miteinander verknüpft sind, wird nicht unterstützt.
Stellen Sie sicher, dass der beschleunigte Netzwerkbetrieb auf jedem virtuellen Computer aktiviert ist, der für SAP verwendet wird.
Testen und evaluieren Sie die Netzwerklatenz zwischen VMs der SAP-Anwendungsebene und DBMS-VMs gemäß SAP-Hinweisen 500235 und 1100926. Zusätzlich zum Niping von SAP können Sie Tools wie sockperf oder ethr für die TCP-Latenzmessung verwenden. Werten Sie die Ergebnisse anhand der Hinweise zur Netzwerklatenz im SAP-Hinweis 1100926 aus. Die Netzwerklatenz sollte in einem mittleren oder guten Bereich liegen.
Optimieren Sie den Netzwerkdurchsatz auf VMs mit hohem vCPU-Wert, die in der Regel für Datenbankserver verwendet werden. Besonders wichtig für HANA-Scale-out und jedes große SAP-System. Befolgen Sie die Empfehlungen in diesem Artikel zur Optimierung.
Für eine optimale Netzwerklatenz sollten Sie die Anleitungen in den Szenarien zur Näherungsplatzierung des Artikels beachten. Keine Verwendung von Näherungsplatzierungsgruppen für Zonen- oder zonenübergreifende Bereitstellungsmuster.
Überprüfen Sie die richtige Verfügbarkeit, das Routing und den sicheren Zugriff von der SAP-Landschaft aus auf alle erforderlichen Internetendpunkte, z. B. Patchrepositorys für Betriebssysteme, Bereitstellungstools oder Dienstendpunkt. Wenn Ihre SAP-Umgebung gleichermaßen einen öffentlich zugänglichen Dienst wie SAP Fiori oder SAProuter bereitstellt, überprüfen Sie, ob sie erreichbar und gesichert ist.
Bereitstellungen mit Hochverfügbarkeit und Notfallwiederherstellung
Verwenden Sie immer den Load Balancer Standard für Clusterumgebungen. Der Load Balancer Basic wird eingestellt.
Wählen Sie die geeigneten Bereitstellungsoptionen abhängig von Ihrer bevorzugten Systemkonfiguration innerhalb einer Azure-Region aus, unabhängig davon, ob sie sich über Zonen erstrecken, sich innerhalb einer einzelnen Zone befinden oder in einer Region ohne Zone arbeiten.
Wenn Sie in der regionalen Bereitstellung SAP-zentrale Dienste und DBMS-Ebenen für hohe Verfügbarkeit mithilfe der passiven Replikation schützen möchten, platzieren Sie die beiden Knoten für SAP Central Services in einem separaten Verfügbarkeitssatz und den beiden DBMS-Knoten in einem anderen Verfügbarkeitssatz. Mischen Sie keine Anwendungs-VM-Rollen in einer Verfügbarkeitsgruppe.
Konfigurieren Sie für die domänenübergreifende Bereitstellung das System mithilfe eines flexiblen Skalierungssatzes mit FD=1, und stellen Sie die Knoten der aktiven und passiven zentralen Dienste und der DBMS-Ebene in zwei verschiedenen Verfügbarkeitszonen bereit. Verwenden Sie zwei Verfügbarkeitszonen, zwischen denen die niedrigste Latenz besteht.
Wenn Sie Azure Load Balancer in Verbindung mit Linux-Gastbetriebssystemen verwenden, überprüfen Sie, ob der Linux-Netzwerkparameter net.ipv4.tcp_timestamps auf 0 festgelegt ist. Diese Empfehlung steht im Widerspruch zu Empfehlungen in älteren Versionen von SAP-Hinweis 2382421. Der SAP-Hinweis wurde jetzt aktualisiert und gibt an, dass dieser Parameter auf 0 festgelegt werden muss, damit er mit Azure Load Balancern funktioniert.
Timeouteinstellungen
Überprüfen Sie die SAP NetWeaver-Entwicklernachverfolgung der SAP-Instanzen, um sicherzustellen, dass keine Verbindungsunterbrechungen zwischen dem Warteschlangenserver und den SAP-Arbeitsprozessen auftreten. Sie können diese Verbindungsunterbrechungen vermeiden, indem Sie diese beiden Registrierungsparameter festlegen:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Weitere Informationen finden Sie unter KeepAliveTime.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Weitere Informationen finden Sie unter KeepAliveInterval.
Um GUI-Timeouts zwischen lokalen SAP-GUI-Schnittstellen und in Azure bereitgestellten SAP-Anwendungsebenen zu vermeiden, überprüfen Sie, ob diese Parameter in "default.pfl" oder im Instanzprofil festgelegt sind:
rdisp/keepalive_timeout = 3600
rdisp/keepalive = 20
Um eine Unterbrechung der bestehenden Verbindungen zwischen dem SAP-Warteschlangeneinreihungs-Prozess und dem SAP-Arbeitsprozess zu vermeiden, muss der Parameter enque/encni/set_so_keepalive auf true festgelegt werden. Weitere Informationen finden Sie im SAP-Hinweis 2743751.
Wenn Sie eine Konfiguration mit Windows-Failovercluster verwenden, stellen Sie sicher, dass die Zeit zum Reagieren auf nicht reagierende Knoten für Azure ordnungsgemäß festgelegt ist. Im -Artikel Tuning Failover Cluster Network Thresholds (Optimieren der Netzwerkschwellenwerte für Failovercluster) werden die Parameter und ihre Auswirkungen auf Failover aufgeführt. Wenn sich die Clusterknoten im selben Subnetz befinden, sollten Sie die folgenden Parameter ändern:
SameSubNetDelay = 2000 (Anzahl der Millisekunden zwischen „Heartbeats“)
Lesen Sie für die Ausführung von HANA auf SAP diese Hinweise und Dokumentationen zusätzlich zu der nicht azurespezifischen SAP-Dokumentation und anderen Supporthinweisen:
Azure-spezifische SAP-Hinweise in Verbindung mit der SAP-Supportkomponente BC-OP-NT-AZR oder BC-OP-LNX-AZR. Gehen Sie die Notizen im Detail durch, da sie aktualisierte Lösungen enthalten.
Testen Ihrer Verfahren für Hochverfügbarkeit und Notfallwiederherstellung
Simulieren Sie Failoversituationen, indem Sie ein Tool wie NotMyFault (Windows) verwenden oder Betriebssysteme in den Panikmodus versetzen bzw. die Netzwerkschnittstelle mit ifdown (Linux) deaktivieren. Mithilfe dieses Schritts können Sie herausfinden, ob Ihre Failoverkonfigurationen wie beabsichtigt funktionieren.
Messen Sie, wie viel Zeit für die Ausführung eines Failovers benötigt wird. Wenn Sie die Zeiten zu lang sind, erwägen Sie Folgendes:
Verwenden Sie für SUSE Linux SBD-Geräte anstelle von Azure Fence-Agent, um das Failover zu beschleunigen.
Wenn bei SAP HANA das erneute Laden von Daten zu lange dauert, erwägen Sie die Bereitstellung zusätzlicher Speicherbandbreite.
Testen Sie Abfolge und Timing Ihrer Sicherungs-/Wiederherstellungsprozesse, und nehmen Sie ggf. Korrekturen vor. Achten Sie auf ausreichende Sicherungszeiten. Außerdem müssen Sie die Wiederherstellungs- und Zeitwiederherstellungsaktivitäten testen. Achten Sie darauf, dass die Wiederherstellungszeiten innerhalb Ihrer RTO-SLAs liegen, wenn Ihr RTO den Wiederherstellungsprozess für einen virtuellen Computer oder eine Datenbank voraussetzt.
Testen Sie regionsübergreifende Notfallwiederherstellungsfunktionalität und -architektur, und überprüfen Sie, ob RPO und RTO Ihren Erwartungen entsprechen.
Sicherheitsüberprüfungen
Testen Sie die Gültigkeit Ihrer Architektur der rollenbasierten Zugriffssteuerung von Azure (RBAC). Die Aufgabenteilung erfordert die Trennung und Einschränkung von Zugriff und Berechtigungen verschiedener Teams. Beispielweise sollten SAP-Basisteammitglieder in der Lage sein, virtuelle Computer bereitzustellen und Datenträger aus Azure Storage auf einem angegebenen virtuellen Azure-Computer zuzuweisen. Jedoch sollte das SAP-Basisteam keine eigenen virtuellen Netzwerke erstellen oder die Einstellungen vorhandener virtueller Netzwerke ändern können. Mitglieder des Netzwerkteams sollten nicht berechtigt sein, virtuelle Computer in virtuellen Netzwerken bereitzustellen, in denen VMs für die SAP-Anwendung und das DBMS ausgeführt werden. Auch sollten Mitglieder dieses Teams nicht berechtigt sein, Attribute von virtuellen Computern zu ändern oder VMs oder Datenträger zu löschen.
Überprüfen Sie, ob die Regeln für Netzwerksicherheitsgruppen und ASG erwartungsgemäß funktionieren und die geschützten Ressourcen abschirmen.
Stellen Sie sicher, dass alle Ressourcen, die verschlüsselt werden müssen, auch verschlüsselt werden. Definieren und implementieren Sie Prozesse zum Sichern von Zertifikaten, zum Speichern und Zugreifen auf diese Zertifikate und zum Wiederherstellen der verschlüsselten Entitäten.
Für die Speicherverschlüsselung ist die serverseitige Verschlüsselung mit plattformseitig verwaltetem Schlüssel (SSE-PMK) standardmäßig für jeden Speicherdienst aktiviert, der für SAP in Azure verwendet wird, einschließlich verwalteter Datenträger, Azure Files und Azure NetApp Files. Schlüsselverwaltung mit kundenseitig verwalteten Schlüsseln kann in Betracht gezogen werden, falls sie für die Schlüsselrotation beim Kunden erforderlich ist.
Verwenden Sie Azure Disk Encryption für Linux nicht mit SAP, da Betriebssystemimages für SAP nicht unterstützt werden.
Die datenbanknative Verschlüsselung wird von den meisten Kunden von SAP in Azure bereitgestellt, um DBMS-Daten und -Sicherungen zu schützen. Die transparente Datenverschlüsselung (Transparent Data Encryption, TDE) hat in der Regel keinen erkennbaren Leistungsaufwand, erhöht die Sicherheit erheblich und sollte berücksichtigt werden. Die Verschlüsselungsschlüsselverwaltung und der -speicherort müssen gesichert werden. Die Datenbankverschlüsselung geschieht auf der VM auf und ist unabhängig von einer Speicherverschlüsselung wie z. B. SSE.
Leistungstests Nehmen Sie in SAP auf der Grundlage von SAP-Ablaufverfolgung und -Messungen diese Vergleiche vor:
Bestand und Basisplan des aktuellen lokalen Systems.
SAR-Berichte / perfmon.
STAT trace top 10 online reports.
Sammeln des Batchauftragsverlaufs.
Konzentrieren Sie sich auf Tests, um die Leistung von Geschäftsprozessen zu überprüfen. Vergleichen Sie Hardware-KPIs anfangs und im Vakuum nicht, sondern erst bei der Problembehandlung von Leistungsunterschieden.
Vergleichen Sie ggf. die 10 wichtigsten Onlineberichte mit Ihrer aktuellen Implementierung.
Vergleichen Sie ggf. die 10 wichtigsten Batchaufträge mit Ihrer aktuellen Implementierung.
Vergleichen Sie Datenübertragungen über Schnittstellen mit dem SAP-System. Konzentrieren Sie sich auf Schnittstellen, von denen Sie wissen, dass die Übertragung zwischen verschiedenen Standorten erfolgt, etwa von lokal zu Azure.
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.
Wenn sie eine höhere als erwartete Latenz zwischen virtuellen Computern sehen, sollten Sie die Anleitungen in den Szenarien zur Näherungsplatzierung des Artikels 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.
Im Folgenden finden Sie einige gängige 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 Die Wichtigsten Leistungsindikatoren des Betriebssystems:
Stellen Sie unter Linux sicher, dass das sysstat-Tool installiert ist, und erfassen Sie in regelmäßigen Abständen Details.
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 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 -Zwischenspeicherung werden entsprechend 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“.
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.
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: