為了讓您的應用程式對可用性區域相關硬體故障、網路中斷及自然災害更具韌性,請將您的 Azure 工作負載設計成具備區域韌性。 當你在 Azure 區域內將資源分配到多個可用區域時,可以降低單一區域中斷影響關鍵服務的風險。
雖然在工作負載的初始規劃和部署期間解決區域復原問題是最佳做法,但通常想要將現有的非復原工作負載轉換成區域復原設定。 一般而言,為現有工作負載啟用區域韌性(zone resiliency)的處理相當直接,Microsoft 持續簡化此流程。 不過,工作負載的任何變更都可能帶來一定的風險。 瞭解所涉及的風險之後,您就可以評估這些工作負載中的哪些工作負載和服務對您的業務最重要,並排定其優先順序,然後先將區域復原套用至最具影響力的資源。
本文概述了在 Azure 工作負載中實現可用性區域韌性的關鍵考量。 它幫助你規劃、實施並驗證這些變更。
小提示
如果您目前正在設計工作負載,或計劃對現有工作負載進行設計審查,請遵循Azure Well-Architected框架(WAF)中關於冗餘設計的建議。 WAF 建議指南可協助您設計跨多個層級的工作負載備援,並專注於關鍵工作流程。 除了支援採用可用性區域外,本文也概述多區域部署和部署戳記等策略。
什麼是區域復原力?
Azure 服務可以透過兩種主要方式讓其對可用性區域中斷具備韌性:
區域冗餘服務:許多Azure服務支援區域冗餘。 這些服務會在可用性區域之間自動複寫資料、散發傳入要求,並在區域失敗期間容錯移轉至不同的區域。 每個服務都以對該特定服務有意義的方式支援這些功能。 機制與復原行為因服務而異,應用程式在故障轉移期間仍可能遭遇暫時性中斷。 某些服務預設為區域備援,而其他服務可能需要您設定區域備援。
區域服務: 部分Azure服務是區域性的,意即它們可以被固定在特定的可用性區域。 若要使用區域服務來達到區域復原能力,請在多個可用性區域中部署服務的個別執行個體。 您可能還需要管理流量分配、資料複寫,以及執行個體之間的容錯移轉。
某些服務可以部署在區域備援或區域性設定中。 在大部分情況下,最好盡可能部署區域備援服務。
如需詳細資訊,請參閱可用性區域支援類型。
區域復原能力啟用程序
請依照以下步驟系統性檢視您的 Azure 工作負載,優先排序區域韌性,並為每個元件啟用區域韌性。
先決條件
開始之前,請執行下列動作:
識別每個工作負載。 工作負載是指應用程式資源、資料和支援基礎結構的集合,它們共同運作以實現定義的業務成果。 若要深入了解工作負載以及如何加以定義,請參閱 Well-Architected Framework 工作負載。
排定每個工作負載的使用者和系統流程的優先順序。 了解工作負載的關鍵路徑與相依性,決定優先使哪些元件具備區域韌性。 欲了解更多如何利用關鍵流程分析來優先排序工作流程的資訊,請參閱「 識別與評分流程的架構策略」。
為每個工作負載和流程指派重要性評等。 此評等可協助您了解潛在中斷對業務的影響,並指導您決定要優先處理哪些工作負載以實現區域復原。 此外,請考慮重新設定工作負載時可接受的停機時間量。
您可以使用分類法,根據工作負載的重要性對工作負載進行分類。 這種方法可協助您將精力集中在最重要的服務上。
請考慮使用下列範例分類法,對工作負載進行分類。
工作負載類型 Description 中斷的影響 任務關鍵性 關鍵的流程與工作負載必須高度可靠、隨時可用、具備故障韌性,且在發生任何停機時能在明確的復原目標內恢復。 對基本功能的任何中斷都會立即面臨災難性的業務損失,或給人類生命帶來風險。 業務關鍵 操作重要業務功能的基本流程和工作負載。 中斷可能會造成一些財務損失或品牌損害。 企業營運管理 有助於提高業務營運效率,但無法直接為客戶提供服務。 可以容忍一定程度的干擾。 行政 內部生產流程和工作負載與業務營運不一致。 可以忍受干擾。 如需如何根據重要性評等對工作負載進行分類的詳細資訊,請參閱將重要性評等指派給每個流程。
確認你 Azure 資源所在的區域是否支援可用性區域。 請參閱Azure區域列表。 區域不支援可用性區域時,請考慮將資源重新定位至支援的區域。 欲了解更多資訊,請參閱 跨資源群組、訂閱或區域移動Azure資源。
步驟 1:優先使用 Azure 服務以提升區域韌性
當你確定哪些工作負載流程對你的業務最關鍵後,你可以專注於這些流程所依賴的 Azure 服務。 有些 Azure 服務對你的應用程式來說比其他服務更為關鍵。 排定這些服務的優先順序,以協助確保您的應用程式在發生區域故障時保持可用和復原能力。
請依照以下指引,根據 Azure 服務群組對你的工作負載的重要性來優先排序。 當您決定區域復原的服務優先順序時,請考慮您的特定應用程式架構和業務需求。
從網路服務開始。 工作負載傾向於共用網路服務,因此增加這些服務的彈性可以同時改善多個工作負載的彈性。
許多核心網路服務會自動進行區域冗餘,但您應該專注於如 Azure ExpressRoute 閘道器、Azure VPN 閘道、Azure 應用程式閘道、Azure Load Balancer 和 Azure 防火牆 等元件。
提高營運資料儲存彈性。 作業資料存放區包含多個工作負載經常使用的寶貴資料,因此改善這些資料存放區的可用性可協助許多工作負載。
為了操作性資料儲存韌性,請專注於像 Azure SQL Database、Azure SQL 受控執行個體、Azure 儲存體、Azure Data Lake Storage、Azure Cosmos DB 等服務,適用於 PostgreSQL 的 Azure 資料庫, 適用於 MySQL 的 Azure 資料庫, and Azure Managed Redis.
排定運算服務的優先順序。 無狀態應用程式實例可以在不同區域間複製並分散,而無需在實例間複製應用程式狀態。 然而,運算服務也可以承載有狀態應用程式。 規劃區域韌性時,請考慮其資料、儲存與複製需求。
計算服務包括 Azure 虛擬機器、Azure 虛擬機器擴展集、Azure Kubernetes Service (AKS)、Azure App 服務、App Service 環境、Azure Functions、Azure Service Fabric 及 Azure 容器應用程式。
檢閱重要流程使用的剩餘關鍵業務資源。 這些資源可能不如先前列出的資源那麼重要,但它們仍然在應用程式的功能中發揮作用,您應該考慮它們以實現區域復原。
檢閱其餘的業務營運資源。 就是否要讓它們具有區域彈性做出明智的決定。 此檢閱包含的服務可能與您的重要工作負載不直接相關,但仍有助於整體應用程式效能和可靠性。
步驟 2:評估區域設定方法
在優先處理工作負載和 Azure 服務後,找出啟用每個服務可用性區域支援所需的方法。 了解你需要做什麼來設定區域韌性。
每份 Azure 可靠性服務指南都會有一節說明如何啟用該服務的區域韌性。 本節可協助您瞭解讓每個服務區域具有彈性所需的工作,以便您可以據以規劃策略。 欲了解更多特定服務資訊,請參閱 Azure 可靠性服務指南。
使用區域設定資料表找出常見 Azure 服務的採用方式。
這很重要
如果您的工作負載包含部署在分區(或單一區域)設定中的元件,請規劃讓這些元件能夠抵抗區域中斷。 常見的方法是將個別執行個體部署到另一個可用區域,並在必要時在它們之間切換。
步驟 3:測試延遲
當您讓工作負載區域具有復原能力時,請考慮可用性區域之間的延遲。 有時,有些舊系統無法忍受跨區流量帶來的少量額外延遲,尤其是在你啟用了資料層級內跨區域的同步複製時。 如果您懷疑跨區域延遲可能會影響您的工作負載,請在啟用區域復原之前和之後執行測試。 欲了解更多跨區延遲可能影響您的應用程式及減輕跨區延遲問題的方法,請參閱 區域資源與區域韌性。
步驟四:實施變更
對於每個元件,請依照 其可靠性指南中的設定或遷移指示操作。 在你變更生產資源之前:
- 為關鍵流程定義驗收標準,包括可接受的停機時間、延遲、吞吐量及資料遺失。
- 請檢查服務的區域、層級、容量和配額要求。 包含相依資源以及遷移所需的臨時資源。
- 確認你有可恢復的備份(如適用)。 請使用可靠性指南中的 備份與還原 部分,了解如何備份每個資源。 記錄若變更失敗時如何回滾或恢復,包括如何處理遷移切換後寫入的資料。
- 在具代表性的非生產環境中測試變更與恢復程序。
在服務支援的情況下分階段套用變更。 監控每個階段的應用程式健康狀況與關鍵流程,若結果未達接受標準,請使用回滾或恢復程序。
步驟五:驗證區域韌性
套用變更後,請確認工作量符合 你定義的接受標準。 驗證新配置,例如檢查服務是否已設定區域冗餘。
有些服務則是管理實例數量。 檢查服務的實例是否分布在不同可用區域。 若有一個區域無法使用,評估其餘倖存區域的容量是否能滿足您的需求。 不要以為在發生中斷時能分配替代容量。 如需詳細資訊,請參閱 使用過度布建來管理容量。
對於支援故障測試的服務,請依照其可靠性指南,在受控環境中測試故障與復原期間的應用程式行為。 測試你負責的行為,而不是試圖驗證 Microsoft 內部的故障轉移機制。
Azure 服務的區域組態方法
每個 Azure 服務都支援特定類型的可用性區域支援,這取決於服務的預期用途與內部架構。 如果你有資源沒有設定使用可用區域(也稱為 非區域 資源),你可能需要重新配置它,支援可用區域。 該服務的可靠性指南提供指導或可用性區域設定指示的連結。
本節概述不同類型的區域配置方法,以及每個服務支援的方法。 這部分排除了非區域服務,因為 Azure 不會部署到單一區域。 欲了解更多非區域服務資訊,請參閱 Azure 非區域服務及服務可靠性指南。
這很重要
當您在資源上啟用區域備援時,該資源將具備自動復原區域失效的能力。 當您使用 區域性 設定將資源固定至特定可用性區域時,資源不會自動具有區域冗餘性。 您必須讓它能夠具備對區域失效的復原力。 就區域性服務而言,本文所反映的是將服務固定於單一區域的複雜度與成本,而非使其具備區域復原能力。 欲了解更多達成區域韌性額外步驟的資訊,請參閱 服務的可靠性指南 ,以及 區域資源與區域韌性。
zone 配置表列出了許多Azure服務所支援的區域配置方法,並包含該服務每個可靠性指南的連結。 可靠性指南提供如何設定非區域服務資源以啟用可用區域支援的相關資訊。
下表說明常見的區域配置方法,包括啟用可用區域所需的工作量與停機時間。 有些服務因為運作方式不同,列出了不同的做法。
| 方法 | Description | 一般等級的工作量 | 可能需要停機 |
|---|---|---|---|
| 始終具有區域彈性 | 根據預設,服務在 支援可用性區域的區域中具有區域復原能力。 不需要採取任何動作。 | None | 否 |
| 支援 | 需要最少量的設定變更,例如在設定中啟用區域備援。 此過程對資源的可用性影響極小或不大,但可考慮成本或效能的影響。 | Low | 無或極少 |
| 修改 | 可能需要一些設定變更,例如重新部署相依資源或修改網路設定。 | 中等 | Yes |
| 重新部署 | 需要進行重大變更,例如重新部署整個資源、應用程式或服務,或將資料移轉至新服務。 | High | Yes |
了解為服務啟用可用區域支援的成本。 有些服務不會單獨收費,但你仍然需要為所部署的資源和容量付費。 其他服務則需要特定層級、最低執行個體數目、最低容量單位數,或兩者皆需。 對於儲存服務而言,區域冗餘儲存(ZRS)的費率可能高於本地冗餘儲存(LRS)。 下一節的表格將識別這些成本因素。
備註
本文中的資訊摘要說明啟用可用區域支援的一般方法,並概述一般成本影響。 但某些因素可能會影響它如何適用於您的特定解決方案。 例如,某些服務會列為 一律區域復原,但此指定僅適用於特定區域或服務的特定層。 請以這些表格作為起點,但請參考連結的可靠性指南以了解具體細節。
區域配置方法的 Azure 服務
下表總結了許多 Azure 服務的可用性區域支援,並提供一種方法,包括成本影響,以啟用每個服務的可用性區域支援。
| 服務 | 可以是區域備援 | 可以是區域性 | 一般區域設定方法 | 一般成本影響 |
|---|---|---|---|---|
|
|
|
支援 | 最低階級與複本數量要求 | |
|
|
|
|
自動設定:一律具備區域復原能力 手動區域重新配置:修改 |
額外單位以 Premium 級別費率計費 |
|
|
|
重新部署 | 額外單位則依所選梯級的費率計費 | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
支援 | 所需的最低層級和實例數量 | |
|
|
|
支援 | 最低所需的執行個體數量 | |
|
|
|
|
始終具有區域彈性 | N/A |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
重新部署 | 適度成本增加 | |
|
|
|
|
重新部署 | 無成本影響 |
|
|
|
重新部署 | 相同數量的虛擬機器 (VM) 沒有成本影響 | |
|
|
|
支援 | 適度成本增加 | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
重新部署 | 所需的副本數量下限 | |
|
|
|
重新部署 | 無成本影響 | |
|
|
|
|
重新部署 | 相同數量的容器群組不會產生成本影響 |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
修改 | 若使用自動調整或多區域寫入,則無 | |
|
|
|
修改 | 適度成本增加 | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
支援 | 適度成本增加 | |
|
|
|
|
重新部署 | 需要主要複本和高可用性 (HA) 複本 |
|
|
|
|
支援 | 需要主要複本和 HA 複本 |
|
|
|
支援 | 相同數量的虛擬機不會產生成本影響;儲存成本適度增加 | |
|
|
|
|
支援 | 適度成本增加 |
|
|
|
一律具有區域復原力 | N/A | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
支援 | 需要主要和 HA 備用分片 | |
|
|
|
重新部署 | 適度成本增加 | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
始終具有區域彈性 | 所需的最小容量單位 (CU) | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
新閘道:預設區域韌性 現有非分區閘道:修改 |
最低需求的 SKU | |
|
|
|
|
支援 | ZRS:中度成本上升 分區 LRS:不會影響成本 |
|
|
|
|
新的防火牆:預設具備區域復原能力 現有非區域防火牆:修改(自動遷移進行中) |
無成本影響 |
|
|
|
支援 | 最低所需的執行個體數量 | |
|
|
|
支援 | 最低所需的執行個體數量 | |
|
|
|
重新部署 | 最低所需的執行個體數量 | |
|
|
|
重新部署 | 相同數量的節點沒有成本變動 | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
|
重新部署 | 無成本影響 |
|
|
|
|
修改 | 無成本影響 |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
重新部署 | 所需的最低層級和實例數量 | |
|
|
|
重新部署 | 適度成本增加 | |
|
|
|
支援 | 需要主要和 HA 執行個體 | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
始終具有區域彈性 | ||
|
|
|
|
重新部署 | 無成本影響 |
|
|
|
重新部署 | 取決於複寫組態 | |
|
|
|
重新部署 | 適度成本增加 | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
支援 | 適度成本增加 | |
|
|
|
一律具有區域復原力 | N/A | |
|
|
|
|
重新部署 | 相同數量的 VM 沒有成本影響 |
|
|
|
支援 | 所需的最低層級 | |
|
|
|
重新部署 | Site Recovery 沒有成本影響,複本儲存則有中度成本增加 | |
|
|
|
支援 | 無成本影響 | |
|
|
|
支援 | 適度成本增加 | |
|
|
|
重新部署 | 所需的副本數量下限 | |
|
|
|
支援 | 無成本影響 | |
|
|
|
支援 | 適度成本增加 | |
|
|
|
一律具備區域復原能力(控制平面) 啟用(目標儲存帳戶) |
N/A(控制平面) 這取決於目標儲存帳戶的冗餘性 |
|
|
|
|
一律具有區域復原力 | N/A | |
|
|
|
一律具有區域復原力 | N/A | |
|
|
|
支援 | 適度成本增加 | |
|
|
|
|
重新部署 | 相同數量的 VM 沒有成本影響 |
|
|
|
修改 | 相同數量的 VM 沒有成本影響 | |
|
|
|
始終具有區域彈性 | N/A | |
|
|
|
一律具有區域復原力 | N/A | |
|
|
|
|
重新部署 | 相同數量的節點沒有成本變動 |
|
|
|
修改 | 最低需求的 SKU | |
|
|
|
支援 | 所需的最低層級 | |
|
|
|
|
始終具有區域彈性 | N/A |