SDN VMware NSX网络原理与实践-NSX 的底层物理网络设计【4.7】

12.2.2 在 Arista Networks 网络平台之上部署 NSX

        Arista Networks 和 VMware 的合作由来已久。早在 2010 年，这两家成立时间并不长， 却都蓬勃发展的公司就开始了第一阶段的合作。 Arista Networks 交换机针对 ESXi 的标准交 换机和分布式交换机在物理链路的连接层面做了优化。 2012 年，两家公司联合 Cisco 和 Broadcom 公司共同参与研发了 VXLAN 协议并制定了这个协议的行业规范，同时 Arista Networks 还在其 EOS 软件中引入了 VM Tracer 功能。 Arista Networks 和 NSX 的融合解决 方案的提出，标志着两家公司的合作进入了第三阶段。

        Arista Networks 与 VMware 认为，当今的数据中心需要在实现自动化、 设备自动配置、 线性扩展的同时，保证数据中心的经济性与实用性。 在 Arista Networks 数据中心交换产品 上运行 VMware NSX 网络虚拟化平台之后，企业能够通过单一的管理节点实现下一代网络 的虚拟化、可编程性及架构的简化。 Arista Networks 和 NSX 的融合解决方案的一个典型的拓扑如图 12.6 所示。 Arista Networks 的交换机有众多针对数据中心网络和应用的特点而优化的功能， 作为承载 NSX Overlay 的 Underlay，这些功能都可以更好地实现逻辑网络。在这个拓扑中，数 据中心中既有虚拟化环境，又有物理服务器。 Arista Networks 交换机全部支持 VXLAN 技术，可以在连接物理服务器的 ToR 交换机之上处理 VTEP 的封装与解封装，并和 Hypervisor 端的 VTEP 进行交互。因此，无需在 Edge 机柜之上实现 VXLAN-VLAN 的 转换，大大提升了数据中心中 Edge 机柜的效率并简化了部署。

        由于 Arista Networks 交换机具备极强的可编程性，因此 Arista Networks 公司的研发人 员将这种可编程性以现成代码的形式进行交付，使得 Arista Networks 交换机可以轻松注册 到 NSX Controller，并通过 OpenFlow 和 OVSDB 协议， 让 NSX Controller 成为其 SDN 控制器，自己则只需要处理物理网络层面的数据转发工作。 Arista Networks 的 LANZ 和网络追踪功能，可以针对物理流量和虚拟流量进行识别、 分析和追踪， 这样， 网络管理人员在物理网络层面对全网有一个全局的可视性，便于进行 故障排查。 对于流量，本书之前讨论的所有 NSX 环境中的流量模型在 Arista Networks 和 NSX 的 融合解决方案中都是完全一致的， NSX 网络虚拟化平台将各种复杂的多跳流量的路径进行 了大幅精简。

        最后，因为 NSX 网络虚拟化环境有需要使用 VXLAN 等隧道封装技术进行报文传 输的特点，使用 Arista Networks 交换机部署底层物理网络还有一大优势。之前介绍过， 由于 VXLAN 流量并不是一个 TCP 报文，因此传统网卡无法对其进行分片，可能需要 CPU 来处理，这种情况下会给整个网络带来一个副作用—分片之后，网络中会产生 多个突发的线速流量。因此，网络中的流量可能产生微爆流（ Microburst），形成拥塞 并影响端到端的吞吐。 在传统网络架构中，这个现象很难抑制，并且在发生之后很难 进行排查，因为我们不知道原始流量的哪一个分片形成了微爆流。然而， Arista Networks 交换机中有深度缓冲的结构，可以针对每个端口动态分配缓存，结合 LANZ 技术，可以有效避免因微爆流产生的拥塞和丢包。

