設計備援的建議
適用於此 Azure 架構完善的架構可靠性檢查清單建議：
| RE：05 | 在不同的層級新增備援，特別是針對重要流程。 根據識別的可靠性目標，將備援套用至計算、數據、網路和其他基礎結構層。 |
|---|
相關指南：使用可用性區域和區域進行高可用性多區域設計 |
本指南說明如何在不同工作負載層新增備援的建議，以優化復原能力。 藉由將適當的備援層級套用至計算、數據、網路和其他基礎結構層，以符合已定義可靠性目標的需求。 套用此備援，為您的工作負載提供強大的可靠基礎，以建置基礎。 當您在沒有基礎結構備援的情況下建置工作負載時，可能會因為 潛在的失敗而延長停機時間。
定義
| 詞彙 | 定義 |
|---|---|
| 備援 | 工作負載元件的多個相同實例實作。 |
| 多語言持續性 | 透過相同應用程式或解決方案使用不同的儲存技術的概念，以充分利用每個元件的最佳功能。 |
| 資料一致性 | 在多個存放區之間同步處理或同步處理指定數據集的方式量值。 |
| 資料分割 | 實際將數據分割成個別數據存放區的程式。 |
| 分區 | 水平資料庫分割策略，可支援具有通用架構的多個記憶體實例。 數據不會在所有實例中複寫。 |
關鍵設計策略
在可靠性的內容中，使用備援來包含影響單一資源的問題，並確保這些問題不會影響整個系統的可靠性。 使用您識別出重要流程和可靠性目標的相關信息，針對每個流程的備援做出明智的決策。
例如，您可能有多個 Web 伺服器節點一次執行。 如果發生會影響整個集區的問題，例如區域性中斷，他們所支援的流程關鍵性可能會要求所有流程都有可接受流量的複本。 或者，由於大規模問題很少見，而且部署整組複本的成本很高，因此您可能會部署有限的複本，讓流程以降級狀態運作，直到您解決問題為止。
當您在效能效率的內容中設計備援時，請將負載分散到多個備援節點，以確保每個節點都能以最佳方式執行。 在可靠性方面，建置備用容量以吸收影響一或多個節點的失敗或故障。 請確定備用容量可以吸收復原受影響節點所需之整個時間的失敗。 考慮到這一區別，這兩種策略都需要一起運作。 如果您將流量分散到兩個節點以達到效能，而且它們都以 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 虛擬 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 應用程式。
下圖顯示另一個範例：
相關連結
若要深入瞭解備援，請參閱下列資源：
可靠性檢查清單
請參閱一組完整的建議。