Dela via

Nätverkstopologi och anslutning för en SAP-migrering

  • Artikel

Den här artikeln bygger på de överväganden och rekommendationer som definieras i designområdet för Azure-landningszoner för nätverkstopologi och anslutning. Vägledningen i den här artikeln undersöker viktiga designöverväganden och metodtips för nätverk och anslutning till, från och inom Microsoft Azure- och SAP-distributioner. Eftersom SAP är en verksamhetskritisk plattform bör din design också följa riktlinjerna för designområden för Azure-landningszoner.

Planera för IP-adressering

En plan för IP-adressering i Azure är viktig för att säkerställa att:

  • IP-adressutrymmet överlappar inte lokala platser och Azure-regioner.
  • Det virtuella nätverket innehåller rätt adressutrymme.
  • Konfigurationsplaner för undernät sker i förväg.

Följande arkitekturdiagram visar nätverksöverväganden i SAP på en Accelerator för Azure-landningszoner:

Ett diagram över nätverksöverväganden i SAP på en Azure-accelerator för landningszoner.

Designöverväganden för SAP-implementering:

Du kan dedikera och delegera undernät till vissa tjänster och sedan skapa instanser av dessa tjänster i dessa undernät. Även om Azure hjälper dig att skapa flera delegerade undernät i ett virtuellt nätverk kan du bara ha ett delegerat undernät i ett virtuellt nätverk för Azure NetApp Files. Om du använder mer än ett delegerat undernät för Azure NetApp Files kan du inte skapa en ny volym.

Användningsfall:

Du behöver delegerade undernät för att implementera Azure NetApp Files. Den här metoden är populär för SAP-distributioner som delar filsystem. Du behöver endast ett delegerat undernät för en programgateway vid belastningsutjämning eller för SAP BusinessObjects Business Intelligence, som är en belastningsutjämnings-SAP-webbprogramserver.

Konfigurera DNS och namnmatchning för lokala resurser och Azure-resurser

Domain Name System (DNS) är en viktig del av Azure-landningszonens arkitektur. Vissa organisationer kanske vill använda sina befintliga investeringar i DNS. Andra kan se molnimplementering som en möjlighet att modernisera sin interna DNS-infrastruktur och använda inbyggda Azure-funktioner.

Designrekommendationer för SAP-implementering:

Använd följande användningsfallsrekommendationer när en virtuell dators DNS-namn eller virtuella namn inte ändras under migreringen.

Användningsfall:

  • Bakgrunds-DNS och virtuella namn ansluter många systemgränssnitt i SAP-liggande, och kunderna är bara ibland medvetna om de gränssnitt som utvecklare definierar över tid. Anslut ionsutmaningar uppstår mellan system när virtuella namn eller DNS-namn ändras efter migreringar. För enkelhetens skull rekommenderar vi att du behåller DNS-alias.

  • Använd olika DNS-zoner för att skilja varje miljö, inklusive sandbox-, utvecklings-, förproduktions- och produktionsmiljöer, från varandra. Ett undantag är för SAP-distributioner som har ett eget virtuellt nätverk. I det här scenariot kanske privata DNS-zoner inte är nödvändiga.

Definiera en Azure-nätverkstopologi

Landningszoner i företagsskala stöder två nätverkstopologier. En topologi baseras på Azure Virtual WAN. Den andra är en traditionell nätverkstopologi som baseras på en hub-and-spoke-arkitektur. I det här avsnittet beskrivs rekommenderade SAP-konfigurationer och metoder för båda distributionsmodellerna.

Använd en nätverkstopologi baserad på Virtual WAN om din organisation planerar att:

  • Distribuera resurser i flera Azure-regioner och anslut dina globala platser till både Azure och lokala miljöer.
  • Integrera programvarudefinierade WAN-distributioner fullständigt med Azure.
  • Distribuera upp till 2 000 arbetsbelastningar för virtuella datorer i alla virtuella nätverk som är anslutna till en Virtuell WAN-hubb.

Organisationer använder Virtual WAN för att uppfylla storskaliga krav på sammankoppling. Microsoft hanterar den här tjänsten, vilket minskar den övergripande nätverkskomplexiteten och moderniserar organisationens nätverk.

Använd en traditionell Azure-nätverkstopologi baserad på en hub-and-spoke-arkitektur om din organisation:

  • Planer på att distribuera resurser i endast azure-regioner.
  • Behöver inte ett globalt, sammankopplat nätverk.
  • Har få fjärr- eller grenplatser per region och behöver färre än 30 IPSec-tunnlar (Internet Protocol Security).
  • Kräver fullständig kontroll och kornighet för att konfigurera ditt Azure-nätverk manuellt.

