Anslut ivitet med SAP RISE
Med ditt SAP-landskap som körs i RISE och körs i ett separat virtuellt nätverk tillhandahåller vi i den här artikeln tillgängliga anslutningsalternativ.
Peering för virtuella nätverk med SAP RISE/ECS
Peering för ett virtuellt nätverk (vnet) är det mest högpresterande sättet att ansluta säkert mellan två virtuella nätverk, allt i ett privat nätverksadressutrymme. Peer-kopplade nätverk visas som ett för anslutningsändamål, så att program kan prata med varandra. Program som körs i olika virtuella nätverk, prenumerationer, Azure-klientorganisationer eller regioner kan kommunicera direkt. Precis som nätverkstrafik i ett enda virtuellt nätverk förblir peering-trafik i ett privat adressutrymme och passerar inte internet.
För SAP RISE/ECS-distributioner är virtuell peering det bästa sättet att upprätta anslutning till kundens befintliga Azure-miljö. De främsta fördelarna är:
- Minimerad nätverksfördröjning och maximalt dataflöde mellan SAP RISE-liggande och egna program och tjänster som körs i Azure.
- Ingen extra komplexitet och kostnad med olika lokala kommunikationsvägar för SAP RISE, i stället med hjälp av befintliga Azure-nätverkshubbar.
Peering för virtuella nätverk kan konfigureras inom samma region som din SAP-hanterade miljö, men även via global peering för virtuella nätverk mellan två Azure-regioner. Med SAP RISE/ECS tillgängligt i många Azure-regioner bör regionen matcha med arbetsbelastningen som körs i kundens virtuella nätverk på grund av svarstid och peeringkostnadsöverväganden. Vissa scenarier (till exempel central S/4HANA-distribution för ett globalt närvarande företag) kräver dock också peer-nätverk globalt. För ett sådant globalt distribuerat SAP-landskap rekommenderar vi att du använder nätverksarkitektur för flera regioner i din egen Azure-miljö, med SAP RISE-peering lokalt i varje geografi till dina nätverkshubbar.
Det här diagrammet visar en typisk virtuell SAP-kunds hubb- och ekernätverk. Peering för virtuella nätverk mellan klientorganisationer ansluter SAP RISE och kundens virtuella hubbnätverk.
Både SAP och kundens virtuella nätverk skyddas med nätverkssäkerhetsgrupper (NSG), vilket tillåter kommunikation på SAP- och databasportar via peering. Kommunikationen mellan peer-kopplade virtuella nätverk skyddas via dessa NSG:er, vilket begränsar kommunikationen till och från kundens SAP-miljö.
Eftersom SAP RISE/ECS körs i SAP:s Azure-klientorganisation och prenumerationer konfigurerar du peering för virtuella nätverk mellan olika klienter. Du utför den här konfigurationen genom att konfigurera peering med DET SAP-tillhandahållna nätverkets Azure-resurs-ID och låta SAP godkänna peering. Lägg till en användare från den motsatta Microsoft Entra-klientorganisationen som gästanvändare, acceptera inbjudan till gästanvändaren och följ processen som dokumenteras i Skapa en virtuell nätverkspeering – olika prenumerationer. Kontakta SAP-representanten för de exakta steg som krävs. Engagera respektive team i din organisation som hanterar nätverk, användaradministration och arkitektur för att göra det möjligt att slutföra processen snabbt.
VPN vnet-to-vnet
Som ett alternativ till peering för virtuella nätverk kan vpn-anslutning upprättas mellan VPN-gatewayer, distribuerade både i SAP RISE/ECS-prenumerationen och kundernas egna. Du kan upprätta en vnet-till-vnet-anslutning mellan dessa två VPN-gatewayer, vilket möjliggör snabb kommunikation mellan de två separata virtuella nätverken. Respektive nätverk och gatewayer kan finnas i olika Azure-regioner.
Det här diagrammet visar en typisk virtuell SAP-kunds hubb- och ekernätverk. VPN-gateway som finns i det virtuella SAP RISE-nätverket ansluter via vnet-till-vnet-anslutning till gatewayen som finns i kundens virtuella hubbnätverk.
Även om peering för virtuella nätverk är den rekommenderade och mer typiska distributionsmodellen, kan ett VPN vnet-till-v-nätverk potentiellt förenkla en komplex virtuell peering mellan kunder och virtuella SAP RISE/ECS-nätverk. VPN Gateway fungerar bara som en startpunkt i kundens nätverk och hanteras och skyddas av ett centralt team. Nätverksdataflödet begränsas av den valda gateway-SKU:n på båda sidor. Se till att zonredundanta virtuella nätverksgatewayer används för en sådan anslutning för att uppfylla återhämtningskraven.
Nätverkssäkerhetsgrupper tillämpas på både kundens och SAP:s virtuella nätverk, identiskt med peeringarkitekturen som möjliggör kommunikation till SAP NetWeaver- och HANA-portar efter behov. Kontakta SAP-representanten om du vill ha mer information om hur du konfigurerar VPN-anslutningen och vilka inställningar som ska användas.
Anslut ivitet tillbaka till den lokala miljön
Med en befintlig azure-kunddistribution är det lokala nätverket redan anslutet via ExpressRoute (ER) eller VPN. Samma lokala nätverkssökväg används vanligtvis för SAP RISE/ECS-hanterade arbetsbelastningar. Prioriterad arkitektur är att använda befintliga ER/VPN-gatewayer i kundens för detta ändamål, med anslutna virtuella SAP RISE-nätverk som ses som ett ekernätverk som är anslutet till kundens virtuella nätverkshubb.
Det här diagrammet visar en typisk virtuell SAP-kunds hubb- och ekernätverk. Anslut till lokalt med en anslutning. Peering för virtuella nätverk mellan klientorganisationer ansluter det virtuella SAP RISE-nätverket till kundens hubbnätverk. Peering för virtuella nätverk har fjärrgatewayöverföring aktiverat, vilket gör att det virtuella SAP RISE-nätverket kan nås lokalt.
Med den här arkitekturen gäller även centrala principer och säkerhetsregler för nätverksanslutning till kundarbetsbelastningar för SAP RISE/ECS-hanterade arbetsbelastningar. Samma lokala nätverkssökväg används för både kundens och SAP RISE/ECS virtuella nätverk.
Om det för närvarande inte finns någon lokal azure-anslutning kontaktar du SAP-representanten för information om vilka anslutningsmodeller som är möjliga för RISE-arbetsbelastningen. Om SAP RISE/ECS etablerar lokalt inom RISE direkt är sådan lokal anslutning tillgänglig endast för att nå det SAP-hanterade virtuella nätverket. En sådan dedikerad ExpressRoute- eller VPN-anslutning i SAP RISE kan inte användas för att komma åt kundens egna virtuella Azure-nätverk.
Kommentar
Ett virtuellt nätverk kan bara ha en gateway, lokal eller fjärransluten. När peering för virtuella nätverk upprättas mellan SAP RISE med hjälp av fjärrgatewayöverföring kan inga gatewayer läggas till i det virtuella SAP RISE/ECS-nätverket. En kombination av peering för virtuella nätverk med fjärrgatewayöverföring tillsammans med en annan virtuell nätverksgateway i det virtuella SAP RISE/ECS-nätverket är inte möjlig.
Virtual WAN med SAP RISE-hanterade arbetsbelastningar
På samma sätt som när du använder en nätverksarkitektur för nav och eker med anslutning till både det virtuella SAP RISE/ECS-nätverket och den lokala hubben kan Azure Virtual Wan-hubben (vWAN) användas för samma ändamål. RISE-arbetsbelastningen är ett ekernätverk som är anslutet till vWAN-nätverkshubben. Båda anslutningsalternativen till SAP RISE som beskrevs tidigare – peering för virtuella nätverk samt VPN vnet-to-vnet – är tillgängliga med vWAN.
VWAN-nätverkshubben distribueras och hanteras av kunden i en egen prenumeration. Kunden hanterar också helt den lokala anslutningen och routningen via vWAN-nätverkshubben, med åtkomst till det virtuella SAP RISE-peer-kopplade ekernätverket.
Anslut ivitet under migreringen till SAP RISE
Migreringen av SAP-landskapet till SAP RISE sker i flera faser under flera månader eller längre. Vissa av dina SAP-miljöer migreras redan och används produktivt, medan du förbereder andra SAP-system för migrering. I de flesta kundprojekt migreras de största och mest kritiska systemen i mitten eller i slutet av projektet. Du måste överväga att ha gott om bandbredd för datamigrering eller databasreplikering och inte påverka användarnas nätverkssökväg till de redan produktiva RISE-miljöerna. Redan migrerade SAP-system kan också behöva kommunicera med SAP-landskapet som fortfarande finns lokalt eller hos en befintlig tjänstleverantör.
Under migreringsplaneringen till SAP RISE planerar du hur SAP-system i varje fas kan nås för din användarbas och hur dataöverföring till det virtuella RISE/ECS-nätverket dirigeras. Ofta är flera platser och parter inblandade, till exempel befintlig tjänstleverantör och datacenter med egen anslutning till företagets nätverk. Se till att inga tillfälliga lösningar med VPN-anslutningar skapas utan att fundera på hur SAP-data i senare faser migreras för de mest affärskritiska systemen.
DNS-integrering med SAP RISE/ECS-hanterade arbetsbelastningar
Integrering av kundägda nätverk med molnbaserad infrastruktur och ett sömlöst namnmatchningskoncept är en viktig del av en lyckad projektimplementering. Det här diagrammet beskriver ett av de vanliga integreringsscenarierna för SAP-ägda prenumerationer, virtuella nätverk och DNS-infrastruktur med kundens lokala nätverk och DNS-tjänster. I den här konfigurationen har Azure Hub eller lokala DNS-servrar alla DNS-poster. DNS-infrastrukturen kan matcha DNS-begäranden som kommer från alla källor (lokala klienter, kundens Azure-tjänster och SAP-hanterade miljöer).
Designbeskrivning och detaljer:
Anpassad DNS-konfiguration för SAP-ägda virtuella nätverk
Två virtuella datorer i RISE/PCE Azures virtuella nätverksvärd-DNS-servrar
Kunder måste tillhandahålla och delegera till SAP en underdomän/zon (till exempel ecs.contoso.com) för att tilldela namn och skapa vidarebefordrade och omvända DNS-poster för de virtuella datorer som kör SAP-hanterad miljö. SAP DNS-servrar har en huvud-DNS-roll för den delegerade zonen
DNS-zonöverföring från SAP DNS-server till kundens DNS-servrar är den primära metoden för att replikera DNS-poster från RISE/PCE-miljön.
Kundens virtuella Azure-nätverk använder också anpassad DNS-konfiguration som refererar till kundens DNS-servrar som finns i det virtuella Azure Hub-nätverket.
Alternativt kan kunder konfigurera en privat DNS-vidarebefordrare i sina virtuella Azure-nätverk. En sådan vidarebefordrare skickar sedan DNS-begäranden som kommer från Azure-tjänster till SAP DNS-servrar som är riktade mot den delegerade zonen (till exempel ecs.contoso.com).
DNS-zonöverföring gäller för designen när kunder använder en anpassad DNS-lösning (till exempel AD DS - eller BIND-servrar) i deras virtuella hubbnätverk.
Kommentar
Både azure-tillhandahållna privata DNS- och Azure-zoner stöder inte DNS-zonöverföringsfunktioner, och kan därför inte användas för att acceptera DNS-replikering från SAP RISE/PCE/ECS DNS-servrar. Dessutom stöder SAP vanligtvis inte externa DNS-tjänstleverantörer för den delegerade zonen.
SAP publicerade ett blogginlägg om DNS-implementeringen med SAP RISE i Azure. Mer information finns här.
Mer information om användningen av Azure DNS för SAP finns i mer information i följande blogginlägg utanför användningen med SAP RISE/ECS.
Utgående och inkommande internetanslutningar med SAP RISE/ECS
SAP-arbetsbelastningar som kommunicerar med externa program och gränssnitt kan kräva en utgående nätverkssökväg till Internet. På samma sätt behöver företagets användarbas (till exempel SAP Fiori) ingress eller inkommande internetanslutningar till SAP-landskapet. För SAP RISE-hanterade arbetsbelastningar kan du samarbeta med din SAP-representant för att utforska behoven för sådana https/RFC/andra kommunikationsvägar. Nätverkskommunikation till/från Internet är som standard inte aktiverat för SAP RISE/ECS-kunder och standardnätverk använder endast privata IP-intervall. Internetanslutningen kräver planering med SAP för att optimalt skydda kundens SAP-landskap.
Om du aktiverar internetbunden eller inkommande trafik med SAP RISE skyddas nätverkskommunikationen via olika Azure-tekniker, till exempel NSG:er, ASG:er, Application Gateway med Web Application Firewall (WAF), proxyservrar och andra beroende på användnings- och nätverksprotokoll. Dessa tjänster hanteras helt och hållet via SAP i det virtuella SAP RISE/ECS-nätverket och prenumerationen. Nätverkssökvägen SAP RISE till och från Internet förblir vanligtvis endast inom det virtuella SAP RISE/ECS-nätverket och överförs inte till/från kundens egna virtuella nätverk.
Program i kundens eget virtuella nätverk ansluter till Internet direkt från respektive virtuellt nätverk eller via kundens centralt hanterade tjänster som Azure Firewall, Azure Application Gateway, NAT Gateway med flera. Anslut ivity to SAP BTP from non-SAP RISE/ECS applications takes the same network Internet bound path on your side.Anslut ivity to SAP BTP from non-SAP RISE/ECS applications takes the same network Internet bound path on your side. Om en SAP Cloud Anslut er behövs för en sådan integrering kör du den på kundens virtuella datorer. Med andra ord är SAP BTP eller all offentlig slutpunktskommunikation på en nätverkssökväg som hanteras av kunderna själva om SAP RISE-arbetsbelastningen inte är involverad.
SAP BTP-anslutning
SAP Business Technology Platform (BTP) tillhandahåller en mängd program som vanligtvis används via offentlig IP/värddator via Internet. Kundens tjänster som körs i sina Azure-prenumerationer får åtkomst till BTP via den konfigurerade metoden för utgående åtkomst, till exempel central brandvägg eller utgående offentliga IP-adresser. Vissa SAP BTP-tjänster, till exempel SAP Data Intelligence, används dock avsiktligt via en separat peering för virtuella nätverk i stället för en offentlig slutpunkt.
SAP erbjuder Private Link Service för kunder som använder SAP BTP i Azure. SAP Private Link-tjänsten ansluter SAP BTP-tjänster via ett privat IP-intervall till kundens Azure-nätverk och kan därför nås privat via tjänsten private link i stället för via Internet. Kontakta SAP om du vill ha tillgång till den här tjänsten för SAP RISE/ECS-arbetsbelastningar.
Se SAP:s dokumentation och en serie blogginlägg om arkitekturen för SAP BTP Private Link Service och privata anslutningsmetoder som hanterar DNS och certifikat i följande SAP-bloggserie Komma igång med BTP Private Link Service för Azure.
Nätverkskommunikationsportar med SAP RISE
Alla Azure-tjänster med åtkomst till kundens virtuella nätverk kan kommunicera med SAP-landskapet som körs i SAP RISE/ECS-prenumerationen via de tillgängliga portarna.
Diagram över öppna portar i ett SAP RISE/ECS-system. RFC-anslutningar för BAPI och IDoc, https för OData och Rest/SOAP. ODBC/JDBC för direkta databasanslutningar till SAP HANA. Alla anslutningar via peering för privata virtuella nätverk. Application Gateway med offentlig IP-adress för https som ett potentiellt alternativ som hanteras via SAP.
SAP-systemet i SAP RISE kan nås via de öppna nätverksportarna, som konfigurerats och öppnats av SAP för din användning. https-, RFC- och JDBC/ODBC-protokoll kan användas via privata nätverksadressintervall. Dessutom kan program komma åt via https på en offentligt tillgänglig IP-adress som exponeras av SAP RISE-hanterad Azure-programgateway. Mer information och inställningar för programgatewayen och öppna NSG-portar finns i SAP.
Se ytterligare dokument Integrera Azure-tjänster med SAP RISE hur den tillgängliga anslutningen gör att du kan utöka ditt SAP-landskap med Azure-tjänster.
Nästa steg
Kolla in dokumentationen:
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för