Redigera

Dela via

SAP-landskapsarkitektur

Azure Virtual Machines
Azure Virtual Network
Azure Files
Azure Load Balancer

Den här artikeln innehåller metodtips för att skapa ett helt SAP-landskap i Azure. SAP-landskapet innehåller flera SAP-system i hubb-, produktions-, icke-produktions- och haveriberedskapsmiljöer. Vi ger rekommendationer som fokuserar på nätverksdesign och inte specifika SAP-system. Målet är att ge våra rekommendationer för att skapa ett säkert, högpresterande och motståndskraftigt SAP-landskap.

Arkitektur

Diagram som visar ett exempel på ett övergripande SAP-landskap i Azure.

Ladda ned en Visio-fil med arkitekturen.

Arbetsflöde

  1. Lokalt nätverk: ExpressRoute-anslutning från lokalt nätverk till anslutna Azure-regioner.
  2. Regionala azure-prenumerationshubbar: Azure-prenumeration som innehåller centrala tjänster för hela företaget, inte bara SAP. Hubbprenumerationen tillhandahåller centrala tjänster och anslutningar genom peering till virtuella ekernätverk som innehåller SAP-arbetsbelastningar.
  3. Virtuellt navnätverk: En virtuell nätverksekerare för den centrala hubben i den primära regionen eller regionen A.
  4. Hub virtual network in disaster recovery (DR) region: A virtual network spoke for the central hub in disaster recovery region. Den speglar undernätsdesignen för det virtuella produktionsnätverket i den primära regionen.
  5. Azure-prenumeration sap icke-produktion: En Azure-prenumeration för alla SAP-arbetsbelastningar som inte är produktionsbaserade. Den innehåller miljöer för förproduktion, kvalitetssäkring, utveckling och sandbox-miljö.
  6. Virtuella SAP-nätverk som inte är produktionskritiska: Separata virtuella nätverk för SAP-arbetsbelastningar som inte är produktionsbaserade i den primära regionen. Varje SAP-miljö har ett eget virtuellt nätverk och undernät.
  7. Sap-produktion för Azure-prenumeration: En Azure-prenumeration för alla SAP-arbetsbelastningar för produktion.
  8. Virtuellt SAP-ekernätverk: Ett virtuellt nätverk för SAP-produktionsmiljön med flera undernät. Det här virtuella nätverket finns i den primära regionen.
  9. Virtuellt nätverk för haveriberedskap för SAP-produktion (DR): Ett virtuellt nätverk för SAP-produktion i den sekundära katastrofåterställningsregionen. Den speglar undernätsdesignen för det virtuella produktionsnätverket i den primära regionen.
  10. Azure Services: Ett urval av Azure-tjänster som du kan ansluta till SAP-liggande.
  11. SAP Business Technology Platform (BTP): SAP-miljön får åtkomst till SAP Business Technology Platform via Azure Private Link.

Azure-prenumerationer

Vi rekommenderar att du använder en nätverksdesign för hub-spoke. Med en hub-spoke-design behöver du minst tre prenumerationer för att dela upp dina SAP-miljöer. Du bör ha en prenumeration för de (1) regionala virtuella hubbnätverken, (2) virtuella nätverk som inte är produktionsbaserade och (3) virtuella produktionsnätverk. Prenumerationer tillhandahåller fakturerings-, princip- och säkerhetsgränser. Det finns inget korrekt antal prenumerationer. Hur många prenumerationer du använder beror på dina fakturerings-, princip- och säkerhetsbehov. I allmänhet vill du undvika att använda för många prenumerationer. För många prenumerationer kan lägga till onödiga hanteringskostnader och nätverkskomplexitet. Du behöver till exempel ingen prenumeration för varje SAP-system. Vår arkitektur använder tre prenumerationer:

  • Regionala hubbar: En prenumeration på en virtuell Azure-hubb där det virtuella hubbnätverket finns för de primära och sekundära regionerna. Den här prenumerationen gäller för alla centrala tjänster och inte bara SAP.

  • SAP-icke-produktion: En icke-produktionsprenumeration för Azure SAP där icke-produktionssystem, inklusive sandbox-, utvecklings-, kvalitetssäkrings- eller förproduktionssystem, finns.

  • SAP-produktion: En Azure SAP-produktionsprenumeration där vi konfigurerade produktions- och haveriberedskapssystemen.

