图1. DCFabric：面向云计算数据中心的开源SDN控制器

admin

ODL和ONOS等虽然在拓扑性能和应用开发便利度上有了很大进步，但是它们的灵活性、工作速度和效率仍有待提高。因此，随着大数据浪潮的到来，我们迫切需要可面向云计算数据中心的性能更完善、开发更便利、效率更突出的SDN控制器。
为了解决上述问题，我们设计了一款面向云计算数据中心开源SDN控制器——DCFabric，其从上至下依次可分为五层（见图1）：第一层是控制器支持的Web应用层，第二层是北向接口层，第三层是包含SFabric模块的系统应用（System APP）层，第四层是为上层应用的正常运行提供保障的基础服务层，最后是基于OpenFlow等协议的南向接口层。

</p>图1. DCFabric：面向云计算数据中心的开源SDN控制器

DCFabric可支持的Web应用主要包括Web GUI、Neutron接口、流量工程、防火墙、负载均衡、DDoS防御等。因此，DCFabric可为数据中心在网络管理、网络虚拟化、网络安全、网络流量控制等方面提供一系列支持。
Restful API是DCFabric向上层应用开发者提供的北向接口，它能将网络应用和网络细节彼此隔离，使得网络中的各种设备、事件（如链路中断）和具体操作对应用程序而言都是透明的。因此，数据中心可通过各种灵活的网络应用来提升用户的体验，实现网络的智能化和安全化。
相比较已有的其它SDN控制器，DCFabric主要有两点不同：

SFabric模块：不同于在主机级别进行路由规划的一般SDN方案，含有SFabric模块的DCFabric可在交换机级别进行路由规划。由于网络中的交换机数目一般远低于主机数目，所以SFabric能有效地降低网络的流表数目和DCFabric的工作负载，从而使DCFabric有更快的工作速度（具体内容请见章节3.1）。由于在网关、路由、网络地址转换（Network Address Translation, NAT）、多租户管理等方面有着更好的工作效率，所以DCFabric可对规模日益增长的云计算数据中心网络实现高效的控制和管理。支持再次开发：DCFabric还支持系统应用的再次开发，即允许其他开发者根据自身的具体需求对控制器进行相应的更改。因此，DCFabric具备更强的兼容性以及更广阔的应用空间。

考虑到单个控制器的工作能力毕竟有限，为了应对数据中心不断增长的网络规模以及保证其健壮性，DCFabric还支持控制器的集群化（Cluster）部署。如果某个控制器出现问题，则SDN交换机可马上连接另一个控制器。并且多个控制器通过协同工作表现为一个逻辑实体，使得数据平面对应用程序而言是透明的。因此，DCFabric的集群化对于实现高吞吐量、低时延、好的灵活性以及强稳定度的数据中心是非常有益的。

2、DCFabric的主要特点

SDN控制器虽有利于网络资源利用率的提升，但随着数据中心规模的扩大，SDN控制器仍面临着一个主要问题：交换机和用户主机数目的增长，使得每个交换机需存储的流表内容也在相应增加（理论上每台交换机上的流表最多需覆盖到网络中的所有主机），这不仅需要每台交换机有更大的存储容量和更快的查询速度，也对SDN控制器的工作效率提出了更高的要求。
我们对现有的SDN控制器进行了改进，设计了新颖的SFabric架构，使得SDN控制器的工作负载大大减少，从而有效地提高了控制器的工作效率。
在SFabric中，每个交换机都会向其所有的端口发送链路层发现协议包（Link Layer Disvovery Protocol, LLDP）。由于主机会自动忽略LLDP包，所以之后每个交换机就可知道到底哪些交换机是和其直接相连的。当DCFabric从各个交换机获取了一定信息后，就可知道整个网络的交换机拓扑情况。接下来，DCFabric会为每对交换机之间设置一条通信路径（出于流量均衡等考虑，该路径并不一定是最短路径），并且为所有目的交换机（与目的主机直接相连的交换机）相同的路径设置一个专门的标签（目的交换机的ID）。然后，DCFabric会把路径信息装载到交换机的流表项中，这样交换机就能根据标签来转发数据包。以图3为例，假设交换机1到交换机2、3、4、6的路径分别为1→2，1→3，1→2→5→4，1→3→4→6，则交换机1的路由表将如图3底部的表格所示。例如，第四个流表项表示标签为6（目的交换机为交换机6）的数据包将从交换机1的端口2输出。因此，SFabric可帮助DCFabric实时迅速地构建好交换机级别的路由规划，从而为后续数据包的端到端单播路径建立预先做好准备。

