您好,欢迎来到 DCFabric

ENGLISH中文版

DCFabric V5.0“汉”版本正式发布 2019/1/24 18:35:06

经过1年多的工作努力,我们很高兴正式发布DCFabric v5.0 “汉”版本,目前已经可以通过GitHub下载代码,地址为https://github.com/China863SDN/DCFabric/tree/master/DCFabric-Plus。为了能实现功能的灵活扩展和克服前面的C版本的缺陷,我们采用C++语言重新构建了DCFabric。


图:DCFabric汉版本架构


该版本既继承了前面四个版本的SFabric高性能交换、基于预分配的高效内存管理等技术,又实现了在灵活性和性能方面的全面提升,具体来说体现在以下4个方面。

 (1)完备的二三层网络管理模块

前面版本的DCFabric不具备独立的网络管理功能,必须要对接OpenStack才能实现对二三层网络的管理。在汉版本中,我们借鉴OpenStack的Neutron组件设计实现了网络管理层模块,具备完整的二三层网络功能,包括租户、子网、NAT、浮动IP、安全组等。这样带来的一个优势是我们不再依赖于OpenStack平台,从而可以基于OpenFlow交换机构建交换网络,并且可以通过Restful API接口对接多个上层应用实现跨平台通信。下图是基于DCFabric“汉”版本构建的国家863项目“软件定义网络(SDN)规模验证与应用示范”规模试验网。


    


图:863 SDN规模试验网


      (2)最大可处理700K Pps的二维队列消息事件树


SDN控制器在实际网络中应用的一个最大挑战是在网络中有爆发性流量时的健壮性,即当有大量的Packet-In消息报文上来的时候,如何保证其可以被正常接收和重要消息仍然可以被及时处理。为了能达到这个要求,不仅要求控制器的消息处理方式为异步方式,而且要求其消息的缓存机制应该非常具有弹性,可以应对大消息量的冲击。

根据OpenFlow协议,SDN控制器需要处理的消息主要分为以下几类:

    1. 拓扑变化相关消息:例如交换机的上线下线、交换机的端口变化、链路变化、拓扑发现LLDP消息等;

    2. 主机通讯相关信息:例如ARP消息、IP消息、DHCP消息等;

    3. 网络心跳和流量监控等消息:主要是OpenFlow协议中的Echo消息和针对交换机、端口或流表的流量统计数据。

   上述三类消息的特征和重要性都有着很大的区别。第一类消息的数量最小,重要性却最大,需要控制器及时的做出相应,否则会影响整个网络的通信。第二类消息的数量会比较多,网络中的每个主机的通信行为都会导致控制器收到相应的消息。若某个主机大量的发包,则控制器很有可能会被阻塞掉。但是重要性却没有第一类消息大,因为若控制器处理不及时,只会影响到相关主机的通信。第三类消息的数量不多,重要性也最低,可以看做是对网络的监控消息,处理不及时不会影响到网络的通信。

图:二维队列消息事件树

       根据所分析的消息的特征,我们设计了如上图所示的消息队列树。在这个消息队列树上有两个类型的对象:消息类型节点(MsgTypeNode)和消息队列(MsgQueue)。消息类型节点代表了一个特定类型的消息,根据消息的种类及他们之间的包含关系,他们构成了父子关系。每一个消息类型节点多有对应的一个消息队列,其中存储了该类型所对应的消息或子队列。设置子队列的原因是有些消息可以进行归并处理。例如,针对同一个主机地址的ARP_Request是只需要处理一次的。
