Freigeben über

Planen und Implementieren einer SAP-Bereitstellung in Azure

  • Artikel

In Azure können Organisationen die benötigten Cloudressourcen und -dienste abrufen, ohne einen langen Beschaffungszyklus abzuschließen. Das Ausführen Ihrer SAP-Workload in Azure erfordert jedoch Kenntnisse über die verfügbaren Optionen und die sorgfältige Planung, um die Azure-Komponenten und -Architektur auszuwählen, um Ihre Lösung zu unterstützen.

Azure bietet eine umfassende Plattform für die Ausführung Ihrer SAP-Anwendungen. Azure-Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS)-Angebote bieten Ihnen optimale Auswahlmöglichkeiten für eine erfolgreiche Bereitstellung Ihrer gesamten SAP-Unternehmenslandschaft.

Dieser Artikel ergänzt die SAP-Dokumentation und SAP Notes, die wichtigsten Quellen zum Installieren und Bereitstellen von SAP-Software auf Azure und anderen Plattformen.

Definitionen

In diesem Artikel werden die folgenden Begriffe verwendet:

  • SAP-Komponente: Eine einzelne SAP-Anwendung wie SAP S/4HANA, SAP ECC, SAP BW oder SAP Solution Manager. Eine SAP-Komponente kann auf der traditionellen Advanced Business Application Programming (ABAP) oder Java-Technologien basieren, oder sie kann eine Anwendung sein, die nicht auf SAP NetWeaver basiert, wie SAP BusinessObjects.
  • SAP-Umgebung: Mehrere SAP-Komponenten, die logisch gruppiert sind, um eine Geschäftsfunktion wie Entwicklung, Qualitätssicherung, Schulung, Notfallwiederherstellung oder Produktion auszuführen.
  • SAP-Landschaft: Die gesamte Gruppe von SAP-Ressourcen in der IT-Landschaft einer Organisation. Die SAP-Landschaft umfasst alle Produktions- und anderen Umgebungen.
  • SAP-System: Die Kombination aus einer DBMS-Ebene (Database Management System) und einer Anwendungsschicht. Zwei Beispiele sind ein SAP ERP-Entwicklungssystem und ein SAP BW-Testsystem. Bei einer Bereitstellung in Azure können diese beiden Schichten nicht zwischen lokalen und Azure aufgeteilt werden. Ein SAP-System wird entweder lokal oder in Azure bereitgestellt. Allerdings können Sie die verschiedenen Systeme einer SAP-Landschaft in Azure oder lokal ausführen.

Ressourcen

Weitere Informationen zum Hosten und Ausführen eines SAP Workloads auf Azure finden Sie unter Erste Schritte mit SAP auf einer Azure-VM. In dem Artikel finden Sie Links zu anderen Artikeln, die Folgendes abdecken:

  • SAP Workload-Spezifikationen für Speicher, Netzwerk und unterstützte Optionen.
  • SAP DBMS-Anleitungen für verschiedene DBMS-Systeme auf Azure.
  • SAP-Bereitstellungsleitfäden, sowohl für die manuelle als auch für die automatisierte Bereitstellung.
  • Details zur Hochverfügbarkeit und Notfallwiederherstellung für eine SAP Workload auf Azure.
  • Integration von SAP in Azure mit anderen Diensten und Anwendungen von Drittanbietern.

Wichtig

Für die Voraussetzungen, den Installationsprozess und Details zu bestimmten SAP-Funktionen sollten Sie die SAP-Dokumentation und -Leitfäden sorgfältig lesen. In diesem Artikel werden nur spezifische Aufgaben für SAP-Software behandelt, die auf einer Azure-VM installiert und ausgeführt wird.

Die folgenden SAP-Hinweise bilden die Grundlage der Azure-Anleitung für SAP-Bereitstellungen:

Hinweisnummer Titel
1928533 SAP-Anwendungen auf Azure: Unterstützte Produkte und Größen
2015553 SAP on Azure: Voraussetzungen für die Unterstützung
2039619 SAP-Anwendungen auf Azure mit der Oracle-Datenbank
2233094 DB6: SAP-Anwendungen in Azure mit IBM Db2 für Linux, UNIX und Windows
1999351 Problembehandlung für die erweiterte Azure-Überwachung für SAP
1409604 Virtualisierung unter Windows: Erweiterte Überwachung
2191498 SAP unter Linux mit Azure: Erweiterte Überwachung
2731110 Unterstützung virtueller Netzwerkgeräte (Network Virtual Appliances, NVA) für SAP in Azure

Allgemeine Standard- und maximale Einschränkungen für Azure-Abonnements und -Ressourcen finden Sie unter Einschränkungen, Kontingente und Beschränkungen für Azure-Abonnements und -Dienste.

Szenarien

SAP-Dienste gehören oft zu den unternehmenskritischen Anwendungen in einem Unternehmen. Die Architektur und die Vorgänge der Anwendungen sind komplex, und es muss sichergestellt werden, dass alle Anforderungen an Verfügbarkeit und Leistung erfüllt werden. Ein Unternehmen überlegt sich in der Regel sehr genau, welcher Cloud-Anbieter für die Ausführung solcher unternehmenskritischer Prozesse ausgewählt wird.

Azure ist die ideale öffentliche Cloudplattform für unternehmenskritische SAP-Anwendungen und Geschäftsprozesse. Die aktuellste SAP-Software, einschließlich der Systeme SAP NetWeaver und SAP S/4HANA, kann heute in der Azure-Infrastruktur gehostet werden. Azure bietet mehr als 800 CPU-Typen und VMs, die viele Terabytes an Speicher haben.

Beschreibungen der unterstützten Szenarien und einiger Szenarien, die nicht unterstützt werden, finden Sie unter Unterstützte Szenarien für SAP auf Azure VMs. Prüfen Sie diese Szenarien und die Bedingungen, die als nicht unterstützt angezeigt werden, wenn Sie die Architektur planen, die Sie in Azure bereitstellen möchten.

Um SAP-Systeme erfolgreich in Azure IaaS oder IaaS bereitzustellen, müssen Sie die wichtigsten Unterschiede zwischen den Angeboten herkömmlicher privater Clouds und IaaS-Angeboten kennen. Ein herkömmlicher Host oder Outsourcer passt die Infrastruktur (Netzwerk, Speicher und Servertyp) an die Workload an, die gehostet werden soll. Bei einer IaaS-Bereitstellung liegt es in der Verantwortung der Kundin bzw. des Kunden oder des Partnerunternehmens, die potenzielle Workload zu bewerten und die richtigen Azure-Komponenten (VMs, Storage und Netzwerk) auszuwählen.

Um Daten für die Planung Ihrer Bereitstellung auf Azure zu sammeln, ist es wichtig, dass Sie Folgendes tun:

  • Ermitteln Sie, welche SAP-Produkte und Versionen in Azure unterstützt werden.
  • Prüfen Sie, ob die Betriebssystemversionen, die Sie verwenden möchten, von den Azure-VMs unterstützt werden, die Sie für Ihre SAP-Produkte wählen würden.
  • Ermitteln Sie, welche DBMS-Versionen auf bestimmten VMs für Ihre SAP-Produkte unterstützt werden.
  • Prüfen Sie, ob ein Upgrade oder eine Aktualisierung Ihrer SAP-Landschaft erforderlich ist, um die erforderlichen Betriebssystem- und DBMS-Releases für eine unterstützte Konfiguration zu erreichen.
  • Beurteilen Sie, ob Sie für die Bereitstellung in Azure auf andere Betriebssysteme umsteigen müssen.

Einzelheiten zu unterstützten SAP-Komponenten auf Azure, Azure-Infrastruktureinheiten und zugehörigen Betriebssystem- und DBMS-Releases finden Sie unter Welche SAP-Software wird für Azure-Bereitstellungen unterstützt?. Das Wissen, das Sie aus der Bewertung der Unterstützung und der Abhängigkeiten zwischen SAP-Releases, Betriebssystem-Releases und DBMS-Releases gewinnen, hat einen erheblichen Einfluss auf Ihre Bemühungen, Ihre SAP-Systeme nach Azure zu verlagern. Sie erfahren, ob ein erheblicher Vorbereitungsaufwand erforderlich ist, z. B. ob Sie ein Upgrade Ihrer SAP-Version durchführen oder auf ein anderes Betriebssystem umsteigen müssen.

Erste Schritte bei der Planung einer Bereitstellung

Der erste Schritt bei der Planung der Bereitstellung besteht nicht darin, nach VMs zu suchen, die für die Ausführung von SAP-Anwendungen verfügbar sind.

Die ersten Schritte bei der Planung einer Bereitstellung sind die Zusammenarbeit mit den Compliance- und Sicherheitsteams in Ihrem Unternehmen, um festzustellen, welche Randbedingungen für die Bereitstellung welcher Art von SAP Workload oder Geschäftsprozess in einer öffentlichen Cloud gelten. Der Prozess kann zeitaufwendig sein, aber es ist eine wichtige Vorarbeit.

Wenn Ihr Unternehmen bereits Software in Azure bereitgestellt hat, dürfte der Prozess einfach sein. Wenn Ihr Unternehmen eher noch am Anfang der Reise steht, könnten größere Diskussionen notwendig sein, um die Randbedingungen, Sicherheitsbedingungen und die Unternehmensarchitektur herauszufinden, die es erlauben, bestimmte SAP-Daten und SAP-Geschäftsprozesse in einer öffentlichen Cloud zu hosten.

Planen der Compliance

Eine Liste der Compliance-Angebote von Microsoft, die Ihnen bei der Planung Ihrer Compliance-Anforderungen helfen können, finden Sie unter Microsoft Compliance-Angebote.

Planen der Sicherheit

Informationen zu SAP-spezifischen Sicherheitsaspekten, wie z. B. die Verschlüsselung von Daten im Ruhezustand oder andere Verschlüsselungen in einem Azure-Service, finden Sie unter Überblick über die Azure-Verschlüsselung und Sicherheit für Ihre SAP-Landschaft.

Organisieren von Azure-Ressourcen

Planen Sie zusammen mit der Überprüfung der Sicherheit und Compliance, falls Sie diese Aufgabe noch nicht erledigt haben, wie Sie Ihre Azure-Ressourcen organisieren. Der Prozess umfasst Entscheidungen über:

  • Eine Namenskonvention, die Sie für jede Azure-Ressource verwenden, z. B. für VMs und Ressourcengruppen.
  • Ein Abonnement- und Verwaltungsgruppendesign für Ihre SAP Workload, z. B. ob mehrere Abonnements pro Workload, pro Bereitstellungsebene oder für jede Geschäftseinheit erstellt werden sollen.
  • Unternehmensweite Nutzung von Azure-Richtlinien für Abonnements und Verwaltungsgruppen.

Um Ihnen zu helfen, die richtigen Entscheidungen zu treffen, werden viele Details der Unternehmensarchitektur im Azure Cloud Adoption Framework beschrieben.

Unterschätzen Sie bei Ihrer Planung nicht die Anfangsphase des Projekts. Erst wenn Sie Vereinbarungen und Regeln für die Einhaltung von Vorschriften, die Sicherheit und die Organisation von Azure-Ressourcen festgelegt haben, sollten Sie mit der Planung der Bereitstellung beginnen.

Die nächsten Schritte sind die Planung der geografischen Platzierung und der Netzwerkarchitektur, die Sie in Azure bereitstellen.

Azure-Geografien und -Regionen

