1、NSX軟件定義網絡POC測試方案目 錄 TOC o 1-3 1POC目的 PAGEREF _Toc7723777 h 32POC人員及職責 PAGEREF _Toc7723778 h 42.1人員分配 PAGEREF _Toc7723779 h 42.2職責劃分 PAGEREF _Toc7723780 h 43POC安排 PAGEREF _Toc7723781 h 63.1時間 PAGEREF _Toc7723782 h 63.2地點 PAGEREF _Toc7723783 h 63.3內容一覽表 PAGEREF _Toc7723784 h 63.4POC測試進度 PAGEREF _Toc77

2、23785 h 84POC測試環境 PAGEREF _Toc7723786 h 94.1測試場景 PAGEREF _Toc7723787 h 94.2環境搭建 PAGEREF _Toc7723788 h 105NSX基本功能驗證 PAGEREF _Toc7723789 h 165.1邏輯交換 PAGEREF _Toc7723790 h 165.1.1創建邏輯交換機 PAGEREF _Toc7723791 h 165.2邏輯路由 PAGEREF _Toc7723792 h 175.2.1配置并啟用分布式路由 PAGEREF _Toc7723793 h 185.2.2配置并啟用動態路由 PAGER

3、EF _Toc7723794 h 195.2.3動態路由通告和控制 PAGEREF _Toc7723795 h 215.3分布式防火墻 PAGEREF _Toc7723796 h 225.3.1修改防火墻默認規則 PAGEREF _Toc7723797 h 225.3.2基于安全組的防火墻規則 PAGEREF _Toc7723798 h 225.3.3基于身份的防火墻規則 PAGEREF _Toc7723799 h 245.3.4兩種防火墻的統一管理 PAGEREF _Toc7723800 h 246NSX可用性驗證 PAGEREF _Toc7723801 h 266.1.1NSX 控制器的可

4、用性 PAGEREF _Toc7723802 h 266.1.2高可用性 Edge服務網關 PAGEREF _Toc7723803 h 276.1.3等價多路徑（ECMP）提供的高可用驗證 PAGEREF _Toc7723804 h 297跨vCenter的交換與路由 PAGEREF _Toc7723805 h 327.1跨vCenter的邏輯交換 PAGEREF _Toc7723806 h 327.2跨vCenter的邏輯路由 PAGEREF _Toc7723807 h 348NSX高級功能驗證 PAGEREF _Toc7723808 h 408.1SSL VPN PAGEREF _Toc7

5、723809 h 408.2邏輯負載均衡 PAGEREF _Toc7723810 h 428.3VXLAN與VLAN之間的二層橋接 PAGEREF _Toc7723811 h 429測試結果匯總 PAGEREF _Toc7723812 h 4910縮略語解釋 PAGEREF _Toc7723813 h 52POC目的本測試的主要目的是為了協助公司更好的了解VMware的軟件定義網絡平臺NSX的架構及功能，驗證公司測試環境采用NSX網絡平臺實現軟件定義網絡的可行性。本測試主要對NSX進行如下幾個方面的測試。NSX一次性安裝基本功能測試邏輯交換邏輯路由分布式防火墻可用性驗證NSX控制器的可用性高可

6、用性Edge服務網關等價多路徑（ECMP）提供的可用性跨vCenter的交換與路由跨vCenter的邏輯交換跨vCenter的邏輯路由高級功能驗證SSL VPN邏輯負載均衡VXLAN與VLAN之間的橋接POC人員及職責人員分配測試由VMware合作伙伴公司與客戶共同完成，各方提供固定的測試人員和工程技術人員進行測試，根據測試計劃有步驟地進行測試工作。姓名職責單位名稱聯系電話郵件地址公司 XXX 測試項目負責人 XXX XXX技術工程師XXX客戶 XXX 客戶方技術負責人 XXX XXX技術工程師表：POC人員分配職責劃分參與測試單位參與人員職責XXX客戶XXXXXXXXX負責測試場地、服務器環

7、境、存儲環境、網絡環境準備；負責相關測試服務器的安裝、配置；負責檢查測試方案是否符合要求；檢查測試準備工作是否滿足測試的要求；與廠商共同測試；獨立監督測試過程，確認測試記錄、測試結果是否真實有效。VMware合作伙伴公司XXXXXXXXX負責編寫虛擬架構基本測試方案；負責提供VMware軟件產品及相關測試License；負責確認測試所用設備與VMware產品的兼容性；負責VMware虛擬架構軟件在服務器上的安裝與配置；負責協調測試過程中VMware相關問題的上訴解決；負責確認測試步驟符合VMware虛擬架構軟件最佳實踐規范。表：POC職責劃分POC安排 時間測試時間定于XXXX年X月XX日開始

