Azure AI 搜尋中的多區域部署

Note

Azure AI 搜尋服務 可透過 Azure 入口網站、REST API 及 Azure SDK 取得。 它同時也是 Foundry IQ 的基礎,這是一個管理式知識層,能將企業內容轉化為可重複使用、權限感知的知識庫,供 Microsoft Foundry 入口網站中的代理使用。

雖然 Azure AI 搜尋服務 是單一區域服務,但透過部署多個配置與內容相同的搜尋服務,可以達到更高的可靠性。

本文說明多區域解決方案的元件;此解決方案仰賴您的自訂指令碼或程式碼來處理容錯移轉,以因應服務無法使用的情況。

如需 Azure AI 搜尋的可靠性功能詳細資訊,包括透過可用性區域進行區域內部復原,請參閱 Azure AI 搜尋中的可靠性。

為什麼要使用多個區域?

如果您需要兩個或多個搜尋服務,請在不同的區域中建立它們,可以符合下列作業需求:

  • 對區域中斷的復原能力。 如果發生中斷,Azure AI 搜尋不會提供即時切換至另一個區域。

  • 全域分散式應用程式的快速效能。 如果索引編製和查詢要求來自世界各地,最接近主機數據中心的用戶會體驗更快的效能。 在靠近這些用戶的區域建立更多服務,可以讓每個人的效能相等。

多區域架構

在多重區域設定中,有兩個以上的搜尋服務位於不同的區域,並具有同步索引。 系統會以最低延遲自動將使用者路由傳送至服務。

Azure AI 搜尋不提供跨區域索引複寫的自動化方法。 不過,您可以使用 推送或提取模型索引來同步處理數據,這兩者都會在下一節中說明。 您也可以新增 Azure 流量管理員或其他負載平衡器以進行 要求重新導向。

下圖說明一組異地分散式搜尋服務:

顯示依區域而分的服務交叉表檢視的圖表。

多區域 Bicep 樣本

試著執行這個範例,了解如何在多個區域部署 Azure AI 搜尋服務,並由 Azure Front Door 處理故障轉移: Azure-Samples/azure-search-multiple-regions。

部署會在兩個區域建立相同的 Azure AI 搜尋服務,並透過 Azure Functions API 公開。

透過結合健康探測與優先順序導向, Azure Front Door 能在區域故障時自動將流量重新導向次要區域。 開發者常用這種多區域模式來提升搜尋型應用程式的可用性與災難復原能力。

資料同步

若要同步處理兩個或多個相異的搜尋服務,您可以:

如果您使用 REST API 將 內容推送至索引,您可以在每次發生變更時將更新傳送至每個服務,以同步處理多個搜尋服務。 請確定您的程式代碼會處理一個服務更新失敗但其他服務成功的情況。

資料存放位置

當您在不同的區域中建立多個搜尋服務時,您的內容會儲存在您為每個服務選擇的區域。

Azure AI 搜尋不會在指定的區域外部儲存數據,而不需要您的授權。 當您使用寫入 Azure 儲存體的功能時,授權是默認的,為此您需要在所偏好的區域中提供一個儲存體帳戶。 這些功能包括:

如果您的搜尋服務和記憶體帳戶位於相同的區域,網路流量會透過Microsoft骨幹網路使用私人IP位址,因此您無法設定IP防火牆或私人端點的網路安全性。 或者,使用 受信任的服務例外狀況。

要求容錯移轉與重新導向

針對要求層級的備援,Azure 提供數個 負載平衡選項:

使用 Azure 應用程式閘道 在應用層區域中的伺服器之間進行負載平衡。

根據預設,服務端點會透過公用因特網連線來存取。 如果您為源自虛擬網路內的用戶端連線設定私人端點,請使用應用程式閘道。

當您評估這些負載平衡選項時,請考慮下列幾點:

  • Azure AI 搜尋服務是一種後端服務,可接受來自用戶端的索引編製和查詢要求。

  • 根據預設,服務端點會透過公用因特網連線來存取。 針對源自虛擬網路內的私人端點,我們建議 使用 Azure 應用程式閘道 。

  • Azure AI 搜尋會接受傳送到 <your-search-service-name>.search.windows.net 端點的要求。 如果您在主機標頭中使用不同的 DNS 名稱 (例如 CNAME) 來連線到相同的端點,則會拒絕要求。

  • 用戶端向搜尋服務發出的要求必須經過驗證。 若要存取搜尋作業,呼叫端必須具有 角色型許可權 ,或向要求提供 API 金鑰 。