Azure-Dienste sind in separaten Azure-Regionen verfügbar. Eine Azure-Region ist eine Sammlung von Rechenzentren. Die Rechenzentren enthalten die Hardware und Infrastruktur, die die in der Region verfügbaren Azure-Dienste hosten und ausführen. Die Infrastruktur umfasst eine große Anzahl von Knoten, die als Computeknoten oder Speicherknoten fungieren, oder die Netzwerkfunktionen ausführen.

Eine Liste der Azure-Regionen finden Sie unter Azure-Geografien. Eine interaktive Karte finden Sie unter Globale Azure-Infrastruktur.

Nicht alle Azure-Regionen bieten dieselben Dienste. Je nach dem SAP-Produkt, das Sie einsetzen möchten, Ihren Größenanforderungen und dem Betriebssystem und DBMS, das Sie benötigen, ist es möglich, dass eine bestimmte Region nicht die VM-Typen anbietet, die für Ihr Szenario erforderlich sind. Wenn Sie zum Beispiel SAP HANA einsetzen, benötigen Sie in der Regel VMs der verschiedenen VM-Familien der M-Serie. Diese VM-Familien werden nur in einer Teilmenge der Azure-Regionen bereitgestellt.

Wenn Sie mit der Planung beginnen und darüber nachdenken, welche Regionen Sie als Primärregion und eventuell als Sekundärregion auswählen möchten, müssen Sie prüfen, ob die Dienste, die Sie für Ihre Szenarien benötigen, in den Regionen, die Sie in Betracht ziehen, verfügbar sind. Welche VM-Typen, Azure-Speichertypen und andere Azure-Dienste in den einzelnen Regionen verfügbar sind, erfahren Sie unter Verfügbare Produkte nach Regionen.

Azure-Regionspaare

In einem Azure-Regionspaar ist die Replikation bestimmter Daten zwischen den beiden Regionen standardmäßig aktiviert. Weitere Informationen finden Sie unter Regionsübergreifende Replikation in Azure: Business Continuity & Disaster Recovery.

Die Datenreplikation in einem Regionspaar ist an die Arten von Azure-Speicher gebunden, die Sie für die Replikation in eine gepaarte Region konfigurieren können. Einzelheiten finden Sie unter Speicherredundanz in einer sekundären Region.

Bei den Speichertypen, die die Datenreplikation für Regionspaare unterstützen, handelt es sich um Speichertypen, die für SAP-Komponenten und einen DBMS Workload nicht geeignet sind. Die Nutzbarkeit der Azure-Speicherreplikation ist auf Azure Blob Storage (für Sicherungszwecke), Dateifreigaben und Volumes sowie andere Speicherszenarien mit hoher Latenz beschränkt.

Wenn Sie nach Regionspaaren und den Diensten suchen, die Sie in Ihrer primären oder sekundären Region verwenden möchten, ist es möglich, dass die Azure-Dienste oder VM-Typen, die Sie in Ihrer primären Region verwenden möchten, in der Region, die Sie als sekundäre Region verwenden möchten, nicht verfügbar sind. Oder Sie stellen fest, dass ein Azure-Regionspaar für Ihr Szenario aus Gründen der Dateneinhaltung nicht akzeptabel ist. Für diese Szenarien müssen Sie eine nicht gepaarte Region als sekundäre oder Notfallwiederherstellungsregion verwenden und einen Teil der Datenreplikation selbst einrichten.

Verfügbarkeitszonen

Viele Azure-Regionen verwenden Verfügbarkeitszonen, um Standorte innerhalb einer Azure-Region physisch zu trennen. Jede Verfügbarkeitszone besteht aus einem oder mehreren Rechenzentren, die mit unabhängiger Stromversorgung, Kühlung und unabhängigem Netzwerk ausgestattet sind. Ein Beispiel für die Verwendung einer Verfügbarkeitszone zur Verbesserung der Ausfallsicherheit ist die Bereitstellung von zwei VMs in zwei separaten Verfügbarkeitszonen in Azure. Ein weiteres Beispiel ist die Implementierung eines Hochverfügbarkeits-Frameworks für Ihr SAP DBMS-System in einer Verfügbarkeitszone und die Bereitstellung von SAP (A)SCS in einer anderen Verfügbarkeitszone, so dass Sie das beste SLA in Azure erhalten.

Weitere Informationen über VM SLAs in Azure finden Sie in der neuesten Version von SLAs für VMs. Da sich Azure-Regionen schnell entwickeln und erweitern, ändert sich die Topologie der Azure-Regionen, die Anzahl der physischen Rechenzentren, der Abstand zwischen den Rechenzentren und der Abstand zwischen Azure-Verfügbarkeitszonen. Die Netzwerklatenz ändert sich, wenn sich die Infrastruktur ändert.

Befolgen Sie die Anweisungen in SAP Workload-Konfigurationen mit Azure-Verfügbarkeitszonen, wenn Sie eine Region mit Verfügbarkeitszonen wählen. Bestimmen Sie auch, welches zonale Bereitstellungsmodell für Ihre Anforderungen, die von Ihnen gewählte Region und Ihre Workload am besten geeignet ist.

Fehlerdomänen

Fehlerdomänen stellen eine physische Fehlereinheit dar. Eine Fehlerdomäne steht in engem Zusammenhang mit der physischen Infrastruktur, die in Rechenzentren enthalten ist. Obwohl ein physisches Blade oder Rack als Fehlerdomäne betrachtet werden kann, gibt es keine direkte Eins-zu-Eins-Zuordnung zwischen einem physischen Computerelement und einer Fehlerdomäne.

Wenn Sie mehrere VMs als Teil eines SAP-Systems bereitstellen, können Sie den Azure Fabric Controller indirekt dahingehend beeinflussen, dass er Ihre VMs in verschiedenen Feherldomänen bereitstellt, so dass Sie die Anforderungen für Verfügbarkeits-SLAs erfüllen können. Sie haben jedoch keine direkte Kontrolle über die Verteilung von Fehlerdomänen über eine Azure-Skalierungseinheit (eine Sammlung von Hunderten von Compute- oder Speicherknoten und Netzwerken) oder die Zuordnung von VMs zu einer bestimmten Fehlerdomäne. Um den Azure Fabric Controller so zu steuern, dass er eine Reihe von VMs über verschiedene Fehlerdomänen bereitstellt, müssen Sie den VMs zum Zeitpunkt der Bereitstellung eine Azure-Verfügbarkeitsgruppe zuweisen. Weitere Informationen finden Sie unter Verfügbarkeitsgruppen.

Updatedomänen

Updatedomänen stellen eine logische Einheit dar, die festlegt, wie eine VM in einem SAP-System, das aus mehreren VMs besteht, aktualisiert wird. Wenn eine Plattformaktualisierung stattfindet, aktualisiert Azure diese Updatedomänen eine nach der anderen. Indem Sie die VMs zum Zeitpunkt der Bereitstellung auf verschiedene Update-Domänen verteilen, können Sie Ihr SAP-System vor möglichen Ausfallzeiten schützen. Ähnlich wie bei den Fehlerdomänen ist eine Azure-Skalierungseinheit in mehrere Updatedomänen unterteilt. Um den Azure Fabric Controller so zu steuern, dass er eine Reihe von VMs über verschiedene Update-Domänen bereitstellt, müssen Sie den VMs zum Zeitpunkt der Bereitstellung eine Azure-Verfügbarkeitsgruppe zuweisen. Weitere Informationen finden Sie unter Verfügbarkeitsgruppen.

Abbildung der Update- und Fehlerdomänen.

Verfügbarkeitsgruppen

Azure-VMs innerhalb einer Azure-Verfügbarkeitsgruppe werden vom Azure Fabric Controller auf verschiedene Fehlerdomänen verteilt. Die Verteilung auf verschiedene Fehlerdomänen soll verhindern, dass alle VMs eines SAP-Systems während der Wartung der Infrastruktur oder bei einem Ausfall in einer Fehlerdomäne heruntergefahren werden. Standardmäßig sind VMs nicht Teil einer Verfügbarkeitsgruppe. Sie können eine VM nur zum Zeitpunkt der Bereitstellung oder bei der Neuverteilung einer VM zu einem Availability Set hinzufügen.

Weitere Informationen über Azure Verfügbarkeitsgruppen und den Zusammenhang zwischen Verfügbarkeitsgruppen und Fehlerdomänen finden Sie unter Azure-Verfügbarkeitsgruppen.

Wichtig

Verfügbarkeitszonen und Verfügbarkeitsgruppen in Azure schließen sich gegenseitig aus. Sie können mehrere VMs in einer bestimmten Verfügbarkeitszone oder in einer Verfügbarkeitsgruppe bereitstellen. Allerdings können einer VM nicht sowohl die Verfügbarkeitszone als auch die Verfügbarkeitsgruppe zugewiesen werden.

Sie können Verfügbarkeitsgruppen und Verfügbarkeitszonen kombinieren, wenn Sie Näherungsplatzierungsgruppen verwenden.

Wenn Sie Verfügbarkeitsgruppen definieren und versuchen, verschiedene VMs unterschiedlicher VM-Familien in einer Verfügbarkeitsgruppe zu mischen, können Probleme auftreten, die verhindern, dass Sie einen bestimmten VM-Typ in eine Verfügbarkeitsgruppe aufnehmen können. Der Grund dafür ist, dass die Verfügbarkeitsgruppe an eine Skalierungseinheit gebunden ist, die einen bestimmten Typ von Computehost enthält. Ein bestimmter Typ von Computehost kann nur mit bestimmten Typen von VM-Familien betrieben werden.

Sie erstellen zum Beispiel eine Verfügbarkeitsgruppe und stellen die erste VM in der Verfügbarkeitsgruppe bereit. Die erste VM, die Sie der Verfügbarkeitsgruppe hinzufügen, gehört zur VM-Familie Edsv5. Wenn Sie versuchen, eine zweite VM – eine VM aus der M-Familie – bereitzustellen, schlägt diese Bereitstellung fehl. Der Grund dafür ist, dass VMs der Edsv5-Familie nicht auf der gleichen Hosthardware laufen wie die VMs der M-Familie.

Das gleiche Problem kann auftreten, wenn Sie die Größe von VMs ändern. Wenn Sie versuchen, eine VM aus der Edsv5-Familie in einen VM-Typ zu verschieben, der zur M-Familie gehört, schlägt die Bereitstellung fehl. Wenn Sie die Größe auf eine VM-Familie ändern, die nicht auf derselben Hosthardware gehostet werden kann, müssen Sie alle VMs in Ihrer Verfügbarkeitsgruppe herunterfahren und die Größe aller VMs ändern, damit sie auf dem anderen Hostcomputertyp ausgeführt werden können. Informationen zu SLAs von VMs, die in einer Verfügbarkeitsgruppe bereitgestellt werden, finden Sie unter SLAs für VMs.

VM-Skalierungsgruppen mit flexibler Orchestrierung

VM-Skalierungsgruppen mit flexibler Orchestrierung bieten eine logische Gruppierung von plattformseitig verwalteten VMs. Sie haben die Möglichkeit, eine Skalierungsgruppe innerhalb einer Region zu erstellen oder sie über Verfügbarkeitszonen zu verteilen. Beim Erstellen der flexiblen Skalierungsgruppe in einer Region mit „platformFaultDomainCount>1“ (FD>1) werden die in der Skalierungsgruppe bereitgestellten VMs über die angegebene Anzahl von Fehlerdomänen in derselben Region verteilt. Andererseits würde das Erstellen der flexiblen Skalierungsgruppe über Verfügbarkeitszonen hinweg mit „platformFaultDomainCount=1“ (FD=1) die VMs über die angegebene Zone verteilen, und die Skalierungsgruppe würde ebenfalls VMs möglichst auf unterschiedliche Fehlerdomänen innerhalb der Zone verteilen.

