SDN实战团分享（十八）：品高云的SDN实践

在讲SDN云网络之前，我们先来回顾一下，传统的云网络。先来一张图（自己画的）

传统的云网络我相信大家一定非常熟悉。我简单介绍一下传统云网络的一些特点。

特点：

绝大部分网络功能都是沿用Linux原生自带的网络组件完成。网络功能的控制权分散。网络压力集中在CC（Network Node）上，这个网络节点它的压力是非常巨大的，两个不同子网的虚拟机之间的访问需要经过网络节点，外部网络访问虚拟机需要经过网络节点，虚拟机访问外部网络需要经过网络节点，这样东西南北各方向的流量都要经过这个网络节点。并且CC（Network Node）的网络控制器是建立在VLan的引流之上，缺乏高可用性的网络处理功能，而它的性能又决定了整个云网络的性能，同时这个还存在单点的风险。

接下来：我们来说说Bingo SDN的网络模型。大家可以对比一下与传统云网络的差异性。

同样甩上特点：

遵循ONF（open network foundation）的SDN标准，NC（Node Compute）完成所有的网络流量的处理，包括：Route、NAT、Security Gourp、QOS、Subnet、VPC、ACL、VPCPeerIng。整体的网络架构设计中，不存在Network Node。SDN controller支持Cluster mode，Cluster mode支持Load Balance 和 HA。

大家在Bingo SDN中，看到的所有云网络的业务功能，基本都是通过OpenFlow协议实现的。这样做有什么优点呢？我们一一细说。

优点：

统一的高效集中化管理，SDN controller可以感知整体网络的情况。摆脱臃肿的Linux network stack组件。摆脱Network Node的单点性能瓶颈，网络高可用、高容灾性、高扩展性。

接下来从四点开始讲Bingo SDN：

1）Bingo SDN贴合品高云的网络功能

2）Bingo SDN 的安全隔离

3）Bingo SDN的性能优化

4）Bingo SDN的高可用性设计

我们先来看看BingoSDN的业务功能：

简单解析一下：

l Security Group：充当实例的虚拟防火墙以控制入站和出站流量。

l Subnet：是VPC内的IP地址范围。可以在选定的子网内启动云资源。

l ACL：是一个可选安全层，可作为防火墙，以控制进出子网的数据流。可以设置网络ACL，使其规则与安全组相似，以便为VPC添加额外安全层。

l RouteTable：中包含一系列被称为路由的规则，可用于判断网络流量的导向目标。

l VPC：的私有子网内启动的实例无法与Internet通信。可以选择使用公有子网内的网络地址转换(NAT)实例来让私有子网中的实例连接到Internet，以及拒绝接收由Internet中其他用户的入站数据流。

l NAT：可以通过网关与外部非VPC网络通信。通过Internet网关，实例可穿越云网络边界而连接到Internet，前提是实例要有一个公有IP地址。

这些功能都在SDN controller中实现。因此规则的增加只是内存的消耗，不会真实地影响到NC的网络IO。

接下来是分布式的QOS（东西南北分离的QOS）

我们做一下对比：

传统网络的QOS：因为NAT发生在网络节点上，所以QOS只能在网络节点处理的。网络节点的QOS处理存在单点性能瓶颈。并且东西向的QOS难以实现。

Bingo SDN的QOS：Bingo SDN的NAT发生在计算节点上，所以QOS的处理可以分布到各个计算节点上处理。并且Bingo SDN可以更加首包分析数据流是东西向还是南北向的。通过规则的下发，将东西向和南北向流量区分到不同Queue上。这样Bingo SDN的QOS不仅可以做到对南北向分布式的QOS，同时也可以做到的东西向分布式的QOS。

对于一个云网络，网络安全隔离也是我们重点考虑的问题。

Bingo SDN的网络隔离是基于租户的网络隔离

无论是Vlan隔离，还是Vxlan隔离，他们都是需要做数据包叠加。Vlan叠加一个Tag，Vxlan需要叠加一个四层包头。而Bingo SDN的网络隔离是直接通过OpenFlow协议的规则完成的。而且隔离的信息完全记录在SDN Controller的Memory Key Store DB中。这样Bingo SDN的租户隔离的不受数量的限制，只要内存放得下，SDN controller都可以处理。Bingo SDN构建了一个平行化的网络空间。租户的隔离不会增加NC（Node compute）的IO压力。

Bingo SDN在实现防火墙的功能的时候，并没有用到传统的Iptables。而是通过OpenFlow协议实现的一套。分布式虚拟化Security Group/ACL （灵活多层次化安全保护）先来个图

在大规模网络中，如果将庞大的Security Group规则通过静态配置到计算上节点上，对整个云网络会造成非常严重消耗。同时实例迁移的过程，必须将对应的Security Group规则一同迁移。 迁移的过程还需要考虑解决规则的合并带来的冲突的问题。

