Azure App Service 的可靠性
本文說明 Azure App Service 的可靠性支援,並涵蓋可用性區域的區域內復原能力,以及跨區域災害復原和商務持續性。 如需更多關於 Azure 可靠性準則的詳細概觀,請參閱 Azure 可靠性。
Azure App Service 是 HTTP 型服務,用來裝載 Web 應用程式、REST API 和行動後端;並為您的應用程式新增 Microsoft Azure 的功能,例如:
- 安全性
- 負載平衡
- 自動調整規模
- 自動化管理
若要探索 Azure App Service 如何支援應用程式工作負載的可靠性和復原功能,請參閱為何要使用 App Service?
可用性區域支援
Azure 可用性區域是每個 Azure 區域內至少三個實體獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻系統和網路基礎結構。 在本機區域失敗的案例中,可用性區域的設計在於,當一個區域受影響時,讓其餘兩個區域支援區域服務、容量和高可用性。
這類失敗的範圍可從軟體和硬體故障,擴及到如地震、淹水和火災的事件。 透過 Azure 服務的備援和邏輯隔離,實現對失敗的容錯。 如需深入了解 Azure 的可用性區域,請參閱區域和可用性區域。
已啟用 Azure 可用性區域的服務旨在提供正確程度的可靠性和彈性。 您可以透過兩種方式加以設定。 它們可以是區域備援,具有跨區域自動複寫功能,或者是區域性的,將執行個體釘選在特定區域。 兩種方法可以結合使用。 如需區域與區域備援架構的詳細資訊,請參閱使用可用性區域和區域的建議。
Azure App Service 可以跨可用性區域 (AZ) 進行部署,以協助您達到業務關鍵工作負載的復原和可靠性。 此架構稱也為區域備援。
將 App Service 設定為區域備援時,平台會自動將 Azure App Service 方案的執行個體散佈至所選區域中的三個區域。
使用區域備援部署進行散佈的執行個體,即使應用程式增加或減少數量,也會根據以下規則來確定:
- App Service 方案執行個體計數下限為三個。
- 如果您指定的容量大於三,而且執行個體數目可以使用三整除,則會平均分散執行個體。
- 任何超過 3*N 的執行個體計數則會散佈至其餘的一或兩個區域中。
可用性區域支援是 App Service 方案的屬性。 您可以使用 App Service 環境 v3,在受控多租用戶環境或專用環境上建立 App Service 方案。 若要深入了解 App Service 環境 v3,請參閱 App Service 環境 v3 概觀。
對於未設定為區域備援的應用程式服務,VM 執行個體不具備區域復原性,在該區域的任何一個區域出現中斷情形時,可能會出現停機的情況。
如需企業部署架構的相關資訊,請參閱使用 App Service 環境進行高度敏感性企業部署。
必要條件
啟用可用性區域的目前需求/限制如下:
支援 Windows 和 Linux。
只有較新的 App Service 使用量才支援可用性區域。 即使您使用其中一個支援的區域,如果資源群組不支援可用性區域,仍會收到錯誤。 若要確保工作負載落在支援可用性區域的戳記上,可能需要建立新的資源群組、App Service 方案和 App Service。
App Service 方案必須是下列其中一個支援可用性區域的方案:
- 在多租用戶環境中,使用 App Service 進階 v2 或進階 v3 方案。
- 在使用 App Service 環境 v3 的專用環境中,會與隔離式 v2 App Service 方案搭配使用。
對專用環境而言,您的 App Service 環境必須是 v3。
重要
App Service 環境 v2 和 v1 將於 2024 年 8 月 31 日淘汰。 App Service Environment v3 更易於使用,並且是在更強大的基礎結構上執行。 若要深入了解 App Service 環境 v3,請參閱 App Service 環境概觀。 如果您目前使用 App Service 環境 v2 或 v1,且想要升級至 v3,請遵循本文中的步驟來移轉至新版本。
強制要求執行個體的計數下限為三個區域。 如果您指定少於三個執行個體計數,則平台會在幕後強制執行此最小計數。
只有在建立新的 App Service 方案時,才能指定可用性區域。 預先存在的 App Service 方案無法改為使用可用性區域。
下列區域支援在多租用戶環境中執行的 Azure App Service:
- 澳大利亞東部
- 巴西南部
- 加拿大中部
- 印度中部
- 美國中部
- 東亞
- 美國東部
- 美國東部 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 的應用程式設計。 開始思考建立災害復原方案之前,請參閱設計災害復原策略的建議。
Microsoft 在災害復原方面採取共同責任模型。 在共同責任模型中,Microsoft 確保基準基礎結構和平台服務可供使用。 此時,許多 Azure 服務不會自動複寫資料,或從失敗區域回復為交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合工作負載的災害復原方案。 在 Azure 平台即服務 (PaaS) 供應項目上執行的多數服務,都有提供支援災害復原的功能和指導,您可以使用特定服務功能復原,制定災害復原方案。
本節說明將 Web 應用程式部署至 App Service 的一些常見策略。
在 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 Database 和 Azure 儲存體帳戶。 建議您也為每個相依的 Azure 服務制定災害復原策略。 若為 SQL Database,請參閱 Azure SQL Database 的主動式異地複寫。 若為 Azure 儲存體,請參閱 Azure 儲存體備援。
多區域地理位置的災害復原
有多種方式可以「主動-主動」或「主動-被動」架構跨 Azure 區域複寫 Web 應用程式內容和組態,例如使用 App Service 備份與還原。 不過,備份與還原會建立時間點快照集,最終會導致跨區域發生 Web 應用程式版本控制的難題。 請參閱下表,以取得備份與還原指導和災害復原指導之間的比較:
備份與還原 vs. 災害復原
平台 | 備份與還原指導 | 災害復原指南 |
---|---|---|
App Service Web Apps (免費和共用定價層) |
如果您已將 Web 應用程式部署至免費或共用層,且需要存取這些 Web 應用程式的備份和還原功能,請調整為基本層或更高層級。 | 在區域性災害期間,將 App Service 資源帶回不同的 Azure 區域中。 如從全區域失敗復原一文中所述,從 2025 年 3 月 31 日起,在 Azure 區域中的災害期間,App Service 應用程式將不會處於災害復原模式。 建議您實作常用的災害復原技術,以防止在區域性災害期間發生停機和資料遺失。 |
App Service Web Apps (基本\標準\進階定價層) |
在 Azure App Service 中,可進行隨選自訂備份或使用自動備份。 您可以藉由還原至新應用程式或位置,覆寫現有的應用程式以還原備份。 請參閱在 Azure App Service 中備份並還原應用程式,以取得更多資訊。 |
如需如何在區域性災害期間,將 App Service 資源在不同 Azure 區域中重新連線的最新指導,請參閱從全區域失敗中復原 - Azure App Service。 如從全區域失敗復原一文中所述,從 2025 年 3 月 31 日起,在 Azure 區域中的災害期間,App Service web 應用程式將不再處於災害復原模式。 我們鼓勵您實作常用的災害復原技術,以避免發生區域性災害時,Web 應用程式的功能或資料遺失。 |
App Service 環境 (V2 & V3) | 在 Azure App Service 環境中,可進行隨選自訂備份或使用自動備份。 自動備份可還原至相同的 ASE 內、而非在另一個 ASE 中的目標應用程式。 自訂備份可還原至另一個 ASE 中的目標應用程式 (例如從 V2 ASE 還原至 V3 ASE)。 備份可以還原至與來源應用程式相同的 OS 平台目標應用程式。 請參閱在 Azure App Service 中備份並還原應用程式,以取得更多詳細資訊。 |
我們鼓勵您使用常用的災害復原技術,為部署到 App Service 環境的 Web 應用程式實作災害復原指導。 |
Azure Functions (專用) | 在 Azure Functions 中,可進行隨選自訂備份或使用自動備份。 您可以藉由還原至新應用程式或位置,覆寫現有的應用程式以還原備份。 請參閱在 Azure App Service 中備份並還原應用程式,以取得更多資訊。 |
如需如何在區域性災害期間,將 Azure Functions 應用程式 (專用) 資源在不同的 Azure 區域中重新連線的最新指導,請參閱從全區域失敗中復原 - Azure App Service。 如從全區域失敗復原一文中所述,從 2025 年 3 月 31 日起,在 Azure 區域中的災害期間,App Service 應用程式將不會處於災害復原模式。 請改為實作 Azure Functions 異地災害復原。 此外,您也可以參考 Azure Functions 專用常用的災害復原技術。 |
Azure Functions 取用和進階方案 | 部署至取用和進階方案的 Azure 函數不會提供自訂和自動備份的存取權。 函數應用程式內容位於 Azure 儲存體帳戶中。 使用 Azure 儲存體備援選項,以確保儲存體帳戶在中斷期間符合其可用性和持久性目標。 如果您已在 Azure 入口網站中使用編輯器建立函數,也可將現有的函數應用程式專案下載為 .ZIP 檔案。 |
強烈建議您實作 Azure Functions 異地災害復原和可靠性。 |
若要避免備份與還原方法的限制,請將 CI/CD 管線設定為將程式碼部署至兩個 Azure 區域。 請考慮使用 Azure Pipelines 或 GitHub Actions。 如需詳細資訊,請參閱持續部署至 Azure App Service。
中斷偵測、通知及管理
建議您為 Web 應用程式設定監視和警示,以在災害期間及時收到通知。 如需詳細資訊,請參閱 Application Insights 可用性測試。
若要在 Azure 中管理應用程式資源,請使用基礎結構即程式碼 (IaC) 機制。 在跨多個區域的複雜部署中,若要獨立管理區域,並以可靠的方式讓設定保持跨區域同步,需要可預測、可測試且可重複的流程。 請考慮 IaC 工具,例如 Azure Resource Manager 範本或 Terraform。
設定災害復原和中斷偵測
若要準備在多區域地理位置進行災害復原,可使用「主動-主動」或「主動-被動」架構。
主動-主動架構
在「主動-主動」災害復原架構中,相同的 Web 應用程式會部署在兩個不同的區域中,而 Azure Front Door 則用來將流量路由傳送至兩個使用中的區域。
使用此範例架構:
- 相同的 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 應用程式建立「主動-主動」架構的步驟摘要如下:
在兩個不同的 Azure 區域中建立兩個 App Service 方案。 以相同方式設定兩個 App Service 方案。
建立 Web 應用程式的兩個執行個體,每個 App Service 方案中各有一個。
使用下列項目建立 Azure Front Door 設定檔:
- 端點。
- 兩個原點群組,每個群組的優先順序為 1。 優先順序相等時,則會告知 Azure Front Door 將流量平均路由傳送至這兩個區域 (因此兩者均為「主動-主動」)。
- 路由。
設定及配置所有其他後端 Azure 服務,例如資料庫、儲存體帳戶和驗證提供者。
使用持續部署,將程式碼部署至兩個 Web 應用程式。
教學課程:在 Azure App Service 中建立高可用性的多區域應用程式會示範如何設定主動-被動架構。 以最小的變更採取相同的步驟 (在 Azure Front Door 中將原點群組中兩個原點的優先順序設為「1」) 即可建立主動-主動結構。
主動-被動架構
在這個災害復原方法中,相同的 Web 應用程式會部署在兩個不同的區域中,而 Azure Front Door 則用來將流量路由傳送至其中一個區域 (使用中區域)。
使用此範例架構:
相同的 App Service 應用程式會部署在兩個不同區域。
直接流入 App Service 應用程式的公用流量遭到封鎖。
Azure Front Door 是用來將流量路由傳送至主要區域。
為了節省成本,次要 App Service 方案會設定為使用較少的執行個體和/或較低的定價層。 有三種可能的方法:
慣用:次要 App Service 方案使用與主要方案相同的定價層,且執行個體數目相同或更少。 此方法可確保這兩個 App Service 方案的功能和 VM 大小均等。 異地容錯移轉期間的 RTO 僅取決於擴增執行個體的時間。
次慣用:次要 App Service 方案使用相同的定價層型別 (例如 PremiumV3),但 VM 大小較小且執行個體數也較少。 例如,主要區域可能位於 P3V3 層,而次要區域位於 P1V3 層。 此方法仍可確保兩個 App Service 方案的功能相等,但若次要區域變成使用中區域時,大小不相等的區域可能需要手動擴大。 異地容錯移轉期間的 RTO 取決於擴大和擴增執行個體的時間。
最少慣用:次要 App Service 方案的定價層不同於主要方案且執行個體數較少。 例如,主要區域可能位於 P3V3 層,而次要區域位於 S1 層。 請確定次要 App Service 方案提供應用程式執行所需的所有功能。 這兩者之間的功能可用性差異可能會造成 Web 應用程式復原延遲。 異地容錯移轉期間的 RTO 取決於擴大和擴增執行個體的時間。
如果使用中區域變成非使用中,會在次要區域上設定自動調整。 建議在主動和被動區域中建立類似的自動調整規則。
在災害發生期間,主要區域會變成非使用中,而次要區域會開始接收流量並變成使用中區域。
如果次要區域變成使用中,網路負載會觸發預先設定的自動調整規則,以擴增次要 Web 應用程式。
如果次要區域還沒有使用中區域執行所需的功能,則您可能需要手動擴大次要區域的定價層。 例如,自動調整需要標準層或更高層級。
如果主要區域再次處於使用中狀態,Azure Front Door 會自動將流量重新導回該區域,而架構會像以前一樣回到「主動-被動」模式。
應用程式檔案應部署至兩個採用 CI/CD 解決方案的 Web 應用程式。 這可確保 RPO 幾乎為零。
如果您的應用程式主動修改檔案系統,則最小化 RPO 的最佳方式是只寫入掛接的 Azure 儲存體共用,而不是直接寫入 Web 應用程式的 /home 內容共用。 然後,為掛接共用使用 Azure 儲存體備援功能 (GZRS 或 GRS),其中的 RPO 約 15 分鐘。
在 App Service 中為 Web 應用程式建立「主動-被動」架構的步驟摘要如下:
- 在兩個不同的 Azure 區域中建立兩個 App Service 方案。 次要 App Service 方案可以使用先前所述的其中一種方法來佈建。
- 設定次要 App Service 方案的自動調整規則,以便在主要區域變成非使用中時,調整成與主要區域相同的執行個體計數。
- 建立 Web 應用程式的兩個執行個體,每個 App Service 方案中各有一個。
- 使用下列項目建立 Azure Front Door 設定檔:
- 端點。
- 原點群組在主要區域中的優先順序為 1。
- 第二個原點群組在次要區域中的優先順序為 2。 優先順序差異會告知 Azure Front Door 在連線時優先使用主要區域 (因此是「主動-被動」模式)。
- 路由。
- 僅限從 Azure Front Door 執行個體到 Web 應用程式的網路流量。
- 設定及配置所有其他後端 Azure 服務,例如資料庫、儲存體帳戶和驗證提供者。
- 使用持續部署,將程式碼部署至兩個 Web 應用程式。
教學課程:在 Azure App Service 中建立高可用性的多區域應用程式會示範如何設定主動-被動架構。
被動-極非經常性存取架構
使用「被動/極非經常性存取」架構,在位於另一個區域的 Azure 儲存體帳戶中建立和維護 Web 應用程式的一般備份。
使用此範例架構:
單一 Web 應用程式會部署到單一區域。
Web 應用程式會定期備份至相同區域中的 Azure 儲存體帳戶。
備份的跨區域複寫取決於 Azure 儲存體帳戶中的資料備援設定。 您應該盡可能將 Azure 儲存體帳戶設定為 GZRS。 GZRS 可以在一個區域中提供同步區域備援,並在次要區域中提供非同步備援。 如果無法使用 GZRS,請將帳戶設定為 GRS。 GZRS 和 GRS 的 RPO 大約 15 分鐘。
為了確保您可以在儲存體帳戶的主要區域無法使用時擷取備份,啟用次要區域的唯讀存取權 (分別設定儲存體帳戶 RA-GZRS 或 RA-GRS)。 如需有關設計應用程式以利用異地備援的詳細資訊,請參閱使用異地備援來設計高可用性應用程式。
在 Web 應用程式區域發生災害期間,您必須使用 Azure 儲存體帳戶中的備份 (最有可能的是使用讀取權存取次要區域),手動部署所有必要的 App Service 相依資源。 RTO 可能是幾小時或幾天。
若要將 RTO 降到最低,強烈建議您建立完整的教戰守則,概述將 Web 應用程式備份還原至另一個 Azure 區域的所有必要步驟。
在 App Service 中為 Web 應用程式建立「被動-極非經常性存取」區域的步驟摘要如下:
使用與 Web 應用程式相同的區域,建立 Azure 儲存體帳戶。 選擇 [標準效能層級],然後選取備援作為異地備援儲存體 (GRS) 或異地區域備援儲存體 (GZRS)。
啟用 RA-GRS 或 RA-GZRS (次要區域的讀取存取權)。
為 Web 應用程式設定自訂備份。 您可以決定如何設定 Web 應用程式備份的排程,例如每小時。
確認可以從儲存體帳戶的次要區域擷取 Web 應用程式備份檔。
提示
除了 Azure Front Door 之外,Azure 還提供其他負載平衡選項,例如 Azure 流量管理員。 如需各種選項的比較,請參閱負載平衡選項 - Azure 架構中心。
單一區域地理位置的災害復原
如果您的 Web 應用程式區域沒有 GZRS 或 GRS 儲存體,或您位於非區域配對的 Azure 區域中,則必須使用區域備援儲存體 (ZRS) 或本地備援儲存體 (LRS) 來建立類似的架構。 例如,您可以手動建立儲存體帳戶的次要區域,如下所示:
建立不含 GRS 和 GZRS 的「被動-極非經常性存取」區域的步驟摘要如下:
在 Web 應用程式的相同區域中,建立 Azure 儲存體帳戶。 選擇 [標準效能層級],然後選取備援作為區域備援儲存體 (ZRS)。
為 Web 應用程式設定自訂備份。 您可以決定如何設定 Web 應用程式備份的排程,例如每小時。
確認可以從儲存體帳戶的次要區域擷取 Web 應用程式備份檔。
在不同的區域中建立第二個 Azure 儲存體帳戶。 選擇 [標準效能層級],然後選取備援作為本地備援儲存體 (LRS)。
藉由使用 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 應用程式備份類似的排程。
下一步
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應