Supported SAP Deployment Scenarios

Lesson: Supported SAP Deployment Scenarios on Azure

Introduction: Why Deployment Scenarios Matter

Migrating SAP workloads to the cloud is not a simple "lift and shift" operation. Because SAP environments are often the central nervous system of an enterprise, the underlying infrastructure must be architected with extreme precision. Choosing the right deployment scenario on Azure is the foundation of your entire migration strategy. It dictates your performance, your ability to scale, your compliance posture, and ultimately, your total cost of ownership.

When we talk about "supported SAP deployment scenarios," we are referring to the specific architectural patterns—ranging from single-node instances to complex, multi-region high availability clusters—that Microsoft and SAP have jointly certified. If you choose a configuration that isn't explicitly supported, you risk performance bottlenecks, data corruption, and, most importantly, a lack of support from SAP should a technical failure occur. Understanding these scenarios allows you to align your technical requirements with Azure’s cloud-native capabilities, ensuring that your SAP estate is not just running, but running optimally.

In this lesson, we will dissect the primary deployment architectures, the specific infrastructure requirements for each, and the decision-making framework you need to navigate these choices successfully.

The Spectrum of SAP Deployment Architectures

SAP deployments on Azure generally fall into three distinct categories: Single-node, High Availability (HA), and Disaster Recovery (DR). Each category serves a different business need and carries specific infrastructure requirements.

1. The Single-Node Deployment (Non-Production)

The single-node deployment is the simplest form of SAP architecture. In this scenario, the SAP application server and the database (such as HANA or AnyDB) reside on a single virtual machine (VM). This is almost exclusively used for sandbox, development, or training environments where high availability is not a priority.

• Infrastructure Requirements:

  • Sizing must account for the memory and CPU requirements of both the application layer and the database layer simultaneously.
  • Managed disks must be sized to accommodate the data growth of both the database and the application file systems.
  • Network throughput must be sufficient to handle both internal SAP traffic and user-facing traffic.

• Best Practice: Even in non-production, avoid over-provisioning. Use Azure Autoscale or schedule VM shutdowns during off-hours to manage costs effectively.

2. The Multi-Tier Deployment (Production)

In a production environment, you separate the application server layer from the database layer. This is the industry standard for SAP. By decoupling these layers, you gain the ability to scale them independently. If your application tier is struggling under a high volume of concurrent users, you can add more application server VMs without touching the database infrastructure.

• Infrastructure Requirements:
  • Proximity Placement Groups (PPG): You must place your application servers and database servers in a PPG to ensure low latency between the tiers.
  • Accelerated Networking: Always enable Accelerated Networking on your VMs to reduce latency and jitter.
  • Dedicated Subnets: Isolate your database tier in its own subnet to allow for granular Network Security Group (NSG) rules.

3. High Availability (HA) and Disaster Recovery (DR)

High availability ensures that your SAP system remains operational even if an individual component, a rack, or an entire datacenter fails. This is achieved through clustering. For SAP HANA, this typically involves a primary node and a secondary node synchronized via HANA System Replication (HSR).

Callout: The Difference Between HA and DR High Availability (HA) is designed to keep your system running despite local failures (like a hardware crash or a single VM failure) within a single region using Availability Zones. Disaster Recovery (DR) is designed to keep your business running after a catastrophic event that takes out an entire Azure region, usually by replicating data to a geographically distant region.

Detailed Infrastructure Requirements: Choosing the Right VM

The most critical decision you will make is selecting the correct Azure VM series. SAP has strict certification requirements for VMs running HANA and other database workloads.

Certified VM Families for SAP

Azure offers several VM families specifically certified for SAP workloads. Choosing the wrong series can lead to a "Not Supported" status from SAP, which can complicate your support tickets.

• M-Series: These are memory-optimized VMs designed for very large HANA databases. They offer high RAM-to-CPU ratios, which is ideal for the in-memory requirements of SAP HANA.
• E-Series: These are general-purpose memory-optimized VMs. They are excellent for the application tier or smaller, non-production database instances.
• Edsv5 / Msv2 Series: These are the latest, most performant iterations. Always check the SAP HANA on Azure documentation to ensure your chosen series is certified for your specific SAP version.

Storage Requirements

SAP HANA requires specific storage performance characteristics. You cannot simply use any disk type.

