Compute Storage Network Requirements

Module: Migrate SAP Workloads to Azure

Section: Target Infrastructure Requirements

Lesson: Compute, Storage, and Network Requirements

Introduction: Why Infrastructure Design Matters for SAP on Azure

Migrating SAP workloads to the cloud is not a simple "lift and shift" operation. SAP systems—comprising SAP HANA databases, SAP Application Servers (NetWeaver or S/4HANA), and associated middleware—are among the most mission-critical applications in an enterprise environment. Because these systems are highly sensitive to latency, throughput, and memory availability, the underlying infrastructure in Azure must be meticulously planned to ensure performance parity or improvement compared to your on-premises data center.

When we talk about "Target Infrastructure Requirements," we are referring to the specific Azure building blocks required to host your SAP landscape. This includes selecting the right virtual machine (VM) families, configuring storage tiers for high-performance database logs, and designing a network architecture that minimizes latency between the application and the database. If you fail to align your infrastructure with SAP’s specific certification requirements, you risk system instability, slow transaction processing, and potential non-compliance with SAP support policies.

This lesson serves as a deep dive into the three pillars of Azure infrastructure for SAP: Compute, Storage, and Networking. We will move beyond high-level concepts to discuss the specific configurations required to keep your SAP landscape running smoothly. By the end of this module, you will understand how to choose the right VM SKUs, how to map SAP storage requirements to Azure Managed Disks, and how to architect your virtual networks for high availability and security.

Part 1: Compute Requirements for SAP Workloads

SAP workloads are categorized primarily into two groups: the Database Tier (often SAP HANA) and the Application Tier (SAP NetWeaver or S/4HANA Application Servers). Each tier has distinct compute needs. HANA, for instance, is an in-memory database, meaning it requires massive amounts of RAM and high-frequency CPUs. Application servers, by contrast, are more focused on concurrent processing and scaling horizontally.

Selecting the Right VM Families

Azure offers specific VM families that are SAP-certified. You cannot simply pick any VM from the Azure catalog; you must select from the list of SAP-certified hardware. For SAP HANA, you generally look at the M-series, E-series, or specialized M-v2 series.

• M-Series (Memory-Optimized): Designed for large-scale production HANA databases. These VMs offer high memory-to-vCPU ratios, which is exactly what HANA requires to load entire datasets into memory.
• E-Series (Esv3, Edsv4, etc.): Often used for smaller HANA environments, test systems, or SAP Application Servers. They provide a balanced memory-to-CPU ratio and support Premium SSD storage.
• Mv2-Series: The heavy hitters for massive, mission-critical HANA databases that require terabytes of RAM.

Callout: The "Certified" Distinction It is vital to understand that not all Azure VMs are "SAP-certified." SAP publishes a specific list of supported hardware configurations in the SAP Note 1928533. If you deploy a non-certified VM, SAP will not provide support for your environment. Always check the SAP Certified IaaS Platforms website before finalizing your VM SKU selection.

CPU and Memory Considerations

When sizing your compute, you must calculate the SAPS (SAP Application Performance Standard). SAPS is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment. When migrating, you should perform an SAPS analysis of your current on-premises landscape to determine the target Azure footprint.

For the database tier, memory is the primary constraint. You should plan for the size of your current database plus a buffer for growth, and ensure the VM you choose has enough RAM to accommodate the "hot" data in memory. For application servers, you have more flexibility to scale out by adding more VMs, rather than scaling up by adding more cores to a single VM.

Part 2: Storage Requirements for SAP

Storage in an SAP environment is not just about capacity; it is about input/output operations per second (IOPS) and throughput. SAP HANA, in particular, is extremely sensitive to the latency of the storage subsystem where the transaction logs are stored. If the storage cannot keep up with the log writes, the entire system will experience transaction delays.

Azure Managed Disks Tiers

For SAP, you will typically use Azure Premium SSD or Ultra Disk storage. Standard HDD or standard SSD storage are generally insufficient for production SAP database workloads.

• Premium SSD: These disks provide consistent performance and are the standard for most SAP application servers and smaller HANA databases. They offer a balance of cost and speed.
• Ultra Disk: These are the gold standard for high-performance HANA logs. You can dynamically adjust the IOPS and throughput of an Ultra Disk without detaching it from the VM, which is incredibly useful during peak month-end processing periods.