Für SAP-Workloads werden nur flexible Skalierungsgruppen mit „FD=1“ unterstützt. Der Vorteil der Verwendung flexibler Skalierungsgruppen mit „FD=1“ für domänenübergreifende Bereitstellungen anstelle der herkömmlichen Bereitstellung in Verfügbarkeitszonen besteht darin, dass die mit der Skalierungsgruppe bereitgestellten VMs auf verschiedene Fehlerdomänen innerhalb der Zone verteilt werden. Weitere Informationen über die Bereitstellung von SAP Workloads mit der Skalierungsgruppe finden Sie im Leitfaden für die flexible Skalierung von VMs.

Bei der Bereitstellung einer hochverfügbaren SAP Workload auf Azure ist es wichtig, die verschiedenen verfügbaren Bereitstellungsarten zu berücksichtigen und zu wissen, wie sie in verschiedenen Azure-Regionen angewendet werden können (z. B. zonenübergreifend, in einer einzigen Zone oder in einer Region ohne Zonen). Weitere Informationen finden Sie unter Optionen für die Bereitstellung von Hochverfügbarkeit für SAP Workloads.

Tipp

Derzeit gibt es keine direkte Möglichkeit, SAP Workloads, die in Verfügbarkeitsgruppen oder Verfügbarkeitszonen bereitgestellt werden, auf flexible Skalierung mit FD=1 zu migrieren. Um den Wechsel vorzunehmen, müssen Sie die VM und die Datenträger neu erstellen, wobei die Zoneneinschränkungen der bestehenden Ressourcen beibehalten werden. Ein Open-Source-Projekt enthält PowerShell-Funktionen, die Sie als Beispiel verwenden können, um eine in einer Verfügbarkeitsgruppe oder Verfügbarkeitszone bereitgestellte VM in eine flexible Skalierungsgruppe mit FD=1 zu ändern. In diesem Blogbeitrag erfahren Sie, wie Sie ein HA- oder Nicht-HA-SAP-System, das in einer Verfügbarkeitsgruppe oder Verfügbarkeitszone bereitgestellt wird, in eine flexible Skalierungsgruppe mit FD=1 umwandeln können.

Näherungsplatzierungsgruppen

Die Netzwerklatenz zwischen einzelnen SAP-VMs kann erhebliche Auswirkungen auf die Leistung haben. Insbesondere die Netzwerklaufzeit zwischen SAP-Anwendungsservern und dem DBMS kann erhebliche Auswirkungen auf Geschäftsanwendungen haben. Optimal ist es, wenn alle Compute-Elemente, auf denen Ihre SAP-VMs laufen, so nah wie möglich beieinander liegen. Diese Option ist nicht in jeder Kombination möglich, und Azure weiß möglicherweise nicht, welche VMs zusammen bleiben sollen. In den meisten Situationen und Regionen erfüllt die Standardplatzierung die Anforderungen an die Roundtrip-Latenz im Netzwerk.

Wenn die Standardplatzierung in einem SAP-System nicht ausreicht, um die Netzwerkanforderungen zu erfüllen, können Näherungsplatzierungsgruppen diesen Bedarf decken. Sie können Näherungsplatzierungsgruppen mit den Standortbeschränkungen von Azure-Region, Verfügbarkeitszone und Verfügbarkeitsgruppe verwenden, um die Ausfallsicherheit zu erhöhen. Bei einer Näherungsplatzierungsgruppe ist es möglich, sowohl Verfügbarkeitszonen als auch Verfügbarkeitsgruppen zu kombinieren und dabei unterschiedliche Aktualisierungs- und Ausfalldomänen festzulegen. Eine Näherungsplatzierungsgruppe sollte nur ein einzelnes SAP-System enthalten.

Obwohl die Bereitstellung in einer Näherungsplatzierungsgruppe zu einer optimalen Latenzzeit führen kann, hat die Bereitstellung mithilfe einer Näherungsplatzierungsgruppe auch Nachteile. Einige VM-Familien können nicht in einer Näherungsplatzierungsgruppe kombiniert werden, oder Sie könnten Probleme bekommen, wenn Sie die Größe zwischen VM-Familien ändern. Die Beschränkungen von VM-Familien, Regionen und Verfügbarkeitszonen unterstützen möglicherweise keine Colocation. Einzelheiten und Informationen zu den Vorteilen und potenziellen Herausforderungen bei der Verwendung einer Näherungsplatzierungsgruppe finden Sie unter Szenarien für Näherungsplatzierungsgruppen.

VMs, die keine Näherungsplatzierungsgruppen verwenden, sollten in den meisten Situationen die Standardmethode für die Bereitstellung von SAP-Systemen sein. Diese Vorgabe gilt insbesondere für zonale (eine einzige Verfügbarkeitszone) und zonenübergreifende (VMs, die auf zwei Verfügbarkeitszonen verteilt sind) Bereitstellungen eines SAP-Systems. Die Verwendung von Näherungsplatzierungsgruppen sollte nur dann auf SAP-Systeme und Azure-Regionen beschränkt werden, wenn dies aus Leistungsgründen erforderlich ist.

Azure-Netzwerke

Azure verfügt über eine Netzwerkinfrastruktur, die alle Szenarien abbildet, die Sie in einer SAP-Bereitstellung implementieren möchten. Azure bietet die folgenden Funktionen:

  • Zugriff auf Azure-Dienste und Zugriff auf bestimmte Ports in VMs, die von Anwendungen genutzt werden.
  • Direkter Zugriff auf VMs über Secure Shell (SSH) oder Windows Remote Desktop (RDP) zur Verwaltung und Administration.
  • Interne Kommunikation und Namensauflösung zwischen VMs und durch Azure-Dienste.
  • Lokale Konnektivität zwischen einem lokalen Netzwerk und Azure-Netzwerken.
  • Kommunikation zwischen Diensten, die in verschiedenen Azure-Regionen bereitgestellt werden.

Weitere Informationen zum virtuellen Azure-Netzwerk finden Sie unter Azure Virtual Network – FAQ.

Das Entwerfen von Netzwerken ist in der Regel die erste technische Aktivität, die Sie bei der Bereitstellung auf Azure durchführen. Die Unterstützung einer zentralen Unternehmensarchitektur wie SAP ist häufig Teil der allgemeinen Netzwerkanforderungen. In der Planungsphase sollten Sie die vorgeschlagene Netzwerkarchitektur so detailliert wie möglich dokumentieren. Wenn Sie zu einem späteren Zeitpunkt eine Änderung vornehmen, z. B. eine Änderung der Netzwerkadresse eines Subnetzes, müssen Sie die bereitgestellten Ressourcen möglicherweise verschieben oder löschen.

Virtuelle Azure-Netzwerke

Ein virtuelles Netzwerk ist ein grundlegender Baustein für Ihr privates Netzwerk in Azure. Sie können den Adressbereich des Netzwerks definieren und den Bereich in Netzwerk-Subnetze unterteilen. Ein Netzwerk-Subnetz kann für eine SAP-VM zur Verfügung stehen oder für einen bestimmten Dienst oder Zweck reserviert werden. Einige Azure-Dienste, wie Azure Virtual Network und Azure Application Gateway, erfordern ein eigenes Subnetz.

Ein virtuelles Netzwerk fungiert als Netzwerkgrenze. Bei der Planung Ihrer Bereitstellung müssen Sie unter anderem das virtuelle Netzwerk, die Subnetze und die Adressbereiche des privaten Netzwerks definieren. Sie können die Zuweisung des virtuellen Netzwerks für Ressourcen wie Netzwerkschnittstellenkarten (NICs) für VMs nicht mehr ändern, nachdem die VMs bereitgestellt wurden. Wenn Sie ein virtuelles Netzwerk oder einen Subnetz-Adressbereich ändern, müssen Sie möglicherweise alle bereitgestellten Ressourcen in ein anderes Subnetz verschieben.

Ihr Netzwerkdesign sollte mehrere Anforderungen für die Bereitstellung von SAP berücksichtigen:

  • Es werden keine virtuellen Netzwerkgeräte, wie z. B. eine Firewall, in den Kommunikationspfad zwischen der SAP-Anwendung und der DBMS-Schicht von SAP-Produkten über den SAP-Kernel, wie S/4HANA oder SAP NetWeaver, gestellt.
  • Netzwerkroutingeinschränkungen werden von Netzwerksicherheitsgruppen (NSGs) auf der Ebene des Subnetzes durchgesetzt. Gruppieren Sie IPs von VMs in Anwendungssicherheitsgruppen (ASGs), die in den NSG-Regeln verwaltet werden, und stellen Sie Rollen-, Schicht- und SID-Gruppierungen von Berechtigungen bereit.
  • SAP-Anwendungs- und Datenbank-VMs laufen im selben virtuellen Netzwerk, innerhalb desselben oder verschiedener Subnetze eines einzigen virtuellen Netzwerks. Verwenden Sie unterschiedliche Subnetze für Anwendungs- und Datenbank-VMs. Alternativ können Sie spezielle Anwendungs- und DBMS-ASGs verwenden, um Regeln zu gruppieren, die auf jeden Workloadtyp innerhalb desselben Subnetzes anwendbar sind.
  • Für SAP Workloads wird die Netzwerkbeschleunigung auf allen Netzwerkkarten aller VMs aktiviert, sofern dies technisch möglich ist.
  • Stellen Sie einen sicheren Zugang für die Abhängigkeit von zentralen Diensten sicher, einschließlich für die Namensauflösung (DNS), die Identitätsverwaltung (Windows Server Active Directory-Domänen/Microsoft Entra ID) und den administrativen Zugang.
  • Ermöglichen Sie bei Bedarf den Zugang zu und von öffentlichen Endpunkten. Beispiele hierfür sind die Azure-Verwaltung für ClusterLabs Pacemaker-Vorgänge in Hochverfügbarkeit oder für Azure-Dienste wie Azure Backup.
  • Verwenden Sie mehrere NICs nur dann, wenn sie notwendig sind, um ausgewiesene Subnetze zu erstellen, die über eigene Routen und NSG-Regeln verfügen.

Beispiele für Netzwerkarchitekturen für die Bereitstellung von SAP finden Sie in den folgenden Artikeln:

Überlegungen zum virtuellen Netzwerk

