共用方式為

Azure OpenAI 服務的商務持續性和災害復原 (BCDR) 考量

  • 發行項

Azure OpenAI 於多個區域提供。 當您建立 Azure OpenAI 資源時，會指定區域。 從當時刻起，您的資源及其所有作業都會與該 Azure 伺服器區域建立關聯。

遇到影響整個區域的網路問題相當罕見，但並非不可能。 如果您的服務必須保持隨時可用，建議您將其設計為可容錯移轉到另一個區域，或將工作負載分割到兩個或更多區域。 這兩種方法至少需要不同區域中的兩項 Azure OpenAI 資源。 本文提供如何為您的 Azure OpenAI 應用程式實作商務持續性和災害復原 (BCDR) 的一般建議。

根據預設，Azure OpenAI 服務會提供 預設 SLA。 雖然預設恢復功能可能足以供許多應用程式使用，但需要高度復原和商務持續性的應用程式應採取其他步驟，進一步加強其模型基礎結構。

標準部署

注意

如果可以使用全域標準部署，您應該改用這些部署。 數據區部署是要求數據處理完全在地理界限內進行的組織下一個最佳選項。

  1. 針對 [標準部署] 預設為 [數據區部署] （US/EU 選項）。

  2. 您應該在 Azure 訂用帳戶中部署兩個 Azure OpenAI 服務資源。 一個資源應該部署在您的慣用區域中，另一個資源應該部署在次要/故障轉移區域中。 Azure OpenAI 服務會在訂用帳戶 + 區域層級配置配額，因此它們可以存在於相同的訂用帳戶中，而不會影響配額。

  3. 您應該針對您打算在慣用 Azure 區域中使用部署至 Azure OpenAI 服務資源的每個模型都有一個部署，而且您應該在次要/故障轉移區域中複製這些模型部署。 將標準部署中可用的完整配額配置給每個端點。 相較於分割多個部署的配額，這可提供最高的輸送量速率。

  4. 根據您的網路拓撲選取部署區域。 您可以將 Azure OpenAI 服務資源部署至任何支援的區域，然後在您慣用區域中為該資源建立私人端點。

    • 在 Azure OpenAI 服務界限內之後，Azure OpenAI 服務會將數據區域中可用計算的路由和處理優化。
    • 使用數據區域比跨多個區域部署的自我管理負載平衡更有效率且更簡單。

  5. 如果部署處於無法使用狀態的區域中斷，您可以在相同訂用帳戶內的次要/被動區域中使用其他部署。

    • 因為主要和次要部署都是區域部署，所以會從區域中的所有可用區域繪製的相同區域容量集區。 次要部署可防範無法連線的主要 Azure OpenAI 端點。
    • 使用支援負載平衡和斷路器模式的產生 AI 閘道，例如 Azure OpenAI 服務端點前方 API 管理，因此在區域中斷期間中斷會最小化至取用應用程式。
    • 如果指定訂用帳戶內的配額已用盡，則可以以與上述相同方式部署新的訂用帳戶，以及其部署在 Generative AI Gateway 後方的端點。

已布建的部署

建立企業 PTU 集區

  1. 針對布建的部署，我們建議使用單一數據區 PTU 部署（2024/12/04/2024）作為 PTU 的企業集區。 您可以使用 API 管理 來管理來自多個應用程式的流量，以設定輸送量限制、記錄、優先順序和故障轉移邏輯。
    • 將此企業 PTU 集區視為「私人隨用隨付」資源，可防範服務需求高時，標準部署上可能發生的嘈雜鄰問題。 貴組織將保證、專用的容量集區存取權，而此集區僅供您使用，因此不受其他客戶的需求尖峰所造成。
    • 這可讓您先控制哪些應用程式體驗增加延遲，讓您將流量排定到任務關鍵應用程式的優先順序。
    • 布建的部署會受到延遲 SLA 的支援，讓部署更適合標準部署（隨用隨付）部署，以取得延遲敏感性工作負載。
    • 企業 PTU 部署也可啟用較高的使用率，因為流量會在應用程式工作負載之間順暢，而個別工作負載往往較容易出現尖峰。
  2. 您的主要企業 PTU 部署應該位於與主要標準區域部署不同的區域中。 如此一來，如果發生區域性中斷，您就不會同時失去 PTU 部署和標準區域部署的存取權。

