Share via

Netzwerktopologie und Konnektivität für eine SAP-Migration

  • Artikel

Dieser Artikel baut auf Überlegungen und Empfehlungen, die in der Übersicht über Netzwerktopologie und Konnektivität in Azure definiert sind. In diesem Artikel erfahren Sie mehr über die Beurteilung der wichtigsten Entwurfsüberlegungen und bewährten Methoden für Netzwerke und die Konnektivität für Microsoft Azure- und SAP-Bereitstellungen Da es sich bei SAP um eine unternehmenskritische Plattform handelt, sollte Ihr Entwurf auch der Anleitung zu den Entwurfsbereichen für Azure-Zielzonen folgen.

Planen der IP-Adressierung

Ein Plan für die IP-Adressierung in Azure ist wichtig, um Folgendes sicherzustellen:

  • Der IP-Adressraum weist keine Überlappungen in Bezug auf lokale Standorte und Azure-Regionen auf.
  • Das virtuelle Netzwerk enthält den richtigen Adressraum.
  • Subnetzkonfigurationspläne erfolgen im Voraus.

Das folgende Architekturdiagramm zeigt die Netzwerküberlegungen in SAP für einen Azure-Zielzonenbeschleuniger:

Ein Diagramm mit Netzwerküberlegungen in SAP zu einem Azure-Zielzonenbeschleuniger.

Entwurfsaspekte für die SAP-Implementierung:

Sie können Subnetze für bestimmte Dienste dediziert festlegen und delegieren und in den Subnetzen dann Instanzen dieser Dienste erstellen. Obwohl Sie mit Azure mehrere delegierte Subnetze in einem virtuellen Netzwerk erstellen können, können Sie nur ein delegiertes Subnetz in einem virtuellen Netzwerk für Azure NetApp Files verwenden. Wenn Sie mehr als ein delegiertes Subnets für Azure NetApp Files verwenden, können Sie kein neues Volume erstellen.

Anwendungsfall:

Sie benötigen delegierte Subnetze, um Azure NetApp Files zu implementieren. Dies ist ein beliebter Ansatz für SAP-Bereitstellungen, die Dateisysteme gemeinsam nutzen. Sie benötigen ein delegiertes Subnetz nur für ein Application Gateway während des Lastenausgleichs oder für SAP BusinessObjects Business Intelligence, bei dem es sich um einen Lastenausgleichsserver für SAP-Webanwendungen handelt.

Konfigurieren von DNS und der Namensauflösung für lokale Ressourcen und Azure-Ressourcen

Domain Name System (DNS) ist ein wichtiger Bestandteil der Azure-Zielzonenarchitektur. Einige Unternehmen möchten möglicherweise Ihre vorhandenen Investitionen in DNS nutzen. Andere sehen möchten vielleicht die Gelegenheit nutzen, eine Cloudlösung einzuführen, um Ihre interne DNS-Infrastruktur zu modernisieren und native Azure-Funktionen zu verwenden.

Entwurfsempfehlungen für die SAP-Implementierung:

Die folgenden Empfehlungen gelten für Fälle, in denen sich das DNS oder der virtuelle Name eines virtuellen Computers während der Migration nicht ändern.

Anwendungsfall:

  • Per Hintergrund-DNS und mit virtuellen Namen werden viele Systemschnittstellen in der SAP-Landschaft verbunden, und Kunden kennen nicht immer alle Schnittstellen, die von Entwicklern im Laufe der Zeit definiert werden. Zwischen Systemen treten Verbindungsprobleme auf, wenn sich virtuelle oder DNS-Namen nach Migrationen ändern. Aus Gründen der Einfachheit wird empfohlen, DNS-Aliase beizubehalten.

  • Verwenden Sie unterschiedliche DNS-Zonen, um die einzelnen Umgebungen (einschließlich Sandbox, Entwicklung, Präproduktion und Produktion) voneinander zu unterscheiden. Eine Ausnahme bilden SAP-Bereitstellungen, die über ein eigenes virtuelles Netzwerk verfügen. In diesem Szenario sind private DNS-Zonen möglicherweise nicht erforderlich.