Für einige virtuelle Netzwerkkonfigurationen müssen Sie besondere Erwägungen anstellen.

  • Die Konfiguration von virtuellen Netzwerkgeräten im Kommunikationspfad zwischen der SAP-Anwendungsschicht und der DBMS-Schicht von SAP-Komponenten unter Verwendung des SAP-Kernels, wie S/4HANA oder SAP NetWeaver, wird nicht unterstützt.

    Virtuelle Netzwerkgeräte in Kommunikationspfaden können die Netzwerklatenz zwischen zwei Kommunikationspartnern locker verdoppeln. Außerdem können sie den Durchsatz in kritischen Pfaden zwischen der SAP-Anwendungsschicht und der DBMS-Schicht einschränken. In einigen Szenarien können virtuelle Netzwerkgeräte zum Ausfall von Pacemaker Linux-Clustern führen.

    Der Kommunikationspfad zwischen der SAP-Anwendungsschicht und der DBMS-Schicht muss ein direkter Pfad sein. Die Einschränkung gilt nicht für Regeln für ASGs und NSGs, wenn die ASG- und NSG-Regeln einen direkten Kommunikationspfad zulassen.

    Weitere Szenarien, in denen virtuelle Netzwerkgeräte nicht unterstützt werden:

  • Das Trennen der SAP-Anwendungsschicht und der DBMS-Schicht in verschiedene virtuelle Azure-Netzwerke wird nicht unterstützt. Es wird empfohlen, die SAP-Anwendungsschicht und die DBMS-Schicht durch Subnetze innerhalb des gleichen virtuellen Azure-Netzwerks zu trennen, anstatt verschiedene virtuelle Azure-Netzwerke zu verwenden.

    Wenn Sie ein nicht unterstütztes Szenario einrichten, das zwei SAP-Systemebenen in verschiedenen virtuellen Netzwerken trennt, müssen die beiden virtuellen Netzwerke Peers sein.

    Für den Netzwerkdatenverkehr zwischen zwei virtuellen Azure-Netzwerken mit Peering können Übertragungskosten anfallen. Jeden Tag wird ein riesiges Datenvolumen von vielen Terabytes zwischen der SAP-Anwendungsschicht und der DBMS-Schicht ausgetauscht. Sie können erhebliche Kosten verursachen, wenn die SAP-Anwendungsschicht und die DBMS-Schicht auf zwei getrennte virtuelle Azure-Netzwerke verteilt sind.

Namensauflösung und Domänendienste

Die Auflösung von Hostnamen in IP-Adressen über DNS ist oft ein entscheidendes Element für SAP-Netzwerke. Sie haben in Azure viele Optionen zur Konfiguration der Namens- und IP-Auflösung.

Oft hat ein Unternehmen eine zentrale DNS-Lösung, die Teil der Gesamtarchitektur ist. Mehrere Optionen zur nativen Implementierung der Namensauflösung in Azure, anstatt eigene DNS-Server einzurichten, sind unter Namensauflösung für Ressourcen in virtuellen Azure-Netzwerken beschrieben.

Wie bei DNS-Diensten kann es erforderlich sein, dass die SAP-VMs oder -Dienste auf Windows Server Active Directory zugreifen können.

IP-Adresszuweisung

Eine IP-Adresse für eine NIC wird während der gesamten Existenz der NIC einer VM beansprucht und verwendet. Die Regel gilt sowohl für die dynamische als auch für die statische IP-Zuweisung. Dies gilt unabhängig davon, ob die VM ausgeführt wird oder heruntergefahren ist. Die dynamische IP-Zuweisung wird aufgehoben, wenn die NIC gelöscht wird, wenn sich das Subnetz ändert oder wenn die Zuweisungsmethode auf statisch geändert wird.

Es ist möglich, VMs innerhalb eines virtuellen Azure-Netzwerks feste IP-Adressen zuzuweisen. Für SAP-Systeme, die von externen DNS-Servern und statischen Einträgen abhängen, werden IP-Adressen oft neu zugewiesen. Die IP-Adresse bleibt zugewiesen, entweder bis die VM und ihre NIC gelöscht werden oder bis die Zuweisung der IP-Adresse aufgehoben wird. Sie müssen die Gesamtzahl der VMs (ausgeführte und angehaltene) berücksichtigen, wenn Sie den Bereich der IP-Adressen für das virtuelle Netzwerk festlegen.

Weitere Informationen finden Sie unter Erstellen einer VM mit einer statischen privaten IP-Adresse.

Hinweis

Sie sollten sich zwischen statischer und dynamischer IP-Adresszuweisung für Azure-VMs und deren NICs entscheiden. Das Gastbetriebssystem der VM erhält die IP, die der NIC zugewiesen ist, wenn die VM startet. Sie sollten einer NIC keine statischen IP-Adressen im Gastbetriebssystem zuweisen. Einige Azure-Dienste wie Azure Backup verlassen sich darauf, dass zumindest die primäre Netzwerkkarte auf DHCP und nicht auf statische IP-Adressen innerhalb des Betriebssystems eingestellt ist. Weitere Informationen finden Sie unter Problembehandlung für die Sicherung von Azure-VMs.

Sekundäre IP-Adressen für die Virtualisierung von SAP-Hostnamen

Jeder NIC einer Azure-VM können mehrere IP-Adressen zugewiesen werden. Eine sekundäre IP kann für einen virtuellen SAP-Hostnamen verwendet werden, der einem DNS-A-Eintrag oder DNS-PTR-Eintrag zugeordnet ist. Der IP-Konfiguration der Azure-NIC muss eine sekundäre IP-Adresse zugewiesen werden. Eine sekundäre IP muss auch innerhalb des Betriebssystems statisch konfiguriert werden, da sekundäre IPs oft nicht über DHCP zugewiesen werden. Jede sekundäre IP muss aus demselben Subnetz stammen, an das die NIC gebunden ist. Eine sekundäre IP kann einer Azure-NIC hinzugefügt und entfernt werden, ohne dass die VM angehalten oder freigegeben werden muss. Um die primäre IP einer NIC hinzuzufügen oder zu entfernen, muss die VM deallokiert werden.

Der Azure Load Balancer wird von SAP-Hochverfügbarkeitsarchitekturen mit Pacemaker-Clustern verwendet. In diesem Szenario aktiviert der Load Balancer die virtuellen SAP-Hostnamen. Allgemeine Hinweise zur Verwendung von virtuellen Hostnamen finden Sie im SAP-Hinweis 962955.

Azure Load Balancer mit VMs, auf denen SAP läuft

Ein Load Balancer wird in der Regel in Hochverfügbarkeitsarchitekturen eingesetzt, um Floating-IP-Adressen zwischen aktiven und passiven Clusterknoten bereitzustellen. Sie können einen Load Balancer auch für eine einzelne VM verwenden, um eine virtuelle IP-Adresse für einen virtuellen SAP-Hostnamen zu halten. Die Verwendung eines Lastenausgleichs für eine einzelne VM ist eine Alternative zur Verwendung einer sekundären IP-Adresse auf einer NIC oder zum Verwenden mehrerer NICs im selben Subnetz.

Der Standard-Lastenausgleich ändert den standardmäßigen ausgehenden Zugriffspfad, da seine Architektur standardmäßig sicher ist. VMs, die sich hinter einem Standard-Lastenausgleich befinden, können möglicherweise nicht mehr dieselben öffentlichen Endpunkte erreichen. Einige Beispiele sind ein Endpunkt für ein Betriebssystemupdate-Repository oder ein öffentlicher Endpunkt von Azure-Diensten. Optionen für die Bereitstellung ausgehender Konnektivität finden Sie unter Öffentliche Endpunktkonnektivität für VMs mit dem Azure Load Balancer Standard.

Tipp

Der grundlegende Lastenausgleich sollte nicht mit einer SAP-Architektur in Azure verwendet werden. Das grundlegende Lastenausgleichsmodul wird demnächst eingestellt.

Mehrere vNICs pro VM

Sie können mehrere virtuelle Netzwerkschnittstellenkarten (vNICs) für eine Azure-VM definieren, wobei jede vNIC einem beliebigen Subnetz im selben virtuellen Netzwerk wie die primäre vNIC zugewiesen wird. Mit der Möglichkeit, mehrere vNICs zu haben, können Sie bei Bedarf eine Trennung des Netzwerkverkehrs einrichten. Beispielsweise wird der Client-Datenverkehr über die primäre vNIC geleitet und ein Teil des Verwaltungs- oder Backend-Datenverkehrs wird über eine zweite vNIC geleitet. Je nach Betriebssystem und dem von Ihnen verwendeten Image müssen die Datenverkehrsrouten für die NICs innerhalb des Betriebssystems möglicherweise für ein korrektes Routing eingerichtet werden.

Der Typ und die Größe einer VM bestimmen, wie viele vNICs einer VM zugewiesen werden können. Informationen über Funktionen und Einschränkungen finden Sie unter Zuweisen mehrerer IP-Adressen zu VMs über das Azure-Portal.

Das Hinzufügen von vNICs zu einer VM erhöht nicht die verfügbare Netzwerkbandbreite. Alle Netzwerkschnittstellen teilen sich die gleiche Bandbreite. Wir empfehlen Ihnen die Verwendung mehrerer NICs nur, wenn VMs auf private Subnetze zugreifen müssen. Wir empfehlen ein Entwurfsmuster, das sich auf die NSG-Funktionalität stützt und die Anforderungen an Netzwerk und Subnetz vereinfacht. Das Design sollte so wenig Netzwerkschnittstellen wie möglich verwenden, am besten nur eine. Eine Ausnahme ist das horizontal skalierende HANA, bei dem eine sekundäre vNIC für das interne HANA-Netzwerk erforderlich ist.

Warnung

Wenn Sie mehrere vNICs auf einer VM verwenden, empfehlen wir Ihnen, das Subnetz einer primären NIC für den Benutzernetzwerkdatenverkehr zu verwenden.

Beschleunigte Netzwerke

Um die Netzwerklatenz zwischen Azure-VMs weiter zu reduzieren, empfehlen wir Ihnen, sich zu vergewissern, dass der beschleunigte Netzwerkbetrieb von Azure auf jeder VM aktiviert ist, auf der ein SAP Workload ausgeführt wird. Obwohl der beschleunigte Netzwerkbetrieb für neue VMs standardmäßig aktiviert ist, sollten Sie den Status gemäß der Checkliste für die Bereitstellung überprüfen. Die Vorteile eines beschleunigten Netzwerkbetriebs sind eine deutlich verbesserte Netzwerkleistung und Latenzzeiten. Verwenden Sie ihn, wenn Sie Azure-VMs für SAP Workloads auf allen unterstützten VMs bereitstellen, insbesondere für die SAP Anwendungsschicht und die SAP DBMS-Schicht. Die verlinkte Dokumentation enthält Support-Abhängigkeiten von Betriebssystemversionen und VM-Instanzen.

Lokale Konnektivität

Die Bereitstellung von SAP in Azure setzt voraus, dass eine zentrale, unternehmensweite Netzwerkarchitektur und ein Kommunikationsknotenpunkt vorhanden sind, um die lokale Konnektivität zu ermöglichen. Die lokale Netzwerkkonnektivität ist unerlässlich, damit Benutzerinnen und Benutzer sowie Anwendungen Zugriff auf die SAP-Landschaft in Azure haben, um wiederum auf andere zentrale Unternehmensdienste zuzugreifen, wie z. B. die zentrale DNS-, Domänen-, Sicherheits- und Patch-Management-Infrastruktur.

Sie haben viele Möglichkeiten, lokale Konnektivität für Ihre SAP in Azure-Bereitstellung bereitzustellen. Bei der Bereitstellung des Netzwerks handelt es sich meist um eine Hub-Spoke-Netzwerktopologie oder eine Erweiterung der Hub-Spoke-Topologie, ein globales virtuelles WAN.

Für lokale SAP-Bereitstellungen empfehlen wir Ihnen, eine private Verbindung über Azure ExpressRoute zu verwenden. Für kleinere SAP Workloads, abgelegene Regionen oder kleinere Büros ist eine lokale VPN-Verbindung verfügbar. Die Verwendung von ExpressRoute mit einer VPN-Standort-zu-Standort-Verbindung als Failover-Pfad ist eine mögliche Kombination aus beiden Diensten.

