本文說明在 Azure 中部署一組網路虛擬裝置 （NVA） 以取得高可用性的常見方式。 NVA 通常會控制具有不同安全性層級的網路區段之間的流量流程。 例如，您可以使用周邊網路虛擬網路與公用因特網之間的 NVA，或透過虛擬專用網 （VPN） 或軟體定義的 WAN （SD-WAN） 設備將外部位置連線到 Azure。
本文假設您已基本瞭解 Azure 網路、 Azure 負載平衡器、 虛擬網路流量路由，以及使用者定義的路由（UDR）。
許多設計模式都會使用 NVA 來檢查不同安全性區域之間的流量。 這些模式可能會針對下列用途使用 NVA：
檢查虛擬機到因特網的輸出流量，並防止數據外流。
檢查從因特網到虛擬機的輸入流量，並防止攻擊。
若要在 Azure 中篩選虛擬機之間的流量，以防止受入侵系統進行橫向移動。
若要篩選內部部署系統與 Azure 虛擬機之間的流量，特別是當它們屬於不同的安全性層級時。 例如，Azure 會裝載周邊網路，而內部部署環境則裝載內部應用程式。
若要從外部位置終止 VPN 或 SD-WAN 通道，例如內部部署網路或其他公用雲端。
您可以使用本文中的模式，將下列 NVA 新增至 Azure 設計：
- 網路防火牆
- 第 4 層反向代理
- 因特網通訊協定安全性 （IPsec） VPN 端點
- SD-WAN 家電
- 具有 Web 應用程式防火牆功能的 Web 型反向 Proxy
- 網路代理限制 Azure 存取的網頁
- 第 7 層負載平衡器
Azure 原生 NVA，例如 Azure 防火牆 和 Azure 應用程式閘道，使用本文稍後說明的設計。 您應該從設計觀點和網路疑難解答目的了解這些選項。
NVA 通常需要高可用性，因為它們可控制網路區段之間的通訊。 如果 NVA 變成無法使用，網路流量就無法流動，應用程式會停止運作。 計畫性與非計畫性的停機偶爾會關閉 NVA 實例，這類情況類似於發生在 Azure 或其他雲端服務中的虛擬機器。 即使您使用 Azure 進階 SSD 進行設定，NVA 實例仍可能會關閉，這會在 Azure 中提供單一實例服務等級協定。 高可用性應用程式至少需要兩個 NVA，以協助確保連線能力。
當您選擇將 NVA 部署到 Azure 虛擬網路的最佳選項時，最重要的層面是 NVA 廠商是否已評估並驗證其設計。 廠商也必須提供必要的 NVA 設定，才能將 NVA 整合到 Azure。 如果 NVA 廠商提供多個支援的設計選項，請考慮下列因素來做出決策：
聚合時間：每個設計重新引導流量以避開失敗的 NVA 實例所需的時間
拓撲支援： 每個設計選項支援的 NVA 組態，例如主動/主動、主動/待命，或具有額外備援單位的向外延展 NVA 叢集
流量對稱： 特定設計是否強制 NVA 在封包上執行來源網路位址轉換 （SNAT），以避免非對稱式路由，或者設計是否以其他方式強制執行流量對稱
備註
本文著重於 中樞和輪輻設計。 本文並未涵蓋 Azure 虛擬 WAN，因為它提供更具規範性的指導方針來配置 NVA，這取決於虛擬 WAN 中樞是否可以支援特定的 NVA。 如需詳細資訊，請參閱 虛擬 WAN 中樞中的 NVA。
下列各節說明可用來將 NVA 整合到中樞和輪輻網路的常見架構。
高可用性架構概觀
| 解決方法 | 優點 | 考慮事項 |
|---|---|---|
| Azure Load Balancer | 此解決方案支持主動/主動和主動/待命設定，以及具有良好聚合時間的向外延展 NVA。 | NVA 必須提供健康情況探查的埠，特別是作用中/待命部署。 對於需要流量對稱的有狀態設備，例如防火牆，與網際網路之間的流量往返都需要使用 SNAT。 |
| Azure 路由伺服器 | NVA 必須支持邊界閘道協定 （BGP）。 此解決方案支持主動/主動、主動/待命，以及向外延展 NVA。 | 流量對稱需要此解決方案中的 SNAT。 |
| Azure 閘道負載平衡器 | 不使用 SNAT 時，流量對稱性可獲得保證。 NVA 可以跨租用戶共用。 此解決方案具有良好的聚合時間，並支持主動/主動、主動/待命，以及向外延展 NVA。 | 此解決方案支援進出網際網路的流量，且不支援 East-West 流量。 |
| 動態私人IP位址和UDR | NVA 不需要特殊功能。 此解決方案可保證對稱流量。 | 此解決方案僅適用於主動/被動設計。 它的聚合時間很高，為一到兩分鐘。 |
負載均衡器
Load Balancer 設計會使用兩個 Azure 負載平衡器，將 NVA 叢集公開至網路的其餘部分。 這種方法適用於有狀態和無狀態的網路虛擬設備（NVA）。
內部負載平衡器會將內部流量從 Azure 和內部部署重新導向至 NVA。 此內部負載平衡器會設定高可用性埠規則，以便將每個傳輸控制通訊協定 (TCP) 和用戶數據報通訊協定 (UDP) 埠轉送到 NVA 實例。
公用負載平衡器會將 NVA 公開至因特網。 高可用性埠適用於輸入流量，因此必須在專用負載平衡規則中開啟每個 TCP/UDP 埠。
下圖顯示封包從網際網路到輻射虛擬網路中應用伺服器的跳躍序列。 這些封包通過防火牆 NVA 來控制進出公用互聯網的流量，也稱為 North-South 流量。
下載此架構的 Visio 檔案。
若要透過 NVA 將輪輻的流量傳送至公用因特網，此設計會使用 UDR 作為 0.0.0.0/0。 下一個躍點是內部負載平衡器的IP位址。
針對 Azure 與公用因特網之間的流量，流量流程的每個方向都會跨越不同的 Azure 負載平衡器。 即使防火牆 NVA 有公用和內部網路的單一網路介面卡 （NIC），因為輸入封包通過公用 Azure 負載平衡器，而輸出封包會通過內部 Azure 負載平衡器，也會發生此程式。 流量的雙向都會經過不同的負載平衡器。 因此，如果您需要流量對稱，NVA 實例必須執行 SNAT 來吸引傳回流量，並確保流量對稱。 大部分防火牆都需要流量對稱。
下圖展示如何使用相同的負載平衡器設計，以檢查 Azure 與內部部署網路之間的流量，或 East-West 流量，這僅涉及內部負載平衡器。 您也可以使用此方法，透過 NVA 在輪輻之間傳送流量。
在上圖中，spoke1 不知道 spoke2 的範圍。 因此，UDR 會將要前往端點2 的流量傳送至 NVA 的內部 Azure 負載平衡器。
針對內部部署網路與 Azure 之間的流量，或 Azure 虛擬機之間的流量，內部 Azure 負載平衡器會保證單一 NIC NVA 中的流量對稱性。 當流量的雙向都經過相同的 Azure 負載平衡器時，負載平衡器會選擇相同的 NVA 實例來處理雙向流量。 如果雙 NIC NVA 設計具有每個通訊方向的內部負載平衡器，SNAT 可確保流量對稱。 上一個 North-South 圖表提供此設計的範例。
在此設計中，雙 NIC NVA 必須判斷將回復傳送至負載均衡器健康檢查的位置。 Load Balancer 一律會使用與健康情況檢查來源相同的 IP 位址，也就是 168.63.129.16。 NVA 必須透過收到的相同介面，將這些健康情況檢查回應傳回。 此過程通常需要作業系統中的多個路由表，因為基於目的地的路由會通過相同的網卡傳送回覆。
Azure 負載平衡器在個別 NVA 中斷時有良好的聚合時間。 您可以每隔五秒傳送一次健康情況探查，而且需要三次失敗的探查才能宣告後端實例停止服務。 因此，Azure 負載平衡器通常需要 10 到 15 秒的時間，才能將流量聚合至不同的 NVA 實例。
此設定同時支持主動/主動和主動/待命組態。 針對作用中/待命組態，NVA 實例必須提供 TCP 或 UDP 埠，或只回應目前作用中角色中實例之負載平衡器健康情況探查的 HTTP 端點。
第 7 層負載平衡器
安全性應用裝置的特定設計會將 Azure 公用負載平衡器取代為第 7 層負載平衡器，例如 Azure 應用程式閘道，這可視為 NVA 本身。
在此場景中，NVA 只需要一個內部負載平衡器來處理來自工作負載系統的流量。 Dual-NIC 裝置有時會使用這種方法來避免 Azure 負載平衡器健全性檢查的路由問題。 此設計僅支援第 7 層負載平衡器支援的第 7 層通訊協定，通常是 HTTP 和 HTTPS。
NVA 應該處理第 7 層負載平衡器不支援的通訊協定輸入流量。 NVA 也可能處理輸出流量。 如需詳細資訊，請參閱 虛擬網路的防火牆和應用程式網關。
路由伺服器
路由伺服器 是一項服務，可讓 NVA 透過 BGP 與 Azure 軟體定義網路互動。 NVA 會瞭解 Azure 虛擬網路中存在哪些 IP 位址前綴。 它們也可以在 Azure 中虛擬機的有效路由表中插入路由。
在上圖中，每個 NVA 實例都會透過 BGP 連線到路由伺服器。 此設計在分支子網路中不需要路由表，因為路由伺服器會設定 NVA 公告的路由。 如果 Azure 虛擬機器中有兩個或多個路由進行程式設計，則會使用相等成本的多路徑路由，為每個流量選擇其中一個 NVA 實例。 因此，如果您需要流量對稱，則必須在此設計中包含 SNAT。
這個插入方法同時支持主動/主動和主動/待命組態。 在作用中/主動設定中，所有 NVA 都會向路由伺服器公告相同的路由。 在主動/待命配置中，其中一個 NVA 會以比另一個更短的自治系統（AS）路徑來宣告路由。 路由伺服器最多支援八個 BGP 相鄰。 因此，如果您使用主動 NVA 的向外延展叢集，此設計最多支援八個 NVA 實例。
此設定具有快速的聚合時間。 BGP 相鄰的 keepalive 和 holdtime 定時器會影響聚合時間。 路由伺服器的預設保留定時器設定為 60 秒，而保留時間定時器設定為 180 秒。 但在 BGP 相鄰建立期間，NVA 可以談判較低的定時器。 設定這些定時器太低可能會導致 BGP 不穩定。
此設計適用於需要與 Azure 路由互動的 NVA。 範例包括 SD-WAN 或 IPsec NVA，通常具有良好的 BGP 支援。 這些 NVA 必須瞭解在 Azure 虛擬網路中設定的前置詞，或透過 ExpressRoute 私人對等互連公告特定路由。 這些類型的設備通常是無狀態的，因此流量對稱不是問題，而且不需要 SNAT。
閘道負載平衡器
網關負載平衡器 提供了一種在數據路徑中插入網路虛擬設備 (NVA) 的方法，而無需使用 UDR 來進行流量路由。 對於透過 Azure 負載平衡器或公用 IP 位址公開其工作負載的虛擬機，您可以透明地將輸入和輸出流量重新導向至位於不同虛擬網路中的 NVA 叢集。 下圖顯示，當工作負載透過 Azure 負載平衡器公開應用程式時，來自公共互聯網的入站流量數據包所遵循的路徑。
此 NVA 插入方法提供下列優點：
此方法不需要 SNAT 來保證流量對稱。
您可以使用相同的 NVA 來檢查來自和前往不同虛擬網路的流量，從 NVA 的角度提供多租戶功能。
NVA 虛擬網路與工作負載虛擬網路之間不需要虛擬網路對等互連，可簡化設定。
工作負載虛擬網路中不需要UDR，這也簡化了設定。
您可以透過閘道 Load Balancer 使用服務插入，將流量輸入至 Azure 公用負載平衡器、其傳回流量，以及來自 Azure 的輸出流量。 East-West Azure 虛擬機之間的流量無法使用閘道負載平衡器進行 NVA 插入。
在 NVA 叢集中，Azure 負載平衡器健康情況檢查探查會偵測個別 NVA 實例中的失敗，可提供 10 到 15 秒的快速聚合時間。
動態公用IP位址和UDR管理
此設計的目標是要有一個沒有 NVA 備援功能的設定，而且如果 NVA 遇到停機，則可以加以修改。 下圖顯示 Azure 公用 IP 位址如何與使用中的 NVA（圖中的 NVA1）產生關聯。 分支中的 UDR 使用運作中的 NVA 的 IP 位址（10.0.0.37）作為下一跳。
如果主動 NVA 變得無法使用，待命 NVA 會呼叫 Azure API 來重新映射公用 IP 位址和將輪輻 UDR 重新映射到自身，或是接手私人 IP 位址。 這些 API 呼叫可能需要幾分鐘的時間才能生效。 此設計是本文所有選項中聚合時間最差的。
此設計僅支援作用中/待命組態，這可能會導致延展性問題。 如果您需要增加 NVA 支援的頻寬，您必須提升這兩個實例的規模。
此設計不需要 SNAT 保證流量對稱，因為在任何指定時間只有一個 NVA 處於作用中狀態。
貢獻者們
本文由 Microsoft 維護。 下列參與者撰寫本文。
主要作者：
- Keith Mayer |主要雲端解決方案架構師
- Telmo Sampaio |Principal Service Engineering Manager
- 何塞·莫雷諾 |首席工程師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。