Definieren einer Azure-Netzwerktopologie

Zielzonen im Unternehmensmaßstab unterstützen zwei Netzwerktopologien. Eine Topologie basiert auf Azure Virtual WAN. Die andere ist eine herkömmliche Azure-Netzwerktopologie, die auf der Hub-Spoke-Architektur basiert. Dieser Abschnitt informiert über empfohlene SAP-Konfigurationen und Methoden für beide Bereitstellungsmodelle.

Verwenden Sie eine auf Virtual WAN basierende Netzwerktopologie, wenn Sie in Ihrer Organisation Folgendes planen:

  • Stellen Sie Ressourcen in mehreren Azure-Regionen bereit, und verbinden Sie die globalen Standorte sowohl mit Azure als auch mit lokalen Umgebungen.
  • Vollständiges Integrieren von softwaredefinierten WAN-Bereitstellungen mit Azure
  • Stellen Sie bis zu 2.000 VM-Workloads in allen virtuellen Netzwerken bereit, die mit einem Virtual WAN-Hub verbunden sind.

Organisationen nutzen Virtual WAN, um die hohen Anforderungen in Bezug auf die Interkonnektivität zu erfüllen. Microsoft verwaltet diesen Dienst, um für Sie die allgemeine Komplexität des Netzwerks zu verringern und eine Modernisierung des Netzwerks Ihrer Organisation zu erzielen.

Verwenden Sie eine herkömmliche Azure-Netzwerktopologie, die auf der Hub-and-Spoke-Architektur basiert, wenn für Ihre Organisation Folgendes zutrifft:

  • Bereitstellung von Ressourcen nur in ausgewählten Azure-Regionen.
  • Kein globales verbundenes Netzwerk erforderlich.
  • Wenige Remote- oder Zweigstandorte pro Region und weniger als 30 benötigte Internet Protocol Security-(IPSec-)Tunnel
  • Vollständige Kontrolle und Granularität für die manuelle Konfiguration des Azure-Netzwerks.

Entwurfsempfehlungen für die SAP-Implementierung:

  • Verwenden Sie Virtual WAN für Azure-Bereitstellungen in neuen, großen bzw. globalen Netzwerken, für die Sie eine globale Transitkonnektivität zwischen Azure-Regionen und lokalen Standorten benötigen. Bei diesem Ansatz müssen Sie das transitive Routing für Azure-Netzwerke nicht manuell einrichten, und Sie können die Standardvorgehensweise für Bereitstellungen von SAP in Azure verwenden.

  • Erwägen Sie, virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) nur dann zwischen Regionen bereitzustellen, wenn Sie Partner-NVAs nutzen. NVAs zwischen Regionen oder virtuellen Netzwerken sind nicht erforderlich, wenn native NVAs vorhanden sind. Wenn Sie Netzwerktechnologien und NVAs von Partnern bereitstellen, sollten Sie die Anweisungen des jeweiligen Anbieters befolgen, um zu ermitteln, ob Konflikte in Bezug auf die Konfiguration des Azure-Netzwerks bestehen.

  • Virtual WAN verwaltet die Konnektivität zwischen virtuellen Speichennetzwerken für Virtual WAN-basierte Topologien, sodass Sie keine benutzerdefinierten Routen (USER-Defined Routes, UDRs) oder NVAs einrichten müssen. Der maximale Netzwerkdurchsatz für Netzwerk-zu-Netzwerkdatenverkehr im gleichen virtuellen Hub beträgt 50 GBit/s. Für SAP-Zielzonen kann das Peering virtueller Netzwerke verwendet werden, um eine Verbindung mit anderen Zielzonen herzustellen und diese Bandbreitenbegrenzung aufzuheben.

  • Keine der Topologien unterstützt NVA-Bereitstellungen zwischen einer SAP-Anwendung und einem Datenbankserver.

  • Die Konnektivität kann per lokalem und globalem Peering virtueller Netzwerke hergestellt werden. Dies sind die bevorzugten Ansätze, mit denen die Konnektivität zwischen Zielzonen für SAP-Bereitstellungen über mehrere Azure-Regionen hinweg sichergestellt werden kann.