12.3 Brocade 网络平台与 NSX 的融合

        本节会介绍老牌网络厂商 Brocade 的交换机是如何支持 NSX 网络虚拟化平台的。作为 SAN 网络的全球第一品牌， Brocade 在传统 IP 网络市场依然占据相当一部分的份额。近年， Brocade 在 SDN、 NFV 和网络虚拟化领域重拳出击，尤其在 2015 年，其 VDX 数据中心交 换机增强了可编程能力， 与主流 SDN、 NFV 供应商共同提出了融合解决方案。此外， Brocade 还在 2015 年还发布了 2.0 版本的 SDN 控制器和两个新的 SDN 应用—拓扑管理器、流量 管理器，并且通过收购 NFV 初创公司 Connectem 获得了 vEPC 技术，还通过收购 Riverved 公司的 SteelApp 业务获得了虚拟应用交付（vADC）技术。

        由于 VMwRare NSX 解决方案 是业内领先的网络虚拟化解决方案，希望在这个领域有所作为的 Brocade 公司与 VMwrare 公司的合作就非常紧密了—两家公司联合提出了解决方案。 12.3.1 Brocade VCS Fabric 平台介绍 Brocade 公司成立于 1995 年，专注于 SAN 网络和 IP 网络的交换技术以及这两种网络 的融合架构。 Brocade 的交换机支持的协议包括 iSCSI、 FCIP、 GigE、 FICON、 FCoE、 DCB/CEE、二到七层 IP 网络协议。

        Brocade 认为，在数据中心中使用 Folded CLOS 架构搭建物理网络时，所有用于 TOR 的枝叶节点交换机和骨干节点应当采用 40GE 端口连接，同时支持无缝的横向扩展。 然而 在扩展过程中，数据中心会变得越来越复杂，这样网络设备的自动化程度和上线的速度都 至关重要—配置TRILL或其他大二层技术，需要在每台新的枝叶节点交换机上进行配置， 并且还需要在骨干节点增加配置， 这会带来大量的重复劳动，影响业务上线时间，且容易 发生人为错误。

         为此， Brocade 专注于对集群和 Fabric 的配置进行自动化和动态发现。 Brocade VCS Fabric 采用了即插即用的集群化技术。自动化运维和配置对于重复性、常规性的配置，可 以极大缩短网络配置时间，降低管理难度和出现问题的可能性。 Brocade 宣称， 它们的交换机只需要三个步骤就可以部署—开机、配置 R-Bridge ID、 在设备间连线。

        当然，由于每个端口连接的设备类型不同，还需要配置一些 IP 地址、二 层封装方式（直接接入 VLAN 或配置成 Trunk）及一些安全策略。通过第三步即连线而 形成的 Brocade VCS Fanric 的拓扑，依然建议遵循 Folded CLOS 架构。 Brocade VCS Fabric 对于二层 Folded CLOS 的解决方法是使用 TRILL 技术，二层互联协议的配置都可以在交 换机连线后自动生成，而无需特别手动配置。 Brocade 对于三层 Folded CLOS 则混合使用 OSPF 和 BGP， 这需要手动配置，无法自动生成互联的命令。 Brocade 数据中心交换机主要有如下型号。  VDX8770 系列：机箱式多槽位交换机，主要用于骨干节点或超级骨干（ Super Spine）。

          VDX6940 系列： 2U 高度机架式交换机，全 40GE 端口，可用于骨干节点。  VDX6700 系列： 1U 或 2U 高度 ToR/枝叶节点交换机，其端口可以是 10GE 以太网 端口，也可以是用于连接存储设备 HBA 卡的 FC 或 FCOE 端口。 通过这些 Brocade VDX 数据中心交换机系列， 可以很容易搭建一张大型数据中心网 络。由于 VDX8770 系列的超高性能， 可以将它用作 Super Spine 交换机，而其下连的每 个 POD 都建议部署为标准的 Folded CLOS，有其自己的骨干节点（一般使用 VDX6940 系列）和枝叶节点（一般使用 VDX6700 系列，如 VDX6740）。这样一来， 每个 POD 都 成为了大型数据中心的一个业务模块， Edge POD 则用于与其他数据中心或 Internet 的互 联。此外， Brocade 的 VLAG 技术也可以实现与 Cisco 的 VPC 或 Arista Networks 的 MLAG 类似的功能，实现跨交换机的链路聚合，这样一来，枝叶节点交换机连接的服务器的上 行链路也实现了冗余。这种存在 Super Spine 的 Brocade VCS Fabric 典型架构如图 12.7 所示。

