Azure App 服務的可靠性

本文說明 Azure App 服務的可靠性支援,並涵蓋具有可用性區域和跨區域災害復原和商務持續性的區域內部復原能力。 如需 Azure 中可靠性原則的詳細概觀,請參閱 Azure 可靠性

Azure App 服務 是以 HTTP 為基礎的服務,可用來裝載 Web 應用程式、REST API 和行動後端;並將 Microsoft Azure 的強大功能新增至您的應用程式,例如:

  • 安全性
  • 負載平衡
  • 自動調整規模
  • 自動化管理

若要探索 Azure App 服務 如何增強應用程式工作負載的可靠性與復原能力,請參閱為何要使用 App Service?

可靠性建議

本節包含達成復原和可用性的建議。 每個建議分為兩個類別之一:

  • 健康情況專案 涵蓋設定專案等區域,以及組成 Azure 工作負載的主要元件的適當功能,例如 Azure 資源組態設定、其他服務的相依性等等。

  • 風險專案 涵蓋可用性和復原需求、測試、監視、部署和其他專案,如果尚未解決,會增加環境中問題的機會。

可靠性建議優先順序矩陣

每個建議都會根據下列優先順序矩陣來標示:

映像 優先順序 描述
需要立即修正。
修正 3-6 個月內。
需要檢閱。

可靠性建議摘要

類別 優先順序 建議
高可用性 ASP-1 - 部署區域備援 App Service 方案
復原 ASP-2 -使用支援可用性區域的 App Service 方案
ASP-4 - 為生產與測試建立個別的 App Service 方案
延展性 ASP-3 - 避免經常相應增加或減少
ASP-5 - 啟用自動調整/自動調整,以確保有足夠的資源可供服務要求使用

高可用性

ASP-1 - 部署區域備援 App Service 方案

若要增強業務關鍵性工作負載的復原和可靠性,建議您部署具有區域備援的新 App Service 方案。 請依照步驟重新 部署至可用性區域支援、設定管線以在新 App Services 方案上重新部署 WebApp,然後使用 Blue-Green 部署 方法來故障轉移至新月臺。

藉由將應用程式分散到多個可用性區域,即使數據中心層級失敗,您也能確保其持續作業。 如需 Azure App 服務 中可用性區域支援的詳細資訊,請參閱可用性區域支援

// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A

resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, sku_tier, zoneRedundant

復原

ASP-2 -使用支援可用性區域的 App Service 方案

可用性區域支援僅適用於特定 App Service 方案。 若要查看使用可用性區域所需的方案,請參閱 可用性區域必要條件

// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the “Standard”, “Premium”, or “IsolatedV2” SKU tiers.

resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
        tolower(sku_tier) !contains "premium" and
        tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, sku_tier

ASP-4 - 為生產與測試建立個別的 App Service 方案

若要增強業務關鍵性工作負載的復原和可靠性,您應該將現有的 App Service 方案和 App Service 環境 移轉至可用性區域支援。 藉由將應用程式分散到多個可用性區域,即使數據中心層級失敗,您也能確保其持續作業。 如需 Azure App 服務 中可用性區域支援的詳細資訊,請參閱可用性區域支援

延展性

ASP-3 - 避免經常相應增加或減少

建議您避免經常相應增加或減少 Azure App 服務 實例。 相反地,請選擇可處理一般工作負載的適當層級和實例大小,並相應放大實例以容納流量的變更。 相應增加或減少可能會觸發應用程式重新啟動,這可能會導致服務中斷。

ASP-5 - 啟用自動調整/自動調整,以確保有足夠的資源可供服務要求使用

建議您為 Azure App 服務 啟用自動調整/自動調整,以確保有足夠的資源可以處理傳入要求。 自動調整是以規則為基礎的調整,而自動調整會根據 HTTP 流量執行自動相應縮小和相應放大。 如需詳細資訊,請參閱自動調整 Azure App 服務,或開始使用 Azure 中的自動調整。