云网络Security Group是保护对象是VM，但是在某些场景下，用户希望通过ACL方式保护整个Subnet。

Bingo SDN希望Security Group/ACL规则是按需分配的，假设一个VM没有发生任何流量。这样是没有任何网络规则的，只有在流量发生的时候，SDN controller才会下发规则，并且OpenFlow规则可以实现Security Group /ACL的规则合并。这样带来两个好处，第一，规则数量会减少。第二，VM迁移，规则无需迁移。

Bingo SDN如何将Security Group/ACL配合使用呢? Security Group是White-list带状态， 而ACL是WB-LIST，无状态的。

在云网络安全中，是需要专业的同人一齐来助力。Bingo SDN的云网络安全是支持第三方安全厂家的虚拟化产品整合。

我们简单谈谈云网络安全。云网络的安全包括三个方面：1）边界网络安全性，2）内部网络安全性，3）内部网络健全性。边界网络的安全性可以通过硬件防火墙、硬件入侵防御保证。但是云的内部网络安全、云的内部网络健全单靠外部的硬件是无法结局的。

Bingo SDN的虚拟化安全产品接入的方案如下：

如上图：一个云内部的实例因为软件长期不更新，导致被黑客入侵了。这样这个时候可以直接攻击/感染其他实例、GW、数据中心。

Bingo SDN的云网络集成了分布式的入侵防御系统，以及分布式的漏洞扫描系统。可以有效地保证云内部网络的安全性和健全性。值得一提的是Bingo SDN的云网络安全系统是支持第三方的安全厂家接入。如山石网科、蓝盾、深信服等。和山石网科的整合项目已经落地了。主要整合的产品有云格、和云界。

接下来谈谈Bingo SDN的网络性能优化。

第一个，DVGW（零消耗的网关）

不同的Subnet之间需要有独立的Gateway作为Subnet出口。在大规模网络中，存在大量的组网，同时需要大量的网关。这时候gateway到底在哪里？在传统的云网络是把Gateway部署在的CC（Network node）上，这样很容易造成单点故障，同时本身网关将成为整个云网络的性能瓶颈。同时Gateway也是黑客攻击的一个重点对象。

Bingo SDN在考虑Gateway的处理，希望Gateway是隐藏的、虚拟的、分布的。这个Gateway没有真实的载体。我们再也不用担心Gateway会被攻击了，因为根本没有Gateway，此外Gateway也不会存在单点，Gateway的资源消耗接近于零。

我们在研发SDN云网络的过程中，明确Gateway是可以通过OpenFlow协议虚拟处理。VM只是被欺骗而已。

第二个，无连接跟踪的NAT （高效的网络处理能力）

传统网络的NAT:

NAT是公有IP和私有IP之间互相转换的有效方式。传统网络的NAT必须依赖内核网络协议栈的ConntectTrack。Linux Networkstack的ConntectTrack是一个非常消耗计算性能的功能模块。在大规模的云网络下，NAT对网络性能有很明显的消耗，同时ConntectTrack也很容易被成为网络攻击的对象。

Bingo SDN的NAT：

Bingo SDN的NAT是无连接跟踪的NAT。丰富的OpenFlow协议可以模式实现一对一的NAT。NAT的过程是在二层网络全部处理完成，没有经过ConntectTrack。

第三个，L2 POP & ARP responder （感知网络，提升网络质量），这个命名方式是借用OpenStack命名方式，大家比较好理解。

云网络的扁平化，最大的性能问题就是广播数据等垃圾数据对网络的质量带来的巨大影响。容易形成广播风暴。为此，Bingo SDN对网络质量的保证做了很深入的优化。通过

Bingo SDN的网络的学习能力与预判能力，把广播包做一次拦截，直接通过流变把数据包发送到指定目标。保证有效的网络流量能高效的转发。

到了这里，我相信大家可能会有一个疑问。如果SDN Controller宕机了，是不是整个云网络都会出现瘫痪呢？还有 SDN Controller的处理能力能不能支撑大规模的云网络？

接下来就是Bingo SDN的高可用性，以及集群化模式。

控制器集群并高可用（专利保护）

集中化的控制不可避免的一个问题就是高可用。假设Bingo SDN controller出现异常崩溃了，这样会直接影响到整个云网络不能运行。甚至连管理IP都无法访问。如何保证集中化控制的高可用，这也是一个值得研究的课题。

解决方法：

1、secure mode。在openvswitch br0配置了secure mode，加入openvswitch 和控制器失去了连接，openvswitch会保持原来的flowtable继续工作。这样即使Bingo SDN controller宕机了，云网络原来的网络连接也不会断开。

2、Bingo SDN controller的集群调度能力。controller宕机之后，它的工作会由其他控制器接管过来，有因为openvswitch 配置了secure mode的关系，Bingo SDN controller的集群调度能力可以是无缝切换。值得一提的是，这项技术的专利目前已经公告，编号（33384、38231）。

Q&A

Q1：对用户来说，会看到多个CONTROLLER吗？