8、，XXXX年X月XX日之前結束全部測試，并在XXXX年X月XXX日時提交最終的測試報告。地點 內容一覽表序號POC測試項目POC測試內容POC測試目標1NSX一次性安裝在物理主機上安裝部署NSX，并將一臺外圍獨立主機加入集群驗證NSX可以成功安裝，當向集群內添加主機時，不需要二次安裝，NSX組件可以自動進行部署2NSX基本功能驗證邏輯交換：創建邏輯交換機驗證NSX可以：1.高效便捷的創建邏輯交換機并在虛擬機之間轉發流量，可以橫跨物理第三層的邊界提供第二層連接邏輯路由：配置并啟動分布式路由配置并啟動動態路由動態路由通告和控制驗證NSX可以：1.創建分布式路由，該路由獨特的內核級分布式路由可減少“

9、發卡”式轉發2.在分布式路由器上啟用動態路由功能，該功能可以在邏輯空間中重現復雜的物理網絡拓撲3.OSPF動態路由可以在系統中更新和傳播分布式防火墻：修改防火墻默認規則創建安全組與訪問規則基于身份的防火墻規則Edge防火墻與分布式防火墻的統一管理驗證NSX 分布式防火墻可以：1. 修改防火墻規則并實現相應的訪問控制2.通過創建安全組與訪問規則實現訪問控制3.可以通過使用 Active Directory 組創建規則，并借此控制用戶對其他安全對象和其他安全組的訪問4.Edge服務網關防火墻和分布式防火墻可以統一管理3NSX可用性驗證NSX控制器的可用性高可用性Edge服務網關等價多路徑（ECMP

10、）提供的高可用驗證NSX可以提供如下的可用性：1.控制器具備高可用性2.Edge服務網關可以提供可用性3.等價多路徑可以提供高可用4跨vCenter的交換與路由跨vCenter的邏輯交換跨vCenter的邏輯路由驗證NSX可以實現跨vCenter的交換與路由功能5NSX高級功能驗證SSL VPN邏輯負載均衡VXLAN與VLAN的橋接驗證NSX Edge服務網關可以：1.提供基于客戶端的SSL VPN服務2.提供邏輯負載均衡功能3.提供物理與虛擬網絡之間的通信功能表：POC內容一覽表POC測試進度本次測試進度安排如下：序號項目時間內容周期1測試方案最終確定XX年X月確定最終測試方案1天2測試設備

11、現場就位XX年X月準備測試條件1天3測試實施階段XX年X月安裝部署vCenter、vSphere和NSX1天XX年X月NSX基本功能測試1天XX年X月NSX可用性測試1天XX年X月NSX高級功能測試1天4測試總結及評估XXXX年X月對測試結果進行總結和評估1天5完成測試報告XXXX年X月根據測試結果完成最終測試報告1天表：POC測試進度安排POC測試環境本POC的測試場景是基于數據中心內托管一個Web應用，測試環境描述如下。測試場景該Web應用是一個三層應用，每層分別位于不同的第二層網絡中，以下是托管該應用所需的一些主要服務負載均衡器服務，用于提供更好的應用用戶體驗。防火墻服務，用于保護該三層

12、應用的各層。Web、應用和數據庫服務器通過防火墻規則保護彼此間以及與外界的通信。路由服務，用于提供跨層訪問以及對物理網絡的訪問本測試包含三個配置了VMware的vSphere產品的集群，如圖所示。其中包含兩個計算集群，以及一個由 vCenter Server 管理的管理和邊緣集群。管理和邊緣集群中部署了 NSX 的所有控制層和管理層組件。在計算集群 A 和 B 中，部署了多個虛擬機。雖然示意圖中沒有顯示底層物理網絡拓撲，但每個集群都運行在不同的網絡中。計算集群 A 和 B 連接到一個子網 (/24)。管理集群位于 /24 子網中。注意：如果條件有限，不具備五臺物理服務器，可以酌情在計算集群A以

13、及管理和邊緣集群中各減掉一臺物理服務器。圖：測試場景環境搭建軟硬件需求NSX所需的最低硬件配置如下表所示。表：NSX最低硬件配置本POC測試的硬件配置如下表所示（僅供參考）。序號名稱配置參數1服務器共5臺虛擬化服務器四路4核至強CPU，32GB 內存，RAID5 disk，4塊千兆網卡2存儲陣列12TB 光纖存儲陣列可用容量為12TB（SAS磁盤，RAID 5 7+1），至少2塊熱備盤3網卡DELL Broadcom 5709 雙口千兆網卡每臺虛擬服務器已有2塊千兆網卡，每臺需再擴2塊雙口網卡4交換機CISCO6509R-E；N7K交換機表：POC測試硬件配置本POC測試的軟件配置如下表所示（

