編輯

多區域多層式應用程式

Azure 監視器
Azure 流量管理員
Azure SQL Database
Azure 虛擬機器

此參考架構顯示一組經實證的作法，其可在多個 Azure 區域中執行多層式架構 (N-Tier) 應用程式，以實現可用性和強固的災害復原基礎結構。

架構

Highly available network architecture for Azure N-tier applications

下載此架構的 Visio 檔案。

工作流程

  • 主要和次要區域。 使用兩個區域來達到更高的可用性。 一個是主要區域。 另一個區域是用於故障轉移。

  • Azure 流量管理員。 流量管理員 將連入要求路由傳送至其中一個區域。 在一般作業期間，它會將要求路由傳送至主要區域。 如果該區域無法使用，流量管理員 故障轉移至次要區域。 如需詳細資訊，請參閱 流量管理員 組態一節。

  • 資源群組。 為主要區域、次要區域和 流量管理員 建立個別的資源群組。 此方法可讓您彈性地將每個區域管理為單一資源集合。 例如，您可以重新部署一個區域，而不需要關閉另一個區域。 鏈接資源群組，讓您可以執行查詢來列出應用程式的所有資源。

  • 虛擬網路。 為每個區域建立個別的虛擬網路。 請確定位址空間不會重疊。

  • SQL Server Always On 可用性群組。 如果您使用 SQL Server，建議您 使用 SQL Always On 可用性群組 來達到高可用性。 建立單一可用性群組，其中包含這兩個區域中的 SQL Server 實例。

    注意

    另請考慮 Azure SQL 資料庫，其提供關係資料庫作為雲端服務。 使用 SQL 資料庫 時，您不需要設定可用性群組或管理故障轉移。

  • 虛擬網路對等互連。 將兩個虛擬網路對等互連，以允許將數據從主要區域復寫到次要區域。 如需詳細資訊，請參閱 虛擬網路對等互連。

元件

  • 可用性設定組 可確保您在 Azure 上部署的 VM 會分散到叢集中的多個隔離硬體節點。 如果 Azure 內發生硬體或軟體失敗，則只會影響 VM 的子集，且您的整個解決方案仍可供使用且可運作。
  • 可用性區域 可保護您的應用程式和數據免於資料中心失敗。 可用性區域是 Azure 區域內的個別實體位置。 每個區域皆由一或多個配備獨立電力、冷卻系統及網路的資料中心所組成。
  • Azure 流量管理員 是以 DNS 為基礎的流量負載平衡器，能以最佳方式分散流量。 其提供全球 Azure 區域之間的服務，具有高可用性和回應性。
  • Azure Load Balancer 會根據定義的規則和健康情況探查來散發輸入流量。 負載平衡器提供低延遲和高輸送量，為所有 TCP 和 UDP 應用程式調整為數百萬個流程。 在此案例中會使用公用負載平衡器，將連入用戶端流量分散到 Web 層。 在此案例中會使用內部負載平衡器，將流量從商務層散發到後端 SQL Server 叢集。
  • Azure Bastion 會在布建所在的虛擬網路中，為所有 VM 提供安全的 RDP 和 SSH 連線。 使用 Azure Bastion 保護您的虛擬機，避免將 RDP/SSH 埠公開到外部世界，同時仍使用 RDP/SSH 提供安全存取。

建議

多區域結構可以提供比部署到單個區域更高的可用性。 如果區域中斷會影響主要區域，您可以使用 流量管理員 故障轉移至次要區域。 如果應用程式的單個子系統出現故障，此結構也可以提供幫助。

有數種一般方法可跨區域實現高可用性：

  • 主動/被動與熱待命。 流量流向一個區域，而另一個區域處於熱待命狀態。 熱待命表示次要區域中的 VM 已配置且一律正在執行。
  • 主動/被動與冷待命。 流量流向一個區域，而另一區域處於冷待命狀態。 冷待命表示次要區域中的 VM 在故障轉移需要之前不會配置。 這種方法的執行成本較低，但在失敗期間通常需要較長的時間才能上線。
  • 使用中/主動。 兩個區域都處於活動狀態，並且要求在它們之間進行負載平衡。 如果某個區域變成無法使用，則會從輪替中取出。

此參考架構著重於主動/被動與熱待命，使用 流量管理員 進行故障轉移。 您可以部署一些 VM 以進行熱待命，然後視需要相應放大。

區域配對

每個 Azure 區域都會與相同地理位置內的另一個區域配對。 一般而言，請選擇相同區域配對的區域（例如美國東部 2 和美國中部）。 這麼做的好處包括：

  • 如果發生廣泛的中斷，則會優先復原每對中至少一個區域。
  • 已規劃的 Azure 系統更新會循序推出至配對的區域，以將可能的停機時間降到最低。
  • 配對位於相同的地理位置，以符合數據落地需求。

不過，請確定這兩個區域都支援應用程式所需的所有 Azure 服務（請參閱 依區域的服務）。 如需區域配對的詳細資訊，請參閱 商務持續性和災害復原（BCDR）：Azure 配對區域。

