Skip to content

Commit f1f0de7

Browse files
committed
update anf for sap hana
1 parent 3550e68 commit f1f0de7

File tree

1 file changed

+18
-10
lines changed

1 file changed

+18
-10
lines changed

articles/sap/workloads/planning-guide-storage.md

Lines changed: 18 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -281,11 +281,20 @@ Azure NetApp Files is currently supported for several SAP workload scenarios:
281281
> [!NOTE]
282282
> So far no DBMS workloads are supported on SMB based on Azure NetApp Files.
283283
284-
As already with Azure premium storage, a fixed or linear throughput size per GB can be a problem when you're required to adhere to some minimum numbers in throughput. Like this is the case for SAP HANA. With Azure NetApp Files, this problem can become more pronounced than with Azure premium disk. Using Azure premium disk, you can take several smaller disks with a relatively high throughput per GiB and stripe across them to be cost efficient and have higher throughput at lower capacity. This kind of striping doesn't work for NFS or SMB shares hosted on Azure NetApp Files. This restriction resulted in deployment of overcapacity like:
284+
Storage for database applications typically has throughput requirements that do not scale linearly with the size of the volumes, ie log volumes are relatively small in size but require high levels of throughput.
285285

286-
- To achieve, for example, a throughput of 250 MiB/sec on an NFS volume hosted on Azure NetApp Files, you need to deploy 1.95 TiB capacity of the Ultra service level.
287-
- To achieve 400 MiB/sec, you would need to deploy 3.125 TiB capacity. But you may need the over-provisioning of capacity to achieve the throughput you require of the volume. This over-provisioning of capacity impacts the pricing of smaller HANA instances.
288-
- Using NFS on top of Azure NetApp Files for the SAP /sapmnt directory, you're usually going far with the minimum capacity of 100 GiB to 150 GiB that is enforced by Azure NetApp Files. However customer experience showed that the related throughput of 12.8 MiB/sec (using Ultra service level) may not be enough and may have negative impact on the stability of the SAP system. In such cases, customers could avoid issues by increasing the volume of the /sapmnt volume, so, that more throughput is provided to that volume.
286+
Azure NetApp Files allows you to allocate volume throughput independently from volume sizes when using a capacity pool of type [manual QoS](../../azure-netapp-files/azure-netapp-files-service-levels.md#throughput-limit-examples-of-volumes-in-a-manual-qos-capacity-pool).
287+
288+
Here's an example:
289+
290+
- A volume for database files requires 500 MiB/s throughput and 39 TiB capacity
291+
- A volume for log files requires 2000 MiB/s throughput and 1 TiB capacity
292+
293+
You can create a manual QoS capacity pool for this scenario and allocate throughput independently of the volume sizes. The total capacity required is 40 TiB, and the total throughput is 2500 MiB/s. A capacity pool in the Premium service level (64 MiB/s per allocated TiB) accommodates both performance and capacity requirements (40 TiB * 64 TiB/s/TiB = 2560 TiB).
294+
295+
Linear performance scaling would require considerable overprovisioning of the log volume to achieve the throughput requirement. To achieve the 2000 MiB/s throughput for the log volume, you'd need to deploy a capacity pool in the Ultra tier (128 MiB/s per allocated TiB) of 16 TiB, resulting in a wasted capacity of 15 TiB.
296+
297+
Use the [Azure NetApp Files Performance Calculator](https://aka.ms/anfcalc) to get an estimate for your scenario.
289298

290299
The capability matrix for SAP workload looks like:
291300

@@ -298,16 +307,15 @@ The capability matrix for SAP workload looks like:
298307
| Backup storage | Suitable | - |
299308
| Shares/shared disk | Yes | SMB 3.0, NFS v3, and NFS v4.1 |
300309
| Resiliency | LRS and GRS | [GRS available](../../azure-netapp-files/cross-region-replication-introduction.md) |
301-
| Latency | Very low | - |
310+
| Latency | Very low | Typically less than 1 ms |
302311
| IOPS SLA | Yes | - |
303-
| IOPS linear to capacity | strictly linear | Dependent on [Service Level](../../azure-netapp-files/azure-netapp-files-service-levels.md) |
312+
| IOPS linear to capacity | Linear with auto QoS; independent with Manual QoS | Three [service levels](../../azure-netapp-files/azure-netapp-files-service-levels.md) available |
304313
| Throughput SLA | Yes | - |
305-
| Throughput linear to capacity | linear | Dependent on [Service Level](../../azure-netapp-files/azure-netapp-files-service-levels.md) |
314+
| Throughput linear to capacity | Linear with auto QoS; independent with Manual QoS | Three [service levels](../../azure-netapp-files/azure-netapp-files-service-levels.md) available |
306315
| HANA certified | Yes | - |
307316
| Disk snapshots possible | Yes | - |
308-
| Azure Backup VM snapshots possible | No | - |
309-
| Costs | Higher than Premium storage | - |
310-
317+
| Azure Backup VM snapshots possible | No | Use [AzAcSnap](../../azure-netapp-files/azacsnap-introduction.md) or [SnapCenter](https://docs.netapp.com/us-en/snapcenter/concept/concept_snapcenter_overview.html) |
318+
| Costs | Competitive when including benefits of snapshots and integrated backup | - |
311319

312320
Other built-in functionality of Azure NetApp Files storage:
313321

0 commit comments

Comments
 (0)