Azure AI 搜尋中的可靠性
在 Azure 中， 可靠性 表示如果服務中斷或降低，復原和可用性。 在 Azure AI 搜尋服務中，您可以在單一服務內或透過不同區域中的多個搜尋服務來達成可靠性。
部署單一搜尋服務並相應增加以達到高可用性。 您可以新增多個復本來處理較高的索引編製和查詢工作負載。 如果您的搜尋服務 支援可用性區域，複本會自動布建在不同的實體數據中心，以取得額外的復原能力。
跨不同的地理區域部署多個搜尋服務。 所有搜尋工作負載都完全包含在單一地理區域中執行的單一服務內，但在多服務案例中，您可以選擇同步處理內容，讓所有服務都相同。 您也可以設定負載平衡解決方案，以重新發佈要求，或在服務中斷時故障轉移。
針對區域層級的災害進行商務持續性和復原，請規劃跨區域拓撲，其中包含多個具有相同組態和內容的搜尋服務。 如果您的自定義腳本或程序代碼在突然無法使用時，會將「故障轉移」機制提供給替代搜尋服務。
高可用性
在 Azure AI 搜尋中，複本是索引的複本。 搜尋服務會委託至少一個復本，且最多可以有12個複本。 新增複本可讓 Azure AI 搜尋針對一個複 本執行機器重新啟動和維護，而查詢執行會繼續在其他複本上執行。
對於每個個別的搜尋服務，Microsoft 保證符合下列準則的設定至少有 99.9% 的可用性：
針對唯讀工作負載 (查詢)，需有 2 個複本才能達到高可用性
針對讀取/寫入工作負載 (查詢和索引) 的高可用性為 3 或更多個複本
系統具有監視複本健全狀況和數據分割完整性的內部機制。 如果您布建複本和分割區的特定組合，系統可確保服務的容量層級。
免費層不提供 SLA。 如需詳細資訊，請參閱 Azure AI 搜尋的 SLA。
可用性區域支援
可用性區域 是 Azure 平臺功能，可將區域資料中心分成不同的實體位置群組，以提供相同區域內的高可用性。 在 Azure AI 搜尋中，個別複本是區域指派的單位。 搜尋服務會在一個區域內執行;其復本會在該區域內的不同實體數據中心（或區域）中執行。
當您將兩個或多個復本新增至搜尋服務時，會使用可用性區域。 每個復本都會放在區域內的不同可用性區域中。 如果您有比搜尋服務區域中可用區域更多的複本，複本會盡可能平均地分散到區域。 除了在提供可用性區域的區域中建立搜尋服務，然後設定服務以使用多個複本之外，您的部分沒有特定的動作。
必要條件
- 服務層級必須是標準或更高層級。
- 服務區域必須位於具有可用區域的區域中（下一節所列）。
- 組態必須包含多個複本：兩個用於唯讀查詢工作負載，三個用於包含索引的讀寫工作負載。
支援的區域
可用性區域的支援取決於基礎結構和記憶體。 目前，在 2023 年 10 月宣佈的兩個區域記憶體不足，且不提供 Azure AI 搜尋的可用性區域：
- 以色列中部
- 義大利北部
否則，下列區域支援 Azure AI 搜尋的可用性區域：
| 區域 | 推出 |
|---|---|
| 澳大利亞東部 | 2021 年 1 月 30 日或更新版本 |
| 巴西南部 | 2021 年 5 月 2 日或更新版本 |
| 加拿大中部 | 2021 年 1 月 30 日或更新版本 |
| 印度中部 | 2022 年 1 月 20 日或更新版本 |
| 美國中部 | 2020 年 12 月 4 日或更新版本 |
| 中國北部 3 | 2022 年 9 月 7 日或更新版本 |
| 東亞 | 2022 年 1 月 13 日或更新版本 |
| 美國東部 | 2021 年 1 月 27 日或更新版本 |
| 美國東部 2 | 2021 年 1 月 30 日或更新版本 |
| 法國中部 | 2020 年 10 月 23 日或更新版本 |
| 德國中西部 | 2021 年 5 月 3 日或更新版本 |
| 日本東部 | 2021 年 1 月 30 日或更新版本 |
| 南韓中部 | 2022 年 1 月 20 日或更新版本 |
| 北歐 | 2021 年 1 月 28 日或更新版本 |
| 挪威東部 | 2022 年 1 月 20 日或更新版本 |
| 卡達中部 | 2022 年 8 月 25 日或更新版本 |
| 南非北部 | 2022 年 9 月 7 日或更新版本 |
| 美國中南部 | 2021 年 4 月 30 日或更新版本 |
| 東南亞 | 2021 年 1 月 31 日或更新版本 |
| 瑞典中部 | 2022 年 1 月 21 日或更新版本 |
| 瑞士北部 | 2022 年 9 月 7 日或更新版本 |
| 阿拉伯聯合大公國北部 | 2022 年 9 月 9 日或更新版本 |
| 英國南部 | 2021 年 1 月 30 日或更新版本 |
| US Gov 維吉尼亞州 | 2021 年 4 月 30 日或更新版本 |
| 西歐 | 2021 年 1 月 29 日或更新版本 |
| 美國西部 2 | 2021 年 1 月 30 日或更新版本 |
| 美國西部 3 | 2021 年 6 月 2 日或更新版本 |
注意
可用性區域不會變更 Azure AI 搜尋服務等級協議的條款。 您仍然需要三個以上的複本，以取得查詢高可用性。
不同地理區域中的多個服務
如果您的作業需求包括：
商務持續性和災害復原 （BCDR） 需求 （Azure AI 搜尋服務在中斷時不會提供立即故障轉移）。
全域分散式應用程式的快速效能。 如果查詢和編製索引要求來自世界各地，最接近主機數據中心的用戶會體驗更快的效能。 在接近這些用戶的區域中建立更多服務，即可讓所有使用者的效能相等。
如果您需要兩個以上的搜尋服務，請在不同的區域中建立它們，可以符合持續性和復原的應用程式需求，以及全域使用者群的更快速回應時間。
Azure AI 搜尋不提供跨地理區域複寫搜尋索引的自動化方法，但有一些技術可讓此程式簡化實作和管理。 下列幾節將概述這些技術。
異地分散式搜尋服務集合的目標是在兩個或多個區域中有兩個或多個索引可供使用，其中使用者會路由傳送至 Azure AI 搜尋服務，以提供最低延遲：
您可以建立多個服務並設計數據同步處理策略，以實作此架構。 您可以選擇性地包含資源，例如路由要求的 Azure 流量管理員。
提示
如需跨多個區域部署多個搜尋服務的說明，請參閱 GitHub 上的此 Bicep 範例，以部署完整設定的多區域搜尋解決方案。 此範例提供索引同步處理的兩個選項，以及使用 流量管理員 要求重新導向。
跨多個服務同步處理數據
有兩個選項可將兩個以上的不同搜尋服務保持同步：
- 使用 索引器將內容更新提取至搜尋索引。
- 使用 新增或更新檔 （REST） API 或 Azure SDK 對等 API 將內容推送至索引。
若要設定任一選項，建議您在 azure-search-multiple-region 存放庫中使用範例 Bicep 腳本，並修改為您的區域和編製索引策略。
選項 1：使用索引器更新多個服務上的內容
如果您已經在某個服務上使用索引器，您可以在第二個服務上設定第二個索引器，以使用相同的數據源物件，從相同位置提取數據。 每個區域中的每個服務都有自己的索引器和目標索引（您的搜尋索引未共用，這表示每個索引都有自己的數據複本），但每個索引器都會參考相同的數據源。
以下是該架構外觀的高階視覺效果。
選項 2：使用 REST API 在多個服務上推送內容更新
如果您使用 Azure AI 搜尋服務 REST API 將 內容推送至搜尋索引，只要需要更新，就可以將變更推送至所有搜尋服務，讓各種搜尋服務保持同步。 在您的程式代碼中，請務必處理更新至一個搜尋服務失敗，但會成功處理其他搜尋服務的情況。
故障轉移或重新導向查詢要求
如果您需要要求層級的備援，Azure 會提供數 個負載平衡選項：
- Azure 流量管理員，用來將要求路由傳送至多個地理位置網站，然後由多個搜尋服務支援。
- 應用程式閘道，用來在應用層區域中的伺服器之間進行負載平衡。
- Azure Front Door，用來優化 Web 流量的全域路由，並提供全域故障轉移。
評估負載平衡選項時，請記住一些重點：
搜尋是一項後端服務，可接受來自客戶端的查詢和編製要求索引。
用戶端對搜尋服務的要求必須經過驗證。 若要存取搜尋作業，呼叫端必須具有角色型許可權，或在要求上提供 API 金鑰。
服務端點預設會透過公用因特網連線來連線。 如果您為源自虛擬網路內的用戶端連線設定私人端點，請使用 應用程式閘道。
Azure AI 搜尋會接受尋址至
<your-search-service-name>.search.windows.net端點的要求。 如果您在主機標頭中使用不同的 DNS 名稱來連線到相同的端點，例如 CNAME，則會拒絕要求。
Azure AI 搜尋提供多區域部署範例，如果主要端點失敗，則會使用 Azure 流量管理員 進行要求重新導向。 當您路由至只呼叫相同區域中搜尋服務的已啟用搜尋用戶端時，此解決方案很有用。
Azure 流量管理員 主要用於根據特定路由方法（例如優先順序、效能或地理位置）跨不同端點路由網路流量。 它會在 DNS 層級上運作，以將連入要求導向至適當的端點。 如果服務 流量管理員 的端點開始拒絕要求，流量就會路由傳送至另一個端點。
流量管理員 不提供直接連線至 Azure AI 搜尋的端點，這表示您無法將搜尋服務直接放在 流量管理員 後面。 相反地，假設要求會流向 流量管理員，然後流向已啟用搜尋的 Web 用戶端，最後流向後端的搜尋服務。 用戶端和服務位於相同的區域中。 如果一個搜尋服務關閉，搜尋用戶端就會開始失敗，流量管理員 重新導向至其餘用戶端。
關於多區域部署中的數據落地
當您在各種地理區域中部署多個搜尋服務時，您的內容會儲存在您為每個搜尋服務選擇的區域。
Azure AI 搜尋不會在指定的區域外儲存數據，而不需要您的授權。 當您使用寫入 Azure 儲存體 資源的功能時，授權是隱含的：擴充快取、偵錯會話、知識存放區。 在所有情況下，記憶體帳戶都是您在您選擇的區域中提供的帳戶。
注意
如果記憶體帳戶和搜尋服務都位於相同的區域，則搜尋與記憶體之間的網路流量會使用私人IP位址，並透過 Microsoft 骨幹網路發生。 由於使用私人IP位址，因此您無法設定IP防火牆或私人端點來獲得網路安全性。 相反地，當兩個服務都位於相同區域時，請使用 受信任的服務例外 狀況作為替代方案。
關於服務中斷和災難性事件
如服務等級協定（SLA）所述，當 Azure AI 搜尋服務 實例設定為兩個以上的複本時，Microsoft 會保證索引查詢要求的高可用性，以及當 Azure AI 搜尋服務 實例設定為三個或多個複本時，索引更新要求。 不過，沒有內建的災害復原機制。 如果在 Microsoft 控制外部發生重大失敗時需要持續服務，建議您在不同的區域中布建第二個服務，並實作異地復寫策略，以確保索引在所有服務中都是完全備援的。
使用 索引器 填入和重新整理索引的客戶，可以透過從相同數據源擷取數據的異地特定索引器來處理災害復原。 不同區域中的兩個服務，每個執行索引器，都可以為相同的數據源編製索引，以達到異地備援。 如果您要從也是異地備援的數據源編製索引，請記住，Azure AI 搜尋服務索引器只能從主要復本執行累加式索引編製（合併來自新、修改或刪除檔的更新）。 在故障轉移事件中，請務必將索引器重新導向至新的主要複本。
如果您沒有使用索引器，您會使用應用程式程式代碼，以平行方式將對象和數據推送至不同的搜尋服務。 如需詳細資訊，請參閱 讓數據跨多個服務保持同步。
備份和還原替代專案
數據層的商務持續性策略通常包含從備份還原的步驟。 由於 Azure AI 搜尋不是主要資料記憶體解決方案，因此 Microsoft 不提供自助式備份和還原的正式機制。 不過，您可以使用此 Azure AI 搜尋 .NET 範例存放庫中的 index-backup-restore 範例程式代碼，將索引定義和快照集備份到一系列 JSON 檔案，然後視需要使用這些檔案來還原索引。 此工具也可以在服務層級之間移動索引。
否則，如果您不小心刪除索引，則用來建立和填入索引的應用程式程式代碼是事實上的還原選項。 若要重建索引，您會將其刪除（假設存在）、重新建立服務中的索引，然後從主要數據存放區擷取數據來重載。
下一步
- 檢閱 服務限制 ，以深入瞭解每個定價層和服務限制。
- 檢閱 規劃容量 ，以深入了解數據分割和複本組合。
- 檢閱 案例研究：使用認知搜尋來支持複雜的 AI 案例 ，以取得更多設定指引。