Merge pull request #303484 from b-ahibbard/reliability-restructure

ANF reliability

Author: JillGrant615

articles/azure-netapp-files/.openpublishing.redirection.azure-netapp-files.json

@@ -44,6 +44,36 @@
             "source_path_from_root": "/articles/azure-netapp-files/access-smb-volume-from-windows-client.md",
             "redirect_url": "/azure/azure-netapp-files/mount-volumes-vms-smb",
             "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-netapp-files/use-availability-zones.md",
+            "redirect_url": "/azure/reliability/reliability-netapp-files",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-netapp-files/cross-zone-replication-introduction.md",
+            "redirect_url": "/azure/azure-netapp-files/replication",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-netapp-files/cross-zone-region-replication.md",
+            "redirect_url": "/azure/azure-netapp-files/replication",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-netapp-files/cross-region-replication-introduction.md",
+            "redirect_url": "/azure/azure-netapp-files/replication",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root":"/articles/azure-netapp-files/cross-region-replication-requirements-considerations.md",
+            "redirect_url": "/azure/azure-netapp-files/replication-requirements",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root":"/articles/azure-netapp-files/cross-zone-replication-requirements-considerations.md",
+            "redirect_url": "/azure/azure-netapp-files/replication-requirements",
+            "redirect_document_id": false
         }
     ]
 }

articles/azure-netapp-files/TOC.yml

@@ -177,6 +177,8 @@
           href: application-volume-group-oracle-considerations.md
   - name: Data protection and resiliency
     items:
+    - name: Reliability in Azure NetApp Files 
+      href: ../reliability/reliability-netapp-files.md?toc=azure/azure-netapp-files/toc.json&bc=/azure/azure-netapp-files/breadcrumb/toc.yml
     - name: Understand data protection and disaster recovery options
       href: data-protection-disaster-recovery-options.md
     - name: How Azure NetApp Files snapshots work
@@ -187,22 +189,12 @@
         href: backup-introduction.md  
       - name: Requirements and considerations for Azure NetApp Files backup
         href: backup-requirements-considerations.md
-    - name: Disaster recovery with cross-region replication
+    - name: Replication 
       items: 
-      - name: Understand cross-region replication
-        href: cross-region-replication-introduction.md
-      - name: Requirements and considerations for cross-region replication
-        href: cross-region-replication-requirements-considerations.md
-    - name: High availability and resiliency with availability zones and cross-zone replication
-      items: 
-      - name: Use availability zones for high availability 
-        href: use-availability-zones.md
-      - name: Understand cross-zone replication 
-        href: cross-zone-replication-introduction.md
-      - name: Requirements and considerations for cross-zone replication 
-        href: cross-zone-replication-requirements-considerations.md
-    - name: Understand cross-zone-region replication 
-      href: cross-zone-region-replication.md
+      - name: Replication in Azure NetApp Files 
+        href: replication.md
+      - name: Replication requirements and considerations
+        href: replication-requirements.md
     - name: Azure Application Consistent Snapshot (AzAcSnap) tool
       items: 
       - name: What is AzAcSnap?

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

@@ -17,7 +17,7 @@ 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 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. 
+* Application volume group supports [availability zone volume placement](replication.md#availability-zones) 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. 
     * 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 PPGs](#best-practices-about-proximity-placement) and [Create a PPG using the Azure portal](/azure/virtual-machines/windows/proximity-placement-groups-portal).

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

@@ -17,7 +17,7 @@ This article describes using an application volume group to add volumes for an S
 
 ## CRR between source and destination HANA servers
 
-The Azure NetApp Files [cross-region replication](cross-region-replication-introduction.md) functionality enables you to replicate volumes between [supported cross-region replication pairs](cross-region-replication-introduction.md#supported-region-pairs). This functionality allows you to [replicate a volume](cross-region-replication-create-peering.md) from a source region to a volume on the destination region for disaster recovery (DR). 
+The Azure NetApp Files [cross-region replication](replication.md) functionality enables you to replicate volumes between [supported cross-region replication pairs](replication.md#supported-region-pairs). This functionality allows you to [replicate a volume](cross-region-replication-create-peering.md) from a source region to a volume on the destination region for disaster recovery (DR). 
 
 Instead of using HANA System Replication (HSR), you can use cross-region replication to protect a database without needing a HANA database server that runs all the time. You need to create replication destination volumes in a region supported for cross-region replication. Application volume group for SAP HANA ensures that the destination volumes are created with the correct volume type that meets all SAP HANA specific requirements.
 
@@ -80,7 +80,7 @@ The following example adds volumes to an SAP HANA system. The system serves as a
     * **Multiple-host**:  
         Select this option if you're adding additional hosts to a multiple-hosts HANA system.
     * **Disaster recover destination**:  
-        Select this option to create volumes for a HANA system as a DR site using [cross-region replication](cross-region-replication-introduction.md).  
+        Select this option to create volumes for a HANA system as a DR site using [cross-region replication](replication.md).  
 
         Selecting **Disaster recover destination** triggers the naming convention for the volume group name to include `"-DR-"` to indicate a disaster-recovery setup. 
 

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

@@ -24,7 +24,7 @@ Application volume group for SAP HANA is supported for all regions where Azure N
 * Supporting SAP HANA configurations for both single and multiple host setups, including: 
     * Volumes for a single or primary SAP HANA database
     * Volumes for an SAP HANA System Replication (HSR) secondary system
-    * Volumes for a disaster recovery (DR) scenario using [cross-region replication](cross-region-replication-introduction.md)
+    * Volumes for a disaster recovery (DR) scenario using [cross-region replication](replication.md)
 
 * Creating the following volumes: 
     * SAP HANA data volumes (one for each database host)
@@ -41,7 +41,7 @@ Application volume group for SAP HANA is supported for all regions where Azure N
 
 Application volume group for SAP HANA helps you simplify the deployment process and increase the storage performance for SAP HANA workloads. Some of the new features are as follows:
 
-* [Availability zone volume placement](use-availability-zones.md)
+* [Availability zone volume placement](replication.md#availability-zones)
 
     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#best-practices-about-proximity-placement).
 

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

@@ -46,15 +46,15 @@ Application volume group for Oracle helps you simplify the deployment process an
 * Creation of separate storage endpoints (with different IP addresses) for data and log volumes.   
     This deployment method provides better performance and throughput for the Oracle database.
 * Customer-managed keys support increased security and compliance. 
-* [Cross-zone](cross-zone-replication-introduction.md) and [cross-region](cross-region-replication-introduction.md) replication provide efficient storage-based data replication without load on compute infrastructure and a layer of protection for disaster recovery. This feature currently is in preview and only supported with the [REST API](configure-application-volume-oracle-api.md#replication). 
+* [Cross-zone and cross-region replication](replication.md) provide efficient storage-based data replication without load on compute infrastructure and a layer of protection for disaster recovery. This feature currently is in preview and only supported with the [REST API](configure-application-volume-oracle-api.md#replication). 
 
 ## Application volume group layout
 
 Application volume group for Oracle deploys multiple volumes based on your input and on resource availability in the selected region and zone, subject to the following rules:
 
 [!INCLUDE [AVG bullet points](includes/application-volume-group-layout.md)]
 
-High availability deployments will include volumes in two availability zones or regions. Application volume group for Oracle allows you to deploy production volumes in the primary zone and data protection volumes in an alternate zone or region. You can use Data Guard to replicate redo log and data volumes, or you can choose to offload data volume replication load from the application server by using Azure NetApp Files [cross-zone](cross-zone-replication-introduction.md) or [cross-region replication](cross-region-replication-introduction.md) for the data volumes. Use application-based data replication with Data Guard to synchronously replicate the redo logs so the database can be rolled forward after a failover.
+High availability deployments will include volumes in two availability zones or regions. Application volume group for Oracle allows you to deploy production volumes in the primary zone and data protection volumes in an alternate zone or region. You can use Data Guard to replicate redo log and data volumes, or you can choose to offload data volume replication load from the application server by using Azure NetApp Files [cross-zone or cross-region replication](replication.md) for the data volumes. Use application-based data replication with Data Guard to synchronously replicate the redo logs so the database can be rolled forward after a failover.
 
 :::image type="content" source="./media/application-volume-group-oracle-introduction/oracle-dual-zone-layout.png" alt-text="Diagram of dual-zone volume layout." lightbox="./media/application-volume-group-oracle-introduction/oracle-dual-zone-layout.png":::
 

articles/azure-netapp-files/azure-netapp-files-cost-model.md

@@ -13,7 +13,7 @@ ms.author: anfdocs
 
 Understanding the cost model for Azure NetApp Files helps you manage your expenses from the service. 
 
-For cost model specific to cross-region replication, see [Cost model for cross-region replication](cross-region-replication-introduction.md#cost-model-for-cross-region-replication).
+For cost model specific to cross-region replication, see [Cost model for cross-region replication](replication.md#cost-model-for-cross-region-replication).
 
 ## Calculation of capacity consumption
 
@@ -100,7 +100,7 @@ The following diagram illustrates the concepts.
 * [Azure NetApp Files pricing page](https://azure.microsoft.com/pricing/details/storage/netapp/)
 * [Service levels for Azure NetApp Files](azure-netapp-files-service-levels.md)
 * [Resource limits for Azure NetApp Files](azure-netapp-files-resource-limits.md)
-* [Cost model for cross-region replication](cross-region-replication-introduction.md#cost-model-for-cross-region-replication)
+* [Cost model for cross-region replication](replication.md#cost-model-for-cross-region-replication)
 * [Understand volume quota](volume-quota-introduction.md)
 * [Monitor the capacity of a volume](monitor-volume-capacity.md)
 * [Resize the capacity pool or a volume](azure-netapp-files-resize-capacity-pools-or-volumes.md)

articles/azure-netapp-files/azure-netapp-files-manage-snapshots.md

@@ -14,7 +14,7 @@ ms.author: anfdocs
 Azure NetApp Files supports creating on-demand [snapshots](snapshots-introduction.md) and using snapshot policies to schedule automatic snapshot creation. You can also restore a [snapshot to a new volume](snapshots-restore-new-volume.md), [restore a single file by using a client](snapshots-restore-file-client.md), or [revert an existing volume by using a snapshot](snapshots-revert-volume.md). This article explains how to create an on-demand snapshot for a volume. 
 
 > [!NOTE] 
-> * For considerations about snapshot management in cross-region replication, see [Requirements and considerations for using cross-region replication](cross-region-replication-requirements-considerations.md).
+> * For considerations about snapshot management in cross-region replication, see [Requirements and considerations for using cross-region replication](replication-requirements.md).
 > * You can use Azure Application Consistent Snapshot tool (AzAcSnap) to enable data protection for third-party databases. For more information, see What is [Azure Application Consistent Snapshot tool](azacsnap-introduction.md).
  
 ## Steps

articles/azure-netapp-files/azure-netapp-files-resize-capacity-pools-or-volumes.md

@@ -71,9 +71,9 @@ See [REST API for Azure NetApp Files](azure-netapp-files-develop-with-rest-api.m
 
 The REST API specification and example code for Azure NetApp Files are available through the [resource-manager GitHub directory](https://github.com/Azure/azure-rest-api-specs/tree/main/specification/netapp/resource-manager/Microsoft.NetApp/stable). See [this command](https://github.com/Azure/azure-rest-api-specs/blob/main/specification/netapp/resource-manager/Microsoft.NetApp/stable/2023-11-01/examples/Volumes_Update.json) for a sample volume update.
 
-## Resize a cross-region replication destination volume 
+## Resize a replication destination volume 
 
-In a [cross-region replication](cross-region-replication-introduction.md) relationship, a destination volume is automatically resized based on the size of the source volume. As such, you don’t need to resize the destination volume separately. This automatic resizing behavior is applicable when the volumes are in an active replication relationship, or when replication peering is broken with the [resync operation](cross-region-replication-manage-disaster-recovery.md#resync-replication). 
+In a [cross-region or cross-zone replication](replication.md) relationship, a destination volume is automatically resized based on the size of the source volume. As such, you don’t need to resize the destination volume separately. This automatic resizing behavior is applicable when the volumes are in an active replication relationship, or when replication peering is broken with the [resync operation](cross-region-replication-manage-disaster-recovery.md#resync-replication). 
 
 The following table describes the destination volume resizing behavior based on the [Mirror state](cross-region-replication-display-health-status.md):
 
@@ -84,7 +84,7 @@ The following table describes the destination volume resizing behavior based on
 | *Uninitialized* | When you resize the source volume and the Mirror state is still *uninitialized*, resizing the destination volume needs to be done manually. As such, it's recommended that you wait for the initialization to complete (that is, when the Mirror state becomes *mirrored*) to resize the source volume. | 
 
 > [!IMPORTANT]
-> Ensure that you have enough headroom in the capacity pools for both the source and the destination volumes of cross-region replication. When you resize the source volume, the destination volume is automatically resized. But if the capacity pool hosting the destination volume doesn’t have enough headroom, the resizing of both the source and the destination volumes will fail.
+> Ensure that you have enough headroom in the capacity pools for both the source and the destination volumes of replication. When you resize the source volume, the destination volume is automatically resized. But if the capacity pool hosting the destination volume doesn’t have enough headroom, the resizing of both the source and the destination volumes will fail.
 
 ## Next steps
 

articles/azure-netapp-files/azure-netapp-files-service-levels.md

@@ -93,7 +93,7 @@ As illustrated in the diagram, the SAP HANA backup volume received the 128MiB/s
 | 1,024 | 128 | 5 * 128 * 1,024 = 655,360 |
 
 >[!NOTE]
->A baseline throughput of 128 MiB/s is provided for every pool, at no additional cost.
+>A baseline throughput of 128 MiB/s is provided for every pool at no additional cost.
 
 ## Next steps
 
@@ -102,4 +102,4 @@ As illustrated in the diagram, the SAP HANA backup volume received the 128MiB/s
 - [Create a capacity pool](azure-netapp-files-set-up-capacity-pool.md)
 - [Service Level Agreement (SLA) for Azure NetApp Files](https://azure.microsoft.com/support/legal/sla/netapp/)
 - [Dynamically change the service level of a volume](dynamic-change-volume-service-level.md) 
-- [Service-level objectives for cross-region replication](cross-region-replication-introduction.md#service-level-objectives)
+- [Service-level objectives](../reliability/reliability-netapp-files.md#region-down-experience)