流量管理員 組態

設定 流量管理員 時，請考慮下列幾點：

  • 路由。 流量管理員 支援數種路由演算法。 針對本文所述的案例，請使用 優先順序 路由（先前稱為 故障轉移 路由）。 使用此設定，除非主要區域無法連線，否則 流量管理員 將所有要求傳送至主要區域。 此時，它會自動故障轉移至次要區域。 請參閱 設定故障轉移路由方法。
  • 健康情況探查。 流量管理員 會使用 HTTP （或 HTTPS） 探查來監視每個區域的可用性。 探查會檢查 HTTP 200 回應是否有指定的 URL 路徑。 最佳做法是建立可報告應用程式整體健全狀況的端點，並將此端點用於健康情況探查。 否則，當應用程式的重要部分實際失敗時，探查可能會報告狀況良好的端點。 如需詳細資訊，請參閱 健全狀況端點監視模式。

當 流量管理員 故障轉移時，客戶端無法連線到應用程式有一段時間。 持續時間受下列因素影響：

  • 健康情況探查必須偵測到主要區域已無法連線。
  • DNS 伺服器必須更新IP位址的快取 DNS 記錄，這取決於 DNS 存留時間（TTL）。 默認 TTL 為 300 秒（5 分鐘），但您可以在建立 流量管理員 設定檔時設定此值。

如需詳細資訊，請參閱關於 流量管理員 監視。

如果 流量管理員 故障轉移，建議您執行手動容錯回復，而不是實作自動容錯回復。 否則，您可以建立應用程式在區域之間來回翻轉的情況。 在容錯回復之前，請確認所有應用程式子系統都狀況良好。

流量管理員 預設會自動容錯回復。 若要避免此問題，請在故障轉移事件之後手動降低主要區域的優先順序。 例如，假設主要區域是優先順序 1，而次要區域是優先順序 2。 故障轉移之後，將主要區域設定為優先順序 3，以防止自動容錯回復。 當您準備好切換回時，請將優先順序更新為 1。

下列 Azure CLI 命令會更新優先順序：

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --priority 3

另一種方法是暫時停用端點，直到您準備好容錯回復為止：

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --endpoint-status Disabled

根據故障轉移的原因，您可能需要重新部署區域內的資源。 在容錯回復之前，請執行作業整備測試。 測試應該驗證如下：

  • VM 已正確設定。 （已安裝所有必要的軟體、IIS 正在執行等等。
  • 應用程式子系統狀況良好。
  • 功能測試。 （例如，可從 Web 層連線到資料庫層。

設定 SQL Server Always On 可用性群組

在 Windows Server 2016 之前，SQL Server Always On 可用性群組需要域控制器，而可用性群組中的所有節點都必須位於相同的 Active Directory （AD） 網域中。

若要設定可用性群組：

  • 至少在每個區域中放置兩個域控制器。

  • 為每個域控制器提供靜態IP位址。

  • 將兩個虛擬網路對等互連，以啟用兩者之間的通訊。

  • 針對每個虛擬網路，將域控制器的IP位址（從兩個區域）新增至 DNS 伺服器清單。 您可以使用下列 CLI 命令。 如需詳細資訊，請參閱 變更 DNS 伺服器。

    az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"

  • 建立 Windows Server 故障轉移叢集 （WSFC） 叢集 ，其中包含這兩個區域中的 SQL Server 實例。

  • 建立 SQL Server Always On 可用性群組，其中包含主要和次要區域中的 SQL Server 實例。 如需步驟，請參閱將 AlwaysOn 可用性群組擴充至遠端 Azure 資料中心 （PowerShell）。

    • 將主要復本放在主要區域中。

    • 將一或多個次要複本放在主要區域中。 設定這些復本以搭配自動故障轉移使用同步認可。

    • 將一或多個次要複本放在次要區域中。 基於效能考慮，請將這些複本設定為使用 異步 認可。 （否則，所有 T-SQL 交易都必須等候透過網路往返至次要區域。

      注意

      異步認可複本不支援自動故障轉移。

考量

這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。

可用性

使用複雜的多層式應用程式，您可能不需要複寫次要區域中的整個應用程式。 相反地，您可能只復寫支援商務持續性所需的重要子系統。

流量管理員 是系統中可能的失敗點。 如果 流量管理員 服務失敗，用戶端就無法在停機期間存取您的應用程式。 檢閱 流量管理員 SLA，並判斷單獨使用 流量管理員 是否符合高可用性的商務需求。 如果沒有，請考慮新增另一個流量管理解決方案作為容錯回復。 如果 Azure 流量管理員 服務失敗，請將 DNS 中的 CNAME 記錄變更為指向其他流量管理服務。 （此步驟必須手動執行，而且在傳播 DNS 變更之前，您的應用程式將無法使用。

