Azure AI 搜索是一种可缩放的搜索基础结构，可索引异类内容，并通过 API、应用程序和 AI 代理进行检索。 它适用于需要通过聊天完成模型生成动态内容的企业搜索方案和 AI 支持的客户体验。
本文介绍 Azure AI 搜索中的可靠性支持，包括通过 可用性区域 和 多区域部署实现区域内复原能力。
可靠性是你和Microsoft之间的共同责任。 可以使用本指南确定哪些可靠性选项满足特定业务目标和运行时间目标。
生产部署建议
对于生产工作负荷，建议使用计费层，该层至少应有两个副本。 此配置使搜索服务能够更灵活地应对暂时性故障和维护作。 它还符合 AI 搜索的服务级别协议 (SLA)。 SLA 需要两个副本用于只读工作负荷，三个或更多个副本用于读写工作负荷。
AI 搜索不会为免费层级提供服务级别协议 (SLA)，该层级仅限于一个副本，不推荐用于生产环境。
可靠性体系结构概述
使用 AI 搜索时，将创建 搜索服务。 每个搜索服务都支持许多用于存储可 搜索内容的搜索索引 。
AI 搜索的设计目的不是作为主要数据存储。 而是使用 索引器 将搜索服务连接到外部数据源。 索引器对源数据进行爬网，调用执行处理和扩充的 技能 ，并使用技能输出填充索引。
还可以为服务配置 副本 数。 在 AI 搜索中，副本是您服务的搜索引擎的复制版本。 可以将副本视为表示单个虚拟机（VM）。 每个搜索服务可以有 1 到 12 个副本。
添加多个副本后，AI 搜索可以：
提高搜索服务的可用性。
在查询继续在其他副本上运行时，对一个副本执行维护。
处理更高的索引编制和查询工作负荷。
通过尝试在不同的可用性区域中预配副本（如果您的区域支持可用性区），可以提高系统的弹性。
AI 搜索会自动将一个副本指定为 主要副本。 所有写入作都针对该副本执行。 其他副本用于读取作。
下图演示了包含三个副本的搜索服务可能如何跨三个可用性区域分布：
还可以配置分区数，这些 分区表示搜索索引使用的存储。
请务必了解添加副本和分区的影响，因为它们都以不同的方式影响读取和写入性能。 有关副本和分区的详细信息，请参阅 搜索服务的估计和管理容量。
暂时性故障
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。
AI 搜索索引器具有内置的暂时性故障处理。 如果数据源暂时不可用，则索引器旨在恢复和重试。 它利用变更跟踪, 从上次成功进行索引的文档继续进行索引。
搜索服务可能会在标准、计划外维护作期间遇到暂时性故障。 Azure AI 搜索不提供提前通知或允许在特定时间计划维护。 尽管尽一切努力将停机时间降到最低，即使对于单副本服务，也仍会发生短暂的中断。 为了提高针对这些暂时性故障的复原能力，建议使用两个或多个副本。
如果构建与 AI 搜索交互的任何应用程序，它们应该处理暂时性故障。 对读取和写入操作使用带指数退避的重试策略。
可用性区域支持
可用性区域 是每个 Azure 区域内物理上独立的数据中心群组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
AI 搜索服务是区域冗余的，这意味着副本分布在搜索服务区域中的多个可用区。
向服务添加两个或多个副本时，AI 搜索会尝试将每个副本放置在不同的可用性区域中。 对于具有比可用区域更多的副本的服务，副本将尽可能均匀地分布在各个区域。
下图演示了可能如何跨三个可用性区域部署包含四个副本的示例搜索服务：
重要
AI 搜索不保证副本的精确放置。 放置受容量约束、缩放操作和其他因素的限制。
区域支持
对可用性区域的支持取决于基础结构和存储。 有关受支持区域的列表，请参阅 “选择 AI 搜索区域”。
要求
搜索服务满足以下所有条件时，会自动启用区域冗余：
注释
当你拥有两个或多个副本时，AI 搜索会尝试跨多个区域分发副本。 但是，对于读写工作负荷，应使用三个或更多个副本，以便获得尽可能高的可用性 SLA。
跨区域的实例分布
AI 搜索尝试将副本分布在不同的可用性区域。 但是，有时，可能会将搜索服务的所有副本置于同一可用性区域中。 当从服务中删除副本时（例如，通过配置服务以使用更少的副本来 缩减 时），可能会发生这种情况。 副本删除不会触发剩余副本在可用性区域中重新平衡。
若要减少将所有副本放入单个可用性区域的可能性，可以在缩放作后立即手动触发横向扩展作。 例如，假设搜索服务有 10 个副本，并且你想要扩展到 7 个副本。 与其执行单次缩放操作，不如先将实例暂时缩放至 6 个，然后立刻再缩放至 7 个，以触发区域再平衡。
成本
每个搜索服务都以一个副本开头。 区域冗余需要两个或更多个副本，这会增加运行服务的成本。 若要了解副本的计费影响，请使用 定价计算器。
配置可用性区域支持
如果搜索服务满足 区域冗余的要求，则无需进行额外的配置。 只要可能，AI 搜索会尝试将副本放置在不同的可用性区域中。
容量计划和管理
若要准备可用性区域故障，请考虑 过度预配 副本数。 过度预配允许搜索服务容忍某些容量丢失，并继续正常运行，而不会降低性能。 在中断期间添加副本具有挑战性，因此过度预配有助于确保搜索服务能够处理正常的请求量，即使容量降低也是如此。 有关详细信息，请参阅 通过过度预配管理容量。
常规操作
本部分介绍在为区域冗余配置搜索服务以及所有可用性区域正常运行时会发生什么情况。
区域之间的流量路由： AI 搜索对所有可用副本的所有查询和写入执行自动负载均衡。 AI 搜索可以将读取操作发送到任何可用性区域的任何副本。 它将写操作发送到 AI 搜索服务选择的单个主副本。
区域之间的数据复制： 数据更改在可用性区域的副本之间自动复制。 复制是以异步方式进行的，这意味着写入会首先提交到一个主要副本，然后再复制到其他副本。
区域关闭体验
本节介绍了在配置搜索服务以实现区域冗余时的预期结果，以及发生可用区故障时会出现的情况。
检测和响应： AI 搜索负责检测可用性区域中的故障。 无需执行任何操作即可启动区域故障转移。
通知： AI 搜索不会在区域关闭时通知你。 但是，可以使用 Azure 资源运行状况 来监视副本的运行状况。 如果某个区域关闭，该区域中的副本显示为不可用。 还可以使用 Azure 服务运行状况 来了解 AI 搜索服务的总体运行状况，包括任何区域故障。
针对这些服务设置警报，以接收有关区域级别问题的通知。 有关详细信息，请参阅 Azure 门户中的“创建服务运行状况警报 ”并 创建和配置资源运行状况警报。
活动请求： 在故障区域中，副本所处理的请求将会终止。 客户端应按照 处理暂时性故障的指导重试请求。
预期数据丢失： 如果受影响的可用性区域仅包含只读副本，则不会丢失任何数据。
如果主副本因位于受影响区域中而丢失，则尚未复制的任何写入作都可能会丢失。
预期的停机时间： 在大多数情况下，区域故障不会导致读取操作的搜索服务停机，因为其他可用性区域中的只读副本会继续处理请求。
如果由于位于受影响的区域中而导致主副本丢失，AI 搜索会自动将另一个副本升级为新的主副本，以便恢复写入操作。 副本升级通常需要几秒钟的时间。 在此期间，写入操作可能不会成功。 按照 暂时性故障处理指南确保应用程序已准备好。
在不太可能的某些情况下，所有搜索服务的副本可能位于单个可用区中。 在这种情况下，您可能会遇到停机，直到区域恢复。 有关详细信息，并了解解决方法，请参阅 实例分发。
流量重新路由： 当某个区域发生故障时，AI 搜索系统会检测到故障，并将请求重新路由至幸存区域中的可用副本。 如果丢失了主要副本，会将另一个副本提升为新的主要副本。
区域恢复
当可用性区域恢复时，AI 搜索会自动还原正常操作，并开始将流量路由至所有可用的区域，包括恢复的区域。
对区域故障进行测试
AI 搜索管理区域冗余服务的流量路由。 无需启动或验证任何区域故障进程。
多区域支持
AI 搜索是单区域服务。 如果区域不可用，则搜索服务也变得不可用。
备选多区域方法
可以选择在不同的区域中部署多个 AI 搜索服务。 你负责在每个区域中部署和配置单独的服务。 如果在使用多区域架构的次要 Azure 区域中创建相同的部署，您的应用程序将不太容易受到单区域灾难的影响。
按照此方法作时，必须跨区域同步索引以恢复最后一个应用程序状态。 还必须配置负载均衡和故障转移策略。
若要优化整体解决方案的性能，请查找对数据源的只读副本执行索引的机会。 例如，某些索引器支持从异地分布式数据源的只读副本进行读取。
Backups
由于 AI 搜索不是主数据存储解决方案，因此它不提供自助备份和还原选项。 但是，可以使用 index-backup-restore.NET 或 Python 的示例将索引定义及其文档备份到一系列 JSON 文件，然后用于还原索引。
但是，如果意外删除了索引且没有备份，则可以 重新生成索引。 重新生成涉及在搜索服务上重新创建索引，然后通过从主数据存储检索数据来重新加载索引。
服务级别协议
Azure 服务的服务级别协议 (SLA) 描述了每个服务的预期可用性，以及解决方案为实现该可用性预期而必须满足的条件。 有关详细信息，请参阅 联机服务的 SLA。
在 AI 搜索中，可用性 SLA 适用于以下搜索服务：