Bearbeiten

Freigeben über

Architektur der SAP-Landschaft

Azure Virtual Machines
Azure Virtual Network
Azure Files
Azure Load Balancer

Dieser Artikel enthält bewährte Methoden für das Entwerfen einer umfassenden SAP-Landschaft in Azure. Die SAP-Landschaft umfasst mehrere SAP-Systeme in Hub-, Produktions-, Nicht-Produktions- und Notfallwiederherstellungsumgebungen. Wir geben Empfehlungen, die sich auf den Netzwerkentwurf und nicht auf bestimmte SAP-Systeme konzentrieren. Durch Bereitstellung unserer Empfehlungen möchten wir die Erstellung einer sicheren, leistungsfähigen und resilienten SAP-Landschaft ermöglichen.

Architektur

Diagramm: Beispiel für die gesamte SAP-Landschaft in Azure.

Laden Sie eine Visio-Datei mit der Architektur herunter.

Workflow

  1. Lokales Netzwerk: ExpressRoute-Verbindung vom lokalen Netzwerk zu verbundenen Azure-Regionen.
  2. Azure-Abonnement für regionale Hubs: Azure-Abonnement mit zentralen Diensten für das gesamte Unternehmen, nicht nur für SAP. Das Hubabonnement bietet zentrale Dienste und Konnektivität durch Peering zu virtuellen Speichennetzwerken, die SAP-Workloads enthalten.
  3. Virtuelles Hub-Netzwerk: Ein virtueller Netzwerk-Spoke für den zentralen Hub in der primären Region (Region A).
  4. virtuellen Hubnetzwerk in der Notfallwiederherstellung (DR)-Region: Ein virtuelles Netzwerk sprach für den zentralen Hub in der Notfallwiederherstellungsregion. Es spiegelt den Subnetzentwurf des virtuellen Produktionsnetzwerks in der primären Region.
  5. Azure-Abonnement für SAP (Nicht-Produktion): Ein Azure-Abonnement für alle Nicht-Produktiven SAP-Workloads. Es umfasst Präproduktions-, Qualitätssicherungs-, Entwicklungs- und Sandboxumgebungen.
  6. Virtuelle Spoke-Netzwerke für SAP (Nicht-Produktion): Separate virtuelle Netzwerke für SAP-Nicht-Produktionsworkloads in der primären Region. Jede SAP-Umgebung verfügt über ein eigenes virtuelles Netzwerk und Subnetze.
  7. Azure-Abonnement für SAP (Produktion): Ein Azure-Abonnement für alle produktiven SAP-Workloads.
  8. Virtuelles Spoke-Netzwerk für SAP (Produktion): Ein virtuelles Netzwerk für die SAP-Produktionsumgebung mit mehreren Subnetzen. Dieses virtuelle Netzwerk befindet sich in der primären Region.
  9. Virtuelles Spoke-Netzwerk für die Notfallwiederherstellung für SAP (Produktion): Ein virtuelles Netzwerk für die SAP-Produktionsumgebung in der sekundären Notfallwiederherstellungsregion. Es spiegelt den Subnetzentwurf des virtuellen Produktionsnetzwerks in der primären Region.
  10. Azure-Dienste: Eine Auswahl von Azure-Diensten, die Sie mit der SAP-Landschaft verbinden können.
  11. SAP Business Technology Platform (BTP): Die SAP-Umgebung greift über Azure Private Link auf die SAP Business Technology Platform zu.

Azure-Abonnements

Es wird empfohlen, einen Hub-Spoke-Netzwerkentwurf zu verwenden. Bei einem Hub-Spoke-Entwurf benötigen Sie mindestens drei Abonnements zum Trennen der SAP-Umgebungen. Sie benötigen ein Abonnement für die (1) regionalen virtuellen Hub-Netzwerke, die (2) virtuellen Nicht-Produktionsnetzwerke und die (3) virtuellen Produktionsnetzwerke. Abonnements ermöglichen Abrechnungs-, Richtlinien- und Sicherheitsgrenzen. Es gibt keine konkrete Anzahl von Abonnements. Die Anzahl der verwendeten Abonnements hängt von den jeweiligen Abrechnungs-, Richtlinien- und Sicherheitsanforderungen ab. Im Allgemeinen sollte die Verwendung zu vieler Abonnements vermieden werden. Zu viele Abonnements können unnötigen Verwaltungsaufwand bewirken und die Netzwerkkomplexität erhöhen. Sie brauchen beispielsweise nicht für jedes SAP-System ein Abonnement. In unserer Architektur werden drei Abonnements verwendet:

  • Regionale Hubs: Ein Azure Virtual Hub-Abonnement, in dem sich das virtuelle Hub-Netzwerk für die primäre und sekundäre Region befindet. Dieses Abonnement ist für alle zentralen Dienste und nicht nur für SAP vorgesehen.

  • SAP (Nicht-Produktion): Ein Azure-Abonnement für SAP (Nicht-Produktion), in dem sich Nicht-Produktionssysteme wie Sandbox-, Entwicklungs-, Qualitätssicherungs- oder Präproduktionssysteme befinden.

  • SAP (Produktion): Ein Azure-Abonnement für SAP (Produktion), in dem die Produktions- und Notfallwiederherstellungssysteme konfiguriert sind.

