Delen via


Verbinding maken iviteit met SAP RISE

Nu uw SAP-landschap wordt uitgevoerd in RISE en wordt uitgevoerd in een afzonderlijk virtueel netwerk, bieden we in dit artikel beschikbare connectiviteitsopties.

Peering van virtuele netwerken met SAP RISE/ECS

Een vnet-peering (virtueel netwerk) is de meest krachtige manier om veilig verbinding te maken tussen twee virtuele netwerken, allemaal in een privénetwerkadresruimte. De gekoppelde netwerken worden weergegeven als een netwerk voor connectiviteitsdoeleinden, zodat toepassingen met elkaar kunnen communiceren. Toepassingen die worden uitgevoerd in verschillende virtuele netwerken, abonnementen, Azure-tenants of -regio's kunnen rechtstreeks communiceren. Net als netwerkverkeer in één virtueel netwerk blijft peeringverkeer in een privéadresruimte en gaat het internet niet over.

Voor SAP RISE/ECS-implementaties is virtuele peering de beste manier om verbinding te maken met de bestaande Azure-omgeving van de klant. Primaire voordelen zijn:

  • Minimale netwerklatentie en maximale doorvoer tussen SAP RISE-landschap en eigen toepassingen en services die worden uitgevoerd in Azure.
  • Geen extra complexiteit en kosten met verschillende on-premises communicatiepaden voor SAP RISE, in plaats daarvan met behulp van bestaande Azure-netwerkhub(s).

Peering van virtuele netwerken kan worden ingesteld binnen dezelfde regio als uw door SAP beheerde omgeving, maar ook via wereldwijde peering van virtuele netwerken tussen twee Azure-regio's. Omdat SAP RISE/ECS beschikbaar is in veel Azure-regio's, moet de regio overeenkomen met de workload die wordt uitgevoerd in virtuele netwerken van klanten vanwege latentie- en peeringkostenoverwegingen. Sommige scenario's (bijvoorbeeld centrale S/4HANA-implementatie voor een wereldwijd aanwezig bedrijf) vereisen echter ook peernetwerken wereldwijd. Voor dergelijke wereldwijd gedistribueerde SAP-landschap raden we u aan om netwerkarchitectuur met meerdere regio's te gebruiken in uw eigen Azure-omgeving, met SAP RISE-peering lokaal in elke geografie naar uw netwerkhubs.

Customer peering with SAP RISE/ECS

In dit diagram ziet u een typische hub en spoke virtuele netwerken van sap-klanten. Peering voor virtuele netwerken tussen tenants verbindt virtuele SAP RISE- en hubnetwerken van de klant.

Zowel het virtuele SAP- als het virtuele netwerk van de klant worden beveiligd met netwerkbeveiligingsgroepen (NSG), waardoor communicatie op SAP- en databasepoorten via de peering wordt toegestaan. Communicatie tussen de gekoppelde virtuele netwerken wordt beveiligd via deze NSG's, waardoor de communicatie van en naar de SAP-omgeving van de klant wordt beperkt.

Aangezien SAP RISE/ECS wordt uitgevoerd in de Azure-tenant en -abonnementen van SAP, stelt u de peering van het virtuele netwerk tussen verschillende tenants in. U kunt deze configuratie uitvoeren door de peering in te stellen met de Azure-resource-id van het opgegeven SAP-netwerk en sap de peering goed te keuren. Voeg een gebruiker toe van de tegenovergestelde Microsoft Entra-tenant als gastgebruiker, accepteer de uitnodiging voor gastgebruikers en volg het proces dat wordt beschreven bij Een peering voor een virtueel netwerk maken - verschillende abonnementen. Neem contact op met uw SAP-vertegenwoordiger voor de exacte stappen die nodig zijn. Neem contact op met de respectieve team(s) binnen uw organisatie die te maken hebben met netwerk- en gebruikersbeheer en -architectuur, zodat dit proces snel kan worden voltooid.