Ausgehende und eingehende Internetkonnektivität

Ihre SAP-Landschaft benötigt eine Verbindung zum Internet, sei es, um Updates für das Betriebssystem-Repository zu erhalten, um eine Verbindung zu den SAP SaaS-Anwendungen an deren öffentlichen Endpunkten herzustellen oder um auf einen Azure-Dienst über dessen öffentlichen Endpunkt zuzugreifen. In ähnlicher Weise kann es erforderlich sein, dass Sie Ihren Kundinnen und Kunden Zugang zu SAP Fiori-Anwendungen gewähren, wobei diese über das Internet auf Dienste zugreifen, die von Ihrer SAP-Landschaft bereitgestellt werden. Für Ihre SAP-Netzwerkarchitektur müssen Sie den Pfad zum Internet und alle eingehenden Anforderungen planen.

Sichern Sie Ihr virtuelles Netzwerk durch die Verwendung von NSG-Regeln, durch die Verwendung von Netzwerkdienst-Tags für bekannte Dienste und durch die Einrichtung von Routing und IP-Adressen für Ihre Firewall oder eine andere virtuelle Netzwerkgeräte. All diese Aufgaben oder Überlegungen sind Teil der Architektur. Ressourcen in privaten Netzwerken müssen durch Layer-4- und Layer-7-Firewalls im Netzwerk geschützt werden.

Die Kommunikationswege mit dem Internet stehen im Mittelpunkt einer Architektur mit bewährten Methoden.

Azure-VMs für SAP-Workloads

Einige Azure-VM-Familien eignen sich besonders gut für SAP Workloads, und einige speziell für einen SAP HANA Workload. Wie Sie den richtigen VM-Typ und seine Fähigkeit zur Unterstützung Ihrer SAP Workload finden, ist in Welche SAP-Software wird für Azure-Bereitstellungen unterstützt beschrieben. Im SAP-Hinweis 1928533 finden Sie außerdem eine Liste aller zertifizierten Azure-VMs und ihrer Leistungsfähigkeit, gemessen am SAP Application Performance Standard (SAPS)-Benchmark, sowie der Grenzwerte, sofern diese zutreffen. Die VM-Typen, die für eine SAP Workload zertifiziert sind, verwenden kein Over-Provisioning für CPU- und Speicherressourcen.

Sie müssen nicht nur die Auswahl der unterstützten VM-Typen betrachten, sondern auch prüfen, ob diese VM-Typen in einer bestimmten Region verfügbar sind, und zwar auf der Grundlage von Verfügbare Produkte nach Region. Mindestens ebenso wichtig ist es, festzustellen, ob die folgenden Fähigkeiten einer VM für Ihr Szenario geeignet sind:

  • CPU-Ressourcen und Arbeitsspeicherressourcen
  • Bandbreite der Eingabe-/Ausgabevorgänge pro Sekunde (IOPS)
  • Netzwerkfunktionen
  • Anzahl der Datenträger, die angefügt werden können
  • Möglichkeit, bestimmte Azure-Speichertypen zu verwenden

Diese Informationen für eine bestimmte VM-Familie und einen bestimmten Typ finden Sie unter Größen für virtuelle VMs in Azure.

Preismodelle für Azure-VMs

Für ein VM-Preismodell können Sie die gewünschte Option auswählen:

  • Ein nutzungsbasiertes Bezahlungsmodell
  • Ein einjähriger Reserve- oder Sparplan
  • Ein auf drei Jahre angelegter Reserve- oder Sparplan
  • Ein Spot-Preis-Modell

Ausführliche Informationen zu den VM-Preisen für verschiedene Azure-Dienste, Betriebssysteme und Regionen finden Sie unter Preise für VMs.

Wenn Sie mehr über die Preise und die Flexibilität der ein- und dreijährigen Sparpläne und der reservierten Instanzen erfahren möchten, lesen Sie diese Artikel:

Weitere Informationen über Spot-Preise finden Sie unter Azure Spot-VMs.

Die Preise für denselben VM-Typ können zwischen Azure-Regionen variieren. Einige Kundinnen und Kunden profitieren von der Bereitstellung in einer kostengünstigeren Azure-Region, sodass Informationen zu Preisen nach Region beim Planen hilfreich sein können.

Azure bietet auch die Möglichkeit, einen dedizierten Host zu verwenden. Die Verwendung eines dedizierten Hosts bietet Ihnen mehr Kontrolle über Patchingzyklen für Azure-Dienste. Sie können das Patching so planen, dass es Ihren eigenen Zeitplan und Ihre Zyklen berücksichtigt. Dieses Angebot richtet sich speziell an Kundinnen und Kunden, die eine Workload haben, die nicht dem normalen Zyklus einer Workload folgt. Weitere Informationen finden Sie unter Azure Dedicated Host.

Die Verwendung eines Azure Dedicated Host wird für eine SAP-Workload unterstützt. Mehrere SAP-Kundinnen und Kunden, die mehr Kontrolle über Infrastrukturpatching- und Wartungspläne haben möchten, verwenden Azure Dedicated Hosts. Weitere Informationen dazu, wie Microsoft die Azure-Infrastruktur, die VMs hostet, verwaltet und patcht finden Sie im Artikel Wartung für VMs in Azure.

Betriebssystem für VMs

Wenn Sie neue VMs für eine SAP-Landschaft in Azure bereitstellen, entweder um ein SAP-System zu installieren oder zu migrieren, ist es wichtig, das richtige Vorgangssystem für Ihre Workload zu wählen. Azure bietet eine große Auswahl an Betriebssystem-Images für Linux und Windows und viele geeignete Optionen für SAP-Systeme. Sie können auch benutzerdefinierte Images aus Ihrer lokalen Umgebung erstellen oder hochladen, oder Sie können Imagegalerien nutzen oder verallgemeinern.

Ausführliche Informationen zu den verfügbaren Optionen finden Sie unter:

Planen Sie bei Bedarf eine Betriebssystem-Update-Infrastruktur und deren Abhängigkeiten für Ihre SAP Workload ein. Erwägen Sie den Einsatz einer Repository-Stagingumgebung, um alle Schichten einer SAP-Landschaft (Sandbox, Entwicklung, Vorproduktion und Produktion) zu synchronisieren, indem Sie während des Updatezeitraums die gleichen Versionen von Patches und Updates verwenden.

VMs der Generation 1 und Generation 2

In Azure können Sie eine VM entweder als Generation 1 oder Generation 2 bereitstellen. Unterstützung für VMs der Generation 2 in Azure listet die Azure-VM-Familien auf, die Sie als Generation 2 bereitstellen können. Der Artikel listet auch die funktionalen Unterschiede zwischen VMs der Generation 1 und der Generation 2 in Azure auf.

Wenn Sie eine VM bereitstellen, bestimmt das von Ihnen gewählte Betriebssystem-Image, ob es sich um eine VM der Generation 1 oder der Generation 2 handelt. Die neuesten Versionen aller Betriebssystem-Images für SAP, die in Azure verfügbar sind (Red Hat Enterprise Linux, SuSE Enterprise Linux und Windows oder Oracle Enterprise Linux), sind sowohl in Generation 1 als auch in Generation 2 verfügbar. Es ist wichtig, dass Sie ein Image anhand der Image-Beschreibung sorgfältig auswählen, um die richtige VM-Generation bereitzustellen. In ähnlicher Weise können Sie benutzerdefinierte Betriebssystem-Images als Generation 1 oder Generation 2 erstellen, was sich bei der Bereitstellung der VM auf die VM-Generation auswirken.

Hinweis

Wir empfehlen Ihnen, bei allen SAP-Bereitstellungen in Azure-VMs der Generation 2 zu verwenden, unabhängig von der VM-Größe. Alle aktuellen Azure-VMs für SAP sind Generation 2-fähig oder auf die Generation 2 beschränkt. Einige VM-Familien unterstützen derzeit nur VMs der Generation 2. Einige zukünftige VM-Familien unterstützen möglicherweise nur die Generation 2.

Sie können anhand des ausgewählten Betriebssystem-Images feststellen, ob eine VM Generation 1- oder nur Generation 2-basiert ist. Eine Umstellung einer vorhandenen VM von einer Generation in die andere Generation ist nicht möglich.

Das Umstellen einer bereitgestellten VM von Generation 1 auf Generation 2 ist in Azure nicht möglich. Um die VM-Generation umzustellen, müssen Sie eine neue VM bereitstellen, die der gewünschten Generation entspricht, und Ihre Software auf der neuen VM-Generation neu installieren. Diese Änderung betrifft nur das VHD-Basisimage der VM und hat keine Auswirkungen auf die Datenfestplatten oder angehängte Network File System (NFS) oder Server Message Block (SMB) Freigaben. Datenträger, NFS-Freigaben oder SMB-Freigaben, die ursprünglich einer VM der Generation 1 zugewiesen waren, können an eine neue VM der Generation 2 angefügt werden.

Einige VM-Familien, wie die Mv2-Serie, unterstützen nur die Generation 2. Dieselbe Anforderung könnte in Zukunft auch für neue VM-Familien gelten. In diesem Szenario kann eine vorhandene VM der Generation 1 nicht an die neue VM-Familie angepasst werden. Zusätzlich zu den Anforderungen der Azure-Plattform der Generation 2 haben Ihre SAP-Komponenten möglicherweise Anforderungen, die mit der Generation einer VM zusammenhängen. Informationen zu den Anforderungen der Generation 2 für die von Ihnen gewählte VM-Familie finden Sie im SAP-Hinweis 1928533.

Leistungsbeschränkungen für Azure-VMs

Als öffentliche Cloud ist Azure darauf angewiesen, seine Infrastruktur auf sichere Weise mit seinen Kundinnen und Kunden zu teilen. Um Skalierung und Kapazität zu ermöglichen, werden für jede Ressource und jeden Dienst Grenzwerte für die Leistung festgelegt. Auf der Compute-Seite der Azure-Infrastruktur ist es wichtig, die Grenzwerte zu beachten, die für jede VM-Größe definiert sind.

Jede VM hat unterschiedliche Kontingente für den Datenträger- und Netzwerkdurchsatz, die Anzahl der Datenträger, die angeschlossen werden können, ob sie über einen lokalen temporären Speicher verfügt, der eigene Grenzwerte für Durchsatz und IOPS hat, die Größe des Arbeitsspeichers und wie viele vCPUs verfügbar sind.

Hinweis

Wenn Sie Entscheidungen über die VM-Größe für eine SAP-Lösung auf Azure treffen, müssen Sie die Leistungsbeschränkungen für jede VM-Größe berücksichtigen. Die in der Dokumentation beschriebenen Kontingente stellen die theoretisch maximal erreichbaren Werte dar. Die Leistungsbeschränkung von IOPS pro Festplatte kann bei kleinen Ein-/Ausgabewerten (z. B. 8 KB) erreicht werden, bei großen E/A-Werten (z. B. 1 MB) jedoch nicht.

Wie bei VMs gelten für jeden Speichertyp die gleichen Leistungsbeschränkungen für eine SAP Workload und für alle anderen Azure-Dienste.

