Netwerktopologie en connectiviteit voor een SAP-migratie
Dit artikel is gebaseerd op de overwegingen en aanbevelingen die zijn gedefinieerd in het ontwerpgebied van de Azure-landingszone voor netwerktopologie en -connectiviteit. In de richtlijnen in dit artikel worden belangrijke ontwerpoverwegingen en aanbevolen procedures besproken voor netwerken en connectiviteit met, vanuit en binnen Microsoft Azure- en SAP-implementaties. Omdat SAP een bedrijfskritiek platform is, moet uw ontwerp ook de richtlijnen volgen op ontwerpgebieden van de Azure-landingszone.
IP-adressering plannen
Een plan voor IP-adressering in Azure is essentieel om ervoor te zorgen dat:
- De IP-adresruimte overlapt niet on-premises locaties en Azure-regio's.
- Het virtuele netwerk bevat de juiste adresruimte.
- Subnetconfiguratieplannen worden vooraf uitgevoerd.
In het volgende architectuurdiagram ziet u aandachtspunten voor netwerken in SAP in een Azure-landingszoneversneller:
Ontwerpoverwegingen voor SAP-implementatie:
U kunt subnetten toewijzen en delegeren aan bepaalde services en vervolgens exemplaren van deze services binnen die subnetten maken. Hoewel Azure u helpt bij het maken van meerdere gedelegeerde subnetten in een virtueel netwerk, kunt u slechts één gedelegeerd subnet in een virtueel netwerk voor Azure NetApp Files hebben. Als u meer dan één gedelegeerd subnet voor Azure NetApp Files gebruikt, kunt u geen nieuw volume maken.
Use case:
U hebt gedelegeerde subnetten nodig om Azure NetApp Files te implementeren. Deze methode is populair voor SAP-implementaties die bestandssystemen delen. U hebt alleen een gedelegeerd subnet nodig voor een toepassingsgateway tijdens taakverdeling of voor SAP BusinessObjects Business Intelligence, een taakverdeling voor SAP-webtoepassingsserver.
DNS- en naamomzetting configureren voor on-premises en Azure-resources
Domain Name System (DNS) is een essentieel onderdeel van de Architectuur van de Azure-landingszone. Sommige organisaties willen mogelijk hun bestaande investeringen in DNS gebruiken. Anderen kunnen de overstap naar de cloud zien als een mogelijkheid om hun interne DNS-infrastructuur te moderniseren en systeemeigen Azure-mogelijkheden te gebruiken.
Ontwerpaan aanbevelingen voor SAP-implementatie:
Gebruik de volgende use-caseaankopen wanneer de DNS- of virtuele naam van een virtuele machine niet wordt gewijzigd tijdens de migratie.
Use case:
Achtergrond-DNS- en virtuele namen verbinden veel systeeminterfaces in het SAP-landschap en klanten zijn slechts soms op de hoogte van de interfaces die ontwikkelaars in de loop van de tijd definiëren. Verbinding maken ieproblemen ontstaan tussen systemen wanneer virtuele of DNS-namen na migraties veranderen. Voor het gemak raden we u aan DNS-aliassen te bewaren.
Gebruik verschillende DNS-zones om elke omgeving te onderscheiden, waaronder sandbox, ontwikkeling, preproductie en productieomgevingen, van elkaar. Een uitzondering hierop is voor SAP-implementaties die een eigen virtueel netwerk hebben. In dit scenario zijn privé-DNS-zones mogelijk niet nodig.
Een Azure-netwerktopologie definiëren
Landingszones op ondernemingsniveau ondersteunen twee netwerktopologieën. Eén topologie is gebaseerd op Azure Virtual WAN. De andere is een traditionele netwerktopologie die is gebaseerd op een hub-and-spoke-architectuur. In deze sectie worden aanbevolen SAP-configuraties en -procedures voor beide implementatiemodellen beschreven.
Gebruik een netwerktopologie op basis van Virtual WAN als uw organisatie van plan is het volgende te doen:
- Implementeer resources in verschillende Azure-regio's en verbind uw globale locaties met zowel Azure- als on-premises omgevingen.
- Integreer softwaregedefinieerde WAN-implementaties volledig met Azure.
- Implementeer maximaal 2000 virtuele-machineworkloads in alle virtuele netwerken die zijn verbonden met één Virtual WAN-hub.
Organisaties gebruiken Virtual WAN om te voldoen aan grootschalige interconnectiviteitsvereisten. Microsoft beheert deze service, waardoor de algehele netwerkcomplexiteit wordt verminderd en het netwerk van uw organisatie wordt gemoderniseerd.
Gebruik een traditionele Azure-netwerktopologie op basis van een hub-and-spoke-architectuur als uw organisatie:
- Plannen voor het implementeren van resources in alleen bepaalde Azure-regio's.
- Er is geen wereldwijd, onderling verbonden netwerk nodig.
- Heeft weinig externe of vertakkingslocaties per regio en heeft minder dan 30 IPSec-tunnels (Internet Protocol Security) nodig.
- Vereist volledig beheer en granulariteit om uw Azure-netwerk handmatig te configureren.
Ontwerpaan aanbevelingen voor SAP-implementatie:
Gebruik Virtual WAN voor Azure-implementaties in nieuwe, grote of wereldwijde netwerken waarin u wereldwijde doorvoerconnectiviteit nodig hebt tussen Azure-regio's en on-premises locaties. Als u deze aanpak gebruikt, hoeft u geen transitieve routering handmatig in te stellen voor Azure-netwerken en kunt u een standaard voor SAP in Azure-implementaties volgen.
Overweeg alleen virtuele netwerkapparaten (NVA's) tussen regio's te implementeren als u NVA's van partners gebruikt. NVA's tussen regio's of virtuele netwerken zijn niet vereist als systeemeigen NVA's aanwezig zijn. Wanneer u partnernetwerktechnologieën en NVA's implementeert, volgt u de richtlijnen van de leverancier om conflicterende configuraties met Azure-netwerken te identificeren.
Virtual WAN beheert connectiviteit tussen virtuele spoke-netwerken voor op Virtual WAN gebaseerde topologieën, dus u hoeft geen door de gebruiker gedefinieerde routes (UDR's) of NVA's in te stellen. De maximale netwerkdoorvoer voor netwerk-naar-netwerkverkeer in dezelfde virtuele hub is 50 Gbps. Om deze bandbreedtebeperking te overwinnen, kunnen SAP-landingszones peering van virtuele netwerken gebruiken om verbinding te maken met andere landingszones.
Geen van beide topologie ondersteunt NVA-implementaties tussen een SAP-toepassing en een databaseserver.
Peering voor lokale en wereldwijde virtuele netwerken biedt connectiviteit en zijn de voorkeursmethoden om connectiviteit tussen landingszones voor SAP-implementaties in meerdere Azure-regio's te garanderen.
Plannen voor binnenkomende en uitgaande internetverbinding
In deze sectie worden aanbevolen connectiviteitsmodellen beschreven voor binnenkomende en uitgaande connectiviteit van en naar het openbare internet. Systeemeigen netwerkbeveiligingsservices van Azure, zoals Azure Firewall, Azure Web Application Firewall op Azure-toepassing Gateway en Azure Front Door, zijn volledig beheerde services, zodat u geen operationele en beheerkosten ondervindt die zijn gekoppeld aan infrastructuurimplementaties.
Ontwerpaan aanbevelingen voor SAP-implementatie:
Voor klanten die een wereldwijde footprint hebben, faciliteert Azure Front Door SAP-implementaties met behulp van Web Application Firewall-beleid om wereldwijde HTTP- en HTTPS-toepassingen in Azure-regio's te leveren en te beveiligen.
Profiteer van Web Application Firewall-beleid in Azure Front Door wanneer u Azure Front Door en Application Gateway gebruikt om HTTP- en HTTPS-toepassingen te beveiligen. Verkeer naar Application Gateway blokkeren zodat het alleen verkeer van Azure Front Door ontvangt.
Application Gateway en Web Application Firewall hebben beperkingen wanneer Application Gateway fungeert als een omgekeerde proxy voor SAP-web-apps. Omdat SAP Web Dispatcher en NetScaler intelligenter zijn dan Application Gateway, moet u uitgebreid testen als u ze vervangt door Application Gateway. Controleer indien mogelijk de meest recente status en vermeld alle ondersteunde, niet-ondersteunde, geteste en niet geteste scenario's.
Gebruik een webtoepassingsfirewall om uw verkeer te scannen wanneer het wordt blootgesteld aan internet. Een andere optie is om deze te gebruiken met uw load balancer of met resources, zoals Application Gateway of oplossingen van derden, met ingebouwde firewallmogelijkheden.
Als u gegevenslekken wilt voorkomen, gebruikt u Azure Private Link om veilig toegang te krijgen tot PaaS-resources (Platform as a Service), zoals Azure Blob Storage, Azure Files, Azure Data Lake Storage Gen2 en Azure Data Factory. Privé-eindpunten kunnen ook helpen bij het beveiligen van verkeer tussen virtuele netwerken en services, zoals Azure Storage en Azure Backup. Verkeer tussen uw virtuele netwerk en de privé-eindpuntservice reist via het wereldwijde Microsoft-netwerk, waardoor de blootstelling aan het openbare internet wordt voorkomen.
Azure ExpressRoute implementeren met hoge beschikbaarheid
Azure ExpressRoute is ontworpen voor hoge beschikbaarheid om een privénetwerkverbinding met Microsoft-resources te bieden op providerniveau. Er is geen single point of failure in het ExpressRoute-pad binnen het Microsoft-netwerk. Om de beschikbaarheid te maximaliseren, moeten de klant en het segment van de serviceprovider van uw ExpressRoute-circuit ook worden gebouwd voor hoge beschikbaarheid.
Ontwerpaan aanbevelingen voor SAP-implementaties:
- Zorg ervoor dat u de twee fysieke koppelingen van uw ExpressRoute-circuit verbindt met twee afzonderlijke edge-apparaten in uw netwerk. Zie de aanbevelingen voor tolerantie van ExpressRoute-circuits voor aanbevelingen om de beschikbaarheid van uw ExpressRoute-circuit te maximaliseren.
- Hoge beschikbaarheid voor ExpressRoute garanderen. Zie Ontwerpen voor hoge beschikbaarheid met ExpressRoute voor meer informatie.
- Voer een goed ontworpen beoordeling uit van ExpressRoute. Zie Azure Well-Architected Framework review - Azure ExpressRoute-aanbevelingen voor meer informatie.
- Zorg ervoor dat u een plan voor herstel na noodgevallen voor ExpressRoute hebt. Zie Ontwerpen voor herstel na noodgevallen met persoonlijke ExpressRoute-peering voor meer informatie.
- Zorg ervoor dat beide verbindingen van een ExpressRoute-circuit zijn geconfigureerd in de actief-actiefmodus. Zie Ontwerpen voor hoge beschikbaarheid met ExpressRoute - Actief-actieve verbindingen voor meer informatie.
- Configureer bewaking en waarschuwingen voor ExpressRoute-circuits.
- Configureer de servicestatus voor het ontvangen van onderhoudsmeldingen voor expressRoute-circuits.
Vereisten voor netwerkversleuteling definiëren
In deze sectie worden belangrijke aanbevelingen besproken voor het versleutelen van netwerken tussen on-premises en Azure-omgevingen en tussen Azure-regio's.
Ontwerpoverwegingen voor SAP-implementaties:
Verkeer wordt standaard niet versleuteld wanneer u ExpressRoute gebruikt om persoonlijke peering te configureren.
U hoeft geen verkeer via ExpressRoute te versleutelen voor SAP-implementaties. SAP-verkeer verbruikt doorgaans veel bandbreedte en is gevoelig voor prestaties. IPSec-tunnels versleutelen internetverkeer standaard en versleuteling of ontsleuteling kan een negatieve invloed hebben op de prestaties van het verkeer.
De klant bepaalt of SAP-verkeer moet worden versleuteld. Zie De netwerktopologie en -connectiviteit voor meer informatie over de opties voor netwerkversleuteling in landingszones op ondernemingsniveau.
Gescheiden systemen
Er zijn verschillende omgevingen, waaronder ontwikkeling, testen, kwaliteit, preproductie en productieomgevingen, in een SAP-scenario, en klanten categoriseren deze systemen in logische of fysieke constructies om beveiligings- en nalevingsstandaarden te handhaven. Het idee is om alle systemen met dezelfde levenscyclus in één gemeenschappelijke resourcegroep te beheren. U kunt deze groepen op verschillende niveaus definiëren, zoals op abonnements- of resourcegroepniveau.
Uw organisatie moet ook rekening houden met de beveiligings- en beleidsstructuur tijdens het groeperen van resources in een SAP-landschap. Voor SAP-transporten tussen ontwikkel-, test-, kwaliteits- en productieomgevingen heeft uw organisatie mogelijk het volgende nodig:
- Peering van virtuele netwerken.
- Poortopeningen van firewall tussen virtuele netwerken.
- Regels voor UDR en netwerkbeveiligingsgroep (NSG).
We raden u niet aan het databasebeheersysteem (DBMS) en toepassingslagen van SAP-systemen in verschillende virtuele netwerken te hosten en deze te verbinden met behulp van peering voor virtuele netwerken. Overmatig netwerkverkeer tussen de lagen kan aanzienlijke kosten met zich meebrengen.
Aanvullende aanbevelingen voor SAP-implementaties:
Geen van beide topologie biedt ondersteuning voor het plaatsen van de SAP-toepassingslaag en SAP DBMS in verschillende virtuele Azure-netwerken die niet zijn gekoppeld.
U kunt toepassingsbeveiligingsgroepen (ASG) en NSG-regels gebruiken om lijsten voor toegangsbeheer voor netwerkbeveiliging tussen de SAP-toepassing en DBMS-lagen te definiëren. U kunt virtuele machines toevoegen aan ASG's om hun beveiliging te helpen beheren.
Schakel versnelde Netwerken van Azure in op de virtuele machines die u gebruikt in de SAP-toepassing en DBMS-lagen. De volgende besturingssysteemniveaus ondersteunen versneld netwerken in Azure:
- Windows Server 2012 R2 of hoger
- SUSE Linux Enterprise Desktop 12 SP3 of hoger
- Red Hat Enterprise Linux 7.4 of hoger
- Oracle Linux 7.5
- Voor de kernel die compatibel is met Red Hat Enterprise Linux is release 3.10.0-862.13.1.el7 vereist.
- Voor de Oracle Unbreakable Enterprise Kernel is release 5 vereist.
Zorg ervoor dat u interne implementaties voor Azure Load Balancer instelt om de functie voor direct server return te gebruiken. Deze functie vermindert de latentie wanneer u interne load balancer-configuraties gebruikt voor configuraties met hoge beschikbaarheid op de DBMS-laag.
Als u Load Balancer met Linux-gastbesturingssystemen gebruikt, moet u ervoor zorgen dat de Linux-netwerkparameter
net.ipv4.tcp_timestamps
is ingesteld op0
.Voor optimale netwerklatentie met SAP-toepassingen kunt u overwegen azure-nabijheidsplaatsingsgroepen te gebruiken.
Voor migratieprojecten kunt u overwegen de netwerkparameters af te stemmen. U kunt bijvoorbeeld de prestaties verbeteren door de bevestigingen tijdens de migratieperiode uit te schakelen.
Verken de SAP-ondersteuningsportal en SAP Note 2391465 voor meer informatie over het implementeren van SAP.
Ontwerpoverwegingen voor RISE-implementaties
Wanneer u SAP RISE-implementaties uitvoert in Azure, is de integratie van de door SAP beheerde omgeving met uw eigen Azure-ecosysteem van cruciaal belang. Zie Azure integreren met door SAP RISE beheerde workloads voor meer informatie over de aanbevolen procedures en richtlijnen.
De SAP RISE-implementatie heeft doorgaans twee opties voor connectiviteit: een site-naar-site-VPN of peering voor virtuele netwerken. Als u geen eerdere Azure-workloads hebt, is een site-naar-site-VPN mogelijk de eenvoudigere optie. Als u Azure echter wilt gebruiken als strategisch platform, kunt u een juiste Azure-landingszone instellen en peering van virtuele netwerken gebruiken voor de SAP RISE-tenant. Voor deze scenario's is een vereenvoudigde landingszone zoals de Azure-landingszone mogelijk een goede optie. U kunt deze kant-en-klare implementatie-ervaring eenvoudig aanpassen aan uw vereisten, met name de parameters van het virtuele netwerk.
Voor het implementeren van peering tussen tenants voor virtuele netwerken naar de SAP RISE-tenant is ook meer werk vereist. U moet de architectuur van het virtuele netwerk zorgvuldig plannen om ervoor te zorgen dat er geen overlappende interdomeinrouteringsbereiken tussen domeinen zijn. U moet ook DNS correct koppelen aan de SAP RISE-tenant.
Houd rekening met de limieten en beperkingen als u besluit een Virtual WAN-oplossing in te stellen en site-naar-site-VPN- of ExpressRoute-verbindingen nodig hebt.