在多個 Azure Stack Hub 區域中執行多層式架構 (N-Tier) 應用程式以獲得高可用性

此參考架構顯示一組經過證實的作法,可跨多個 Azure Stack Hub 區域執行多層式架構應用程式,以實現可用性和穩固的災害復原基礎結構。 在此文件中,「流量管理員」是用來達成高可用性,不過若「流量管理員」不是您環境中的優先選擇,您可以使用一組高可用性負載平衡器來取代。

注意

請注意,下面架構中使用的「流量管理員」必須在 Azure 中設定,且用於設定「流量管理員」設定檔的端點必須是可在公開網路上路由的 IP。

架構

此架構係根據具有 SQL Server 的多層式架構 (N-tier) 應用程式中顯示的架構而建置的。

Highly available network architecture for Azure N-tier applications

  • 主要和次要區域。 使用兩個區域以實現更高的可用性。 其中一個是主要區域。 另一個則用於容錯移轉。

  • Azure 流量管理員流量管理員會將連入要求路由傳送到其中一個區域。 正常作業期間,它會將要求路由傳送到主要區域。 如果該區域變得無法使用,流量管理員就會容錯移轉到次要區域。 如需詳細資訊,請參閱流量管理員設定

  • 資源群組。 分別針對主要區域與次要區域建立資源群組。 這可讓您彈性地將每個區域當作單一資源集合來管理。 例如,您可以重新部署某一個區域,而不需拿掉另一個區域。 連結資源群組,如此一來,您就能執行查詢,以列出應用程式的所有資源。

  • 虛擬網路。 針對每個區域建立不同的虛擬網路。 確定位址空間並未重疊。

  • SQL Server Always On 可用性群組。 如果您使用 SQL Server,我們建議使用 SQL Always On 可用性群組來獲得高可用性。 建立單一可用性群組,以包含這兩個區域中的 SQL Server 執行個體。

  • VNET 對 VNET VPN 連線。 由於 Azure Stack Hub 上尚未提供 VNET 對等互連,請使用 VNET 對 VNET VPN 連線來連接兩個 VNET。 如需詳細資訊,請參閱 Azure Stack Hub 中的 VNET 對 VNET

建議

多區域架構可以提供比部署到單一區域更高的可用性。 如果區域中斷會影響主要區域,您可以使用流量管理員容錯移轉到次要區域。 如果應用程式的個別子系統失敗,此架構也可以提供協助。

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

  • 搭配熱待命的主動/被動。 流量會傳送到其中一個區域,而另一個區域會以熱待命模式等候。 熱待命表示次要區域中隨時都已配置 VM 且正在執行中。

  • 搭配冷待命的主動/被動。 流量會傳送到其中一個區域,而另一個區域會以冷待命模式等候。 冷待命表示在需要容錯移轉之前,不會在次要區域中配置 VM。 此方式的執行成本較小,但在失敗發生時通常需要較久的時間才能上線。

  • 主動/主動。 兩個區域均為主動,而且要求會在它們之間負載平衡。 如果其中一個區域變成無法使用,就會將它從輪替中剔除。

此參考架構著重於搭配熱待命的主動/被動,使用流量管理員進行容錯移轉。 您可以部署少量的 VM 來進行熱待命,然後視需要相應放大。

流量管理員設定

設定流量管理員時,請考慮下列各點:

  • 路由。 流量管理員支援數個路由演算法。 針對本文所述的案例,請使用「優先順序」路由 (先前稱為「容錯移轉」路由)。 使用此設定,流量管理員會將所有要求傳送到主要區域,除非主要地區變成無法連線。 那時,就會自動容錯移轉到次要區域。 請參閱設定容錯移轉路由方法

  • 健康情況探查。 流量管理員會使用 HTTP (或 HTTPS) 探查來監視每個區域的可用性。 探查會針對指定的 URL 路徑檢查 HTTP 200 回應。 最佳作法是,建立端點來報告應用程式的整體健康情況,並使用此端點進行健康情況探查。 否則,探查可能會在應用程式的關鍵組件真的失敗時報告端點狀況良好。 如需詳細資訊,請參閱健康情況端點監視模式 \(部分機器翻譯\)。

當流量管理員容錯移轉時,用戶端會有一段時間無法連線到應用程式。 持續時間受到下列因素影響:

  • 健康情況探查必須偵測到主要區域已變成無法連線。

  • 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 externalEndpoints --priority 3

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

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

依據容錯移轉的原因而定,您可能需要重新部署區域內的資源。 容錯回復之前,請執行操作性整備測試。 測試應該確認如下的事項:

  • VM 已正確設定 (已安裝所有必要的軟體,IIS 正在執行等設定)。

  • 應用程式子系統均狀況良好。

  • 功能測試 (例如,資料庫層可從 Web 層連線)。

設定 SQL Server Always On 可用性群組

在 Windows Server 2016 之前,SQL Server Always On 可用性群組需要一個網域控制站,而且可用性群組中的所有節點都必須位於相同的 Active Directory (AD) 網域。

設定可用性群組:

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

  • 為每個網域控制站提供一個靜態 IP 位址。

  • 建立 VPN,以啟用兩個虛擬網路之間的通訊。

  • 針對每個虛擬網路,將網域控制站的 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 執行個體。 如需相關步驟,請參閱將 Always On 可用性群組擴充到遠端 Azure 資料中心 (PowerShell) \(英文\)。

    • 將主要複本放置於主要區域。

    • 將一或多個次要複本放置於主要區域。 設定這些來使用具有自動容錯移轉的同步認可。

    • 將一或多個次要複本放置於次要區域。 基於效能考量,設定這些來使用「非同步」認可 (否則,所有的 T-SQL 交易都必須等候透過網路到次要區域的來回行程)。

注意

非同步認可複本不支援自動容錯移轉。

可用性考量

使用複雜的多層式架構應用程式,您可能不需要在次要區域中複寫整個應用程式, 而是可能只需複寫支援商務持續性所需的關鍵子系統。

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

對於 SQL Server 叢集,有兩個要考慮的容錯移轉案例:

  • 主要區域中的所有 SQL Server 資料庫複本都失敗。 例如,這可能會在區域中斷期間發生。 在該情況下,您必須手動容錯移轉可用性群組,即使流量管理員會在前端自動容錯移轉。 請依照執行 SQL Server 可用性群組的強制手動容錯移轉,其中描述如何使用 SQL Server 2016 中的 SQL Server Management Studio、Transact-SQL 或 PowerShell 執行強制容錯移轉。

    警告

    使用強制容錯移轉,會有資料遺失的風險。 當主要區域再次上線之後,請取得資料庫的快照集,然後使用 tablediff 來找出差異。

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

    1. 將次要區域中的 SQL Server 資料庫複本暫時切換到「同步」認可。 這確保在容錯移轉期間將不會遺失資料。

    2. 容錯移轉到該複本。

    3. 當您容錯回復到主要區域時,還原非同步認可設定。

管理性考量

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

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

  • 關閉 VM 執行個體。

  • 壓力資源,例如 CPU 和記憶體。

  • 中斷連線/延遲網路。

  • 毀損程序。

  • 憑證到期。

  • 模擬硬體故障。

  • 關閉網域控制站上的 DNS 服務。

測量復原時間,並確認它們符合您的業務需求。 此外,也需測試失敗模式組合。

後續步驟