在讲 SDN 云网络之前，我们先来回顾一下，传统的云网络：
传统的云网络我相信大家一定非常熟悉。我简单介绍一下传统云网络的一些特点。
传统云网络特点：
绝大部分网络功能都是沿用 Linux 原生自带的网络组件完成。网络功能的控制权分散。网络压力集中在 CC（Network Node）上，这个网络节点它的压力是非常巨大的，两个不同子网的虚拟机之间的访问需要经过网络节点，外部网络访问虚拟机需要经过网络节点，虚拟机访问外部网络需要经过网络节点，这样东西南北各方向的流量都要经过这个网络节点。并且 CC（Network Node）的网络控制器是建立在 VLan 的引流之上，缺乏高可用性的网络处理功能，而它的性能又决定了整个云网络的性能，同时这个还存在单点的风险。
接下来，我们来说说 Bingo SDN 的网络模型。大家可以对比一下与传统云网络的差异性。
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 协议实现的。这样做有什么优点呢？我们一一细说。
Bingo SDN 优点
统一的高效集中化管理，SDN controller 可以感知整体网络的情况。摆脱臃肿的 Linux network stack 组件。摆脱 Network Node 的单点性能瓶颈，网络高可用、高容灾性、高扩展性。
接下来从四点开始讲 Bingo SDN：
- Bingo SDN 贴合品高云的网络功能
- Bingo SDN 的安全隔离
- Bingo SDN 的性能优化
- Bingo SDN 的高可用性设计
我们先来看看 BingoSDN 的业务功能：
简单解析一下：
- Security Group：充当实例的虚拟防火墙以控制入站和出站流量。
- Subnet：是 VPC 内的 IP 地址范围。可以在选定的子网内启动云资源。
- ACL：是一个可选安全层，可作为防火墙，以控制进出子网的数据流。可以设置网络 ACL，使其规则与安全组相似，以便为 VPC 添加额外安全层。
- RouteTable：中包含一系列被称为路由的规则，可用于判断网络流量的导向目标。
- VPC：的私有子网内启动的实例无法与 Internet 通信。可以选择使用公有子网内的网络地址转换 (NAT) 实例来让私有子网中的实例连接到 Internet，以及拒绝接收由 Internet 中其他用户的入站数据流。
- 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）内部网络健全性。边界网络的安全性可以通过硬件防火墙、硬件入侵防御保证。但是云的内部网络安全、云的内部网络健全单靠外部的硬件是无法结局的。
如上图：一个云内部的实例因为软件长期不更新，导致被黑客入侵了。这样这个时候可以直接攻击/感染其他实例、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：我们的控制器集群，不存在一个统一的中央管理器。只是 SDNcontroller 通过私有协议做 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 个。我们多个 SDNcontroller 是负载均衡的。 - Q10：你们一个控制器能控制多少个 OVS？多控制器是分域控制么？packet_in 和 flow entryinstall 处理性能一个控制器有多少？
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 可以容纳多少 flowentries？有具体的数字吗？
A15：我们实测，一个 switch 最大的 Flow entries 能到 3 万。当然 controller 也有保护机制。 - Q16：请问第三方安全产品具体是如何接入租户网络呢，通过部署到虚拟机还是直接部署到硬件呢？
A16：通过虚拟机的方式接入。 - Q17：NC 是分布式的，那最终到公网的出口应该远低于 NC 的数量，多链路物理交换机支持？
A17：这个是支持的。 - Q18：像保护 vm 流量的 sg 规则和保护子网的 acl 规则都是通过 odl 下发流表规则到 ovs 交换机上，而且好像还能动态设置，方便迁移，那 vmovs controller 间是如何协调实现的？
A18：vm 和 ovs 其实就是 virtio 的链接，没有特别的。ovs 和 controller 通过 OpenFlow 链接。关键的协调者还是 SDN controller。 - Q19：我以为租户网络是通过 vlan，vxlan，gre 来实现的隔离，刚才有提到通过 sdn 控制器通过 of 协议规则实现租户隔离，大致实现概念是什么？
A19： 我们的 ovs 本身的网络是不同的。和传统的二层不太一样。大致的实现，其实在 SDNcontroller 知道所有网络的布局。通过 OpenFlow 协议配置互联。 - Q20：出外网的 SNAT 是创建 VM 时静态生成的吧？每个 VM 针对外网都有一个 IP+port，出外网的查表有没有性能问题？
A20：SNAT 是动态的。我们的 NAT 是 IP 一对一 NAT。查表必然存在性能损耗。我们通过 BingoSDN 优化 Flowtable 的粒度，减少规则的产生。 - Q21：在 Controller 故障切换，特别是 Controller 都故障时，因为 securemode，转发还继续，可能生成流表，等 ControllerOK 后，怎么做 Controller 和 OVS 的数据平滑，平滑的思路是？
A21：如果 SDN 都故障了，拿新建链接无法进行。OVS 的首包无法上传。等 SDNcontroller 重新接管之后，新建链接恢复。这里的新建链接泛指首包。 - Q22：如果 reactive 用的多了，控制器压力会不会太大？
A22：会有压力的，我们使用 S&Dflow 的方式，动态和静态流表会配合。同时如果是恶意的首包，我们会将限制。同时我们的 Flow table 是可以匹配多个流的。 - Q23：有宣传的案例吗？
A23：我们的官网 cloudos.bingocloud.cn 上有案例。案例如：广州市电子政务云，招商银行，广州大学，国药集团等。