Vorbemerkungen - Maßeinheiten für Daten/Informationen

Häufig wird der Durchsatz von Netzspeicher in Mb/s oder Gb/s angezeigt.

Dabei ist zu beachten, dass Mb (Megabit) ein Dezimalpräfix darstellt, MiB (Mebibyte) dagegen ein Binärpräfix. Diese Einheiten sind somit in verschiedenen Größenordnungen angesiedelt. Noch verwirrender wird es angesichts der Tatsache, dass für MiB (Mebibyte) in Microsoft Windows allgemein die Langform Megabyte verwendet wurde.

Für nachfolgende Verweise werden in der gesamten Dokumentation zum Netzbetrieb die Einheiten Mb (Megabits) und MiB (Mebibyte) gemäß dem von der IEC definierten Einheitensystem (SI) verwendet, das von Organisationen wie IEEE, ISO und NIST übernommen wurde.

Beispiel:

• 100 Mb/s (Megabit pro Sekunde) entsprechen 12 MiB/s (Mebibyte pro Sekunde)
• 1000 Mb/s (Megabit pro Sekunde), auch als 1 Gb/s (Gigabit pro Sekunde) bezeichnet, entsprechen 120 MiB/s (Mebibyte pro Sekunde)
• 10 Gb/s (Gigabit pro Sekunde) entsprechen 1200 MiB/s (Mebibyte pro Sekunde)

Hinweise zur Netzkonnektivität

Eine Übersicht über die verfügbaren Konnektivitätsoptionen finden Sie unter Zugang zur SAP-Systemlandschaft bestimmen.

Betriebsoperationen sind oft auf SAP-Systeme konzentriert, wobei eine Vielzahl integrierter Anwendungen (traditionelle Anwendungen eingeschlossen) eingebunden sind.

In den meisten Fällen erfordern SAP-Workloads eine Verbindung zum vorhandenen internen Netz. Es wird empfohlen, IBM Cloud® Direct Link 2.0 zu verwenden, um über eine sichere Verbindung mit niedriger Latenzzeit und hohem Durchsatz (bis zu 10 Gb/s) als Verbindung in OSI-Schicht 2/3 mit Routing zu verfügen.

Die folgenden Konnektivitätsoptionen richten sich nach den Geschäftsanforderungen, z. B. danach, ob ein Unternehmen die Cloud verwenden und außerdem das Sicherheitsrisiko durch eine Isolierung von Datenflüssen über die vorhandenen Netzstrukturen und Sicherheitseinrichtungen verringern möchte. Kunden wird bei diesen 'abgetrennten' oder 'rein privaten' Konnektivitätsdesigns geraten, zusätzliche Informationen bei IBM Cloud® einzuholen und die jeweiligen Anwendungsfälle zu erörtern.

Darüber hinaus wird von SAP ausdrücklich nicht empfohlen, das SAP-System-Tiering über einen oder mehrere lokale Standorte und Cloud-Standorte hinweg aufzuteilen, wobei das jeweilige Unternehmen für eine Bewertung dieser Empfehlung zuständig ist. SAP rät z. B. davon ab, SAP AnyDB, betrieben in der Infrastruktur eines lokalen Standorts, beizubehalten und Verbindungen zu SAP NetWeaver, betrieben in der Infrastruktur eines Cloud-Standorts, herzustellen. Bei IBM Power Virtual Server-Instanzen wird diese Aufteilung im Rahmen des SAP-System-Tierings nicht unterstützt.

Hinweise zur Netztopologie

Die Netztopologie variiert erheblich je nach Anzahl und Konfiguration der SAP-Systeme, die aus Sicherheits- oder Leistungsgründen mit der Anordnung der Netzflüsse zwischen diesen Systemen kombiniert werden. Das Design dieser Topologie spiegelt die Anforderungen der Firma in Bezug auf Sicherheit, Leistung, Kosten, Flexibilität und Konnektivität wider.

Bei Verwendung der SAP ERP-Geschäftsanwendung (ERP = Enterprise Resource Planning) gilt z. B. für ein als Host der Produktionsinstanz eingesetztes SAP-System, das dem SAP-System-Tiering-Konzept entspricht und die Hochverfügbarkeitskonfiguration für SAP NetWeaver und SAP HANA verwendet, Folgendes:

• SAP NetWeaver - mit mindestens vier Hosts anstelle eines einzigen Hosts:

  • ASCS (Central Services)
  • PAS (primärer Anwendungsserver), auch als CI (Central Instance) bezeichnet
  • ERS-Instanz (Enqueue-Replikationsserverinstanz)
  • AAS (zusätzlicher Anwendungsserver)

• SAP HANA - mit mindestens zwei Hosts (von 3 möglichen) anstelle eines einzigen Hosts:

  • SAP HANA-Primärknoten (mit SAP HANA System Replication)
  • Sekundärer SAP HANA-Failover-Knoten (mit SAP HANA System Replication)
  • SAP HANA Failover-Knoten für tertiäre Disaster-Recovery (mit SAP HANA System Replication)