14、僅供參考）。軟件名稱版本號PatchVMware vSphere企業增強版6.0 U1vCenter Server6.0 U1VMware NSX for vSphere6.2表：POC測試軟件配置以下環境由XXX客戶準備：Windows 2008 R2 Enterprise/Windows 7典型的應用測試環境，包括Web/App/DB網絡性能測試工具：iperf，主要用來測試東西向同主機交換、東西向同主機路由，東西向跨主機交換、東西向跨主機路由，南北向流量的吞吐量。安裝與配置（驗證一次性安裝）ESXi 6.0 U1 的安裝安裝ESXi 6.0 U1版本，這樣可以以使每個服務器支持跨 vCe

15、nter NSX。vCenter Server 6.0 U1 ova安裝安裝vCenter Server 6.0 U1版本，以便支持跨vCenter的 NSX。NSX 6.2的安裝和連接vCenter NSX 安裝流程包括部署多個虛擬設備,完成一些 ESX 主機準備，并進行一些配置以便所有物理和虛擬設備能夠相互通信，如下圖所示。圖：NSX安裝流程此流程首先應部署 NSX Manager OVF/OVA 模板，確保 NSX Manager 完全連接到它將管理的 ESX 主機的管 理接口。接下來，需要通過注冊流程將 NSX Manager 與一個vCenter實例彼此鏈接。然后，就可以部署 NSX

16、 Controller 群集了。與 NSX Manager 一樣，NSX Controller 在 ESX 主機上作為虛擬設備運行。下一步是為 NSX 準備 ESX 主機，管理員需要在主機上安裝多個 VIB。這些 VIB 支持第 2 層 VXLAN 功能、分布式路由和 Distributed Firewall。配置 VXLAN、指定虛擬網絡接口 (VNI) 范圍并創建傳輸區域之后，管理員就可以開始構建 自己的 NSX 覆蓋拓撲。 此處需要對NSX的一次性安裝進行驗證，方法是提前將一臺物理主機獨立出來，待集群搭建完成后，再將該主機添加進集群并觀察集群上NSX功能組件的安裝情況。此時會發現，NSX

17、組件將自動在該主機上進行部署，不需要進行二次安裝。VMware ESXi 6.0 U1的下載地址如下。 HYPERLINK /cn/web/vmware/details?downloadGroup=ESXI600U1&productId=491&rPId=9676 /cn/web/vmware/details?downloadGroup=ESXI600U1&productId=491&rPId=9676VMware vCenter Server 6.0 U1的下載地址如下。 HYPERLINK /cn/web/vmware/details?downloadGroup=VC600U1&produ

18、ctId=491&rPId=9676 /cn/web/vmware/details?downloadGroup=VC600U1&productId=491&rPId=9676NSX for vSphere 6.2的下載地址如下。 HYPERLINK /build/mts/release/bora-2986609/publish/VMware-NSX-Manager-6.2.0-2986609.ova /build/mts/release/bora-2986609/publish/VMware-NSX-Manager-6.2.0-2986609.ovaESXi的安裝配置文檔如下。 HYPERLI

19、NK /cn/support/support-resources/pubs/vsphere-esxi-vcenter-server-6-pubs /cn/support/support-resources/pubs/vsphere-esxi-vcenter-server-6-pubsNSX的安裝配置文檔如下。 HYPERLINK /cn/support/support-resources/pubs/nsx_pubs.html /cn/support/support-resources/pubs/nsx_pubs.html完成了上述的相關安裝與配置操作后，還需要進行如下的檢查與驗證操作。驗證已部

20、署的組件在“Installation”“Host Preparation”下可以看到主機上的數據層組件，也稱為網絡虛擬化組件。這些組件包括以下內容：端口安全、VXLAN、分布式防火墻和分布式路由等的虛擬化管理程序級內核模塊圖：驗證已部署的組件上圖顯示安裝網絡虛擬化組件后，防火墻和 VXLAN 功能會在每個集群上啟用。配置了 NSX Edge 邏輯路由器后，端口安全模塊會在啟用分布式路由模塊后輔助 VXLAN 功能。查看 VTEP 配置通過“Logical Network Preparation”“VXLAN Transport”可以查看如下VTEP配置。圖：VTEP配置如圖所示，計算集群中的主

21、機配置為使用不同于管理集群的子網中的 VTEP IP。計算集群 A 位于 /24 子網計算集群 B 位于 /24 子網管理邊緣集群位于 /24 子網客戶面臨的一個主要 VXLAN 部署問題是物理網絡設備需要多播協議支持。通過提供基于控制器的 VXLAN 實施實例，以及不再需要在物理網絡中配置多播功能，該問題已在 NSX 平臺中得到解決。這種模式是默認模式，并且客戶不必在定義邏輯網絡池時配置任何多播地址，在本POC測試中我們將使用“Unicast Mode”（單播模式）。確認集群是全局傳輸區域的成員圖：確認集群在傳輸域中確認所有 3 個集群都位于“Transport Zone”（傳輸區域）中，定