VPN vnet-naar-vnet

Als alternatief voor peering van virtuele netwerken kan een VPN-verbinding (virtueel particulier netwerk) tot stand worden gebracht tussen VPN-gateways, die zowel in het SAP RISE/ECS-abonnement als de eigen klanten zijn geïmplementeerd. U kunt een vnet-naar-vnet-verbinding tot stand brengen tussen deze twee VPN-gateways, waardoor snelle communicatie tussen de twee afzonderlijke virtuele netwerken mogelijk is. De respectieve netwerken en gateways kunnen zich in verschillende Azure-regio's bevinden.

Diagram ofSAP RISE/ECS VPN connection to customer virtual network.

In dit diagram ziet u een typische hub en spoke virtuele netwerken van sap-klanten. VPN-gateway die zich in het virtuele SAP RISE-netwerk bevindt, maakt verbinding via een vnet-naar-vnet-verbinding in de gateway in het virtuele hubnetwerk van de klant.

Hoewel peering van virtuele netwerken het aanbevolen en meer gangbare implementatiemodel is, kan een VPN-vnet-naar-vnet mogelijk een complexe virtuele peering tussen klant- en SAP RISE/ECS-netwerken vereenvoudigen. De VPN Gateway fungeert als enige toegangspunt in het netwerk van de klant en wordt beheerd en beveiligd door een centraal team. Netwerkdoorvoer wordt beperkt door de gekozen gateway-SKU aan beide zijden. Om te voldoen aan de tolerantievereisten, moet u ervoor zorgen dat zone-redundante virtuele netwerkgateways worden gebruikt voor een dergelijke verbinding.

Netwerkbeveiligingsgroepen zijn van kracht op zowel de klant als het virtuele SAP-netwerk, identiek aan peeringarchitectuur, waardoor communicatie met SAP NetWeaver- en HANA-poorten naar behoefte mogelijk is. Neem contact op met uw SAP-vertegenwoordiger voor meer informatie over het instellen van de VPN-verbinding en welke instellingen moeten worden gebruikt.

Verbinding maken iviteit terug naar on-premises

Met een bestaande Azure-implementatie van een klant is het on-premises netwerk al verbonden via ExpressRoute (ER) of VPN. Hetzelfde on-premises netwerkpad wordt doorgaans gebruikt voor door SAP RISE/ECS beheerde workloads. De voorkeursarchitectuur is het gebruik van bestaande ER/VPN-gateways in de klant voor dit doel, met een verbonden virtueel SAP RISE-netwerk, gezien als een spoke-netwerk dat is verbonden met de virtuele netwerkhub van de klant.

Example diagram of SAP RISE/ECS as spoke network peered to customer's virtual network hub and on-premises.

In dit diagram ziet u een typische hub en spoke virtuele netwerken van sap-klanten. Verbinding maken on-premises met een verbinding. Peering tussen tenants voor virtueel netwerk verbindt het virtuele SAP RISE-netwerk met het hubnetwerk van de klant. Voor peering van virtuele netwerken is externe gatewayoverdracht ingeschakeld, waardoor het virtuele SAP RISE-netwerk toegankelijk is vanuit on-premises.

Met deze architectuur zijn centrale beleidsregels en beveiligingsregels voor netwerkconnectiviteit met klantworkloads ook van toepassing op door SAP RISE/ECS beheerde workloads. Hetzelfde on-premises netwerkpad wordt gebruikt voor het virtuele NETWERK van zowel de klant als het virtuele SAP RISE/ECS-netwerk.

Als er momenteel geen Azure-verbinding met on-premises connectiviteit is, neemt u contact op met uw SAP-vertegenwoordiger voor meer informatie over welke verbindingsmodellen mogelijk zijn voor de RISE-workload. Als SAP RISE/ECS on-premises rechtstreeks in RISE tot stand brengt, is een dergelijke on-premises verbinding alleen beschikbaar voor het bereiken van het door SAP beheerde virtuele netwerk. Een dergelijke toegewezen ExpressRoute- of VPN-verbinding binnen SAP RISE kan niet worden gebruikt voor toegang tot de eigen virtuele Azure-netwerken van de klant.