12.3.2 在 Brocade VCS Fabric 平台之上部署 NSX

        在 VMware NSX 网络虚拟化环境中，由于存在 VXLAN，跨三层网络的二层通信变为 可能， 而且无需特别在虚拟机的资源池之间使用传统二层协议。但在一些特殊情况下， 在 网络虚拟化环境内部还是需要使用这些纯二层连接。使用 Brocade VDX 设备，可以天然承 载二层域的流量，并能够在硬件上终结 VXLAN 流量，如图 12.8 所示。

        此外， VMware NSX 网络虚拟化平台，可以使得服务器虚拟化和逻辑网络位于同一 个管理平台之上，实现有效管理。 但是如果想要通过 NSX Controller 去控制物理网络， 需要编程人员通过编写代码来改写物理交换机的 API，并将 NSX Controller 进行再编程， 使其成为 OpenFlow 控制器。这样的实现方式非常繁琐，且无法使用统一的 UI 进行管 理。但是当 Brocade 和 VMware 深入合作以后，物理网络和逻辑网络统一管控的问题得 到了解决。

        在 Brocade 和 VMware NSX 的融合解决方案中， VMware NSX 管理 Hypervisor 中的 逻辑交换机，并且使用 VXLAN 在 Underlay 物理网络之上创建和连接 Overlay 逻辑网络。 对于 Overlay 网络， NSX 可以创建 VXLAN 隧道连接不同的网段。对于第三方物理设备， 例如 Brocade VCS，可以作为物理网络中的 VTEP 设备，与 Hypervisor 之上的 VTEP 通 信，承载 VXLAN 流量。

        此外， NSX 提供了可编程的 API，并通过 OVSDB 协议与物理 网络设备交换信息，而 Brocade 研发人员直接实现了 VDX 系列交换机与 NSX API 的集 成，无需编程人员通过再开发来实现。因此。对于跨逻辑网络和物理网络的 VXLAN 隧 道， NSX 就可以只负责 VXLAN 隧道的创建和管理，其他外部网络特性仍然由物理网络 设备单独实现。 在控制平面的层面， NSX 与 Brocade VCS 软件的交互过程就好比两个人打了电话。 双 方互相打了个招呼，说明一下自身情况，然后 VCS 就开始接受 NSX 远程遥控和调度— NSX Controller 成为了 VCS 交换机的控制平面， VCS 交换机通过 OpenFlow 协议接收控制 平面信息，对数据平面的任务进行处理。为了将 Brocade VCS Fabric 配置成为 NSX 的 VXLAN 二层网关，它们的具体通信流程如下。

        1． NSX Manager 获取 Brocade VCS 的设备相关信息。 2． Brocade VCS Fabric 进行回应，告知 NSX 自身的物理端口信息和设备信息。 3． NSX 管理员将 VCS 中的物理端口关联到 VTEP 二层网关服务。 4． NSX 管理员创建逻辑交换机，并且将其关联到一个 VNI（VXLAN 标识），并关联 到传输区域。 5．同时， NSX 管理员需要创建逻辑网络端口，并且关联到交集交换机。这需要关联 之前在 VCS 网关上面创建的 VLAN 和 VTEP 二层网关。 6． NSX 推送 VNI-VLAN 的映射给 VCS Fabric， 同时提供 MAC 地址和关联的 VTEP 信息。 7． VCS 通过识别 VNI-VLAN 映射，连接 VXLAN 和 VLAN 间的流量。 VCS 同时将逻 辑网络中的 MAC 地址和 VXLAN 隧道进行关联。 8． VCS 将物理网络中 VLAN 下的 MAC 地址信息提供给 NSX， NSX 通过这些信息创 建虚拟网络中的 MAC 地址。

        总的来说， VCS Fabric 像一个“边桥”，用于连接基于 VXLAN 的逻辑网络和物理网络。 对于一些需要通过物理网络连接到 VXLAN 环境中的服务（如数据库服务器），采用 Brocade VCS Fabric 作为边界也是简单易行的方案。另外，由于 Brocade VCS 技术的逻辑集群功能 是对整个物理网络集群进行统一管理，因此在 NSX 之中，整个集群呈现为一个服务节点， 网络硬件的管理可以交由 NSX 统一实现。 除了接受 NSX Controller 的统一控制， Brocade 还能够接受 VMware vRealize 进行管理。 可以使用 vRealize 工具在 VMware vSphere Web Client 统一视图之下提供对物理交换机的管 理、分析以及日志信息记录，便于进行全局控制。 Brocade 和 NSX 的集成解决方案的优势如下：

         Underlay 和 Overlay 统一管理；  支持自动化的部署工具；  虚拟化和云网络环境的适配（虚拟机感知、管理、策略分发）；  在 vCenter 中可同时管理 SAN 设备和 IP 设备。 12.4 NSX 环境中物理交换机连接的机柜设计 在 NSX 网络虚拟化环境中，会有不同类型的机柜和集群，其承载的应用特点和流量特 点都不尽相同。如何设计这些枝叶节点交换机连接的机柜和集群，就成了一个值得讨论的 话题。 本节将基于之前讨论的三层物理网络，来讨论如何部署 NSX 环境中的机柜和集群。