// Azure Resource Graph Query
//// Provides a list of Azure App Service Plans that are in the “PremiumV2”, “PremiumV3”, “Premium0V3”, “PremiumMV3”, or “Standard” tier, and checks if they have Elastic Scale or Autoscale enabled.

  resources
  | where type =~ 'microsoft.web/serverfarms'
  | extend tier = sku.tier, elasticScaleEnabled = coalesce(properties.elasticScaleEnabled, false)
  | where tier in ('PremiumV2', 'PremiumV3', 'Premium0V3', 'PremiumMV3', 'Standard')
  | extend id = tostring(id)
  | project id, name,  tier, ['Elastic Scale'] = iff(elasticScaleEnabled, 'Enabled', 'Disabled')
  | join kind=leftouter (
    resources
    | where type =~ 'microsoft.insights/autoscalesettings'
    | extend autoscaleEnabled = coalesce(properties.enabled, false), metricResourceUri = tostring(properties.profiles[0].rules[0].metricTrigger.metricResourceUri)
    | project autoscaleEnabled, metricResourceUri
  ) on $left.id == $right.metricResourceUri
  | project recommendationid="asp-5",name, id, ['Tier'] = tier, ['Elastic Scale'] = ['Elastic Scale'], ['Autoscale'] = iff(isnull(autoscaleEnabled), 'Disabled', iff(autoscaleEnabled, 'Enabled', 'Disabled'))

可用性區域支援

Azure 可用性區域是每個 Azure 區域內至少三個實體分開的數據中心群組。 每個區域內的數據中心都配備了獨立的電源、冷卻和網路基礎結構。 在本機區域失敗的情況下,可用性區域的設計是為了讓一個區域受到影響,其餘兩個區域都支援區域服務、容量和高可用性。

失敗範圍從軟體和硬體故障到地震、洪水和火災等事件。 透過 Azure 服務的備援和邏輯隔離,可達成對失敗的容忍度。 如需 Azure 中可用性區域的詳細資訊,請參閱 區域和可用性區域

已啟用 Azure 可用性區域的服務是設計來提供正確的可靠性和彈性層級。 其可透過兩種方式進行設定。 它們可以是區域備援、跨區域自動復寫,或具有固定至特定區域的實例的區域複寫。 您也可以結合這些方法。 如需區域與區域備援架構的詳細資訊,請參閱使用可用性區域和區域的 建議。

Azure App 服務 可以部署到可用性區域 (AZ),以協助您為業務關鍵性工作負載實現復原和可靠性。 此架構稱也為區域備援。

當您將 App Service 設定為區域備援時,平臺會自動將 Azure App 服務 方案的實例分散到所選區域中的三個區域。

使用區域備援部署進行分散的實例會在下列規則內決定,即使應用程式相應縮小和相應放大:

  • App Service 方案實例計數下限為三個。
  • 如果您指定的容量大於三,而且執行個體數目可以使用三整除,則會平均分散執行個體。
  • 超過 3*N 的任何實例計數都會分散到其餘一或兩個區域。

可用性區域支援是 App Service 方案的屬性。 您可以使用 App Service 環境 v3,在受控多租用戶環境或專用環境中建立 App Service 方案。 若要深入瞭解 v3 App Service 環境,請參閱 App Service 環境 v3 概觀

對於未設定為區域備援的應用程式服務,VM 實例不會具有區域復原性,而且在該區域的任何區域中斷期間可能會發生停機時間。

如需企業部署架構的詳細資訊,請參閱使用 App Service 環境 的高可用性企業部署。

必要條件