Weitere Informationen finden Sie unter:

Netzwerkentwurf.

Als Netzwerkentwurf für eine SAP-Landschaft wird eine Hub-Spoke-Topologie empfohlen. In dieser Topologie fungiert das virtuelle Hub-Netzwerk für die Produktion als zentraler Konnektivitätspunkt. Es ist mit dem lokalen Netzwerk und den verschiedenen virtuellen Spoke-Netzwerken verbunden und ermöglicht Benutzern sowie Anwendungen Zugriff auf die SAP-Workload. Innerhalb dieser Hub-Spoke-Topologie gelten unsererseits folgende Empfehlungen für den SAP-Netzwerkentwurf.

Verwenden Sie ExpressRoute für die Verbindung zur lokalen Umgebung. Für SAP-Workloads wird die Verwendung einer ExpressRoute-Verbindung vom lokalen Netzwerk zum virtuellen Hub-Netzwerk und zum virtuellen Hub-Netzwerk für die Notfallwiederherstellung empfohlen. Sie können die Azure Virtual WAN-Topologie verwenden, wenn Sie über globale Standorte verfügen. Erwägen Sie das Einrichten eines Site-to-Site-VPN (S2S) als Backup für Azure ExpressRoute oder erforderliche Drittanbieterrouten.

Weitere Informationen finden Sie unter:

Verwenden Sie ein virtuelles Netzwerk pro Umgebung. Es wird empfohlen, ein virtuelles Netzwerk pro Umgebung (SAP-Bereitstellungsebene) zu verwenden. In der Architektur wird jeweils ein eigenständiges virtuelles Netzwerk für Produktion, Entwicklung, Qualitätssicherung und Sandbox verwendet. Dieser Netzwerkentwurf eignet sich ideal für umfangreiche Unternehmensarchitekturen.

Verwenden Sie eine zentrale Firewall. Der gesamte Netzwerkdatenverkehr zu den virtuellen Spoke-Netzwerken, einschließlich RFC-Verbindungen (Remote Function Call), sollte über eine zentrale Firewall im virtuellen Hub-Netzwerk geleitet werden. Die Netzwerkkommunikation zwischen den virtuellen Spoke-Netzwerken (Spoke-to-Spoke-Kommunikation) erfolgt über die Firewall des virtuellen Hub-Netzwerks im Azure Firewall-Subnetz des virtuellen Hub-Netzwerks. Ebenso läuft auch die Netzwerkkommunikation zwischen den virtuellen Spoke-Netzwerken und dem lokalen Netzwerk durch die Firewall des virtuellen Hub-Netzwerks. Wir haben das Peering virtueller Netzwerke verwendet, um die verschiedenen virtuellen Spoke-Netzwerke mit dem virtuellen Hub-Netzwerk zu verbinden. Die gesamte Kommunikation zwischen den virtuellen Spoke-Netzwerken durchläuft die Firewall des virtuellen Hub-Netzwerks. Sie können auch ein virtuelles Netzwerkgerät anstelle einer Firewall verwenden. Weitere Informationen finden Sie auf der Seite für virtuelle Netzwerkgeräte.

Netzwerkdatenverkehr, der in einem virtuellen Netzwerk verbleibt, sollte nicht über eine Firewall laufen. Verwenden Sie beispielsweise keine Firewall zwischen dem SAP-Anwendungssubnetz und dem SAP-Datenbanksubnetz. Es wird nicht unterstützt, eine Firewall oder virtuelle Netzwerkgeräte (VIRTUAL Appliances, NVAs) zwischen der SAP-Anwendung und der DBMS-Ebene (Database Management System) von SAP-Systemen zu platzieren, die den SAP-Kernel ausführen. Dies wirkt sich negativ auf die Netzwerklatenz für alle Datenbankzugriffe aus und wirkt sich stark auf die SAP-Leistung aus.

