本文說明在 Azure 中部署一組網路虛擬裝置 （NVA） 以取得高可用性的最常見選項。 NVA 通常用於控制以不同安全性層級分類的網路區段之間的流量流量，例如，在非軍事化區域 （DMZ） 虛擬網絡 和公用因特網之間。
有一些設計模式，其中 NVA 可用來檢查不同安全性區域之間的流量，例如：
- 檢查虛擬機到因特網的輸出流量，並防止數據外流。
- 檢查從因特網到虛擬機的輸入流量，並防止攻擊。
- 若要篩選 Azure 中虛擬機之間的流量，以避免橫向移動遭入侵的系統。
- 若要篩選內部部署系統與 Azure 虛擬機之間的流量，如果它們被視為屬於不同的安全性層級。 （例如，如果 Azure 裝載 DMZ，以及內部部署應用程式。）
NVA 有許多範例，例如網路防火牆、第 4 層反向 Proxy、IPsec VPN 端點、具有 Web 應用程式防火牆功能的 Web 型反向 Proxy、因特網 Proxy 來限制可從 Azure 存取哪些因特網頁面、第 7 層負載平衡器，以及其他許多專案。 它們全都可以插入 Azure 設計，其中包含本文所述的模式。 即使是 Azure 第一方網路虛擬設備，例如 Azure 防火牆 和 Azure 應用程式閘道 也會使用本文稍後說明的設計。 從設計觀點以及針對網路問題進行疑難解答時，了解這些選項非常重要。
要回答的第一個問題是為什麼需要網路虛擬設備高可用性。 原因是這些裝置控制網路區段之間的通訊。 如果無法使用，網路流量就無法流動，而且應用程式將會停止運作。 排程和未排程的中斷偶爾會關閉 NVA 實例（如同 Azure 或任何其他雲端的任何其他虛擬機）。 即使這些 NVA 已設定為 進階版 受控磁碟，以在 Azure 中提供單一實例 SLA，也會關閉實例。 因此，高可用性應用程式至少需要第二個 NVA，以確保連線能力。
必要條件：本文假設對 Azure 網路、Azure Load Balancer 和 虛擬網絡 流量路由 （UDR） 有基本的瞭解。
選擇將網路虛擬設備部署到 Azure VNet 的最佳選項時，最重要的層面是 NVA 廠商是否已審查並驗證該特定設計。 廠商也必須提供在 Azure 中整合 NVA 所需的必要 NVA 組態。 如果 NVA 廠商提供不同的替代方案作為 NVA 支援的設計選項，這些因素可能會影響決策：
- 聚合時間：每個設計需要多久的時間才能將流量從失敗的 NVA 實例移開？
- 拓撲支援：每個設計選項都支援哪些 NVA 設定？ 主動/主動、主動/待命、具有 n+1 備援的向外延展 NVA 叢集？
- 流量對稱：特定設計是否強制 NVA 在封包上執行來源網路位址轉換 （SNAT），以避免非對稱路由？ 還是以其他方式強制執行流量對稱？
檔中的下列各節將說明將 NVA 整合到中樞和輪輻網路的最常見架構。
注意
本文著重於 中樞和輪輻設計。 虛擬 WAN 並未涵蓋，因為虛擬 WAN 對於 NVA 的部署方式更為規範，取決於虛擬 WAN 中樞是否支援特定的 NVA。 如需詳細資訊，請參閱 虛擬 WAN 中樞 的網路虛擬設備。
HA 架構概觀
下列架構描述高可用性 NVA 所需的資源和設定：
| 解決方案 | 優點 | 考量 |
|---|---|---|
| Azure Load Balancer | 支持主動/主動、主動/待命和向外延展 NVA。 非常好的聚合時間 | NVA 必須提供健康情況探查的埠，特別是作用中/待命部署。 從因特網到因特網的流程需要 SNAT 才能對稱 |
| Azure 路由伺服器 | NVA 需要支援 BGP。 支持主動/主動、主動/待命和向外延展 NVA。 | 流量對稱需要 SNAT |
| 閘道負載平衡器 | 保證沒有 SNAT 的流量對稱性。 NVA 可以跨租用戶共用。 非常好的聚合時間。 支持主動/主動、主動/待命和向外延展 NVA。 | 支援從因特網來回流動，不支援東西系流程 |
| 變更 PIP/UDR | NVA 不需要特殊功能。 保證對稱流量 | 僅適用於主動/被動設計。 1-2 分鐘的高聚合時間 |
Load Balancer 設計
此設計會使用兩個 Azure Load Balancer 將 NVA 叢集公開至網路的其餘部分：
- 內部 Load Balancer 可用來將內部流量從 Azure 和內部部署重新導向至 NVA。 此內部負載平衡器會使用 HA埠規則進行設定，以便將每個TCP/UDP埠重新導向至 NVA 實例。
- 公用 Load Balancer 會將 NVA 公開至因特網。 由於 HA埠 適用於輸入流量，因此每個個別的TCP/UDP埠都必須在專用負載平衡規則中開啟。
下圖描述從因特網到輪輻 VNet 中應用程式伺服器封包的躍點順序：
透過 NVA 將來自輪輻的流量傳送至公用因特網的機制，是一種使用者定義的路由，其 0.0.0.0/0 下一個躍點是內部 Load Balancer IP 位址的下一個躍點。
針對 Azure 與公用因特網之間的流量，流量流程的每個方向都會跨越不同的 Azure Load Balancer（透過公用 ALB 的輸入封包，以及透過內部 ALB 的輸出封包）。 因此，如果需要流量對稱，來源網路位址轉換 （SNAT） 必須由 NVA 實例執行，以吸引傳回流量並避免流量不對稱。
此設計也可用來檢查 Azure 與內部部署網路之間的流量：
透過 NVA 在輪輻之間傳送流量的機制完全相同，因此不會提供其他圖表。 在上述範例圖表中，由於 spoke1 不知道 spoke2 的範圍， 0.0.0.0/0 UDR 會將尋址至輪輻2 的流量傳送至 NVA 的內部 Azure Load Balancer。
針對內部部署網路與 Azure 或 Azure 虛擬機之間的流量，內部 Azure Load Balancer 會保證流量對稱：當流量流程的雙向周遊相同的 Azure Load Balancer 時，將會選擇相同的 NVA 實例。
當個別 NVA 中斷時，Azure Load Balancer 有非常好的聚合時間。 由於健康情況 探查可以每隔 5 秒傳送一次，而且需要 3 個失敗的探查 才能將後端實例宣告出服務，因此 Azure Load Balancer 通常需要 10-15 秒的時間，才能將流量聚合至不同的 NVA 實例。
此設定同時支持主動/主動和主動/待命組態。 不過，針對作用中/待命組態，NVA 實例必須提供 TCP/UDP 埠或 HTTP 端點，除非實例處於作用中角色，否則不會回應 Load Balancer 健康情況探查。
使用 L7 負載平衡器
此設計的特定案例是將 Azure 公用 Load Balancer 取代為第 7 層負載平衡器，例如 Azure 應用程式閘道（這可視為自己的 NVA）。 在此情況下，NVA 只會在它們前面要求內部 Load Balancer，因為來自 應用程式閘道 的流量會從 VNet 內部來源，且流量不對稱並不相關。
NVA 應該針對第 7 層負載平衡器不支援的通訊協議採用輸入流量，以及可能所有的輸出流量。 如需使用 Azure 防火牆 作為 NVA 和 Azure 應用程式閘道 作為第 7 層 Web 反向 Proxy 時，此組態的進一步詳細數據，請參閱虛擬網路的防火牆和 應用程式閘道。
Azure 路由伺服器
Azure 路由伺服器 是一項服務，可讓 NVA 透過邊界閘道通訊協定 （BGP） 與 Azure SDN 互動。 NVA 不僅會瞭解 Azure VNet 中存在的 IP 前置詞，還能在 Azure 中虛擬機的有效路由表中插入路由。
在上圖中，每個 NVA 實例都會透過 BGP 與 Azure 路由伺服器對等互連。 輪輻子網中不需要路由表，因為 Azure 路由伺服器會針對 NVA 公告的路由進行程序設計。 如果 Azure 虛擬機器中有兩個或多個路由進行程式設計，則會使用等價多重路徑 （ECMP） 為每個流量選擇其中一個 NVA 實例。 因此，如果流量對稱是需求，SNAT 就是此設計中必須的 。
此插入方法同時支援主動/主動（所有 NVA 都會向 Azure 路由伺服器公告相同的路由），以及作用中/待命（一個 NVA 會公告具有比另一個路徑較短的 AS 路徑的路由）。 Azure 路由伺服器最多支援 8 個 BGP 相鄰。 因此，如果使用主動 NVA 的向外延展叢集，此設計最多支援 8 個 NVA 實例。
此設定中的聚合時間相當快，而且會受到 BGP 相鄰的保留和保留時間定時器的影響。 雖然 Azure 路由伺服器具有預設 keepalive 和 holdtime 定時器（分別 60 秒和 180 秒），但 NVA 可以在 BGP 相鄰建立期間交涉較低的定時器。 設定這些定時器太低可能會導致 BGP 不穩定。
此設計是需要與 Azure 路由互動的 NVA 最常見的選項，例如需要瞭解 Azure VNet 中所設定前置詞的 VPN 終止 NVA，或透過 ExpressRoute 私人對等互連公告特定路由。
閘道負載平衡器
Azure 閘道負載平衡器 是將數據路徑中插入 NVA 的新方式，不需要使用使用者定義的路由引導流量。 對於透過 Azure Load Balancer 或公用 IP 位址公開其工作負載的 虛擬機器，輸入和輸出流量可以透明地重新導向至位於不同 VNet 中的 NVA 叢集。 下圖說明當工作負載透過 Azure Load Balancer 公開應用程式時，封包針對來自公用因特網的輸入流量所遵循的路徑：
此 NVA 插入方法的主要優點之一是來源網路位址轉換 （SNAT） 不需要保證流量對稱性。 此設計選項的另一個優點是，相同的 NVA 可用來檢查不同 VNet 的流量，從而從 NVA 的觀點達成多租使用者。 NVA VNet 與工作負載 VNet 之間不需要 VNet 對等互連，工作負載 VNet 中不需要使用者定義路由，這可大幅簡化設定。
網關 Load Balancer 的服務插入可用於達到 Azure 公用 Load Balancer 的輸入流量（及其傳回流量），以及源自 Azure 的輸出流程。 Azure 虛擬機之間的東西部流量無法利用閘道負載平衡器進行 NVA 插入。
在 NVA 叢集中，Azure Load Balancer 健康情況檢查探查將用來偵測個別 NVA 實例失敗，達到非常快速的聚合時間（10-15 秒）。
變更 PIP-UDR
此設計背後的概念是具有不需要 NVA 備援的設定，並在 NVA 發生停機時加以修改。 下圖顯示 Azure 公用 IP 位址如何與作用中的 NVA （NVA1） 相關聯，而輪輻中的使用者定義路由將作用中的 NVA IP 位址設為下一個躍點 （10.0.0.37）。
如果作用中的 NVA 變得無法使用，待命 NVA 會呼叫 Azure API 來重新對應公用 IP 位址和輪輻使用者定義路由本身（或移動私人 IP 位址）。 這些 API 呼叫可能需要幾分鐘的時間才能生效，這就是為什麼此設計提供本檔中所有選項最差的聚合時間。
此設計的另一個限制是只支援作用中/待命組態，這可能會導致延展性問題：如果您需要增加 NVA 支援的頻寬，此設計的唯一選項就是相應增加這兩個實例。
此設計的優點之一是不需要來源網路位址轉譯 （SNAT） 保證流量對稱性，因為在任何指定的時間點只有一個 NVA 作用中。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Keith Mayer |主要雲端解決方案架構師
- Telmo Sampaio |Principal Service Engineering Manager
若要查看非公用LinkedIn配置檔，請登入LinkedIn。