Mer information finns i:

Nätverksdesign

En hub-spoke-topologi är den rekommenderade nätverksdesignen för ett SAP-landskap. I den här topologin fungerar det virtuella nätverket för produktionshubben som en central anslutningspunkt. Den ansluter till det lokala nätverket och de olika virtuella ekernätverken och ger användare och program åtkomst till SAP-arbetsbelastningen. I den här hub-spoke-topologin finns här våra rekommendationer för SAP-nätverksdesign.

Använd ExpressRoute för lokal anslutning. För SAP-arbetsbelastningar rekommenderar vi att du använder ExpressRoute för att ansluta det lokala nätverket till det virtuella hubbnätverket och det virtuella hubbnätverket. Du kan använda azure virtual WAN-topologi om du har globala platser. Överväg att konfigurera ett plats-till-plats-VPN (S2S) som en säkerhetskopia till Azure ExpressRoute eller eventuella routningskrav från tredje part.

Mer information finns i:

Använd ett virtuellt nätverk per miljö. Vi rekommenderar att du använder ett virtuellt nätverk per miljö (SAP-distributionsnivå). Arkitekturen använder ett annat virtuellt nätverk för produktion, utveckling, kvalitetssäkring och sandbox-miljö. Den här nätverksdesignen är perfekt för stora företagsarkitekturer.

Använd en central brandvägg. All nätverkstrafik till de virtuella ekernätverken, inklusive RFC-anslutningar (Remote Function Call), bör passera genom en central brandvägg i det virtuella hubbnätverket. Nätverkskommunikation mellan de virtuella ekernätverken (eker-till-eker-kommunikation) passerar via brandväggen för det virtuella hubbnätverket i Azure Firewall-undernätet för det virtuella hubbnätverket. På samma sätt passerar även nätverkskommunikationen mellan de virtuella ekernätverken och det lokala nätverket via brandväggen för det virtuella hubbnätverket. Vi använde peering för virtuella nätverk för att ansluta de olika virtuella ekernätverken till det virtuella hubbnätverket. All kommunikation mellan de virtuella ekernätverken passerar via brandväggen för det virtuella hubbnätverket. Du kan också använda en virtuell nätverksinstallation i stället för en brandvägg. Mer information finns i virtuell nätverksinstallation.

Nätverkstrafik som finns kvar i ett virtuellt nätverk ska inte passera genom en brandvägg. Placera till exempel inte en brandvägg mellan SAP-programmets undernät och SAP-databasundernätet. Det stöds inte att placera en brandvägg eller virtuella nätverksinstallationer (NVA) mellan SAP-programmet och databashanteringssystemets (DBMS) lager av SAP-system som kör SAP-kerneln. Om du gör det påverkas nätverksfördröjningen negativt för alla databasåtkomster och sap-prestandan påverkas kraftigt.

Undvik virtuella peering-ekernätverk. Peering av virtuella nätverk mellan de virtuella ekernätverken bör undvikas om möjligt. Med peering för eker-till-eker-nätverk kan eker-till-eker-kommunikation kringgå brandväggen för det virtuella nätverket på hubben. Du bör bara konfigurera peering för eker-till-eker-virtuella nätverk när du har krav på hög bandbredd, till exempel med databasreplikering mellan SAP-miljöer. All annan nätverkstrafik ska köras via det virtuella hubbnätverket och brandväggen. Mer information finns i inkommande och utgående Internetanslutningar för SAP på Azure.

Undernät

