SAP-Certified Azure VMs

SAP-Certified Azure VMs: Designing and Implementing Infrastructure

Introduction: Why SAP on Azure Matters

When organizations consider moving their critical SAP landscapes to the cloud, the primary concern is rarely just about hardware replacement; it is about ensuring that the business processes—which often form the backbone of the enterprise—continue to run with the performance, reliability, and security they require. SAP systems, particularly those running on HANA databases, have very specific requirements regarding compute power, memory bandwidth, and storage latency. Microsoft Azure has worked closely with SAP to certify specific Virtual Machine (VM) families that meet these rigorous standards.

Understanding SAP-certified Azure VMs is essential for any infrastructure architect or cloud engineer. If you select a VM that is not certified for your specific SAP workload, you risk unsupported configurations, performance bottlenecks that can disrupt financial closing or supply chain operations, and a lack of support from SAP in the event of a critical failure. This lesson explores the technical landscape of SAP-certified compute solutions on Azure, providing the knowledge necessary to design, deploy, and maintain these environments effectively.

Understanding SAP Certification for Azure

SAP certification for cloud infrastructure is not a marketing label; it is a technical validation process. SAP and Microsoft test these VM families under heavy load to ensure they handle the specific memory-to-CPU ratios and I/O throughput requirements of SAP HANA and SAP NetWeaver applications. When a VM is "certified," it means that SAP formally supports running production workloads on that specific hardware configuration.

The Role of SAP Notes

The primary source of truth for all SAP-on-Azure deployments is the SAP Note system. Specifically, SAP Note 1928533 (SAP Applications on Azure: Supported Products and Azure VM Types) acts as the master reference. Before architecting any solution, you must verify the VM type against this note. If you deploy a VM that is not listed for your specific database size or SAP Application Performance Standard (SAPS) requirements, you are essentially operating outside of a supportable boundary.

Callout: Certification vs. Support It is important to distinguish between "supported" and "certified." A VM might be capable of running Linux or Windows, but that does not mean it is certified for SAP HANA. SAP HANA requires specific performance characteristics—such as high memory bandwidth—that are only guaranteed on VM families that have undergone the joint certification process. Always verify the certification for the specific database engine (HANA, ASE, SQL Server, Oracle) you intend to use.

VM Families and Their Use Cases

Azure organizes its VMs into families, each designed for different workload profiles. For SAP, we typically focus on Memory-Optimized and Storage-Optimized families.

Memory-Optimized Families (M-Series)

The M-series is the workhorse for large-scale SAP HANA databases. These VMs provide high memory-to-CPU ratios, which are critical because HANA is an in-memory database. If your HANA database is 2TB in size, you need a VM that can hold that data in RAM while leaving overhead for the operating system and processing tasks.

• Mv2-Series: Designed for very large HANA instances. These offer massive memory capacity and are often used in scale-up scenarios where the entire database resides on a single, large VM.
• Md-Series: These are newer, high-memory offerings that provide even better performance for mission-critical databases by utilizing advanced hardware acceleration and improved interconnects.

General Purpose and Compute-Optimized (D and E-Series)

The D-series is often used for SAP Application Servers (the "App Layer"). Application servers do not require the massive memory footprint of the database; instead, they need good CPU performance to process user requests, background jobs, and interface communications. The E-series is a middle ground, often used for smaller SAP HANA development or test systems where memory is needed, but the extreme scale of the M-series is overkill.

Note: Always look for the "s" suffix in Azure VM names (e.g., E4s_v3). The "s" indicates that the VM supports Premium Storage, which is mandatory for SAP production workloads to ensure consistent disk latency.

Designing the Infrastructure: Key Considerations

When you begin the design phase, you must balance cost, performance, and availability. A common mistake is selecting the largest VM available without considering the actual SAPS requirements. SAPS is a hardware-independent unit of measurement that describes the throughput capacity of an SAP application server.

Determining SAPS Requirements

To calculate your needs, you should use the SAP Quick Sizer tool. This tool analyzes your current business volume—such as the number of invoices processed, the number of concurrent users, and the size of your database—to estimate the required SAPS. Once you have this number, you consult the Azure SAP certification tables to find a VM family that provides the required SAPS while fitting within your budget.