開啟可用性區域的目前需求/限制如下:

  • 支援 Windows 和 Linux。

  • 只有較新的 App Service 使用量才支援可用性區域。 即使您使用其中一個支持的區域,如果資源群組不支援可用性區域,您仍會收到錯誤。 若要確保您的工作負載落在支援可用性區域的戳記上,您可能需要建立新的資源群組、App Service 方案和 App Service。

  • 您的 App Services 方案必須是下列其中一個支援可用性區域的方案:

    • 在多租用戶環境中,使用 App Service 進階版 v2 或 進階版 v3 方案。
    • 在專用環境中,使用 App Service 環境 v3,與隔離 v2 App Service 方案搭配使用。
  • 針對專用環境,您的 App Service 環境 必須是 v3。

    重要

    App Service 環境 v2 和 v1 將於 2024 年 8 月 31 日淘汰。 App Service 環境 v3 更容易使用,並在更強大的基礎結構上執行。 若要深入瞭解 v3 App Service 環境,請參閱 App Service 環境 概觀。 如果您目前使用 App Service 環境 v2 或 v1,而且想要升級至 v3,請遵循本文中的步驟移轉至新版本。

  • 強制執行三個區域的實例計數下限。 如果您指定實例計數少於三個,平臺會在幕後強制執行此最小計數。

  • 只有在建立 新的 App Service 方案時,才能指定可用性區域。 預先存在的 App Service 方案無法轉換成使用可用性區域。

  • 下列區域支援在多租用戶環境中執行的 Azure App 服務:

    • 澳大利亞東部
    • 巴西南部
    • 加拿大中部
    • 印度中部
    • 美國中部
    • 東亞
    • 美國東部
    • 美國東部 2
    • 法國中部
    • 德國中西部
    • 日本東部
    • 南韓中部
    • 北歐
    • 挪威東部
    • 波蘭中部
    • 卡達中部
    • 南非北部
    • 美國中南部
    • 東南亞
    • 瑞典中部
    • 瑞士北部
    • 阿拉伯聯合大公國北部
    • 英國南部
    • 西歐
    • 美國西部 2
    • 美國西部 3
    • 由 21Vianet 營運的 Microsoft Azure - 中國北方 3
    • Azure Government - US Gov 維吉尼亞州
  • 若要查看哪些區域支援 App Service 環境 v3 的可用性區域,請參閱區域

建立已啟用可用性區域的資源

部署多租用戶區域備援App Service

若要使用 Azure CLI 啟用可用性區域,請在建立 App Service 方案時包含 --zone-redundant 參數。 您也可以包含 --number-of-workers 參數來指定容量。 如果您未指定容量,平台預設為三個。 容量應根據工作負載需求來設定,但不得少於三個。 選擇容量的良好規則是確保應用程式有足夠的實例,讓一個實例失去一個區域,讓足夠的容量來處理預期的負載。

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

提示

若要決定實例容量,您可以使用下列計算:

由於平臺會將 VM 分散到三個區域,因此您必須至少考慮一個區域的失敗,請將尖峰工作負載實例計數乘以區域/(zone-1) 或 3/2 的因數。 例如,如果您的一般尖峰工作負載需要四個實例,您應該布建六個實例:(2/3 * 6 個實例) = 4 個實例。

使用專用環境部署區域備援App Service

若要瞭解如何在隔離 v2 方案上建立 App Service 環境 v3,請參閱建立 App Service 環境

疑難排解

錯誤訊息 描述 建議
資源群組 'RG-NAME' 無法使用區域備援。 請將 App Service 方案 'ASP-NAME' 部署到新的資源群組。 只有較新的 App Service 使用量才支援可用性區域。 即使您使用其中一個支持的區域,如果資源群組不支援可用性區域,您仍會收到錯誤。 若要確保您的工作負載落在支援可用性區域的戳記上,請建立新的資源群組、App Service 方案和 App Service。

容錯

若要準備可用性區域失敗,您應該過度布建服務的容量,以確保解決方案可以容許 1/3 的容量遺失,並在全區域中斷期間繼續運作,而不會降低效能。 由於平臺會將 VM 分散到三個區域,因此您必須至少考慮一個區域的失敗,請將尖峰工作負載實例計數乘以區域/(zone-1) 或 3/2 的因數。 例如,如果您的一般尖峰工作負載需要四個實例,您應該布建六個實例:(2/3 * 6 個實例) = 4 個實例。

區域關閉體驗