Det är bästa praxis att dela upp varje SAP-miljö (produktion, förproduktion, utveckling, sandbox-miljö) i undernät och att använda undernät för att gruppera relaterade tjänster. Här är våra rekommendationer för att underordna ett SAP-landskap.

Antal undernät

Det virtuella produktionsnätverket i arkitekturen har fem undernät. Den här designen är perfekt för stora företagslösningar. Antalet undernät kan vara mindre eller mer. Antalet resurser i det virtuella nätverket ska bestämma antalet undernät i det virtuella nätverket.

Storlek på undernät

Kontrollera att undernäten har tillräckligt med nätverksadressutrymme. Om du använder virtuella SAP-värdnamn behöver du mer adressutrymme i dina SAP-undernät. Ofta kräver varje SAP-instans 2–3 IP-adresser och innehåller en IP-adress för den virtuella datorns värdnamn. Andra Azure-tjänster kan kräva ett eget dedikerat undernät när de distribueras i de virtuella SAP-arbetsbelastningsnätverken.

Programundernät

Programundernätet innehåller virtuella datorer som kör SAP-programservrar, SAP Central Services (ASCS), SAP Enqueue Replication Services (ERS) och SAP Web Dispatcher-instanser. Undernätet innehåller också en privat slutpunkt till Azure Files. I diagrammet grupperade vi de virtuella datorerna efter roll. Vi rekommenderar att du använder vm-skalningsuppsättningar med flexibel orkestrering i kombination med tillgänglighetszoner för elastisk distribution. Mer information finns i nästa steg.

Databasundernät

Databasundernätet innehåller virtuella datorer som kör databaser. I diagrammet representerar ett par virtuella datorer med synkron replikering alla virtuella databasdatorer i en SAP-miljö.

Perimeterundernät

Perimeterundernät är internetuppkopplade och innehåller ett SAP-perimeterundernät och ett Application Gateway-undernät. Här är våra rekommendationer för att utforma dessa två undernät.

SAP-perimeterundernät: SAP-perimeterundernätet är ett perimeternätverk som innehåller internetanslutna program som SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent och Application Gateway. Dessa tjänster har beroenden för SAP-system som ett SAP-team ska distribuera, hantera och konfigurera. Ett centralt IT-team bör inte hantera tjänsterna i SAP-perimeterundernätet. Därför bör du placera dessa tjänster i det virtuella SAP-ekernätverket och inte i det virtuella hubbnätverket. Arkitekturdiagrammet visar bara ett SAP-perimeternätverk för produktion. Det har inget SAP-perimeterundernät i de virtuella nätverk som inte är produktionsbaserade. Arbetsbelastningarna i den icke-produktionsbaserade SAP-prenumerationen använder tjänsterna i SAP-perimeterundernätet.

Du kan skapa ett separat SAP-perimeterundernät i en icke-produktionsprenumeration. Vi rekommenderar bara den här metoden för kritiska arbetsbelastningar eller arbetsbelastningar som ändras ofta. En dedikerad SAP-perimeter som inte är produktionsbaserad är användbar för testning och distribution av nya funktioner. Mindre kritiska program eller program som bara har få ändringar över tid behöver inte ett separat SAP-perimeterundernät som inte är produktionsbaserat.

Application Gateway-undernät: Azure Application Gateway kräver ett eget undernät. Använd den för att tillåta trafik från Internet som SAP-tjänster, till exempel SAP Fiori, kan använda. Den rekommenderade arkitekturen placerar Azure Application Gateway tillsammans med den offentliga IP-adressen för klientdelen i det virtuella hubbnätverket. En Azure Application Gateway kräver minst ett /29-storleksundernät. Vi rekommenderar storlek /27 eller större. Du kan inte använda båda versionerna av Application Gateway (v1 och v2) i samma undernät. Mer information finns i undernätet för Azure Application Gateway.

