多區域網路設計

本文說明如何設計跨越多個區域的 Azure 網路。 多區域網路可在發生區域性中斷時提供高可用性，為地理上分散的使用者提供較低延遲的服務，並支援法規對資料駐留的要求。

本文涵蓋的內容

本文涵蓋了區域與區域備援、跨區域路由策略、多區域部署的中樞拓撲選擇、主動-主動與主動-被動容錯轉模式以及複寫延遲考慮因素。

誰需要這篇文章

如果你的環境符合以下任何條件，請閱讀這篇文章：

• 你的工作負載需要針對全面 Azure 區域故障進行災難復原保護。
• 你服務於多個地區的用戶，需要盡量減少網路延遲。
• 法規或合規要求資料必須限制在特定的地理範圍內。
• 您的業務持續性目標定義了一個復原時間目標（RTO），單一區域無法單獨達成。

如果你的工作負載只在單一區域運作，且區域冗餘部署符合可用性需求，你可能還不需要多區域設計。 先從一個區域的樞紐輻射拓撲或 Virtual WAN 開始，之後再擴展。

Azure 服務與功能

下表列出了實現多區域網路的 Azure 服務與功能：

為什麼多區域需要多個虛擬網路

虛擬網路（VNet）跨越單一區域。 該 VNet 內的子網涵蓋該區域所有可用區域，但 VNet 本身無法跨越區域邊界延伸。 因此，多區域網路意味著部署多個VNet，每個區域一個或多個，並以跨區域服務連接。

這個基本限制塑造了每一個多區域設計：

• 每個區域需要自己的 VNet 位址空間（不與其他區域重疊以便對等）。
• 跨區域流量需要明確指定的連線機制：全域 VNet 對等互連、Virtual WAN 中樞間互連，或以閘道為基礎的路由。
• 全球負載平衡服務（Traffic Manager 或 Front Door）會引導使用者前往正確的區域部署。

關於子網與位址規劃的指引，請參見 IP 位址規劃。

可用性區域與區域冗餘

在設計多區域拓撲之前，請了解 Azure 中基礎設施冗餘的兩層級：

先從區域冗餘開始。 區域冗餘部署能防範最常見的故障情境（單一資料中心問題），且無需多區域路由的複雜性。 當您的企業需要防範區域性中斷，或需要服務地理分散的使用者時，請加入區域冗餘。

區域冗餘網路服務參考

下表顯示核心網路服務的區域冗餘部署選項。 在您執行工作負載的每個區域部署這些：

如何選擇跨區域流量路由方式

請使用以下決策表來選擇適合區域間流量路由的服務：

如何選擇多區域樞紐拓撲

當你決定跨區域擴展網路後，請選擇一個管理跨區域連接的樞紐模式：

欲詳細比較單一區域中樞紐輻射與Virtual WAN，請參見樞紐輻射拓撲與Virtual WAN。

設計考量

先決條件

在設計多區域網路前，請確保你具備：

• 部署並測試了單一區域拓撲。 可以從 中樞與輪輻 或 Virtual WAN 開始。
• 定義高可用性與災難復原需求：RTO、復原目標（RPO）及合規要求。
• 建立了跨所有區域的不重疊 IP 位址計畫。 請參見 IP 位址規劃。
• 辨識哪些工作負載需要區域冗餘，哪些工作負載僅需區域冗餘。

主動-主動部署模式與主動-被動部署模式

您的多區域部署模型決定了正常運作及區域故障時的流量流動：

Active-active

兩個區域同時服務交通。 全域負載平衡器，如 Traffic Manager 或 Front Door，會根據距離、效能或權重在不同區域間分配請求。

何時使用主動-主動式：

• 你的應用程式可以在不依賴特定區域狀態相依性的情況下，處理任何區域中的請求。
• 您需要最低的 RTO (容錯移轉是即時的，因為健康區域已經在處理流量)。
• 你希望在正常運作時同時使用兩個區域的容量（以提升成本效益）。

人脈考量：

• 兩個區域必須擁有相同的網路基礎設施，包括防火牆、閘道器和負載平衡器。
• 區域間的資料複製必須保持兩種部署的即時性。
• DNS 的 TTL 與健康探測間隔決定 Traffic Manager 轉移流量的速度。 Front Door 提供更快的連線層級故障轉移。

Active-passive

一個區域（主要區域）負責處理所有流量。 次要區域保持準備就緒，但直到故障轉移事件前不會處理使用者請求。

何時使用主動-被動：

• 你的應用程式有嚴格的寫入區域要求，或者無法輕易複製狀態。
• 成本限制無法同時在兩個區域全容量運轉。
• 你的 RTO 可容忍範圍可涵蓋啟用次要區域所需的時間。

人脈考量：

• 被動區域的網路基礎架構可在故障轉移前使用較小的分層或降低容量。
• 自動容錯移轉需要具備適當閾值的健全狀態探查 (避免震盪)。
• 定期測試容錯移轉。 若未驗證，被動區域的網路配置可能會漂移。
• 保持路由表和 NSG 規則在各區域間同步。 使用基礎設施即程式碼範本，確保被動區域與主要區域的安全態勢相符。
• 在被動區域預先配置 VPN 或 ExpressRoute 閘道器。 閘道器配置可能需要 20 至 45 分鐘。 這對大多數RTO目標來說太慢了。