Notitie

Een virtueel netwerk kan slechts één gateway, lokaal of extern hebben. Wanneer peering van virtuele netwerken tot stand is gebracht tussen SAP RISE met behulp van externe gatewayoverdracht, kunnen er geen gateways worden toegevoegd in het virtuele SAP RISE/ECS-netwerk. Een combinatie van peering van virtuele netwerken met externe gatewayoverdracht samen met een andere virtuele netwerkgateway in het virtuele SAP RISE/ECS-netwerk is niet mogelijk.

Virtual WAN met door SAP RISE beheerde workloads

Net als bij het gebruik van een hub- en spoke-netwerkarchitectuur met connectiviteit met zowel het virtuele SAP RISE/ECS-netwerk als on-premises, kan Azure Virtual Wan -hub (vWAN) voor hetzelfde doel worden gebruikt. RISE-werkbelasting is een spoke-netwerk dat is verbonden met de vWAN-netwerkhub. Beide verbindingsopties voor SAP RISE die eerder zijn beschreven: peering van virtuele netwerken en VPN-vnet-naar-vnet- zijn beschikbaar met vWAN.

De vWAN-netwerkhub wordt geïmplementeerd en beheerd door de klant in een eigen abonnement. De klant beheert ook volledig de on-premises verbinding en routering via de vWAN-netwerkhub, met toegang tot een virtueel SAP RISE-peered spoke-netwerk.

Verbinding maken iviteit tijdens migratie naar SAP RISE

Migratie van uw SAP-landschap naar SAP RISE wordt uitgevoerd in verschillende fasen gedurende meerdere maanden of langer. Sommige van uw SAP-omgevingen worden al gemigreerd en worden productief gebruikt, terwijl u andere SAP-systemen voorbereidt op migratie. In de meeste klantprojecten worden de grootste en meest kritieke systemen gemigreerd in het midden of aan het einde van het project. U moet overwegen om voldoende bandbreedte te hebben voor gegevensmigratie of databasereplicatie, en niet van invloed op het netwerkpad van uw gebruikers naar de reeds productieve RISE-omgevingen. Al gemigreerde SAP-systemen moeten mogelijk ook communiceren met het SAP-landschap dat nog on-premises of bij een bestaande serviceprovider is.

Plan tijdens uw migratieplanning naar SAP RISE hoe in elke fase SAP-systemen bereikbaar zijn voor uw gebruikersbasis en hoe gegevensoverdracht naar het virtuele RISE/ECS-netwerk wordt gerouteerd. Vaak zijn er meerdere locaties en partijen betrokken, zoals bestaande serviceproviders en datacenters met een eigen verbinding met uw bedrijfsnetwerk. Zorg ervoor dat er geen tijdelijke oplossingen met VPN-verbindingen worden gemaakt zonder te overwegen hoe SAP-gegevens in latere fasen worden gemigreerd voor de meest bedrijfskritieke systemen.

DNS-integratie met door SAP RISE/ECS beheerde workloads

Integratie van netwerken die eigendom zijn van de klant met een cloudinfrastructuur en het bieden van een naadloos naamomzettingsconcept is een essentieel onderdeel van een succesvolle projectuitvoering. In dit diagram wordt een van de algemene integratiescenario's van SAP-abonnementen, virtuele netwerken en DNS-infrastructuur beschreven met het lokale netwerk en DNS-services van de klant. In een dergelijke installatie hebben Azure Hub- of on-premises DNS-servers alle DNS-vermeldingen. De DNS-infrastructuur kan DNS-aanvragen die afkomstig zijn van alle bronnen (on-premises clients, De Azure-services van de klant en door SAP beheerde omgevingen) oplossen.

