SDNLAB技术分享（七）：开源SDN控制器DCFabric及云计算高效网络

1.DCFabric控制器的由来 1.1 SDN是云计算数据中心网络技术发展的必然要求

随着以虚拟化为基础的云数据中心的发展和成熟, 应用数据猛增，虚拟服务器的迁移等要求VLAN可延展到所有汇聚层、接入层交换机。传统二层技术存在链路冗余能力、负载均衡能力、可扩展性和网络稳定性差等诸多缺陷。因此，大二层网络技术如Trill、SPB等应运而生，却存在过长收敛时间、低转发效率、有限网络规模和昂贵的专有设备等缺点。而SDN则凭借其大二层网互通、全网拓扑、以及多路径流量均衡等灵活高效的功能，使其成为构建数据中心大二层网络的理想方案。 1.2 SDN控制器在云计算数据中心的主要挑战

随着数据中心规模的扩大，SDN控制器面临的主要问题：交换机和用户主机数目的增长，使得每个交换机需存储的流表内容也在相应增加（理论上每台交换机上的流表最多需覆盖到网络中的所有主机），这不仅需要每台交换机有更大的存储容量和更快的查询速度，也对控制器的工作效率提出了更高的要求。尽管当前已有若干开源SDN控制器，但受制于性能和可扩展性等，它们所能管理的网络规模还有限，尚不具备直接的商业化运营的能力。因此，随着大数据浪潮的到来，我们迫切需要可面向云计算数据中心的高性能SDN控制器。

1.3 DCFabric：面向云计算的SDN开源控制器

为了能尽快推进SDN技术在云计算数据中心的产业化应用进程，在国家高技术研究发展计划（863计划）项目“软件定义网络（SDN）关键技术研发与示范”的资助下，上海宽带中心、武汉绿网、中国电信联合设计开发了面向云计算数据中心的开源SDN控制器——DCFabric控制器（http://www.sdn863.org.cn/）。

图：DCFabric控制器架构 相较于其他开源SDN控制器，DCFabric具有以下的主要特性：

1）基于高效C语言，借助于高效的内存管理能力和多线程优化，DCFabric具有强大的拓扑发现（单实例>1000个交换机）、消息处理和流表下发能力（>100,000 OpenFlow流表/S）。

2）针对数据中心网络流量特点创新地提出了基于流表预先下发和流表聚合的SFabric算法，突破了物理OpenFlow交换机流表数量限制和通信路径建立的抖动等难题，从而实现了基于物理OpenFlow交换机的超大规模组网与高效交换。

3）架构简洁，南向接口只支持OpenFlow和OVSDB，基于四种基础服务，致力于云计算环境下的网络交换。

4）易于扩展，可方便灵活的进行系统定制，实现各种场景下的SDN应用。

2.SFabric算法

当前主流的SDN网络中的流表下发方式主要有两种：前应式（Proactive）和反应式（Reactive）。由于在云计算环境下的NAT等功能的要求，反应式的流表下发是必不可少的。受制于OpenFlow流表下发的不确定性和并发性下发的复杂性，通信路径的建立常会出现由于交换机和控制器之间的多次Packet-in消息和流表下发的交互而带来的长时间剧烈抖动，且随着通信路径的增长而快速恶化。再加上交换机TCAM流表容量有限带来的限制，已有的云计算数据中心内的SDN方案一般采用基于传统交换网上的通道技术的OVERLAY网络方案：控制器只控制网络边界的虚拟交换机。这不仅会带来由于封包、解包所带来的性能下降问题，而且会导致在物理网络上的网络流量的不可视、不可控等问题。

针对上述两个问题，SFabric创新性的提出了“两步式”流表下发法和基于交换机ID的流表聚合，从而提高了控制器的效率和降低了流表数量。当控制器完成网络拓扑发现以后，SFabric首先每一个交换机分配一个唯一的Switch ID，然后会为每对交换机计算两条有向的通信路径。计算路径时主要有两个问题需要考虑：一是到同一个目的交换机的路径应该是收敛的，即到同一个目的交换机的所有路径应该是构成一个以其为根节点的树；二是出于流量均衡等因素，应该把所有的路径在整个网络拓扑中做到均匀分布。

计算好路径以后，控制器就会把路径信息以OpenFlow流表的形式装载到交换机中。由于网络中到每一个目的交换机的路径构成一个树，所以需要下发的OpenFlow流表只需要把目的交换机的Switch ID作为匹配字段即可。由于而不需要关心路径的起始点，所以所有交换机中的流表的个数最多只有n条，其中n表示网络中交换机的个数。因此，SFabric可预先构建好交换机级别的路由规划，从而为后续数据包的端到端单播路径建立做好提前准备。考虑到与其它现有OpenFlow交换机和网卡的兼容 性，SFabric推荐采用VLAN ID作为Switch ID存储字段。