Designrekommendationer för SAP-implementering:

  • Använd Virtual WAN för Azure-distributioner i nya, stora eller globala nätverk där du behöver global överföringsanslutning mellan Azure-regioner och lokala platser. Med den här metoden behöver du inte konfigurera transitiv routning för Azure-nätverk manuellt, och du kan följa en standard för SAP i Azure-distributioner.

  • Överväg att distribuera virtuella nätverksinstallationer (NVA) mellan regioner endast om du använder partner-NVA:er. NVA:er mellan regioner eller virtuella nätverk krävs inte om inbyggda NVA:er finns. När du distribuerar partnernätverkstekniker och NVA:er följer du leverantörens vägledning för att identifiera motstridiga konfigurationer med Azure-nätverk.

  • Virtual WAN hanterar anslutningen mellan virtuella ekernätverk för Virtual WAN-baserade topologier, så du behöver inte konfigurera användardefinierade vägar (UDR) eller NVA:er. Maximalt nätverksdataflöde för nätverks-till-nätverk-trafik i samma virtuella hubb är 50 Gbit/s. För att övervinna den här bandbreddsbegränsningen kan SAP-landningszoner använda peering för virtuella nätverk för att ansluta till andra landningszoner.

  • Ingen av topologierna stöder NVA-distributioner mellan ett SAP-program och en databasserver.

  • Peering för lokala och globala virtuella nätverk ger anslutning och är de bästa metoderna för att säkerställa anslutning mellan landningszoner för SAP-distributioner i flera Azure-regioner.

Planera för inkommande och utgående Internetanslutning

I det här avsnittet beskrivs rekommenderade anslutningsmodeller för inkommande och utgående anslutning till och från det offentliga Internet. Azure-interna nätverkssäkerhetstjänster som Azure Firewall, Azure Web Application Firewall på Azure Application Gateway och Azure Front Door är fullständigt hanterade tjänster, så du ådrar dig inte de drift- och hanteringskostnader som är associerade med infrastrukturdistributioner.

Designrekommendationer för SAP-implementering:

  • För kunder som har ett globalt fotavtryck underlättar Azure Front Door SAP-distributioner med hjälp av brandväggsprinciper för webbaserade program för att leverera och skydda globala HTTP- och HTTPS-program i Azure-regioner.

  • Dra nytta av brandväggsprinciper för webbprogram i Azure Front Door när du använder Azure Front Door och Application Gateway för att skydda HTTP- och HTTPS-program. Blockera trafik till Application Gateway så att den endast tar emot trafik från Azure Front Door.

  • Application Gateway och Brandvägg för webbaserade program har begränsningar när Application Gateway fungerar som en omvänd proxy för SAP-webbappar. Eftersom SAP Web Dispatcher och NetScaler är mer intelligenta än Application Gateway måste du göra omfattande tester om du ersätter dem med Application Gateway. Kontrollera den senaste statusen och visa en lista över alla scenarier som stöds, som inte stöds, testas och inte testas om möjligt.

  • Använd en brandvägg för webbprogram för att genomsöka trafiken när den exponeras för Internet. Ett annat alternativ är att använda den med lastbalanseraren eller med resurser, till exempel Application Gateway eller lösningar från tredje part, som har inbyggda brandväggsfunktioner.

  • För att förhindra dataläckage använder du Azure Private Link för att på ett säkert sätt komma åt PaaS-resurser (Plattform som en tjänst) som Azure Blob Storage, Azure Files, Azure Data Lake Storage Gen2 och Azure Data Factory. Privata slutpunkter kan också hjälpa till att skydda trafiken mellan virtuella nätverk och tjänster som Azure Storage och Azure Backup. Trafik mellan ditt virtuella nätverk och den privata slutpunktsaktiverade tjänsten färdas över det globala Microsoft-nätverket, vilket förhindrar att den exponeras för det offentliga Internet.

Implementera Azure ExpressRoute med hög tillgänglighet

Azure ExpressRoute är utformat för hög tillgänglighet för att tillhandahålla privata nätverksanslutningar i transportföretagsklass till Microsoft-resurser. Det finns ingen enskild felpunkt i ExpressRoute-sökvägen i Microsoft-nätverket. För att maximera tillgängligheten bör kunden och tjänsteleverantörssegmentet i ExpressRoute-kretsen också byggas för hög tillgänglighet.

Designrekommendationer för SAP-implementeringar:

Definiera krav för nätverkskryptering

I det här avsnittet beskrivs viktiga rekommendationer för att kryptera nätverk mellan lokala miljöer och Azure-miljöer och mellan Azure-regioner.

Designöverväganden för SAP-implementeringar:

  • Trafiken krypteras inte som standard när du använder ExpressRoute för att konfigurera privat peering.

  • Du behöver inte kryptera trafik via ExpressRoute för SAP-distributioner. SAP-trafik förbrukar vanligtvis mycket bandbredd och är känslig för prestanda. IPSec-tunnlar krypterar internettrafik som standard, och kryptering eller dekryptering kan påverka trafikens prestanda negativt.

  • Kunden avgör om SAP-trafik ska krypteras. Mer information om alternativ för nätverkskryptering i landningszoner i företagsskala finns i Nätverkstopologi och anslutning.