Storage Architecture

Compute is only half the story. SAP HANA requires specific storage performance (IOPS and throughput) for its data and log volumes. Azure provides several storage options:

1. Azure Managed Disks (Premium SSD): The standard for production. You must provision enough disks to meet the throughput requirements defined by SAP.
2. Azure NetApp Files: Often used for very large SAP landscapes where high performance and advanced data management (like snapshots and cloning) are required.
3. Ultra Disk Storage: Used when sub-millisecond latency is required for the HANA log volume, which is the most I/O-sensitive part of the database.

Step-by-Step: Deploying an SAP-Certified VM

Deploying an SAP VM is not just about clicking "Create" in the portal. It requires a structured approach to ensure the environment is ready for SAP installation.

Step 1: Resource Group and Networking

First, establish a dedicated resource group for your SAP landscape. Configure your Virtual Network (VNet) with specific subnets: one for the Application Layer, one for the Database Layer, and one for management/bastion access.

Step 2: Selecting the VM and OS

Choose a certified VM size. Ensure you select an image that is supported by SAP, such as SUSE Linux Enterprise Server (SLES) for SAP Applications or Red Hat Enterprise Linux (RHEL) for SAP Solutions. These images are pre-configured with the necessary kernel parameters and drivers for SAP.

Step 3: Storage Provisioning

When configuring the disks, follow the SAP-recommended striping patterns. For HANA, you typically stripe multiple managed disks into a single logical volume using LVM (Logical Volume Manager) to ensure you hit the required throughput for the HANA data volume.

Step 4: Accelerated Networking

Always enable Accelerated Networking on the VM. This reduces jitter and latency by offloading the network processing to the hardware. For SAP, where the communication between the App Server and Database is constant, this is non-negotiable.

Warning: Never disable Accelerated Networking on a production SAP VM. While it may seem like a minor configuration, the performance impact on inter-VM communication can be significant during high-load periods, potentially causing "time-out" errors in the SAP application.

Best Practices for SAP on Azure

1. Use Proximity Placement Groups (PPG)

To achieve the lowest possible latency between your SAP application servers and your HANA database, place them in a Proximity Placement Group. This ensures that the physical hardware hosting your VMs is in the same datacenter, physically close to each other.

2. Implement Availability Sets or Zones

For high availability, you should deploy your SAP app servers across different Availability Zones. If one zone experiences an outage, your SAP system remains operational. For the database, use HANA System Replication (HSR) across zones to ensure data consistency.

3. Monitoring with Azure Monitor for SAP Solutions

Do not rely on generic infrastructure monitoring. Use "Azure Monitor for SAP Solutions," which is specifically designed to collect metrics from the SAP ABAP stack, the HANA database, and the underlying OS. This allows you to see the health of your SAP environment in a single pane of glass.

Common Pitfalls and How to Avoid Them

Miscalculating Throughput

A common mistake is assuming that a larger VM automatically provides better storage throughput. While larger VMs support more disks, you still have to manually provision the correct number of disks to reach the required IOPS. Always check the "Disk Throughput" limits for the specific VM size you have chosen.

Ignoring Kernel Parameters

SAP requires specific OS-level configurations. If you use a generic Linux image instead of the "for SAP" images provided in the Azure Marketplace, you will have to manually tune the kernel, network stack, and memory settings. This is prone to error. Always use the images specifically built for SAP.

Over-provisioning

While it is tempting to pick the largest VM to "be safe," this leads to massive, unnecessary cloud spend. Use the SAP Quick Sizer results to find the "Goldilocks" VM—one that provides enough performance to meet your peak load without excessive idle capacity.

Tip: If your workload is seasonal (e.g., heavy usage during month-end closing), consider using Azure's ability to resize VMs. You can shut down a smaller VM and start it as a larger size, provided the VM family supports the change.

Scripting the Deployment: A Practical Example

While many organizations use Terraform or Bicep for Infrastructure as Code (IaC), it is helpful to understand the underlying parameters. Below is a conceptual representation of how you might define a VM for an SAP database layer using Azure CLI.