每一个消息类型节点都对应于一个相应的消息处理线程Msg_Handler。消息处理节点需要实现以下的几个接口:
     1) PushMsg 用来处理一个消息。该函数应该会首先判断当前消息是否可以放入某个子节点中,如果其没有子节点或所有的子节点都和此消息不匹配,则该消息应放入其自身的消息队列中。放入消息队列中时,还需要判断是否有子队列。若有子队列,则应根据子队列分队规则选择相应的子队列。
     2) GetMsg 用以返回一个消息给相应的Msg_Handler处理。GetMsg接口应支持两个参数:IfDel和Msg。IfDel表示返回相应的消息后是否需要从队列中删除。Msg参数表示指定被返回的消息的属性。
    每一个消息类型节点是否存在取决于是否有相应的Msg_Handler。当系统初始化时,所有支持的Msg_Handler都应在系统中注册以提交其支持的消息的类型信息。SDN控制器根据所有Msg_Handler提交的注册信息以决定建立的消息队列树。SDN控制器会为每一个消息处理Msg_Handler生成一定数量的线程。这些线程都会监控一个公共的信号量。当消息类型节点添加一个消息到自身队列后,会通过增加信号量的值以通知所有的Msg_Handler线程来取消息。


    (3)基于状态机的交换机状态精细化管理


   SDN控制器通过TCP连接和其管理的每一个交换机之间进行通信,这个TCP连接又被称为是管理通道。由于在网络运行时需要一直保持SDN控制器和交换机之间的通信,管理通道的稳定性就会极大的影响到SDN网络工作的稳定性。在实际的SDN网络应用场景中,例如数据中心,SDN管理通道一般是使用的原因的管理网络,相较于业务网络,管理网络的稳定性会大大的降低。SDN网络中交换机正常工作时可能会受到两个因素的影响导致暂时的不可用:一是TCP连接会受到网络的影响而暂时关闭,二是SDN控制器和交换机之间的心跳包会出现丢包导致控制器认为交换机进入不可达状态。然而,当SDN控制器在交换机中下发网络通信规则以后,即使管理通道暂时失效,交换机仍然可以按照已经下发的通信规则进行数据包的转发。因此,如何应对管理通道的非稳定性,提供SDN控制器在此种情况的健壮性就成为了本领域技术人员亟待解决的问题。

通常来说,当SDN控制器和交换机建立好OpenFlow会话以后,交换机的正常工作状态会被设为“已连接状态”,此状态下控制器和交换机之间可以进行正常的OpenFlow消息交互。当交换机的TCP长连接断开或心跳保活超时以后,交换机即被马上转为“离线状态”。一个交换机转为离线状态以后,网络拓扑会随之发生变化,交换机对象所附属资源也会被控制器回收。主流的开源控制器如OpenDayLight和ONOS等也是采用的类似的交换机状态管理机制,从而在管理通道不稳定时容易导致前述的控制器的稳定性。

       针对上述问题,在DCFabric“汉”版本中,我们定义了SDN控制器中交换机的多种状态(包括初始化、新连接建立、版本协商成功、正常工作、不可达、连接断开、掉电、正在下线和已下线共9种交换机状态)和相应的交换机状态迁移图,并定义了多个关键的反映交换机工作状态改变的事件,可以应对交换机管理通道的不确定性,提高SDN控制器中交换机管理的精确性,较强控制器的可靠性和健壮性,降低了对SDN网络中管理通道可靠性的要求,为SDN网络在实际环境中的应用提供了保障。

图:交换机状态转移示意图


    (4)基于标签交换的OpenStack高效多流表方案



为了能更好的发挥SDN在OpenStack中的应用潜力,避免Overlay网络带来的各项难题,在前面几个版本中我们已经提出了基于物理OpenFlow交换机的高效网络方案,其主要优点如下:

  1. 无须封包、解包带来的高网络吞吐量,可以最大程度发挥物理网络性能;

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

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

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

   基于标准OpenFlow流表实现OpenStack中虚拟机的内外网所有网络通信,交换网中的交换机分为计算节点OVS虚拟交换机、转发交换机、外网出口交换机三种角色,根据其角色分别下发不同的流表。转发交换机和出口交换机都可以采用支持OpenFlow协议的物理交换机。


通过控制器计算交换机之间的通信路径,每个交换机分配一个唯一的基于Vlan ID的标签,根据路径建立基于Vlan ID标签的数据流表,当有网络通信请求时候,在通信两端点所在交换机上分别建立两个流表,在起点处数据加上Vlan ID的标签并放在路径上,在终点把数据拆解标签并转发到指定的通信端点上,完成数据通信。交换机间的通信路径都基于标签下发OpenFlow流表。转发交换机上只要基于标签进行路由的流表,因此流量数量会得以大大降低。

转发交换机上面只有一个0号标签转发表,会根据数据包中的不同标签转发到不同的端口。本专利使用VLAN ID作为数据包标签,所以标签转发表上面的流表都是类似于如下的流表模式:

