Merge pull request #1118 from cdpark/refresh-oct-mattgott

Feature 322546: Q&M: Freshness - AI Services & Search 180d target - Oct sprint - mattgott

Author: JamesJBarnett

articles/search/search-reliability.md

@@ -1,12 +1,12 @@
 ---
 title: Reliability in Azure AI Search
 titleSuffix: Azure AI Search
-description: Find out about reliability in Azure AI Search.
+description: Learn how to improve the reliability and availability of Azure AI Search services.
 author: mattgotteiner
 ms.author: magottei
 ms.service: azure-ai-search
 ms.topic: conceptual
-ms.date: 09/04/2024
+ms.date: 10/29/2024
 ms.custom:
   - subject-reliability
   - references_regions
@@ -21,7 +21,7 @@ Across Azure, [reliability](/azure/reliability/overview) means resiliency and av
 
 + Deploy multiple search services across different geographic regions. All search workloads are fully contained within a single service that runs in a single geographic region, but in a multi-service scenario, you have options for synchronizing content so that it's the same across all services. You can also set up a load balancing solution to redistribute requests or fail over if there's a service outage.
 
-For business continuity and recovery from disasters at a regional level, plan on a cross-regional topology, consisting of multiple search services having identical configuration and content. Your custom script or code provides the "fail over" mechanism to an alternate search service if one suddenly becomes unavailable.
+For business continuity and recovery from disasters at a regional level, plan on a cross-regional topology, consisting of multiple search services having identical configuration and content. Your custom script or code provides the *fail over* mechanism to an alternate search service if one suddenly becomes unavailable.
 
 <a name="scale-for-availability"></a>
 
@@ -31,27 +31,27 @@ In Azure AI Search, replicas are copies of your index. A search service is commi
 
 For each individual search service, Microsoft guarantees at least 99.9% availability for configurations that meet these criteria:
 
-+ Two replicas for high availability of read-only workloads (queries)
++ Two replicas for high availability of *read-only* workloads (queries)
 
-+ Three or more replicas for high availability of read-write workloads (queries and indexing) 
++ Three or more replicas for high availability of *read-write* workloads (queries and indexing) 
 
 The system has internal mechanisms for monitoring replica health and partition integrity. If you provision a specific combination of replicas and partitions, the system ensures that level of capacity for your service.
 