• Managed Disks: For production HANA, use Premium SSD or Ultra Disk. Standard HDD is never recommended for SAP production workloads.
• Write Accelerator: For M-Series VMs, the Write Accelerator (WA) is a critical feature that improves the write latency for the transaction log (the /hana/log directory).

Warning: Storage Throughput Never ignore the IOPS and throughput limits of your disks. If your disk throughput is lower than what SAP HANA requires for its transaction log, your system will experience severe performance degradation, often manifesting as "hanging" processes during heavy transaction periods.

Step-by-Step: Deploying a Scalable SAP Application Tier

Scaling the SAP application tier is often a requirement when user load increases. Below is the process for setting up a scale-out application tier using Azure Virtual Machine Scale Sets (VMSS) or individual VMs with an Azure Load Balancer.

Step 1: Define the Network Topology

Create a Virtual Network (VNet) with separate subnets for the database, application, and management layers. Ensure that your NSGs are configured to allow traffic on standard SAP ports (e.g., 32xx for Dialog instances, 33xx for Message Server).

Step 2: Configure the Load Balancer

Deploy an Azure Load Balancer to distribute traffic across your application servers.

1. Create a backend pool containing your application server VMs.
2. Configure a health probe to check port 3300 (or your specific message server port).
3. Set the session persistence to "Client IP" to ensure that user sessions remain sticky to a specific application server.

Step 3: Implement Proximity Placement Groups

To ensure the lowest possible network latency, create a Proximity Placement Group and assign your VMs to it during deployment. This ensures that the physical hardware hosting your VMs is in the same data center cluster.

# Example CLI command to create a Proximity Placement Group
az ppg create \
  --name SAPProductionPPG \
  --resource-group SAP-RG \
  --location eastus \
  --type standard

Explanation: The command above creates the logical container that forces the Azure fabric to keep your VMs physically close together. Without this, your VMs could be spread across different racks, increasing network latency.

Comparing Deployment Scenarios

To help you decide which path to take, use the following table to compare the complexity and benefits of each scenario.

Best Practices and Industry Standards

1. Leverage SAP-Specific Azure Extensions

Microsoft provides the "Azure VM Extension for SAP." This agent automates the collection of telemetry data from the OS level and sends it to the Azure portal. This allows you to monitor the health of your SAP system directly from the Azure Monitor dashboard.

2. Automate with Infrastructure as Code (IaC)

Do not deploy SAP infrastructure manually via the portal. Use Terraform or Bicep. By using code, you ensure that your production environment is an exact mirror of your test environment, which is the only way to guarantee consistent performance.

3. Right-Sizing and Monitoring

Your initial sizing is an estimate. Use the Azure Advisor and SAP’s own monitoring tools (like ST06 or DB02) to track actual memory and CPU usage. If you find you are consistently using less than 40% of your allocated resources, consider resizing to a smaller VM to save costs.

4. Backup Strategy

Production SAP systems require a robust backup strategy. Use the Azure Backup for SAP HANA service. It is backint-certified, meaning it integrates directly with the HANA database, allowing you to trigger backups and restores without needing to manage file-level scripts.

Common Pitfalls and How to Avoid Them

Pitfall 1: Ignoring the "SAP Note" Requirement

Many administrators forget to check the specific SAP Notes relevant to the Azure VM series they are using. SAP Notes contain the "fine print" regarding kernel versions, operating system patches, and specific configuration parameters that are mandatory for support.

• The Fix: Always bookmark the "SAP on Azure" landing page and cross-reference your configuration against the latest notes before finalizing a build.

Pitfall 2: Incorrect Storage Pathing

A common mistake is placing the SAP data, log, and backup directories on the same disk or failing to follow the recommended mount point structure.

• The Fix: Follow the SAP-recommended directory structure: /hana/data, /hana/log, and /hana/shared. Each should be on a separate disk or storage volume to prevent I/O contention.

Pitfall 3: Overlooking Network Latency

Even if you have a powerful VM, if your application server is in a different region or availability zone than your database server, your SAP system will feel slow.

• The Fix: Always test your network latency using hdbnsutil or ping between the application and database tiers. The latency should ideally be below 1 millisecond for production workloads.

Callout: The Importance of Latency In an SAP environment, latency is the silent killer. Because SAP HANA is an in-memory database, it expects near-instantaneous responses from the storage layer and the application tier. Any network latency introduced by poor architecture will result in long-running SQL queries, which will eventually time out and crash the SAP application processes.

Deep Dive: High Availability Clusters (Pacemaker)