IP,dl_vlan=x,actions=output:y

转发交换机上面的流表只和网络拓扑有关,和主机的通信过程无关,所以只在拓扑发生变化影响到交换机之间的转发路径时才需要进行更新。

图:OVS虚拟交换机多流表方案

     上图显示了汉版本中提出的OVS虚拟交换机的多流表方案。每个OVS虚拟交换机上的流表分为两个不同的流水线,分别对应于处理本地虚拟机发送的数据包和其他交换机转发过来的带标签的数据包,0号流表会根据数据包的实际情况选择不同的流水线进行处理。本地虚拟机发送的数据包流经的流水线包括0号出口分发表、1号输出防火墙表、2号输出QoS表、3至10号的网络功能区表、11号虚机间通信会话表和12号标签转发表,最终由12号表输出到不同的交换机上联端口。其他交换机转发过来的带有本地标签的数据包流经的流水线包括13至20号的网络功能区表、21号入口防火墙表、22号入口QoS表和30号本地主机转发表,最终由30号表输出到本地不同的虚拟机。

  其中网络功能区中的每一个流表都对应于一个单独的网络功能,多个网络功能之间彼此隔离,可以根据实际需求增加或删除网络功能,以适应不能的云平台环境,而且可以根据其功能特性分别支持反应式和预先式两种下发策略。例如,对于Floating IP流表,其中的流表下发方式为预先下发式,当用户在OpenStack平台中更新相应配置以后可以直接在5号和15号表中下发相应的流表。但是对于NAT流表,就要求在每次NAT会话时才能以反应式的方式在4号和14号表中下发相应的流表。

图:外网出口交换机多流表方案


在OpenStack Neutron网络方案中,网络的管理分为内部网络(Internal network)和外部网络(public network)。内部网络为虚拟机可以直接连接的网络,一般分配的是局域网IP地址。所谓外部网络是指openstack部署环境以外的网络。这个网络可以是数据中心中的另一个网络、Internet、或者一个不被openstack控制的私有网络。与外部网络通信,我们需要在openstack中创建一个network并设置为public。这个network用于虚拟机与public network通信。虚拟机不能直接连接到这个新创建的属性为public的network,所有网络流量必须使用openstack创建的router从private network路由到public network。OpenStack管理员可以创建多个属性为public的网络,用以把虚拟机连接到不同的外部网络中。

我们在本版本中的SDN网络方案会包含多个外网出口交换机,每一个外网出口对应于一个Public网络。每个外网出口交换机上的流表分为两个不同的流水线,如上图所示,分别对应于处理其他交换机转发过来的由虚拟机发出的数据包和外连网口发送过来的数据包,0号流表会根据数据包的实际情况选择不同的流水线进行处理。外连网口发送过来的数据包流经的流水线包括0号出口分发表、1号输入防火墙表、2号输入QoS表、3至10号的网络功能区表和12号标签转发表,最终由12号表通过不同的内联端口输出到内部交换机。其他交换机转发过来的带有本地标签的数据包流经的流水线包括21号外连输出防火墙表、22号外连输出QoS表和30号外部网关MAC转发表,最终由30号表输出到不同的外联端口。

为了能和OVS虚拟交换机上面的多流表方案保持相对应,这里把外网出口作为一个连接所有外部主机的本地端口。和OVS虚拟交换机上面的多流表方案最大的不同是外网出口交换机上的网络功能区流表只有一份,目的是为了减少出口交换机上面的流表数量,而把其实现在了每一个虚拟交换机上面。

  外网出口交换机可以是OVS虚拟交换机也可以是支持OpenFlow协议的物理交换机,如Pica8的交换机P-5401、P-5101等。基于现有物理OpenFlow交换机的实现方式和交换芯片的限制,在一个数据包处理的流水线中,对数据包相关字段做出修改后必须要立即输出到某个端口。因此,若外网出口交换机为物理交换机,则上图所示的第12号流表需要删除,而应由网络功能区中的各流表直接进行输出,但是这样会破坏流表的耦合性要求。另外一个常用的解决方案是令相应的数据包可以从0号流表开始重新走一次流水线,这可以通过由两个网口直连构造的“回路”来实现。