-No SLA is provided for the Free tier. For more information, see [SLA for Azure AI Search](https://azure.microsoft.com/support/legal/sla/search/v1_0/).
+No Service Level Agreement (SLA) is provided for the *Free* tier. For more information, see the [SLA for Azure AI Search](https://azure.microsoft.com/support/legal/sla/search/v1_0/).
 
 <a name="availability-zones"></a>
 
 ## Availability zone support
 
-[Availability zones](/azure/availability-zones/az-overview) are an Azure platform capability that divides a region's data centers into distinct physical location groups to provide high-availability, within the same region. In Azure AI Search, individual replicas are the units for zone assignment. A search service runs within one region; its replicas run in different physical data centers (or zones) within that region.
+[Availability zones](/azure/availability-zones/az-overview) are an Azure platform capability that divides a region's data centers into distinct physical location groups to provide high availability, within the same region. In Azure AI Search, individual replicas are the units for zone assignment. A search service runs within one region; its replicas run in different physical data centers (or zones) within that region.
 
 Availability zones are used when you add two or more replicas to your search service. Each replica is placed in a different availability zone within the region. If you have more replicas than available zones in the search service region, the replicas are distributed across zones as evenly as possible. There's no specific action on your part, except to [create a search service](search-create-service-portal.md) in a region that provides availability zones, and then to configure the service to [use multiple replicas](search-capacity-planning.md#adjust-capacity).
 
 ### Prerequisites
 
-+ Service tier must be Standard or higher.
-+ Service region must be in a region that has available zones (listed in the following section).
-+ Configuration must include multiple replicas: two for read-only query workloads, three for read-write workloads that include indexing.
++ Service tier must be *Standard* or higher
++ Service region must be in a region that has available zones (listed in the following section)
++ Configuration must include multiple replicas: two for read-only query workloads, three for read-write workloads that include indexing
 
 ### Supported regions
 
@@ -61,7 +61,7 @@ Support for availability zones depends on infrastructure and storage. Currently,
 
 Otherwise, availability zones for Azure AI Search are supported in the following regions:
 
-| Region | Roll out |
+| Region | Roll out date |
 |--------|-----------|
 | Australia East | January 30, 2021 or later |
 | Brazil South |  May 2, 2021 or later |
@@ -94,13 +94,13 @@ Otherwise, availability zones for Azure AI Search are supported in the following
 | West US 3 | June 02, 2021 or later |
 
 > [!NOTE]
-> Availability zones don't change the terms of the [Azure AI Search Service Level Agreement](https://azure.microsoft.com/support/legal/sla/search/v1_0/). You still need three or more replicas for query high availability.
+> Availability zones don't change the terms of the [SLA](https://azure.microsoft.com/support/legal/sla/search/v1_0/). You still need three or more replicas for query high availability.
 
 ## Multiple services in separate geographic regions
 
 Service redundancy is necessary if your operational requirements include:
 
-+ [Business continuity and disaster recovery (BCDR) requirements](/azure/availability-zones/cross-region-replication-azure) (Azure AI Search doesn't provide instant failover if there's an outage).
++ [Business continuity and disaster recovery (BCDR) requirements](/azure/reliability/disaster-recovery-overview). Azure AI Search doesn't provide instant failover if there's an outage.
 
 + Fast performance for a globally distributed application. If query and indexing requests come from all over the world, users who are closest to the host data center experience faster performance. Creating more services in regions with close proximity to these users can equalize performance for all users.
 
@@ -110,7 +110,7 @@ Azure AI Search doesn't provide an automated method of replicating search indexe
 
 The goal of a geo-distributed set of search services is to have two or more indexes available in two or more regions, where a user is routed to the Azure AI Search service that provides the lowest latency:
 
-   ![Cross-tab of services by region][1]
+   ![Diagram showing cross-tab view of services by region.][1]
 
 You can implement this architecture by creating multiple services and designing a strategy for data synchronization. Optionally, you can include a resource like Azure Traffic Manager for routing requests. 
 
@@ -134,7 +134,7 @@ If you're already using indexer on one service, you can configure a second index
 
 Here's a high-level visual of what that architecture would look like.
 
-![Single data source with distributed indexer and service combinations][2]
+![Diagram showing a single data source with distributed indexer and service combinations.][2]
 
 #### Option 2: Use REST APIs for pushing content updates on multiple services
 
@@ -164,39 +164,38 @@ Azure Traffic Manager is primarily used for routing network traffic across diffe
 
 Traffic Manager doesn't provide an endpoint for a direct connection to Azure AI Search, which means you can't put a search service directly behind Traffic Manager. Instead, the assumption is that requests flow to Traffic Manager, then to a search-enabled web client, and finally to a search service on the backend. The client and service are located in the same region. If one search service goes down, the search client starts failing, and Traffic Manager redirects to the remaining client.
 
-![Search apps connecting through Azure Traffic Manager][4]
+![Diagram of search apps connecting through Azure Traffic Manager.][4]
 
-## About data residency in a multi-region deployment
+## Data residency in a multi-region deployment
 
 When you deploy multiple search services in various geographic regions, your content is stored in the region you chose for each search service.
 
-Azure AI Search won't store data outside of your specified region without your authorization. Authorization is implicit when you use features that write to an Azure Storage resource: [enrichment cache](cognitive-search-incremental-indexing-conceptual.md), [debug session](cognitive-search-debug-session.md), [knowledge store](knowledge-store-concept-intro.md). In all cases, the storage account is one that you provide, in the region of your choice. 
+Azure AI Search doesn't store data outside of your specified region without your authorization. Authorization is implicit when you use features that write to an Azure Storage resource: [enrichment cache](cognitive-search-incremental-indexing-conceptual.md), [debug session](cognitive-search-debug-session.md), [knowledge store](knowledge-store-concept-intro.md). In all cases, the storage account is one that you provide, in the region of your choice. 
 
 > [!NOTE]
 > If both the storage account and the search service are in the same region, network traffic between search and storage uses a private IP address and occurs over the Microsoft backbone network. Because private IP addresses are used, you can't configure IP firewalls or a private endpoint for network security. Instead, use the [trusted service exception](search-indexer-howto-access-trusted-service-exception.md) as an alternative when both services are in the same region. 
 
 ## About service outages and catastrophic events
 
-As stated in the [Service Level Agreement (SLA)](https://azure.microsoft.com/support/legal/sla/search/v1_0/), Microsoft guarantees a high level of availability for index query requests when an Azure AI Search service instance is configured with two or more replicas, and index update requests when an Azure AI Search service instance is configured with three or more replicas. However, there's no built-in mechanism for disaster recovery. If continuous service is required in the event of a catastrophic failure outside of Microsoft’s control, we recommend provisioning a second service in a different region and implementing a geo-replication strategy to ensure indexes are fully redundant across all services.
+As stated in the [SLA](https://azure.microsoft.com/support/legal/sla/search/v1_0/), Microsoft guarantees a high level of availability for index query requests when an Azure AI Search service instance is configured with two or more replicas, and index update requests when an Azure AI Search service instance is configured with three or more replicas. However, there's no built-in mechanism for disaster recovery. If continuous service is required in the event of a catastrophic failure outside of Microsoft’s control, we recommend provisioning a second service in a different region and implementing a geo-replication strategy to ensure indexes are fully redundant across all services.
 
 Customers who use [indexers](search-indexer-overview.md) to populate and refresh indexes can handle disaster recovery through geo-specific indexers that retrieve data from the same data source. Two services in different regions, each running an indexer, could index the same data source to achieve geo-redundancy. If you're indexing from data sources that are also geo-redundant, remember that Azure AI Search indexers can only perform incremental indexing (merging updates from new, modified, or deleted documents) from primary replicas. In a failover event, be sure to redirect the indexer to the new primary replica. 
 
-If you don't use indexers, you would use your application code to push objects and data to different search services in parallel. For more information, see [Keep data synchronized across multiple services](#data-sync).
+If you don't use indexers, you would use your application code to push objects and data to different search services in parallel. For more information, see [Synchronize data across multiple services](#data-sync).
 
 ## Back up and restore alternatives
 
 A business continuity strategy for the data layer usually includes a restore-from-backup step. Because Azure AI Search isn't a primary data storage solution, Microsoft doesn't provide a formal mechanism for self-service backup and restore. However, you can use the **index-backup-restore** sample code in this [Azure AI Search .NET sample repo](https://github.com/Azure-Samples/azure-search-dotnet-utilities) to back up your index definition and snapshot to a series of JSON files, and then use these files to restore the index, if needed. This tool can also move indexes between service tiers.
 
 Otherwise, your application code used for creating and populating an index is the de facto restore option if you delete an index by mistake. To rebuild an index, you would delete it (assuming it exists), recreate the index in the service, and reload by retrieving data from your primary data store.
 
-## Next steps
+## Related content
 
-+ Review [Service limits](search-limits-quotas-capacity.md) to learn more about the pricing tiers and services limits for each one.
++ Review [Service limits](search-limits-quotas-capacity.md) to learn more about the pricing tiers and service limits.
 + Review [Plan for capacity](search-capacity-planning.md) to learn more about partition and replica combinations.
 + Review [Case Study: Use Cognitive Search to Support Complex AI Scenarios](https://techcommunity.microsoft.com/t5/azure-ai/case-study-effectively-using-cognitive-search-to-support-complex/ba-p/2804078) for more configuration guidance.
 
 <!--Image references-->
 [1]: ./media/search-reliability/geo-redundancy.png
 [2]: ./media/search-reliability/scale-indexers.png
-[3]: ./media/search-reliability/geo-search-traffic-mgr.png
 [4]: ./media/search-reliability/azure-function-search-traffic-mgr.png

articles/search/toc.yml

@@ -199,7 +199,7 @@ items:
       href: search-capacity-planning.md
     - name: Plan and manage costs
       href: search-sku-manage-costs.md
-    - name: Availability and recovery
+    - name: Reliability and recovery
       href: search-reliability.md
     - name: Availability migration guidance
       href: /azure/reliability/migrate-search-service