Diagram shows customer DNS servers are located both within customer's hub as well as SAP RISE virtual networks, with DNS zone transfer between them.

Ontwerpbeschrijving en details:

  • Aangepaste DNS-configuratie voor virtuele SAP-netwerken

  • Twee VM's in de VIRTUELE RISE/PCE Azure-netwerkhost dns-servers

  • Klanten moeten sap een subdomein/zone (bijvoorbeeld ecs.contoso.com) verstrekken en delegeren om namen toe te wijzen en dns-vermeldingen voor doorsturen en omgekeerde DNS-vermeldingen te maken voor de virtuele machines waarop SAP beheerde omgeving wordt uitgevoerd. SAP DNS-servers hebben een hoofd-DNS-rol voor de gedelegeerde zone

  • DNS-zoneoverdracht van SAP DNS-server naar de DNS-servers van de klant is de primaire methode voor het repliceren van DNS-vermeldingen uit RISE/PCE-omgeving.

  • De virtuele Azure-netwerken van de klant maken ook gebruik van aangepaste DNS-configuratie die verwijst naar DNS-servers van de klant die zich in het virtuele Azure Hub-netwerk bevinden.

  • Klanten kunnen desgewenst een privé-DNS-doorstuurserver instellen binnen hun virtuele Azure-netwerken. Een dergelijke doorstuurserver pusht vervolgens DNS-aanvragen die afkomstig zijn van Azure-services naar SAP DNS-servers die zijn gericht op de gedelegeerde zone (bijvoorbeeld ecs.contoso.com).

DNS-zoneoverdracht is van toepassing op de ontwerpen wanneer klanten een aangepaste DNS-oplossing gebruiken (bijvoorbeeld AD DS - of BIND-servers) binnen hun virtuele hubnetwerk.

Notitie

Zowel door Azure geleverde DNS- als Azure-privézones bieden geen ondersteuning voor dns-zoneoverdracht, dus kan niet worden gebruikt voor het accepteren van DNS-replicatie van SAP RISE/PCE/ECS DNS-servers. Daarnaast biedt SAP doorgaans geen ondersteuning voor externe DNS-serviceproviders voor de gedelegeerde zone.

SAP heeft een blogbericht gepubliceerd over de DNS-implementatie met SAP RISE in Azure. Zie hier voor meer informatie.

Raadpleeg de volgende blogpost voor meer informatie over het gebruik van Azure DNS voor SAP, buiten het gebruik met SAP RISE/ECS.

Uitgaande en binnenkomende internetverbindingen met SAP RISE/ECS

SAP-workloads die communiceren met externe toepassingen en interfaces, kunnen een uitgaand netwerkpad naar internet vereisen. Op dezelfde manier heeft de gebruikersbasis van uw bedrijf (bijvoorbeeld SAP Fiori) een inkomend internet- of inkomende verbindingen met het SAP-landschap nodig. Voor door SAP RISE beheerde workloads kunt u samenwerken met uw SAP-vertegenwoordiger om de behoeften voor dergelijke https/RFC/andere communicatiepaden te verkennen. Netwerkcommunicatie naar/van internet is standaard niet ingeschakeld voor SAP RISE/ECS-klanten en standaardnetwerken maken alleen gebruik van privé-IP-bereiken. Voor de internetverbinding is planning met SAP vereist om het SAP-landschap van de klant optimaal te beveiligen.

Als u internetgebonden of binnenkomend verkeer met SAP RISE inschakelt, wordt de netwerkcommunicatie beveiligd via verschillende Azure-technologieën, zoals NSG's, ASG's, Application Gateway met Web Application Firewall (WAF), proxyservers en andere, afhankelijk van gebruik en netwerkprotocollen. Deze services worden volledig beheerd via SAP binnen het virtuele SAP RISE/ECS-netwerk en -abonnement. Het netwerkpad SAP RISE naar en van internet blijft doorgaans alleen binnen het virtuele SAP RISE/ECS-netwerk en wordt niet overgedragen naar/van de eigen vnet(s) van de klant.

