Networking design considerations

Preface: units of measure for data/information

Often the throughput Network Storage is shown in Mbps or Gbps.

It is important to note, that Mb (Megabits) is a decimal prefix and MiB (Mebibyte) is a binary prefix so they are on different scales. More confusion arises because MiB (Mebibyte) was commonly known in Microsoft Windows as Megabyte.

For future reference throughout the networking documentation, Mb (Megabits) and MiB (Mebibyte) is used based on the system of units (SI) defined by IEC and adopted by IEEE, ISO, and NIST.

For example,:

• 100 Mbps (Megabits per second), would be 12 MiB/s (Mebibyte per second)
• 1000 Mbps (Megabits per second) also known as 1 Gbps (Gigabits per second), would be 120 MiB/s (Mebibyte per second)
• 10 Gbps (Gigabits per second), would be 1200 MiB/s (Mebibyte per second)

Networking connectivity considerations

For an overview of the connectivity options available, see Determining access to your SAP system landscape.

SAP Systems are often the focal point of business operations, with a great number of integrated applications (including legacy applications).

In most circumstances for SAP workloads, a connection to the existing internal network is required, and it is recommended to use IBM Cloud® Direct Link 2.0 to operate the secure, low-latency, high-throughput (available up to 10 Gbps) as a Routed OSI Layer-2/3 connection.

These connectivity options are dependent on business requirements, for example, whether the business wants to use Cloud and also decrease security risk by isolating network flows through their existing networking structure and security. In these "disconnected" or "private-only" connectivity designs, it is best to request IBM Cloud® for additional information and discuss your use cases.

In addition, it is strongly not recommended by SAP to split the SAP System tiering across On-Premises location/s and Cloud locations and it is up to the business to evaluate this; for example, it is not recommended by SAP to retain SAP AnyDB run from infrastructure in an On-Premises location and connect to SAP NetWeaver run from infrastructure in a Cloud location. For IBM Power Virtual Servers this split of SAP System tiering is not supported.

Network Topology considerations

Dependent on the count and configuration of SAP Systems that are combined with the arrangement of the network flows between these systems for security or performance reasons, the Network Topology will be significantly different. The design of this topology reflects the requirements from the business for security, performance, cost, flexibility, and connectivity.

Using the Enterprise Resource Planning (ERP) business application, for example, an SAP System hosting the Production instance that uses the SAP System Tiering approach using High Availability of SAP NetWeaver and SAP HANA:

• SAP NetWeaver, there are at least four hosts instead of 1:

  • Central Services (ASCS)
  • Primary Application Server (PAS), also known as Central Instance (CI)
  • Enqueue Replication Server Instance (ERS)
  • Additional Application Server (AAS)

• SAP HANA, there are at least 2 hosts (possibly 3) instead of 1:

  • SAP HANA primary node (using SAP HANA System Replication)
  • SAP HANA secondary failover node (using SAP HANA System Replication)
  • SAP HANA tertiary disaster recovery failover node (using SAP HANA System Replication)

  This describes 1 SAP System within the SAP Landscape. An SAP Landscape might use:

  • One Track, 5 SAP Systems (Sandbox > Development > Testing > Staging > Production)
  • Dual Track, 5 SAP Systems (Sandbox > New Feature Development + Maintenance Development > New feature testing + Maintenance testing > Staging > Production)

Therefore for an SAP Landscape potentially 30 to 50 instances of SAP, spread across 10-50 host servers (physical or virtualized) might be required. This is before more business applications are added for specific business operations, industry, or geographic functions.

The size of the SAP Landscapes have a direct impact on the Network Topology.

Typically, although this varies from case to case, the following networks are required to meet the scenarios and performance that is required by the business that uses SAP Business Applications:

• Internal network for communication between multiple instances in an SAP Landscape with different SAP System Tiering approaches
• Network for the management and storage transfers of database systems
• Network that is used in production

However, in the simplest scenario there might be one private network for all purposes. It depends on business requirements.

Networking consumption considerations

Traditional SAP workload network communication is relatively small with under 100 MiB network traffic per day possible, such as:

• User transactions from SAPGUI; for Windows, for Java (used with macOS or Linux)
• User transactions from SAP WebGUI
• User transactions with SAP web Dynpro apps from SAP NetWeaver Business Client (NWBC)
• SAP Remote Function Call (SAP RFC) between SAP and non-SAP systems
• SAP iDOC Inbound/Outbound between SAP and non-SAP systems with third-parties (for example, banks, suppliers)