Placera perimeterundernät i ett separat virtuellt nätverk för ökad säkerhet: För ökad säkerhet kan du placera SAP-perimeterundernätet och Application Gateway-undernätet i ett separat virtuellt nätverk i SAP-produktionsprenumerationen. Det virtuella SAP Perimeter Spoke-nätverket peerkopplas med det virtuella hubbnätverket och all nätverkstrafik till offentliga nätverk flödar via det virtuella perimeternätverket. Den här alternativa metoden visar Azure Application Gateway med sin offentliga IP-adress för inkommande anslutningar som placeras i ett virtuellt ekernätverk för SAP-användning exklusivt.

Diagram som visar nätverksflödet mellan virtuella nätverksekrar via det virtuella hubbnätverket.

Ladda ned en Visio-fil med den här alternativa arkitekturen.

Den här nätverksdesignen ger bättre funktioner för incidenthantering och detaljerad nätverksåtkomstkontroll. Men det ökar även hanteringskomplexiteten, nätverksfördröjningen och kostnaden för distributionen. Låt oss diskutera varje punkt.

Bättre incidenthantering: Det virtuella SAP-perimeternätverket tillåter snabb isolering av komprometterade tjänster om du upptäcker ett intrång. Du kan ta bort peering för virtuella nätverk från det virtuella SAP-perimeternätverket till hubben och omedelbart isolera SAP-perimeterarbetsbelastningarna och sap-programmets virtuella nätverksprogram från Internet. Du vill inte förlita dig på ändringar av NSG-regler (Network Security Group) för incidenthantering. Att ändra eller ta bort en NSG-regel påverkar bara nya anslutningar och minskar inte befintliga skadliga anslutningar.

Detaljerad nätverksåtkomstkontroll: Det virtuella SAP-perimeternätverket ger strängare nätverksåtkomstkontroll till och från det virtuella SAP-produktionsnätverket.

Ökad komplexitet, svarstid och kostnad: Arkitekturen ökar hanteringskomplexiteten, kostnaden och svarstiden. Internetbunden kommunikation från det virtuella SAP-produktionsnätverket peerkopplas två gånger, en gång till det virtuella hubbnätverket och igen till det virtuella SAP-perimeternätverket ut till Internet. Brandväggen i det virtuella hubbnätverket har störst effekt på svarstiden. Vi rekommenderar att du mäter svarstiden för att se om ditt användningsfall kan stödja det.

Mer information finns i metodtips för perimeternätverk.

Azure NetApp Files-undernät

Om du använder NetApp Files bör du ha ett delegerat undernät för att tillhandahålla NFS-filresurser (Network File System) eller SMB-filresurser (Server Message Block) för olika SAP i Azure-scenarier. Ett /24-undernät är standardstorleken för ett NetApp Files-undernät, men du kan ändra storleken för att uppfylla dina behov. Använd dina egna krav för att fastställa rätt storlek. Mer information finns i delegerat undernät.

Säkerhet för undernät

Om du använder undernät för att gruppera SAP-resurser som har samma säkerhetskrav blir det enklare att hantera säkerheten.

Nätverkssäkerhetsgrupper (NSG): Med undernät kan du implementera nätverkssäkerhetsgrupper på undernätsnivå. Gruppering av resurser i samma undernät som kräver olika säkerhetsregler kräver nätverkssäkerhetsgrupper på undernätsnivå och nätverksgränssnittsnivå. Med den här konfigurationen på två nivåer står säkerhetsreglerna lätt i konflikt och kan orsaka oväntade kommunikationsproblem som är svåra att felsöka. NSG-regler påverkar även trafik i undernätet. Mer information om nätverkssäkerhetsgrupper finns i nätverkssäkerhetsgrupper.