Planen der eingehenden und ausgehenden Internetkonnektivität

In diesem Abschnitt werden empfohlene Konnektivitätsmodelle für die eingehende und ausgehende Konnektivität zum und aus dem öffentlichen Internet beschrieben. Da es sich bei nativen Azure-Netzwerksicherheitsdiensten, z. B. Azure Firewall, Azure Web Application Firewall in Azure Application Gateway und Azure Front Door, um vollständig verwaltete Dienste handelt, fällt für Sie nicht der operative und verwaltungsbezogene Aufwand an, der mit Infrastrukturbereitstellungen verbunden ist.

Entwurfsempfehlungen für die SAP-Implementierung:

  • Für Kunden mit globaler Abdeckung dient Azure Front Door zur Vereinfachung von SAP-Bereitstellungen, indem Richtlinien von Azure Web Application Firewall verwendet werden, um globale HTTP- und HTTPS-Anwendungen für Azure-Regionen übergreifend bereitzustellen und zu schützen.

  • Nutzen Sie die Web Application Firewall-Richtlinien in Azure Front Door, wenn Sie Azure Front Door und Application Gateway verwenden, um HTTP- und HTTPS-Anwendungen zu schützen. Blockieren Sie den Datenverkehr zu Application Gateway, sodass der Datenverkehr nur von Azure Front Door empfangen wird.

  • Application Gateway und Web Application Firewall haben Einschränkungen, wenn Application Gateway als Reverseproxy für SAP-Web-Apps dient. Da SAP Web Dispatcher und NetScaler intelligenter sind als Application Gateway, müssen Sie umfangreiche Tests durchführen, wenn Sie sie durch Application Gateway ersetzen. Überprüfen Sie nach Möglichkeit den aktuellen Status, und listen Sie alle unterstützten, nicht unterstützten und getesteten bzw. nicht getesteten Szenarien auf.

  • Verwenden Sie eine Web Application Firewall, um Ihren Datenverkehr zu überprüfen, wenn dieser im Internet verfügbar gemacht wird. Eine andere Möglichkeit ist die gemeinsame Verwendung mit Ihrem Lastenausgleichsmodul oder mit Ressourcen, wie Application Gateway oder Drittanbieterlösungen, die über integrierte Firewallfunktionen verfügen.

  • Verwenden Sie zur Verhinderung von Datenlecks Azure Private Link, um den sicheren Zugriff auf Platform-as-a-Service-(PaaS)-Ressourcen zu ermöglichen, z. B. Azure Blob Storage, Azure Files, Azure Data Lake Storage Gen2 und Azure Data Factory. Private Endpunkte können zum Schutz von Datenverkehr zwischen virtuellen Netzwerken und Diensten wie Azure Storage und Azure Backup beitragen. Datenverkehr zwischen Ihrem virtuellem Netzwerk und dem für private Endpunkte geeigneten Dienst fließt über das globale Microsoft-Netzwerk, um zu verhindern, dass er im öffentlichen Internet offengelegt wird.

Implementieren von Azure ExpressRoute mit hoher Verfügbarkeit

Azure ExpressRoute wurde für Hochverfügbarkeit entwickelt, um Konnektivität für private Netzwerke mit Microsoft-Ressourcen auf Netzbetreiberniveau bereitzustellen. Es gibt keine einzelne Fehlerquelle im ExpressRoute-Pfad im Microsoft-Netzwerk. Um die Verfügbarkeit zu maximieren, sollten auch das Kunden- und das Dienstanbietersegment Ihrer ExpressRoute-Verbindung auf Hochverfügbarkeit ausgelegt sein.