图. 示例网络拓扑和SFabric流表 当SFabric构建好转发路径以后，系统就完成了初始化程序。由于网络中交换机之间的转发路径都已建立，当主机实际通信时，控制器只需在主机的接入交换机上下发对数据包进行打标签的一个流表即可。考虑图1中连接在交换机1和6上的两个主机Host A和Host B（其IP和MAC分别为IP_A、MAC_A和IP_B、MAC_B），当其需要通信时，SFabric首先查询其所对应的接入交换机的Switch ID分别是1和6，然后只需在这两个交换机的Table1分别下发如图中所示的两个流表来对数据包添加Vlan标签。

3.基于DCFabric的OpenStack高效网络

3.1当前OpenStack主要网络架构：OverLay

OverLay网络的主要缺点如下：

1）需要耗费主机的CPU资源进行数据的封包和解包过程

2）封包、解包的低效导致了VM的有限的网络吞吐量（<2.5 Gpbs in 10GE链路）

3）在物理网络上的流量的不可视带来的不可控问题

4）南北向流量都需要从网络节点通过带来的流量瓶颈问题

5）网络配置的复杂性带来的配置困难和低可靠性 3.2基于DCFabric的全物理OpenFlow交换机网络

为了能更好的发挥SDN在OpenStack中的应用潜力，避免Overlay网络带来的各项难题，我们提出了基于物理OpenFlow交换机和DCFabric的高效网络方案，其主要优点如下：

1）无须封包、解包带来的高网络吞吐量，10 Gbps环境下的虚拟机最大网络带宽可以达到9.3 Gpbs以上；

2）VM的南北向流量可以直接通过物理交换网转发，不仅南北向带宽可以达到线性速度，而且NAT、Floating IP和负载均衡等高级网络功能都可在控制器的统一调度下由交换机来实现；

3）基于标准OpenFlow协议，无厂商绑定，造价较传统网络方案可大幅降低，而且网络可动态线性扩展；

4）物理网络中流量可视带来的可管可控优势，可支持网络安全功能和流量工程等功能扩展，提高系统的灵活性。

图：基于DCFabric的OpenStack高效网络架构

Q&A Q1:这个控制器的安全机制有那些？

A1：暂时没有考虑控制器本身的安全机制。

Q2:你说的这物理openflow交换机可以介绍一下吗？

A2：

Q3:物理网络的流量不可视的不可控是怎么理解，边界网络性能强劲的话，这个不会影响?

A3：是指的在Overlay网络中，虚拟机的流量在物理交换网上不可视可控。

Q4:用vlan id代表一台sdn交换机的switch id，这个交换机就是跑vlan的，难免vlan id会出现一些冲突，为何不用交换机唯一的mac地址字段去代替switch id ？

A4：应该是用VLAN ID代表一台SDN交换机的ID，是用这个VLAN字段储存交换机的ID

Q5:您上面有说“为每对交换机计算两条有向的通信路径”，这里是指两条可行路径吗？ 然后根据负载均衡条件选择较优的那一条吗？~ 那么，我想问，预置两条路径的道理是什么呢？为什么不是三条或者四条？

A5：两条是指的每一对交换机之间的双向路径。

Q6：我想问一下 您说得流量不可控是怎么理解的？ 还有最后的仿真图上 sorth-north指的是什么 ？

A6：sorth-north指的是云主机和域外的主机通信的流量，即云主机和公网主机的相互访问。

Q7：你介绍的这个流表聚合方式应该不是你们首创的吧？

A7：这种在SDN网络中聚合方式我们之前没有发现过，它的主要思想借鉴了Trill协议

Q8：你好你说得首创的两步式流表下发有那些性能提高呢？

A8：主要是解决了通信路径建立时由于流表的下发没有成功反馈信息而导致的交换机和控制器之间的多次的Packet-in处理流程。

Q9：如果由VLAN来承载Switch ID的，真正的802.1q的tag怎么传递？

A9：如果数据包中本来是有VLAN Tag的，那么我们会多添加一个。在OpenStack环境中，子网等划分也不依靠VLAN。

Q10：请问一下SFabric中提出的出于流量负载均衡，然后将所有路径在网络拓扑中做到均匀分布，是动态的流量负载均衡还是只根据网络拓扑预先设定路径达到负载均衡？

