Konnektivität mit SAP RISE

Mit Ihrer SAP-Landschaft, die in RISE betrieben wird und in einem separaten virtuellen Netzwerk ausgeführt wird, bieten wir in diesem Artikel verfügbare Konnektivitätsoptionen an.

Peering virtueller Netzwerke mit SAP RISE/ECS

Ein virtuelles Netzwerk (vnet)-Peering ist die leistungsfähigste Methode, um eine sichere Verbindung zwischen zwei virtuellen Netzwerken herzustellen, die sich alle in einem privaten Netzwerkadressraum befinden. Die Netzwerke mit Peering werden aus Konnektivitätsgründen als eins angezeigt, sodass Anwendungen miteinander kommunizieren können. Anwendungen, die in verschiedenen virtuellen Netzwerken, Abonnements, Azure-Mandanten oder Regionen ausgeführt werden, können direkt kommunizieren. Wie der Netzwerkdatenverkehr in einem einzelnen virtuellen Netzwerk verbleibt der Peering-Datenverkehr in einem privaten Adressbereich und durchquert das Internet nicht. Es fallen Gebühren für das Peering virtueller Netzwerke an.

Für SAP RISE/ECS-Bereitstellungen ist virtuelles Peering der bevorzugte Weg, um Konnektivität mit der bestehenden Azure-Umgebung des Kunden herzustellen. Die wichtigsten Vorteile sind:

• Minimierte Netzwerklatenz und maximaler Durchsatz zwischen SAP RISE-Landschaft und eigenen Anwendungen und Diensten, die in Azure ausgeführt werden.
• Keine zusätzliche Komplexität und Kosten mit einem dedizierten lokalen Kommunikationspfad für die SAP RISE-Workload. Stattdessen stellt Ihr vorhandener Azure-Netzwerkhub den lokalen Kommunikationspfad bereit.

Das Peering virtueller Netzwerke kann in derselben Region wie Ihre verwaltete SAP-Umgebung eingerichtet werden, aber auch über globales Peering virtueller Netzwerke zwischen zwei Azure-Regionen. Da SAP RISE/ECS in vielen Azure-Regionen verfügbar ist, sollte die Region aufgrund von Latenz und Kostenüberlegungen zum VNET-Peering idealerweise mit Workloads abgeglichen werden, die in virtuellen Kundennetzwerken ausgeführt werden. Einige Szenarien (z. B. zentrale S/4HANA-Bereitstellung für ein global dargestelltes Unternehmen) erfordern jedoch auch globale Peeringnetzwerke. Für eine solche global verteilte SAP-Landschaft empfehlen wir die Verwendung der Multi-Region-Netzwerkarchitektur in Ihrer eigenen Azure-Umgebung mit SAP RISE-Peering lokal in jeder Geografie zu Ihren Netzwerkhubs.

Sowohl die virtuellen SAP- als auch die Kundennetzwerke sind durch Netzwerksicherheitsgruppen (NSG) geschützt und erlauben die Kommunikation über SAP- und Datenbankports, die durch das Peering ermöglicht wird. Die Kommunikation zwischen den gepeerten virtuellen Netzwerken wird durch diese NSGs gesichert, wodurch die Kommunikation auf die SAP-Umgebung des Kunden beschränkt wird.

Da SAP RISE/ECS in SAPs Azure-Mandant und Abonnements läuft, richten Sie das virtuelle Netzwerk-Peering zwischen verschiedenen Mandanten ein. Dies können Sie erreichen, indem Sie das Peering mit der Azure-Ressourcen-ID des von SAP bereitgestellten Netzwerks einrichten und das Peering von SAP genehmigen lassen. Fügen Sie einen Benutzer aus dem gegenüberliegenden Microsoft Entra-Mandanten als Gastbenutzer hinzu, akzeptieren Sie die Einladung des Gastbenutzers, und folgen Sie dem Prozess, der unter Erstellen eines virtuellen Netzwerk-Peerings dokumentiert ist – verschiedene Abonnements. Wenden Sie sich an Ihren SAP-Vertreter, um die genauen erforderlichen Schritte zu erfragen. Binden Sie die entsprechenden Teams innerhalb Ihrer Organisation ein, die sich mit Netzwerk, Benutzerverwaltung und Architektur befassen, damit dieser Prozess schnell abgeschlossen werden kann.

SAP bietet keine private Konnektivität über private Endpunkte zu SAP RISE-Workloads für Kunden im Allgemeinen. Einige seltene und isolierte Szenarien können einen solchen privaten Endpunkt für Kunden verwenden, aber SAP aktiviert solche privaten Endpunkte nicht für die verwaltete SAP-Landschaft.