Wenn Sie VMs für Ihre SAP-Bereitstellung planen und auswählen, sollten Sie diese Faktoren berücksichtigen:

  • Beginnen Sie mit den Arbeitsspeicher- und CPU-Anforderungen. Trennen Sie die SAPS-Anforderungen an die CPU-Leistung in den DBMS-Teil und die SAP-Anwendungsteile. Für bestehende Systeme kann der SAPS in Bezug auf die von Ihnen häufig verwendete Hardware auf der Grundlage bestehender SAP Standard Application Benchmarks ermittelt oder geschätzt werden. Führen Sie für neu bereitgestellte SAP-Systeme eine Größenbestimmung durch, um die SAPS-Anforderungen für das System zu ermitteln.

  • Bei bestehenden Systemen sollten der E/A-Durchsatz und die IOPS auf dem DBMS-Server gemessen werden. Bei neuen Systemen sollte Ihnen die Dimensionierung des neuen Systems auch eine allgemeine Vorstellung von den E/A-Anforderungen auf der DBMS-Seite geben. Falls Sie sich unsicher sind, sollten Sie eventuell eine Machbarkeitsstudie durchführen.

  • Vergleichen Sie die SAPS-Anforderungen für den DBMS-Server mit den SAPS der verschiedenen von Azure bereitgestellten VM-Typen. Informationen über die SAPS der verschiedenen Azure-VM-Typen finden Sie in SAP-Hinweis 1928533. Hauptaugenmerk sollten Sie zunächst auf die DBMS-VM legen, da die Datenbankebene die Ebene in einem SAP-NetWeaver-System ist, die sich in den meisten Bereitstellungen nicht aufskalieren lässt. Im Gegensatz dazu lässt sich die SAP-Anwendungsebene durchaus verteilen. Einzelne DBMS-Leitfäden beschreiben die empfohlenen Speicherkonfigurationen.

  • Fassen Sie Ihre Ergebnisse zusammen für:

    • Die Anzahl der Azure-VMs, die Sie verwenden möchten.
    • Einzelne VM-Familien- und VM-SKUs für jede SAP-Schicht: DBMS, (A)SCS und Anwendungsserver.
    • E/A-Durchsatzkennzahlen oder berechnete Speicherkapazitätsanforderungen.

Dienst HANA (große Instanzen)

Azure bietet Computefunktionen für den Betrieb einer großen vertikal oder horizontal skalierbaren HANA-Datenbank über ein spezielles Angebot mit der Bezeichnung SAP HANA in Azure (große Instanzen). Dieses Angebot erweitert die VMs, die in Azure verfügbar sind.

Hinweis

Der Dienst HANA (große-Instanzen) befindet sich im Auslaufmodus und akzeptiert keine neuen Kundinnen und Kunden mehr. Die Bereitstellung von Einheiten für vorhandene Kundinnen und Kunden von HANA (große Instanzen) ist weiterhin möglich.

Speicher für SAP in Azure

Azure-VMs verwenden verschiedene Speicheroptionen für Persistenz. Vereinfacht ausgedrückt können die VMs in persistente und temporäre oder nicht-persistente Speichertypen unterteilt werden.

Sie können aus mehreren Speicheroptionen für SAP Workloads und für bestimmte SAP-Komponenten wählen. Weitere Informationen finden Sie unter Azure Storage für SAP Workloads. In diesem Artikel wird die Speicherarchitektur für jeden Teil von SAP behandelt: Betriebssystem, Binärdateien für Anwendungen, Konfigurationsdateien, Datenbankdaten, Protokoll- und Ablaufverfolgungsprotokolle sowie Dateischnittstellen zu anderen Anwendungen, unabhängig davon, ob sie auf dem Datenträger gespeichert sind oder über Dateifreigaben aufgerufen werden.

Temporärer Datenträger in VMs

Die meisten Azure-VMs für SAP bieten einen temporären Datenträger, bei dem es sich nicht um einen verwalteten Datenträger handelt. Verwenden Sie einen temporären Datenträger nur für entbehrliche Daten. Die Daten auf einem temporären Datenträger können bei unvorhergesehenen Wartungsereignissen oder bei der Neuverteilung von VMs verloren gehen. Die Leistungsmerkmale des temporären Datenträgers eignen sich ideal als Austausch-/Seitendateien des Betriebssystems.

Auf einem temporären Datenträger sollten keine Daten von Anwendungen oder des Betriebssystems gespeichert werden, die nicht gelöscht werden dürfen. In Windows-Umgebungen ist der temporäre Datenträger in der Regel das Laufwerk D. In Linux-Systemen ist der Einhängepunkt oft /dev/sdb device, /mnt, oder /mnt/resource.

Einige VMs bieten keinen temporären Datenträger. Wenn Sie diese VM-Größen für SAP verwenden möchten, müssen Sie möglicherweise die Größe des Betriebssystemlaufwerks erhöhen. Weitere Informationen finden Sie im SAP-Hinweis 1928533. Für VMs, die über einen temporären Datenträger verfügen, erhalten Sie Informationen über die Größe des temporären Datenträgers und die Grenzwerte für IOPS und Durchsatz für jede VM-Serie unter VM-Größen in Azure.

Sie können nicht direkt zwischen einer VM-Serie mit temporären Datenträgern und einer VM-Serie ohne temporäre Datenträger wechseln. Derzeit schlägt eine Größenänderung zwischen zwei solchen VM-Familien fehl. Eine Lösung besteht darin, die VM, die keinen temporären Datenträger hat, mithilfe einer Momentaufnahme des Betriebssystems in der neuen Größe neu zu erstellen. Behalten Sie alle anderen Datenträger und die Netzwerkschnittstelle. Erfahren Sie, wie Sie die Größe einer VM mit einem lokalen temporären Datenträger auf eine VM-Größe ändern können, die keine lokalen temporären Datenträger hat.

Netzwerkfreigaben und Volumes für SAP

SAP-Systeme benötigen in der Regel eine oder mehrere Netzwerk-Dateifreigaben. Die Dateifreigaben sind in der Regel eine der folgenden Optionen:

  • Ein SAP-Transportverzeichnis (/usr/sap/trans oder TRANSDIR).
  • SAP-Volumes oder gemeinsam genutzte sapmnt- oder saploc-Volumes zur Bereitstellung mehrerer Anwendungsserver.
  • Hochverfügbare Architekturvolumes für SAP (A)SCS, SAP ERS oder eine Datenbank (/hana/shared).
  • Dateischnittstellen, die Anwendungen von Drittanbietern für den Import und Export von Dateien ausführen.

In diesen Szenarien sollten Sie einen Azure-Dienst wie Azure Files oder Azure NetApp Files verwenden. Wenn diese Dienste in den von Ihnen gewählten Regionen nicht verfügbar sind oder für Ihre Lösungsarchitektur nicht in Frage kommen, können Sie alternativ NFS- oder SMB-Dateifreigaben über selbst verwaltete, VM-basierte Anwendungen oder über Dienste von Drittanbietern bereitstellen. Weitere Informationen über Grenzwerte für die SAP-Unterstützung bei der Verwendung von Drittanbieterdiensten für Speicherebenen in einem SAP-System in Azure finden Sie im SAP-Hinweis 2015553.

Aufgrund der oft kritischen Natur von Netzwerkfreigaben und der Tatsache, dass sie oft einen Single Point of Failure in einem Design (für Hochverfügbarkeit) oder Prozess (für die Dateischnittstelle) darstellen, sollten Sie sich darauf verlassen, dass jeder Azure-eigene Dienst für seine eigene Verfügbarkeit, SLA und Ausfallsicherheit sorgt. In der Planungsphase ist es wichtig, diese Faktoren zu berücksichtigen:

  • NFS- oder SMB-Freigabe-Design, einschließlich der zu verwendenden Freigaben pro SAP-System-ID (SID), pro Landschaft und pro Region.
  • Dimensionierung von Subnetzen, einschließlich der IP-Anforderungen für private Endpunkte oder dedizierte Subnetze für Dienste wie Azure NetApp Files.
  • Netzwerk-Routing zu SAP-Systemen und angeschlossenen Anwendungen.
  • Verwendung eines öffentlichen oder privaten Endpunkts für Azure Files.

Informationen zu den Anforderungen und zur Verwendung einer NFS- oder SMB-Freigabe in einem Hochverfügbarkeitsszenario finden Sie unter Hochverfügbarkeit.

Hinweis

Wenn Sie Azure Files für Ihre Netzwerkfreigaben verwenden, sollten Sie einen privaten Endpunkt verwenden. Im unwahrscheinlichen Fall eines Zonenausfalls leitet Ihr NFS-Client automatisch auf eine fehlerfreie Zone um. Sie müssen die NFS- oder SMB-Freigaben auf Ihren VMs nicht neu einbinden.

Sicherheit für Ihre SAP-Landschaft

Um Ihre SAP-Workload in Azure zu schützen, müssen Sie mehrere Sicherheitsaspekte einplanen:

  • Netzwerksegmentierung und die Sicherheit der einzelnen Subnetze und Netzwerkschnittstellen.
  • Verschlüsselung auf jeder Ebene innerhalb der SAP-Landschaft.
  • Identitätslösung für Endbenutzer- und Administratorzugriff und Einmaliges Anmelden.
  • Überwachung von Bedrohungen und Vorgängen.

Die Themen in diesem Kapitel sind keine vollständige Liste aller verfügbaren Dienste, Optionen und Alternativen. Es werden mehrere bewährte Methoden aufgeführt, die für alle SAP-Bereitstellungen in Azure berücksichtigt werden sollten. Je nach Unternehmens- oder Workloadanforderungen gibt es weitere Aspekte, die abgedeckt werden müssen. Weitere Informationen zum Sicherheitsdesign finden Sie in den folgenden Ressourcen mit allgemeinen Anweisungen für Azure:

Sichern von virtuellen Netzwerken mit Netzwerksicherheitsgruppen

Die Planung Ihrer SAP-Landschaft in Azure sollte ein gewisses Maß an Netzwerksegmentierung umfassen, wobei virtuelle Netzwerke und Subnetze nur für SAP-Workloads vorgesehen sind. Bewährte Methoden für die Subnetzdefinition werden in Netzwerk und in anderen Azure-Architekturhandbüchern beschrieben. Es wird empfohlen, NSGs mit ASGs innerhalb von NSGs zu verwenden, um eingehende und ausgehende Verbindungen zu ermöglichen. Wenn Sie ASGs entwerfen, kann jede NIC auf einer VM mehreren ASGs zugeordnet werden, sodass Sie unterschiedliche Gruppen erstellen können. Erstellen Sie z. B. eine ASG für DBMS-VMs, die alle Datenbankserver der Landschaft enthält. Erstellen Sie eine weitere ASG für alle VMs (Anwendung und DBMS) einer einzelnen SAP-SID. Auf diese Weise können Sie eine NSG-Regel für die Gesamtdatenbank-ASG und eine andere, spezifischere Regel nur für die SID-spezifische ASG definieren.

NSGs beschränken die Leistung nicht mit den Regeln, die Sie für die NSG definieren. Für die Überwachung des Datenverkehrsflusses können Sie optional NSG-Ablaufprotokollierung mit Protokollen aktivieren, die von einem SIEM (Information Event Management) oder einem Angriffserkennungssystem (Intrusion Detection System, IDS) Ihrer Wahl ausgewertet werden, um verdächtige Netzwerkaktivitäten zu überwachen und darauf zu reagieren.

Tipp

Aktivieren Sie NSGs nur auf Subnetzebene. Obwohl NSGs sowohl auf der Subnetzebene als auch auf der NIC-Ebene aktiviert werden können, ist die Aktivierung auf beiden Seiten für die Problembehandlung bei der Analyse von Netzwerkdatenverkehrseinschränkungen sehr häufig eine Behinderung. Verwenden Sie NSGs auf NIC-Ebene nur in Ausnahmefällen und bei Bedarf.