流量會路由傳送至您所有可用的 App Service 實例。 在區域關閉的情況下,App Service 平臺會偵測遺失的實例,並自動嘗試尋找新的取代實例,並視需要分散流量。 如果您已設定 自動調整 ,而且它決定需要更多實例,自動調整也會向App Service發出要求以新增更多實例。 請注意, 自動調整行為與 App Service 平臺行為 無關,而且您的自動調整實例計數規格不需要是三個的倍數。

注意

不保證區域關閉案例中其他實例的要求將會成功。 遺失實例的回填會以最佳方式進行。 建議的解決方案是建立和設定 App Service 方案,以考慮遺失區域,如下一節所述。

在已啟用可用性區域的 App Service 方案中部署的應用程式,即使相同區域中的其他區域發生中斷,仍會繼續執行並提供服務流量。 不過,非運行時間行為,包括 App Service 方案調整、應用程式建立、應用程式設定和應用程式發佈,仍可能會受到其他 可用性區域 中斷的影響。 App Service 方案的區域備援只會確保已部署應用程式的持續運行時間。

當 App Service 平臺將實例配置給區域備援 App Service 方案時,它會使用基礎 Azure 虛擬機器擴展集 所提供的最佳工作區域平衡。 如果每個區域都有相同的 VM 數目,或 App Service 方案所使用的所有其他區域中的一個 VM,App Service 方案將會「平衡」。

可用性區域移轉

您無法將現有的 App Service 實例或環境資源從非可用性區域支援移轉至可用性區域支援。 若要取得可用性區域的支援,您必須 建立已啟用可用性區域的資源。

定價

啟用可用性區域不需要額外的成本。 區域備援 App Service 的價格與單一區域 App Service 相同。 您將根據 App Service 方案 SKU、您指定的容量,以及您根據自動調整準則調整至的任何實例來收費。 如果您啟用可用性區域,但指定容量少於三個,則平臺會強制執行三個實例的最小實例計數,並向您收取這三個實例的費用。 如需 App Service 環境 v3 的定價資訊,請參閱定價

跨區域災害復原和商務持續性

災害復原 (DR) 是關於從高影響事件中復原,例如自然災害或導致停機時間和數據遺失的失敗部署。 無論原因為何,解決災害的最佳辦法是定義完善且經過測試的 DR 方案,以及主動支援 DR 的應用程式設計。 開始考慮建立災害復原計劃之前,請參閱設計災害復原策略 建議。

在DR方面,Microsoft 會使用 共同責任模型。 在共同責任模型中,Microsoft 可確保基準基礎結構和平臺服務可供使用。 同時,許多 Azure 服務不會自動復寫數據,也不會從失敗的區域回復至另一個已啟用的區域。 針對這些服務,您必須負責設定適用於您工作負載的災害復原計劃。 大部分在 Azure 平臺即服務上執行的服務 (PaaS) 供應專案都提供支援DR的功能和指引,而且您可以使用 服務特定功能來支援快速復原 ,以協助開發DR方案。

本節涵蓋部署至 App Service 的 Web 應用程式一些常見策略。

當您在 App Service 中建立 Web 應用程式並在資源建立期間選擇 Azure 區域時,它是單一區域應用程式。 當區域在災害期間變成無法使用時,您的應用程式也會變成無法使用。 如果您使用多區域地理架構在次要 Azure 區域中建立相同的部署,則應用程式較不容易遭受單一區域災害,進而保證商務持續性。 跨區域的任何數據復寫都可讓您復原最後一個應用程式狀態。

針對 IT,商務持續性計劃主要由復原時間目標 (RTO) 和恢復點目標 (RPO) 驅動。 如需 RTO 和 RPO 的詳細資訊,請參閱 復原目標

通常,針對區域災害,維護 RTO 周圍的 SLA 是不切實際的,而且您通常會單獨在 RPO 周圍設計災害復原策略(也就是專注於復原數據,而不是將中斷降至最低)。 不過,透過 Azure,它不僅實用,甚至可以直接部署 App Service 以進行自動異地故障轉移。 這可讓您藉由處理 RTO 和 RPO,進一步證明您的應用程式。