Firewall als Dienst und Subnetz-Peering

Für Kunden, die eine stärkere netzwerkbasierte Sicherheit als NSGs erfordern, bietet RISE einen optionalen Premiumdienst namens "Firewall as a Service (FWaaS)". Die Firewall ist ein von SAP RISE/ECS bereitgestellter verwalteter Dienst und stellt eine Makrosegmentierung von SAP-Workloads in verschiedene Ebenen bereit. Systeme innerhalb derselben Ebene können die Firewall umgehen und direkt kommunizieren, während die kommunikation zwischen den Ebenen die Firewall durchlaufen und die Regeln der Datenverkehrskontrolle einhalten muss. Sie können den erforderlichen Regelsatz ändern und Firewallprotokolle und Überwachungspfade über den RISE LogServ-Dienst abrufen.

Um den FWaaS-Dienst zu aktivieren, wird Subnetz-Peering zwischen einem Subnetz aus dem RISE-VNet und einem Subnetz auf der Kundenseite eingerichtet. Im Gegensatz zum vollständigen VNet-Peering ermöglicht Subnetz-Peering nur die Kommunikation zwischen den ausgewählten Subnetzen, die an der Peering beteiligt sind. Wenn Sie das FWaaS-Angebot von RISE abonnieren, wird Subnetz-Peering zwischen einem RISE-Subnetz eingerichtet, das eine Firewall hostet, und einem Kundensubnetz, das eine NVA oder eine andere Routing-Appliance hostet. Jede NVA wird als primäres Routenziel für jede RISE-Kommunikation konfiguriert. Daher durchläuft der gesamte Datenverkehr zwischen SAP RISE-Workloads und Ihrem Netzwerk beide Appliances.

Die VON RISE betriebene Firewall ersetzt keine vom Kunden betriebenen Firewalls innerhalb Ihres eigenen Abonnements, der FWaaS-Dienst ergänzt Ihre vorhandene Einrichtung.

VPN Vnet-to-Vnet

Als Alternative zum virtuellen Netzwerk-Peering kann eine VPN-Verbindung (Virtuelles privates Netzwerk) zwischen VPN-Gateways hergestellt werden, die sowohl im SAP RISE/ECS-Abonnement als auch im Besitz der Kunden bereitgestellt werden. Sie können zwischen diesen beiden VPN-Gateways wird eine VNET-zu-VNET-Verbindung herstellen, die eine schnelle Kommunikation zwischen den beiden separaten virtuellen Netzwerken ermöglicht. Die jeweiligen Netzwerke und Gateways können sich in verschiedenen Azure-Regionen befinden.

Das virtuelles Netzwerk-Peering ist zwar das empfohlene und typischere Bereitstellungsmodell, aber ein VPN-VNET-zu-VNET kann möglicherweise ein komplexes virtuelles Peering zwischen kundenseitigen und virtuellen SAP RISE/ECS-Netzwerken vereinfachen. Das VPN Gateway dient als einziger Zugangspunkt zum Netzwerk des Kunden und wird von einem zentralen Team verwaltet und gesichert. Der Netzwerkdurchsatz ist durch die ausgewählte Gateway-SKU auf beiden Seiten begrenzt. Um die Resilienzanforderungen zu erfüllen, stellen Sie sicher, dass zonenredundante virtuelle Netzwerkgateways für diese Verbindung verwendet werden.

Netzwerksicherheitsgruppen sind sowohl auf dem virtuellen Kunden- als auch im SAP-virtuellen Netzwerk wirksam, identisch mit der Peering-Architektur und ermöglichen die Kommunikation mit SAP NetWeaver- und HANA-Ports nach Bedarf. Ausführliche Informationen zum Einrichten der VPN-Verbindung und zu den zu verwendenden Einstellungen erhalten Sie bei Ihrem SAP-Vertreter.

Konnektivität zurück zum lokalen Standort

Bei einer bestehenden Azure-Bereitstellung des Kunden ist das lokale Netzwerk bereits über ExpressRoute (ER) oder VPN verbunden. Derselbe lokale Netzwerkpfad wird in der Regel für verwaltete SAP RISE/ECS-Workloads verwendet. Die bevorzugte Architektur besteht darin, vorhandene ER/VPN-Gateways im Abonnement des Kunden zu diesem Zweck zu verwenden. Das verbundene virtuelle SAP RISE-Netzwerk fungiert als Speichennetzwerk, das mit dem virtuellen Netzwerkhub des Kunden verbunden ist.

