此範例案例適用於任何需要部署針對高可用性和災害復原所建置的復原多層應用程式產業。 在此案例中，應用程式是由三個層級所組成。
- Web 層：包括使用者介面的最上層。 此層會剖析用戶互動，並將動作傳遞至下一層進行處理。
- 商務層：處理用戶互動，並針對後續步驟做出邏輯決策。 此層會連接 Web 層和數據層。
- 數據層：儲存應用程式數據。 通常使用資料庫、物件記憶體或檔案記憶體。
常見的應用程式案例包括 Windows 或 Linux 上執行的任何任務關鍵性應用程式。 這可以是現成的應用程式，例如 SAP 和 SharePoint 或自定義的企業營運應用程式。
潛在的使用案例
其他相關的使用案例包括：
- 部署高度復原的應用程式，例如 SAP 和 SharePoint
- 為企業營運應用程式設計商務持續性和災害復原計劃
- 設定災害復原並針對合規性目的執行相關演練
架構
工作流程
- 將每一層中的 VM 分散到支援區域的兩個可用性區域。 在其他區域中，將 VM 部署在一個可用性設定組內的每一層。
- 資料庫層可以設定為使用 Always On 可用性群組。 使用此 SQL Server 設定時，可用性群組內的一個主要讀取/寫入複本會設定最多八個次要只讀複本。 如果主要復本發生問題，可用性群組會將主要讀取/寫入活動故障轉移至其中一個次要複本，讓應用程式維持可用狀態。 如需詳細資訊，請參閱 SQL Server 的 Always On 可用性群組概觀。
- 針對災害復原案例，您可以將 SQL Always On 異步原生複寫設定為用於災害復原的目標區域。 如果數據變更率在 Azure Site Recovery 的支援範圍內，您也可以設定 Azure Site Recovery 複寫至目標區域。
- 用戶可透過流量管理員端點存取前端 ASP.NET Web 層。
- 流量管理員會將流量重新導向至主要來源區域中的主要公用IP端點。
- 公用IP會透過公用負載平衡器將呼叫重新導向至其中一個Web層 VM 實例。 所有 Web 層 VM 實例都位於一個子網中。
- 從 Web 層 VM，每個呼叫都會透過內部負載平衡器，路由傳送至商務層中的其中一個 VM 實例進行處理。 所有商務層 VM 都位於個別的子網中。
- 作業會在商務層中處理，ASP.NET 應用程式會透過 Azure 內部負載平衡器連線到後端層中的 Microsoft SQL Server 叢集。 這些後端 SQL Server 實例位於不同的子網中。
- 流量管理員的次要端點會設定為用於災害復原的目標區域中的公用IP。
- 發生主要區域中斷時，您會叫用 Azure Site Recovery 故障轉移，而應用程式會在目標區域中變成作用中。
- 流量管理員端點會自動將用戶端流量重新導向至目標區域中的公用IP。
元件
- 可用性設定組 可確保您在 Azure 上部署的 VM 會分散到叢集中的多個隔離硬體節點。 如果 Azure 內發生硬體或軟體失敗，則只會影響 VM 的子集，且您的整個解決方案仍可供使用且運作。
- 可用性區域 可保護您的應用程式和數據免於資料中心失敗。 可用性區域是 Azure 區域內的個別實體位置。 每個區域皆由一或多個配備獨立電力、冷卻系統及網路的資料中心所組成。
- Azure Site Recovery 可讓您將 VM 複寫至另一個 Azure 區域，以符合商務持續性和災害復原需求。 您可以定期進行災害復原演練，以確保符合合規性需求。 VM 將會使用指定的設定複寫至選取的區域，以便在來源區域中發生中斷時復原應用程式。
- Azure 流量管理員 是以 DNS 為基礎的流量負載平衡器，可將流量以最佳方式分散到全球 Azure 區域的服務，同時提供高可用性和回應性。
- Azure Load Balancer 會根據定義的規則和健康情況探查來散發輸入流量。 負載平衡器提供低延遲和高輸送量，為所有 TCP 和 UDP 應用程式調整為數百萬個流程。 在此案例中會使用公用負載平衡器，將連入用戶端流量散發至 Web 層。 在此案例中，會使用內部負載平衡器將流量從商務層散發到後端 SQL Server 叢集。
替代項目
- Windows 可以由其他作業系統取代，因為基礎結構中沒有任何專案相依於操作系統。
- 適用於 Linux 的 SQL Server 可以取代後端資料存放區。
- 資料庫可以取代為任何可用的標準資料庫應用程式。
案例詳細資料
此案例示範使用 ASP.NET 和 Microsoft SQL Server 的多層應用程式。 在 支援可用性區域的 Azure 區域中，您可以在來源區域中跨可用性區域部署虛擬機，並將 VM 複寫至用於災害復原的目標區域。 在不支援可用性區域的 Azure 區域中，您可以在可用性設定組內部署 VM，並將 VM 複寫至目標區域。
若要在區域之間路由傳送流量，您需要全域負載平衡器。 有兩個主要的 Azure 供應專案：
- Azure Front Door
- Azure 流量管理員
選擇負載平衡器時，請考慮您的需求和兩個供應專案的功能集。 您想要故障轉移的速度有多快？ 您可以承擔 TLS 管理的額外負荷嗎？ 是否有組織成本限制？
Front Door 具有第 7 層功能：SSL 卸除、路徑型路由、快速故障轉移、快取及其他專案，以改善應用程式的效能和高可用性。 您可能會遇到更快的封包移動時間，因為基礎結構已於 Azure 網路上更快上線。
因為 Front Door 新增了躍點，因此新增了安全性作業。 如果架構符合法規需求，可能會有其他流量 TLS 終止點的限制。 Front Door 所選取的 TLS 加密套件必須符合您組織的安全性列。 此外，Front Door 預期後端服務會使用 Microsoft 所使用的憑證。
另一個考慮是成本。 架構應該利用廣泛的功能集（不只是故障轉移）來證明新增的成本。
流量管理員 是以 DNS 為基礎的負載平衡服務。 它只會在 DNS 層級平衡和故障轉移。 基於這個理由，DNS 快取和系統不接受 DNS TTL 的常見挑戰，其無法像 Front Door 一樣快速容錯移轉。
如有需要，您可以合併這兩個負載平衡器。 例如，您想要 DNS 型故障轉移，但您想要在該流量管理的基礎結構前面新增 POP 體驗。
此架構會使用 流量管理員，因為它是輕量型的。 故障轉移時間足以說明目的。
考量
延展性
您可以根據您的調整需求，在每個層中新增或移除 VM。 由於此案例會使用負載平衡器，因此您可以將更多 VM 新增至階層，而不會影響應用程式運作時間。
如需其他延展性主題，請參閱 Azure 架構中心的效能效率檢查清單 。
安全性
進入前端應用層的所有虛擬網路流量都會受到網路安全組的保護。 規則會限制流量流量，讓只有前端應用層 VM 實例可以存取後端資料庫層。 不允許來自商務層或資料庫層的輸出因特網流量。 為了減少攻擊使用量，不會開啟任何直接的遠端管理埠。 如需詳細資訊，請參閱 Azure 網路安全組。
如需設計安全案例的一般指引，請參閱 Azure 安全性檔。
定價
使用 Azure Site Recovery 設定 Azure VM 的災害復原，將會持續產生下列費用。
- 每個 VM 的 Azure Site Recovery 授權成本。
- 將來源 VM 磁碟的數據變更復寫到另一個 Azure 區域的網路輸出成本。 Azure Site Recovery 使用內建壓縮來減少大約 50% 的數據傳輸需求。
- 儲存體 復原網站上的成本。 這通常與來源區域記憶體相同，再加上維護恢復點作為復原快照所需的任何其他記憶體。
我們已提供範例成本計算機，以使用六部虛擬機為三層式應用程式設定災害復原。 所有服務都會在成本計算機中預先設定。 若要查看您特定使用案例的價格如何變更，請變更適當的變數以估計成本。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- Sujay Talasila |主要產品潛在客戶
下一步
相關資源
如需其他高可用性和災害復原參考架構，請參閱：
- 多區域多層式應用程式
- 多重區域負載平衡
- [具有私人資料庫的多重區域應用程式][Multi-region-app-with-private-database]
- 企業級災害復原