讓所有專案備援

在應用程式中建置備援，以避免發生單一失敗點

復原的應用程式會路由傳送失敗。 識別應用程式中的重要路徑。 路徑中的每個點是否有備援？ 當子系統失敗時，應用程式是否會故障轉移至其他專案？

建議

請考慮商務需求。 系統內建的備援數量可能會影響成本和複雜性。 您的架構應透過商務需求來通知，例如復原時間目標 （RTO） 和恢復點目標 （RPO）。 您也應該考慮您的效能需求，以及小組管理複雜資源集的能力。

請考慮多區域和多區域架構。 請確定您瞭解可用性區域和區域如何提供復原能力，以及不同的架構取捨。

Azure 可用性區域是區域內的隔離數據集。 藉由使用可用性區域，您可以復原單一數據中心或整個可用性區域的失敗。 您可以使用可用性區域來權衡成本、風險降低、效能和復原能力。 例如，當您在架構中使用區域備援服務時，Azure 會在異地分隔的實例之間提供自動數據復寫和故障轉移，以降低許多不同類型的風險。

如果您有任務關鍵性工作負載，且需要降低全區域中斷的風險，請考慮多區域部署。 雖然多區域部署會隔離您免受區域災害的影響，但會付出代價。 多區域部署比單一區域部署更昂貴，而且管理更為複雜。 您需要操作程式來處理故障轉移和容錯回復。 根據您的 RPO 需求，您可能需要接受稍微較低的效能，才能啟用跨區域數據複寫。 某些商務案例可能會有額外的成本和複雜性。

提示

對於許多工作負載，區域備援架構會提供最佳取捨集。 如果您的商務需求指出您需要降低全區域中斷不太可能的風險，而且您已準備好接受這類方法所涉及的取捨，請考慮多區域架構。

若要深入瞭解如何設計解決方案以使用可用性區域和區域，請參閱使用可用性區域和區域的 建議。

將 VM 放在負載平衡器後面。 請勿將單一 VM 用於任務關鍵性工作負載。 相反地，將多個 VM 放在負載平衡器後面。 如果有任何 VM 無法使用，負載平衡器會將流量分散到其餘狀況良好的 VM。 若要瞭解如何部署此設定，請參閱 [多個 VM 以取得延展性和可用性][多 vm-blueprint]。

複寫資料庫。 Azure SQL 資料庫 和 Azure Cosmos DB 會自動復寫區域內的數據，並可設定為跨可用性區域複寫，以提升復原能力。 您也可以選擇跨區域啟用異地複寫。 Azure SQL 資料庫 和 Azure Cosmos DB 的異地複寫會在一或多個次要區域中建立數據的次要可讀取複本。 如果主要區域中發生中斷，資料庫可以故障轉移至次要區域以進行寫入。 視復寫組態而定，您可能會因為未復寫的交易而遺失一些數據。

如果您使用 IaaS 資料庫解決方案，請選擇支援複寫和故障轉移的解決方案，例如 SQL Server Always On 可用性群組。

可用性的數據分割。 資料庫分割通常用來改善延展性，但也可以改善可用性。 如果某個分區關閉，仍然可以連線到其他分區。 一個分區中的失敗只會中斷交易總數的子集。

多區域解決方案

下圖顯示使用 Azure 流量管理員 來處理故障轉移的多區域應用程式。

如果您在多區域解決方案中使用 流量管理員，請考慮下列建議：

同步處理前端和後端故障轉移。 使用 流量管理員 來故障轉移前端。 如果一個區域中無法連線到前端，流量管理員 會將新的要求路由傳送至次要區域。 視後端元件和資料庫解決方案而定，您可能需要協調後端服務和資料庫的故障轉移。

使用自動故障轉移，但手動容錯回復。 使用 流量管理員 進行自動故障轉移，但不適用於自動容錯回復。 自動容錯回復可能會讓您在區域完全狀況良好之前切換至主要區域的風險。 相反地，請先確認所有應用程式子系統在手動容錯回復之前都狀況良好。 此外，視資料庫而定，您可能需要在容錯回復之前檢查數據一致性。

若要達成此目的，請在故障轉移後停用 流量管理員 的主要端點。 請注意，如果探查的監視間隔很短，且容許的失敗數目很小，故障轉移和容錯回復將會在短時間內進行。 在某些情況下，將無法及時完成停用。 若要避免未確認的容錯回復，請考慮同時實作健康情況端點，以確認所有子系統都狀況良好。 請參閱健康情況 端點監視模式。

包含 流量管理員的備援。 流量管理員 是可能的失敗點。 檢閱 流量管理員 SLA，並判斷單獨使用 流量管理員 是否符合高可用性的商務需求。 如果沒有，請考慮新增另一個流量管理解決方案作為容錯回復。 如果 Azure 流量管理員 服務失敗，請將 DNS 中的 CNAME 記錄變更為指向其他流量管理服務。