You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -64,6 +64,8 @@ In the SAP workload documentation space, you can find the following areas:
64
64
65
65
## Change Log
66
66
67
+
- August 03, 2023: Change of recommendation to use a /25 IP range for delegated subnet for ANF for SAP workload [NFS v4.1 volumes on Azure NetApp Files for SAP HANA](./hana-vm-operations-netapp.md)
68
+
- August 03, 2023: Change in support of block storage and NFS on ANF storage for SAP HANA documented in [SAP HANA Azure virtual machine storage configurations](./hana-vm-operations-storage.md)
67
69
- July 25, 2023: Adding reference to SAP Note #3074643 to [Azure Virtual Machines Oracle DBMS deployment for SAP workload](./dbms-guide-oracle.md)
68
70
- July 13, 2023: Clarifying dfifferences in zonal replication between NFS on AFS and ANF in table in [Azure Storage types for SAP workload](./planning-guide-storage.md)
69
71
- July 13, 2023: Statement that 512byte and 4096 sector size for Premium SSD v2 do not show any performance difference in [SAP HANA Azure virtual machine Ultra Disk storage configurations](./hana-vm-ultra-disk.md)
Copy file name to clipboardExpand all lines: articles/sap/workloads/hana-vm-operations-netapp.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ ms.service: sap-on-azure
9
9
ms.subservice: sap-vm-workloads
10
10
ms.topic: article
11
11
ms.workload: infrastructure
12
-
ms.date: 12/28/2022
12
+
ms.date: 08/02/2023
13
13
ms.author: juergent
14
14
ms.custom: H1Hack27Feb2017
15
15
---
@@ -29,7 +29,7 @@ When considering Azure NetApp Files for the SAP Netweaver and SAP HANA, be aware
29
29
- The minimum capacity pool is 4 TiB
30
30
- The minimum volume size is 100 GiB
31
31
- ANF-based NFS shares and the virtual machines that mount those share must be in the same Azure Virtual Network or in [peered virtual networks](../../virtual-network/virtual-network-peering-overview.md) in the same region
32
-
- The selected virtual network must have a subnet, delegated to Azure NetApp Files. The subnet requires a minimum of a /28 IP address range. Ideally a /26 would be better if many ANF volumes should be mounted to VMs in the specific VNET
32
+
- The selected virtual network must have a subnet, delegated to Azure NetApp Files. **For SAP workload, it is highly recommended to configure a /25 range for the subnet delegeated to ANF.**
33
33
- It's important to have the virtual machines deployed sufficient proximity to the Azure NetApp storage for lower latency as, for example, demanded by SAP HANA for redo log writes.
34
34
- Azure NetApp Files meanwhile has functionality to deploy NFS volumes into specific Azure Availability Zones. Such a zonal proximity is going to be sufficient in the majority of cases to achieve a latency of less than 1 millisecond. The functionality is in public preview and described in the article [Manage availability zone volume placement for Azure NetApp Files](../../azure-netapp-files/manage-availability-zone-volume-placement.md). This functionality isn't requiring any interactive process with Microsoft to achieve proximity between your VM and the NFS volumes you allocate.
35
35
- To achieve most optimal proximity, the functionality of [Application Volume Groups](../../azure-netapp-files/application-volume-group-introduction.md) is available. This functionality isn't only looking for most optimal proximity, but for most optimal placement of the NFS volumes, so, that HANA data and redo log volumes are handled by different controllers. The disadvantage is that this method needs some interactive process with Microsoft to pin your VMs.
Copy file name to clipboardExpand all lines: articles/sap/workloads/hana-vm-operations-storage.md
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ ms.service: sap-on-azure
9
9
ms.subservice: sap-vm-workloads
10
10
ms.topic: article
11
11
ms.workload: infrastructure
12
-
ms.date: 10/09/2022
12
+
ms.date: 08/03/2023
13
13
ms.author: juergent
14
14
ms.custom: H1Hack27Feb2017
15
15
---
@@ -18,13 +18,13 @@ ms.custom: H1Hack27Feb2017
18
18
19
19
Azure provides different types of storage that are suitable for Azure VMs that are running SAP HANA. The **SAP HANA certified Azure storage types** that can be considered for SAP HANA deployments list like:
To learn about these disk types, see the article [Azure Storage types for SAP workload](./planning-guide-storage.md) and [Select a disk type](../../virtual-machines/disks-types.md)
26
26
27
-
Azure offers two deployment methods for VHDs on Azure Standard and premium storage. We expect you to take advantage of [Azure managed disk](https://azure.microsoft.com/services/managed-disks/) for Azure block storage deployments.
27
+
Azure offers two deployment methods for VHDs on Azure Standard and premium storage v1/v2. We expect you to take advantage of [Azure managed disk](https://azure.microsoft.com/services/managed-disks/) for Azure block storage deployments.
28
28
29
29
For a list of storage types and their SLAs in IOPS and storage throughput, review the [Azure documentation for managed disks](https://azure.microsoft.com/pricing/details/managed-disks/).
30
30
@@ -34,42 +34,42 @@ For a list of storage types and their SLAs in IOPS and storage throughput, revie
34
34
35
35
The minimum SAP HANA certified conditions for the different storage types are:
36
36
37
-
- Azure premium storage - **/hana/log** is required to be supported by Azure [Write Accelerator](../../virtual-machines/how-to-enable-write-accelerator.md). The **/hana/data** volume could be placed on premium storage without Azure Write Accelerator or on Ultra disk
38
-
- Azure Ultra disk at least for the **/hana/log** volume. The **/hana/data** volume can be placed on either premium storage without Azure Write Accelerator or in order to get faster restart times Ultra disk
37
+
- Azure premium storage v1 - **/hana/log** is required to be supported by Azure [Write Accelerator](../../virtual-machines/how-to-enable-write-accelerator.md). The **/hana/data** volume could be placed on premium storage v1 without Azure Write Accelerator or on Ultra disk. Azure premium storage v2 or Azure premium SSD v2 is not supporting the usage of Azure Write Accelerator
38
+
- Azure Ultra disk at least for the **/hana/log** volume. The **/hana/data** volume can be placed on either premium storage v1/v2 without Azure Write Accelerator or in order to get faster restart times Ultra disk
39
39
-**NFS v4.1** volumes on top of Azure NetApp Files for **/hana/log and /hana/data**. The volume of /hana/shared can use NFS v3 or NFS v4.1 protocol
40
40
41
-
Some of the storage types can be combined. For example, it's possible to put **/hana/data** onto premium storage and **/hana/log** can be placed on Ultra disk storage in order to get the required low latency. If you use a volume based on ANF for **/hana/data**, **/hana/log** volume needs to be based on NFS on top of ANF as well. Using NFS on top of ANF for one of the volumes (like /hana/data) and Azure premium storage or Ultra disk for the other volume (like **/hana/log**) is **not supported**.
41
+
Based on experience gained with customers, we changed the support for combining different storage types between **/hana/data** and **/hana/log**. It is supported to combine the usage of the different Azure block storages that are certified for HANA AND NFS shares based on Azure NetApp Files. For example, it's possible to put **/hana/data** onto premium storage v1 or v2 and **/hana/log** can be placed on Ultra disk storage in order to get the required low latency. If you use a volume based on ANF for **/hana/data**, **/hana/log** volume can be placed on one of the HANA certified Azure block storage types as well. Using NFS on top of ANF for one of the volumes (like **/hana/data**) and Azure premium storage v1/v2 or Ultra disk for the other volume (like **/hana/log**) is **supported**.
42
42
43
43
In the on-premises world, you rarely had to care about the I/O subsystems and its capabilities. Reason was that the appliance vendor needed to make sure that the minimum storage requirements are met for SAP HANA. As you build the Azure infrastructure yourself, you should be aware of some of these SAP issued requirements. Some of the minimum throughput characteristics that SAP is recommending, are:
44
44
45
45
- Read/write on **/hana/log** of 250 MB/sec with 1 MB I/O sizes
46
46
- Read activity of at least 400 MB/sec for **/hana/data** for 16 MB and 64 MB I/O sizes
47
47
- Write activity of at least 250 MB/sec for **/hana/data** with 16 MB and 64 MB I/O sizes
48
48
49
-
Given that low storage latency is critical for DBMS systems, even as DBMS, like SAP HANA, keep data in-memory. The critical path in storage is usually around the transaction log writes of the DBMS systems. But also operations like writing savepoints or loading data in-memory after crash recovery can be critical. Therefore, it's **mandatory** to use Azure premium storage, Ultra disk, or ANF for **/hana/data** and **/hana/log** volumes.
49
+
Given that low storage latency is critical for DBMS systems, even as DBMS, like SAP HANA, keep data in-memory. The critical path in storage is usually around the transaction log writes of the DBMS systems. But also operations like writing savepoints or loading data in-memory after crash recovery can be critical. Therefore, it's **mandatory** to use Azure premium storage v1/v2, Ultra disk, or ANF for **/hana/data** and **/hana/log** volumes.
50
50
51
51
52
52
Some guiding principles in selecting your storage configuration for HANA can be listed like:
53
53
54
54
- Decide on the type of storage based on [Azure Storage types for SAP workload](./planning-guide-storage.md) and [Select a disk type](../../virtual-machines/disks-types.md)
55
55
- The overall VM I/O throughput and IOPS limits in mind when sizing or deciding for a VM. Overall VM storage throughput is documented in the article [Memory optimized virtual machine sizes](../../virtual-machines/sizes-memory.md).
56
56
- When deciding for the storage configuration, try to stay below the overall throughput of the VM with your **/hana/data** volume configuration. SAP HANA writing savepoints, HANA can be aggressive issuing I/Os. It's easily possible to push up to throughput limits of your **/hana/data** volume when writing a savepoint. If your disk(s) that build the **/hana/data** volume have a higher throughput than your VM allows, you could run into situations where throughput utilized by the savepoint writing is interfering with throughput demands of the redo log writes. A situation that can impact the application throughput
57
-
- If you're considering using HANA System Replication, the storage used for **/hana/data** on each replica must be same and the storage type used for **/hana/log** on each replica must be same. For example, using Azure premium storage for **/hana/data** with one VM and Azure Ultra disk for **/hana/data** in another VM running a replica of the same HANA System replication configuration, isn't supported
57
+
- If you're considering using HANA System Replication, the storage used for **/hana/data** on each replica must be same and the storage type used for **/hana/log** on each replica must be same. For example, using Azure premium storage v1 for **/hana/data** with one VM and Azure Ultra disk for **/hana/data** in another VM running a replica of the same HANA System replication configuration, isn't supported
58
58
59
59
60
60
> [!IMPORTANT]
61
61
> The suggestions for the storage configurations in this or subsequent documents are meant as directions to start with. Running workload and analyzing storage utilization patterns, you might realize that you're not utilizing all the storage bandwidth or IOPS provided. You might consider downsizing on storage then. Or in contrary, your workload might need more storage throughput than suggested with these configurations. As a result, you might need to deploy more capacity, IOPS or throughput. In the field of tension between storage capacity required, storage latency needed, storage throughput and IOPS required and least expensive configuration, Azure offers enough different storage types with different capabilities and different price points to find and adjust to the right compromise for you and your HANA workload.
62
62
63
63
64
64
## Stripe sets versus SAP HANA data volume partitioning
65
-
Using Azure premium storage you may hit the best price/performance ratio when you stripe the **/hana/data** and/or **/hana/log** volume across multiple Azure disks. Instead of deploying larger disk volumes that provide the more on IOPS or throughput needed. Creating a single volume across multiple Azure disks can be accomplished with LVM and MDADM volume managers, which are part of Linux. The method of striping disks is decades old and well known. As beneficial as those striped volumes are to get to the IOPS or throughput capabilities you may need, it adds complexities around managing those striped volumes. Especially in cases when the volumes need to get extended in capacity. At least for **/hana/data**, SAP introduced an alternative method that achieves the same goal as striping across multiple Azure disks. Since SAP HANA 2.0 SPS03, the HANA indexserver is able to stripe its I/O activity across multiple HANA data files, which are located on different Azure disks. The advantage is that you don't have to take care of creating and managing a striped volume across different Azure disks. The SAP HANA functionality of data volume partitioning is described in detail in:
65
+
Using Azure premium storage v1 you may hit the best price/performance ratio when you stripe the **/hana/data** and/or **/hana/log** volume across multiple Azure disks. Instead of deploying larger disk volumes that provide the more on IOPS or throughput needed. Creating a single volume across multiple Azure disks can be accomplished with LVM and MDADM volume managers, which are part of Linux. The method of striping disks is decades old and well known. As beneficial as those striped volumes are to get to the IOPS or throughput capabilities you may need, it adds complexities around managing those striped volumes. Especially in cases when the volumes need to get extended in capacity. At least for **/hana/data**, SAP introduced an alternative method that achieves the same goal as striping across multiple Azure disks. Since SAP HANA 2.0 SPS03, the HANA indexserver is able to stripe its I/O activity across multiple HANA data files, which are located on different Azure disks. The advantage is that you don't have to take care of creating and managing a striped volume across different Azure disks. The SAP HANA functionality of data volume partitioning is described in detail in:
66
66
67
67
-[The HANA Administrator's Guide](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/40b2b2a880ec4df7bac16eae3daef756.html?q=hana%20data%20volume%20partitioning)
68
68
-[Blog about SAP HANA – Partitioning Data Volumes](https://blogs.sap.com/2020/10/07/sap-hana-partitioning-data-volumes/)
Reading through the details, it's apparent that applying this functionality takes away complexities of volume manager based stripe sets. You also realize that the HANA data volume partitioning isn't only working for Azure block storage, like Azure premium storage. You can use this functionality as well to stripe across NFS shares in case these shares have IOPS or throughput limitations.
72
+
Reading through the details, it's apparent that applying this functionality takes away complexities of volume manager based stripe sets. You also realize that the HANA data volume partitioning isn't only working for Azure block storage, like Azure premium storage v1/v2. You can use this functionality as well to stripe across NFS shares in case these shares have IOPS or throughput limitations.
73
73
74
74
75
75
## Linux I/O Scheduler mode
@@ -94,14 +94,14 @@ If you're using LVM or mdadm to build stripe sets across several Azure premium d
94
94
> [!NOTE]
95
95
> You don't need to configure any redundancy level using RAID volumes since Azure block storage keeps three images of a VHD. The usage of a stripe set with Azure premium disks is purely to configure volumes that provide sufficient IOPS and/or I/O throughput.
96
96
97
-
Accumulating multiple Azure disks underneath a stripe set, is accumulative from an IOPS and storage throughput side. So, if you put a stripe set across over 3 x P30 Azure premium storage disks, it should give you three times the IOPS and three times the storage throughput of a single Azure premium Storage P30 disk.
97
+
Accumulating multiple Azure disks underneath a stripe set, is accumulative from an IOPS and storage throughput side. So, if you put a stripe set across over 3 x P30 Azure premium storage v1 disks, it should give you three times the IOPS and three times the storage throughput of a single Azure premium Storage v1 P30 disk.
98
98
99
99
> [!IMPORTANT]
100
100
> In case you're using LVM or mdadm as volume manager to create stripe sets across multiple Azure premium disks, the three SAP HANA FileSystems /data, /log and /shared must not be put in a default or root volume group. It's highly recommended to follow the Linux Vendors guidance which is typically to create individual Volume Groups for /data, /log and /shared.
101
101
102
102
103
-
## Azure Premium Storage configurations for HANA
104
-
For detailed HANA storage configuration recommendations using Azure premium storage, read the document [SAP HANA Azure virtual machine Premium SSD storage configurations](./hana-vm-premium-ssd-v1.md)
103
+
## Azure Premium Storage v1 configurations for HANA
104
+
For detailed HANA storage configuration recommendations using Azure premium storage v1, read the document [SAP HANA Azure virtual machine Premium SSD storage configurations](./hana-vm-premium-ssd-v1.md)
105
105
106
106
## Azure Premium SSD v2 configurations for HANA
107
107
For detailed HANA storage configuration recommendations using Azure premium ssd v2 storage, read the document [SAP HANA Azure virtual machine Premium SSD v2 storage configurations](./hana-vm-premium-ssd-v2.md)
![prmerger-automator[bot]](https://avatars.githubusercontent.com/u/22479449?v=4&size=40){kind=avatar}
0 commit comments