Vermeiden Sie das Peering virtueller Spoke-Netzwerke. Das Peering virtueller Netzwerke zwischen den virtuellen Spoke-Netzwerken sollte nach Möglichkeit vermieden werden. Das Peering virtueller Spoke-to-Spoke-Netzwerke ermöglicht es der Spoke-to-Spoke-Kommunikation, die Firewall des virtuellen Hub-Netzwerks zu umgehen. Sie sollten das Peering virtueller Spoke-to-Spoke-Netzwerke nur konfigurieren, wenn hohe Bandbreiten erforderlich sind, z. B. bei der Datenbankreplikation zwischen SAP-Umgebungen. Der gesamte andere Netzwerkdatenverkehr sollte über das virtuelle Hub-Netzwerk und die Firewall laufen. Weitere Informationen finden Sie unter Eingehende und ausgehende Internetverbindungen für SAP in Azure.

Subnetze

Es hat sich bewährt, die einzelnen SAP-Umgebungen (Produktion, Präproduktion, Entwicklung, Sandbox) in Subnetze aufzuteilen und Subnetze zum Gruppieren ähnlicher Dienste zu verwenden. Für die Erstellung von Subnetzen in einer SAP-Landschaft gelten unsererseits folgende Empfehlungen.

Anzahl von Subnetzen

Das virtuelle Produktionsnetzwerk in der Architektur umfasst fünf Subnetze. Dieser Entwurf ist ideal für umfangreiche Unternehmenslösungen. Die Anzahl der Subnetze kann kleiner oder größer sein. Die Anzahl der Subnetze im virtuellen Netzwerk hängt von der jeweiligen Anzahl der Ressourcen im virtuellen Netzwerk ab.

Subnetzdimensionierung

Die Subnetze müssen über einen ausreichenden Netzwerkadressraum verfügen. Wenn Sie virtuelle SAP-Hostnamen verwenden, benötigen Sie einen größeren Adressraum in Ihren SAP-Subnetzen. Eine SAP-Instanz benötigt oftmals 2 bis 3 IP-Adressen; dazu gehört eine IP-Adresse für den Hostnamen des virtuellen Computers. Andere Azure-Dienste benötigen möglicherweise ein eigenes dediziertes Subnetz, wenn sie in den virtuellen SAP-Workloadnetzwerken bereitgestellt werden.

Anwendungssubnetz

Das Anwendungssubnetz enthält virtuelle Computer, auf denen SAP-Anwendungsserver, SAP Central Services- (ASCS), SAP Enqueue Replication Services- (ERS) und SAP Web Dispatcher-Instanzen ausgeführt werden. Das Subnetz enthält auch einen privaten Endpunkt zu Azure Files. Im Diagramm wurden die virtuellen Computer nach Rolle gruppiert. Es wird empfohlen, Skalierungssätze für virtuelle Computer mit flexibler Orchestrierung in Kombination mit Verfügbarkeitszonen für eine robuste Bereitstellung zu verwenden. Weitere Informationen finden Sie unter Nächste Schritte.

Datenbanksubnetz

Das Datenbanksubnetz enthält virtuelle Computer, auf denen Datenbanken ausgeführt werden. Im Diagramm stellt ein Paar von virtuellen Computern mit synchroner Replikation alle virtuellen Datenbankcomputer einer SAP-Umgebung dar.

Umkreissubnetze

Umkreissubnetze sind mit dem Internet verbunden und umfassen ein SAP-Umkreissubnetz sowie ein Application Gateway-Subnetz. Für den Entwurf dieser beiden Subnetze gelten unsererseits folgende Empfehlungen.

