update graphic

Author: b-ahibbard

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

@@ -16,10 +16,10 @@ This article describes the requirements and considerations you need to be aware
 
 * You need to use the [manual QoS capacity pool](manage-manual-qos-capacity-pool.md) functionality.  
 * Application volume group supports Basic and Standard network features. To use features including availability zone volume placement, use [Standard network features](azure-netapp-files-network-topologies.md).
-* Application volume group supports [availability zone volume placement](use-availability-zones.md) as the new default method for placement. This upgrade mitigates the need for AVset pinning and eliminates the need for proximity placement groups. With support for availability zone volume placement, you only need to select the same availability zone as the database servers. Using availability zone volume placement aligns with the Microsoft recommendation on how to deploy SAP HANA infrastructures to achieve best performance with high-availability, maximum flexibility, and simplified deployment. 
-    * If regions don't support availability zones, you can select a regional deployment or choose proximity placement groups (PPG).
+* Application volume group supports [availability zone volume placement](use-availability-zones.md) as the default and recommended method for placement. Using availability zone volume placement mitigates the need for AVset pinning and eliminates the need for proximity placement groups. With support for availability zone volume placement, you only need to select the same availability zone as the database servers. Using availability zone volume placement aligns with the Microsoft recommendation on how to deploy SAP HANA infrastructures to achieve best performance with high-availability, maximum flexibility, and simplified deployment. 
+    * <a name="ppg"></a> If regions don't support availability zones, you can select a regional deployment or choose proximity placement groups (PPG).
 