在主動-主動與主動-被動網路間的選擇

主動-主動與主動-被動網路的選擇會影響網路規模、成本及營運複雜度：

資料複製與延遲

跨區域複製會引入影響應用程式設計的網路延遲。 同一地理範圍內的 Azure 區域，鄰近對（例如東美國到東美 2）的往返延遲通常為 1–10 毫秒，而遠距離對（例如東美國到西美國）則有 30–70 毫秒。 跨大西洋或跨太平洋的區域配對，延遲可能超過 100 毫秒。

主要設計考量：

• 複寫拓撲： 僅針對延遲低於 < 10 毫秒的區域對選用同步複寫。 針對遠距配對，請使用非同步複寫，以避免應用程式效能下降。
• 頻寬規劃：估算複寫輸送量需求，並將全域 VNet 對等互連的每 GB 資料傳輸成本納入考量。 遠距離區域間的高量複製會產生顯著的出口電荷。
• 衝突解決： 具有雙向寫入的主動-主動模式需要在應用程式層或資料庫層執行衝突解決策略。 網路提供連線，但應用程式必須處理寫入衝突。
• 用於 PaaS 複寫的私有端點：在跨區域複製 Azure SQL、Cosmos DB 或 Storage 時，請在每個區域使用私有端點，以保持複寫流量在 Microsoft 骨幹網路上，避免公開網路暴露。

成本考量

多區域網路透過重複基礎設施與跨區域資料傳輸增加成本。 請圍繞以下主要成本驅動因素規劃預算：

• 跨區域資料傳輸：全域 VNet 對等互連和虛擬 WAN 中樞間流量，對於跨越區域界限的資料會按每 GB 收費。 同一區域內對等 VNet 之間的區域內流量，對同一區域不需額外付費，跨區域則收費較低。
• 重複的網路設備： 每個區域都需要自己的防火牆、負載平衡器和閘道實例。 主動-主動式部署會讓這些成本加倍。 主動-被動部署可透過在待機區域使用較小的層級，並在容錯移轉時擴大規模來降低成本。
• 全球負載均衡費用： Traffic Manager 和 Front Door 都會根據 DNS 查詢或處理的請求收費。 Front Door 會另外針對從邊緣 PoP 傳輸至後端的資料傳輸收費。
• ExpressRoute 與 VPN 閘道：多區域設計通常需要在每個區域設置閘道實例。 連接多個地區的 ExpressRoute 電路會增加每月埠費及每 GB 計費數據費。
• 以流量區域性優化： 設計應用層級以減少跨區域通話。 將每個區域中的讀取複本與運算資源部署在同一區域，以降低複寫頻寬需求，並減少延遲敏感型查詢的延遲。

安全性考慮

多區域網路引入了超越單一區域部署的安全考量：

• 流量則保留在 Microsoft 骨幹網路上。 所有透過全域 VNet 對等互連或 Virtual WAN 集線器之間連線的跨區域流量，都會經由 Microsoft 骨幹網路，而非公用網際網路。
• 在每個區域部署區域冗餘防火牆。 每個區域樞紐都需要自己的防火牆實例來進行流量檢查。 在可用區域部署防火牆，以在區域故障時保持安全。
• Front Door WAF 提供邊緣安全性。 使用 Front Door 時，其整合的 Web 應用程式防火牆 會在流量抵達任何區域部署前進行檢查。 這在網路邊緣提供了第一層防禦。
• 謹慎規劃 DNS 故障轉移。 流量管理員的容錯移轉依賴於 DNS TTL。 較短的 TTL 可以加快備援速度，但會增加 DNS 查詢量。 Front Door 提供連線層級的容錯移轉，且不取決於用戶端 DNS 快取是否到期。
• ExpressRoute Global Reach 的流量保持私密狀態。 透過 Global Reach 連接的本地站點之間的流量，絕不會觸及公共網際網路。 它會留在 Microsoft 的主幹網路上，介於電路之間。
• 保護跨區域複製通道。 透過全域 VNet 對等互連傳輸的後端複寫流量預設為私人，但對於傳輸中的敏感資料，請套用網路安全群組並加密保護。

相關文章

如果你的多區域設計涉及本指南其他地方涵蓋的特定情境，請參見：

• 中樞輪輻拓撲：多區域部署的中樞設計模式。
• Virtual WAN：具備自動集線器間路由的 Virtual WAN 多集線器模式。
• 跨區域連線：詳細說明對等互連、Global Reach 及樞紐間連線選項。
• VNet 與子網：以區域為單位設計與子網規劃。
• IP 位址規劃：跨區域不重疊的位址空間。
• Azure 防火牆 與流量檢查：在每個區域樞紐部署區域冗餘防火牆。

瞭解更多資訊

欲了解更多本文所討論的服務與概念，請參閱以下資源：

• 流量管理器概述
• Azure Front Door 概觀
• 虛擬網路對等互連概觀
• ExpressRoute 全球覆蓋範圍
• Virtual WAN 全球運輸網路架構
• Azure 區域與可用性區域

下一步