12.4.1 NSX 环境中的机柜和集群设计

        基于 NSX 网络虚拟化平台，可以在逻辑网络的层面为应用提供二层连接性、独立于底 层物理网络平台的各种特性，这是基本的解耦效果。例如，一旦在数据中心网络中，二层 和三层的边界位于枝叶节点， VLAN 就无法跨越不同机柜之间进行扩展。将这个 VLAN 的 网关部署在骨干节点又会带来其他路由问题，回到了使用模块化方式部署数据中心网络的 老路。但是，有了基于 NSX 网络虚拟化平台搭建的逻辑网络，就不会妨碍在不同机柜之间 扩展二层网络的工作负载了。 构建新的网络环境时，选择一套在未来易于扩展的架构非常重要。之前已经讨论了如 何部署 Folded CLOS 架构，使物理网络具备高可扩展性。当数据中心使用 NSX 网络虚拟化 平台之后，则可以根据服务器数量的增加来进行逻辑网络的扩展，提供更多关于计算、管 理、 Edge 服务的诸多功能，而不用再基于物理网络来扩展。这种物理网络和逻辑网络的解 耦在数据中心中带来了如下优势：

         对于提供特定功能的资源，在其业务（工作负载）扩大和收缩时，提供了灵活性。  有利于业务的分类和控制。  对于提供特性功能的资源， 实现更好的生命周期管理（更好的 CPU、内存、网卡 资源管理，使得它们可以更好地进行升级和迁移）。  基于逻辑网络中的应用实现更强的高可用性（利用 DRS、 FT、 HA 等虚拟化中才 有的功能）。  对于频繁变化的业务（如应用层、安全标签、负载均衡等）， 可以实现自动化地 控制。 图 12.9 所示为承载 NSX 网络虚拟化环境的基于 Folded CLOS 架构的数据中心物理网 络中，不同机柜中的 ESXi 主机需要担任的角色的示意图。根据 ESXi 主机角色的不同，将 它们分为计算机柜、 Edge（边界）机柜、 管理机柜。每种机柜中分别部署计算集群、 Edge 集群和基础架构集群，每种机柜关联的集群可能有一个，也可能有多个。

         计算机柜：计算机柜中的服务器可以是物理服务器，也可以是运行 vSphere 虚拟机 的服务器（ESXi 主机）。对于 ESXi 主机，自然会在其之上部署 NSX 网络虚拟化 平台。对于物理服务器需要分两种情况进行讨论：如果物理网络不支持或没有配 置 VXLAN，逻辑网络中的应用与之通信的流量，需要通过 Edge 机柜再与之进行 交互； 如果物理网络配置了 VXLAN，则无需通过 Edge 机柜中的 NSX Edge 设备。

         Edge 机柜： Edge 机柜提供了逻辑网络与外部物理网络的连接能力， 其主要的应用 场景包括：逻辑网络连接到与物理服务器、 逻辑网络连接到外部 Internet/WAN 或 其他硬件设备（如物理防火墙、物理负载均衡设备）。这种机柜上的流量虽然也会 出现东西向流量，但流量特征和南北向流量还是很像的。其中，运行 NSX Edge 的服务器仍然是运行了虚拟化程序的服务器，因为 NSX Edge 是需要安装在 ESXi 主机中的虚拟机里的。

         管理机柜：管理机柜中主要运行一些管理组件， 包括 vCenter、 NSX Manager、 NSX Controller、 Cloud Management Systems（CMS）和其他共享的 IP 存储相关的组件。 这种机柜里的很多服务其实也是运行在虚拟化环境中的，但是在其之上不会有任 何与租户相关的通信流量，而只有管理信令流量或 IP 存储流量。对于 IP 存储流量， 可能需要使用较高的网络带宽。 当然，对于小型数据中心网络，承担计算、基础架构和边界服务的 ESXi 主机可能会 集中安装在一两个机柜中，或者将 Edge 与管理机柜进行合并。这样，就需要对枝叶节点交 换机的全局策略和端口策略进行更详细的定义和划分。

        对于 NSX 中的这三种 ESXi 集群设计，需要考虑如下几点：  对于计算机柜、 Edge 机柜和管理机柜而言，需要考虑每个 vSphere 集群的范围和 其扩展性；  对于计算机柜、 Edge 机柜和管理机柜中的虚拟机，需要考虑 VDS 的上连链路 带宽；

         在每一个 NSX 域中如何设计 VDS。 首先讨论如何设计计算、Edge和管理的vSphere集群。如图12.10所示，由于每个vCenter 最多支持的 ESXi 主机和虚拟机的数量有限， 因此在大型数据中心中需要将不同服务器和 虚拟机划入不同的集群中。每个集群的大小都应有所预留，使得应用可以扩展。由于现在 VMware 可以实现跨越 vCenter 甚至跨越数据中心的 vMotion 技术，因此，不同集群之间的 虚拟机迁移已不再是问题。

        而服务器、交换机或机架的故障，也会基于集群内或集群间配 置的 vMotion 技术而实现高可用性，从而不影响应用功能和使用—受影响的只有集群容 量、交换机带宽和性能。 为 NSX 网络虚拟化环境服务的 vCenter 可以有两种部署模式，即面向中小型数据中心 的 vCenter 和面向大型数据中心的 vCenter。无论使用哪种部署模式，都需要考虑以下问题。  在 NSX 6.1 版本之前， NSX Manager 和 vCenter 之间必须是 1︰ 1 的关系。换句话 说，对于一个给定的 vCenter Server，只能有一个 NSX 域与之关联，只能部署一张 逻辑网络。这意味着在 NSX 网络虚拟化环境需要进行扩展的时候，会受到 vCenter 的限制。但是 NSX 6.2 版本之后则突破了这样的限制。

 集群内的所有 NSX Controller，都需要部署到 NSX Manager 连接的同一台 vCenter之下。这个限制在 NSX 6.2 版本之后也不存在了。