A10：负载均衡是根据网络拓扑的

Q11：我觉得这个流表聚合有点像ospf，每个交换机到另一个交换机率先建立一条ospf路径，那么每个交换机最多只会有n个流表。（当然，这里并不一定非要是ospf路径，要考虑到全局均匀，只要是可行路径就行）我这里还是想问，这里是预设了两条可行路径吗？为什么呢？

A11：那个两条的意思其实是说双向的两条

Q12：我想问下，如果由VLAN来承载Switch ID的，真正的802.1q的tag怎么传递？

A12：我们是通过增加一个vlan标签实现的，其实OpenStack里面是没有vlan的，只有子网

Q13：您好，我想了解一下流表下发的两种模式的，您说的SFabric也都俱备，只不过在主动下发的时候会进行进行流表聚合，尽可能的把多条路径都算出来，后续就算发生链路改变，交换机先前存储的流表也能找到相应的路径，除非变更后的网络找不到路径，才会进行反应式请求对么？

A13：前应式是指的交换机之间的路径的流表是预先下发的；反应式是指的主机通信时在接入交换机上下发的流表。 Q14：还有 刚才说的那个聚合方法也有问题，智能节省中间经由switch的flow entry数，对edge switch没什么效果。所以你们的edge还是以使用ovs为主是吧？

A14：不一定，但是在OpenStack环境中，edge一般都是ovs。

Q15：怎么解决的租户数量的限制吗？

A15：租户的控制是靠的控制器读取OpenStack的租户相关数据

Q16：请问该项目有发表什么论文吗？ 可以给个论文题目，我去搜搜看一下呢

A16：LU Xiaoyuan, Xu Yanwei: SFabric: A Scalable SDN Based Large Layer 2 Data Center Network Fabric, Proceeding of IWQoS, 2015

Q17：这个ecmp如何处理的？

A17：不涉及到ECMP

Q18：你发的那个vxlan的性能用的什么版本ovs测的？ ovs + dpdk，numa和page优化好的话，vxlan 万兆线速没有问题。

A18：非DPDK版本

Q19：你们10K pps的处理能力，指的是packet_in/out再加flow entry installation，barrier request/reply一套transaction全做完。能处理10K transaction么？

A19：10K pps 指的是单纯的流表的下发速度

Q20：这个交换机预设id的命名规则是怎么样的呢？ 根据mac地址吗？

A20：交换机ID是自定义的，只要保证不重复即可 Q21：你们的lb 怎么做的？

A21：目前还没有考虑同一对交换机之间的路径的lb

Q22：物理网络的流量不可视的不可控是怎么理解，能举例么？边界网络性能强劲的话，这个不会影响

A22：这里不可视不可控的意思是说 vxlan的流量全部为物理服务器的IP和MAC的流量，这个其实是没有限制的，如果用group流表来实现的话，但是目前我们还没有实现这个功能

Q23：流表聚合是怎么来聚合的，这个能详细介绍一下么？

A23：流表聚合的思就是说利用主机的接入交换机为依据进行路由 Q24：关于path control，你们两个node间，ecmp最大有几条？我好像看到你在讲解中说的是两条？

A24：两条是说为每对交换机计算双向的两个路径

Q25：那就是拓扑实际存在几条ecmp，就会构筑几条ecmp么？

A25：不是的，只计算一条

Q26：双挂两台ovs，单播流量和bum流量怎么走？

A26：N/A

Q27：我说的那个知识产权是构筑多条ecmp。这个其实没有技术难度，为啥不做呢？

A27：目前还是人力有限，如果您有兴趣可以提供相关代码，欢迎贡献

Q28：研究这个问题的初衷是基于TCAM的数量不足还是控制器流表下发速度及控制能力不足呢？或者说，这两个问题，再以前的架构中，哪个问题表现的更明显

A28：当网络规模比较大的时候，这两个问题都比较严重 Q29：多条ecmp的话不就会增加流表项数目吗，这系统不是要尽量减少流表项吗

A29：可以用Group流表来实现，目前还没有支持ECMP。

Q30：DCFabric控制器现在能做到1+1冗余么？

A30：有主备的实现计划

Q31：vxlan是用vetp走的，用eV**传递vxlan信息，怎么和ip地址的多少有关呢？交换机流表不是256k么

A31：博通的芯片目前支持的TCMP的流表差不多是这个数量

Q32：SFabric交换机中的流表的个数最多只有n条，其中n表示网络中交换机的个数，这个聚合还是N条对吧

A32：这是指的聚合后的流表的数量