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

11.2.3 与 NSX Edge 平行部署 F5 应用服务

        第一种部署方式是使用物理 BIG-IP 设备，基于 VXLAN Overlay，与 NSX Edge 平行部 署应用服务。也可以将 BIG-IP VE 版本部署在逻辑网络内部，将物理与 VE 版本的 F5 设备 统一交给 BIG-IQ 管理。其实这种部署模式与利用 NSX Edge 部署在线模式的负载均衡的设计思想完全一致，因为可以将物理 BIG-IP 设备和与其平行部署的物理 BIG-IP 设备看成一 个整体。 这种部署方法除了可以使用物理 BIG-IP 设备外，同样可以将 BIG-IP VE 版本安装在 NSX Edge 所在的 ESXi 主机上，这样在拓扑上就与利用 NSX Edge 部署在线模式的负载均 衡的拓扑完全一致了，但是逻辑架构上， VE 版本的 BIG-IP 设备仍然是与 NSX Edge 平行 部署的。

        图 11.8 所示为这种部署模式的逻辑拓扑图。可以看到， 物理的 F5 BIG-IP 设备同时连 接 NSX Edge 和外部网络，而 NSX Edge 可以部署为 Active/Standby 模式或 ECMP 模式，其 中 ECMP 模式需要在 BIG-IP 设备与 NSX Edge 设备之间开启动态路由。在 NSX Edge 之下 的网络虚拟化环境内部，分布式逻辑路由器可以对应用的不同层面（即 Web 层、 App 层、 数据库层） 提供三层连接性。 这些不同层面的子网网关，都是位于分布式路由器之上的。 而内部网络可以是 VLAN，也可以是 VXLAN，推荐使用 VXLAN。

        图 11.9 所示为与 NSX Edge 平行部署应用服务的模式在数据中心机房的机柜中的部署 示意图。这是一种典型的骨干/枝叶节点的数据中心部署模式（下一章会详细讲解这种部署 模式），在枝叶节点层面，安装了大量虚拟机、部署了大量应用的服务器机柜（ Computer Rack）， 与安装了物理 F5 设备、 NSX Edge 的 Edge 机柜，都会连接到各自的 ToR 交换机。 这些 ToR 交换机在底层物理网络中，也都会连接骨干节点，枝叶节点和骨干节点实现了 ECMP。而 Edge 机柜的 ToR 交换机也会如逻辑拓扑所示，连接外部网络。

        对于一个需要访问 Web 服务器 VIP 客户端的外部流量，首先会前往物理 F5 设备进行 NAT 转换和负载均衡处理。之后，流量通过 NSX Edge 进入网络虚拟化环境内部，访问 Web 服务器，这时本应去往 App 服务器的流量，需要回到物理 F5 设备再次进行负载均衡处理 （当然，这一步可以通过部署 VE 版本的 BIG-IP 来实现， 以优化流量路径），然后再去往 App 层。当流量抵达 App 层时，则直接通过分布式逻辑路由器，去往数据库搜寻相关信息。 App 层与数据库层的通信流量一般不会经过负载均衡、应用交付设备。

11.2.4 与分布式路由器平行部署 F5 应用服务

        第二种部署方式是使用物理 BIG-IP 设备，基于 VLAN，与 NSX 分布式逻辑路由器平 行部署应用服务。与第一种部署模式相同，同样可以使用 BIG-IP VE 版本部署在逻辑网络 内部，并由 BIG-IQ 统一管理。 图 11.10 所示为这种部署模式的逻辑拓扑图。可以看到， 物理 F5 BIG-IP 设备部署在外 部网络，它并不与 NSX Edge 直接相连，它的位置是与 NSX 分布式逻辑路由器平行的。在 内部网络，分布式路由器主要使用 VLAN 连接应用的 Web 层、 App 层、数据库层，并为它 们提供网关，并使用标准的 802.1Q 封装将基于 VLAN 的逻辑子网连接到物理 BIG-IP 设备 所在的物理网络的子网。由于物理 F5 BIG-IP 设备可以提供动态路由功能，因此，流量需 要由物理 BIG-IP 设备处理时， 并不需要关心分布式路由器的部署，而是直接由物理 BIG-IP 设备处理路由，并作为 Web 层或 App 层流量的下一跳。