-    When you create a PPG, you must anchor it to your SAP HANA compute resources. Application volume group for SAP HANA needs this setup to search for an Azure NetApp Files resource that is close to the SAP HANA servers. For more information, see [Best practices about Proximity Placement Groups](#best-practices-about-proximity-placement) and [Create a Proximity Placement Group using the Azure portal](/azure/virtual-machines/windows/proximity-placement-groups-portal).
+    When you create a PPG, you must anchor it to your SAP HANA compute resources. Application volume group for SAP HANA needs this setup to search for an Azure NetApp Files resource that is close to the SAP HANA servers. For more information, see [Best practices about PPGs](#best-practices-about-proximity-placement) and [Create a PPG using the Azure portal](/azure/virtual-machines/windows/proximity-placement-groups-portal).
 
    >[!NOTE]
    >Do not delete the PPG. Deleting a PPG removes the pinning and can cause subsequent volume groups to be created in sub-optimal locations which could lead to increased latency.
@@ -46,24 +46,25 @@ To deploy SAP HANA volumes using the application volume group, you need to ensur
 
 * **Availability zone volume placement (preferred)**
     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. 
+
 * **Proximity placement group with VM pinning**
     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.
 
 > [!IMPORTANT]
 > 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. 
 
-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. 
+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 (VMs) are at the same location. As long as one of the VMs is started, the PPG retains its anchor to deploy the AVG volumes. 
 
 > [!IMPORTANT]
-> If you had requested Azure NetApp Files SAP HANA volume pinning before the application volume group was available, you should remove the pinning for your subscription. Existing pinning for a subscription might result in inconsistent deployment of volumes, as application volume group volumes are deployed based on the PPG while other volumes are still deployed based on existing pinning.
+> If you requested Azure NetApp Files SAP HANA volume pinning before the application volume group was available, you should remove the pinning for your subscription. Existing pinning for a subscription might result in inconsistent deployment of volumes; application volume group volumes are deployed based on the PPG while other volumes are deployed based on the initial volume pinning request.
 
 ### Relationship between availability set, VM, PPG, and Azure NetApp Files volumes 
 
 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.
 
 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.
 
-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.
+When using a PPG without a pinned availability set, a PPG would lose its anchor if all VMs in that PPG are stopped. When the VMs 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.
 
 ### Two possible scenarios about using PPG
 
@@ -72,12 +73,12 @@ This situation leads to two possible scenarios:
 * Stable long-term setup:   
     Using an availability set in combination with a PPG where the availability set is manually pinned.
 
-    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.
+    With pinning, it's always assured that the placement of the VM won't change even if all machines in the availability set are stopped.
 
 * Temporary setup:   
     Using a PPG or an availability set in combination with a PPG without any pinning.
 
-    SAP HANA capable virtual machine series (that is, M-Series) are mostly placed close to Azure NetApp Files resources so that the application volume group can create the required volumes with lowest possible latency with the help of a PPG. This relationship between volumes and HANA hosts won't change if at least one virtual machine is up and running all the time.
+    SAP HANA capable virtual machine series (that is, M-Series) are mostly placed close to Azure NetApp Files resources so that the application volume group can create the required volumes with lowest possible latency with the help of a PPG. This relationship between volumes and HANA hosts won't change if at least one VM is up and running all the time.
 
 > [!NOTE]
 > When you use application volume group to deploy your HANA volumes, at least one VM in the availability set must be started. Without a running VM, the PPG can't be used to find the optimal Azure NetApp files hardware, causing provisioning to fail.

articles/azure-netapp-files/application-volume-group-disaster-recovery.md

@@ -26,7 +26,7 @@ The following diagram illustrates cross-region replication between the source an
 > When you use an HA deployment with HSR at the primary side, you can choose to replicate not only the primary HANA system as described in this section, but also the HANA secondary system using cross-region replication. To automatically adapt the naming convention, you select both the **HSR secondary** and **Disaster recovery destination** options in the Create a Volume Group screen. The prefix then changes to `DR2-`. 
 
 > [!IMPORTANT]
-> * Recovering the HANA database at the destination region requires that you use application-consistent storage snapshots for your HANA backup. You can create such snapshots by using data-protection solutions such as the [Azure Application Consistent Snapshot tool](azacsnap-introduction.md) (AzAcSnap).
+> * Recovering the HANA database at the destination region requires that you use application-consistent storage snapshots for your HANA backup. You can create such snapshots by using data-protection solutions such as SnapCenter and the[Azure Application Consistent Snapshot tool](azacsnap-introduction.md) (AzAcSnap).
 > * You need to replicate at least the data volume and the log-backup volume. 
 > * You can optionally replicate the data-backup volume and the shared volume. 
 > * You should *never* replicate the log volume. The application volume group will create the log volume as a standard volume.

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

@@ -42,11 +42,7 @@ Application volume group for SAP HANA helps you simplify the deployment process
 
 * [Availability zone volume placement](use-availability-zones.md)
 
-    Designating the same availability zone for the volumes ensures that virtual machines and Azure NetApp Files volumes reside in the same availability zone and meet the latency requirements for SAP HANA. This improvement simplifies the deployment process, avoiding the manual AvSet pinning process and eliminating the requirement for availability sets. 
-
-    * Application volume groups also support proximity placement groups (PPGs) in lieu of manual pinning.
-    
-        You anchor the SAP HANA VMs using a PPG to guaranty lowest possible latency. The PPG enforces the creation of data, log, and shared volumes in the close proximity to the SAP HANA VMs. See [Best practices about Proximity Placement Groups](application-volume-group-considerations.md#best-practices-about-proximity-placement) for details.
+    Designating the same availability zone for the volumes ensures that virtual machines and Azure NetApp Files volumes reside in the same availability zone and meet the latency requirements for SAP HANA. Availability zone volume placement simplifies the deployment process, avoiding the manual AvSet pinning process and eliminating the requirement for availability sets. To learn more about the differences between availability zone volume placement and proximity placement groups, see [Requirements and considerations for application volume group for SAP HANA](application-volume-group-considerations.md#ppg).
 
 * Creation of separate storage endpoints (with different IP addresses) for data and log volumes.
     * This deployment method provides better performance and throughput for the SAP HANA database.

articles/azure-netapp-files/configure-network-features.md

@@ -18,7 +18,7 @@ The **Network Features** functionality enables you to indicate whether you want
 Two settings are available for network features: 
 
 * ***Standard***  
-    This setting enables VNet features for the volume.  
+    This setting enables VNet features for the volume. Standard network features is the default and preferred setting. 
 
     If you need higher IP limits or VNet features such as [network security groups (NSGs)](../virtual-network/network-security-groups-overview.md), [user-defined routes](../virtual-network/virtual-networks-udr-overview.md#user-defined), or additional connectivity patterns, set **Network Features** to *Standard*.