Mit dieser Architektur gelten zentrale Richtlinien und Sicherheitsregeln für die Netzwerkkonnektivität mit Kundenworkloads auch für verwaltete SAP RISE/ECS-Workloads. Der gleiche lokale Netzwerkpfad wird sowohl für die VNETs des Kunden als auch für das SAP RISE/ECS-virtuelle Netzwerk verwendet.

Wenn derzeit keine Konnektivität zwischen Azure und der lokalen Bereitstellung vorhanden ist, wenden Sie sich an Ihren SAP-Vertreter, um zu erfahren, welche Verbindungsmodelle für die Workload von RISE möglich sind. Wenn SAP RISE/ECS lokal in RISE direkt eingerichtet wird, steht eine solche lokale Verbindung nur zum Erreichen des von SAP verwalteten virtuellen Netzwerks zur Verfügung. Eine solche dedizierte ExpressRoute- oder VPN-Verbindung innerhalb von SAP RISE kann nicht für den Zugriff auf die eigenen virtuellen Azure-Netzwerke des Kunden verwendet werden. Stellen Sie sicher, dass Ihre ExpressRoute hinsichtlich der Ausfallsicherheit konzipiert ist, wobei eine hohe oder maximale Ausfallsicherheit empfohlen wird.

Virtual WAN mit von SAP RISE verwalteten Workloads

Ähnlich wie bei der Verwendung einer Hub-and-Speichen-Netzwerkarchitektur mit Konnektivität mit SAP RISE/ECS virtuellen Netzwerk und lokal kann Azure Virtual Wan-Hub (vWAN) für den gleichen Zweck verwendet werden. RISE-Workload ist ein Speichennetzwerk, das mit dem vWAN-Netzwerkhub verbunden ist. Beide Verbindungsoptionen zu SAP RISE, die zuvor beschrieben wurden – virtuelles Netzwerk-Peering sowie VPN-vnet-zu-vnet – sind mit vWAN verfügbar.

Der vWAN-Netzwerkhub wird vom Kunden in einem eigenen Abonnement bereitgestellt und verwaltet. Der Kunde verwaltet auch vollständig die lokale Verbindung und das Routing über den vWAN-Netzwerkhub, mit Zugriff auf SAP RISE Peered virtuelles Speichennetzwerk.

Konnektivität während der Migration zu SAP/RISE

Die Migration Ihrer SAP-Umgebung zu SAP/RISE erfolgt in mehreren Phasen über mehrere Monate oder einen noch längeren Zeitraum. Einige Ihrer SAP-Umgebungen werden bereits migriert und produktiv verwendet, während Sie andere SAP-Systeme für die Migration vorbereiten. In den meisten Kundenprojekten werden die größten und kritischsten Systeme in der Mitte oder am Ende des Projekts migriert. Sie brauchen eine ausreichende Bandbreite für die Datenmigration oder Datenbankreplikation vorsehen müssen, ohne den Netzwerkpfad Ihrer Benutzer zu den bereits produktiven RISE-Umgebungen zu beeinträchtigen. Bereits migrierte SAP-Systeme müssen möglicherweise auch mit der SAP-Umgebung kommunizieren, die noch lokal oder beim jeweiligen Dienstanbieter vorhanden ist.

Planen Sie während der Migrationsplanung zu SAP RISE, wie in jeder Phase SAP-Systeme für Ihre Benutzerbasis erreichbar sind und wie die Datenübertragung an das virtuelle RISE/ECS-Netzwerk weitergeleitet wird. Oft werden mehrere Standorte und beteiligte Parteien in Betracht gezogen, z. B. vorhandene Dienstanbieter und Rechenzentren mit eigener Anbindung an Ihr Unternehmensnetzwerk. Stellen Sie sicher, dass keine temporären Lösungen mit VPN-Verbindungen geschaffen werden, ohne zu berücksichtigen, wie in späteren Phasen die SAP-Daten für die geschäftskritischsten Systeme migriert werden.

DNS-Integration mit verwalteten SAP RISE/ECS-Workloads