• Diese Beschreibung bezieht sich auf ein einzelnes SAP-System innerhalb der SAP-Landschaft. Eine SAP-Landschaft kann Folgendes beinhalten:

  • 1 Track, 5 SAP-Systeme (Sandbox > Entwicklung > Tests > Staging > Produktion)
  • 2 Tracks, 5 SAP-Systeme (Sandbox > Entwicklung neuer Features + Wartungsentwicklung > Testen neuer Features + Wartungstests > Staging > Produktion)

**Für eine SAP-Landschaft sind deshalb potenziell 30 bis 50 Instanzen von SAP erforderlich, die auf 10 bis 50 physische oder virtualisierte Host-Server verteilt sind. ** Dies ist die Ausgangslage, bevor weitere Geschäftsanwendungen für bestimmte Geschäftsoperationen oder branchen- bzw. standortbezogene Operationen hinzugefügt werden.

Die Größe der SAP-Landschaften wirkt sich unmittelbar auf die Netztopologie aus.

In der Regel sind die folgenden Netze erforderlich, um den Szenarios und den zugehörigen Leistungsanforderungen gerecht zu werden, die ein Unternehmen, in dem SAP-Geschäftsanwendungen eingesetzt werden, auszeichnen:

• Internes Netz für die Kommunikation zwischen mehreren Instanzen in einer SAP-Landschaft mit unterschiedlichen SAP-System-Tiering-Konzepten
• Netz für die Management- und Speichertransfers der Datenbanksysteme
• In der Produktionsumgebung verwendetes Netz

Im einfachsten Szenario könnte es jedoch ein einziges privates Netz für alle Zwecke geben. Dies hängt von den Geschäftsanforderungen ab.

Hinweise zur Netzauslastung

Die Netzkommunikation für konventionelle SAP-Workload ist mit einem Netzverkehr unter 100 MiB pro Tag relativ gering. Dazu einige Beispiele:

• Benutzertransaktionen über SAP GUI, für Windows, für Java (verwendet mit macOS oder Linux)
• Benutzertransaktionen über SAP WebGUI
• Benutzertransaktionen mit SAP-Apps mit Web Dynpro über SAP NetWeaver Business Client (NWBC)
• SAP-RFC (Remote Function Call) zwischen SAP-Systemen und Systemen anderer Anbieter
• Eingehende und ausgehende SAP-iDocs beim Datenverkehr zwischen SAP-Systemen und Systemen anderer Anbieter, z. B. beim Datenaustausch mit Fremdfirmen wie Lieferanten oder Banken

Es gibt darüber hinaus jedoch eine deutlich umfangreichere Netzkommunikation für SAP-Workloads, die zu wesentlich mehr Netzverkehr beiträgt. Dazu einige Beispiele:

• Vorinstallierte SAPUI5-Bibliotheken und -Themen für SAP Fiori Launchpad und Apps
  • 10 MiB - 25 MiB (Schätzung) pro neuer Sitzung, die aus SAP Web Assistant geladen wird (auch bekannt als. XRay), diese Vorinstallationsbibliotheken werden dann vom Browser zwischengespeichert. Einmal zwischengespeichert sind die Bibliotheken für die Verwendung in einer neuen Browserregisterkarte verfügbar, auch nach einem Neustart des Browsers oder einer SAP Fiori-Abmeldung; bis der Browser-Cache gelöscht ist
  • Geschätzte 20 - 500 KiB für jede neue Fiori-App, die innerhalb der Session geladen wird
• SAP HANA System Replication (HSR), synchron oder asynchron, mit einem Datenstreaming vom primären Knoten zum sekundären (oder tertiären) Knoten im Umfang von mehreren Gigabyte pro Monat

Mit dem erhöhten Datenverkehr bei der SAP-Software mit neuem Design wird der Umfang an Netzverkehr, der bei der SAP-Nutzung bisher üblich war, möglicherweise erheblich überschritten.

Beim Entwurf Ihrer SAP-Anwendungen ist darauf zu achten, dass das private IBM Cloud-Backbone für diese Datenübertragungen verwendet wird, da keine Gebühren für eingehenden und abgehenden Datenverkehr anfallen, während beim Datenverkehr über das öffentliche Internet Kosten für abgehenden Datenverkehr entstehen.

Es empfiehlt sich, den Umfang der übertragenen Daten zu schätzen. In den ersten Stadien der Projektimplementierung kann dies schwierig sein. Es sollte jedoch zumindest eine grobe Schätzung vorgenommen werden.

Hinweise zur Leistung in Bezug auf Netzdurchsatz

SAP empfiehlt im Allgemeinen einen Netzdurchsatz von 10 Gb/s für den Datenverkehr zwischen den SAP-Anwendungsservern und SAP HANA-Datenbanken sowie für andere SAP HANA-Clients, z. B. SAP Business Intelligence.