Private Endpunkte für Dienste

Auf viele Azure PaaS-Dienste wird standardmäßig über einen öffentlichen Endpunkt zugegriffen. Obwohl sich der Kommunikationsendpunkt im Azure-Back-End-Netzwerk befindet, wird der Endpunkt für das öffentliche Internet verfügbar gemacht. Private Endpunkte sind eine Netzwerkschnittstelle innerhalb Ihres eigenen privaten virtuellen Netzwerks. Über Azure Private Linkprojiziert der private Endpunkt den Dienst in Ihr virtuelles Netzwerk. Ausgewählte PaaS-Dienste werden dann privat über die IP-Adresse in Ihrem Netzwerk aufgerufen. Je nach Konfiguration kann der Dienst möglicherweise nur für die Kommunikation über einen privaten Endpunkt festgelegt werden.

Die Verwendung eines privaten Endpunkts erhöht den Schutz vor Datenlecks und vereinfacht häufig den Zugriff von lokalen und Peer-Netzwerken. In vielen Situationen wird das Netzwerkrouting und der Prozess zum Öffnen von Firewallports vereinfacht, die häufig für öffentliche Endpunkte erforderlich sind. Die Ressourcen befinden sich bereits in Ihrem Netzwerk, da darauf von einem privaten Endpunkt zugegriffen wird.

Informationen dazu, welche Azure-Dienste die Möglichkeit bieten, einen privaten Endpunkt zu verwenden, finden Sie unter Verfügbare Dienste für Private Link. Für NFS oder SMB mit Azure Files wird empfohlen, dass Sie immer private Endpunkte für SAP-Workloads verwenden. Weitere Informationen zu Gebühren, die durch die Nutzung des Diensts entstehen, finden Sie unter Preise für private Endpunkte. In einigen Azure-Diensten können optional die Kosten für den Dienst enthalten sein. Diese Informationen finden Sie in den Preisinformationen eines Diensts.

Verschlüsselung

Je nach Ihren Unternehmensrichtlinien ist möglicherweise für Ihre SAP-Workloads eine Verschlüsselung über die Standardoptionen hinaus erforderlich.

Verschlüsselung für Infrastrukturressourcen

Standardmäßig werden verwaltete Datenträger und Blob-Speicher in Azure mit einem plattformseitig verwalteten Schlüssel (PMK) verschlüsselt. Darüber hinaus wird die BYOK-Verschlüsselung (Bring Your Own Key) für verwaltete Datenträger und Blob-Speicher für SAP-Workloads in Azure unterstützt. Für verwaltete Datenträgerverschlüsselungkönnen Sie je nach Sicherheitsanforderungen Ihres Unternehmens aus verschiedenen Optionen wählen. Zu den Azure-Verschlüsselungsoptionen gehören:

  • Speicherseitige Verschlüsselung (SSE) PMK (SSE-PMK)
  • SSE kundenseitig verwalteter Schlüssel (SSE-CMK)
  • Doppelte Verschlüsselung im Ruhezustand
  • Hostbasierte Verschlüsselung

Weitere Informationen, einschließlich einer Beschreibung der Azure Disk Encryption, finden Sie in einem Vergleich der Azure-Verschlüsselungsoptionen.

Hinweis

Verwenden Sie aufgrund einer potenziellen Leistungsbeschränkung derzeit keine hostbasierte Verschlüsselung auf einer VM der VM-Familie der M-Serie, wenn sie mit Linux ausgeführt wird. Die Verwendung der SSE-CMK-Verschlüsselung für verwaltete Datenträger ist von dieser Einschränkung unberührt.

Verwenden Sie für SAP-Bereitstellungen auf Linux-Systemen keine Azure Disk Encryption. Azure Disk Encryption umfasst Verschlüsselung, die innerhalb der SAP-VMs mithilfe von CMKs aus Azure Key Vault ausgeführt wird. Unter Linux unterstützt Azure Disk Encryption nicht die Betriebssystemimages, die für SAP-Workloads verwendet werden. Azure Disk Encryption kann auf Windows-Systemen mit SAP-Workloads verwendet werden. Kombinieren Sie jedoch keine Azure Disk Encryption mit der systemeigenen Datenbankverschlüsselung. Sie sollten die systemeigene Datenbankverschlüsselung anstelle der Azure Disk Encryption verwenden. Weitere Informationen finden Sie im nächsten Abschnitt.

Ähnlich wie die verwaltete Datenträgerverschlüsselung ist die Azure Files Verschlüsselung ruhender Dateien (SMB und NFS) mit PMKs oder CMKs verfügbar.

Prüfen Sie bei SMB-Netzwerkfreigaben sorgfältig die Abhängigkeiten von Azure Files und dem Betriebssystem mit SMB-Versionen, da die Konfiguration die Unterstützung für die Verschlüsselung während der Übertragung beeinflusst.

Wichtig

Die Bedeutung eines sorgfältigen Plans zur Aufbewahrung und zum Schutz der Verschlüsselungsschlüssel, wenn Sie eine kundenseitig verwaltete Verschlüsselung verwenden, kann nicht hoch genug eingeschätzt werden. Ohne Verschlüsselungsschlüssel sind verschlüsselte Ressourcen wie Datenträger unzugänglich und können zu Datenverlust führen. Überlegen Sie sorgfältig, ob Sie die Schlüssel und den Zugang zu den Schlüsseln nur privilegierten Benutzerinnen und Benutzern oder Diensten zur Verfügung stellen wollen.

Verschlüsselung für SAP-Komponenten

Die Verschlüsselung auf SAP-Ebene kann in zwei Ebenen unterteilt werden:

  • DBMS-Verschlüsselung
  • Transportverschlüsselung

Für die DBMS-Verschlüsselung unterstützt jede Datenbank, die für eine SAP NetWeaver- oder SAP S/4HANA-Bereitstellung unterstützt wird, die native Verschlüsselung. Die transparente Datenbankverschlüsselung ist völlig unabhängig von der in Azure vorhandenen Infrastrukturverschlüsselung. Sie können SSE- und Datenbankverschlüsselung gleichzeitig verwenden. Wenn Sie Verschlüsselung verwenden, ist der Ort, die Speicherung und die sichere Aufbewahrung der Verschlüsselungsschlüssel von entscheidender Bedeutung. Jeder Verlust von Verschlüsselungsschlüsseln führt zu Datenverlust, da Sie nicht in der Lage sind, Ihre Datenbank zu starten oder wiederherzustellen.

Einige Datenbanken verfügen möglicherweise nicht über eine Datenbankverschlüsselungsmethode oder erfordern keine spezielle Einstellung zur Aktivierung. Bei anderen Datenbanken können DBMS-Sicherungen implizit verschlüsselt werden, wenn die Datenbankverschlüsselung aktiviert ist. In der folgenden SAP-Dokumentation erfahren Sie, wie Sie die transparente Datenbankverschlüsselung aktivieren und verwenden können:

Wenden Sie sich an SAP oder Ihren DBMS-Anbieter, um Unterstützung bei der Aktivierung, Verwendung oder Problembehandlung der Softwareverschlüsselung zu erhalten.

Wichtig

Es kann nicht genug betont werden, wie wichtig es ist, einen sorgfältigen Plan für die Speicherung und den Schutz Ihrer Verschlüsselungsschlüssel zu haben. Ohne Verschlüsselungsschlüssel kann die Datenbank oder die SAP-Software unzugänglich sein und Sie könnten Daten verlieren. Überlegen Sie sorgfältig, wie Sie die Schlüssel schützen können. Erlauben Sie den Zugriff auf die Schlüssel nur für privilegierte Benutzerinnen und Benutzer oder Dienste.

Die Transport- oder Kommunikationsverschlüsselung kann auf SQL Server-Verbindungen zwischen SAP-Engines und dem DBMS angewendet werden. Ebenso können Sie Verbindungen von der SAP-Präsentationsschicht (SAPGui Secure Network Connection oder SNC) oder eine HTTPS-Verbindung zu einem Web-Front-End verschlüsseln. In der Dokumentation des Anwendungsanbieters finden Sie Informationen zur Aktivierung und Verwaltung der Verschlüsselung bei der Übertragung.

Überwachung und Alarmierung bei Bedrohungen

Für die Bereitstellung und Nutzung von Lösungen zur Überwachung und Alarmierung von Bedrohungen sollten Sie zunächst die Architektur Ihres Unternehmens nutzen. Azure-Services bieten Schutz vor Bedrohungen und eine Sicherheitsansicht, die Sie in Ihren Gesamtplan für die Bereitstellung von SAP einbeziehen können. Microsoft Defender for Cloud erfüllt die Anforderungen an den Schutz vor Bedrohungen. Defender for Cloud ist in der Regel Teil eines übergreifenden Governance-Modells für eine gesamte Azure-Bereitstellung, nicht nur für SAP-Komponenten.

Weitere Informationen über Lösungen für Security Information Event Management (SIEM) und Security Orchestration Automated Response (SOAR) finden Sie unter Microsoft Sentinel-Lösungen für die SAP-Integration.

Sicherheitssoftware in SAP-VMs

SAP-Hinweis 2808515 für Linux und SAP-Hinweis 106267 für Windows beschreiben Anforderungen und bewährte Methoden, wenn Sie Virenscanner oder Sicherheitssoftware auf SAP-Servern einsetzen. Sie sollten die SAP-Empfehlungen befolgen, wenn Sie SAP-Komponenten in Azure bereitstellen.

Hochverfügbarkeit

SAP-Hochverfügbarkeit in Azure hat zwei Komponenten:

  • Hochverfügbarkeit der Azure-Infrastruktur: Hochverfügbarkeit von Azure Compute- (VMs), Netzwerk- und Speicherdiensten und wie sie die Verfügbarkeit von SAP-Anwendungen erhöhen können.

  • Hochverfügbarkeit von SAP-Anwendungen: Wie sie mit der Hochverfügbarkeit der Azure-Infrastruktur durch Dienstreparatur kombiniert werden kann. Ein Beispiel für die Verwendung von Hochverfügbarkeit in SAP-Softwarekomponenten:

    • Eine SAP (A)SCS- und SAP ERS-Instanz
    • Der Datenbankserver

Weitere Informationen über Hochverfügbarkeit für SAP in Azure finden Sie in den folgenden Artikeln:

Pacemaker auf Linux und Windows Server Failoverclustering sind die einzigen Hochverfügbarkeits-Frameworks für SAP Workloads, die von Microsoft auf Azure direkt unterstützt werden. Alle anderen Hochverfügbarkeits-Frameworks werden von Microsoft nicht unterstützt und müssen vom Anbieter in Bezug auf Design, Implementierungsdetails und Vorgänge unterstützt werden. Weitere Informationen finden Sie unter Unterstützte SAP-Szenarien in Azure.

Notfallwiederherstellung

SAP-Anwendungen gehören oft zu den geschäftskritischsten Prozessen in einem Unternehmen. Aufgrund ihrer Bedeutung und der Zeit, die benötigt wird, um nach einer unvorhergesehenen Unterbrechung wieder betriebsbereit zu sein, sollten Business Continuity & Disaster Recovery-Szenarien (BCDR) sorgfältig geplant werden.