Diagram shows SAP Cloud Connector VM from SAP RISE virtual network connecting through Internet to SAP BTP. SAP RISE/ECS provides inbound/outbound internet connectivity. Customer's own workloads go through own internet breakout, not crossing over to SAP RISE virtual network

Toepassingen binnen het eigen virtuele netwerk van een klant maken rechtstreeks verbinding met internet vanuit het respectieve virtuele netwerk of via centraal beheerde services van de klant, zoals Azure Firewall, Azure-toepassing Gateway, NAT Gateway en andere. Verbinding maken iviteit van SAP BTP vanuit niet-SAP RISE/ECS-toepassingen gebruikt hetzelfde netwerkgebonden netwerkpad aan uw zijde. Als een SAP Cloud-Verbinding maken er nodig is voor een dergelijke integratie, voert u deze uit op de VM's van de klant. Met andere woorden, SAP BTP of een openbare eindpuntcommunicatie bevindt zich op een netwerkpad dat wordt beheerd door klanten zelf als SAP RISE-werkbelasting niet betrokken is.

SAP BTP-connectiviteit

SAP Business Technology Platform (BTP) biedt een groot aantal toepassingen die doorgaans worden geopend via openbare IP/hostnaam via internet. De services van klanten die worden uitgevoerd in hun Azure-abonnementen hebben toegang tot BTP via de geconfigureerde uitgaande toegangsmethode, zoals centrale firewall of uitgaande openbare IP-adressen. Sommige SAP BTP-services, zoals SAP Data Intelligence, zijn echter standaard toegankelijk via een afzonderlijke peering van virtuele netwerken in plaats van een openbaar eindpunt.

SAP biedt Private Link Service voor klanten die SAP BTP in Azure gebruiken. De SAP Private Link-service verbindt SAP BTP-services via een privé-IP-bereik in het Azure-netwerk van de klant en is dus privé toegankelijk via de private link-service in plaats van via internet. Neem contact op met SAP voor beschikbaarheid van deze service voor SAP RISE/ECS-workloads.

Raadpleeg de documentatie van SAP en een reeks blogberichten over de architectuur van de SAP BTP Private Link-service en privéconnectiviteitsmethoden, die te maken hebben met DNS en certificaten in de volgende SAP-blogserie Aan de slag met BTP Private Link Service voor Azure.

Netwerkcommunicatiepoorten met SAP RISE

Elke Azure-service met toegang tot het virtuele netwerk van de klant kan communiceren met het SAP-landschap dat wordt uitgevoerd binnen het SAP RISE/ECS-abonnement via de beschikbare poorten.

Diagram of SAP's open ports for integration with SAP services

Diagram van geopende poorten op een SAP RISE/ECS-systeem. RFC-verbindingen voor BAPI en IDoc, https voor OData en Rest/SOAP. ODBC/JDBC voor directe databaseverbindingen met SAP HANA. Alle verbindingen via peering van het privé-virtuele netwerk. Application Gateway met openbaar IP-adres voor https als mogelijke optie, beheerd via SAP.

Uw SAP-systeem in SAP RISE kan worden geopend via de open netwerkpoorten, zoals geconfigureerd en geopend door SAP voor uw gebruik. https, RFC en JDBC/ODBC-protocollen kunnen worden gebruikt via adresbereiken van het privénetwerk. Bovendien hebben toepassingen toegang via https op een openbaar beschikbaar IP-adres, beschikbaar gemaakt door door SAP RISE beheerde Azure-toepassingsgateway. Neem contact op met SAP voor meer informatie en instellingen voor de toepassingsgateway en NSG.

Zie het document Azure-services integreren met SAP RISE hoe u met de beschikbare connectiviteit uw SAP-landschap kunt uitbreiden met Azure-services.

Volgende stappen

Raadpleeg de documentatie: