Updatess from 'kegger' meeting

stevenmatthew · stevenmatthew · commit 6f9885c32e6d · 2024-05-03T12:59:26.000-07:00
diff --git a/articles/storage/common/storage-disaster-recovery-guidance.md b/articles/storage/common/storage-disaster-recovery-guidance.md
@@ -130,7 +130,7 @@ Although Microsoft could potentially initiate a regional failover, this only hap
 ### Anticipate data loss and inconsistencies
 
 > [!CAUTION]
-> Storage account failover usually involves some amount data loss, and could also potentially introduce file and data inconsistencies. In your disaster recovery plan, it's important to consider the impact that an account failover would have on your data before initiating one.
+> Customer-managed (unplanned) failover usually involves some amount data loss, and can also potentially introduce file and data inconsistencies. In your disaster recovery plan, it's important to consider the impact that an account failover would have on your data before initiating one.
 
 Because data is written asynchronously from the primary region to the secondary region, there's always a delay before a write to the primary region is copied to the secondary. If the primary region becomes unavailable, it's possible that the most recent writes might not yet be copied to the secondary.
 
diff --git a/articles/storage/common/storage-failover-customer-managed-planned.md b/articles/storage/common/storage-failover-customer-managed-planned.md
@@ -20,9 +20,11 @@ Current: 100 (1779/0)
 
 # How customer-managed planned failover (preview) works
 
-Customer-managed storage account planned failover enables you to fail over your entire geo-redundant storage account to the secondary region to do disaster recovery testing. During failover, the original secondary region becomes the new primary and all storage service endpoints for blobs, tables, queues, and files are redirected to the new primary region. After testing is complete, you can perform another failover operation to *fail back* to the original primary region. A *failback* is an operation restores a storage account to its original regional configuration.
+Customer-managed planned failover (preview) can be used to to test your disaster recovery plan. During the planned failover process, the primnary and secondary regions are swapped. The original primary region is demoted and becomes the new secondary, while the original secondary region is promoted and becomes the new primary. After the failover completes, users can proceed to access data in the new primary region and administrators can validate their disaster recovery plan. The storage account must be available in both the primary and secondary regions before a planned failover can be initiated.
 
-This article describes what happens during a customer-managed planned storage account failover and failback at every stage of the process. To understand how a failover due to an unexpected storage endpoint outage works, see [How customer-managed storage account failover to recover from an outage works](storage-failover-customer-managed-unplanned.md).
+Customer-managed planned failover (preview) can also be used during a partial networking or compute outage in your primary region. These outages might occur, for example, when an outage in your primary region prevents your workloads from functioning properly, but leaves your storage service endpoints available.
+
+This article describes what happens during a customer-managed planned storage account failover and failback at every stage of the process. To understand how a failover due to an unexpected storage endpoint outage works, see [How customer-managed (unplanned) failover](storage-failover-customer-managed-unplanned.md).
 
 > [!IMPORTANT]
 > Customer-managed planned failover is currently in PREVIEW. This preview version is provided without a service level agreement, and might not be suitable for production workloads. Certain features might not be supported or might have constrained capabilities. 
@@ -31,7 +33,7 @@ This article describes what happens during a customer-managed planned storage ac
 >
 > To opt in to the preview, see [Set up preview features in Azure subscription](../../azure-resource-manager/management/preview-features.md) and specify `AllowSoftFailover` as the feature name.
 
-## Redundancy management during failover and failback
+## Redundancy management during planned failover and failback
 
 > [!TIP]
 > To understand the varying redundancy states during the storage account failover and failback process in detail, see [Azure Storage redundancy](storage-redundancy.md) for definitions of each.
@@ -59,7 +61,7 @@ The failback process is essentially the same as the failover process, except Azu
 
 To learn how to initiate a failover, see [Initiate a storage account failover](storage-initiate-account-failover.md).
 
-## The failover and failback process
+## The planned failover and failback process
 
 The following diagrams show what happens during a customer-managed planned failover and failback of a storage account.
 
@@ -69,7 +71,7 @@ Under normal circumstances, a client writes data to a storage account in the pri
 
 :::image type="content" source="media/storage-failover-customer-managed-common/pre-failover-geo-redundant.png" alt-text="Diagram that shows how clients write data to the storage account in the primary region." lightbox="media/storage-failover-customer-managed-common/pre-failover-geo-redundant.png":::
 
-### The failover process (GRS/RA-GRS)
+### The planned failover process (GRS/RA-GRS)
 
 Begin disaster recovery testing by initiating a failover of your storage account to the secondary region. The following steps describe the failover process, and the subsequent image provides illustration:
 
@@ -87,7 +89,7 @@ After the failover is complete, the original primary region becomes the new seco
 
 While in the failover state, perform your disaster recovery testing.
 
-### The failback process (GRS/RA-GRS)
+### The planned failback process (GRS/RA-GRS)
 
 After testing is complete, perform another failover to failback to the original primary region. During the failover process, as shown in the following image:
 
@@ -109,7 +111,7 @@ Under normal circumstances, a client writes data to a storage account in the pri
 
 :::image type="content" source="media/storage-failover-customer-managed-common/pre-failover-geo-zone-redundant.png" alt-text="Diagram that shows how the clients write data to the storage account in the primary region." lightbox="media/storage-failover-customer-managed-common/pre-failover-geo-zone-redundant.png":::
 
-### The failover process (GZRS/RA-GZRS)
+### The planned failover process (GZRS/RA-GZRS)
 
 Begin disaster recovery testing by initiating a failover of your storage account to the secondary region. The following steps describe the failover process, and the subsequent image provides illustration:
 
@@ -127,7 +129,7 @@ After the failover is complete, the original primary region becomes the new seco
 
 While in the failover state, perform your disaster recovery testing.
 
-### The failback process (GZRS/RA-GZRS)
+### The planned failback process (GZRS/RA-GZRS)
 
 When testing is complete, perform another failover to fail back to the original primary region. The following image illustrates the steps involved in the failover process.
 
diff --git a/articles/storage/common/storage-failover-customer-managed-unplanned.md b/articles/storage/common/storage-failover-customer-managed-unplanned.md
@@ -17,19 +17,12 @@ Initial: 84 (2544/39)
 Current: 100 (2548/3)
 -->
 
-# How customer-managed (unplanned) storage account failover works
+# How customer-managed (unplanned) failover works
 
-Customer-managed (unplanned) failover of Azure Storage accounts enables you to fail over your entire geo-redundant storage account to the secondary region if the storage service endpoints for the primary region become unavailable. During failover, the original secondary region becomes the new primary region. All storage service endpoints are then redirected to the *new* primary region. After the storage service endpoint outage is resolved, you can perform another failover operation to fail *back* to the original primary region.
+Customer-managed (unplanned) failover enables you to fail over your entire geo-redundant storage account to the secondary region if the storage service endpoints for the primary region become unavailable. During failover, the original secondary region becomes the new primary region. All storage service endpoints are then redirected to the *new* primary region. After the storage service endpoint outage is resolved, you can perform another failover operation to fail *back* to the original primary region.
 
 This article describes what happens during a customer-managed storage account failover and failback at every stage of the process.
 
-> [!IMPORTANT]
-> Customer-managed (unplanned) failover is currently in PREVIEW. This preview version is provided without a service level agreement, and might not be suitable for production workloads. Certain features might not be supported or might have constrained capabilities. 
->
-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
->
-> To opt in to the preview, see [Set up preview features in Azure subscription](../../azure-resource-manager/management/preview-features.md) and specify `AllowSoftFailover` as the feature name.
-
 [!INCLUDE [updated-for-az](../../../includes/storage-failover-unplanned-hns-preview-include.md)]
 
 ## Redundancy management during failover and failback
@@ -54,12 +47,12 @@ The failback process is essentially the same as the failover process except Azur
 
 After failback, you can reconfigure your storage account to take advantage of geo-redundancy again. If the original primary region was configured for LRS, you can configure it to be GRS or RA-GRS. If the original primary was configured as ZRS, you can configure it to be GZRS or RA-GZRS. For more options, see [Change how a storage account is replicated](redundancy-migration.md).
 