Die Integration kundeneigener Netzwerke in die cloudbasierte Infrastruktur und die Bereitstellung eines nahtlosen Namensauflösungskonzepts sind ein wesentlicher Bestandteil einer erfolgreichen Projektimplementierungen. Dieses Diagramm beschreibt eines der üblichen Integrationsszenarien von SAP-eigenen Abonnements, virtuelle Netzwerke und DNS-Infrastruktur mit dem lokalen Netzwerk und den DNS-Diensten des Kunden. Bei dieser Einrichtung halten Azure Hub- oder lokale DNS-Server alle DNS-Einträge. Die DNS-Infrastruktur ist in der Lage, DNS-Anforderungen aus allen Quellen (lokale Clients, Azure-Dienste des Kunden und von SAP verwaltete Umgebungen) aufzulösen.

Entwurfsbeschreibung und Besonderheiten:

• Benutzerdefinierte DNS-Konfiguration für virtuelle SAP-Netzwerke

• Zwei VMs innerhalb des virtuellen RISE/PCE Azure-Netzwerks hosten DNS-Server

• Kunden müssen eine Unterdomäne/Zone (z. B. Beispiel ecs.contoso.com) bereitstellen und an SAP delegieren, zum Zuweisen von Namen und Erstellen von Vorwärts- und Reverse-DNS-Einträgen für die virtuellen Computer, auf denen die verwaltete SAP-Umgebung ausgeführt wird. SAP DNS-Server verfügen über eine MASTER-DNS-Rolle für die delegierte Zone.

• Der DNS-Zonentransfer vom SAP DNS-Server zu den DNS-Servern des Kunden ist die primäre Methode zur Replikation von DNS-Einträgen aus der RISE/PCE-Umgebung in das DNS vor Ort.

• Die virtuellen Azure-Netzwerke des Kunden verwenden auch eine benutzerdefinierte DNS-Konfiguration, die sich auf Kunden-DNS-Server bezieht, die sich im virtuellen Azure-Hub-Netzwerk befinden.

• Optional können Kunden eine private DNS-Weiterleitung in ihren virtuellen Azure-Netzwerken einrichten. Diese Weiterleitung überträgt dann DNS-Anforderungen von Azure-Diensten an SAP DNS-Server, die für die delegierte Zone vorgesehen sind (Beispiel ecs.contoso.com).

Die DNS-Zonenübertragung gilt für die Designs, wenn Kunden benutzerdefinierte DNS-Lösungen (z. B. AD DS oder BIND-Server) innerhalb ihres virtuellen Hubnetzwerks betreiben.

SAP hat einen Blogbeitrag zur DNS-Implementierung mit SAP RISE in Azure veröffentlicht. Weitere Informationen finden Sie hier.

Weitere Informationen zur Verwendung von Azure DNS für SAP außerhalb der Nutzung mit SAP RISE/ECS finden Sie im folgenden Blogbeitrag.

Ausgehende und eingehende Internetverbindungen mit SAP RISE/ECS

SAP-Workloads, die mit externen Anwendungen und Schnittstellen kommunizieren, könnten einen Netzwerkausgangspfad zum Internet erfordern. Ebenso benötigen die Benutzerbasis Ihres Unternehmens (z. B. SAP Fiori) eine Ingress- oder eingehende Verbindung zur SAP-Landschaft. Für verwaltete SAP RISE-Workloads arbeiten Sie mit Ihrem SAP-Vertreter zusammen, um die Anforderungen für solche HTTPS-/RFC-/anderen Kommunikationspfade zu untersuchen. Die Netzwerkkommunikation mit dem/aus dem Internet ist für SAP RISE/ECS-Kunden standardmäßig nicht aktiviert, und das Standardnetzwerk verwendet nur private IP-Adressbereiche. Internet-Konnektivität erfordert eine Planung mit SAP, um die SAP-Landschaft des Kunden optimal zu schützen.

Wenn Sie internetgebundenen oder eingehenden Datenverkehr mit Ihren SAP RISE aktivieren, wird die Netzwerkkommunikation durch verschiedene Azure-Technologien wie NSGs, ASGs, Application Gateway mit Web Application Firewall (WAF), Proxyservern und anderen geschützt, je nach Nutzung und verwendeten Netzwerkprotokollen. Diese Dienste werden vollständig über SAP innerhalb des SAP RISE/ECS-VNET und -Abonnements verwaltet. Der Netzwerkpfad SAP RISE zu und aus dem Internet verbleibt in der Regel nur innerhalb des virtuellen SAP RISE/ECS-Netzwerks und wird nicht in die eigenen vnets des Kunden übergehen.