Separera system

Det finns olika miljöer, inklusive utvecklings-, testnings-, kvalitets-, förproduktions- och produktionsmiljöer, i ett SAP-scenario, och kunderna tenderar att kategorisera dessa system i logiska eller fysiska konstruktioner för att upprätthålla säkerhets- och efterlevnadsstandarder. Tanken är att hantera alla system som har samma livscykel i en gemensam resursgrupp. Du kan definiera dessa grupper på olika nivåer, till exempel på prenumerations- eller resursgruppsnivå.

Din organisation bör också överväga säkerhets- och principstrukturen när du grupperar resurser i ett SAP-landskap. Men för att SAP-transporter ska kunna flöda mellan utvecklings-, testnings-, kvalitets- och produktionsmiljöer kan din organisation behöva:

  • Peering för virtuella nätverk.
  • Brandväggsportöppningar mellan virtuella nätverk.
  • UDR- och NSG-regler (Network Security Group).

Vi rekommenderar inte att du är värd för databashanteringssystemet (DBMS) och programskikten för SAP-system i olika virtuella nätverk och ansluter dem med hjälp av peering för virtuella nätverk. Överdriven nätverkstrafik mellan lagren kan tillföra betydande kostnader.

Ytterligare rekommendationer för SAP-implementeringar:

  • Ingen av topologierna stöder placering av SAP-programskiktet och SAP DBMS i olika virtuella Azure-nätverk som inte är peer-kopplade.

  • Du kan använda programsäkerhetsgrupp (ASG) och NSG-regler för att definiera åtkomstkontrollistor för nätverkssäkerhet mellan SAP-programmet och DBMS-lagren. Du kan lägga till virtuella datorer i ASG:er för att hantera deras säkerhet.

  • Aktivera accelererat Azure-nätverk på de virtuella datorer som du använder i SAP-programmet och DBMS-lagren. Följande operativsystemnivåer stöder accelererat nätverk i Azure:

    • Windows Server 2012 R2 eller senare
    • SUSE Linux Enterprise Desktop 12 SP3 eller senare
    • Red Hat Enterprise Linux 7.4 eller senare
    • Oracle Linux 7.5
      • Kerneln som är kompatibel med Red Hat Enterprise Linux kräver version 3.10.0-862.13.1.el7.
      • Oracle Unbreakable Enterprise Kernel kräver version 5.

  • Se till att du konfigurerar interna distributioner för Azure Load Balancer för att använda direktserverns returfunktion. Den här funktionen minskar svarstiden när du använder interna lastbalanseringskonfigurationer för konfigurationer med hög tillgänglighet på DBMS-lagret.

  • Om du använder Load Balancer med Linux-gästoperativsystem kontrollerar du att Linux-nätverksparametern net.ipv4.tcp_timestamps är inställd på 0.

  • För optimal nätverksfördröjning med SAP-program bör du överväga att använda närhetsplaceringsgrupper i Azure.

  • För migreringsprojekt bör du överväga att justera nätverksparametrarna. Du kan till exempel förbättra prestanda genom att inaktivera bekräftelser under migreringsperioden.

  • Utforska SAP-supportportalen och SAP Note-2391465 för att lära dig mer om att implementera SAP.

Designöverväganden för RISE-implementeringar

När du kör SAP RISE-distributioner i Azure är integreringen av den SAP-hanterade miljön med ditt eget Azure-ekosystem av största vikt. Mer information om metodtips och vägledning finns i Integrera Azure med SAP RISE-hanterade arbetsbelastningar.

SAP RISE-implementeringen har vanligtvis två alternativ för anslutning: ett plats-till-plats-VPN eller peering för virtuella nätverk. Om du inte har några tidigare Azure-arbetsbelastningar kan ett plats-till-plats-VPN vara det enklare alternativet. Men om du vill använda Azure som en strategisk plattform kan du konfigurera en lämplig Azure-landningszon och använda peering för virtuella nätverk till SAP RISE-klientorganisationen. I dessa scenarier kan en förenklad landningszon som Azure-landningszonen vara ett bra alternativ. Du kan enkelt anpassa den här färdiga distributionsupplevelsen efter dina behov, särskilt de virtuella nätverksparametrarna.

Att distribuera peering mellan klientorganisationer för virtuella nätverk till SAP RISE-klientorganisationen kräver också mer arbete. Du måste planera arkitekturen för virtuella nätverk noggrant för att säkerställa att det inte finns några överlappande klasslösa routningsintervall mellan domäner. Du måste också ha en korrekt peer-DNS till SAP RISE-klientorganisationen.

Överväg begränsningarna och begränsningarna om du bestämmer dig för att konfigurera en Virtual WAN-lösning och behöver plats-till-plats-VPN- eller ExpressRoute-anslutningar.