However, there are much larger SAP workload network communications too consuming significantly more network traffic, such as:

• SAPUI5 preinstall libraries and themes for SAP Fiori Launchpad and Apps
  • 10 MiB - 25 MiB (estimate) per new session that is loaded from SAP web Assistant (also known as. XRay), these preinstall libraries are then cached by the browser. Once cached the libraries are available for use in any new browser tab, even after browser restart or SAP Fiori logout; until browser cache cleared
  • 20 KiB - 500 KiB (estimate) per each new Fiori app that is loaded within the session
• SAP HANA System Replication (HSR) Sync or Async, streaming Gigabyte's of data per month from primary to secondary (or tertiary) nodes

With increased traffic of new design SAP software, it is possible to heavily exceed the amount of network traffic seen in past SAP usage.

Designing your SAP applications to use the IBM Cloud private backbone for these data transfers is important, as there are no ingress/egress charges; whereas usage over public internet incurs egress charges.

You should estimate the amount of data that is transferred. During initial project implementation stages, this can be difficult. However at least by an order of magnitude estimate should be performed.

Networking Throughput performance considerations

SAP generally recommends 10 Gbps (redundant) network throughput for traffic between its application servers and SAP HANA databases, and for other SAP HANA clients, such as SAP Business Intelligence.

For deployments of SAP NetWeaver using SAP AnyDB with local storage, even for three-tier setups, 1 Gbps networks are usually sufficient.

Networking Latency performance considerations

For your business operations and non-SAP dependent systems, you may required certain latency key performance indicators (KPIs) to be met. This should consider the site location of your hosts, and testing the latency by using the IBM Cloud private backbone network.

The testing of latency by using the Round Trip Time (RTT) metric is necessary when designing High Availability (HA) and Disaster Recovery (DR) for SAP HANA.

If a HA failover is being designed within one site location, in almost all cases this will be achievable for SAP HANA System Replication requirements.

However, if designing High Availability for SAP HANA across multiple sites within a Region, or if designing Disaster Recovery across multiple Regions then the latency that uses the Round Trip Time (RTT) metric must be carefully tested and considered.

This is because IBM Cloud seeks to ensure high availability of the platform, by using geographically dispersed site locations with fault tolerance (for example, different risk assessments). More information available on How IBM Cloud ensures high availability and disaster recovery.

In particular, for VPC Infrastructure the Availability Zones are geographically dispersed locations within the Region. For most workloads, this design provides more redundancy across the Region. However, SAP HANA System Replication requires low network latency, which can become difficult to meet the necessary Round Trip Time (RTT) metric due to current technology physical data transfer limitations of cabling from a physics perspective (that is, speed of light over fiber Optic cable).

Networking Ports security considerations

The following information is a brief summary of SAP Help Portal - TCP/IP Ports of All SAP Products, which provides an example of the considerations that are required for the security of your SAP Systems and entire IT infrastructure landscape on IBM Cloud.

Depending on the SAP Technical Applications used and the business scenarios being addressed, different hosts will need ports to be opened. Typically, to meet this requirement, the Firewall Port Groups are combined with Firewall Rules. You can also use individual Firewall Rules per host, although is often becomes unmanageable.

The below table includes some of the key Ports to use with SAP Systems that use SAP NetWeaver and SAP HANA, which need correction, depending on the SAP Technical Application’s instance number; the instance numbers 00, 01, 02 are the defaults across the various SAP Technical Applications and will be in different patterns (these patterns are shown with code blocks highlighting):

Networking Traffic Segregation security considerations

You can separate different network traffic types in your landscape, either because of security restrictions or because of throughput considerations.

Segregation of networks is useful for the following SAP workload use cases:

• Multiple servers that exchange data
  • SAP Systems in a three-tier logical architecture, where the SAP database and SAP application instances are on different hosts.
• Multiple SAP Systems that exchange large amounts of data
  • Database servers, which need to have low network latency and high network throughput to network block/file storage therefore need to avoid firewalls. However the database still needs protection for other systems and networks access.

To use segregation of networks effectively, interconnectivity must be allowed under specific conditions.