面向中小型数据中心的vCenter和面向大型数据中心的vCenter的主要区别在于vCenter 数量的不同。中小型数据中心只需要部署一台 vCenter，而大型数据中心需要部署多台 vCenter。图 12.11 所示为面向中小型数据中心的 vCenter 部署，一台 vCenter 与一台 NSX Manager 管控了所有 NSX 组件。

即便是机柜数量较少的小型数据中心，如果需要利用 NSX 解决方案实现网络虚拟化， 还是推荐针对计算资源使用独立的集群。此外，推荐将 Edge 资源和管理资源统一到一个独 立的集群中。 如图 12.12 所示，对于大型数据中心的部署，大多数企业习惯针对管理机柜专门部署一个集群，利用统一的管理集群中的各种组件来管理不同 vCenter 下属的不同 NSX 域中的计算和 Edge 集群。

这种部署方式有如下好处：
 避免了各个组件循环的依赖关系，管理集群始终处在它需要管理的域的外部；
 对于异地数据中心的运维和操作，实现了统一的管理集群，在此之上可以进行移动式的配置和管理；
 可以与现有 vCenter 实现集成；
 便于部署和扩展多个 NSX 域；
 升级任何一台 vCenter 时，都不会影响 NSX 域；
 可以集成 SRM（VMware Site Recovery Manager）等其他专用的管理工具。