針對 SQL Server 叢集，有兩個故障轉移案例需要考慮：

  • 主要區域中的所有 SQL Server 資料庫複本都會失敗。 例如，此失敗可能會在區域性中斷期間發生。 在此情況下，您必須手動故障轉移可用性群組，即使 流量管理員 在前端上自動故障轉移也一樣。 請遵循執行 SQL Server 可用性群組的強制手動故障轉移中的步驟，說明如何使用 SQL Server Management Studio、Transact-SQL 或 SQL Server 2016 中的 PowerShell 來執行強制故障轉移。

    警告

    使用強制故障轉移時，數據遺失的風險。 一旦主要區域重新上線，請擷取資料庫的快照集，並使用 tablediff 來尋找差異。

  • 流量管理員 故障轉移至次要區域，但主要 SQL Server 資料庫複本仍可供使用。 例如，前端層可能會失敗，而不會影響 SQL Server VM。 在此情況下，因特網流量會路由傳送至次要區域，而且該區域仍可連線到主要複本。 不過，延遲將會增加，因為 SQL Server 聯機會跨區域進行。 在此情況下，您應該執行手動故障轉移，如下所示：

    1. 暫時將次要區域中的 SQL Server 資料庫複本切換為 同步 認可。 此步驟可確保在故障轉移期間不會遺失數據。
    2. 故障轉移至該複本。
    3. 當您容錯回復到主要區域時，請還原異步認可設定。

管理能力

當您更新部署時，請一次更新一個區域，以減少因應用程式設定不正確或錯誤而發生全域失敗的機會。

測試系統對失敗的復原能力。 以下是一些要測試的常見失敗案例：

  • 關閉 VM 實例。
  • 壓力資源，例如 CPU 和記憶體。
  • 中斷連線/延遲網路。
  • 當機程式。
  • 憑證過期。
  • 模擬硬體錯誤。
  • 關閉域控制器上的 DNS 服務。

測量復原時間，並確認它們符合您的商務需求。 測試失敗模式的組合。

成本最佳化

成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素概觀。

使用 Azure 定價計算機來預估成本。 以下是一些其他考慮。

虛擬機器擴展集

虛擬機器擴展集 適用於所有 Windows VM 大小。 您只需要支付您所部署的 Azure VM 的費用，以及任何已新增的基礎結構資源，例如記憶體和網路功能。 虛擬機器擴展集 服務沒有累加費用。

如需單一 VM 定價選項，請參閱 Windows VM 定價。

SQL Server

如果您選擇 Azure SQL DBaas，您可以節省成本，因為不需要設定 AlwaysOn 可用性群組和域控制器機器。 從單一資料庫到受控實例或彈性集區，有數個部署選項。 如需詳細資訊，請參閱 Azure SQL 定價。

如需 SQL Server VM 定價選項，請參閱 SQL VM 定價。

負載平衡器

您只需支付已設定的負載平衡和輸出規則數目。 輸入 NAT 規則是免費的。 未設定任何規則時，標準 Load Balancer 不會每小時收費。

流量管理員定價

流量管理員的計費是以接收到的 DNS 查詢數量為基準，每個月接收到超過 10 億次查詢的服務將能享有折扣。 您也會針對每個受監視的端點付費。

如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的成本一節。

VNET 對等互連定價

使用多個 Azure 區域的高可用性部署將會使用 VNET 對等互連。 相同區域內的 VNET 對等互連和全域 VNET 對等互連有不同的費用。

如需詳細資訊，請參閱 虛擬網絡 定價。

DevOps

使用單 一 Azure Resource Manager 範本 來布建 Azure 資源及其相依性。 使用相同的範本將資源部署至主要和次要區域。 將所有資源包含在相同的虛擬網路中，使其隔離在相同的基本工作負載中。 藉由包含所有資源，您可以更輕鬆地將工作負載的特定資源與 DevOps 小組產生關聯，讓小組可以獨立管理這些資源的所有層面。 此隔離可讓 DevOps 小組和服務執行持續整合和持續傳遞 （CI/CD）。

此外，您可以使用不同的 Azure Resource Manager 範本 ，並將其與 Azure DevOps Services 整合，以在幾分鐘內布建不同的環境，例如只在需要時復寫生產環境，例如案例或負載測試環境，以節省成本。

請考慮使用 Azure 監視器 來分析和優化基礎結構的效能、監視和診斷網路問題，而不需要登入虛擬機。 Application Insights 實際上是 Azure 監視器的其中一個元件，可提供豐富的計量和記錄，以驗證完整 Azure 環境的狀態。 Azure 監視器可協助您遵循基礎結構的狀態。

請務必不僅監視支援應用程式程式代碼的計算元素，而且監視您的數據平臺，特別是您的資料庫，因為應用程式的數據層效能低可能會產生嚴重後果。

為了測試執行應用程式的 Azure 環境，它應該透過與應用程式程式代碼相同的機制進行版本控制並部署，然後也可以使用 DevOps 測試範例進行測試和驗證。

如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的 Operational Excellence 一節。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

若要查看非公用LinkedIn配置檔，請登入LinkedIn。

下一步

下列架構使用一些相同的技術：