根據您的所需 RTO 和 RPO 計量,三種災害復原架構通常用於 App Service 多租使用者和 App Service 環境。 下表說明每個架構:

計量 主動-主動 主動-被動 被動/冷
復原時間目標 (RTO) 即時或秒 分鐘 小時
復原點目標 (RPO) 即時或秒 分鐘 小時
成本 $$$ $$ $
案例 任務關鍵性應用程式 高優先順序應用程式 低優先順序應用程式
提供多區域使用者流量的能力 Yes 是/也許 No
程式碼部署 慣用 CI/CD 管線 慣用 CI/CD 管線 備份和還原
在停機期間建立新的App Service資源 非必要 非必要 必要

注意

您的應用程式最有可能相依於 Azure 中的其他資料服務,例如 Azure SQL 資料庫 和 Azure 儲存體 帳戶。 建議您也針對每個相依的 Azure 服務開發災害復原策略。 如需 SQL 資料庫,請參閱 Azure SQL 資料庫 的作用中異地複寫。 如需 Azure 儲存體,請參閱 Azure 儲存體 備援

多區域地理位置的災害復原

有多種方式可在主動-主動或主動-被動架構中跨 Azure 區域復寫 Web 應用程式內容和組態,例如使用 App Service 備份和還原。 不過,備份和還原會建立時間點快照集,最終會導致跨區域發生 Web 應用程式版本設定挑戰。 請參閱下表,以取得返回和還原指引與 diaster 復原指引之間的比較:

備份與還原與災害復原

平台 備份和還原指引 災害復原指南
App Service Web Apps
(免費和共用定價層)
如果您已將 Web 應用程式部署至免費或共用層,且需要存取這些 Web 應用程式的備份和還原功能, 請相應增加 至基本層或更高層級。 在區域性災害期間,將 App Service 資源帶回不同的 Azure 區域。

從 2025 年 3 月 31 日起,App Service 應用程式將不會在 Azure 區域中的災害期間處於災害復原模式,如從全區域失敗復原一文中所述。 建議您實 作常用的災害復原技術 ,以防止區域性災害期間停機和數據遺失。
App Service Web Apps
(基本\標準\進階版 定價層)
在 Azure App 服務 中,您可以進行隨選自定義備份或使用自動備份。 您可以藉由還原至新的應用程式或位置來覆寫現有的應用程式來還原備份。

如需詳細資訊,請參閱在 Azure App 服務 中備份和還原您的應用程式。
關於如何在區域災害期間將App Service資源帶回不同 Azure 區域中的目前指引,請參閱從全區域失敗復原 - Azure App 服務

從 2025 年 3 月 31 日起,Azure App 服務 Web 應用程式將不再處於 Azure 區域中的災害復原模式,如從全區域失敗復原一文中所述。 我們鼓勵您實 作常用的災害復原技術 ,以避免在發生區域性災害時遺失 Web 應用程式的功能或數據。
App Service 環境 (V2 和 V3) 在 Azure App 服務 環境中,您可以進行隨選自定義備份或使用自動備份。 自動備份可以還原至相同 ASE 內的目標應用程式,而不是在另一個 ASE 中。 自定義備份可以還原至另一個 ASE 中的目標應用程式(例如從 V2 ASE 還原至 V3 ASE)。 備份可以還原至與來源應用程式相同的OS平台目標應用程式。

如需詳細資訊,請參閱在 Azure App 服務 中備份和還原您的應用程式。
我們鼓勵您使用常用的災害復原技術,為部署至 App Service 環境 的 Web 應用程式實作災害復原指引。
Azure Functions (專用) 在 Azure Functions 中,您可以進行隨選自定義備份或使用自動備份。 您可以藉由還原至新的應用程式或位置來覆寫現有的應用程式來還原備份。

如需詳細資訊,請參閱在 Azure App 服務 中備份和還原您的應用程式。
關於如何在區域災害期間將 Azure Functions 應用程式(專用)資源重新上線的目前指引,請參閱從全區域失敗復原 - Azure App 服務

