Azure
Azure Arc
SQL Server
Windows
此範例適用於任何需要部署可靠多層級高可用性與災難復原（DR）應用程式的產業。 在此案例中，應用程式是由三個層級所組成。
網頁層 是包含使用者介面的頂層。 此層解析使用者互動，並將動作傳至下一層進行處理。
業務層 級負責處理使用者互動，並對下一步做出合理決策。 此層會連接 Web 層和數據層。
資料層 透過資料庫、物件儲存或檔案儲存來儲存應用程式資料。
常見的應用場景包括任何在 Windows 或 Linux 上執行的關鍵任務應用程式，例如預先建置的應用程式如 SAP，或是自訂業務線（LOB）應用程式。
架構
下載此架構的 Visio 檔案。
Workflow
下列工作流程對應至上圖：
使用者透過 Azure 流量管理員 端點存取前端 ASP.NET 網頁層。 流量管理器將流量重新導向至主要來源區域的主要公共 IP 位址。 公共 IP 位址會透過公共負載平衡器將通話導向到其中一個網頁層虛擬機（VM）實例。
所有網頁層虛擬實例都存在於同一個子網路中。 內部負載平衡器會將每個呼叫從網頁層路由到商業層虛擬機實例進行處理。
所有商業層虛擬機都存在於獨立的子網路中。 業務層負責處理操作，ASP.NET 應用程式透過內部負載平衡器連接到後端層的 SQL Server 叢集。 這些後端 SQL Server 實例存在於獨立的子網路中。
將每一層中的 VM 分散到支援區域的兩個可用性區域。
在其他區域中，將 VM 部署在一個可用性設定組內的每一層。
你可以設定資料庫層級來使用 Always On 可用性群組 (Always On Availability Groups)。 此 SQL Server 配置在一個可用性群組中使用一個主讀寫副本，以及最多八個次要唯讀副本。 若主要副本失敗，可用性群組會將次要副本升格為主要副本。 次要副本負責讀寫操作並保持應用程式可用。 如需詳細資訊，請參閱 SQL Server 的 Always On 可用性群組概觀。
針對災難復原情境，你可以設定 SQL Always On 非同步原生複製到你用來做災難復原的目標區域。 如果資料變更速率在 Site Recovery 支援的範圍內，你也可以設定 Azure Site Recovery 複製到目標區域。
流量管理員的次要端點會設定為你用於災難復原的目標區域的公有 IP 位址。 當主要區域發生中斷時，你會啟動 Site Recovery 故障轉移，應用程式在目標區域內啟動。 流量管理員端會自動將客戶端流量導向目標區域的公共 IP 位址。
元件
可用性集 是一種容錯功能，可以用來分散虛擬機到叢集中多個隔離的硬體節點。 在此架構中，可用性集透過確保中斷只影響部分虛擬機，來防止硬體與軟體故障。 此方法維持多層應用程式的可用性與營運連續性。
可用性區域 是 Azure 區域內的個別實體位置，可保護應用程式和資料免於資料中心失敗。 在此架構中，可用性區域透過將虛擬機分散到多個擁有獨立電力、冷卻與網路基礎設施的資料中心，提供更高的韌性。
Azure 負載平衡器 是一款第四層負載平衡器，依據定義的規則與健康探針分配入站流量，以達成高吞吐量與低延遲。 在此架構中，公共負載平衡器將進來的客戶端流量分散到網頁層級虛擬機之間。 內部負載平衡器將流量從網頁層路由到商業層，從商業層到後端 SQL Server 叢集。
Traffic Manager 是一款基於網域名稱系統（DNS）的流量負載平衡器，能在全球 Azure 區域間分配流量。 在此架構中，Traffic Manager 提供全域負載平衡。 它在正常運作時將使用者流量導向主要區域，並在中斷時自動將流量導向 DR 區域。
Site Recovery 是一項 DR 服務，會將虛擬機複製到另一個 Azure 區域，以進行業務持續性與災難復原（BC/DR）。 在此架構中，Site Recovery 會將虛擬機複製到目標區域。 此複寫會在來源區域中斷時恢復應用程式，並透過定期的災難復原演練來支援合規要求。
替代方案
你可以用其他作業系統代替 Windows。 基礎架構不依賴特定作業系統。
你可以用 SQL Server for Linux 取代後端資料庫。
你可以用任何標準的資料庫應用程式取代資料儲存。
案例詳細資料
此情境展示了一個使用 ASP.NET 與 SQL Server 的多層級應用程式。 在 支援可用性區域的 Azure 區域中，你可以將虛擬機部署在來源區域，跨越多個可用性區域，並將虛擬機複製到你用於災難復原的目標區域。 在不支援可用性區域的 Azure 區域中，您可以在可用性設定組內部署 VM，並將 VM 複寫至目標區域。
若要在區域之間路由傳送流量，您需要全域負載平衡器。 Azure 的產品包括：
- Azure Front Door
- Traffic Manager
選擇負載平衡器時，請考慮你的需求以及這兩款產品的功能組合。 請考慮故障轉移速度、傳輸層安全性（TLS）相關的管理開銷，以及組織上的成本限制。
Azure Front Door 具備第七層功能，包括安全套接層（SSL）卸載處理、路徑導向路由、快速故障轉移及快取。 這些功能提升了應用程式的效能與高可用性。 Azure Front Door 的價格比 Traffic Manager 還高。 使用Azure Front Door的完整功能，不只是故障轉移，來合理化較高的成本。 Azure Front Door 會在流量路由的過程中更早利用 Azure 網路基礎架構，從而縮短封包的傳輸時間。
Azure Front Door 新增了一個網路躍點，需要進行額外的安全操作。 法規要求可能會限制額外的流量 TLS 終止點。 確認 Azure Front Door 的 TLS 密碼套件是否符合貴組織的安全需求。 同時也要確認你的後端服務是否使用來自 Microsoft Trusted Certificate Authority（CA）清單的憑證。
Traffic Manager 是一種基於 DNS 的負載平衡服務，僅在 DNS 層級進行負載平衡和故障移轉。 Traffic Manager 的故障轉移速度比 Azure Front Door 慢，因為 DNS 快取和不遵循 DNS 生存時間（TTL）值的系統會造成傳播延遲。
你可以把兩個負載平衡器合併使用。 例如，使用 Traffic Manager 進行基於 DNS 的故障轉移，並新增 Azure Front Door 的 point-of-presence (POP) 位置以加快邊緣路由。
此架構使用交通管理器，因其簡單且成本較低。 故障切換速度符合本例的要求。
潛在使用案例
你可以利用此架構來：
- 部署高度韌性的應用程式，如 SAP 及其他關鍵任務組織架構應用程式。
- 為 LOB 應用設計 BC/DR 計畫。
- 設定災難復原（DR）並進行相關的演練以符合合規要求。
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱安全性的設計檢閱檢查清單。
網路安全群組（NSG）保護所有虛擬網路流量至前端應用層。 規則限制流量，只有前端應用層虛擬機實例能存取後端資料庫層。 商業層和資料庫層會阻擋所有外出網路流量。 為了減少攻擊使用量，不會開啟任何直接的遠端管理埠。 欲了解更多資訊，請參閱 Azure NSG。
欲了解更多如何設計安全情境的資訊，請參閱 Azure 安全文件。
成本優化
成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。
在 Azure VM 中使用 Site Recovery for DR 會產生以下持續費用：
每個虛擬機的網站復原授權。
網路出口用來將資料變更從來源虛擬機硬碟複製到另一個 Azure 區域。 Site Recovery 採用內建壓縮技術，將資料傳輸減少約 50%。
存放在復原網站上。 復原站點的儲存容量通常與來源區域的儲存容量相符，並會額外加入供復原點快照使用的儲存空間。
請使用 Azure 定價計算器中的預先設定的估算範本，來估算使用六部 VM 的三層式應用程式災害復原成本。 調整數值以符合你的使用情境。
效能效率
效能效率是指工作負載能夠有效率地調整以符合使用者需求。 有關詳細資訊，請參閱效能效率的設計審核清單。
您可以根據您的調整需求，在每個層中新增或移除 VM。 這種情況會使用負載平衡器，所以你可以在不影響應用程式運作時間的情況下，增加更多虛擬機到同一層。
貢獻者
本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。
主要作者：
- Sujay Talasila | 主要產品負責人
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。