SAP-Umkreissubnetz: Das SAP-Umkreissubnetz ist ein Umkreisnetzwerk, das internetorientierte Anwendungen wie SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent und Application Gateway enthält. Diese Dienste weisen Abhängigkeiten von SAP-Systemen auf, die ein SAP-Team bereitstellen, verwalten und konfigurieren sollte. Die Dienste im SAP-Umkreissubnetz sollten nicht von einem zentralen IT-Team verwaltet werden. Aus diesem Grund sollten Sie diese Dienste im virtuellen SAP-Spoke-Netzwerk und nicht im virtuellen Hub-Netzwerk platzieren. Das Architekturdiagramm enthält nur ein SAP-Umkreisnetzwerk in der Produktionsumgebung. Ein SAP-Umkreissubnetz in den virtuellen Netzwerken, die nicht zur Produktion gehören, ist nicht vorhanden. Die Workloads im SAP-Abonnement für Nicht-Produktionssysteme verwenden die Dienste im SAP-Umkreissubnetz.

Sie können ein separates SAP-Umkreissubnetz im Nicht-Produktionsabonnement erstellen. Diese Vorgehensweise wird nur für kritische Workloads oder Workloads empfohlen, die sich häufig ändern. Ein dediziertes SAP-Umkreisnetzwerk für Nicht-Produktionssysteme ist für Tests und die Bereitstellung neuer Features hilfreich. Weniger kritische Anwendungen oder Anwendungen, die im Laufe der Zeit kaum geändert werden, benötigen kein separates SAP-Umkreissubnetz für Nicht-Produktionssysteme.

Application Gateway-Subnetz: Für Azure Application Gateway ist ein eigenes Subnetz erforderlich. Damit können Sie Datenverkehr aus dem Internet zuzulassen, den SAP-Dienste, z. B. SAP Fiori, verwenden können. Bei der empfohlenen Architektur wird Azure Application Gateway zusammen mit der öffentlichen IP-Adresse des Front-Ends im virtuellen Hubnetzwerk platziert. Ein Azure Application Gateway erfordert mindestens ein /29-Subnetz. Wir empfehlen mindestens ein /27-Subnetz. Sie können nicht beide Application Gateway-Versionen (v1 und v2) in demselben Subnetz verwenden. Weitere Informationen finden Sie im Artikel zu Azure Application Gateway-Subnetzen.

Platzieren Sie Umkreissubnetze in einem separaten virtuellen Netzwerk, um die Sicherheit zu erhöhen: Sie können das SAP-Umkreissubnetz und das Application Gateway-Subnetz in einem separaten virtuellen Netzwerk im SAP-Produktionsabonnement platzieren, um die Sicherheit zu erhöhen. Das virtuelle SAP-UmkreisSpoke-Netzwerk wird über Peering mit dem virtuellen Hub-Netzwerk verbunden, und der gesamte Netzwerkdatenverkehr zu öffentlichen Netzwerken läuft durch das virtuelle Umkreisnetzwerk. Dieser alternative Ansatz zeigt Azure Application Gateway mit seiner öffentlichen IP-Adresse für eingehende Verbindungen in einem virtuellen Spoke-Netzwerk, das ausschließlich für die Nutzung durch SAP vorgesehen ist.

Diagramm: Netzwerkfluss zwischen virtuellen Netzwerkspokes über das virtuelle Hub-Netzwerk.

Laden Sie eine Visio-Datei herunter, die diese alternative Architektur enthält.

Dieser Netzwerkentwurf ermöglicht eine bessere Reaktion auf Vorfälle und eine differenzierte Netzwerkzugriffssteuerung. Allerdings werden auch Verwaltungskomplexität, Netzwerklatenz und Kosten der Bereitstellung größer. Im Folgenden werden die einzelnen Punkte eingehender erörtert.

Bessere Reaktion auf Vorfälle: Das virtuelle SAP-UmkreisSpoke-Netzwerk ermöglicht eine schnelle Isolation von kompromittierten Diensten, wenn eine Sicherheitsverletzung erkannt wird. Sie können das Peering virtueller Netzwerke vom virtuellen SAP-UmkreisSpoke-Netzwerk zum Hub entfernen, um die Workloads im SAP-Umkreisnetzwerk und die Anwendungen des virtuellen SAP-Anwendungsnetzwerks sofort vom Internet zu isolieren. Sie sollten nicht auf Änderungen von Netzwerksicherheitsgruppenregeln (NSG) für die Reaktion auf Vorfälle setzen. Das Ändern oder Entfernen einer NSG-Regel wirkt sich nur auf neue Verbindungen aus, trennt aber keine bestehenden böswilligen Verbindungen.

Differenzierte Netzwerkzugriffssteuerung: Das virtuelle SAP-Umkreisnetzwerk ermöglicht eine strengere Netzwerkzugriffssteuerung zum und vom virtuellen SAP-Spoke-Netzwerk für die Produktion.

