Network connectivity requirements for SAP workloads on virtual server instances in IBM Cloud VPC

Key networking concepts for VPC

Understanding the following VPC networking concepts is essential for planning your SAP landscape:

• Virtual Private Cloud (VPC): An isolated network environment within IBM Cloud where you deploy your resources.
• Subnets: Subdivisions of your VPC's IP address range, associated with specific availability zones.
• Availability zones: Geographically dispersed locations within a region that provide fault tolerance and high availability.
• Address prefixes: IP address ranges assigned to availability zones within your VPC.
• Security groups: Instance-level firewalls that control inbound and outbound traffic for virtual server instances.
• Network access control lists (ACLs): Subnet-level firewalls that control traffic entering and leaving subnets.
• Floating IPs: Public IPv4 addresses that can be assigned to virtual server instances for internet access.
• Public gateways: Enable outbound internet connectivity for an entire subnet.
• Virtual Private Endpoints (VPE): Private connectivity to IBM Cloud services without traversing the public internet.

Network hierarchy

The VPC networking components are organized in the following hierarchy:

1. Global: IBM Cloud global network backbone.
2. Region: Geographic location where a VPC is deployed, for example, us-south, eu-de.
3. VPC: An isolated virtual network within a region.
4. Availability zone: A fault-isolated data center within a region.
5. Address prefix: An IP address range assigned to an availability zone.
6. Subnet: A subdivision of an address prefix where resources are deployed.

Every IBM Cloud® Virtual Private Cloud is created for a specific region and spans multiple availability zones within that region. This design provides high availability and fault tolerance for your SAP workloads.

Subnets and address prefixes

When you deploy a VPC in an availability zone, an address prefix is assigned to that zone. Each VPC zone contains one or more subnets that you can define manually by choosing the IP range and subnet mask, or by specifying the number of IP addresses needed.

Key considerations for subnet planning:

• Each subnet is associated with a single availability zone.
• Subnets within the same VPC can communicate with each other by default unless blocked by ACLs or security groups.
• Multiple subnets help to separate different types of network traffic.
• Virtual server instances are deployed into subnets and can attach to multiple subnets.

For SAP workloads, consider creating separate subnets for:

• SAP application servers
• SAP database servers
• Management and administration systems
• Backup and disaster recovery systems

Connectivity within VPC

Resources within the same VPC communicate with each other through the private network by default. This includes communication between:

• Virtual server instances in the same subnet.
• Virtual server instances in different subnets within the same VPC.
• Virtual server instances across different availability zones within the same VPC.

Communication between resources is controlled by security groups and network ACLs, which you configure based on your security requirements.

Connectivity to the internet

For SAP workloads that require internet connectivity, IBM Cloud VPC provides two options:

Floating IP

A public IPv4 address that can be attached to a virtual server instance network interface. This enables inbound connections from the internet to the instance. Floating IPs are typically used for:

• Initial setup and configuration.
• Jump servers or bastion hosts.
• Web-facing SAP applications, with appropriate security controls.

Public gateway

Public gateway provides outbound-only internet access for all virtual server instances in a subnet. This enables instances to:

• Download operating system updates and patches.
• Access external services and APIs.
• Connect to SAP support systems.

For production SAP systems, minimize or eliminate direct internet connectivity and use private connectivity options instead.

Connectivity to on-premises networks

Most SAP landscapes require secure connectivity between cloud-based systems and on-premises infrastructure. IBM Cloud VPC provides two primary options:

Connectivity to IBM Cloud services

SAP workloads often need to integrate with other IBM Cloud services such as IBM Cloud Object Storage, Cloud Databases, or IBM® Key Protect for IBM Cloud®.

Connectivity between VPCs

For complex SAP landscapes spanning multiple VPCs, you can establish connectivity using:

IBM Cloud® Transit Gateway

Connects multiple VPCs within the same region or across regions, enabling communication between resources in different VPCs. This is useful for:

• Separating production and non-production environments.
• Implementing hub-spoke network architectures.
• Connecting SAP systems across different VPCs.

VPC peering

Establishes direct connectivity between two VPCs, allowing resources to communicate as if they were in the same network.

Connectivity to Classic Infrastructure