A1：我们SDN controller会独立的界面。在界面中可以看多个Controller。但是VM是无感知的。

Q2：控制器基于什么开发的？

A2：是我们自主研发的产品。

Q3：请教一下nat 在哪里处理？性能咋样？

A3：NAT是在Openvswitch上处理，我们在Openvswitch上做了优化。性能需要看服务器的硬件性能。

Q4：这个控制器集群有什么特点啊？我看现在很多人都在研究集群，有什么区别吗？

A4：我们的控制器集群，不存在一个统一的中央管理器。只是SDN controller通过私有协议做HA。数据同步走分布式数据库。

Q5：控制器后端数据库刚说了用了内存数据库，那neutron与控制器数据如何保持一致和灾难恢复？数据库是否也是集群

A5：数据库是分布式数据库。

Q6：这个控制器集群采用什么分布结构？垂直结构还是水平结构？

A6：是水平结构，可以横向拓展

Q7：大规模部署时，走网络节点存在性能问题，一般情况下网络节点大约可以承受多少VM，性能不受影响？

A7：我们的Bingo SDN不存在专门的网络节点。传统网络的VM的限制，是网络节点的性能、还有Vlan数量的限制。

Q8：这些控制器之间怎么实现通信的？使用的是什么协议？

A8：多SDN controller的通讯协议，是我们自定义的协议。基于VRRP的二次开发。

Q9：品高的sdn controller可以同时控制的openflow交换机数量有上限吗

A9：一个SDN controller的控制上有上限的。 最多不超过1000个。我们多个SDN controller是负载均衡的。

Q10：你们一个控制器能控制多少个OVS？多控制器是分域控制么？packet_in和flow entry install处理性能一个控制器有多少？

A10：目前不支持分域控制。一个控制器的处理性能5kpps。

Q11：除了ovs，支持其它带openflow功能的交换机吗？对ovs扩展的功能不能使用的话，整个架构会有问题吗

A11：Cloud 硬件的交换机目前和Pica8的SDN交换机整合过。

Q12：一种多少种flow？用了几级pipeline？控制器只有这一级么？

A12：目前的table分布，是三级。控制器只有一级。

Q13：我想了解山石网科在你们整合方案中云格和云界的工作原理，谢谢

A13：主要是Bingo SDN做了引流。他们做专业的分析，然后反馈给云平台。

Q14：虚机在br-int上会打上localvlan，你们通过什么信息来识别租户？

A14：MAC地址。

Q15：既然都是依靠flow entris，那怎么知道一个switch可以容纳多少flow entries？有具体的数字吗？

A15：我们实测，一个switch最大的Flow entries能到3万。当然controller也有保护机制。

Q16：请问第三方安全产品具体是如何接入租户网络呢，通过部署到虚拟机还是直接部署到硬件呢？

A16：通过虚拟机的方式接入。

Q17：NC是分布式的，那最终到公网的出口应该远低于NC的数量，多链路物理交换机支持？

A17：这个是支持的

Q18：像保护vm流量的sg规则和保护子网的acl规则都是通过odl下发流表规则到ovs交换机上，而且好像还能动态设置，方便迁移，那vm ovs controller间是如何协调实现的

A18：vm 和 ovs 其实就是 virtio的链接，没有特别的。ovs 和 controller通过OpenFlow链接。关键的协调者还是 SDN controller

Q19：我以为租户网络是通过vlan，vxlan，gre来实现的隔离，刚才有提到通过sdn控制器通过of协议规则实现租户隔离，大致实现概念是什么？

A19： 我们的ovs本身的网络是不同的。和传统的二层不太一样。大致的实现，其实在SDN controller知道所有网络的布局。通过OpenFlow协议配置互联。

Q20：出外网的SNAT是创建VM时静态生成的吧？，每个VM针对外网都有一个IP+port，出外网的查表有没有性能问题？

A20：SNAT是动态的。我们的NAT是 IP一对一NAT。查表必然存在性能损耗。我们通过Bingo SDN优化Flowtable的粒度，减少规则的产生。

Q21：在Controller故障切换，特别是Controller都故障时，因为secure mode，转发还继续，可能生成流表，等Controller OK后，怎么做Controller和OVS的数据平滑，平滑的思路是？

A21：如果SDN 都故障了，拿新建链接无法进行。OVS的首包无法上传。等SDN controller重新接管之后，新建链接恢复。这里的新建链接泛指首包。

Q22：就是preactive和reactive的概念，可以在需要时再下发，不过如果reactive用的多了，控制器压力会不会太大

A22：会有压力的，我们使用S&D flow的方式，动态和静态流表会配合。同时如果是恶意的首包，我们会将限制。同时我们的Flow table是可以匹配多个流的。

Q23：有宣传的案例吗？

A23：www.bingocloud.cn上有案例。案例如：广州市电子政务云，互联港湾公有云，招商银行，南车，国药集团等。