Programsäkerhetsgrupper (ASG): Vi rekommenderar att du använder programsäkerhetsgrupper för att gruppera nätverksgränssnitt för virtuella datorer och referera till programsäkerhetsgrupperna i reglerna för nätverkssäkerhetsgruppen. Den här konfigurationen gör det enklare att skapa och hantera regler för SAP-distributioner. Varje nätverksgränssnitt kan tillhöra flera programsäkerhetsgrupper med olika regler för nätverkssäkerhetsgrupper. Mer information finns i programsäkerhetsgrupper.

Vi rekommenderar att du använder Azure Private Link för att förbättra säkerheten för nätverkskommunikation. Azure Private Link använder privata slutpunkter med privata IP-adresser för att kommunicera med Azure-tjänster. Azure Private Links undviker att skicka nätverkskommunikation via Internet till offentliga slutpunkter. Mer information finns i privata slutpunkter för Azure-tjänster.

Använd privata slutpunkter i programundernätet: Vi rekommenderar att du använder privata slutpunkter för att ansluta programmets undernät till Azure-tjänster som stöds. I arkitekturen finns det en privat slutpunkt för Azure Files i programundernätet för varje virtuellt nätverk. Du kan utöka det här konceptet till alla Azure-tjänster som stöds.

Använd Azure Private Link för SAP Business Technology Platform (BTP): Azure Private Link för SAP Business Technology Platform (BTP) är nu allmänt tillgänglig. SAP Private Link Service stöder anslutningar från SAP BTP, Cloud Foundry-körningen och andra tjänster. Exempelscenarier är SAP S/4HANA eller SAP ERP som körs på den virtuella datorn. De kan ansluta till azure-interna tjänster som Azure Database for MariaDB och Azure Database for MySQL.

Arkitekturen visar en SAP Private Link Service-anslutning från SAP BTP-miljöer. SAP Private Link Service upprättar en privat anslutning mellan specifika SAP BTP-tjänster och specifika tjänster i varje nätverk som tjänstleverantörskonton. Med privat länk kan BTP-tjänster komma åt DIN SAP-miljö via privata nätverksanslutningar. Det förbättrar säkerheten genom att inte använda det offentliga Internet för att kommunicera.

Mer information finns i:

Filresurser för nätverksfilsystem (NFS) och servermeddelandeblock (SMB)

SAP-system är ofta beroende av nätverksfilsystemvolymer eller servermeddelandeblockresurser. Dessa filresurser flyttar filer mellan virtuella datorer eller fungerar som ett filgränssnitt med andra program. Vi rekommenderar att du använder inbyggda Azure-tjänster, till exempel Azure Premium Files och Azure NetApp Files, som nätverksfilsystem (NFS) och SMB-filresurser (Server Message Block). Azure-tjänster har bättre kombinerad tillgänglighet, motståndskraft och serviceavtal (SLA) än operativsystembaserade verktyg.

Mer information finns i:

När du skapar din SAP-lösning måste du storleksanpassa enskilda filresursvolymer korrekt och veta vilken SAP-systemfilresurs som ansluter till. Tänk på skalbarhets- och prestandamål för Azure-tjänsten under planeringen. Följande tabell beskriver vanliga SAP-filresurser och ger en kort beskrivning och rekommenderad användning i en hel SAP-miljö.

Filresursnamn Förbrukning Rekommendation
sapmnt Distribuerade SAP-system, profiler och globala kataloger Dedikerad resurs för varje SAP-system, ingen återanvändning
cluster Resurser med hög tillgänglighet för ASCS, ERS och databas per respektive design Dedikerad resurs för varje SAP-system, ingen återanvändning
saptrans SAP-transportkatalog En resurs för ett eller några SAP-landskap (ERP, Business Warehouse)
interface Filutbyte med icke-SAP-program Kundspecifika krav, separata filresurser per miljö (produktion, icke-produktion)

Du kan bara dela saptrans mellan olika SAP-miljöer, och därför bör du noga överväga dess placering. Undvik att konsolidera för många SAP-system i en saptrans resurs av skalbarhets- och prestandaskäl.

