Skip to content

Commit 660624d

Browse files
committed
acrolinx
1 parent 2242ab8 commit 660624d

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

articles/azure-netapp-files/application-volume-group-considerations.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ services: azure-netapp-files
55
author: b-hchen
66
ms.service: azure-netapp-files
77
ms.topic: conceptual
8-
ms.date: 03/13/2025
8+
ms.date: 04/15/2025
99
ms.author: anfdocs
1010
---
1111
# Requirements and considerations for application volume group for SAP HANA
@@ -31,7 +31,7 @@ This article describes the requirements and considerations you need to be aware
3131
* Determine whether you want to use HANA System Replication (HSR).
3232
HSR enables SAP HANA databases to synchronously or asynchronously replicate from a primary SAP HANA system to a secondary SAP HANA system.
3333
* The expected change rate for the data volume (in case you're using snapshots for backup purposes)
34-
* You must create a VNet and delegated subnet to map the Azure NetApp Files IP addresses.
34+
* You must create a virtual network (VNet) and delegated subnet to map the Azure NetApp Files IP addresses.
3535

3636
It's recommended that you lay out the VNet and delegated subnet at design time.
3737

@@ -45,12 +45,12 @@ This article describes the requirements and considerations you need to be aware
4545
To deploy SAP HANA volumes using the application volume group, you need to ensure that your HANA database VMs and the Azure NetApp Files resources are in close proximity to ensure lowest possible latency. You can achieve close proximity using either of the following deployment methods:
4646

4747
* **Availability zone volume placement (preferred)**
48-
Select the availability zone for the volumes and select Standard network features for the deployment. Neither a proximity placement group nor VM pinning are required for this method.
48+
Select the availability zone for the volumes and select Standard network features for the deployment. You don't need a proximity placement group or VM pinning with availability zone volume placement.
4949
* **Proximity placement group with VM pinning**
5050
The application volume group uses a proximity placement group linked (or anchored) to the database VMs. When passed to the application volume group, the PPG is used to find all Azure NetApp Files resources in close proximity to the database servers. Volumes are deployed using Basic network features.
5151

5252
> [!IMPORTANT]
53-
> A PPG is only anchored and can therefore identify the location of the VMs if at least one VM is started and kept running for the duration of all AVG deployments. If all VMs are stopped, the PPG loses its anchor, and at the next restart, the VMs may move to a different location. This situation could lead to increased latency as Azure NetApp Files volumes are not moved after initial creation.
53+
> A PPG is only anchored and can therefore identify the location of the VMs if at least one VM is started and kept running for the duration of all AVG deployments. If all VMs are stopped, the PPG loses its anchor. At the next restart, the VMs can move to a different location. This situation could lead to increased latency as Azure NetApp Files volumes are not moved after initial creation.
5454
5555
To avoid this situation, you should create an availability set per database and use the **[SAP HANA VM pinning request form](https://aka.ms/HANAPINNING)** to pin the availability set to a dedicated compute cluster. After pinning, you need to add a PPG to the availability set, and then deploy all hosts of an SAP HANA database using that availability set. Doing so ensures that all virtual machines are at the same location. As long as one of the virtual machines is started, the PPG retains its anchor to deploy the AVG volumes.
5656

@@ -61,7 +61,7 @@ To avoid this situation, you should create an availability set per database and
6161

6262
A PPG needs to have at least one VM assigned to it, either directly or via an availability set. The purpose of the PPG is to extract the exact location of a VM and pass this information to AVG to search for Azure NetApp Files resources in the same location for volume creation. This approach works only when at least ONE VM in the PPG is started and kept running. Typically, you should add your database servers to this PPG.
6363

64-
PPGs have the side effect that, if all VMs are shut down, a following restart of VMs does NOT guarantee that they would start in the same location as before. To prevent this situation from happening, it is strongly recommended to use an availability set that has all VMs and the PPG associated to it, and use the [HANA pinning workflow](https://aka.ms/HANAPINNING). The workflow not only ensures that the VMs are not moving if restarted, it also ensures that locations are selected where enough compute and Azure NetApp Files resources are available.
64+
PPGs have the side effect that, if all VMs are shut down, a following restart of VMs does NOT guarantee that they would start in the same location as before. To prevent this situation from happening, it's strongly recommended to use an availability set that has all VMs and the PPG associated to it, and use the [HANA pinning workflow](https://aka.ms/HANAPINNING). The workflow not only ensures that the VMs are not moving if restarted, it also ensures that locations are selected where enough compute and Azure NetApp Files resources are available.
6565

6666
When using a PPG without a pinned availability set, a PPG would lose its anchor if all virtual machines in that PPG are stopped. When the virtual machines are restarted, they might be started in a different location, which can result in a latency increase because the volumes created with the application volume group won't be moved.
6767

@@ -72,7 +72,7 @@ This situation leads to two possible scenarios:
7272
* Stable long-term setup:
7373
Using an availability set in combination with a PPG where the availability set is manually pinned.
7474

75-
With the pinning, it is always assured that the placement of the virtual machine won't be changed even if all machines in the availability set are stopped.
75+
With pinning, it's always assured that the placement of the virtual machine won't be changed even if all machines in the availability set are stopped.
7676

7777
* Temporary setup:
7878
Using a PPG or an availability set in combination with a PPG without any pinning.

0 commit comments

Comments
 (0)