Wie Sie diese Anforderung erfüllen können, erfahren Sie unter Überblick über die Notfallwiederherstellung und Infrastrukturrichtlinien für SAP Workloads.

Backup

Als Teil Ihrer BCDR-Strategie muss die Sicherung Ihres SAP Workloads ein integraler Bestandteil jeder geplanten Bereitstellung sein. Die Sicherungslösung muss alle Schichten eines SAP-Lösungsstapels abdecken: VM, Betriebssystem, SAP-Anwendungsschicht, DBMS-Schicht und alle gemeinsam genutzten Speicherlösungen. Die Sicherung von Azure-Diensten, die von Ihrer SAP Workload genutzt werden, und von anderen wichtigen Ressourcen wie Verschlüsselung und Zugriffsschlüssel muss ebenfalls Teil Ihres Sicherungs- und BCDR-Designs sein.

Azure Backup bietet PaaS-Lösungen für die Datensicherung:

  • VM-Konfiguration, Betriebssystem und SAP-Anwendungsebene (Größenänderung der Daten auf verwalteten Datenträgern) über Azure Backup für VM. Prüfen Sie die Unterstützungsmatrix, um sicherzustellen, dass Ihre Architektur diese Lösung verwenden kann.
  • SQL Server- und SAP HANA-Datenbankdaten und -Protokollsicherung. Dazu gehört die Unterstützung von Datenbankreplikationstechnologien wie HANA Systemreplikation oder SQL Always On sowie die Unterstützung von gepaarten Regionen.
  • Sicherung von Dateifreigaben über Azure Files. Überprüfen Sie die Unterstützung für NFS oder SMB und andere Konfigurationsdetails.

Wenn Sie Azure NetApp Files bereitstellen, stehen Ihnen alternativ Sicherungsoptionen auf Volume-Ebene zur Verfügung, einschließlich der Integration von SAP HANA und Oracle DBMS mit einer geplanten Sicherung.

Azure Backup-Lösungen bieten eine Soft-Delete-Option, um böswilliges oder versehentliches Löschen zu verhindern und Datenverlust zu vermeiden. Soft-Delete ist auch für Dateifreigaben verfügbar, die Sie mit Azure Files bereitstellen.

Es gibt Sicherungsoptionen für eine Lösung, die Sie selbst erstellen und verwalten, oder wenn Sie Software von Drittanbietern verwenden. Eine Option ist die Nutzung der Dienste mit Azure Storage, einschließlich der Verwendung von unveränderlichem Speicher für Blob-Daten. Diese selbstverwaltete Option wäre derzeit als DBMS-Sicherungsoption für einige Datenbanken wie SAP ASE oder IBM Db2 erforderlich.

Verwenden Sie die Empfehlungen in den bewährten Methoden von Azure, um sich vor Ransomware-Angriffen zu schützen und zu validieren.

Tipp

Stellen Sie sicher, dass Ihre Sicherungsstrategie den Schutz der Automatisierung der Bereitstellung, der Verschlüsselungsschlüssel für Azure-Ressourcen und der transparenten Datenbankverschlüsselung (falls verwendet) umfasst.

Regionsübergreifende Sicherung

Bestimmen Sie für jede regionsübergreifende Sicherungsanforderung das Recovery Time Objective (RTO) und Recovery Point Objective (RPO), die von der Lösung angeboten werden, und ob sie Ihrem BCDR-Design und Ihren Anforderungen entsprechen.

SAP-Migration zu Azure

Es ist nicht möglich, alle Migrationsansätze und -optionen für die große Vielfalt an SAP-Produkten, Versionsabhängigkeiten und nativen Betriebssystem- und DBMS-Technologien zu beschreiben, die es gibt. Das Projektteam Ihres Unternehmens und Vertreter Ihres Dienstanbieters sollten mehrere Techniken für eine reibungslose SAP-Migration zu Azure in Betracht ziehen.

  • Testen der Leistung während der Migration. Ein wichtiger Bestandteil der SAP-Migrationsplanung sind technische Leistungstests. Das Migrationsteam muss genügend Zeit und Verfügbarkeit für die wichtigsten Mitarbeitenden einplanen, um die Anwendung und die technischen Tests des migrierten SAP-Systems, einschließlich der angeschlossenen Schnittstellen und Anwendungen, durchzuführen. Für eine erfolgreiche SAP-Migration ist es von entscheidender Bedeutung, die Laufzeit und Genauigkeit der wichtigsten Geschäftsprozesse vor und nach der Migration in einer Testumgebung zu vergleichen. Nutzen Sie die Informationen, um die Prozesse zu optimieren, bevor Sie die Produktivumgebung migrieren.

  • Verwenden von Azure-Diensten für die SAP-Migration. Einige VM-basierte Workloads werden mit Hilfe von Diensten wie Azure Migrate oder Azure Site Recovery oder einem Tool eines Drittanbieters ohne Änderungen nach Azure migriert. Vergewissern Sie sich sorgfältig, dass die Version des Betriebssystems und die darauf ausgeführte SAP Workload vom Dienst unterstützt werden.

    Oft wird eine beliebige Workload absichtlich nicht unterstützt, weil ein Dienst die Konsistenz der Datenbank nicht garantieren kann. Wenn der DBMS-Typ vom Migrationsdienst unterstützt wird, ist die Datenbankänderungs- oder Abwanderungsrate oft zu hoch. Die meisten ausgelasteten SAP-Systeme können die Änderungsrate, die Migrationswerkzeuge ermöglichen, nicht erreichen. Es kann sein, dass Probleme erst bei der Produktionsumstellung entdeckt werden. In vielen Situationen sind einige Azure-Dienste nicht für die Migration von SAP-Systemen geeignet. Azure Site Recovery und Azure Migrate haben keine Validierung für eine groß angelegte SAP-Migration. Eine bewährte SAP-Migrationsmethode besteht darin, sich auf die DBMS-Replikation oder SAP-Migrationswerkzeuge zu verlassen.

    Eine Bereitstellung in Azure anstelle einer einfachen VM-Migration ist vorzuziehen und einfacher zu bewerkstelligen als eine Migration vor Ort. Automatisierte Bereitstellungs-Frameworks wie Azure Center for SAP solutions und Azure Deployment Automation Framework ermöglichen die schnelle Ausführung automatisierter Aufgaben. Die Migration Ihrer SAP-Landschaft auf eine neue bereitgestellte Infrastruktur unter Verwendung DBMS-nativer Replikationstechnologien wie HANA-Systemreplikation, DBMS-Sicherungs- und Wiederherstellungstools oder SAP-Migrationstools erfordert fundierte technische Kenntnisse Ihres SAP-Systems.

  • Infrastruktur-Hochskalierung. Bei einer SAP-Migration können Sie mit mehr Infrastrukturkapazität die Bereitstellung beschleunigen. Das Projektteam sollte in Erwägung ziehen, die Größe der VM zu erhöhen, um mehr CPU und Arbeitsspeicher bereitzustellen. Das Team sollte auch die Skalierung des VM-Gesamtspeichers und des Netzwerkdurchsatzes in Betracht ziehen. Ebenso sollten Sie auf VM-Ebene Speicherelemente wie einzelne Datenträger in Betracht ziehen, um den Durchsatz mit On-Demand-Bursting und Leistungsstufen für SSD Premium v1 zu erhöhen. Erhöhen Sie die IOPS- und Durchsatzwerte, wenn Sie SSD Premium v2 verwenden, über die konfigurierten Werte hinaus. Vergrößern Sie NFS- und SMB-Dateifreigaben, um die Leistungsbeschränkungen zu erhöhen. Beachten Sie, dass verwaltete Azure-Datenträger nicht verkleinert werden können und dass die Verringerung der Größe, der Leistungsebenen und der Durchsatz-KPIs unterschiedliche Abkühlungszeiten haben kann.

  • Optimieren von Netzwerk- und Datenkopien. Die Migration eines SAP-Systems nach Azure ist immer mit dem Verschieben einer großen Datenmenge verbunden. Bei den Daten kann es sich um Datenbank- und Dateisicherungen oder -replikationen, eine Datenübertragung von Anwendung zu Anwendung oder einen SAP-Migrationsexport handeln. Je nachdem, welchen Migrationsprozess Sie verwenden, müssen Sie den richtigen Netzwerkpfad für die Übertragung der Daten wählen. Für viele Vorgänge der Datenverlagerung ist die Nutzung des Internets anstelle eines privaten Netzwerks der schnellste Weg, um Daten sicher auf Azure-Speicher zu kopieren.

    Die Verwendung von ExpressRoute oder eines VPN kann zu Engpässen führen:

    • Die Migrationsdaten verbrauchen zu viel Bandbreite und stören den Benutzerzugriff auf Workloads, die in Azure ausgeführt werden.
    • Lokale Netzwerkengpässe, wie z. B. eine Firewall oder Grenzwerte für den Durchsatz, werden oft erst während der Migration entdeckt.

    Unabhängig von der verwendeten Netzwerkverbindung ist die Leistung des Single-Stream-Netzwerks für einen Datenumzug oft gering. Um die Geschwindigkeit der Datenübertragung über mehrere TCP-Streams zu erhöhen, verwenden Sie Tools, die mehrere Streams unterstützen. Wenden Sie Optimierungstechniken an, die in der SAP-Dokumentation und in vielen Blogbeiträgen zu diesem Thema beschrieben sind.

Tipp

In der Planungsphase ist es wichtig, alle dedizierten Migrationsnetzwerke zu berücksichtigen, die Sie für große Datenübertragungen zu Azure verwenden werden. Beispiele hierfür sind Sicherungen oder Datenbankreplikationen oder die Verwendung eines öffentlichen Endpunkts für Datenübertragungen auf Azure Storage. Die Auswirkungen der Migration auf die Netzwerkpfade für Ihre Benutzerkonten und Anwendungen sollten erwartet und gemildert werden. Berücksichtigen Sie bei Ihrer Netzwerkplanung alle Phasen der Migration und die Kosten für eine teilweise produktive Workload in Azure während der Migration.

Support und Betrieb für SAP

Vor und während der Bereitstellung von SAP in Azure sind noch einige andere Bereiche zu beachten.

Azure-VM-Erweiterung für SAP

Azure Monitoring Extension, Enhanced Monitoring und Azure Extension for SAP beziehen sich alle auf eine VM-Erweiterung, die Sie bereitstellen müssen, um dem SAP-Host-Agent einige grundlegende Daten über die Azure-Infrastruktur zur Verfügung zu stellen. In den SAP-Hinweisen wird die Erweiterung möglicherweise als Überwachungserweiterung oder Erweiterte Überwachung bezeichnet. In Azure heißt sie Azure-Erweiterung for SAP. Für Supportzwecke muss die Erweiterung auf allen Azure-VMs installiert werden, auf denen eine SAP Workload ausgeführt wird. Weitere Informationen finden Sie unter Azure-VM-Erweiterung für SAP.

SAProuter für SAP-Support

Der Betrieb einer SAP-Landschaft in Azure erfordert eine Konnektivität zu und von SAP für Supportzwecke. In der Regel erfolgt die Konnektivität in Form einer SAProuter-Verbindung, entweder über einen verschlüsselten Netzwerkkanal über das Internet oder über eine private VPN-Verbindung zu SAP. Bewährte Methoden und eine Beispielimplementierung von SAProuter in Azure finden Sie in Ihrem Architekturszenario unter Eingehende und ausgehende Internetverbindungen für SAP auf Azure.

Nächste Schritte