22、義傳輸區域后的拓撲如下所示。圖：定義傳輸域后的拓撲NSX基本功能驗證本單元將對NSX的如下三項基本功能進行測試。邏輯交換邏輯路由分布式防火墻邏輯交換NSX邏輯交換測試主要包括如下內容。測試如何創建一個邏輯交換機，然后將兩臺虛擬機連接至該邏輯交換機驗證該邏輯交換機如何橫跨第三層物理網絡，同時仍使兩臺 Web 服務器之間能夠建立第二層連接創建邏輯交換機測試目的驗證NSX可以便捷高效的創建邏輯交換機，并提供相應的交換功能。與重新配置物理設備的過程相比，采用這種方法調配邏輯交換機將更加簡單快捷。預期結果可以成功創建邏輯交換機，并在虛擬機之間轉發流量，可以橫跨物理第三層的邊界提供第二層連接。測試步驟創建

23、名為“Prod_Logical_Switch”的邏輯交換機。將新邏輯交換機連接到 NSX EDGE 服務網關以供外部訪問。將虛擬機web-sv-03a和web-sv-04a的虛擬網卡添加到該邏輯交換機。將虛擬機連接到邏輯交換機后的拓撲如下圖所示。圖：虛擬機連接到邏輯交換的拓撲建立與虛擬機的 SSH 會話，此流量將通過 NSX Edge 然后到達 Web 界面，此步驟證明可以從外部對虛擬機進行訪問。位于兩個不同集群上的虛擬機之間的通信將證明邏輯交換機可以橫跨物理第 3 層的邊界，同時提供第 2 層連接。對 WEB 服務器 WEB-SV-04A 執行 PING 操作以顯示第 2 層連接情況。圖：兩

24、臺虛擬機之間的Ping操作Ping操作可以收到回復，因此兩臺虛擬機可以進行第二層的連接，這也證明了邏輯交換機可以橫跨第三層邊界提供第二層連接。邏輯路由NSX邏輯路由測試將驗證以下內容。配置并啟用分布式路由，驗證當啟用分布式路由后，在同一主機上運行的 App 虛擬機和 DB 虛擬機之間的通信流在分布式邏輯路由器和NSXEdge 服務網關之間配置動態路由協議驗證通向外部路由器的內部路由通告配置并啟用分布式路由測試目的創建分布式路由，該路由獨特的內核級分布式路由可減少“發卡”式轉發，尤其是當虛擬機在連接到不同邏輯交換機的同一物理主機上運行時。預期結果沒有分布式路由的情況下，WEB應用的三層位于不同的

25、邏輯交換機上，會產生“發卡”效應。創建分布式路由后，App和DB兩臺虛擬機的流量可以不出物理主機，消除“發卡”效應。測試步驟當前的拓撲和數據包流的示意圖如下所示。圖：當前拓撲中的數據包流上圖中，應用虛擬機和數據庫虛擬機均位于同一物理主機上，在不使用分布式路由的情況下，為了讓這兩臺虛擬機實現通信，流量離開了應用虛擬機，因為數據庫虛擬機不在同一個網絡子網中，所以物理主機將該流量發送到第 3 層設備，也就是駐留在管理集群上的 NSX Edge，然后，NSX Edge 會將流量發回到它最終到達的數據庫虛擬機所在的主機。應用的三個層（Web、應用和數據庫）位于不同的邏輯交換機上，由 NSX Edge 在

26、各層之間提供路由。訪問Web 服務器，此時將返回一個 Web 頁面，其中顯示數據庫中存儲的客戶信息，證明Edge可以完成三層之間的路由。但是此時存在“發卡”效應。接下來，創建分布式路由，并從NSX Edge移除應用和數據庫接口。向分布式路由器中添加應用和數據庫接口，開始配置分布式路由。在分布式路由器上配置這些接口后，這些接口配置會自動推送到環境中的每個主機上。自此，將由主機的分布式路由 (DR) 內核可加載模塊處理應用和數據庫接口之間的路由。所以，如果運行在同一個主機上并連接到兩個不同子網的兩個虛擬機要進行通信，則流量不會采用如前面的通信流示意圖中所示的非優化路徑，啟用分布式路由之后優化的通信

27、流如下所示。圖：啟用分布式路由后的數據包流如上圖所示，運行在同一個主機上的虛擬機的路由發生在內核中，流量并不會離開該主機。 配置并啟用動態路由在上面拓撲中，應用和數據庫層連接到同一個路由器，而 Web 層則連接到外圍邊緣路由器。這兩個路由器現在必須通過動態路由協議彼此通信，本測試將同時在兩個路由器上啟用 OSPF。測試目的驗證分布式路由器上的動態路由功能，能夠在邏輯空間中重現復雜的物理網絡拓撲。預期結果在分布式路由器上成功啟用OSPF，三層WEB應用可以正常運行。測試步驟在目前的拓撲中，應用的 Web 層連接到一個路由器，而其他兩層則連接到另一個路由器。因此，除非在兩個路由器上都啟用了動態路由