Entwurfsempfehlungen für SAP-Implementierungen:

Definieren von Netzwerkverschlüsselungsanforderungen

In diesem Abschnitt werden wichtige Empfehlungen beschrieben, die die Verschlüsselung von Netzwerken zwischen lokalen und Azure-Umgebungen sowie in Azure-Regionen betreffen.

Entwurfsüberlegungen für SAP-Implementierungen:

  • Standardmäßig wird der Datenverkehr derzeit nicht verschlüsselt, wenn Azure ExpressRoute zum Konfigurieren des privaten Peerings verwendet wird.

  • Sie müssen den Datenverkehr über ExpressRoute für SAP-Bereitstellungen verschlüsseln. Für SAP-Datenverkehr wird normalerweise viel Bandbreite verbraucht, und die Empfindlichkeit gegenüber Leistungsschwankungen ist relativ hoch. Für IPSec-Tunnel wird Internetdatenverkehr standardmäßig verschlüsselt, und die Ver- und Entschlüsselung kann eine negative Auswirkung auf die Leistung des Datenverkehrs haben.

  • Der Kunde entscheidet, ob SAP-Datenverkehr verschlüsselt werden soll. Erfahren Sie mehr über Optionen für die Netzwerkverschlüsselung in Zielzonen auf Unternehmensebene unter Netzwerktopologie und -konnektivität.

Trennen von Systemen

Da ein SAP-Szenario unterschiedliche Umgebungen umfasst, z. B. Entwicklung, Test, Qualität, Präproduktion, Produktion usw., neigen Kunden dazu, diese Systeme als logische bzw. physische Konstrukte zu kategorisieren, um die Einhaltung von Sicherheits- und Konformitätsstandards sicherzustellen. Die Idee besteht darin, alle Systeme zu verwalten, die denselben Lebenszyklus in einer gemeinsamen Ressourcengruppe aufweisen. Sie können diese Gruppen auf verschiedenen Ebenen definieren, z. B. auf Abonnement- oder Ressourcengruppenebene.

Darüber hinaus sollte Ihre Organisation auch die Sicherheits- und Richtlinienstruktur berücksichtigen, wenn Ressourcen in einer SAP-Landschaft gruppiert werden. Für die Durchführung von SAP-Transporten zwischen den Entwicklungs-, Test-, Qualitäts- und Produktionsumgebungen benötigt Ihre Organisation aber ggf. Folgendes:

  • Peering virtueller Netzwerke.
  • Firewall-Portöffnungen zwischen virtuellen Netzwerken.
  • UDR- und Netzwerksicherheitsgruppen-(NSG-)Regeln.

Es wird nicht empfohlen, das Datenbankverwaltungssystem (DbMS) und die Anwendungsebenen von SAP-Systemen in verschiedenen virtuellen Netzwerken zu hosten und diese mithilfe von Peering virtueller Netzwerke zu verbinden. Übermäßiger Netzwerkdatenverkehr zwischen den Ebenen kann erhebliche Kosten verursachen.

