Target Sizing Estimation

Module: Migrate SAP Workloads to Azure

Lesson: Target Sizing Estimation

Introduction: Why Sizing is the Foundation of SAP on Azure

Migrating SAP workloads—such as SAP S/4HANA, SAP BW/4HANA, or traditional SAP NetWeaver—to Microsoft Azure is a significant undertaking that requires precision. At the heart of this migration lies "sizing," the process of determining the exact compute, memory, storage, and networking requirements for your SAP system in the cloud. Unlike on-premises environments where you might have "headroom" built into your physical hardware, Azure operates on a consumption-based model. If you undersize, your users experience performance degradation and system instability. If you oversize, you pay for expensive resources that sit idle, ballooning your operational costs unnecessarily.

Sizing is not merely a technical task; it is a financial and operational bridge between your current state and your future cloud reality. When you move to Azure, you are effectively translating your existing SAP workload metrics into Azure Virtual Machine (VM) specifications. This process requires a deep understanding of how SAP measures performance (using SAPS) and how Azure maps these metrics to its diverse catalog of VM families. Getting this right ensures that your SAP landscape remains performant, reliable, and cost-effective throughout its lifecycle in the cloud.

Understanding the SAPS Metric

To size SAP systems, we use the SAP Application Performance Standard (SAPS). SAPS is a hardware-independent unit of measurement that describes the performance of an SAP application server. One hundred SAPS is defined as 2,000 fully business-processed order line items per hour in the standard Sales and Distribution (SD) benchmark. Because this metric is platform-agnostic, it allows us to compare your existing on-premises hardware performance directly against the performance of Azure VMs.

Before you can determine your target infrastructure, you must know your current SAPS consumption. You can obtain this by running the SAP Quick Sizer tool or by analyzing your existing production logs. Most SAP customers have a baseline of their current system performance. If you are migrating a legacy system, you should look at the peak utilization periods rather than the average, as the infrastructure must be capable of handling your highest load without bottlenecks.

Callout: SAPS vs. vCPU A common misconception is that vCPU count is the primary driver of performance. In reality, the architecture of the processor and the memory bandwidth play a massive role. An Azure VM with 16 vCPUs might have a vastly different SAPS rating than a different VM family with the same vCPU count. Always verify the SAPS rating in the official SAP on Azure documentation rather than assuming performance based on core counts alone.

Step-by-Step Sizing Methodology

The sizing process follows a logical flow that begins with data collection and ends with an infrastructure design. Follow these steps to ensure your estimate is accurate.

Step 1: Data Collection and Assessment

Gather historical data from your current environment. You need to identify the CPU, memory, and database throughput requirements. If you are using SAP HANA, the memory requirement is the most critical factor because the entire database must fit into the RAM of the target VM. For traditional databases like SQL Server or Oracle, CPU and I/O throughput (measured in IOPS and MB/s) take precedence.

Step 2: Utilize the SAP Quick Sizer Tool

SAP provides the Quick Sizer tool, which is a web-based application that allows you to calculate the hardware requirements based on your specific business processes. You input your anticipated business volume (e.g., number of invoices per day, number of users, database growth projections) and the tool outputs the required SAPS and memory.

Step 3: Mapping to Azure VM Families

Once you have your SAPS and memory requirements, you map them to Azure VM families. Azure categorizes its VMs based on workload types:

• M-Series: Designed for large-scale, memory-intensive workloads like SAP HANA.
• E-Series: Balanced, memory-optimized VMs suitable for application servers and smaller HANA databases.
• D-Series: General-purpose VMs suitable for smaller, non-production environments.
• Mv2/Mv3-Series: The top-tier machines for massive, mission-critical S/4HANA production databases.

Step 4: Storage Sizing (The Hidden Bottleneck)

Compute is only half the battle. SAP workloads are extremely sensitive to storage latency. You must calculate the required IOPS (Input/Output Operations Per Second) for your database logs and data files. Azure Managed Disks (Premium SSD or Ultra Disk) must be sized to meet the throughput requirements of your specific SAP database.

Practical Example: Sizing an S/4HANA Environment

Let’s assume you are planning to migrate an S/4HANA system that requires 80,000 SAPS and 1 TB of RAM for the HANA database.