Höhere Komplexität, Latenz und Kosten: Die Architektur erhöht die Komplexität der Verwaltung, die Kosten und die Latenz. Die internetgebundene Kommunikation aus dem virtuellen SAP-Produktionsnetzwerk umfasst zwei Peerings, eins zum virtuellen Hub-Netzwerk und wiederum zum virtuellen SAP-Umkreisnetzwerk, das mit dem Internet verbunden ist. Die Firewall im virtuellen Hub-Netzwerk wirkt sich am meisten auf die Latenz aus. Es wird empfohlen, die Latenz zu messen, um festzustellen, ob sie vom jeweiligen Anwendungsfall unterstützt werden kann.

Weitere Informationen finden Sie im Artikel zu bewährten Methode für Umkreisnetzwerke.

Azure NetApp Files-Subnetz

Wenn Sie NetApp Files verwenden, sollten Sie ein delegiertes Subnetz vorsehen, um NFS-Dateifreigaben (Network File System) oder SMB-Freigaben (Server Message Block) für verschiedene SAP-Szenarien in Azure zu ermöglichen. Ein /24-Subnetz ist die Standardgröße für ein NetApp Files-Subnetz. Sie können die Größe jedoch an die jeweiligen Anforderungen anpassen. Ermitteln Sie die richtige Dimensionierung anhand Ihrer Anforderungen. Weitere Informationen finden Sie im Artikel zum Delegieren eines Subnetzes.

Subnetzsicherheit

Die Verwendung von Subnetzen zum Gruppieren von SAP-Ressourcen mit den gleichen erforderlichen Sicherheitsregeln vereinfacht die Verwaltung der Sicherheit.

Netzwerksicherheitsgruppen (NSG): Subnetze ermöglichen die Implementierung von Netzwerksicherheitsgruppen auf Subnetzebene. Zum Gruppieren von Ressourcen, für die unterschiedliche Sicherheitsregeln erforderlich sind, im selben Subnetz sind Netzwerksicherheitsgruppen auf Subnetzebene und Netzwerkschnittstellenebene erforderlich. Bei dieser zweistufigen Einrichtung können Sicherheitsregeln leicht widersprüchlich sein und unerwartete Kommunikationsprobleme verursachen, die schwer zu beheben sind. NSG-Regeln wirken sich auch auf den Datenverkehr im Subnetz aus. Weitere Informationen zu Netzwerksicherheitsgruppen finden Sie unter Netzwerksicherheitsgruppen.

Anwendungssicherheitsgruppen: Es wird empfohlen, Anwendungssicherheitsgruppen zu verwenden, um Netzwerkschnittstellen virtueller Computer zu gruppieren und in den Netzwerksicherheitsgruppenregeln auf die Anwendungssicherheitsgruppen zu verweisen. Diese Konfiguration vereinfacht die Erstellung und Verwaltung von Regeln für SAP-Bereitstellungen. Jede Netzwerkschnittstelle kann zu mehreren Anwendungssicherheitsgruppen mit unterschiedlichen Netzwerksicherheitsgruppenregeln gehören. Weitere Informationen finden Sie unter Anwendungssicherheitsgruppen.

Es wird empfohlen, Azure Private Link zu verwenden, um die Sicherheit der Netzwerkkommunikation zu verbessern. Azure Private Link verwendet private Endpunkte mit privaten IP-Adressen für die Kommunikation mit Azure-Diensten. Bei Verwendung von Azure Privat erfolgt keine Netzwerkkommunikation über das Internet an öffentliche Endpunkte. Weitere Informationen finden Sie in der Übersicht über private Endpunkte für Azure-Dienste.

Verwenden Sie private Endpunkten im Anwendungssubnetz. Es wird empfohlen, private Endpunkte zu verwenden, um das Anwendungssubnetz mit unterstützten Azure-Diensten zu verbinden. In der Architektur gibt es einen privaten Endpunkt für Azure Files im Anwendungssubnetz jedes virtuellen Netzwerks. Sie können dieses Konzept auf alle unterstützten Azure-Dienste erweitern.

Verwenden Sie Azure Private Link für SAP Business Technology Platform (BTP). Azure Private Link für SAP Business Technology Platform (BTP) ist jetzt allgemein verfügbar. SAP Private Link Service unterstützt Verbindungen von SAP BTP, der Cloud Foundry Runtime und anderen Diensten. Beispielszenarien sind SAP S/4HANA oder SAP ERP, die auf dem virtuellen Computer ausgeführt werden. Sie können eine Verbindung zu nativen Azure-Diensten wie Azure Database for MariaDB und Azure Database for MySQL herstellen.