再来看一看与分布式路由器平行部署应用服务的模式在数据中心机房的机柜中如何部署。 在图 11.11 中可以看到，使用这种部署模式，物理 BIG-IP 设备是直接连接数据中心骨干节点的， 并不部署在 NSX Edge 机柜中，这是因为它与分布式路由器的位置是平行的，不与 NSX Edge 进 行物理连接。安装了虚拟机和应用的服务器机柜（Computer Rack）通过枝叶节点 ToR 交换机连 接到骨干节点，并由部署在骨干节点的物理 BIG-IP 设备处理其流量。

        需要访问 Web 服务器 VIP 客户端的流量，首先前往物理 F5 设备进行 NAT 转换和负载 均衡处理。之后，流量会直接访问 Web 服务器，而不需要经过分布式路由器。 这是因为提 供路由功能的物理 BIG-IP 设备直接通过 802.1Q 连接到了逻辑网络。之后，流量需要访问 App 服务器，这时候流量需要在物理 BIG-IP 设备绕行一圈以进行负载均衡处理（同样越过 分布式路由器）。最终，被部署在骨干节点的 F5 设备处理过的流量经过分布式路由器访问 数据库。

11.2.5 使用单臂模式部署 F5 应用服务

        最后一种部署方式是使用 BIG-IP VE 版本，基于 VXLAN Overlay，利用单臂模式进行 应用服务的部署，这也是在 NSX 网络虚拟化环境中推荐的部署模式。 这种部署模式与使用 NSX Edge 的单臂模式负载均衡的部署完全一致。 在图 11.12 中可 以看到， 在内部网络，分布式路由器通过 VXLAN 连接应用的 Web 层、 App 层、数据库层， 并为它们提供网关。 NSX Edge 连接外部网络。整个拓扑图中没有物理 F5 BIG-IP 设备，这 是因为在这个架构中， BIG-IP VE 版本是安装在 ESXi 主机中的虚拟版本，它通过 Active/Standby 模式或 Active/Active 模式部署在逻辑网络内部。

        在冗余性方面，无论物理 BIG-IP 设备还是 VE 版本 BIG-IP 设备，都支持集群式的 Active/Standby 或 Active/Active。 一个集群最多支持 32 台 BIG-IP 设备，而且在 Active/Standby 模式，还支持 N+1 或 N+M 的 冗余， 以便实现更高级的故障切换。换句话说，物理服务器数量在 32 台以下时，就可以在 每台服务器上都安装 VE 版本 BIG-IP，以在服务器集群内部实现分布式负载均衡。如果数 据中心机柜数量在 32 台以下时，也可以在每个机柜部署一台 VE 版本 BIG-IP，在机柜之间 实现分布式负载均衡。当服务器或机柜数量超过 32 时，可以对应用进行分类并增加集群， 而所有集群内的 BIG-IP 设备都可以由 BIG-IQ 进行统一管理。其实一个 vCenter 集群中的 ESXi 主机很少会超过 32 台，因此，利用 BIG-IP VE 版本实现基本分布式负载均衡适用于 绝大部分案例。

        值得注意的是，由于只有在外部网络的客户端访问 Web 服务器时，或 Web 服务器与 App 服务器交互时，才需要实现负载均衡服务（App 层与数据库交互时的处理由 Oracle 等 数据库软件提供商提供高级策略），因此利用 F5 设备实现分布式负载均衡时，只需要在提 供 Web 服务的虚拟机所在的 ESXi 主机安装 VE 版本 BIG-IP 软件，并将这些安装了 BIG-IP VE 版本的 ESXi 主机部署成集群模式。 图 11.13 所示为使用单臂模式部署应用服务的物理架构图。 在数据中心机房的机柜中的部 署上，推荐将安装 VE 版本 BIG-IP 的服务器安装在服务器机柜（Computer Rack），而不是 Edge 机柜。其余设备的安装位置与第一种部署方式完全一致—将服务器机柜和 Edge 机柜的枝叶 节点 ToR 交换机连接至骨干节点， Edge 机柜的 ToR 交换机同时连接外部网络。

 

        现在看一下这种部署模式的流量模型。需要访问 Web 服务器 VIP 客户端的流量，在 NSX Edge 上进行 NAT 之后进入逻辑网络，并前往 VE 版本 F5 BIG-IP 设备进行负载均衡 处理。之后，流量分别经过 Web 服务器、 VE 版本 F5 BIG-IP 设备、 App 服务器。 这些都 是在 NSX 网络虚拟化平台的逻辑网络内部完成的，这样就能在 NSX 与 F5 的集成解决方案中利用到了 NSX 网络虚拟化平台的各种优势，如大幅精简流量跳数等。流量最终访问 的数据库，同样可以在逻辑网络内部完成，但现今企业也可能使用物理服务器部署数据 库服务器。

