此參考架構會顯示一組經過證實的做法，可在多層式應用程式多個 Azure Stack Hub 區域之間執行，以達到可用性和健全的災害復原基礎結構。 在本檔中，流量管理員可用來達到高可用性，不過，如果流量管理員不是您環境中的慣用選擇，也可以使用一組高可用性負載平衡器來替代。
注意
請注意，下列架構中使用的流量管理員必須在 Azure 中設定，而且用來設定流量管理員配置檔的端點必須是可公開路由傳送的 IP。
建築
此架構是以 SQL Server 多層式應用程式中所示的架構為基礎。
主要和次要區域。 使用兩個區域來達到更高的可用性。 一個是主要區域。 另一個區域是用於故障轉移。
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 以進行熱待命，然後視需要相應放大。
流量管理員設定
設定流量管理員時，請考慮下列幾點：
路由。 流量管理員支援數種 路由演算法，。 針對本文所述的案例，請使用 優先順序 路由（先前稱為 故障轉移 路由）。 使用此設定時，流量管理員會將所有要求傳送至主要區域，除非主要區域變得無法連線。 在那個時候，它會自動切換至次要區域。 請參閱 設定故障轉移路由方法。
健康檢測。 流量管理員會使用 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 實例。 如需步驟，請參閱 將 AlwaysOn 可用性群組擴充至遠端 Azure 資料中心 （PowerShell）。
將主副本放在主要區域中。
將一或多個次要複本放在主要區域內。 設定這些以使用同步提交及自動故障轉移。
將一或多個次要複本放在次要區域中。 基於效能考慮，請將這些設定為使用 異步 提交。 （否則，所有 T-SQL 交易都必須等候透過網路往返至次要區域。
注意
非同步提交複本不支援自動故障轉移。
可用性考慮
使用複雜的多層式應用程式，您可能不需要在次要地區中複製整個應用程式。 相反地，您可能只復寫支援商務持續性所需的重要子系統。
流量管理器是系統中可能的故障點。 如果流量管理員服務失敗，用戶端就無法在停機期間存取您的應用程式。 檢閱 流量管理員 SLA，並判斷單獨使用流量管理員是否符合高可用性的商務需求。 如果沒有，請考慮新增另一個流量管理解決方案作為備援。 如果 Azure 流量管理員服務失敗，請將 DNS 中的 CNAME 記錄變更為指向其他流量管理服務。 （此步驟必須手動執行，而且在傳播 DNS 變更之前，您的應用程式將無法使用。
針對 SQL Server 叢集，有兩個故障轉移案例需要考慮：
主要區域中的所有 SQL Server 資料庫複本都會失敗。 例如，這可能會在區域性中斷期間發生。 在此情況下，即使 Traffic Manager 在前端自動進行故障轉移，您仍然必須手動故障轉移可用性群組。 請遵循 執行 SQL Server 可用性群組的強制手動故障轉移中的步驟，其中說明如何在 SQL Server 2016 中使用 SQL Server Management Studio、Transact-SQL 或 PowerShell 來執行強制故障轉移。
警告
使用強制故障轉移時，有資料遺失的風險。 一旦主要區域重新上線，請擷取資料庫的快照，並使用 tablediff 查找差異。
流量管理員故障轉移至次要區域，但主要 SQL Server 資料庫複本仍可供使用。 例如，前端層可能會失敗，而不會影響 SQL Server VM。 在此情況下，因特網流量會路由傳送至次要區域，而且該區域仍可連線到主要複本。 不過，延遲將會增加，因為 SQL Server 連線會跨區域。 在此情況下，您應該執行手動故障轉移，如下所示：
暫時將次要區域中的 SQL Server 資料庫複本切換為 同步 認可。 這可確保在故障轉移期間不會遺失數據。
故障轉移至該複本。
當您切換回主要區域時，請恢復非同步認可設定。
管理性考慮
當您更新部署時，請一次更新一個區域，以減少因應用程式設定不正確或錯誤而發生全域失敗的機會。
測試系統對失敗的復原能力。 以下是一些要測試的常見失敗案例：
關閉 VM 實例。
壓力資源，例如 CPU 和記憶體。
中斷連線/延遲網路。
當機處理程序。
憑證過期。
模擬硬體錯誤。
關閉域控制器上的 DNS 服務。
測量復原時間，並確認它們符合您的商務需求。 測試失敗模式的組合。
後續步驟
- 若要深入瞭解 Azure 雲端模式，請參閱 雲端設計模式。