Die Architektur stellt eine SAP Private Link Service-Verbindung von SAP BTP-Umgebungen dar. SAP Private Link Service stellt eine private Verbindung zwischen bestimmten SAP BTP-Diensten und bestimmten Diensten in den einzelnen Netzwerken als Dienstanbieterkonten her. Eine private Verbindung ermöglicht BTP-Diensten den Zugriff auf die SAP-Umgebung über private Netzwerkverbindungen. Dadurch wird die Sicherheit verbessert, da die Kommunikation nicht über das öffentliche Internet erfolgt.

Weitere Informationen finden Sie unter:

NFS- und SMB-Dateifreigaben

SAP-Systeme sind häufig von NFS-Volumes oder SMB-Freigaben abhängig. Diese Dateifreigaben verschieben Dateien zwischen virtuellen Computern oder fungieren als Dateischnittstelle zu anderen Anwendungen. Es wird empfohlen, native Azure-Dienste wie Azure Premium Files und Azure NetApp Files als NFS-(Network File System) und SMB-Dateifreigaben (Server Message Block) zu verwenden. Azure-Dienste verfügen insgesamt über bessere Verfügbarkeit, Resilienz und Vereinbarungen zum Servicelevel (SLA) als betriebssystembasierte Tools.

Weitere Informationen finden Sie unter:

Beim Entwerfen der SAP-Lösungsarchitektur müssen Sie die einzelnen Dateifreigabevolumes ordnungsgemäß dimensionieren und die Verbindungen der SAP-Systemdateifreigaben kennen. Berücksichtigen Sie bei der Planung die gewünschte Skalierbarkeit und Leistung des Azure-Diensts. Die folgende Tabelle enthält eine Übersicht über übliche SAP-Dateifreigaben mit einer kurzen Beschreibung und der empfohlenen Verwendung in einer umfassenden SAP-Umgebung.

Dateifreigabename Verwendung Empfehlung
sapmnt Verteilte SAP-System-, Profil- und globale Verzeichnisse Dedizierte Freigabe für jedes SAP-System, keine Wiederverwendung
cluster Hochverfügbare Freigaben für ASCS, ERS und Datenbank gemäß Entwurf Dedizierte Freigabe für jedes SAP-System, keine Wiederverwendung
saptrans SAP-Transportverzeichnis Eine Freigabe für eine oder wenige SAP-Landschaften (ERP, Business Warehouse)
interface Dateiaustausch mit Nicht-SAP-Anwendungen Kundenspezifische Anforderungen, separate Dateifreigaben pro Umgebung (Produktion, Nicht-Produktion)

Sie können saptrans nur zwischen verschiedenen SAP-Umgebungen freigeben. Daher sollten Sie die Platzierung sorgfältig prüfen. Vermeiden Sie aus Skalierbarkeits- und Leistungsgründen, zu viele SAP-Systeme in einer saptrans-Freigabe zu konsolidieren.

Die unternehmensspezifischen Sicherheitsrichtlinien bestimmen die Architektur und die Trennung von Volumes zwischen Umgebungen. Ein Transportverzeichnis mit Trennung pro Umgebung oder Ebene benötigt RFC-Kommunikation zwischen SAP-Umgebungen, um SAP-Transportgruppen oder -Transportdomänenlinks zu ermöglichen. Weitere Informationen finden Sie unter:

Datendienste

Die Architektur umfasst Azure-Datendienste, mit denen Sie die SAP-Datenplattform erweitern und verbessern können. Um geschäftliche Erkenntnisse zu gewinnen, wird empfohlen, Dienste wie Azure Synapse Analytics, Azure Data Factory und Azure Data Lake Storage zu verwenden. Mit diesen Datendiensten können Sie SAP-Daten und Nicht-SAP-Daten analysieren und visualisieren.

Für viele Datenintegrationsszenarien ist eine Integration Runtime erforderlich. Die Anzure Integration Runtime ist die Computeinfrastruktur, die Azure Data Factory und Azure Synapse Analytics-Pipelines verwenden, um Datenintegrationsfunktionen bereitzustellen. Es wird empfohlen, die Runtime-VMs für diese Dienste getrennt für jede Umgebung bereitzustellen. Weitere Informationen finden Sie unter:

