《云数据中心网络与SDN：技术架构与实现》——3.3.2　网络传输

3.3.2　网络传输

云数据中心里，Fabric指的是能够为虚拟机间的通信提供高带宽、无阻塞传输的网络。传统数据中心的3-Tier网络，对于Fabric没有明确的需求。云计算兴起后，数据中心的通信模型发生了巨变，前面章节中反复提到过的一些原因，如虚拟机规模的扩张、东西向流量的激增等，使得Fabric成为支撑云数据中心网络的核心技术。高带宽体现在Leaf-Spine设备的线卡由1GE/10GE向40GE/100GE的快速演进，而无阻塞体现在由xSTP转向更为高效的控制逻辑上。

xSTP是一种有阻塞的协议，网络中的链路利用率极低。为了解决这一问题，以TRILL为代表的二层Fabric技术最先兴起，TRILL为二层网络引入了路由的智能，带来了多路径转发（ECMP）的能力。不过，TRILL的运行需要对传输设备进行升级或者更换，而且协议本身仍不够成熟，跨厂商难于互通，维护起来成本也很高。相比之下，OSPF/BGP等传统的路由协议则要成熟得多，它们天生地就支持ECMP，而且部署维护起来也更为方便。不过，三层网络的问题在于不够灵活，虚拟机无法大范围进行二层的迁移。考虑到虚拟机迁移是云数据中心的刚需，而OSPF/BGP无法独立地支持大二层，因此云数据中心的第一代Fabric技术以TRILL为主。

1. Underlay与Overlay

不过部署TRILL可能会带来产商锁定的问题，人们还是希望可以用更为通用的路由协议来运行Fabric。于是，以VxLAN为代表的隧道技术提出在虚拟机二层流量的外面再封装一层IP包头，使得二层虚拟网络得以与Fabric解耦，这样一来，只要是支持路由的交换机，就都可以用来传输大二层的流量。VxLAN在提出后，迅速得到了业界的认可，隧道+OSPF/BGP代替TRILL成为Fabric的新一代技术。不过，隧道技术更多地关注于封装，控制平面往往比较简单，因此SDN和隧道技术的结合成为新的趋势。如标准的VxLAN只能通过二层的自学习来进行转发，二层的泛洪依赖于Fabric对于组播的支持。通过SDN控制平面的全局视图指导vSwitch/TOR上的VxLAN封装，能够有效地抑制泛洪，从而消除VxLAN对于Fabric组播能力的依赖。

从理论上来讲，隧道里面的内容应该对于Fabric的传输来说是透明的。不过出于对虚拟网络流量更好的支持，Fabric需要感知内层包头的一些特征，以方便进行ECMP和QoS的处理，这就需要提供内层包头字段向外层包头字段映射的机制。VxLAN使用外层UDP源端口号和外层IP DSCP字段实现ECMP和QoS，其他隧道协议也各有各的映射规则。不过，这种映射的控制是发生在vSwitch/TOR中的，Fabric使用这些字段也只是服务于传统的路由协议和DiffServ。ECMP的处理依赖于Fabric设备中的算法，往往是通过<源IP，源端口号，目的IP，目的端口号、协议类型>的五元组进行哈希。而QoS的实现依赖于管理员对Fabric设备进行手工的配置。

2. Underlay的自动化

从上述描述可见，OSPF/BGP+ECMP Fabric只是作为VxLAN等隧道技术的Underlay，SDN的控制逻辑（隧道外层包头的封装、标记策略）主要仍发生在网络边缘。也就是说，转发作为Fabric的主要逻辑是不依赖于SDN控制器的，而依然通过传统的路由协议来支撑。从提供连接的角度来说，传统的路由协议已经做得足够好了，用SDN控制器来定义Fabric的转发，目前还没有看到明确的场景和需求。但是为了实现网络边缘和Fabric的统一管理，简化Fabric上的手工配置，很多厂家开始考虑将Fabric的管理功能从网管软件转移到SDN控制器中，作为云数据中心网络提供单一的管控入口，虽然有别于通过OpenFlow对FIB直接进行编程，但这仍然可以算得上是广义上的SDN。例如，在ZTP（Zero Touch Provisioning）技术中，管理员可以预先为Fabric编写好脚本，为设备分配好角色、ID以及OSPF/BGP参数，设备加电之后会通过DHCP Option获得控制器的地址，从控制器上同步这些配置的脚本，并在本地自动加载这些配置，省去了手动对Fabric进行初始化的工作。对于一些更为复杂的Fabric管理场景，比如涉及事务性的操作，可以通过或者NETCONF作为南向的配置协议，或者使用Puppet、Ansible等自动化部署工具来完成。

3. Underlay SDN

当然，用SDN来定义Fabric的转发完全是可以实现的。相比Internet，数据中心Fabric的网络结构和地址规划都是相对简单和固定的，OSPF/BGP这类分布式路由协议并不会带来明显的优势。相比分布式路由协议，基于SDN的Fabric可以提供更为精细的流量策略（QoS），能实现对拥塞的动态调优（大象流），当网络发生故障时有利于提供精确定位和自动修复，当网络进行割接时也能够更加有效地进行路径切换。当然，少数厂商的转发设备上也实现了拥塞自适应、隧道OAM等特性，不过这些特性需要深度定制化的芯片来提供支持，无法做到跨厂家互通。

如果使用SDN来控制Fabric的转发，那么网络边缘的隧道技术就变得不是那么必要了，从学术角度来讲，通过在边缘对现有字段的重新规划，足以满足云数据中心对于网络的需求，还可以消除由隧道封装所带来的开销。当然，使用SDN来控制Fabric也并不意味着网络边缘就不能使用隧道。

另外，随着光端口成本的降低和光交换技术的成熟，未来的数据中心网络有可能会向IP + 光的架构进行演进，那么流量的特征感知、光路的自动开通、IP光的智能协同，这些都需要SDN对网络的传输进行全局的管理与控制才有可能得到实现。

不过，如果从现实的角度来考虑，基于SDN的Fabric需要对数据中心网络进行较大的改造，推动起来存在着很多的阻碍因素。尽管如此，国外还是有一些SDN创业公司选择走上了这条技术路线，希望通过SDN + 白盒彻底地改造云数据中心网络。相比之下，国内的环境要保守得多，无论是互联网企业还是运营商，都鲜有魄力承担“对网络动大手术”的风险。