從 2025 年 3 月 31 日起,App Service 應用程式將不會在 Azure 區域中的災害期間處於災害復原模式,如從全區域失敗復原一文中所述。 請改為實作 Azure Functions 異地災害復原

此外,您也可以參考 Azure Functions 專用的常用災害復原技術
Azure Functions 取用和 進階版 部署至取用和進階方案的 Azure 函式不會提供自定義和自動備份的存取權。 函式應用程式的內容位於 Azure 記憶體帳戶中。 使用 Azure 儲存體 備援選項,以確保記憶體帳戶在中斷期間符合其可用性和持久性目標。

如果您使用 Azure 入口網站 中的編輯器建立函式,您也可以將現有的函式應用程式項目下載為.zip檔案
強烈建議您實 作 Azure Functions 異地災害復原和可靠性

若要避免備份和還原方法的限制,請將 CI/CD 管線設定為將程式代碼部署至兩個 Azure 區域。 請考慮使用 Azure PipelinesGitHub Actions。 如需詳細資訊,請參閱持續部署至 Azure App 服務

中斷偵測、通知和管理

  • 建議您為 Web 應用程式設定監視和警示,以在災害期間及時通知。 如需詳細資訊,請參閱 Application Insights 可用性測試

  • 若要在 Azure 中管理您的應用程式資源,請使用基礎結構即程式代碼 (IaC) 機制。 在跨多個區域的複雜部署中,若要獨立管理區域,並以可靠的方式讓設定保持跨區域同步,需要可預測、可測試且可重複的程式。 請考慮 IaC 工具,例如 Azure Resource Manager 範本Terraform

設定災害復原和中斷偵測

若要準備在多區域地理位置進行災害復原,您可以使用主動-主動或主動-被動架構。

主動-主動架構

在主動-主動式災害復原架構中,相同的 Web 應用程式會部署在兩個不同的區域中,而 Azure Front door 則用來將流量路由傳送至兩個作用中區域。

Diagram that shows an active-active deployment of App Service.

使用此範例架構:

  • 相同的 App Service 應用程式會部署在兩個不同的區域中,包括定價層和實例計數。
  • 直接對 App Service 應用程式的公用流量遭到封鎖。
  • Azure Front Door 可用來將流量路由傳送至這兩個作用中區域。
  • 在災害期間,其中一個區域會脫機,而 Azure Front Door 會將流量獨佔路由傳送到仍維持在在線的區域。 在這類異地故障轉移期間,RTO 接近零。
  • 應用程式檔應部署至兩個具有 CI/CD 解決方案的 Web 應用程式。 這可確保 RPO 幾乎為零。
  • 如果您的應用程式主動修改文件系統,將 RPO 最小化的最佳方式是只寫入掛接的 Azure 儲存體 共用,而不是直接寫入 Web 應用程式的 /home 內容共用。 然後,針對掛接的共用使用 Azure 儲存體 備援功能 (GZRS 或 GRS),其 RPO 大約 15 分鐘。

在 App Service 中為 Web 應用程式建立主動-主動架構的步驟摘要如下:

  1. 在兩個不同的 Azure 區域中建立兩個 App Service 方案。 以相同方式設定兩個 App Service 方案。

  2. 建立 Web 應用程式的兩個實例,每個 App Service 方案中各有一個。

  3. 使用下列專案建立 Azure Front Door 配置檔:

    • 端點。
    • 兩個原始群組,每個群組的優先順序為1。 相等優先順序會告知 Azure Front Door 將流量路由傳送至這兩個區域相同(因此作用中-主動)。
    • 路由。
  4. 僅從 Azure Front Door 實體限制 Web 應用程式的網路流量。

  5. 設定及設定所有其他後端 Azure 服務,例如資料庫、記憶體帳戶和驗證提供者。

  6. 使用持續部署將程式代碼部署至這兩個 Web 應用程式。

教學課程:在 Azure App 服務 中建立高可用性的多區域應用程式會示範如何設定主動-被動架構。 針對 Azure Front Door 中這兩個原始群組設定優先順序為 「1」 的相同步驟,可提供主動 -主動 架構。