Für SAP NetWeaver-Bereitstellungen mit SAP AnyDB und lokalem Speicher, sogar für dreischichtige Konfigurationen, sind in der Regel Netze mit 1 Gb/s ausreichend.

Hinweise zur Leistung in Bezug auf Netzlatenz

Bei Ihren Geschäftsoperationen und abhängigen Systemen anderer Anbieter müssen Sie möglicherweise sicherstellen, dass bestimmte Leistungsindikatoren für die Latenzzeit (Key Performance Indicators, KPIs) erfüllt werden. Dabei sollte der Standort Ihrer Hosts berücksichtigt und das Einsetzen von Latenztests unter Verwendung des privaten IBM Cloud-Backbonenetzes erwogen werden.

Latenztests mit der RTT-Metrik (RTT = Round Trip Time, Umlaufzeit) sind erforderlich, wenn SAP HANA für Hochverfügbarkeit (High Availability, HA) und Disaster-Recovery (DR) konzipiert wird.

Wenn das Design ein HA-Failover innerhalb eines einzigen Standorts vorsieht, ist dies in fast allen Fällen mit den SAP HANA System Replication-Anforderungen vereinbar.

Wenn jedoch Hochverfügbarkeit über mehrere Standorte einer Region hinweg für SAP HANA vorgesehen wird oder das Design Disaster-Recovery über mehrere Regionen hinweg beinhaltet, muss die Latenzzeit sorgfältig mithilfe der RTT-Metrik getestet und beim Design entsprechend berücksichtigt werden.

Dies ist dadurch bedingt, dass IBM Cloud bestrebt ist, eine hohe Verfügbarkeit der Plattform sicherzustellen, indem geografisch verteilte Standorte mit Fehlertoleranz (z. B. unterschiedliche Risikobewertungen) verwendet werden. Weitere Informationen dazu, wie IBM Cloud eine hohe Verfügbarkeit und Redundanz gewährleistet.

Insbesondere bei VPC-Infrastruktur stellen die Verfügbarkeitszonen innerhalb der Region verteilte Standorte dar. Für die meisten Workloads bietet dieses Design eine größere Redundanz in der gesamten Region. SAP HANA System Replication erfordert jedoch eine geringe Netzlatenz, die aufgrund der derzeitigen rein physikalisch vorliegenden technischen Einschränkungen bei der physischen Datenübertragung über Kabel (Lichtgeschwindigkeit bei Glasfaserkabeln) möglicherweise schwer zu erreichen ist.

Hinweise zur Sicherheit von Netzports

Die folgenden Informationen sind eine kurze Zusammenfassung des SAP-Hilfeportals – TCP/IP-Ports aller SAP-Produkte, das ein Beispiel für die Überlegungen bietet, die für die Sicherheit Ihrer SAP-Systeme und der gesamten IT-Infrastrukturlandschaft auf IBM Cloud erforderlich sind.

Abhängig von den verwendeten SAP-IT-Anwendungen und den jeweiligen Geschäftsszenarios müssen für verschiedene Hosts Ports geöffnet sein. Normalerweise werden zu diesem Zweck Firewall-Portgruppen mit Firewallregeln kombiniert. Es ist auch möglich, individuelle Firewallregeln für jeden Host zu verwenden, dies bedeutet jedoch häufig einen kaum zu bewältigenden Aufwand.

Die folgende Tabelle enthält einige der wichtigsten Ports für SAP-Systeme mit SAP NetWeaver und SAP HANA. Die Ports variieren je nach der Instanznummer der SAP Technical Appliance. Die Instanznummern 00, 01, 02 stellen die Standardwerte für die verschiedenen SAP-IT-Anwendungen dar und entsprechen unterschiedlichen Mustern (diese Muster werden im Folgenden mit der für code blocks vorgesehenen Hervorhebung angezeigt):

Sicherheitsaspekte bei der Trennung des Netzdatenverkehrs

Sie können verschiedene Netzverkehrstypen in Ihrer Umgebung voneinander trennen, wenn dies aufgrund von Sicherheitsbeschränkungen oder für den Netzdurchsatz erforderlich bzw. sinnvoll ist.

Das Trennen von Netzen ist bei den folgenden Anwendungsfällen für SAP-Workloads hilfreich:

• Mehrere Server, die Daten austauschen
  • SAP-Systeme in einer dreischichtigen logischen Architektur, in der sich die SAP-Datenbank und die SAP-Anwendungsinstanzen auf verschiedenen Hosts befinden.
• Mehrere SAP-Systeme, die große Datenvolumen austauschen
  • Datenbankserver, die eine geringe Netzlatenz und einen hohen Netzdurchsatz für den Blockspeicher bzw. Dateispeicher im Netz benötigen und bei denen Firewalls deshalb vermieden werden müssen. Die Datenbank benötigt jedoch weiterhin Schutz gegenüber anderen Systemen und Netzwerken.

Um einen echten Nutzen aus der Netztrennung ziehen zu können, muss unter bestimmten Umständen eine Vernetzung zugelassen werden.