Gemeinsame Dienste

SAP-Lösungen basieren auf gemeinsamen Diensten. Lastenausgleich und Anwendungsgateways sind Beispiele für Dienste, die von mehreren SAP-Systemen verwendet werden. Nicht die Architektur, sondern die organisatorischen Anforderungen sollten bestimmen, wie Sie die gemeinsamen Dienste realisieren. Nachstehend finden Sie allgemeine Richtlinien, die Sie befolgen sollten.

Load Balancer: Wir empfehlen einen Load Balancer pro SAP-System. Diese Konfiguration trägt zur Minimierung der Komplexität bei. Sie sollten zu viele Pools und Regeln für einen einzelnen Load Balancer vermeiden. Diese Konfiguration stellt außerdem sicher, dass Benennung und Platzierung auf das SAP-System und die Ressourcengruppe abgestimmt ist. Jedes SAP-System mit einer Clusterarchitektur für Hochverfügbarkeit sollte über mindestens einen Load Balancer verfügen. Die Architektur verwendet einen Load Balancer für die virtuellen ASCS-Computer und einen zweiten Load Balancer für die virtuellen Datenbankcomputer. Einige Datenbanken erfordern möglicherweise keine Load Balancer für eine Bereitstellung mit Hochverfügbarkeit (im Gegensatz zu SAP HANA). Weitere Informationen finden Sie in der datenbankspezifischen Dokumentation.

Application Gateway: Wir empfehlen mindestens ein Anwendungsgateway pro SAP-Umgebung (Produktion, Nicht-Produktion und Sandbox), sofern Komplexität und Anzahl der vernetzten Systeme nicht zu groß werden. Sie können ein Anwendungsgateway für mehrere SAP-Systeme verwenden, um die Komplexität zu reduzieren, da nicht alle SAP-Systeme in der Umgebung eingehenden Zugriff über das Internet erfordern. Ein einzelnes Anwendungsgateway kann mehrere Web Dispatcher-Ports für ein einzelnes SAP S/4HANA-System bereitstellen oder von verschiedenen SAP-Systemen verwendet werden.

Virtuelle SAP Web Dispatcher-Computer: Die Architektur umfasst einen Pool mit mindestens zwei SAP Web Dispatcher-VMs. Es wird empfohlen, virtuelle SAP Web Dispatcher-Computer nicht für verschiedene SAP-Systemen zu verwenden. Wenn sie getrennt bleiben, können Sie die virtuellen Web Dispatcher-Computer so dimensionieren, dass die Anforderungen des jeweiligen SAP-Systems erfüllt werden. Für kleinere SAP-Lösungen wird empfohlen, die Web Dispatcher-Dienste in die ASCS-Instanz einzubetten.

SAP-Dienste: SAP-Dienste wie SAProuter, Cloud Connector und Analytics Cloud Agent werden je nach Anwendungsanforderungen entweder zentral oder getrennt bereitgestellt. Aufgrund der unterschiedlichen Kundenanforderungen gibt es keine Empfehlung zur Verwendung von mehreren SAP-Systemen. Die wichtigste Entscheidung, die getroffen werden muss, wird im Netzwerkabschnitt erwähnt: ob und wann ein SAP-Umkreissubnetz für Nicht-Produktionsumgebungen verwendet werden soll. Andernfalls werden die Dienste des SAP-Umkreisnetzwerks bei nur einem Produktionsumkreissubnetz für SAP von der gesamten SAP-Landschaft genutzt.

Notfallwiederherstellung

Die Notfallwiederherstellung sorgt für die erforderliche Geschäftskontinuität, falls die primäre Azure-Region nicht verfügbar ist oder kompromittiert wurde. Aus Gesamtsicht der SAP-Landschaft gelten unsererseits folgende Empfehlungen für die Notfallwiederherstellung (siehe auch Diagramm).

Verwendung verschiedener IP-Adressbereiche: Virtuelle Netzwerke umspannen nur eine einzelne Azure-Region. Alle Notfallwiederherstellungslösungen sollten eine andere Region verwenden. Sie müssen ein anderes virtuelles Netzwerk in der sekundären Region erstellen. Das virtuelle Netzwerk in der Notfallwiederherstellungsumgebung benötigt einen anderen IP-Adressbereich, um mit der Technologie der jeweiligen Datenbank eine Datenbanksynchronisierung zu ermöglichen.