# Example: Creating a VM for an SAP HANA Database
az vm create \
  --resource-group SAP_Prod_RG \
  --name HANA_DB_01 \
  --image suse:sles-sap-15-sp3:gen2 \
  --size Standard_M64s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --accelerated-networking true \
  --storage-sku Premium_LRS

Explanation of the snippet:

• --image: We select the SLES for SAP image, which is optimized for the workload.
• --size: We choose Standard_M64s. The "s" ensures premium storage support, and the M-series provides the memory required for large HANA databases.
• --accelerated-networking: Set to true to ensure low-latency communication.

Advanced Infrastructure: High Availability (HA)

In a production environment, you cannot afford downtime. SAP HANA High Availability is typically achieved through a combination of Azure Load Balancers and HANA System Replication.

1. Primary Node: Handles all read/write traffic.
2. Secondary Node: Keeps an identical copy of the database.
3. Load Balancer: A frontend IP address is shared between the two nodes. If the primary node fails, the load balancer detects the health check failure and reroutes traffic to the secondary node.

This setup requires careful configuration of the Pacemaker/Corosync cluster software on the Linux OS. Understanding how the Azure platform interacts with these cluster managers is a key skill for a senior cloud engineer.

The Importance of Backup and Recovery

SAP infrastructure is useless if you cannot recover from a data corruption event or a ransomware attack. Azure provides "Azure Backup for SAP HANA," which is a backint-certified solution. This means the backup agent integrates directly with the HANA database, allowing you to trigger backups and restores directly from the SAP HANA Studio or the Azure portal.

• Snapshot Backups: Use these for near-instant restoration of large databases.
• Log Backups: Ensure these are frequent (e.g., every 15 minutes) to keep your Recovery Point Objective (RPO) low.
• Retention Policies: Define clear policies that meet your business compliance requirements.

Troubleshooting: When Things Go Wrong

When performance degrades, the first step is to check if you are hitting the limits of your VM. Use Azure Monitor to check:

• CPU Steal Time: If high, the underlying physical host is oversubscribed.
• Disk Queue Depth: If consistently high, you need more disks or faster storage (e.g., Ultra Disk).
• Memory Pressure: If your HANA database is swapping to disk, you have insufficient RAM, and you must move to a larger VM size.

Always correlate these infrastructure metrics with SAP transaction codes like ST06 (Operating System Monitor) and DB02 (Database Performance). If the OS metrics are clean but the SAP metrics show slow performance, the issue is likely at the application layer or within the database query logic, not the Azure VM itself.

Summary: Key Takeaways for Success

Designing SAP infrastructure on Azure requires a blend of SAP-specific knowledge and cloud architecture expertise. By following these principles, you ensure a stable, performant, and supportable environment:

1. Always Reference SAP Notes: Never deploy a configuration that has not been explicitly validated by SAP Note 1928533. It is the foundation of your supportability.
2. Select the Right VM Family: Use Memory-Optimized (M-series) for databases and Compute-Optimized (D/E-series) for application servers. Always look for the "s" suffix to ensure Premium Storage support.
3. Optimize Storage Performance: Use LVM striping for HANA data and log volumes to meet the IOPS and throughput requirements. Do not rely on a single disk for production database workloads.
4. Prioritize Networking: Enable Accelerated Networking and use Proximity Placement Groups to keep latency between the App and DB layers as low as possible.
5. Build for High Availability: Use Availability Zones and HANA System Replication to ensure your business processes can survive a datacenter-level failure.
6. Use Specialized OS Images: Utilize the SLES or RHEL images specifically built for SAP, as they come pre-configured with the necessary kernel tuning.
7. Monitor at the Application Level: Utilize Azure Monitor for SAP Solutions to gain visibility into the health of the entire SAP stack, rather than just the virtual machine metrics.

By treating the infrastructure as a critical extension of the SAP application itself, you move beyond simple "cloud hosting" and into the realm of professional enterprise architecture. This approach minimizes risk, maximizes performance, and ensures that the business can rely on the SAP platform for years to come.