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 SAP RISE-Workloads. Verwenden Sie stattdessen einen lokalen Kommunikationspfad der vorhandenen Azure-Netzwerkhubs.
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 Multi-Region-Netzwerkarchitektur in Ihrer eigenen Azure-Umgebung zu verwenden, wobei SAP RISE-Peering lokal in jeder Geografie zu Ihren Netzwerkhubs verwendet wird.
Dieses Diagramm zeigt die virtuellen Hub-and-Spoke-Netzwerke eines typischen SAP-Kunden. Mandantenübergreifendes virtuelles Netzwerk-Peering verbindet SAP RISE und die virtuellen Hubnetzwerke des Kunden.
Sowohl das SAP-VNET als auch die VNets der Kunden sind mit Netzwerksicherheitsgruppen (NSG) geschützt, wodurch die Kommunikation über SAP- und Datenbankports über 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 entgegengesetzten Microsoft Entra Mandanten als Gastbenutzer hinzu, akzeptieren Sie die Einladung des Gastbenutzers, und befolgen Sie den unter Erstellen eines virtuellen Netzwerk-Peerings – verschiedene Abonnements dokumentierten Prozess. Wenden Sie sich an Ihren SAP-Vertreter, um die genauen erforderlichen Schritte zu erfragen. Wenden Sie sich an die entsprechenden Teams in Ihrer Organisation, die sich mit Netzwerk, Benutzerverwaltung und Architektur befassen, damit dieser Prozess schnell abgeschlossen werden kann.
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.
Dieses Diagramm zeigt die virtuellen Hub-and-Spoke-Netzwerke eines typischen SAP-Kunden. Das VPN-Gateway im SAP RISE virtuellen Netzwerk stellt über eine VNET-zu-VNET-Verbindung eine Verbindung mit dem Gateway her, das im Hub virtuellen Netzwerk des Kunden enthalten ist.
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 für Kunden als auch für SAP-VNET wirksam. Dies entspricht der virtuellen Netzwerk-Peeringarchitektur, die bei Bedarf die Kommunikation mit SAP NetWeaver- und HANA-Ports ermöglicht. 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 ist die Verwendung vorhandener ER/VPN-Gateways im des Kunden für diesen Zweck, wobei das angeschlossene SAP RISE-virtuellen Netzwerk als Speichen-Netzwerk betrachtet wird, das mit dem Hub-Virtuellen Netzwerk des Kunden verbunden ist.
Dieses Diagramm zeigt die virtuellen Hub-and-Spoke-Netzwerke eines typischen SAP-Kunden. Stellt eine Verbindung mit einer lokalen Verbindung her. Mandantenübergreifendes virtuelles Netzwerk-Peering verbindet das virtuelle SAP RISE-Netzwerk mit dem Hubnetzwerk des Kunden. Das virtuelle Netzwerkpeering ist für die Remotegatewaytransit aktiviert, sodass auf das virtuelle SAP RISE-Netzwerk über die lokale Bereitstellung zugegriffen werden kann.
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.
Hinweis
Ein virtuelles Netzwerk kann nur über ein Gateway( lokal oder remote) verfügen. Wenn das virtuelle Netzwerk-Peering zwischen SAP RISE/ECS über den Remotegatewaytransit eingerichtet wurde, können im SAP RISE/ECS-virtuellen Netzwerk keine Gateways hinzugefügt werden. Eine Kombination aus virtuellem Netzwerk-Peering mit Remotegatewaytransit zusammen mit einem anderen virtuellen Netzwerkgateway im virtuellen SAP RISE/ECS-Netzwerk ist nicht möglich.
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.
Hinweis
Sowohl von Azure bereitgestelltes DNS als auch private Azure-Zonen unterstützenkeine DNS-Zonenübertragungsfunktionen und können daher nicht verwendet werden, um die DNS-Replikation von SAP RISE/PCE/ECS-DNS-Servern zu akzeptieren. Darüber hinaus unterstützt SAP in der Regel keine externen DNS-Dienstanbieter für die delegierte Zone.
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 zum und vom Internet bleibt in der Regel nur innerhalb des SAP RISE/ECS-virtuellen Netzwerks und geht nicht in/aus kundeneigenen VNet(s).
Anwendungen innerhalb eines kundeneigenen virtuellen Netzwerks verbinden sich mit dem Internet direkt vom jeweiligen virtuellen Netzwerks oder über die zentral verwalteten Dienste des Kunden wie Azure Firewall, Azure Application Gateway, NAT Gateway und andere. 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, SAP BTP oder eine öffentliche Endpunktkommunikation befindet sich auf einem Netzwerkpfad, der von Kunden selbst verwaltet wird, wenn SAP RISE-Workload nicht beteiligt ist.
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.
Die SAP-Dokumentation und eine Reihe von Blog-Beiträgen zur Architektur des SAP BTP Private Link-Dienstes und zu Methoden der privaten Konnektivität, die sich mit DNS und Zertifikaten befassen, finden Sie in der folgenden SAP-Blog-Serie Erste Schritte mit BTP Private Link-Dienst für Azure.
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.
Abbildung: Geöffnete Ports auf einem SAP RISE-/ECS-System. RFC-Verbindungen für BAPI und IDoc, HTTPS für OData und Rest/SOAP. ODBC/JDBC für direkte Datenbankverbindungen mit SAP HANA. Alle Verbindungen über das private virtuelle Netzwerk-Peering. Application Gateway mit öffentlicher IP-Adresse für HTTPS als potenzielle Option, verwaltet durch SAP.
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: