formatting & acrolinx

b-ahibbard · b-ahibbard · commit 493d39fbed93 · 2022-09-29T15:47:55.000-04:00
diff --git a/articles/azure-netapp-files/configure-application-volume-group-sap-hana-api.md b/articles/azure-netapp-files/configure-application-volume-group-sap-hana-api.md
@@ -17,7 +17,7 @@ ms.author: b-ahibbard
 ---
 # Configure application volume groups for the SAP HANA REST API
 
-Application volume group (AVG) enables customers to deploy all volumes for a single HANA host in one atomic step. The Azure portal and the Azure Resource Manager template have implemented pre-checks and recommendations for deployment in areas including throughputs and volume naming conventions. As a REST API user, those checks and recommendations are not available.
+Application volume group (AVG) enables you to deploy all volumes for a single HANA host in one atomic step. The Azure portal and the Azure Resource Manager template have implemented pre-checks and recommendations for deployment in areas including throughputs and volume naming conventions. As a REST API user, those checks and recommendations are not available.
 
 Without these checks, it's important to understand the requirements for running HANA on Azure NetApp Files and the basic architecture and workflows application volume groups on which are built.
 
@@ -56,15 +56,15 @@ The following list describes all the possible volume types for application volum
 
 1. **Networking:** You need to decide on the networking architecture. To use Azure NetApp Files, a VNet needs to be created and within the vNet a delegated subnet where the ANF storage endpoints (IPs) will be placed. To ensure that the size of this subnet is large enough, see [Considerations about delegating a subnet to Azure NetApp Files](azure-netapp-files-delegate-subnet.md#considerations).
     1.	Create a VNet.
-    2.	Create a VM subnet and delegated subnet for ANF.
+    2.	Create a virutal machine (VM) subnet and delegated subnet for ANF.
 1.	**Storage Account and Capacity Pool:** A storage account is the entry point to consume Azure NetApp Files. At least one storage account needs to be created. Within a storage account, a capacity pool is the logical unit to create volumes. Application volume groups require a capacity pool with a manual QoS. It should be created with a size and service level that meets your HANA requirements. NOTE: a capacity pool can be resized at any time.
     1.	Create a NetApp storage account.
     2.	Create a manual QoS capacity pool.
-1. **Create AvSet and proximity placement group (PPG):** For production landscapes, you should AvSet that is manually pinned to a data center where Azure NetApp Files resources are available in proximity. The AvSet pinning ensures that VMs will not be moved on restart. The proximity placement group (PPG) needs to be assigned to the AvSet and with the help of application volume groups can find the closest Azure NetApp Files hardware, see [Best practices about proximity placement groups](application-volume-group-considerations.md#best-practices-about-proximity-placement-groups).
+1. **Create AvSet and proximity placement group (PPG):** For production landscapes, you should AvSet that is manually pinned to a data center where Azure NetApp Files resources are available in proximity. The AvSet pinning ensures that VMs will not be moved on restart. The proximity placement group (PPG) needs to be assigned to the AvSet. With the help of application volume groups, the PPG can find the closest Azure NetApp Files hardware. For more information, see [Best practices about proximity placement groups](application-volume-group-considerations.md#best-practices-about-proximity-placement-groups).
     1. Create AvSet.
     2. Create PPG.
     3. Assign PPG to AvSet.
-1. **Manual Steps - Request AvSet pinning**: AvSet pinning is required for long term SAP HANA systems. The Microsoft capacity planning team ensures that the required VMS for SAP HANA and Azure NetApp Files resources be in proximity to the VMs that are available. VMs will not move on restart. 
+1. **Manual Steps - Request AvSet pinning**: AvSet pinning is required for long term SAP HANA systems. The Microsoft capacity planning team ensures that the required VMs for SAP HANA and Azure NetApp Files resources be in proximity to the VMs that are available. VMs will not move on restart. 
     * Request pinning using [this form](https://aka.ms/HANAPINNING).
 1. **Create and start HANA DB VM:** Before you can create volumes using application volume groups, the PPG must be anchored. At least one VM must be created using the pinned AvSet. Once this VM is started, the PPG can be used to detect where the VM is running.
     1. Create and start the VM using the AvSet.
@@ -113,12 +113,12 @@ This table describes the request body parameters and volume properties for creat
 | `tags` | Volume tags | None, however, it may be helpful to add a tag to the HSR partner volume to identify the corresponding HSR partner volume. The Azure portal suggests the following tag for the HSR Secondary volumes: <ul><li> **Name**: `HSRPartnerStorageResourceId` </li><li> **Value:** `<Partner volume Id>` </li></ul> |
 | **Volume properties** | **Description** | **SAP HANA Value Restrictions** |
 | `creationToken` | Export path name, typically same as name above. | None. Example: `SH9-data-mnt00001` |
-| `throughputMibps` | QoS throughput | This must be between 1 and 4500 Mbps. You should set throughput based on volume type. | 
+| `throughputMibps` | QoS throughput | This must be between 1 Mbps and 4500 Mbps. You should set throughput based on volume type. | 
 | `usageThreshhold` | Size of the volume in bytes. This must be in the 100 GiB to 100 TiB range. For instance, 100 GiB = 107374182400 bytes. | None. You should set volume size depending on the volume type. | 
 | `exportPolicyRule` | Volume export policy rule | At least one export policy rule must be specified for SAP HANA. Only the following rules values can be modified for SAP HANA, the rest _must_ have their default values: <ul><li>`unixReadOnly`: should be false</li><li>`unixReadWrite`: should be true</li><li>`allowedClients`: specify allowed clients. Use `0.0.0.0/0` for no restrictions.</li><li>`hasRootAccess`: must be true to install SAP.</li><li>`chownMode`: Specify `chown` mode.</li><li>`nfsv41`: true for data, log, and shared volumes, optionally true for data backup and log backup volumes</li><li>`nfsv3`: optionally true for data backup and log backup volumes</li><ul> All other rule values _must_ be left defaulted. |
 | `volumeSpecName` | Specifies the type of volume for the application volume group being created | SAP HANA volumes must have a value that is one of the following: <ul><li>"data"</li><li>"log"</li><li>"shared"</li><li>"data-backup"</li><li>"log-backup"</li></ul> | 
 | `proximityPlacementGroup` | Resource ID of the Proximity Placement Group (PPG) for proper placement of the volume. | <ul><li>The “data”, “log” and “shared” volumes must each have a PPG specified, preferably a common PPG.</li><li>A PPG must be specified for the “data-backup” and “log-backup” volumes, but it will be ignored during placement.</li></ul> |
-| `subnetId` | Delegated subnet ID for Azure NetApp Files. | In a normal case (where there are sufficient resources available), the number of IP address required in the subnet depends on the order of the application volume group created in the subscription: <ol><li> First application volume group created: the creation usually requires to 3-4 IP addresses but can require up to 5</li><li> Second application volume group created: Normally requires two IP addresses</li><li></li>Third and subsequent application volume group created: Normally, more IP addresses will not be required</ol> |
+| `subnetId` | Delegated subnet ID for Azure NetApp Files. | In a normal case where there are sufficient resources available, the number of IP addresses required in the subnet depends on the order of the application volume group created in the subscription: <ol><li> First application volume group created: the creation usually requires to 3-4 IP addresses but can require up to 5</li><li> Second application volume group created: Normally requires two IP addresses</li><li></li>Third and subsequent application volume group created: Normally, more IP addresses will not be required</ol> |
 | `capacityPoolResourceId` | ID of the capacity pool | The capacity pool must be of type manual QoS. Generally, all SAP volumes are placed in a common capacity pool, however this is not a requirement. |
 | `protocolTypes` | Protocol to use | This should be either NFSv3 or NFSv4.1 and should match the protocol specified in the Export Policy Rule described earlier in this table. | 
 
@@ -141,9 +141,9 @@ In the examples below, selected placeholders are specified and should be replace
 >[!NOTE]
 > The following samples use jq, a tool that helps format the JSON output in a user-friendly way. If you don't have or use jq, you should omit the `| jq xxx` snippets.
 
-## Creating SAP HANA volume groups using Curl
+## Creating SAP HANA volume groups using curl
 
-SAP HANA volume groups for the following examples can be created using a sample shell script that calls the API using Curl:
+SAP HANA volume groups for the following examples can be created using a sample shell script that calls the API using curl:
 
 1. Extract the subscription ID. This will automate the extraction of the subscription ID and generate the authorization token:
     ```bash
@@ -162,15 +162,15 @@ SAP HANA volume groups for the following examples can be created using a sample
     curl -X PUT -H "Authorization: Bearer $token" -H "Content-Type:application/json" -H "Accept:application/json" -d @<ExampleJson> https://management.azure.com/subscriptions/$subId/resourceGroups/<ResourceGroup>/providers/Microsoft.NetApp/netAppAccounts/<NtapAccount>/volumeGroups/<VolumeGroupName>?api-version=2022-03-01 | jq .
     ```
 
-### Example 1 - Deploy volumes for the first HANA host for a single-host or multi-host configuration
+### Example 1: Deploy volumes for the first HANA host for a single-host or multi-host configuration
 To create the five volumes (data, log, shared, data-backup, log-backup) for a single-node SAP HANA system with SID `SH9` as in the example, use the following API request as shown in the JSON example.
 
 >[!NOTE]
 >You need to replace the placeholders and adapt the parameters to meet your requirements.
 
 #### Example single-host SAP HANA application volume group creation Request
 
-This example pertains to data, log, shared, data-backup, and log-backup volumes demonstrating best practices for naming, sizing, and throughputs. This example will serve as the primary volume if you are configuring an HSR pair. 
+This example pertains to data, log, shared, data-backup, and log-backup volumes demonstrating best practices for naming, sizing, and throughputs. This example will serve as the primary volume if you're configuring an HSR pair. 
 
 1. Save the JSON template as `sh9.json`:
     ```json
@@ -368,24 +368,23 @@ This example pertains to data, log, shared, data-backup, and log-backup volumes
         }
     }
     ```
-1. Run the test script. 
+1. Extract the subscription ID:
     ```bash
-    # 1. Extract the subscription ID
     subId=$(az account list | jq ".[] | select (.name == \"Pay-As-You-Go\") | .id" -r)
     echo "Subscription ID: $subId"
-    #
-    # 2. Create the access token
+    ```
+1. Create the access token:
+    ```bash
     response=$(az account get-access-token)
     token=$(echo $response | jq ".accessToken" -r)
     echo "Token: $token"
-    #
-    # 3. Call the REST API using curl
-    #
+    ```
+3. Call the REST API using curl
+    ```bash
     echo "---"
     curl -X PUT -H "Authorization: Bearer $token" -H "Content-Type:application/json" -H "Accept:application/json" -d @sh9.json https://management.azure.com/subscriptions/$subId/resourceGroups/rg-westus/providers/Microsoft.NetApp/netAppAccounts/ANF-WestUS-test/volumeGroups/SAP-HANA-SH9-00001?api-version=2022-03-01 | jq .
-```
+    ```
 1. Sample result:
-
 ```json
 {
   "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-westus/providers/Microsoft.NetApp/netAppAccounts/ANF-WestUS-test/volumeGroups/SAP-HANA-SH9-00001",
@@ -592,7 +591,7 @@ This example pertains to data, log, shared, data-backup, and log-backup volumes
 }
 ```
 
-### Example 2 - Deploy volumes for an additional HANA Host for a multiple-host HANA configuration
+### Example 2: Deploy volumes for an additional HANA Host for a multiple-host HANA configuration
 
 To create a multiple-host HANA system, you need to add additional hosts to the previously deployed HANA hosts. Additional hosts only require a data and log volume each host you add. In this example, a volume group is added for host number `00002`.
 
@@ -685,7 +684,7 @@ This example is similar to the single-host system request in the earlier example
     }
 ```
 
-### Example 3 - Deploy volumes for a secondary HANA system using HANA system replication
+### Example 3: Deploy volumes for a secondary HANA system using HANA system replication
 
 HANA System Replication (HSR) will be used to set up a HANA database where both databases are using the same SAP System Identifier (SID) but have their individual volumes. Typically, HSR setups are in different zones and therefore require different proximity placement groups.
 
@@ -900,7 +899,7 @@ This example encompasses the creation of data, log, shared, data-backup, and log
 }
 ```
 
-### Example 4 - Deploy volumes for a secondary HANA system using HANA system replication
+### Example 4: Deploy volumes for a secondary HANA system using HANA system replication
 
 Cross-region replication is one way to set up a disaster recovery configuration for HANA, where the volumes of the HANA database in the DR-region are replicated on the storage side using cross-region replication in contrast to HSR, which replicates at the application level where it requires to have the HANA VMs deployed and running. Refer to the documentation (link) to understand which volumes require CRR replication. Refer to [Add volumes for an SAP HANA system as a DR system using cross-region replication](application-volume-group-disaster-recovery.md) to understand for which volumes in cross-region replication relations are required (data, shared, log-backup), not allowed (log), or optional (data-backup). 
 