Företagets säkerhetsprinciper kommer att driva arkitekturen och separationen av volymer mellan miljöer. En transportkatalog med separation per miljö eller nivå behöver RFC-kommunikation mellan SAP-miljöer för att tillåta SAP-transportgrupper eller transportdomänlänkar. Mer information finns i:

Datatjänster

Arkitekturen innehåller Azure-datatjänster som hjälper dig att utöka och förbättra din SAP-dataplattform. För att hjälpa dig att låsa upp affärsinsikter rekommenderar vi att du använder tjänster som Azure Synapse Analytics, Azure Data Factory och Azure Data Lake Storage. Dessa datatjänster hjälper dig att analysera och visualisera SAP-data och icke-SAP-data.

För många dataintegreringsscenarier krävs en integreringskörning. Azure Integration Runtime är den beräkningsinfrastruktur som Azure Data Factory och Azure Synapse Analytics-pipelines använder för att tillhandahålla dataintegreringsfunktioner. Vi rekommenderar distribution av virtuella runtime-datorer för dessa tjänster för varje miljö separat. Mer information finns i:

Delade tjänster

SAP-lösningar förlitar sig på delade tjänster. Lastbalanserare och programgatewayer är exempel på tjänster som flera SAP-system använder. Arkitekturen men organisationens behov bör avgöra hur du skapar dina delade tjänster. Här är allmänna riktlinjer som du bör följa.

Lastbalanserare: Vi rekommenderar en lastbalanserare per SAP-system. Den här konfigurationen hjälper till att minimera komplexiteten. Du vill undvika för många pooler och regler på en enda lastbalanserare. Den här konfigurationen säkerställer också att namngivning och placering överensstämmer med SAP-systemet och resursgruppen. Varje SAP-system med en klustrad arkitektur med hög tillgänglighet (HA) bör ha minst en lastbalanserare. Arkitekturen använder en lastbalanserare för de virtuella ASCS-datorerna och en andra lastbalanserare för de virtuella databasdatorerna. Vissa databaser kanske inte kräver lastbalanserare för att skapa en distribution med hög tillgänglighet. SAP HANA gör det. Mer information finns i den databasspecifika dokumentationen.

Application Gateway: Vi rekommenderar minst en programgateway per SAP-miljö (produktion, icke-produktion och sandbox-miljö) om inte komplexiteten och antalet anslutna system är för högt. Du kan använda en programgateway för flera SAP-system för att minska komplexiteten eftersom inte alla SAP-system i miljön kräver inkommande åtkomst från Internet. En enda programgateway kan hantera flera web dispatcher-portar för ett enda SAP S/4HANA-system eller användas av olika SAP-system.

Virtuella SAP Web Dispatcher-datorer: Arkitekturen visar en pool med två eller flera virtuella SAP Web Dispatcher-datorer. Vi rekommenderar att du inte återanvänder virtuella SAP Web Dispatcher-datorer mellan olika SAP-system. Om du håller dem åtskilda kan du ändra storleken på de virtuella web dispatcher-datorerna så att de uppfyller behoven för varje SAP-system. För mindre SAP-lösningar rekommenderar vi att du bäddar in Web Dispatcher-tjänsterna i ASCS-instansen.

SAP-tjänster: SAP-tjänster som SAProuter, Cloud Connector och Analytics Cloud Agent distribueras baserat på programkrav, antingen centralt eller uppdelat. Ingen rekommendation om återanvändning mellan SAP-system på grund av olika kundkrav. Huvudbeslutet att fatta nämns i avsnittet om nätverk, om och när SAP-perimeterundernät för icke-produktion ska användas. I annat fall används SAP-perimetertjänsterna av hela SAP-landskapet med bara ett undernät för produktionsperimeter för SAP.

Haveriberedskap

Haveriberedskap (DR) åtgärdar kravet på affärskontinuitet om den primära Azure-regionen inte är tillgänglig eller komprometteras. Från ett övergripande SAP-landskapsperspektiv och som visas i diagrammet, här är våra rekommendationer för haveriberedskapsdesign.