在大型数据中心的部署中，推荐使用一到两个专门的机柜，用于管理集群，并使用安装在这些机柜的 ToR 交换机连接到骨干节点。在 NSX 域中部署 ESXi 主机集群时，还需要考虑下面这些因素。
 可以使用两种方法扩展计算能力，即水平增加更多的计算机柜，或垂直增加 vCenter
Server 数量。
 管理集群通常不需要配置 VXLAN。 当管理集群跨越两个或更多机柜（其中一个机柜作为管理集群中的冗余机柜， 以防止整个机柜断电）时，需要在两个机柜之间的 vCenter Server、 NSX Controllers、 NSX Manager 和 IP 存储实现二层连通性。推荐的机柜之间的连接方式为在枝叶节点交换机之间打通 802.1Q Trunk，而机柜里的服务器则交叉连接不同机柜的 ToR 交换机。
 通常来说， Edge 机柜是逻辑网络连接外部网络的唯一机柜。这样一来，外部流量只会影响 Edge 机柜，而不会穿越整个数据中心网络环境。
 对于 Edge 集群，可以将其部署在一个或两个机柜中，并使用一对或两对冗余的 ToR交换机连接骨干节点，这样就可以有效保证 Edge 机柜的冗余性。 以上讨论的机柜和集群设计都是 NSX-V 的情形。与 NSX-V 相同，在 NSX-MH 环境中 仍然有三种类型的机柜—计算机柜、 Edge 机柜、管理机柜。其中计算机柜中的服务器用 来承担数据中心中的最终应用，它们都是部署在虚拟化平台上的，这些虚拟化平台包括 Xen、 KVM 和 ESXi。 Edge 机柜中会部署 NSX-MH 的二层、三层网关和服务管理节点集群。 而管理机柜中的组件与 NSX-V 基本相同，包括 NSX Manager、 NSX Controller、第三方管 理平台（CMP/CMS）、存储， 其部署方法与 NSX-V 中非常类似，在此不再赘述。

12.4.2 NSX 中的流量模型

        部署在 NSX 环境中的 ESXi 主机有多种类型的流量，如 Overlay、管理、 vMotion 和存 储流量。其中， Overlay 流量是一种新型的流量模型，承载了 NSX 环境中几乎所有虚拟机 的流量。 这种流量如果是 VXLAN 流量，则会封装在 UDP 中进行传递。其他流量也有自己 的特点。 在部署传统的服务器虚拟化解决方案时，对于物理网络，一般使用两条 1GE 上行链路 承载不同类型的流量。如今，在数据中心中，由于流量的猛增，会使用两条或多条 10GE 上行链路进行流量承载，而且流量类型也不止两种。尤其是通过链路聚合技术捆绑了多条 上行链路并将其视为一条之后，多种类型的流量就会在同一条逻辑链路中进行传输， 因此 对流量模型的规划就变得更加重要。 下面来详细解释各种流量模型。

        1． VXLAN 流量 VXLAN 流量分为东西向流量（虚拟机之间的流量）和南北向流量（穿越 NSX Edge 的 VXLAN 流量或通过 NSX Edge 进行 VXLAN-VLAN 转换的流量）。源自虚拟机的流量会 被 Hypervisor 的 VTEP 封装，到达目的虚拟机（或 NSX Edge）时会被对端的 VTEP 解封装， 而外部物理网络逻辑网络的 MAC 和 IP 地址则无从知晓。 在 NSX-V 环境内部署 VXLAN 时，用于计算、 Edge 集群的不同 VTEP 的 IP 地址 建议位于不同网段之下。 VTEP 的 IP 地址可以通过 DHCP 服务器来分配，也可以为其 手动设置静态 IP 地址。根据特定机柜中的集群进行动态的 DHCP 地址分配，是推荐在 生产环境中使用的部署方式。手动分配地址不利于网络的大规模扩张， 仅建议用于实 验环境。