主動-被動架構

在此災害復原方法中,相同的 Web 應用程式會部署在兩個不同的區域中,而 Azure Front door 則用來僅將流量路由傳送到一個區域(作用區域)。

A diagram showing an active-passive architecture of Azure App Service.

使用此範例架構:

  • 相同的 App Service 應用程式會部署在兩個不同的區域中。

  • 直接對 App Service 應用程式的公用流量遭到封鎖。

  • Azure Front Door 可用來將流量路由傳送至主要區域。

  • 為了節省成本,次要 App Service 方案會設定為較少的實例和/或位於較低的定價層。 有三種可能的方法:

    • 用 次要 App Service 方案與主要方案具有相同的定價層,且實例數目相同或更少。 此方法可確保這兩個 App Service 方案的功能和 VM 大小均等。 異地故障轉移期間的 RTO 僅取決於相應放大實例的時間。

    • 較不慣用 次要 App Service 方案具有相同的定價層類型(例如 進階版 V3),但 VM 大小較小,且實例較少。 例如,次要區域位於 P1V3 層時,主要區域可能位於 P3V3 層。 此方法仍然可確保兩個 App Service 方案的功能同位,但當次要區域變成使用中區域時,缺少大小同位可能需要手動相應增加。 異地故障轉移期間的 RTO 取決於相應增加和相應放大實例的時間。

    • 最不慣用 的次要 App Service 方案具有不同於主要和較少實例的定價層。 例如,次要區域位於 S1 層時,主要區域可能位於 P3V3 層。 請確定次要 App Service 方案具有應用程式執行所需的所有功能。 這兩者之間功能可用性的差異可能會導致 Web 應用程式復原延遲。 異地故障轉移期間的 RTO 取決於相應增加和相應放大實例的時間。

  • 當使用中區域變成非使用中時,會在次要區域上設定自動調整。 建議在主動和被動區域中有類似的自動調整規則。

  • 在災害期間,主要區域會變成非使用中,而次要區域會開始接收流量,並變成作用中區域。

  • 當次要區域變成使用中時,網路負載會觸發預先設定的自動調整規則,以相應放大次要 Web 應用程式。

  • 如果您還沒有作為使用中區域執行所需的功能,您可能需要手動相應增加次要區域的定價層。 例如, 自動調整需要標準層或更高層級。

  • 當主要區域再次處於作用中狀態時,Azure Front Door 會自動將流量導向回該區域,而架構會像以前一樣回到主動-被動。

  • 應用程式檔應部署至兩個具有 CI/CD 解決方案的 Web 應用程式。 這可確保 RPO 幾乎為零。

  • 如果您的應用程式主動修改文件系統,將 RPO 最小化的最佳方式是只寫入掛接的 Azure 儲存體 共用,而不是直接寫入 Web 應用程式的 /home 內容共用。 然後,針對掛接的共用使用 Azure 儲存體 備援功能 (GZRS 或 GRS),其 RPO 大約 15 分鐘。

在 App Service 中為 Web 應用程式建立主動-被動架構的步驟摘要如下:

  1. 在兩個不同的 Azure 區域中建立兩個 App Service 方案。 次要 App Service 方案可以使用先前所述的其中一種方法來布建。
  2. 設定次要 App Service 方案的自動調整規則,以便在主要區域變成非使用中時,調整為與主要實例相同的實例計數。
  3. 建立 Web 應用程式的兩個實例,每個 App Service 方案中各有一個。
  4. 使用下列專案建立 Azure Front Door 配置檔:
    • 端點。
    • 主要區域的優先順序為1的原始群組。
    • 次要區域優先順序為2的第二個原始群組。 優先順序的差異會告訴 Azure Front Door 在在線時偏好主要區域(因此主動-被動)。
    • 路由。
  5. 僅從 Azure Front Door 實體限制 Web 應用程式的網路流量。
  6. 設定及設定所有其他後端 Azure 服務,例如資料庫、記憶體帳戶和驗證提供者。
  7. 使用持續部署將程式代碼部署至這兩個 Web 應用程式。