When you move to a production HA scenario, you are essentially building a cluster. On Linux-based SAP systems (the industry standard), this is managed by Pacemaker.

The Role of the STONITH/Fencing Mechanism

In a cluster, you must have a mechanism to prevent "split-brain" scenarios, where two nodes think they are the primary database. This is handled by a fencing agent (STONITH - "Shoot The Other Node In The Head"). On Azure, this is achieved through the fence_azure_arm agent, which calls the Azure API to reboot or power off the unresponsive node.

Configuration Steps for HA Cluster

1. Install the Cluster Stack: Install pacemaker, corosync, and resource-agents on both nodes.
2. Configure HSR: Set up HANA System Replication so the primary node continuously pushes data to the secondary.
3. Configure the Fence Agent: Use the Azure Service Principal to allow the cluster nodes to communicate with the Azure Resource Manager.
4. Define Cluster Resources: Create the VIP (Virtual IP) resource, the HANA database resource, and the fencing resource.

Example configuration snippet for a cluster resource:

primitive rsc_vip_int_sap1 ocf:heartbeat:IPaddr2 \
  params ip="10.0.0.10" cidr_netmask="24" nic="eth0" \
  op monitor interval="10s" timeout="20s"

Explanation: This snippet defines a Virtual IP (VIP) address that moves between nodes. When the primary node fails, the cluster software moves this IP to the secondary node, ensuring that the SAP application servers do not need to be reconfigured.

The Role of Azure Availability Zones

Availability Zones (AZs) are physically separate datacenters within an Azure region. For mission-critical SAP systems, you should distribute your SAP VMs across at least two different AZs.

• Why AZs? If an entire building in a region experiences a power or cooling failure, your secondary node in a different AZ will remain unaffected.
• Caveat: Distributing across AZs introduces slight network latency. Always perform a latency test to ensure that the cross-zone latency is acceptable for your specific SAP application performance requirements. For most SAP applications, a latency of < 2ms is perfectly acceptable and provides a massive leap in availability compared to a single-zone deployment.

FAQ: Frequently Asked Questions

Q: Can I run SAP HANA on Standard SSDs? A: You can run it, but you shouldn't. SAP HANA requires low-latency, high-throughput storage. Standard SSDs will not provide the performance required for the transaction logs, leading to system instability and poor user experience.

Q: Is it better to scale up or scale out? A: For the database (HANA), it is usually better to "scale up" (move to a larger VM size) until you hit the maximum VM size limits. For the application tier, you should "scale out" (add more VMs) to handle higher user concurrency.

Q: Do I need a separate backup server? A: Not necessarily. With Azure Backup for SAP HANA, the backup process is handled as a service, removing the need to manage a dedicated backup server or storage appliance.

Q: How often should I review my SAP infrastructure? A: You should review your sizing and performance metrics at least once a quarter. SAP workloads are dynamic; as your business grows, your data volume and user count will change, requiring infrastructure adjustments.

Key Takeaways

1. Alignment is Critical: Always ensure your chosen Azure VM series is explicitly certified for your version of SAP HANA. Using non-certified hardware voids your support agreement.
2. Architecture Matters: Never run production SAP systems on single-node architectures. Use multi-tier deployments with distinct subnets for application and database layers to ensure security and performance.
3. Latency is the Bottleneck: Prioritize physical proximity through Proximity Placement Groups (PPG) and monitor network latency closely. If your app and database are too far apart, your system will suffer, regardless of how much CPU or RAM you provide.
4. Storage is Paramount: Treat your disk configuration with the same care as your VM selection. Use Premium SSD or Ultra Disk with the appropriate Write Accelerator settings for transaction logs.
5. Automate for Consistency: Use IaC (Terraform/Bicep) to deploy your infrastructure. Manual deployments are prone to configuration drift, which is the primary cause of "it worked in dev but not in prod" issues.
6. Understand HA/DR: High Availability is about preventing downtime from local failures; Disaster Recovery is about surviving regional outages. A robust SAP strategy requires both.
7. Monitor Proactively: Use the Azure VM extension for SAP and native HANA monitoring tools. Do not wait for a user to report a performance issue; monitor your throughput and latency metrics to identify problems before they impact the business.

By following these guidelines and respecting the architectural constraints of the cloud, you can build an SAP environment on Azure that is reliable, scalable, and fully supported. Remember that your infrastructure is not a static asset—it is a dynamic system that requires constant tuning and alignment with the evolving needs of your SAP landscape.