图2. SFabric架构

当然，考虑到与其它现有OpenFlow交换机的兼容性，SFabric也允许用VLAN ID或MPLS Label替代目的交换机ID。由于OpenFlow从1.1版开始就可支持多流表，所以SFabric在每个交换机中都建立了四个流表来实现流水线式处理，具体如图4所示。假设在流表中使用VLAN ID作为路由标签，四个流表的具体结构和工作过程如下。

图3. SFabric中每个交换机所含的四个流表

Table 0用于包的预处理。它包含p+2个流表项，其中p表示与当前交换机直接相连的交换机的个数。p个流表项的格式为“port=i, ip, actions=goto table:2”，其中1≤i≤p，表示将来自其它交换机的IP包送往Table 2。剩下的2个流表项格式为“ip, actions=goto table:1”和“arp, actions=Controller”，表示将来自当前交换机下的本地主机的IP包和ARP包分别送往Table 1和DCFabric。
本地主机的数据包在发送前需要在当前交换机被打标签，而Table 1则负责存储执行相应操作的流表项。因此，Table 1在初始化后是空的，需要在后续的网络会话通信中逐渐丰富其中的流表项。
Table 2则根据目的交换机的ID来转发数据包，它最多可包含s个流表项， s表示网络中的交换机总数目。其中s-1个流表项的格式为“dl vlan=i, actions=output:j”，表示将VLAN ID为i的数据包通过当前交换机的端口j被发送出去。最后1个流表项的格式为“dl vlan=k, actions=pop vlan, goto table:3”，其中k为当前交换机的ID号，表示若当前的交换机下就是目的交换机时，则数据包应发往Table 3。
Table 3根据数据包的MAC或IP地址，将收到的数据包发往当前交换机下的某个目的主机。所以Table 3在初始化后也是空的，每当当前交换机下的某个主机被发现时，就在Table 3中建立一个相应的流表项。
因为交换机级别的网络拓扑已被预先建立，DCFabric才可对数据包路径建立的流程进行优化，即DCFabric对目的主机相同的通信需求只需进行一次处理，从而使网络流的表数目和DCFabric的工作负载都大幅降低。

图4. 任意两台主机之间的单播路径建立过程

当DCFabric收到一条来自交换机的packet-in信息时（比如ARP请求），它需要首先确定源主机和目的主机的地址。如果DCFabric的数据库中暂时没有目的主机地址的信息，那么DCFabric将会把该ARP请求以泛洪的方式发送到所有交换机的每个端口。无论是获得ARP请求或ARP响应，一旦DCFabric捕获到一台新主机的信息，它就会在与新主机直接相连的交换机的Table 3中添加一个新的流表项。图5描绘了源主机A（与交换机1直连）和目的主机B（与交换机6直连）之间的单播路径建立过程。step1和step2是将ARP请求传递到DCFabric。当DCFabric收到来自目的主机B的ARP响应后，它会分别向交换机1和6的Table 3各下发一个流表项（step 3和step4），它们的格式分别为“ip, nw_dst=IP_A, actions=output:3”和“ip, nw_dst=IP_B, actions=output:1”。前者表示主机A与交换机1的端口3直连，后者表示主机B与交换机6的端口1直连。
接下来，DCFabric向源主机A发送一条ARP响应消息，并分别在交换机1和6的Table 1中各装载一条流表项，如图5底部所示（step 3和step4）。以交换机1中的Table 1为例，前往目的主机B的数据包会被打上目的交换机6的ID标签（step 5和step6）。单播路径沿途的交换机则会根据目的交换机的ID对数据包进行转发。当数据包到达目的交换机6后VLAN ID会被清除，然后该数据包会被转发到目的主机B。反向传递也是如此，不同的是标签变成了交换机1的ID。
因此，在网络运行时，DCFabric可实时感知交换机的状态是否发生任何改变（比如新交换机的加入或旧交换机的退出等），并以增量更新的方式通过对网络的局部调整来快速构建新的网络拓扑和交换机路径。
SFabric具有良好的可扩展性，尤其适用于包含大量交换机和主机的超大型数据中心。一般来说，网络中的交换机和主机数量越多，往往意味着一个交换机中需要维护的TCAM表也就越大，相应地会造成查找表的成本上升和效率下降。因此，网络中的流表项数目便成为评估一套SDN方案是否具备良好可扩展性的重要依据。在SFabric中，假设单个核心层交换机中最多含有s′个流表项（s′是接入层交换机的数目），和网络中的主机数量无关。对于接入层的任何一个交换机来说，其中的Table 2的流表项上限为s′；Table 1的流表项个数H等于和当前交换机下所有主机有会话通信关系的主机数目。假设单个主机最多会和α个主机通信，则H = pα，其中p为当前交换机下的主机数目。因此，网络中流表项数目N的最大值如式（1）所示，其中s为核心层和接入层中所有的交换机数目。
(1)又因为网络中的主机数目远远大于交换机的数目，因此s + pα ≈ pα，则N ≈ s′pα。然而，在大多数其它SDN方案（比如OpenDayLight和Ryu）中，每个交换机需要为网络中的每对主机至少配置一个流表项，因而造成网络中的流表项数目N′如式（2）所示，其中β为每条路径平均包含的交换机数目。
(2)因为N/N′ ≈ s′/s/β 在传统的以太网或其它SDN方案中，核心层的交换机往往因为需要维护大量的信息而导致TCAM过于庞大，因此限制了网络的规模。然而在SFabric中，接入层的交换机可以是软件虚拟机，因而相对物理交换机而言可维护更多的流表项；并且由于核心层交换机是面向接入层交换机的，所以每个核心交换机中的流表项数目可以是一个和主机数目无关的较小的固定值(s- s′)  s′。交换机中流表数目的降低，不仅使SFabric具有非常良好的可扩展性，而且同时意味着控制器的工作负载（包括流表信息维护以及与交换机之间的沟通交互操作等）和成本也相应有所减少，所以SFabric有着更好的工作效率、速度和吞吐量。如表1所示，相对传统网络或已有的SDN技术而言，SFabric能帮助DCFabric在同一网络中控制更多的交换机和主机，并且拥有更快的工作速度。

	传统网络	现有SDN	SFabric
