NSX软件定义网络POC测试方案

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