Merge pull request #304390 from anaharris-ms/rel-ai-search

Reliability: AI Search - Correcting bad merge

Author: JamesJBarnett

articles/reliability/reliability-ai-search.md

@@ -6,39 +6,60 @@ author: haileytap
 ms.author: haileytapia
 ms.service: azure-ai-search
 ms.topic: reliability-article
-ms.date: 08/08/2025
+ms.date: 08/25/2025
 ms.custom: subject-reliability
 ---
 
 # Reliability in Azure AI Search
 
-This article describes reliability support in Azure AI Search, covering intra-regional resiliency via [availability zones](#availability-zone-support) and [multi-region deployments](#multi-region-support).
+Azure AI Search is a scalable search infrastructure that indexes heterogeneous content and enables retrieval through APIs, applications, and AI agents. It's suitable for enterprise search scenarios as well as AI-powered customer experiences that require dynamic content generation through chat completion models.
 
-[!INCLUDE [Shared responsibility description](includes/reliability-shared-responsibility-include.md)]
-
-In Azure AI Search, you can achieve reliability by:
+This article describes reliability support in [Azure AI Search](/azure/search/search-what-is-azure-search), covering intra-regional resiliency via [availability zones](#availability-zone-support) and [multi-region deployments](#multi-region-support).
 
-+ **Scaling a single search service**. Add multiple [replicas](/azure/search/search-capacity-planning#concepts-search-units-replicas-partitions) to increase availability and handle higher indexing and query workloads. If your region supports availability zones, replicas are distributed across different physical data centers on a best-effort basis for extra resiliency.
-
-+ **Deploying multiple search services across different regions**. Each service operates independently within its region. However, in a multi-service scenario, you have options for synchronizing content across all services. You can also use a load-balancing solution to redistribute requests or fail over if there's a service outage.
+[!INCLUDE [Shared responsibility description](includes/reliability-shared-responsibility-include.md)]
 
 ## Production deployment recommendations
 
 For production workloads, we recommend using a [billable tier](/azure/search/search-sku-tier) with at least [two replicas](/azure/search/search-capacity-planning#add-or-remove-partitions-and-replicas). This configuration makes your search service more resilient to transient faults and maintenance operations. It also meets the [service-level agreement](#service-level-agreement) for Azure AI Search, which requires two replicas for read-only workloads and three or more replicas for read-write workloads.
 
 Azure AI Search doesn't provide a service-level agreement for the Free tier, which is limited to one replica and is strongly discouraged for production use.
 
+## Reliability architecture overview
+
+When you use Azure AI Search, you create a *search service*. Each search service supports many *search indexes* that store your searchable content.
+
+Azure AI Search isn't designed as a primary data store. Instead, you use *indexers* to connect your search service to external data sources. An indexer crawls the source data, invokes *skills* that perform processing and enrichment, and populates your index with the skill outputs.
+
+You also configure the number of *replicas* for your service. In Azure AI Search, a replica is a copy of your service's search engine. You can think of a replica as representing a single virtual machine (VM). Each search service can have between 1 and 12 replicas. 
+
+The addition of multiple replicas allows AI Search to:
+
+- Increase the availability of your search service.
+- Perform maintenance on one replica while queries continue executing on other replicas.
+- Handle higher indexing and query workloads.
+- Improve resiliency by attempting to provision replicas in different availability zones, if supported in your region.
+
+One replica is automatically assigned to be the *primary replica* by Azure AI Search. All write operations are performed against that replica. The other replicas are used for read operations.
+
+You can also configure the number of *partitions*, which represent the storage used by the search indexes.
+
+It's important to understand the impact of adding replicas and partitions, because they each affect read and write performance in different ways. For more information about replicas and partitions, see [Estimate and manage capacity of a search service](/azure/search/search-capacity-planning).
+
 ## Transient faults
 
 [!INCLUDE [Transient fault description](includes/reliability-transient-fault-description-include.md)]
 
+Azure AI Search indexers have built-in transient fault handling. If a data source is briefly unavailable, the indexer is designed to recover and retry, and uses change tracking to resume indexing from the last successfully indexed document.
+
 Search services might experience transient faults during standard, unscheduled maintenance operations. Azure AI Search doesn't provide advance notification or allow scheduling of maintenance at specific times. Although every effort is made to minimize downtime, even for single-replica services, brief interruptions can still occur. To improve resiliency against these transient faults, we recommend that you use two or more replicas.
 
+Any applications you build that interact with Azure AI Search should handle transient faults. Use a retry strategy, with exponential backoffs, for both read and write operations.
+
 ## Availability zone support
 
 [!INCLUDE [Availability zone support description](includes/reliability-availability-zone-description-include.md)]
 
-Azure AI Search is zone redundant, which means that your replicas are distributed across multiple availability zones within the service region.
+Azure AI Search is zone redundant, which means that your replicas are distributed across multiple availability zones within the search service region.
 
 When you add two or more replicas to your service, Azure AI Search attempts to place each replica in a different availability zone. For services with more replicas than available zones, replicas are distributed across zones as evenly as possible.
 
@@ -51,11 +72,20 @@ Support for availability zones depends on infrastructure and storage. For a list
 
 ### Requirements
 
-Zone redundancy is automatically enabled when your search service:
+Zone redundancy is automatically enabled when your search service meets all of the following criteria:
 
 + Is in a [region that has availability zones](/azure/search/search-region-support).
-+ Is on the [Basic tier or higher](/azure/search/search-sku-tier). Zone redundancy isn't available for the Free tier.
-+ Has [multiple replicas](/azure/search/search-capacity-planning#add-or-remove-partitions-and-replicas).
++ Is on the [Basic tier or higher](/azure/search/search-sku-tier).
++ Has [at least two replicas](/azure/search/search-capacity-planning#add-or-remove-partitions-and-replicas).
+  
+> [!NOTE]
+> Azure AI Search attempts to distribute replicas across multiple zones when you have two or more replicas. However, for read-write workloads, you should use three or more replicas so that you receive the highest possible availability service-level agreement (SLA).
+
+### Instance distribution across zones
+
+Azure AI Search attempts to place replicas across different availability zones. However, there are occasionally situations where all of the replicas of a search service might be placed into the same availability zone. This situation can happen when replicas are removed from your service, such as when you *scale in* by configuring your service to use fewer replicas. The reason is that replica removal currently doesn't cause the remaining replicas to be rebalanced across the availability zones.
+
+To reduce the likelihood of all of your replicas being placed into a single availability zone, you can manually trigger a scale-out operation immediately after a scale-in operation. For example, suppose your search service has ten replicas and you want to scale in to seven replicas. Instead of performing a single scale operation, you can temporarily scale to six instances, then immediately scale to seven instances, to trigger zone rebalancing.
 
 ### Cost
 
@@ -65,21 +95,41 @@ Each search service starts with one replica. Zone redundancy requires two or mor
 
 If your search service meets the [requirements for zone redundancy](#requirements), no extra configuration is necessary. Whenever possible, Azure AI Search attempts to place your replicas in different availability zones.
 
+### Capacity planning and management
+
+To prepare for availability zone failure, consider *over-provisioning* the number of replicas. Over-provisioning allows the search service to tolerate some degree of capacity loss and continue to function without degraded performance. Adding replicas during an outage is challenging, so over-provisioning helps ensure that your search service can handle normal request volumes, even with reduced capacity. For more information, see [Manage capacity with over-provisioning](/azure/reliability/concept-redundancy-replication-backup#manage-capacity-with-over-provisioning).
+
+### Normal operations
+
+This section describes what to expect when search services are configured for zone redundancy and all availability zones are operational.
+
+- **Traffic routing between zones:** Azure AI Search performs automatic load balancing of all queries and writes across all of the available replicas. Read operations can be sent to any replica in any availability zone. Write operations are sent to a single primary replica, which is selected by the Azure AI Search service.
+
+- **Data replication between zones:** Changes in data are replicated between replicas across availability zones automatically. Replication occurs asynchronously, which means writes are committed to one primary replica before they're replicated to other replicas.
+
 ### Zone-down experience
 
-When an availability zone experiences an outage, your search service continues to operate using replicas in the surviving zones. The following points summarize the expected behavior:
+This section describes what to expect when search services are configured for zone redundancy and there's an availability zone outage.
 
 + **Detection and response**: Azure AI Search is responsible for detecting a failure in an availability zone. You don't need to do anything to initiate a zone failover.
 
-+ **Notification**: Azure AI Search doesn't notify you when a zone is down.
++ **Notification**: Azure AI Search doesn't notify you when a zone is down. However, you can use [Azure Resource Health](/azure/service-health/resource-health-overview) to monitor for the health of replicas. If a zone is down, the replicas in that zone will show as unavailable. You can also use [Azure Service Health](/azure/service-health/overview) to understand the overall health of the Azure AI Search service, including any zone failures.
+
+  Set up alerts on these services to receive notifications of zone-level problems. For more information, see [Create Service Health alerts in the Azure portal](/azure/service-health/alerts-activity-log-service-notifications-portal) and [Create and configure Resource Health alerts](/azure/service-health/resource-health-alert-arm-template-guide).
 
-+ **Active requests**: Any active requests are dropped and should be retried by the client.
++ **Active requests**: Requests being processed by replicas in the failed zone are terminated and should be retried by clients, following the guidance for [handling transient faults](#transient-faults).
 
-+ **Expected data loss**: A zone failure isn't expected to cause data loss.
++ **Expected data loss**: If the affected availability zone only contains read replicas, no data loss is expected.
+  
+  If the primary replica is lost because it was in the affected zone, then any write operations that haven't yet been replicated might be lost.
 
-+ **Expected downtime**: A zone failure isn't expected to cause downtime to your search service, but it can temporarily reduce your service's overall capacity. To maintain optimal performance, consider provisioning more replicas than you typically need. Adding replicas during an outage is challenging, so overprovisioning helps ensure that your service can handle normal request volumes, even with reduced capacity.
++ **Expected downtime**: In most situations, a zone failure isn't expected to cause downtime to your search service for read operations, because read replicas in other availability zones continue to serve requests.
 
-+ **Traffic rerouting**: When a zone fails, Azure AI Search detects the failure and routes requests to active replicas in the surviving zones.
+    If the primary replica is lost because it was in the affected zone, Azure AI Search automatically promotes another replica to become the new primary so that write operations can resume. It typically takes a few seconds for the replica promotion to occur, and during this time write operations might not succeed. Ensure that your applications are prepared by following [transient fault handling guidance](#transient-faults).
+
+    However, there are some unlikely situations where all of your search service's replicas could be in a single availability zone, and if this happens, you might experience downtime until the zone recovers. For more information, and to understand a workaround, see [Instance distribution](#instance-distribution-across-zones).
+
++ **Traffic rerouting**: When a zone fails, Azure AI Search detects the failure and routes requests to active replicas in the surviving zones. If the primary replica was lost, another replica is promoted to be the new primary.
 
 ### Zone recovery
 
@@ -95,7 +145,7 @@ Azure AI Search is a single-region service. If the region becomes unavailable, y
 
 ### Alternative multi-region approaches
 
-To use Azure AI Search in multiple regions, you must deploy separate services in each region. If you create an identical deployment in a secondary Azure region using a multi-region geography architecture, your application becomes less susceptible to a single-region disaster.
+You can optionally deploy multiple Azure AI Search services in different regions. You're responsible for deploying and configuring separate services in each region. If you create an identical deployment in a secondary Azure region using a multi-region architecture, your application becomes less susceptible to a single-region disaster.
 
 When you follow this approach, you must synchronize indexes across regions to recover the last application state. You must also configure load balancing and failover policies. For more information, see [Multi-region deployments in Azure AI Search](/azure/search/search-multi-region).
 
@@ -107,14 +157,13 @@ However, if you accidentally delete the index and don't have a backup, you can [
 
 ## Service-level agreement
 
-The service-level agreement (SLA) for Azure AI Search describes the expected availability of the service and the conditions that must be met to achieve that availability expectation. For more information, see the [SLA for Azure AI Search](https://azure.microsoft.com/support/legal/sla/search/v1_0/).
-
-SLA coverage applies to search services on billable tiers with at least two replicas. In Azure AI Search, a replica is a copy of your index. Each service can have between 1 and 12 replicas. When you [add replicas](/azure/search/search-capacity-planning#add-or-remove-partitions-and-replicas), Azure AI Search can then perform maintenance on one replica while queries continue to execute on other replicas.
+[!INCLUDE [SLA description](includes/reliability-service-level-agreement-include.md)]
 
-Microsoft guarantees at least 99.9% availability of:
+In Azure AI Search, the availability SLA applies to search services that:
 
-+ Read-only workloads (queries) for search services with two replicas.
-+ Read-write workloads (queries and indexing) for search services with three or more replicas.
++ Are configured to use [a billable tier](/azure/search/search-sku-tier).
++ Have at least two [replicas](/azure/search/search-capacity-planning#add-or-remove-partitions-and-replicas) for read-only workloads (queries).
++ Have at least three replicas for read-write workloads (queries and indexing).
 
 ## Related content