28、，否則應用訪問會失敗。測試 3 層應用的訪問是否會失敗，預期結果為訪問失敗。在分布式路由上啟用OSPF，發布變更將更新的配置推送到分布式邊緣設備上，并確認已經在分布式邊緣上啟用和配置了 OSPF 路由。在外圍邊界網關Edge上配置并啟用OSPF路由和路由重新分發，最后發布變更。再次刷新瀏覽器來驗證 3 層 Web 應用是否正常運行，一旦兩個路由器之間發生 OSPF 對等互連（如下圖所示），Web 層虛擬機就能夠訪問跨分布式路由器連接的應用層虛擬機。圖：動態路由OSPF測試結果應為WEB應用可以正常運行。動態路由通告和控制測試目的驗證如何在整個系統中控制、更新和傳播 OSPF 動態路由。預期結果

29、OSPF動態路由可以在系統中更新和傳播。測試步驟首先測試OSPF 路由過程成功啟動并在兩個邊緣設備之間形成了相鄰關系。使用 SSH 連接到邊界路由器設備并輸入show ip ospf neighbor來顯示分布式邊緣設備的 OSPF 相鄰狀態。圖：邊緣設備的OSPF相鄰狀態上圖顯示了與邊界路由有路由關系的路由器（分布式邏輯路由器）的“Neighbor ID”，任何相關聯的計時器以及 OSPF 相鄰過程的狀態。至此，這一過程已經完成，“State”指示為“Full”則意味著 OSPF 過程完成，路由更新也已完成。在命令提示符處輸入命令how ip route以顯示路由表，可以看到邊緣設備的整個路

30、由表，包括該設備從 OSPF 鄰居那里獲知的路由。圖：邊緣設備的路由表該表顯示，上述兩個子網已經成功連接到分布式邊緣設備，并且通過 OSPF 正確配置了從外圍邊緣設備（Edge）到分布式邊緣設備的路由。分布式防火墻本部分將驗證分布式防火墻如何幫助保護 3 層應用，以及如何根據安全組和身份而非基于 IP 地址的規則創建防火墻規則。基于 IP 地址的規則對移動虛擬機具有硬性限制，因此降低了使用資源池的靈活性。NSX分布式防火墻測試包括如下內容。修改防火墻默認規則基于安全組的防火墻規則基于身份的防火墻規則分布式防火墻與Edge防火墻的統一管理修改防火墻默認規則測試目的驗證分布式防火墻可以根據規則完成

31、相關訪問控制。預期結果修改防火墻規則為“阻止”后，相應的網絡訪問均被屏蔽。測試步驟執行從 WEB-SV-01A 到其他 3 層成員的 PING 操作并使用 WEB 瀏覽器演示 3 層應用，此刻將獲得從 Web 層傳遞到app-sv-01a虛擬機并最終查詢db-sv-01a虛擬機后返回的數據。將默認防火墻策略從“允許”改為“阻止”，然后發布變更。驗證規則變更阻止了通信：Putty：打開 PuTTY 時將顯示它不再處于活動狀態，因為默認規則現在阻止包括 SSH 在內的一切內容。Web 瀏覽器：通過瀏覽器訪問Web應用，會收到一條“SSL connection error”（SSL 連接錯誤）消息。

32、基于安全組的防火墻規則測試目的驗證可以通過創建安全組與訪問規則實現訪問控制。預期結果通過創建基于安全組的防火墻規則，可以實現三層應用間的通信。測試步驟創建一個分配有兩個虛擬機的名為 Web-tier 的安全組。接下來將添加新的規則以允許訪問 Web 虛擬機，然后在各層間設置訪問權限，步驟如下。為三層應用添加新規則Section（“3-tier App”）并為該Section添加三條規則。第一個規則為“Ext to Web”，在“目標”中，將“Web-tier”添加至該規則的安全組，將HTTPS和SSH添加至該規則的Service。添加第二條規則“Web to App”，以允許 Web 安全組通

33、過 App 端口訪問 App 安全組，選擇Web-tier 安全組作為源字段。重復上述步驟創建第三條規則，用于允許在應用層和數據庫層之間進行訪問。驗證新規則是否允許三層應用通信：打開瀏覽器并訪問此應用，顯示正在通過該 3 層應用獲取數據，正常訪問。重啟 PUTTY 與 WEB-SV-01A 的會話，在層之間執行 PING 測試，結果如下。圖：Ping操作Ping 操作不被允許，并將失敗，因為在上述規則中，不支持各層之間或層成員之間的 ICMP。基于身份的防火墻規則測試目的驗證可以通過使用 Active Directory 組創建規則，并借此控制用戶對其他安全對象（如網絡、IP 地址）和其他安全