1. Memory Requirement: Since the database must reside in memory, you need a minimum of 1 TB of RAM. You should add a buffer of 20% for future growth and operating system overhead, bringing your requirement to 1.2 TB.
2. VM Selection: Looking at the Azure VM catalog, you might identify the M128ms VM, which provides 2 TB of memory. This fits your requirement perfectly.
3. SAPS Validation: Check the SAP Certified IaaS platforms website to confirm the SAPS rating for the M128ms. If it provides, for example, 100,000 SAPS, you are well within the safe zone for your 80,000 SAPS requirement.
4. Storage Layout: You need to map your HANA data and log volumes to Azure Premium SSDs. Using the Azure Storage calculator, you would provision enough disks in a stripe (RAID 0 via LVM or Storage Spaces) to meet the required latency of less than 1ms for log writes.

Note: Always consult the "SAP HANA on Azure" documentation provided by Microsoft. It contains specific configuration guides for disk stripping and stripe sizes that are mandatory to achieve SAP certification for your storage layout.

Code Snippet: Automating Disk Throughput Verification

While manual calculation is common, you can use Azure CLI or PowerShell to verify the performance limits of your provisioned infrastructure. Below is a PowerShell snippet to check the throughput limits of a specific disk SKU.

# Get the details of a specific Azure Managed Disk
$disk = Get-AzDisk -ResourceGroupName "SAP-Production" -DiskName "HANA-Data-Disk-01"

# Extract the performance tier and IOPS limit
$iopsLimit = $disk.DiskIOPSReadWrite
$throughputLimit = $disk.DiskMBpsReadWrite

Write-Host "Disk IOPS Limit: $iopsLimit"
Write-Host "Disk Throughput Limit: $throughputLimit MB/s"

# Compare against HANA requirements
if ($iopsLimit -lt 5000) {
    Write-Warning "Disk IOPS below the minimum required for HANA data volumes."
}

Explanation: This script pulls the metadata of an existing Azure disk. In an automated deployment pipeline, you would use such logic to validate that the infrastructure provisioned by your Infrastructure-as-Code (IaC) templates meets the minimum SAP performance standards before the SAP installation begins.

Best Practices for Infrastructure Design

1. High Availability (HA) Considerations: Sizing is not just for a single VM. You must size for the secondary (standby) node. In an HA setup, both the primary and secondary nodes must be identically sized to ensure that a failover does not result in a performance drop.
2. Proximity Placement Groups (PPG): When sizing your application servers and database servers, ensure they are placed in a Proximity Placement Group. This reduces network latency between the application and the database, which is vital for the performance of the SAP stack.
3. Use Accelerated Networking: Always enable Accelerated Networking on your SAP VMs. This feature uses SR-IOV (Single Root I/O Virtualization) to provide consistent, low-latency network performance, which is a requirement for most SAP on Azure certifications.
4. Avoid Over-Provisioning: While it is tempting to pick the largest VM to "be safe," Azure allows for vertical scaling. Start with a size that meets your current peak, and utilize Azure’s ability to resize the VM if your business grows. This saves significant capital in the early stages of the migration.

Comparison: Sizing for HANA vs. NetWeaver

Callout: Memory is King for HANA The most common mistake in SAP HANA sizing is underestimating the memory footprint of the database. HANA loads the entire database into RAM. If your database grows beyond the RAM capacity of your VM, the system will crash or force a hard stop. Always account for data growth projections over the next 24 months when selecting your initial memory size.

Common Pitfalls and How to Avoid Them

1. Ignoring Network Latency: Many architects focus entirely on the VM and the disk, forgetting that the network path between the user and the VM is part of the "system." If your users are located in a different region than your Azure datacenter, the latency will make the SAP GUI feel sluggish, even if your backend is perfectly sized. Use ExpressRoute to provide a dedicated, low-latency connection.

2. The "Average Load" Trap: Never size based on the average CPU utilization of your on-premises server. SAP systems are characterized by "bursty" traffic—the start of the month, the end of the quarter, or the daily login spike. Size for the peak load. If you size for the average, your system will be unresponsive during the times your business needs it most.

3. Forgetting the Non-Production Environment: It is common to size the production environment perfectly but treat non-production as an afterthought. If your "Quality Assurance" or "Development" environments are too small, your testing will not accurately reflect production performance. You might pass UAT (User Acceptance Testing) only to find that the system slows to a crawl when moved to the production-sized environment.