Storage Layout Best Practices

You must separate your storage volumes based on their function within the SAP architecture. Never place the database data, logs, and operating system on the same physical disk.

Note: Always ensure that your storage configuration meets the minimum throughput and IOPS requirements specified by SAP for your particular database size. Using "Write Accelerator" on M-series VMs is a critical best practice for the HANA log volume to reduce latency significantly.

Part 3: Network Requirements

The network architecture is the connective tissue of your SAP landscape. Whether you are connecting your on-premises data center to Azure via ExpressRoute or managing communication between subnets within a VNet, latency is your primary enemy.

VNet Design and Subnetting

A common mistake is creating a "flat" network where all SAP components live on one giant subnet. You should implement a tiered network architecture using Network Security Groups (NSGs) to control traffic flow.

1. Database Subnet: Only the Application Servers should have network access to this subnet. No direct internet access should be permitted.
2. Application Subnet: Hosts the SAP application instances. This subnet communicates with the DB subnet and receives traffic from the user/client subnets.
3. Management/Jumpbox Subnet: Contains your Bastion hosts or management gateways. This is the only point of entry for administrators.

Latency Management

SAP application servers communicate constantly with the HANA database. If these components are placed in different Availability Zones, the network latency might exceed the threshold required for optimal performance. While Availability Zones provide high availability, they introduce a small amount of network latency (usually < 2ms). For most SAP systems, this is acceptable, but for extremely high-transaction environments, you may need to evaluate whether to keep the app and DB in the same zone or use Proximity Placement Groups.

Tip: Proximity Placement Groups A Proximity Placement Group (PPG) is an Azure logical grouping that ensures your VMs are physically located as close to each other as possible within an Azure datacenter. By placing your SAP application servers and HANA database in the same PPG, you minimize the physical distance the data travels, resulting in the lowest possible network latency.

Part 4: Practical Implementation and Configuration

To illustrate how these requirements come together, let’s look at how you might provision a basic SAP HANA environment using an Azure Resource Manager (ARM) template or the Azure CLI.

Step-by-Step: Provisioning Storage for HANA

When you provision your VMs, you must ensure the disks are configured correctly at the OS level (usually Linux). Here is a simplified workflow for setting up the storage volumes on your HANA VM:

1. Create the Managed Disks: Provision the required number of Premium SSDs for the data volume and Ultra Disks for the log volume.
2. Attach to VM: Connect the disks to the target VM using the Azure Portal or CLI.
3. LVM Configuration: Use Logical Volume Manager (LVM) to stripe multiple disks together to achieve the required throughput.

# Example: Creating a stripe of 4 Premium SSDs for HANA Data
# Note: This assumes disks are already attached as /dev/sdc, /dev/sdd, /dev/sde, /dev/sdf

pvcreate /dev/sdc /dev/sdd /dev/sde /dev/sdf
vgcreate vg_hana_data /dev/sdc /dev/sdd /dev/sde /dev/sdf
lvcreate -l 100%FREE -n lv_hana_data vg_hana_data
mkfs.xfs /dev/vg_hana_data/lv_hana_data
mount /dev/vg_hana_data/lv_hana_data /hana/data

Explanation: The code above creates a volume group (VG) from four disks, creates a logical volume (LV) that spans those disks, and formats it with XFS (the recommended file system for SAP HANA). By striping the disks, you multiply the IOPS and throughput, allowing the database to read and write data much faster than a single disk could handle.

Common Pitfalls to Avoid

• Ignoring Disk Caching: For HANA log volumes, you should disable host caching. Enabling read-only or read-write caching on a log volume can cause data corruption or performance degradation.
• Over-sizing the VM: Do not simply select the largest VM available. This leads to wasted costs. Size based on the actual SAPS requirements and memory needs of your workload.
• Forgetting Accelerated Networking: Always enable Accelerated Networking on your SAP VMs. This feature bypasses the virtual switch and provides a direct path from the VM to the network card, significantly reducing latency and CPU overhead.

Part 5: Industry Best Practices

To maintain a resilient and performant SAP environment, you should adhere to these industry-standard practices:

