Storage Architecture for SAP on Azure | Guided by A Guide to Cloud

Why storage matters for SAP HANA

☁️ Mei pulls up a performance graph. “Raj, we picked the VMs. Now comes the part that makes or breaks HANA performance — storage. HANA is an in-memory database, but it still writes to disk constantly: transaction logs, savepoints, backups. If the disks are slow, HANA stalls.”

🏗️ Raj looks at the graph. “What kind of speeds are we talking about?”

☁️ Mei circles a number. “For log volumes, HANA needs sub-millisecond write latency. For data volumes, it needs sustained high throughput for savepoints. Get this wrong and your finance team will be waiting for month-end closing.”

Simple explanation

Think of HANA like a chef working at a kitchen counter.

The counter (RAM) is where the actual cooking happens — fast and immediate. But the chef constantly jots notes in a logbook (log volume) to remember what was done, and periodically puts finished dishes into the fridge (data volume). If the logbook is slow to write in, the chef stops cooking and waits. If the fridge door sticks, plating is delayed. Fast storage means the chef never has to pause.

Azure storage options for SAP

Storage options for SAP workloads
Feature	Premium SSD v2	Ultra Disk	Azure NetApp Files (ANF)	Azure Files (NFS)
Typical SAP use	HANA data + log, app tier	HANA log (extreme IOPS)	HANA shared, scale-out, HA file shares	Transport directory, ASCS shares
Max IOPS	Up to 80,000 per disk	Up to 400,000 per disk	Varies by tier and volume size	Up to 100,000 per share
Latency	Sub-millisecond	Sub-millisecond (consistently)	Sub-millisecond	Low milliseconds
Resizable IOPS/throughput	Yes — independent of capacity	Yes — independent of capacity	Adjustable via service tier	Scales with share size
Write Accelerator support	Not needed (already fast enough)	Not needed	Not applicable (NFS)	Not applicable (NFS)
Cost model	Pay for provisioned capacity + IOPS + throughput	Pay for provisioned capacity + IOPS + throughput	Pay for capacity pool and consumed storage	Pay for provisioned capacity

Premium SSD v2

Premium SSD v2 is the recommended default for most SAP HANA deployments. Its key advantage is that you can independently tune capacity, IOPS, and throughput — you pay for exactly what you need. For a typical HANA system, you can set high IOPS on the log volume and high throughput on the data volume without over-provisioning capacity.

Ultra Disk

Ultra Disk provides the absolute lowest and most consistent latency. It is the premium choice for HANA log volumes on very high-transaction systems. Like Premium SSD v2, you can tune IOPS and throughput independently. The trade-off is higher cost and limited availability in some regions.

Azure NetApp Files (ANF)

ANF is a managed NFS service that excels at shared storage scenarios. For SAP, it is commonly used for HANA shared volumes in scale-out deployments, shared file systems for HA clusters (replacing Shared Disks on Linux), and NFS-based storage for ASCS high availability.

Write Accelerator

Write Accelerator is a special M-series feature that provides ultra-low write latency for Premium SSD (v1) managed disks. It caches writes in a battery-backed buffer on the host.

Available only on M-series VMs
Required for HANA log volumes when using Premium SSD v1
Not needed for Premium SSD v2 or Ultra Disk (they are already fast enough)
Limited to 4 KB aligned writes — perfect for HANA log I/O patterns

Exam tip: Write Accelerator triggers

If the exam mentions M-series VM + Premium SSD (v1) + HANA log volume, the answer involves Write Accelerator. If the question mentions Premium SSD v2 or Ultra Disk, Write Accelerator is not needed because those storage types already deliver sub-millisecond latency natively.

HANA storage layout

A properly designed HANA VM has distinct volumes for each purpose:

Log volume (/hana/log): Transaction log writes — latency is critical. Use Premium SSD v2 or Ultra Disk. SAP recommends at least 250 MB/s write throughput and sub-1 ms latency.

Data volume (/hana/data): Savepoints and data persistence — throughput is critical. Use Premium SSD v2 or Ultra Disk with multiple disks striped using LVM for aggregate throughput.

Shared volume (/hana/shared): HANA binaries, trace files, backup catalog. Use Premium SSD or ANF. Lower performance requirements.

Backup volume (/hana/backup): Local backup staging before transfer to Azure Backup vault. Use Standard SSD or Premium SSD — capacity matters more than speed.

📐 Architecture diagram: Open the HANA Storage Layout diagram in Excalidraw to see all five HANA volumes with their recommended storage types.

🏗️ Raj sketches the layout. “So four mount points, each with different performance requirements.”

☁️ Mei nods. “Exactly. And for the data volume, we stripe multiple disks together to get aggregate throughput. A single disk cannot deliver enough for a large HANA savepoint.”

Stripe configurations for HANA data

For HANA data volumes, use LVM (Logical Volume Manager) to stripe 3 to 4 Premium SSD v2 disks into a single volume group. The stripe size should align with HANA’s 256 KB I/O block size. This multiplies the throughput across disks. SAP provides specific recommendations in the Azure HANA storage guide — expect the exam to test whether you know to stripe data volumes but not log volumes (log volumes use a single disk to minimize latency).

Question

Why does SAP HANA need sub-millisecond write latency on the log volume?