Zentrale Dienste und Konnektivität mit lokalen Diensten: In der Notfallwiederherstellungsregion muss Konnektivität mit lokalen und wichtigen zentralen Diensten (DNS oder Firewalls) verfügbar sein. Verfügbarkeit und Änderungskonfiguration der zentralen IT-Dienste müssen Teil Ihres Notfallwiederherstellungsplans sein. Zentrale IT-Dienste sind wichtige Komponenten für eine funktionierende SAP-Umgebung.

Verwendung von Azure Site Recovery: Azure Site Recovery repliziert und schützt verwaltete Datenträger und VM-Konfigurationen für Anwendungsserver in der Notfallwiederherstellungsregion.

Sicherstellen der Verfügbarkeit von Dateifreigaben: SAP hängt von der Verfügbarkeit wichtiger Dateifreigaben ab. Um Daten auf diesen Dateifreigaben mit minimalem Datenverlust in einem Notfallwiederherstellungsszenario bereitzustellen, ist eine Sicherung oder fortlaufende Replikation der Dateifreigabe erforderlich.

Datenbankreplikation: Azure Site Recovery kann SAP-Datenbankserver aufgrund der hohen Änderungsrate und fehlender Datenbankunterstützung durch den Dienst nicht schützen. Sie müssen eine fortlaufende und asynchrone Datenbankreplikation zur Notfallwiederherstellungsregion konfigurieren.

Weitere Informationen finden Sie unter Übersicht über die Notfallwiederherstellung und Leitlinien für die Infrastruktur für SAP-Workloads.

Kleinere SAP-Architektur

Bei kleineren SAP-Lösungen kann es vorteilhaft sein, den Netzwerkentwurf zu vereinfachen. Die virtuellen Netzwerke der einzelnen SAP-Umgebung wären dann Subnetze in einem solchen kombinierten virtuellen Netzwerks. Jede Vereinfachung des Netzwerk- und Abonnemententwurfs kann sich auf die Sicherheit auswirken. Sie sollten das Netzwerkrouting, den Zugriff auf und aus öffentlichen Netzwerken, den Zugriff auf gemeinsame Dienste (Dateifreigaben) und den Zugriff auf andere Azure-Dienste neu bewerten. Nachstehend finden Sie einige Möglichkeiten zum Verkleinern der Architektur, um die Anforderungen der Organisation besser zu erfüllen.

Kombinieren Sie SAP-Anwendungs- und Datenbanksubnetz zu einem Subnetz. Sie können Anwendungs- und Datenbanksubnetze kombinieren, um ein großes SAP-Netzwerk zu erstellen. Dieser Netzwerkentwurf entspricht vielen lokalen SAP-Netzwerken. Die Kombination dieser beiden Subnetze erfordert eine höhere Aufmerksamkeit in Bezug auf Subnetzsicherheit und Netzwerksicherheitsgruppenregeln. Anwendungssicherheitsgruppen sind wichtig, wenn ein einzelnes Subnetz für SAP-Anwendungs- und Datenbanksubnetze verwendet wird.

Kombinieren Sie SAP-Umkreissubnetz und Anwendungssubnetz. Sie können SAP-Umkreissubnetz und Anwendungssubnetz kombinieren. Netzwerksicherheitsgruppenregeln und die Verwendung von Anwendungssicherheitsgruppen bedürfen erhöhter Aufmerksamkeit. Wir empfehlen eine derartige Vereinfachung nur für kleine SAP-Systeme.

Kombinieren Sie virtuelle SAP-Spoke-Netzwerke mehrerer SAP-Umgebungen. Die Architektur verwendet unterschiedliche virtuelle Netzwerke für jede SAP-Umgebung (Hub, Produktion, Nicht-Produktion und Notfallwiederherstellung). Je nach Größe der SAP-Landschaft können Sie die virtuellen SAP-Spoke-Netzwerke zu weniger oder sogar nur einem SAP-Spoke-Netzwerk kombinieren. Eine Trennung zwischen Produktions- und Nicht-Produktionsumgebungen ist weiterhin erforderlich. Jede SAP-Produktionsumgebung wird zu einem Subnetz in einem virtuellen SAP-Produktionsnetzwerk. Jede SAP-Nicht-Produktionsumgebung wird zu einem Subnetz in einem virtuellen SAP-Nicht-Produktionsnetzwerk.

Beitragende

Microsoft pflegt diesen Artikel. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Nächste Schritte