工作負載專用 PTU 部署

  1. 某些工作負載可能需要有自己的專用布建部署。 如果是，您可以建立該應用程式的專用 PTU 部署。
  2. 工作負載和企業 PTU 集區部署應防範區域失敗。 您可以將工作負載 PTU 集區放在區域 A 中，並將企業 PTU 集區放在區域 B 中來執行此動作。
  3. 此部署應該先故障轉移至企業 PTU 集區，然後再故障轉移至標準部署。 這表示當工作負載 PTU 部署使用率超過 100%， 要求仍會由 PTU 端點提供服務，為該應用程式啟用更高的延遲 SLA。

災害復原架構圖。

此架構的另一個優點是，它可讓您使用已布建的部署來堆棧標準部署，讓您可以撥入您慣用的效能和復原層級。 這可讓您針對工作負載之間的基準需求使用 PTU，並利用隨用隨付來增加流量。

布建的縮放比例圖表。

支援基礎結構

支援 Azure OpenAI 架構的基礎結構必須在設計中考慮。 架構所涉及的基礎結構元件會根據應用程式是否透過因特網或專用網取用 Azure OpenAI 服務而有所不同。 本文所討論的架構假設組織已實 作 Generative AI Gateway。 具有成熟 Azure 使用量和混合式連線的組織應該透過專用網取用服務，而沒有混合式連線的組織，或與 GCP 或 AWS 等另一個雲端中的應用程式，將會透過Microsoft公用骨幹取用服務。

透過Microsoft公用骨幹設計取用

透過Microsoft公用骨幹取用服務的組織應考慮下列設計元素：

  1. 應以確保 Azure 區域中斷時可以使用的 Generative AI 閘道的方式進行部署。 如果使用APIM（Azure API 管理），則可以藉由在多個區域中部署個別的APIM實例或使用APIM的多區域閘道功能來完成。

  2. 公用全域伺服器負載平衡器應該使用主動/主動或主動/被動方式，在多個 Generative AI 網關實例之間進行負載平衡。 根據組織的需求，Azure FrontDoor 可用來履行此角色。

故障轉移架構圖。

透過專用網設計取用

透過專用網取用服務的組織應考慮下列設計元素：

  1. 混合式連線應以防止 Azure 區域失敗的方式進行部署。 支援混合式連線的內嵌元件包含組織的內部部署網路基礎結構，以及 Microsoft ExpressRoute 或 VPN。
  2. 應以確保 Azure 區域中斷時可以使用的 Generative AI 閘道的方式進行部署。 如果使用APIM（Azure API 管理），則可以藉由在多個區域中部署個別的APIM實例或使用APIM的多區域閘道功能來完成。
  3. 針對每個 Azure 區域中的每個 Azure OpenAI 服務實例，都應該部署 Azure Private Link 私人端點。 針對 Azure 私用 DNS，如果 Azure OpenAI 服務的所有應用程式存取都是透過 Generative AI 閘道完成，以提供額外的保護，以防止區域性失敗，則可以使用分割腦 DNS 方法。 如果沒有，私用 DNS 記錄必須在 Azure 區域遺失時手動修改。
  4. 私人全域伺服器負載平衡器應該使用主動/主動或主動/被動方式，在多個 Generative AI 網關實例之間進行負載平衡。 Azure 對於需要私人 DNS 解析的工作負載，全域伺服器負載平衡器沒有原生服務。 如需本主題的其他背景，您可以參考此非官方指南： https://github.com/adstuart/azure-crossregion-private-lb。除了全域伺服器負載平衡器之外，組織可以透過切換產生 AI 閘道的 DNS 記錄來達成主動/被動模式。