1. Use Availability Sets or Zones: For production, always distribute your application servers across multiple Availability Zones or Availability Sets to protect against datacenter failures.
2. Backup and Recovery: Use Azure Backup for SAP HANA to automate the snapshots of your database. Ensure that your backup strategy includes both local snapshots and long-term retention in a different region.
3. Monitoring: Implement Azure Monitor for SAP solutions. This provides deep visibility into the health of your HANA database, the underlying OS, and the Azure infrastructure, allowing you to catch performance bottlenecks before they impact users.
4. Security Hardening: Use Azure Disk Encryption with Customer-Managed Keys (CMK) to ensure that your data is encrypted at rest. Furthermore, restrict access to your VNet using Application Security Groups (ASGs).

Callout: Infrastructure as Code (IaC) Manually configuring SAP infrastructure is prone to human error. Use Terraform or Bicep to define your infrastructure. By version-controlling your infrastructure code, you ensure that your production, development, and QA environments are identical, which is critical for successful SAP testing and deployment.

Part 6: Comparison of Storage Options

When deciding between these, consider the size of your SAP instance. Smaller systems may perform perfectly fine on Premium SSDs. Large, high-transaction systems (multi-terabyte HANA databases) often benefit from Azure NetApp Files or Ultra Disks due to their superior throughput capabilities.

Part 7: Managing Network Security

Security in an SAP environment is a shared responsibility. While Azure protects the physical hardware, you are responsible for the network traffic rules.

• Network Security Groups (NSGs): Think of these as your firewall rules. You should apply specific rules to allow traffic only on the ports required by SAP (e.g., 32xx for dialog processes, 33xx for message servers).
• ASG (Application Security Groups): Use these to group VMs by their function. For instance, you can create an ASG for "SAP-App-Servers" and a rule that allows the "SAP-App-Servers" ASG to talk to the "SAP-DB-Server" ASG on specific SQL ports. This is much cleaner than managing individual IP addresses.

Part 8: Troubleshooting Infrastructure Bottlenecks

Even with the best planning, you may encounter performance issues. When troubleshooting SAP on Azure, follow this systematic approach:

1. Check Azure Monitor: Look for CPU spikes or memory pressure on the VM. If you are hitting 90%+ CPU consistently, you may need to resize the VM.
2. Verify Disk Latency: Use the iostat or iotop commands in Linux to check the latency of your disk volumes. If the latency on your /hana/log volume is consistently above 1-2 milliseconds, your transaction logs are bottlenecked.
3. Network Throughput: Use tools like iperf to test the throughput between your application servers and the database. If the throughput is lower than expected, check if Accelerated Networking is enabled on all NICs.
4. SAP-Specific Logs: Check the SAP dev_w* trace files. These logs often reveal if the application is waiting on database responses, which points back to a potential storage or network latency issue.

Part 9: Summary and Key Takeaways

Migrating SAP to Azure is a complex undertaking that requires a deep understanding of the underlying infrastructure. By focusing on compute, storage, and networking, you can create a foundation that supports the performance and availability your business demands.

Key Takeaways:

• Certification is Non-Negotiable: Always select VM SKUs that are explicitly SAP-certified. Using non-certified hardware voids your support agreement with SAP.
• Storage Tiers Matter: Treat your database logs as the highest priority. Use Ultra Disks or Azure NetApp Files to ensure the low latency required for HANA transaction logs.
• Network Architecture: Use a tiered subnet approach and Proximity Placement Groups to minimize latency between application and database tiers.
• Automation: Utilize Infrastructure as Code (IaC) tools like Terraform or Bicep to ensure consistency and repeatability across your landscapes.
• Monitoring: Leverage Azure Monitor for SAP to gain proactive visibility into performance bottlenecks before they become outages.
• Security: Implement granular control using Network Security Groups (NSGs) and Application Security Groups (ASGs) to isolate your SAP tiers.
• Performance Testing: Always conduct thorough stress testing before going live to ensure your infrastructure can handle the peak load of your specific business processes.

By following these principles, you will be well-equipped to design, deploy, and maintain a robust SAP environment in Azure that meets the needs of your users and the expectations of your organization. Remember that infrastructure is not a "set it and forget it" task; regular optimization and monitoring are essential to keep your SAP landscape performing at its best.