設計備援的建議
適用於此 Azure Well-Architected Framework 可靠性檢查清單建議:
RE:05 | 在不同的層級新增備援,特別是針對重要流程。 根據識別的可靠性目標,將備援套用至計算、數據、網路和其他基礎結構層。 |
---|
相關指南:使用可用性區域和區域進行高可用性多區域設計 |
本指南說明在不同工作負載層級新增整個重要流程的備援建議,以優化復原能力。 藉由將適當的備援層級套用至計算、數據、網路和其他基礎結構層,以符合已定義可靠性目標的需求。 套用此備援,為您的工作負載提供強大的可靠基礎以建置基礎。 當您在沒有基礎結構備援的情況下建置工作負載時,可能會因為 潛在的失敗而延長停機時間。
定義
詞彙 | 定義 |
---|---|
備援 | 工作負載元件的多個相同實例的實作。 |
多語言持續性 | 使用相同的應用程式或解決方案使用不同的記憶體技術的概念,以利用每個元件的最佳功能。 |
資料一致性 | 指定數據集同步或同步處理方式的量值,是跨多個存放區。 |
資料分割 | 實際將數據分割成個別數據存放區的程式。 |
分區 | 支援具有通用架構之多個記憶體實例的水平資料庫分割策略。 數據不會在所有實例中複寫。 |
主要設計策略
在可靠性的內容中,使用備援來包含影響單一資源的問題,並確保這些問題不會影響整個系統的可靠性。 使用您識別出有關重要流程和可靠性目標的信息,針對每個流程的備援做出明智的決策。
例如,您可能一次執行多個網頁伺服器節點。 如果發生會影響整個集區的問題,他們可能要求其所有複本都有準備好接受流量的流程重要性,例如區域性中斷。 或者,因為大規模問題很罕見,而且部署整組複本的成本很高,所以您可能會部署有限的複本數目,因此流程會以降級狀態運作,直到您解決問題為止。
當您在效能效率的內容中設計備援時,請將負載分散到多個備援節點,以確保每個節點都能以最佳方式執行。 在可靠性的內容中,建置備援容量以吸收會影響一或多個節點的失敗或故障。 請確定備援容量可以在復原受影響節點所需的整個時間中吸收失敗。 請記住這項區別,這兩種策略都必須一起運作。 如果您將流量分散到兩個節點以達到效能,且兩者都以 60% 的使用率執行,且一個節點失敗,則剩餘的節點可能會因為無法以 120% 運作而變得超載。 將負載分散到另一個節點,以確保您的效能和可靠性目標會受到支援。
取捨:
- 更多工作負載備援相當於更多成本。 請仔細考慮新增備援,並定期檢閱您的架構,以確保您要管理成本,特別是當您使用過度布建時。 當您使用過度布建作為復原策略時,請將其與定義完善的 調整策略 進行平衡,以將成本效率不佳降到最低。
- 當您以高度備援方式建置時,可能會有效能取捨。 例如,分散於可用性區域或區域的資源可能會影響效能,因為您必須透過重複資源之間的高延遲連線傳送流量,例如 Web 伺服器或資料庫實例。
- 相同工作負載內的不同流程可能會有不同的可靠性需求。 流程特定的備援設計可能會對整體設計造成複雜度。
備援架構設計
當您設計備援架構時,請考慮兩種方法:主動-主動或主動-被動。 根據基礎結構元件所支援的使用者流程和系統流程重要性,選擇您的方法。 就可靠性而言,多區域主動-主動設計可協助您達到最高等級的可靠性,但比主動-被動設計更昂貴。 決定適當的地理區域會成為下一個重要選擇。 您也可以使用可用性區域,針對單一區域使用這些設計方法。 如需詳細資訊,請參閱 高可用性多區域設計的建議。
部署戳記和縮放單位
無論您是在主動-主動或主動-被動模型中部署,請遵循 部署戳記設計模式 ,以確保以可重複且可調整的方式部署工作負載。 部署戳記是將工作負載傳遞給特定客戶子集所需的資源群組。 例如,子集可能是區域子集,或是與工作負載具有相同數據隱私權需求的子集。 請將每個戳記視為可重複 的縮放單位 ,以水平調整工作負載,或執行藍綠部署。 使用部署戳記設計工作負載,以將主動-主動或主動-被動實作優化,以進行復原和管理負擔。 規劃多區域相應放大對於克服區域中的潛在暫時資源容量限制也很重要。
Azure 區域內的可用性區域
無論您是部署主動-主動或主動-被動設計,請利用使用中 區域內的可用性區域 ,以完全優化您的復原能力。 許多 Azure 區域提供多個可用性區域,這些區域是區域內的數據中心群組。 視 Azure 服務而定,您可以跨區域重複部署工作負載的元素,或將元素釘選到特定區域,以利用可用性區域。 如需詳細資訊,請參閱 使用可用性區域和區域的建議。
基礎結構層指引
計算資源
為您的工作負載選擇適當的 計算服務 。 根據您設計的工作負載類型,可能會有數個選項可用。 研究可用的服務,並瞭解哪些類型的工作負載最適合用於指定的計算服務。 例如,SAP 工作負載通常最適合基礎結構即服務, (IaaS) 計算服務。 針對容器化應用程式,請判斷您需要控制的特定功能,以判斷要使用 Azure Kubernetes Service (AKS) 或平臺即服務, (PaaS) 解決方案。 您的雲端平臺會完全管理 PaaS 服務。
如果您的需求允許,請使用 PaaS 計算選項。 Azure 完全管理 PaaS 服務,可降低管理負擔,並內建記載的備援程度。
如果您需要部署虛擬機 (VM) ,請使用 Azure 虛擬機器擴展集。 透過 虛擬機器擴展集,您可以自動將計算平均分散到可用性區域。
讓您的計算層 清除任何狀態 ,因為處理要求的個別節點可以隨時遭到刪除、錯誤或取代。
盡可能使用區域備援服務來提供更高的復原能力,而不會增加您的作業負擔。
過度布建重要資源,以減輕備援實例失敗,即使在自動調整作業開始之前,系統仍會在元件失敗之後繼續運作。 當您將過度布建併入備援設計時,計算錯誤的可接受效果。 如同備援決策制定程式,可靠性目標和財務取捨決策會決定您使用過度布建來新增備用容量的程度。 過度布建特別是指 相應放大,這表示新增指定計算資源類型的額外實例,而不是增加任何單一實例的計算功能。 例如,如果您將 VM 從較低層 SKU 變更為較高層級的 SKU。
在您想要實作解決方案的每個可用性區域或區域中,手動或透過自動化部署 IaaS 服務。 某些 PaaS 服務具有內建功能,可在可用性區域和區域之間自動復寫。
資料資源
判斷工作負載的功能是否需要同步或異步數據複寫。 若要協助您做出此判斷,請參閱 使用可用性區域和區域的建議。
請考慮數據的成長率。 針對容量規劃,請規劃數據成長、數據保留和封存,以確保解決方案中的數據量增加時,符合可靠性需求。
依您的服務所支援,依地理位置散發數據,以將異地當地語系化失敗的影響降到最低。
跨地理區域復寫數據,以提供區域性中斷和重大失敗的復原能力。
在資料庫實例失敗之後自動故障轉移。 您可以在多個 Azure PaaS 資料服務中設定自動故障轉移。 支援多區域寫入的數據存放區不需要自動故障轉移,例如 Azure Cosmos DB。 如需詳細資訊,請參閱 設計災害復原策略的建議。
針對您的數據使用最佳 數據存放區 。 採用混合數據存放區技術的polyglot持續性或解決方案。 數據包含不只是保存的應用程式數據。 它也包含應用程式記錄、事件、訊息和快取。
考慮數據一致性需求,並在需求允許時使用 最終一致性 。 當數據散發時,請使用適當的協調來強制執行強式一致性保證。 協調可以降低輸送量,並讓系統緊密結合,這可讓它們更不緊密。 例如,如果作業更新兩個資料庫,而不是將其放入單一交易範圍,則系統可以容納最終一致性會比較好。
分割可用性數據。 資料庫分割 可改善延展性,也可以改善可用性。 如果一個分區關閉,其他分區仍可連線。 一個分區中的失敗只會中斷交易總數的子集。
如果分區化不是選項,您可以使用 命令和查詢責任隔離 (CQRS) 模式 來分隔讀寫和只讀數據模型。 新增更多備援只讀資料庫實例,以提供更多復原能力。
瞭解您所使用具狀態平臺服務的內建複寫和備援功能。 如需具狀態數據服務的特定備援功能,請參閱 相關連結。
網路
決定可靠且可調整的網路拓撲。 使用中樞和輪輻模型或 Azure Virtual WAN 模型,協助您以邏輯模式組織雲端基礎結構,讓您的備援設計更容易建置和調整。
選取適當的 網路服務 ,以平衡和重新導向區域內或跨區域的要求。 盡可能使用全域或區域備援負載平衡服務,以符合您的可靠性目標。
請確定您已在虛擬網路和子網中配置足夠的IP位址空間,以考慮規劃的使用方式,包括向外延展需求。
確定應用程式可以在所選應用程式裝載平臺的埠限制內進行調整。 如果應用程式起始數個輸出 TCP 或 UDP 連線,它可能會耗盡所有可用的埠,並造成應用程式效能不佳。
選擇 SKU 並設定可符合頻寬和可用性需求的網路服務。 VPN 閘道的輸送量會根據其 SKU 而有所不同。 區域備援的支援僅適用於某些負載平衡器 SKU。
請確定處理 DNS 的設計是以恢復功能為主,並支援備援基礎結構。
Azure 設施
Azure 平台可協助您優化工作負載的復原能力,並透過下列方式新增備援:
針對許多 PaaS 和軟體即服務提供內建備援, (SaaS) 解決方案,其中一些是可設定的。
可讓您使用 可用性區域 和區域間備援來設計和實作區域內備援。
提供複本感知負載平衡服務,例如 Azure 應用程式閘道、Azure Front Door 和 Azure Load Balancer。
提供可輕鬆實作的異地復寫解決方案,例如 Azure SQL 資料庫的主動式異地複寫。 使用 Azure Cosmos DB 實作 全域散發 和透明復寫。 Azure Cosmos DB 提供兩個選項來處理 衝突的寫入。 選擇工作負載的最佳選項。
為許多 PaaS 資料服務提供時間點還原功能。
透過 Azure NAT 閘道或 Azure 防火牆 降低埠耗盡。
DNS 專屬的 Azure 服務
針對內部名稱解析案例,請使用具有內建區域備援和異地備援的 Azure DNS 私人區域。 如需詳細資訊,請參閱 Azure DNS 私人區域復原。
針對外部名稱解析案例,請使用具有內建區域備援和異地備援的 Azure DNS 公用區域。
公用和私人 Azure DNS 服務是可復原區域性中斷的全域服務,因為區域數據是全域可用的。
針對內部部署與雲端環境之間的混合式名稱解析案例,請使用 Azure DNS 私人解析程式。 如果您的工作負載位於支援可用性區域的區域中,此服務支援區域備援。 全區域中斷在區域復原期間不需要採取任何動作。 服務會自動自我修復和重新平衡,以利用狀況良好的區域。 如需詳細資訊,請參閱 Azure DNS 私人解析程式中的復原。
若要消除單一失敗點,並跨區域達成更具彈性的混合式名稱解析,請跨不同區域部署兩個或多個 Azure DNS 私人解析程式。 在條件式轉送案例中,DNS 故障轉移是藉由將解析程式指派為主要 DNS 伺服器來達成。 將不同區域中的其他解析程式指派為次要 DNS 伺服器。 如需詳細資訊,請參閱 使用私人解析程式設定 DNS 故障轉移。
範例
如需多區域備援部署的範例,請參閱 基準高可用性區域備援 Web 應用程式。
下圖顯示另一個範例:
相關連結
若要深入瞭解備援,請參閱下列資源:
可靠性檢查清單
請參閱一組完整的建議。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應