11.3 总结

         对于 NSX 与第三方防火墙厂商的集成，将流量重定向至 Palo Alto 或 CheckPoint 的全分布式的、基于虚拟机的 NGFW 进行处理， 可以帮助 NSX 实现网络虚拟化环 境中的 5-7 层安全。  NSX 还可以集成第三方防病毒厂商解决方案，对服务器内部的病毒进行主动防御。

         对于应用交付， NSX 主要与 F5 等厂商合作，实现自动化的负载均衡和高级应用策 略，实现应用交付的自动化，最终将 NSX 网络虚拟化平台打造成一个以应用为中 心的平台，同时实现 SDDC 和 SDAS。

         NSX 与 F5 的集成解决方案有三种部署方式，除了类似于利用 NSX Edge 实现的单 臂模式和在线模式的负载均衡外，部署在物理网络的 F5 设备也可以集成到 NSX 网络虚拟化环境。推荐使用 VE 版本的 F5 BIG-IP 设备利用单臂模式进行部署。  NSX 与第三方顶尖的专业安全或应用交付厂商的解决方案充分集成之后，可以给 用户带来前所未有的网络功能体验，并全方位保留用户的使用习惯及管理界面。 

第12章 NSX 的底层物理网络设计

        在设计数据中心时，虽然利用 NSX 网络虚拟化平台实现了逻辑网络和物理网络的解 耦，但是物理网络真的可以完全没有规划地进行部署了吗？ 答案当然是否定的。我们需要将底层物理网络打造成最适合部署 NSX 网络虚拟化平台 的 Underlay，这样才能设计出完整且完美的数据中心基础架构。

        有些时候，企业实在没有 办法优化底层物理网络的架构。 这些企业有的是因为在合并多家公司后，将这些公司原来 的网络整合在一起，物理连接和路由选路极其复杂；有些是在设计网络之初没有考虑到未 来的扩展性，或最初设计数据中心网络时，遵循了旧的设计思路，没有使用现今流行的架 构。 这些情况就导致了当应用需求增大后，网络在扩展时与原有网络的整合非常混乱。这 些企业都可以利用 NSX 网络虚拟化平台与物理网络解耦的特点，创建一套独立的逻辑网 络。然而，如果在新建数据中心时就对物理网络更好地进行规划，底层 Underlay 平台就可 以更好地支持 NSX 逻辑网络。

         本章将讨论底层物理网络和服务器如何承载使用了 Overlay 技术的 NSX 网络虚拟化平 台。 本章首先会讨论如何设计底层物理网络才能更好地运行 NSX 平台， 之后还会讨论网络 厂商是如何更好地支持 NSX 平台的—如何利用物理硬件网络厂商 Arista Networks 和 Brocode 的物理网络产品来搭建适合运行 NSX 网络虚拟化平台的 Underlay。最后讨论这些 物理交换机的部署位置，并设计 NSX 中的不同集群。