34、組的訪問。預期結果符合AD身份認證的用戶可以訪問應用，反之則被屏蔽。測試步驟創建將 NSX 鏈接到 Active Directory 所需的基于用戶的規則。通過NSX Manager中的域連接器配置并同步AD連接。編輯“EXT TO WEB”規則，將新的域組“AD SALES”添加到“Ext to Web”規則的“Source”字段中，并發布變更。測試用戶身份規則：打開域中另一個虛擬機的控制臺，并以 Active Directory Sales 組成員的身份登錄，來測試基于身份的新規則。User:Sales1是Sales組的成員，User:NonSales不是該組的成員，分別用以上兩個身份登錄

35、，嘗試訪問三層應用的結果如下。用戶nonsales不是AD-Sales Group的成員，因此會被禁止訪問三層應用。用戶Sales1是AD-Sales組的成員，因此允許訪問三層應用。因此，基于身份的防火墻規則驗證成功。兩種防火墻的統一管理測試目的驗證NSX所提供的針對Edge服務網關防火墻和分布式防火墻的統一管理。預期結果Edge服務網關防火墻和分布式防火墻可以通過一個規則條目進行訪問控制。測試步驟編輯 DFW 規則：將源設置為任意，并選擇“阻止”操作。這將發送一個 TCP 重置以清除會話，阻止操作會放棄數據包而不作出響應，并將此規則應用到邊界網關。添加新列“Rule-ID”，記住該規則的Ru

36、le-ID，例如：1008已編輯的 DFW 規則表明 SSH 的“Any to Web-tier”現在為“阻止數據包”。此規則現在可應用于Edge外圍網關以及DFW。檢查由于統一管理做出的Edge防火墻更改：查看邊界網關的防火墻規則，這時，一條新規則已經以預規則的形式添加到Edge，規則標記與 DFW 中先前的數字相同：1008。通過SSH登錄到Edge，輸入：show log follow以讀取防火墻日志條目。通過SSH登錄到虛擬機WEB-SV-01A。檢查 Edge 日志是否受阻。圖：Edge日志受阻情況這證明被置于DFW窗口中的規則可以同時被推送到 Edge。NSX可用性驗證NSX可用性

37、驗證包括如下內容。驗證NSX 平臺的高可用性，主動關閉其中一臺控制器，查看網絡是否仍可運行Edge服務網關的可用性驗證等價多路徑（ECMP）提供的高可用驗證NSX 控制器的可用性測試目的測試控制器的可用性。預期結果一個節點的故障不會影響邏輯交換機或邏輯路由操作。測試步驟檢查 NSX Controller 節點，可以看到已經部署了三個控制器，NSX Controller 始終部署為奇數個數，以實現高可用性和可擴展性。圖：NSX控制器關閉其中一個 NSX CONTROLLER，再次登錄虛擬機 WEB-SV-03A 并用 PUTTY 來測試連接,執行 Ping 操作，以顯示第 3 層物理網絡上方的第

38、 2 層連接，預期結果為可以收到相應的回復。圖：Ping操作測試在一個 NSX Controller 關閉的情況下，其余兩個控制器可供使用。高可用性 Edge服務網關測試目的驗證NSX可在“High Availability”模式下啟用 Edge 服務網關，在此模式下會創建主 Edge 服務網關的被動副本。預期結果如果在高可用性對中充當主 Edge 的虛擬機出現故障，則此被動副本會快速接替主虛擬機并恢復該 Edge 服務網關上提供的所有服務。測試步驟通過使用 Perimeter-Gateway Edge在 Edge 服務網關上啟用高可用性模式，并確認“HA Status”（高可用性狀態）顯示為

39、“Enabled”（已啟用）。登陸Edge，一旦建立 SSH 連接后，輸入如下命令以顯示服務高可用性。此時將看到被動對和主動 Edge 的“High Availability Health Check Status”（高可用性運行狀況檢查狀態）均顯示“good”（良好）。圖：顯示Edge的高可用性對主動 Edge 連續執行Ping操作，然后關閉主動 Edge來強制進入故障切換場景，并在連續執行 Ping 操作期間觀察故障切換。圖：在Edge上進行Ping操作在故障切換期間可觀察到 ping 操作的幾個超時響應，考慮到測試環境的密度，有 2 到 6 個超時是正常的。接下來將看到 ping 操作再

40、次開始回復，這證明在關閉主動 Edge 后被動 Edge 接管了服務，高可用性得到驗證。輸入show service highavailability命令查看高可用狀態，預期結果如下圖所示。 圖：再次顯示Edge的高可用性此時列出的對等主機是原來的主動 Edge，并且其狀態應為“Unreachable”（無法訪問）。等價多路徑（ECMP）提供的高可用驗證測試目的驗證NSX的等價多路徑（ECMP）所提供的高可用性。預期結果等價多路徑上的某個Edge網關壞掉后，流量可以通過其他路徑進行轉發。測試步驟首先，確保在分布式路由和Edge邊界服務網關上面已經開啟OSPF。第二步，創建一個新的Edge服務網