If you have existing resources in IBM Cloud Classic Infrastructure, you can connect them to your VPC using Transit Gateway. This enables:

• Gradual migration from Classic to VPC Infrastructure.
• Hybrid deployments spanning both environments.
• Access to Classic Infrastructure services from VPC.

For more information, see Setting up access to classic infrastructure.

Network bandwidth

Virtual Servers for VPC provides network bandwidth based on the virtual server instance profile.

• Total network bandwidth ranges from 4 Gbps to 64 Gbps depending on the profile.
• Each virtual network interface (vNIC) has a maximum throughput of 16 Gbps.
• You can attach up to 5 vNICs to a virtual server instance to maximize throughput.

For SAP workloads:

• SAP HANA systems typically require 10 Gbps or higher network bandwidth.
• SAP application servers generally require 1-4 Gbps depending on the workload.
• Consider network bandwidth when sizing your virtual server instances.

Network latency

Network latency is particularly important for:

• Communication between SAP application servers and database servers.
• SAP HANA System Replication for high availability and disaster recovery.
• Real-time data processing and analytics workloads.

Key considerations:

• Latency within the same availability zone is typically less than 1 ms.
• Latency between availability zones in the same region is typically 2-5 ms.
• Latency between regions varies based on geographic distance.
• Test latency using Round Trip Time (RTT) measurements before implementing high availability or disaster recovery solutions.

For SAP HANA System Replication:

• Synchronous replication requires RTT less than 1 ms (typically the same availability zone).
• Asynchronous replication can tolerate higher latency (cross-region scenarios).

Network throughput for SAP HANA scale-out

SAP HANA multi-node (scale-out) systems require specific network configurations:

Client network

Connects SAP application servers, SAP HANA Studio clients, and other clients to the SAP HANA system. Network throughput requirements depend on:

• Amount of data transferred to and from the database.
• Number of concurrent users and transactions.
• Availability and performance requirements.

Storage network

Connects to network storage (file or block storage). Requirements include:

• Sufficient throughput to provide 10,000 IOPS to each SAP HANA node.
• Low latency for optimal storage performance.

Internode network

Used for communication between SAP HANA nodes. This network should have:

• High bandwidth for data transfer between nodes.
• Low latency for optimal cluster performance.
• Equivalent performance to the storage network.

To maximize performance and redundancy for SAP HANA scale-out, you can attach up to 5 network interfaces (vNICs) on multiple subnets to each virtual server instance.

Security groups

Security groups act as virtual firewalls at the instance level, controlling inbound and outbound traffic for virtual server instances. Key characteristics:

• Applied to network interfaces (vNICs) of virtual server instances.
• Stateful: Return traffic is automatically allowed.
• Allow-only rules: You specify what traffic is permitted.
• Can be applied to multiple instances.
• Rules can reference other security groups.

Best practices for SAP workloads:

• Create separate security groups for different SAP components (application servers, database servers, web dispatchers).
• Implement least-privilege access: Only allow necessary ports and protocols.
• Use security group references instead of IP addresses for internal communication.
• Regularly review and update security group rules.

Default security group rules typically allow:

• SSH (port 22) for Linux instances.
• RDP (port 3389) for Windows instances.
• ICMP (ping) for network diagnostics.

You should restrict these rules to specific source IP addresses or ranges based on your security requirements.

Network access control lists (ACLs)

Network ACLs provide subnet-level security, controlling traffic entering and leaving subnets. Key characteristics:

• Applied to subnets.
• Stateless: Both inbound and outbound rules must be configured.
• Support both allow and deny rules.
• Rules are evaluated in order (lowest priority number first).
• Default ACL allows all traffic.

Best practices for SAP workloads:

• Use ACLs for broad subnet-level controls.
• Use security groups for fine-grained instance-level controls.
• Consider the impact on required services (DNS, OS updates, monitoring).
• Document ACL rules and their purposes.
• Test ACL changes in non-production environments first.

For more information, see Security in your VPC.

Network traffic segregation

Segregating network traffic improves both security and performance. Common segregation strategies for SAP workloads include:

Separate subnets for different tiers