2．管理流量 管理流量源自并终结于主机之上的 VMkernel 接口，包含了 vCenter 和主机之间的通信 信令， 以及其他管理工具（如 NSX Manager 和 CMP）的管理流量。 单一的 VDS 可以跨越一台（或一对）枝叶节点交换机的多个 Hypervisor，但是由于VLAN 在不同机柜的枝叶节点交换机之间不易扩展，因此当 VLAN 需要在多台枝叶节点交 换机之间扩展时， Hypervisor 的管理接口也会参与进 VDS，用来将 VLAN 在分离的枝叶节 点交换机进行扩展。

3． vSphere vMotion 流量 vSphere 环境中的虚拟机在进行 vMotion 的过程中，虚拟机的运行状态会被网络传输到 对端。 每台 ESXi 主机上的 vSphere vMotionVMkernel 接口是用来移动这种虚拟机状态的。 在 ESXi 主机上，每个 vSphere VMotionVMkernel 接口分配了一个 IP 地址，而有多少这样 的接口，则取决于物理网卡的速度以及可同时通过 vSphere vMotion 进行迁移的数量。当有 万兆以太网卡时，可以同时执行 8 个 vSphere vMotion 的迁移工作。 在没有网络虚拟化环境时，可能会将所有部署的 VMkernel 接口都用于 vMotion，因为 它们都是 IP 子网的一部分。然而，在网络虚拟化环境下， 则会在不同的机柜为这些 VMkernel 接口选择不同的子网，无需将所有 VMkernel 接口都用于 vMotion。

4．存储流量 一个 VMkernel 接口还可以提供共享存储或非直连的存储功能，包括通过 IP 连接的 NAS、 iSCSI 存储，或非 IP 连接的 FC、 FCOE 存储。这种流量其实和管理流量的类型很相 似，因此用于管理流量的策略同样适用于存储的 VMkernel 接口，而管理和存储的机柜也往 往在一起统一部署。需要注意的是，存储 VMkernel 接口连接到枝叶节点交换机的子网只能 位于同一台物理交换机之上。因此在不同的机柜中，存储 VMkernel 接口只能部署到不同的 子网。但是如果枝叶节点交换机支持 FC 或 FCOE 接口，这个问题就不存在了，因为 FC 和 FCOE 的流量在传输过程中无需关心 IP 地址。 以上讨论的流量模型都是 NSX-V 中的情形。在 NSX-MH 环境下，同样存在管理流量 和存储流量。而对于 STT 等其他类型的 Overlay 流量，其特点和 VXLAN 流量其实非常类 似，而 KVM、 Xen 的环境中同样存在虚拟机迁移流量，其特点又与 vSphere vMotion 流量 相类似。因此对 NSX-MH 环境中的流量模型不再赘述。

12.5 总结

 在现代数据中心中，建议使用 Folded CLOS 架构部署物理网络。
 VMware NSX 网络虚拟化环境对其底层物理网络提出了一些要求，主要表现在简单性、可扩展性、高带宽、容错和服务质量。
 Arista Networks 公司的数据中心交换机的诸多功能如 LANZ、 DANZ、网络追踪，都可以对 NSX 网络虚拟化环境进行进一步优化，且 NSX Controller 也可以成为Arista Networks 交换机的控制平面组件。
 Brocade 公司的数据中心交换机可以与 NSX 网络虚拟化环境完美融合，将物理硬件设备交由 NSX Controller 进行控制，实现逻辑网络和物理网络的统一控制和管理。
 建议为计算、管理和 Edge 部署不同的集群，这些集群分属哪些 vCenter 也需要按照 vCenter 的容量、未来扩展的预留空间进行规划。
 NSX 环境中存在管理、 Overlay、虚拟机迁移和存储四种流量模型， 在生产环境中应对这些流量模型的特点进行细化设计。