41、關Perimeter-Gateway-2，并在上面配置OSPF。此時的網絡拓撲圖如下所示。圖：兩個Edge網關并啟動OSPF后的拓撲在開啟ECMP之前，在分布式路由上面運行show ip ospf neighbor，可以看到如下圖所示的結果。此時，分布式路由有兩個OSPF鄰居（Edge邊界網關），并且只有一條通向/24網段的路徑。圖：分布式路由的OSPF鄰居與路徑在分布式路由上開啟ECMP并進行驗證，驗證步驟如下：輸入命令show configuration routing-global，結果顯示“ecmp”：true，證明ECMP已經開啟，如下圖所示。圖：ECMP開啟成功驗證多個路由具有相等

42、路徑，步驟如下：輸入命令show ip route，可以看到分布式路由有兩個相等的路徑(和)到缺省的網關。同時有兩條相等的路徑到/24網段（通過相同的嚇一跳網關）。圖：分布式路由的等價多路徑此時ECMP已經開啟，分布式路由有兩條等價路徑到同一個網段，如果一個Edge壞掉，另一條路徑可以保證流量進行正常轉發。跨vCenter的交換與路由跨vCenter的邏輯交換測試目的驗證NSX可以跨vCenter Server實現邏輯交換功能。預期結果位于兩個不同vCenter上的兩臺虛擬機，可以通過連接到同一個通用邏輯交換機來實現網絡互聯，即：可以從一臺虛擬機上Ping通另外一臺虛擬機。測試步驟在主NSX

43、Manager上創建名為“ULS-Transit-Network-02”的通用邏輯交換機。為Web、App和DB層分別創建通用邏輯交換機：ULS-Web-Tier-02、ULS-App-Tier-02和ULS-DB-Tier-02，如下圖所示。圖：Web、App和DB層的通用邏輯交換機將虛擬機web-03a連接到通用邏輯交換機ULS-Web-Tier-02，并選擇相應的vNIC，如下圖所示。圖：在主NSX Manager上，將web-03a連接到ULS-Web-Tier-02在輔助NSX Manager上，將虛擬機web-01b連接到ULS-Web-Tier-02邏輯交換機上，并為該虛擬機選擇

44、vNIC。圖：在輔助NSX Manager上，將web-01b連接到ULS-Web-Tier-02在虛擬機web-03a上啟動控制臺來測試ULS-Web-Tier-02通用邏輯交換機上跨vCenter的網絡連接情況，運行如下命令。ping -c 3 2假設web-03a的IP地址是1，web-01b的IP地址是2，結果應該如下圖所示。圖：web-03a可以與web-01b進行網絡通信該結果證明，分屬兩個站點，跨vCenter的兩臺虛擬機可以進行通信。跨vCenter的邏輯路由測試目的驗證NSX可以跨vCenter Server實現邏輯路由功能。預期結果被不同vCenter管理的不同的通用邏輯交

45、換機上的兩臺虛擬機應該可以進行網絡通信。測試步驟通用邏輯路由器的創建與配置在主NSX Manager上將虛擬機app-02a連接到通用邏輯交換機ULS-App-Tier-02，并選擇相應的vNIC。重復上述步驟將虛擬機db-02a連接到通用邏輯交換機ULS-DB-Tier-02，并選擇相應的vNIC。在主NSX Manager上創建名為“Universal-Distributed-Router”的通用邏輯路由器，其中需要完成如下幾個接口的配置工作：名字：UDLR-Transit-Network，類型：Uplink，連接到：ULS-Transit-Network-02，通過接口：0/29名字：U

46、DLR-Web-Tier，類型：Internal，連接到：ULS-Web-Tier-02，通過接口：/24名字：UDLR-App-Tier，類型：Internal，連接到： ULS-App-Tier-02，通過接口：/24名字：UDLR-DB-Tier ，類型： Internal，連接到：ULS-DB-Tier-02，通過接口：/24配置完成后的結果如下圖所示。圖：為通用邏輯路由器配置接口配置剛剛創建的通用邏輯分布式路由：配置OSPF、定義域、域到接口的映射和路由重新發布，如下圖所示。圖：配置OSPF驗證跨vCenter的通用邏輯路由器功能在輔助站點的web-01b上打開控制臺，測試web-0

47、1b與app-02a之間的連通性。ping -c 3 1測試結果應該如下如所示，該測試驗證了被不同vCenter管理的不同的通用邏輯交換機上的兩臺虛擬機的網絡連通性。圖：測試web-01b與app-02a之間的連通性。接下來，測試web-01b和DB-02a的連通性，運行如下命令。ping -c 3 1測試結果應該如下如所示，該測試依然驗證了被不同vCenter管理的不同的通用邏輯交換機上的兩臺虛擬機的網絡連通性。圖：測試web-01b和DB-02a的連通性配置邊界路由選擇邊界網關Perimeter-Gateway-02，編輯其中的vNIC，將其連接到ULS-Transit-Network-0