Weitere Empfehlungen für SAP-Implementierungen:

  • Die Platzierung der SAP-Anwendungsschicht und von SAP-DBMS in verschiedenen virtuellen Azure-Netzwerken, die nicht mittels Peering miteinander verknüpft sind, wird von keiner Topologie unterstützt.

  • Sie können Regeln für Anwendungs- und Netzwerksicherheitsgruppen (ASG und NSG) verwenden, um Zugriffssteuerungslisten für die Netzwerksicherheit zwischen den SAP-Anwendungs- und DBMS-Ebenen zu definieren. Sie können den ASGs virtuelle Computer hinzufügen, um deren Sicherheit besser verwalten zu können.

  • Aktivieren Sie den beschleunigten Azure-Netzwerkbetrieb auf den virtuellen Computern, die Sie in der SAP-Anwendung und den DBMS-Ebenen verwenden. Das folgende Betriebssystem unterstützt den beschleunigten Netzwerkbetrieb in Azure:

    • Windows Server 2012 R2 oder höher
    • SUSE Linux Enterprise Desktop 12 SP3 oder höher
    • Red Hat Enterprise Linux 7.4 oder höher
    • Oracle Linux 7.5
      • Der Kernel, der mit Red Hat Enterprise Linux kompatibel ist, benötigt die Version 3.10.0-862.13.1.el7.
      • Der Oracle Unbreakable Enterprise Kernel erfordert Release 5.

  • Stellen Sie sicher, dass interne Bereitstellungen für Azure Load Balancer für die Verwendung von Direct Server Return eingerichtet sind. Mit diesem Feature wird die Latenz verringert, wenn Konfigurationen für interne Lastenausgleichsmodule für Hochverfügbarkeitskonfigurationen auf der DBMS-Ebene verwendet werden.

  • Wenn Sie Load Balancer mit Linux-Gastbetriebssystemen verwenden, stellen Sie sicher, dass der Linux-Netzwerkparameter net.ipv4.tcp_timestamps auf 0 festgelegt ist.

  • Erwägen Sie, Azure-Näherungsplatzierungsgruppen zu verwenden, um mit SAP-Anwendungen die optimale Netzwerklatenz zu erzielen.

  • Erwägen Sie für Migrationsprojekte die Optimierung der Netzwerkparameter. Sie können beispielsweise die Leistung verbessern, indem Sie die Bestätigungen während des Migrationszeitraums deaktivieren.

  • Weitere Informationen zur SAP-Implementierung finden Sie im Supportportal von SAP und im SAP-Hinweis 2391465.

Entwurfsaspekte für RISE-Implementierungen

Wenn Sie SAP RISE-Bereitstellungen in Azure ausführen, ist die Integration der von SAP-verwalteten Umgebung in Ihr eigenes Azure-Ökosystem von größter Bedeutung. Weitere Informationen zu den bewährten Methoden und Anleitungen finden Sie unter Integrieren von Azure in mit SAP RISE-verwaltete Workloads.

Die SAP RISE-Implementierung verfügt in der Regel über zwei Optionen für Konnektivität: Site-to-Site-VPN oder Peering virtueller Netzwerke. Wenn Sie noch keine Azure-Workloads haben, ist ein Site-to-Site-VPN vielleicht die einfachere Option. Wenn Sie Azure jedoch als strategische Plattform einsetzen möchten, können Sie eine richtige Azure-Zielzone einrichten und ein Peering virtueller Netzwerke für den SAP RISE-Mandanten nutzen. Für diese Szenarien könnte eine vereinfachte Zielzone wie die Azure-Zielzone eine gute Option sein. Sie können diese vorgefertigte Bereitstellungsoberfläche ganz einfach an Ihre Anforderungen anpassen, insbesondere die Parameter des virtuellen Netzwerks.

Die Bereitstellung des mandantenübergreifenden Peerings virtueller Netzwerke für den SAP RISE-Mandanten erfordert ebenfalls mehr Arbeit. Sie müssen die Architektur des virtuellen Netzwerks sorgfältig planen, um sicherzustellen, dass keine überlappenden klassenlosen domänenübergreifende Routenplanungsbereiche vorhanden sind. Sie müssen auch die DNS ordnungsgemäß an den SAP RISE-Mandanten peeren.

Berücksichtigen Sie die Grenzwerte und Einschränkungen, senn Sie sich für die Einrichtung einer Virtual WAN-Lösung entscheiden und Site-to-Site-VPN- oder ExpressRoute-Verbindungen benötigen.