教學課程:在 Azure App 服務 中建立高可用性的多區域應用程式會示範如何設定主動-被動架構。

被動冷架構

使用被動/冷架構,在位於另一個區域的 Azure 儲存體 帳戶中建立和維護 Web 應用程式的一般備份。

使用此範例架構:

  • 單一 Web 應用程式會部署到單一區域。

  • Web 應用程式會定期備份至相同區域中的 Azure 儲存體 帳戶。

  • 備份的跨區域復寫取決於 Azure 記憶體帳戶中的數據備援組態。 您應該盡可能將 Azure 儲存體 帳戶設定為 GZRS。 GZRS 提供區域內的同步區域備援,以及在次要區域中提供異步。 如果無法使用 GZRS,請將帳戶設定為 GRS。 GZRS 和 GRS 都有 大約 15 分鐘的 RPO。

  • 為了確保您可以在記憶體帳戶的主要區域無法使用時擷取備份, 請分別啟用次要區域的 唯讀存取權(使記憶體帳戶 RA-GZRSRA-GRS)。 如需設計應用程式以利用異地備援的詳細資訊,請參閱 使用異地備援來設計高可用性應用程式

  • 在 Web 應用程式區域中的災害期間,您必須使用來自 Azure 儲存體 帳戶的備份,手動部署所有必要的 App Service 相依資源,最有可能來自具有讀取許可權的次要區域。 RTO 可能是小時或天數。

  • 若要將 RTO 降到最低,強烈建議您有完整的劇本,概述將 Web 應用程式備份還原至另一個 Azure 區域所需的所有步驟。

在 App Service 中為 Web 應用程式建立被動冷區域的步驟摘要如下:

  1. 在與 Web 應用程式相同的區域中建立 Azure 記憶體帳戶。 選擇 [標準效能層級],然後選取 [備援] 作為異地備援記憶體 (GRS) 或異地區域備援記憶體 (GZRS)。

  2. 啟用RA-GRS或RA-GZRS(次要區域的讀取存取權)。

  3. 設定 Web 應用程式的自訂備份 。 您可以決定設定 Web 應用程式備份的排程,例如每小時。

  4. 確認 Web 應用程式備份檔可以擷取記憶體帳戶的次要區域。

提示

除了 Azure Front Door 之外,Azure 還提供其他負載平衡選項,例如 Azure 流量管理員。 如需各種選項的比較,請參閱 負載平衡選項 - Azure 架構中心

單一區域地理位置中的災害復原

如果您的 Web 應用程式區域沒有 GZRS 或 GRS 記憶體,或您位於 非區域配對的 Azure 區域中,則必須使用區域備援記憶體 (ZRS) 或本地備援記憶體 (LRS) 來建立類似的架構。 例如,您可以手動建立記憶體帳戶的次要區域,如下所示:

Diagram that shows how to create a passive or cold region without GRS or GZRS.

建立不含 GRS 和 GZRS 的被動冷區域的步驟摘要如下:

  1. 在 Web 應用程式的相同區域中建立 Azure 記憶體帳戶。 選擇 [標準效能層級],然後選取 [備援] 作為區域備援記憶體 (ZRS)。

  2. 設定 Web 應用程式的自訂備份 。 您可以決定設定 Web 應用程式備份的排程,例如每小時。

  3. 確認 Web 應用程式備份檔可以擷取記憶體帳戶的次要區域。

  4. 在不同的區域中建立第二個 Azure 記憶體帳戶。 選擇 [標準效能層],然後選取備援作為本地備援記憶體 (LRS)。

  5. 使用 AzCopy 之類的工具,將自訂備份(Zip、XML 和記錄檔)從主要區域複寫到次要記憶體。 例如:

    azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'
    

    您可以使用 Azure 自動化 搭配 PowerShell 工作流程 Runbook,依排程執行複寫腳本。 請確定複寫排程遵循與 Web 應用程式備份類似的排程。

下一步