48、2，如下圖所示。 圖：配置接口接下來，配置OSPF并發布變更。在主NSX Manager上，連接單路由OneArm-LoadBalancer-02與通用邏輯交換機ULS-Web-Tier-02，使其與通用網絡層相連。通過瀏覽器訪問三層Web應用，可以得到如下結果。圖：驗證對三層應用的訪問NSX高級功能驗證NSX高級功能驗證包括如下內容。基于客戶端的 VPN (SSL VPN Plus)邏輯負載均衡服務測試VXLAN與VLAN之間的橋接功能，驗證物理和虛擬網絡之間的通信此單元的拓撲包括三層 Web 應用“前端”的兩個 Web 服務器（web-sv-01a 和 web-sv-02a）、一個“中間件

49、”層 (app-sv-01a) 和一個“后端”數據庫服務器 (db-sv-01a)，IP地址如下所示。Perimeter-Router-0- web-sv-01a- 1web-sv-02a- 2app-sv-01a- 1db-sv-01a- 1SSL VPN測試目的驗證NSX的Edge服務網關可以提供基于客戶端的SSL VPN服務。預期結果可以通過客戶端建立SSL VPN鏈接，可以Ping通防火墻后面的虛擬機。測試步驟配置并啟動SSL VPN Plus服務執行：添加專用網絡、配置身份驗證、創建安裝程序包、為 SSL VPN-Plus 實例配置“Client Configuration”（客戶端

50、配置）等步驟對SSL VPN進行配置，然后啟用 SSL VPN-Plus 服務。準備 EDGE 防火墻規則創建防火墻規則來阻止控制中心和 web-sv-01a 虛擬機之間的流量，進而測試和證明SSL VPN使用情況。對 WEB-SV-01A 執行 PING 測試測試控制中心和 web-sv-01a 之間的 Ping連接，結果應該如下圖所示，證明創建的防火墻阻止了控制中心和web-sv-01a虛擬機之間的流量。圖：Ping操作-超時通過客戶端建立SSL VPN鏈接獲取并安裝SSL VPN 客戶端，安裝程序運行完成后，客戶端會自動啟動，單擊“Login”按鈕繼續，成功登陸后會出現如下結果，表明SS

51、LVPN-PLUS 已建立。圖：SSL VPN連接建立成功通過 PING 操作驗證是否連接：ping web-sv-01a。圖：Ping操作-收到回復現在可以 ping 通防火墻后面的 web-sv-01a，SSL VPN驗證成功。邏輯負載均衡測試目的驗證NSX Edge服務網關可以提供負載均衡功能，實現更為理想的資源利用場景。預期結果成功配置負載均衡，并完成流量分流。測試流程配置IIS服務，并放置不同的Hello.html頁面。在Edge上配置負載均衡器服務如下：創建新的應用配置文件：應用配置文件用于定義典型類型的網絡流量的行為。配置新的虛擬服務器：虛擬服務器用于接受來自負載均衡服務配置“前

52、端”的流量。 用戶流量會定向至虛擬服務器所表示的 IP 地址，然后重新分發至負載均衡器“后端”上的節點。檢查是否自動生成了DNAT Rule。最后，在外網訪問相關頁面hello頁面：在hello頁面清空cache后，多次再次訪問該頁面，可以發現在兩個不同的Hello頁面間切換，負載均衡功能得到驗證。VXLAN與VLAN之間的二層橋接測試目的驗證NSX的VXLAN與VLAN之間的橋接功能可以實現物理與虛擬網絡之間的通信功能。預期結果通過VXLAN與VLAN之間的橋接，虛擬機可以完成物理和虛擬網絡之間的通信，在物理與虛擬環境上的虛擬機之間執行Ping操作，可以收到相應回復。在NSX 6.2中，邏輯

53、交換網絡可以通過DLR來完成到VLAN的擴展，這樣做的好處是數據流量進行了優化，流量不再需要經過Edge進行路由。測試步驟檢查初始配置情況初始配置情況如下圖所示，左側為VLAN 101，在該網絡上有名為vds-mgt_Bridge Network的端口組，虛擬機web-04a在該端口組上，該網絡與右側的網絡目前處于隔離狀態。圖：初始配置在web-04a上啟動控制臺，并運行如下命令。ping -c 3 結果應該如下圖所示，該結果證明VLAN 101與右側的網絡之間不能通信。圖：web-04a與右側網絡的連通性驗證 配置二層橋接在VLAN 101和Web-Tier-01邏輯交換網絡之間配置二層橋接，網絡拓撲圖如下所示。配置完二層橋接后，web-04a就可以與下圖右側的網絡部分進行通信。圖：配置二層橋接打開上圖中名字為Local-Distributed-Router的邏輯路由配置選項，在上面配置二層橋接：名字為Bridge-01邏輯交換機為Web-Tier-01分布式端口組為vds-mgt_Bridged Netw