4. Neglecting OS and Backup Overhead: Every VM requires resources for the Operating System, monitoring agents (like the Azure Monitor for SAP solutions), and backup processes. Always ensure that your chosen VM has at least 10–15% "overhead" capacity beyond your calculated SAPS and memory requirements.

Step-by-Step Instructions: Validating Your Sizing

To validate that your proposed infrastructure is sufficient before you commit to the migration, follow this systematic approach:

1. Run the SAP Performance Trace: In your current system, run transaction ST03N to identify the peak load times and the associated resource usage.
2. Map to Azure: Use the "SAP on Azure" sizing spreadsheet provided by Microsoft. This tool allows you to input your ST03N findings and maps them to specific Azure VM SKUs.
3. Simulate Disk Throughput: Use a tool like fio (on Linux) or DiskSpd (on Windows) to test the throughput of the Azure storage volumes you intend to use. Ensure they hit the required MB/s for your database transaction logs.
4. Perform a "Pilot Migration": Before the full migration, move a smaller, non-critical workload to the target infrastructure. Monitor the performance metrics in Azure Monitor to see if the reality matches your sizing estimates.
5. Review with Stakeholders: Present your findings to the business. If the cost of the sized infrastructure is too high, discuss the trade-offs. Can you move some non-critical data to colder storage? Can you optimize your database to reduce the memory footprint?

Industry Standards and Best Practices

In the enterprise world, sizing is governed by the SAP/Microsoft partnership. You must adhere to the "Certified IaaS Platform" list. If you choose an Azure VM that is not certified for SAP workloads, you will not receive support from SAP in the event of a system failure. This is a critical risk. Always check the "SAP Certified and Supported SAP HANA Hardware Directory" before finalizing your choice.

Furthermore, consider the "Scale-out" vs. "Scale-up" architecture. For S/4HANA, the industry standard is to scale up (larger VM) until you hit the limit of the largest available VM. Scale-out (multiple VMs for one database) adds significant complexity in terms of networking and data synchronization and should only be used when you have exceeded the capacity of the largest single VM available in your region.

Frequently Asked Questions (FAQ)

Q: Can I change my VM size after I have deployed the SAP system? A: Yes, Azure allows you to resize your VMs (Vertical Scaling). You will need to stop the VM, change the size in the portal, and restart it. While this is straightforward, it does require a scheduled maintenance window.

Q: Do I need to size for the database and the application server separately? A: Yes. The database is usually memory-intensive and requires high-performance storage, while the application server is CPU-intensive. Often, these roles are separated onto different VMs, each with its own sizing requirements.

Q: What happens if my database grows faster than expected? A: You should monitor your HANA memory utilization using the HANA Studio or Cockpit. If you approach 80% of your total RAM capacity, it is time to plan a resize to a larger VM SKU.

Q: Are there automated tools to help with sizing? A: Yes, Microsoft offers the "Azure Migrate" service, which includes an assessment tool that can look at your on-premises environment and recommend Azure VM sizes based on actual performance data.

Key Takeaways

1. SAPS is the Universal Language: Use the SAPS metric to ensure your cloud infrastructure matches your current performance baseline, regardless of the underlying hardware.
2. Memory is the HANA Bottleneck: Always prioritize the RAM requirements for HANA databases, ensuring you factor in growth projections and operating system overhead.
3. Storage Throughput Matters: Compute is useless if your storage cannot keep up. Ensure your Azure Managed Disk configuration meets the latency requirements for your specific database engine.
4. Size for Peak, Not Average: Avoid the common pitfall of sizing for average utilization. Your infrastructure must be able to handle peak business hours without failing.
5. Use Certified Hardware: Always cross-reference your chosen Azure VM SKUs with the official SAP Certified IaaS platform list to ensure you remain within the bounds of vendor support.
6. Leverage Vertical Scaling: Start with an appropriately sized VM and utilize Azure’s capability to scale up vertically as your business requirements evolve, rather than over-provisioning from day one.
7. Validate with Testing: Never rely solely on theoretical calculations. Use pilot migrations and disk throughput testing to verify your design in a real-world scenario before committing to the production cutover.

By following these guidelines, you move away from guesswork and toward a scientific approach to infrastructure sizing. This not only protects the stability of your SAP environment but also ensures that your organization maximizes the value of its investment in the Azure cloud. Remember that sizing is an iterative process; as your business changes, your infrastructure should be reviewed and adjusted accordingly to maintain the optimal balance between performance and cost.