• Front end subnet: Web dispatchers, SAP Fiori launchpad
• Application subnet: SAP application server
• Database subnet: SAP HANA or other database systems
• Management subnet: Jump servers, monitoring systems, backup infrastructure

Separate subnets for different environments

• Production subnet.
• Non-production subnet (development, test, QA).
• Disaster recovery subnet.

Separate subnets for different security zones

• DMZ subnet: Internet-facing components.
• Internal subnet: Backend systems.
• Restricted subnet: Highly sensitive data and systems.

While virtual server instances in VPC can be attached to multiple subnets, each vNIC can only be associated with one subnet. Plan your subnet architecture accordingly.

Single-zone deployment

A single-zone deployment places all SAP components in one availability zone. This topology is suitable for:

• Development and test environments.
• Non-critical workloads.
• Proof-of-concept implementations.

Characteristics:

• Simplest network topology.
• Lowest latency between components.
• No high availability across zones.
• Lower cost.

Multi-zone deployment

A multi-zone deployment distributes SAP components across multiple availability zones within a region. This topology provides:

• High availability for SAP systems.
• Fault tolerance against zone failures.
• Disaster recovery within the same region.

Considerations:

• Higher network latency between zones (typically 2-5 ms).
• More complex network configuration.
• Higher cost due to redundant resources.
• Requires careful planning for SAP HANA System Replication.

Multi-region deployment

A multi-region deployment spans multiple IBM Cloud regions. This topology provides:

• Geographic redundancy.
• Disaster recovery across regions.
• Compliance with data residency requirements.
• Support for global SAP landscapes.

Considerations:

• Highest network latency between regions.
• Most complex network configuration.
• Highest cost.
• Requires asynchronous SAP HANA System Replication.
• May require multiple Direct Link connections.

Hybrid cloud deployment

A hybrid cloud deployment combines on-premises infrastructure with IBM Cloud VPC. This topology enables:

• Gradual migration to cloud.
• Burst capacity for peak workloads.
• Integration with existing SAP systems.
• Compliance with data residency requirements.

Considerations:

• Requires Direct Link or VPN connectivity.
• Network latency depends on connection type and distance.
• Bandwidth limitations may impact performance.
• Complex network routing and security configuration.

SAP HANA high availability

For SAP HANA high availability using System Replication:

• Deploy primary and secondary nodes in different availability zones (for zone-level HA).
• Ensure network latency between zones meets SAP requirements (typically < 1 ms for synchronous replication).
• Configure separate subnets for client, storage, and internode communication.
• Use security groups to control access between nodes.
• Consider using Virtual Private Endpoints for backup to Object Storage.

SAP application server high availability

For SAP application server high availability:

• Deploy ASCS/ERS instances in different availability zones.
• Use Application Load Balancer for distributing traffic to application servers.
• Configure security groups to allow cluster communication.
• Ensure network connectivity for shared file systems (NFS).
• Plan for floating IP addresses or a load balancer for failover.

SAP S/4HANA three-tier architecture

For SAP S/4HANA three-tier deployments:

• Front end tier: Web Dispatcher in public subnet (if internet-facing) or private subnet.
• Application tier: SAP application server in dedicated subnet.
• Database tier: SAP HANA in separate, more restricted subnet.
• Use security groups and ACLs to control traffic between tiers.
• Consider using Virtual Private Endpoints for integration with IBM Cloud services.

SAP landscape with multiple systems

For complex SAP landscapes with multiple systems:

• Use separate VPCs for production and non-production environments.
• Connect VPCs using Transit Gateway.
• Implement Hub-spoke network topology with shared services VPC.
• Use consistent subnet naming and IP addressing schemes.
• Document network topology and connectivity paths.

Flow logs

Flow Logs for VPC capture information about IP traffic flowing to and from network interfaces. Use flow logs to:

• Monitor network traffic patterns.
• Troubleshoot connectivity issues.
• Detect security threats.
• Analyze network performance.
• Support compliance and auditing requirements.

Network monitoring tools

Consider implementing:

• IBM Cloud Monitoring for network performance metrics.
• IBM Cloud Activity Tracker for network configuration changes.
• Custom monitoring solutions for SAP-specific network metrics.
• Network latency monitoring between SAP components.