Compute Network Storage with RISE

SAP RISE Integration: Compute, Network, and Storage Foundations

Introduction: Understanding the RISE Paradigm

When organizations decide to transition their SAP workloads to the cloud, the conversation often shifts from "how do we move this" to "who manages this." SAP RISE (Relationship-based Infrastructure and Services Experience) is a managed service offering designed to simplify this transition by providing a subscription-based model where SAP takes responsibility for the underlying infrastructure and technical management. However, even with SAP managing the "Managed Managed Services" (MMS) layer, the technical architecture remains rooted in Azure’s core building blocks: Compute, Network, and Storage.

Understanding these three pillars is critical for any SAP architect or administrator because, while SAP manages the OS and the application layer, the integration with your existing enterprise network, security policies, and data management strategies still falls under your purview. If you do not grasp how these components interact within the RISE framework, you risk performance bottlenecks, security gaps, and unexpected latency that can degrade the user experience for your entire organization.

This lesson explores the technical underpinnings of SAP RISE on Azure. We will dissect how compute instances are sized and deployed, how the virtual network must be structured to accommodate high-throughput SAP traffic, and how storage tiers are selected to ensure the HANA database—the heart of modern SAP systems—performs as expected. By the end of this guide, you will have a clear mental model of how to interface your internal resources with the managed environment provided by SAP.

1. Compute: The Engine of SAP RISE

In the SAP RISE model, compute resources are primarily delivered using Azure Virtual Machines (VMs). SAP selects the specific VM families based on the workload requirements, typically utilizing M-series or E-series instances for HANA databases and application servers. While you do not manually provision these VMs in your own subscription, understanding the resource allocation is vital for troubleshooting and capacity planning.

The Role of Memory and CPU

SAP HANA is an in-memory database, which means the primary constraint on your compute sizing is RAM. Unlike traditional relational databases that rely heavily on disk I/O, HANA needs to keep the "hot" data in volatile memory to execute queries in milliseconds. In the RISE model, SAP adheres to the "Certified SAP HANA Hardware Directory." This ensures that the VMs allocated to your production environment have been rigorously tested for performance consistency.

When reviewing your RISE architecture, you should look for these configurations:

• M-series VMs: These are the workhorses for large-scale HANA production databases. They offer high memory-to-core ratios, which are essential for keeping large datasets in memory without incurring the cost of excessive CPU cores that you might not need.
• E-series VMs: These are typically reserved for SAP application servers (ASCS/ERS) and smaller non-production environments. They provide a balanced memory-to-CPU ratio that suits the general-purpose nature of application processing.

Callout: Managed vs. Unmanaged Compute In a standard Azure deployment, you have full control over the VM lifecycle, including patching and kernel updates. In SAP RISE, SAP manages the Operating System layer (SUSE or RHEL). This means you cannot simply SSH into the server to install random agents or update kernels. Your compute interaction is limited to the application layer and the configuration of the SAP software itself.

Best Practices for RISE Compute

To ensure your compute environment remains stable, prioritize the following:

1. Capacity Monitoring: Even though SAP manages the infrastructure, you must monitor the utilization of your application servers. If your batch jobs are consistently hitting CPU limits, you need to coordinate with SAP to resize the instances.
2. Proximity Placement Groups (PPG): Ensure that your application servers and database servers are placed in the same proximity group. This minimizes the physical distance between the compute nodes, significantly reducing network latency, which is the number one cause of "sluggish" SAP performance.
3. Availability Sets and Zones: Always confirm that your production RISE environment is distributed across multiple Azure Availability Zones. This provides a baseline level of resilience against localized data center failures.

2. Networking: The Backbone of Connectivity

Networking is perhaps the most complex area of SAP RISE integration. Because your RISE environment lives in an Azure subscription managed by SAP, you are essentially connecting two separate entities: your corporate Azure environment (where your users, power BI reports, and other apps reside) and the SAP-managed environment.

Virtual Network Peering and Private Link

The standard way to connect your resources to the RISE environment is through Virtual Network (VNet) Peering. This allows traffic to flow between your virtual network and the SAP-managed virtual network as if they were on the same private network.

• VNet Peering: This is the most efficient way to achieve low-latency connectivity. You define the peering, and traffic stays within the Azure backbone, never touching the public internet.
• Private Link: If you need to expose specific services (like a web interface for Fiori) to your internal users without opening up the entire network, Private Link provides a secure, private endpoint for your services.

Network Latency and Throughput

SAP requires very low latency between the application server and the database. If your network design introduces more than 1-2 milliseconds of latency, you will notice a significant drop in application performance.

Warning: The Latency Trap Never route your SAP traffic through a centralized firewall in a different region. If your application server is in East US and your firewall is in West US, the round-trip time will kill your SAP performance. Always use "Direct Peering" or local network gateways to keep traffic within the same region.

Step-by-Step: Setting Up Connectivity

1. Request the RISE VNet Details: SAP will provide the VNet address space for your RISE environment.
2. Check for Overlaps: Ensure your internal corporate IP ranges do not overlap with the RISE environment. If they do, you will need to implement NAT (Network Address Translation), which adds complexity and potential performance overhead.
3. Configure Peering: In the Azure Portal, navigate to your VNet, select "Peerings," and add a new peering connection to the SAP-provided VNet resource ID.
4. Update Routing Tables: Ensure that your route tables are updated to point traffic destined for the SAP application layer toward the peered connection.

3. Storage: Performance and Persistence

Storage in SAP RISE is architected based on the specific needs of the HANA database. HANA requires extremely fast write speeds for its log files and high throughput for its data files. SAP handles the underlying storage configuration, typically using Azure Managed Disks with specific performance tiers.