交换机数量	N*10	N	N*100
主机数量	千级	百级	万级
连接建立时间	秒级	秒级	毫秒级

表1. 各种技术之间的比较

3、无缝融合云计算平台OpenStack

图5. DCFabric和云计算平台OpenStack的无缝融合

由于DCFabric可向OpenStack提供可支持最新Juno版本Neutron API接口，所以OpenStack可通过该接口与控制器进行网络和地址管理方面的交互。作为OpenStack和下层网络转发设备（SDN交换机）的中间媒介，DCFabric兼具传统转发设备中的网关、路由和NAT等功能，可对网络资源进行集中控制，并支持物理/虚拟交换机的混合组网。因此，如图6所示，DCFabric可以与云计算平台OpenStack实现无缝融合，对网络资源实现集中管控、资源池化、多租户共享和在二层网络的安全隔离，提升面向公有云资源的服务体验（比如虚拟私有云（Virtual Private Cloud, VPC）），为大型数据中心的大吞吐量数据交换提供有力的技术保障，促进云计算产业的发展。

4.与其它SDN控制器的比较

	ODL	ONOS	Ryu	MUL	FloodLight	Nox	Pox	Beacon	DCFabric
Openness	***	***	****	****	****	***	***	***	****
Topological performance	****	**	*	****	***	**	**	***	*****
Switch performance	***	***	***	***	*	*	*	*	*****
UI	****	**		**	**	**	**	**	*****
Reliability	**	*****	*	***	*	*	*	*	***
Special application	OpenStack, SFC, SDNI, AAA	The multi-layer network, SDNIP	OpenStack, the separation of tenants						SFabric, OpenStack, Enterprise network
Application type	Core+Web	Web	Core+Web	Web	Web	Core	Core	Core	Core+Web
The development convenience	**	****	***	***	**	**	**	**	****

表2. DCFabric与其它SDN控制器之间的比较


5、总结
DCFabric是我国第一款基于SDN的开源控制器，目标是为大规模云计算数据中心提供一套切实可行的SDN开源技术方案，主要具备以下优点：
1）与已有的其它SDN控制器相比，DCFabric的灵活度强、可靠性高、智能化高、吞吐量大、延迟低。
2）其北向接口可与云计算平台OpenStack无缝融合，支持各种网络应用，降低创建新服务的难度，为网络应用开发带来敏捷性。
3）其南向接口支持OpenFlow协议的转发设备，并且具备可与传统网络设备兼容的特性。
该项工作有利于促进我国SDN技术在自主创新方面的快速进步，以及云计算产业和数据中心业务的发展。
作者简介：
蒋暕青@上海宽带技术及应用工程研究中心：SDN技术实践者，大四北上思博伦实习半年，现工作地点上海
声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。