12.1 为 NSX 而打造的 Underlay

        本节将会讨论承载了使用 Overlay 技术的逻辑网络的物理网络在数据中心中的架构设 计。 本节首先会讨论数据中心的物理网络要求，并阐述如何优化物理网络以使其更加适用 于网络虚拟化环境，之后会讨论如何设计最适合 NSX 网络虚拟化平台的 Underlay。

12.1.1 数据中心物理网络架构的演进

        在讨论部署如何物理网络才能够最好地支持网络虚拟化平台之前，先来回顾当前数据 中心网络架构的变化和未来趋势。在几年之前，大部分数据中心网络都是以模块化的方式 部署的，如图 12.1 所示。

        在数据中心网络中，有一个叫作 POD（Point of Delivery） 的概念。 每一个 POD 就是 一个业务模块，它一般按照业务功能区域划分，因此将其称为模块化的部署方式。在物理 拓扑上，一般来说，一个 POD 由两台冗余的汇聚层交换机作为这个 POD 的业务核心，这 两台交换机下连多个机柜的 ToR 接入交换机，并上连数据中心核心交换机。

        这种部署方式 参考了传统园区网络经典的“核心-汇聚-接入” 结构，这样设计的初衷是为了限制二层广 播故障域。然而这样的设计更适用于园区网络中最常见的南北向流量的优化。在数据中心 网络中，东西向流量远远多于南北向流量，这样部署的网络会造成数据中心网络在扩展时 的不灵活与 VLAN 编排上的限制，且容易形成复杂的生成树。 此外，不同 POD 之间的应 用在相互访问时，东西向的三层流量都需要经过核心网络设备，不但流量路径是不优化的， 还会给核心网络设备造成很大压力。

        因此在近几年，这种经典的模块化的数据中心网络部署逐渐被一种基于“骨干-枝叶” （Spine-Leaf）节点来进行互联的架构所取代了。 这样的部署使得数据中心网络更加扁平化， 效率更高。因此，网络内部日益增长的东西向流量的通信需求就会得以优化，应用的部署 在需要进行扩展时也不会再局限于传统架构中每一个 POD 内的二层域中。图 12.2 所示为 利用这种数据中心网络架构部署的网络拓扑。

        这种典型的基于骨干-枝叶节点的架构一般称为 Folded CLOS 架构，可以把它理解为折叠式 的骨干-枝叶节点全互连架构。目前，大多数企业在大型数据中心都使用这样的部署方式，以在增 强数据中心网络可扩展性的同时实现ECMP，并消除网络中的生成树。 Folded CLOS 网络中的每 一个设备都是网络的骨干节点或枝叶节点，设备具体是什么节点取决于它部署在网络中的位置。  枝叶节点（Leaf）：在现今的数据中心网络中，枝叶节点取代了传统架构中的汇聚 层和接入层设备，枝叶节点交换机一般是低延迟且包转发能力极强的 ToR 交换机。

        在每个机柜中部署一对冗余的枝叶节点交换机，使用至少双链路连接数据中心服 务器或存储设备。如果使用以太网枝叶节点交换机连接存储设备，存储设备的网 络接口需要支持 iSCSI；如果存储设备的接口是传统 FC 或 FCOE 接口，则需要枝 叶节点交换机的端口支持这些存储协议。有些读者可能会问， Brocade 或 Cisco 这 些厂商不是有专门支持 FC 或 FCOE 的交换机，用于搭建一套独立于以太网的 SAN 网络吗？为什么现在需要用枝叶节点交换机来连接存储设备呢？ 原因是数据中心 网络需要实现架构上的扁平化和管理上的一体化。 如果还是使用传统 SAN 网络与以太网分离的部署方式，则在现代数据中心中无法实现效能和效率的最大化。

        现 今，已有多家物理网络设备厂商的产品支持在一台 ToR 交换机上同时实现以太端 口和 FCOE 端口，有些厂商甚至还能在此基础之上同时开启 FC 端口，如 Brocade、 Cisco 和 ALE（Alcatel-Lucent Enterprise）。  骨干节点（Spine）：在现今的数据中心网络中，骨干节点交换机取代了传统架构中 的核心层设备。在传统的部署架构中，核心设备一般使用两台高端机框式交换机实 现集群或互为冗余，然而在网络大幅扩张时，两台核心设备可能无法处理日益增长 的东西向流量。因此， 在骨干节点会使用多台高端机框式交换机，与所有枝叶节点 实现全互连。在全互连之后，就可以使用 FabricPath、 TRILL 或 SPB 等大二层技术， 在消除网络中的生成树同时，实现 ECMP。值得注意的是，骨干节点的各台交换机 之间一般不进行直接互连，这是为了让 ECMP 的选路效果达到最优化。

          边界枝叶节点（Border Leaf）：有些企业可能在部署数据中心网络时，将骨干节点 设备直接连接外部网络（如 Internet 或 WAN）。但是推荐使用一对专门的边界枝叶 节点设备与外部网络互连，这样一来，数据中心内部服务器与外部的通信流量也 成了一种“伪东西向流量”，而不是传统意义上的南北向流量—在数据中心网络 和应用中的诸多特性和功能都是针对东西向流量优化的，并且也没有必要针对传 统的南北向流量配置更多专门的策略。

        如今，更多客户更加倾向于将这种 Folded CLOS 架构部署为全路由的数据中心网络，骨 干节点和枝叶节点不再是三层网络和二层网络的边界，枝叶节点的 ToR 交换机也逐渐需要引 入功能强大的路由功能。这样一来， ToR 交换机下属的物理服务器或虚拟机之间的本地三层 流量就无需经过骨干节点，还可以在全网（跨越所有骨干节点和枝叶节点）对高带宽的可用 性、突发流量的可预见性和配置保持一致性。此外，如果在整个 Folded CLOS 架构中，物理 交换机是来自不同厂家的设备，还可以提高设备的互操作性和整体的弹性，因为很多路由协 议和大二层协议都是公有的。然而，这样的设计还存在一定的挑战，尤其是对应用需要在不 同枝叶节点之间进行二层连接时的支持不够—每个枝叶节点在需要进行二层域扩展时是 有限制的。因此，网络虚拟化技术浮出了水面，它将物理网络和逻辑网络进行解耦，允许在 逻辑空间内进行任何方式的连接，且独立于底层物理网络的物理连接和配置。

         当然，在网关规模不大的时候，骨干节点交换机可能只有两台，枝叶节点交换机数量 也不会非常多。如图 12.3 所示，这其实也是 Folded CLOS 架构，只是骨干节点只有两台设 备， 枝叶节点也比较少而已。 Folded CLOS 架构给现代数据中心带来了非常多的优势，越来越多的企业希望在新 建数据中心时使用这样的方式部署物理网络。一些几年前就已经使用模块化的多 POD 架构建好了数据中心的企业，也希望将它们先前的数据中心应用架构迁移至新的 FoldedCLOS 架构中来。但是由于物理网络架构的不同，导致各种网络路由、交换、安全策略 都不尽相同，还需要细化两套网络中的连接策略。 这些因素都对应用迁移带来了巨大的 挑战。如图 12.4 所示， NSX 网络虚拟化平台由于实现了物理网络和逻辑网络的解耦， 可以无需关心底层网络架构，跨越这两套物理网络架构创建共同的资源池，实现一致的 网络服务模式，最终实现应用的无缝迁移和完整的业务连续性。