Använd olika IP-adressintervall Virtuella nätverk sträcker sig bara över en enda Azure-region. Alla lösningar för haveriberedskap bör använda en annan region. Du måste skapa ett annat virtuellt nätverk i den sekundära regionen. Det virtuella nätverket i DR-miljön behöver ett annat IP-adressintervall för att aktivera databassynkronisering via databasbaserad teknik.

Centrala tjänster och anslutningar till lokalt: Anslutningar till lokala och viktiga centrala tjänster (DNS eller brandväggar) måste vara tillgängliga i haveriberedskapsregionen. Tillgänglighet och ändringskonfiguration för de centrala IT-tjänsterna måste vara en del av din haveriberedskapsplan. Centrala IT-tjänster är viktiga komponenter för en fungerande SAP-miljö.

Använd Azure Site Recovery Azure Site Recovery replikerar och skyddar hanterade diskar och konfigurationer av virtuella datorer för programservrar till DR-regionen.

Se till att filresursen är tillgänglig: SAP beror på tillgängligheten för nyckelfilresurser. Säkerhetskopiering eller kontinuerlig filresursreplikering krävs för att tillhandahålla data på dessa filresurser med minimal dataförlust i DR-scenariot.

Databasreplikering Azure Site Recovery kan inte skydda SAP-databasservrar på grund av den höga ändringsfrekvensen och bristen på databasstöd från tjänsten. Du måste konfigurera kontinuerlig och asynkron databasreplikering till haveriberedskapsregionen.

Mer information finns i översikt över haveriberedskap och riktlinjer för infrastruktur för SAP-arbetsbelastningar.

Mindre SAP-arkitektur

För mindre SAP-lösningar kan det vara fördelaktigt att förenkla nätverksdesignen. Varje SAP-miljös virtuella nätverk skulle sedan vara undernät i ett sådant kombinerat virtuellt nätverk. Alla förenklingar av nätverks- och prenumerationsdesignbehov kan påverka säkerheten. Du bör omvärdera nätverksroutning, åtkomst till och från offentliga nätverk, åtkomst till delade tjänster (filresurser) och åtkomst till andra Azure-tjänster. Här följer några alternativ för att krympa arkitekturen för att bättre uppfylla organisationens behov.

Kombinera SAP-programmet och databasundernäten till ett. Du kan kombinera program- och databasundernäten för att skapa ett stort SAP-nätverk. Den här nätverksdesignen speglar många lokala SAP-nätverk. Kombinationen av dessa två undernät kräver högre uppmärksamhet på undernätssäkerhet och gruppregler för nätverkssäkerhet. Programsäkerhetsgrupper är viktiga när du använder ett enda undernät för SAP-program och databasundernät.

Kombinera SAP-perimeterundernät och programundernät. Du kan kombinera perimeterundernätet och SAP-programundernätet. En ökad uppmärksamhet måste läggas på regler för nätverkssäkerhetsgrupper och användning av programsäkerhetsgrupp. Vi rekommenderar bara den här förenklingsmetoden för små SAP-egendomar.

Kombinera virtuella SAP-ekernätverk mellan olika SAP-miljöer Arkitekturen använder olika virtuella nätverk för varje SAP-miljö (hubb, produktion, icke-produktion och haveriberedskap). Beroende på storleken på ditt SAP-landskap kan du kombinera virtuella SAP-ekernätverk till färre eller till och med bara en SAP-eker. Du måste fortfarande dela upp mellan produktions- och icke-produktionsmiljöer. Varje SAP-produktionsmiljö blir ett undernät i ett virtuellt SAP-produktionsnätverk. Varje SAP-miljö som inte är produktionsmiljö blir ett undernät i ett virtuellt SAP-nätverk som inte är produktionsbaserat.

Deltagare

Microsoft underhåller den här artikeln. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Nästa steg