Understanding Storage Tiers

For HANA, SAP uses the following storage breakdown:

• Data Disk: This is where the database sits. It requires high throughput to load data into memory during startup and to handle large read operations.
• Log Disk: This is the most critical disk for performance. Every transaction in SAP must be written to the log file before it is confirmed. If this disk is slow, the entire application will hang. RISE environments typically use Ultra Disk or Premium SSD v2 to ensure sub-millisecond latency.
• Backup/Shared Disk: This is used for database backups and the sapmnt directory. Performance is less critical here, so standard Premium SSDs are usually sufficient.

Data Protection and Backup

Even though SAP manages the RISE infrastructure, your data strategy remains your responsibility. You need to ensure that the backup policies (RPO/RTO) align with your business requirements.

• RPO (Recovery Point Objective): How much data can you afford to lose? With HANA, you should be aiming for a 15-minute log backup interval.
• RTO (Recovery Time Objective): How quickly do you need to be back up? This depends on how fast the storage can restore the data.

Tip: Storage Throughput Always check the throughput limits of your VM size. Even if you have a fast disk, if the VM itself is capped at 500 MB/s, you will never see the performance you expect. Use the "Azure VM Disk Limits" documentation to verify that your chosen VM size supports the throughput requirements of your SAP database.

4. Practical Implementation: Infrastructure as Code (IaC)

While you don't build the RISE environment, you often build the surrounding infrastructure (like your jump boxes, integration layers, or reporting tools) using Terraform or Bicep. Writing clean, modular code is essential for maintaining consistency.

Example: Bicep for VNet Peering

Below is a simplified example of how you might define a peering connection in Bicep to connect your environment to the SAP RISE VNet.

resource peering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2021-02-01' = {
  name: 'peering-to-sap-rise'
  properties: {
    remoteVirtualNetwork: {
      id: '/subscriptions/{sap-subscription-id}/resourceGroups/{rg-name}/providers/Microsoft.Network/virtualNetworks/{rise-vnet-name}'
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    useRemoteGateways: false
  }
}

Explanation:

• remoteVirtualNetwork: This points to the SAP-managed resource. You need the exact resource ID provided by your SAP account team.
• allowVirtualNetworkAccess: This is set to true to ensure that VMs in your VNet can communicate with VMs in the SAP VNet using their private IP addresses.
• useRemoteGateways: This is set to false unless you are specifically using the SAP RISE environment to route your corporate traffic, which is rarely the case.

5. Security and Governance

Security in an SAP RISE environment is a shared responsibility. While SAP secures the underlying host and the SAP application, you are responsible for the identities that access the system, the network security groups (NSGs) that govern traffic flow, and the encryption of data at rest.

Identity and Access Management (IAM)

You should use Azure Active Directory (now Microsoft Entra ID) to manage access to the SAP landscape. Implement Conditional Access policies to ensure that only authorized devices from corporate-approved locations can access the SAP GUI or Fiori web portals.

Network Security Groups (NSGs)

Even with peering, you should implement strict NSGs on your side of the connection. Define rules that only allow traffic on the specific ports required by SAP (e.g., 32xx for SAP GUI, 443 for HTTPS/Fiori). Never leave ports open to the entire internal network.

Comparison: Standard Azure vs. RISE Security

6. Common Pitfalls and How to Avoid Them

Pitfall 1: Ignoring DNS Resolution

Many organizations struggle with name resolution between their internal network and the SAP RISE VNet. If your application servers cannot resolve the FQDN of your internal services, the integration will fail.

• Solution: Use Azure Private DNS Zones. Link your internal VNet and the SAP-provided VNet to a central Private DNS Zone to ensure seamless resolution.

Pitfall 2: Over-provisioning Storage

It is tempting to throw the most expensive, highest-performance storage at every SAP server. This leads to massive, unnecessary monthly costs.

• Solution: Follow the SAP sizing guidelines precisely. Only use Ultra Disk for the HANA log volume; use Standard SSD or Premium SSD for non-critical volumes.

Pitfall 3: Neglecting Monitoring

"SAP manages the infrastructure" does not mean you stop monitoring. If the SAP system is slow, your users will blame the network, not the database.

• Solution: Use Azure Monitor and Log Analytics to track the performance of your peered connections. If you see latency spikes, you have data to bring to your SAP account manager.

7. Key Takeaways

1. Shared Responsibility: SAP RISE manages the infrastructure (OS, Database, Hardware), but you are responsible for the network integration, security policies, and identity management.
2. Network Proximity is King: Keep your application servers and database servers as close as possible within the Azure region to minimize latency, which is the primary driver of SAP performance.
3. Storage Tiers Matter: HANA databases are storage-sensitive. Ensure that you are using high-performance tiers (Ultra/Premium SSD v2) for log volumes to prevent transaction bottlenecks.
4. DNS is a Common Blocker: Do not overlook the importance of a solid DNS strategy when connecting your corporate VNet to the SAP RISE VNet.
5. Monitor Your Traffic: Even in a managed environment, use Azure monitoring tools to keep an eye on network latency and peering health.
6. IaC for Integration: Use Bicep or Terraform to manage your side of the integration to ensure that network configurations and peering remain consistent and auditable.
7. Right-Sizing: Trust the SAP sizing documentation for VM families. Avoid the urge to over-provision, as SAP RISE costs are tied to the underlying infrastructure footprint.

By mastering these foundational elements, you move from being a passive recipient of a managed service to an active architect who can troubleshoot, optimize, and secure the SAP landscape. Remember that while SAP handles the "heavy lifting," the integration into your broader enterprise ecosystem is what determines the success of your digital transformation journey.