Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
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.
This article describes reliability support in Azure AI Search, covering intra-regional resiliency via availability zones and multi-region deployments.
Reliability is a shared responsibility between you and Microsoft. You can use this guide to determine which reliability options fulfill your specific business objectives and uptime goals.
Production deployment recommendations
For production workloads, we recommend using a billable tier with at least two replicas. This configuration makes your search service more resilient to transient faults and maintenance operations. It also meets the 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.
Transient faults
Transient faults are short, intermittent failures in components. They occur frequently in a distributed environment like the cloud, and they're a normal part of operations. Transient faults correct themselves after a short period of time. It's important that your applications can handle transient faults, usually by retrying affected requests.
All cloud-hosted applications should follow the Azure transient fault handling guidance when they communicate with any cloud-hosted APIs, databases, and other components. For more information, see Recommendations for handling transient faults.
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
Availability zones are physically separate groups of datacenters within each Azure region. When one zone fails, services can fail over to one of the remaining zones.
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.
Important
Azure AI Search doesn't guarantee the exact placement of replicas, which is subject to capacity constraints, scaling operations, and other factors.
Region support
Support for availability zones depends on infrastructure and storage. For a list of supported regions, see Choose a region for Azure AI Search.
Requirements
Zone redundancy is automatically enabled when your search service meets all of the following criteria:
- Is in a region that has availability zones.
- Is on the Basic tier or higher.
- Has at least two 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
Each search service starts with one replica. Zone redundancy requires two or more replicas, which increases the cost of running the service. To understand the billing implications of replicas, use the pricing calculator.
Configure availability zone support
If your search service meets the requirements for zone redundancy, 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.
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
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. However, you can use Azure Resource Health 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 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 and Create and configure Resource Health alerts.
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.
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: 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.
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.
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.
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
When the availability zone recovers, Azure AI Search automatically restores normal operations and begins routing traffic to available replicas across all zones, including the recovered zone.
Testing for zone failures
Azure AI Search manages traffic routing for zone-redundant services. You don't need to initiate or validate any zone failure processes.
Multi-region support
Azure AI Search is a single-region service. If the region becomes unavailable, your search service also becomes unavailable.
Alternative multi-region approaches
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.
Backups
Because AI Search isn't a primary data storage solution, it doesn't offer self-service backup and restore options. However, you can use the index-backup-restore
sample for .NET or Python to back up your index definition and its documents to a series of JSON files, which are then used to restore the index.
However, if you accidentally delete the index and don't have a backup, you can rebuild the index. Rebuilding involves recreating the index on your search service and then reloading it by retrieving data from your primary data store.
Service-level agreement
The service-level agreement (SLA) for Azure services describes the expected availability of each service and the conditions that your solution must meet to achieve that availability expectation. For more information, see SLAs for online services.
In Azure AI Search, the availability SLA applies to search services that:
- Are configured to use a billable tier.
- Have at least two replicas for read-only workloads (queries).
- Have at least three replicas for read-write workloads (queries and indexing).