Anwendungen innerhalb Ihres eigenen virtuellen Netzwerks stellen direkt oder über die zentral verwalteten Dienste des Kunden wie Azure Firewall, NAT-Gateway und andere Anwendungen direkt oder über das virtuelle Netzwerk eine Verbindung mit dem Internet her. Die Konnektivität mit SAP BTP von Nicht-SAP RISE/ECS-Anwendungen nimmt denselben netzwerkgebundenen Internetpfad ihrerseits an. Sollte ein SAP Cloud Connecter für eine solche Integration erforderlich sein, führen Sie ihn auf den VMs des Kunden aus. Mit anderen Worten, die Kommunikation von Ihren eigenen Anwendungen an SAP BTP oder ein beliebiger öffentlicher RISE-Endpunkt befindet sich auf einem von Ihnen verwalteten Netzwerkpfad. Die Kommunikation von Ihrer SAP RISE-Landschaft an SAP BTP oder andere öffentliche SAP-Endpunkte befindet sich auf einem Netzwerkpfad, der von SAP RISE/ECS verwaltet wird.

SAP BTP-Konnektivität

Sap Business Technology Platform (BTP) bietet eine Vielzahl von Anwendungen, auf die am häufigsten über öffentliche IP-Adresse/Hostname über das Internet zugegriffen wird. Die Dienste des Kunden, die in ihren Azure-Abonnements ausgeführt werden, greifen über die konfigurierte Ausgehende Zugriffsmethode, z. B. die zentrale Firewall oder ausgehende öffentliche IPs, auf BTP zu. Einige SAP-BTP-Dienste, z. B. SAP Data Intelligence, greifen jedoch über ein separates virtuelles Netzwerk-Peering anstatt über einen öffentlichen Endpunkt zu.

SAP bietet den Dienst Private Link für Kunden, die SAP BTP in Azure für unidirektionale Anforderungen verwenden, die von BTP stammen. Der SAP Private Link-Dienst verbindet die SAP BTP-Dienste über einen privaten IP-Bereich mit dem Azure-Netzwerk des Kunden und ist somit privat über den Private Link-Dienst und nicht über das Internet zugänglich. Erkundigen Sie sich bei SAP nach der Verfügbarkeit dieses Dienstes für SAP RISE/ECS-Workloads. Hier erfahren Sie mehr über die SAP-Unterstützung für Private Link für RISE.

Lesen Sie die Dokumentation von SAP und eine Reihe von Blogbeiträgen zur Architektur der SAP BTP Private Link Service und privaten Konnektivitätsmethoden von BTP, die sich mit DNS und Zertifikaten in der folgenden SAP-Blogreihe "Erste Schritte mit BTP Private Link Service für Azure" befasst.

Die Verbindung mit BTP verwendet keine private Verknüpfung und kommuniziert mit einer öffentlichen Schnittstelle. Wenn sowohl SAP BTP als auch Ihre SAP RISE-Landschaft in Azure ausgeführt werden, besteht das Standardroutingverhalten darin, eine solche internetgebundene Kommunikation im Azure-Backbone beizubehalten. Weitere Informationen finden Sie in der Dokumentation zum Azure-Datenverkehrsrouting.

Netzwerkkommunikationsports mit SAP RISE

Jeder Azure-Dienst mit Zugriff auf das virtuelle Kundennetzwerk kann über die verfügbaren Ports mit der SAP-Landschaft kommunizieren, die im SAP RISE/ECS-Abonnement ausgeführt wird.

Auf Ihr SAP-System in SAP RISE kann über die offenen Netzwerkports zugegriffen werden, wie sie von SAP für Ihre Verwendung konfiguriert und geöffnet werden. Https-, RFC- und ODBC-Protokolle können über private Netzwerkadressbereiche verwendet werden. Darüber hinaus können Anwendungen über https auf eine öffentlich verfügbare IP zugreifen, die vom von SAP RISE verwalteten Azure-Anwendungsgateway verfügbar gemacht wird. Wenden Sie sich an SAP, um Details und Informationen zur Einstellung für das Anwendungsgateway und offene NSG-Ports zu erhalten.

Weitere Informationen zum Integrieren von Azure-Diensten in SAP RISE finden Sie in der Möglichkeit, Ihre SAP-Landschaft mit Azure-Diensten zu erweitern.

Nächste Schritte

Weitere Informationen finden Sie in der Dokumentation:

• Integrieren von Azure in SAP RISE
• Integrieren von Azure-Diensten in SAP RISE
• Identität und Sicherheit in Azure mit SAP RISE
• Peering in virtuellen Netzwerken
• DNS-Integration in SAP RISE in Multicloud-Umgebungsserienhandbuch – Azure | SAP-Blogs