-## How to initiate a failover
+## How to initiate an unplanned failover
 
-To learn how to initiate a failover, see [Initiate a storage account failover](storage-initiate-account-failover.md).
+To learn how to initiate an unplanned failover, see [Initiate a storage account failover](storage-initiate-account-failover.md).
 
 > [!CAUTION]
-> Storage account failover usually involves some data loss, and potentially file and data inconsistencies. It's important to understand the impact that an account failover would have on your data before initiating one.
+> Unplanned failover usually involves some data loss, and potentially file and data inconsistencies. It's important to understand the impact that an account failover would have on your data before initiating this type of failover.
 >
 > For details about potential data loss and inconsistencies, see [Anticipate data loss and inconsistencies](storage-disaster-recovery-guidance.md#anticipate-data-loss-and-inconsistencies).
 
diff --git a/articles/storage/common/storage-initiate-account-failover.md b/articles/storage/common/storage-initiate-account-failover.md
@@ -44,16 +44,14 @@ Before you can perform an account failover on your storage account, make sure th
 
 Review these important topics detailed in the [disaster recovery guidance](storage-disaster-recovery-guidance.md#plan-for-storage-account-failover) article before initiating a customer-managed failover.
 
-- **Potential data loss**: Data loss should be expected during an uplanned storage account failover.
-    > [!WARNING]
-    > It is important to understand the expectations for data loss associated with an unplanned failover, and to plan for it. For details on the implications of an unplanned account failover and to how to prepare for data loss, see the [Anticipate data loss and inconsistencies](storage-disaster-recovery-guidance.md#anticipate-data-loss-and-inconsistencies) section.
-- **Geo-redundancy**: Before you can perform a failover, your storage account must be configured for geo-redundancy. Initial synchronization from the primary to the secondary region must also have completed before the failover process can begin. If your account isn't configured for geo-redundancy, you can change it by following the steps described within the [Change how a storage account is replicated](redundancy-migration.md) article. For more information about Azure storage redundancy options, see the [Azure Storage redundancy](storage-redundancy.md) article. 
-- **Understand the different types of account failover**: There are **TWO** or **three** types of storage account failover. See the [Plan for storage account failover](storage-disaster-recovery-guidance.md#plan-for-storage-account-failover) article to learn about potential use cases for each type, and how they differ. *This article focuses on how to initiate a customer-managed failover to recover from the service endpoints being unavailable in the primary region, or a customer-managed **planned** failover (preview) used primarily to perform disaster recovery testing*.
+- **Potential data loss**: Data loss should be expected during an uplanned storage account failover. For details on the implications of an unplanned account failover and to how to prepare for data loss, see the [Anticipate data loss and inconsistencies](storage-disaster-recovery-guidance.md#anticipate-data-loss-and-inconsistencies) section.
+- **Geo-redundancy**: Before you can perform a failover, your storage account must be configured for geo-redundancy. Initial synchronization from the primary to the secondary region must complete before the failover process can begin. If your account isn't configured for geo-redundancy, you can change it by following the steps described within the [Change how a storage account is replicated](redundancy-migration.md) article. For more information about Azure storage redundancy options, see the [Azure Storage redundancy](storage-redundancy.md) article. 
+- **Understand the different types of account failover**: There are two types of customer-managed failover. See the [Plan for failover](storage-disaster-recovery-guidance.md#plan-for-storage-account-failover) article to learn about potential use cases for each type, and how they differ.
 - **Plan for unsupported features and services**: Review the [Unsupported features and services](storage-disaster-recovery-guidance.md#unsupported-features-and-services) article and take appropriate action before initiating a failover.
 - **Supported storage account types**: Ensure that your storage account type can be used to initiate a failover. See [Supported storage account types](storage-disaster-recovery-guidance.md#supported-storage-account-types).
-- **Set your expectations for timing and cost**: The time it takes the failover process to complete after being intiated can vary, but typically takes less than one hour. A an unplanned failover results in the loss of geo-redundancy configuration. Reconfiguring GRS typically incurs extra time and cost. For more information, see the [time and cost of failing over](storage-disaster-recovery-guidance.md#the-time-and-cost-of-failing-over) section.
+- **Set your expectations for timing and cost**: After intiation, the time it takes the customer-managed failover process to complete can vary, but typically takes less than one hour. An unplanned failover results in the loss of geo-redundancy configuration. Reconfiguring GRS typically incurs extra time and cost. For more information, see the [time and cost of failing over](storage-disaster-recovery-guidance.md#the-time-and-cost-of-failing-over) section.
 
-## Initiate the failover
+## Initiate the customer-managed failover
 
 <!--You can initiate an account failover from the Azure portal, PowerShell, or the Azure CLI.-->
 
@@ -76,20 +74,13 @@ Complete the following steps to initiate an account failover using the Azure por
 
     :::image type="content" source="media/storage-initiate-account-failover/portal-failover-redundancy.png" alt-text="Screenshot showing redundancy and failover status." lightbox="media/storage-initiate-account-failover/portal-failover-redundancy.png":::
 
-    If your storage account is configured with a hierarchical namespace enabled, the following message is displayed:
-
-    :::image type="content" source="media/storage-initiate-account-failover/portal-failover-hns-not-supported.png" alt-text="Screenshot showing that failover isn't supported for hierarchical namespace." lightbox="media/storage-initiate-account-failover/portal-failover-hns-not-supported.png":::
-
 1. Verify that your storage account is configured for geo-redundant storage (GRS, RA-GRS, GZRS or RA-GZRS). If it's not, select the desired redundancy configuration from the **Redundancy** drop-down and select **Save** to commit your change. After the geo-redundancy configuration is changed, your data is synchronized from the primary to the secondary region. This synchronization will take several minutes, and failover can't be initiated until all data has been replicated. The following message appears until the synchronization is complete:
 
     :::image type="content" source="media/storage-initiate-account-failover/portal-failover-repl-in-progress.png" alt-text="Screenshot showing the location of the message indicating that synchronization is still in progress." lightbox="media/storage-initiate-account-failover/portal-failover-repl-in-progress.png":::
 
 1. Select **Prepare for Customer-Managed failover** as shown in the following image:
 
-    :::image type="content" source="media/storage-initiate-account-failover/portal-failover-prepare.png" lightbox="media/storage-initiate-account-failover/portal-failover-prepare.png" alt-text="Screenshot showing the prepare for failover window.":::
-
-    > [!NOTE]
-    > If your storage account is configured with a hierarchical namespace enabled, the `Failover` option is disabled.
+    :::image type="content" source="media/storage-initiate-account-failover/portal-failover-redundancy.png" alt-text="Screenshot showing redundancy and failover status." lightbox="media/storage-initiate-account-failover/portal-failover-redundancy.png":::
 
 1. Select the type of failover to prepare for. The confirmation page varies depending on the type of failover you select.
     **If you select `Unplanned Failover`**:
@@ -98,13 +89,6 @@ Complete the following steps to initiate an account failover using the Azure por
 
     :::image type="content" source="media/storage-initiate-account-failover/portal-failover-prepare-failover.png" alt-text="Screenshot showing the failover option selected on the Prepare for failover window." lightbox="media/storage-initiate-account-failover/portal-failover-prepare-failover.png":::
 
-    For more information about potential data loss and what happens to your account redundancy configuration during failover, see:
-
-    > [Anticipate data loss and inconsistencies](storage-disaster-recovery-guidance.md#anticipate-data-loss-and-inconsistencies)
-    >
-    > [Plan for storage account failover](storage-disaster-recovery-guidance.md#plan-for-storage-account-failover)
-    The **Last Sync Time** property indicates the last time the secondary was synchronized with the primary. The difference between **Last Sync Time** and the current time provides an estimate of the extent of data loss that you will experience after the failover is completed. For more information about checking the **Last Sync Time** property, see [Check the Last Sync Time property for a storage account](last-sync-time-get.md).
-
     **If you select `Planned failover`** (preview):
 
     You will see the **Last Sync Time** value, but notice in the image that follows that the failover will not occur until after all of the remaining data is synchronized to the secondary region.
