Neutron的SDN化

对于SDN大家估计都耳熟能详，这里首先讲讲虚拟化网络技术故事，当VM技术出现的时候，存储通过本地存储或远端挂载的形式基本没有太大变化，但是网络技术呈现形式一直不断翻新。

OVS可以说是一个网络虚拟化里一个重量级的开源产品级作品，OVS模仿物理交换机设备的工作流程，实现了很多物理交换机当时才支持的许多网络功能，但是每次配置都需要到宿主机里去手工设置，管理员们正在烦恼之时，SDN就像朝阳带来了希望
就是可以将OVS设置SDN的控制器，然后管理员就可以通过页面点击按钮来调用SDN的北向API来配置和管理多个OVS，这为网络虚拟化管理和配置带来了便捷；这给某些工程师带来了些认识：

1 软件时代来临了，软件实现的虚拟网元可以取代系统工程师和运维工程师一直摸不透的黑盒子；

2 SDN的名称Software Defined Network名称更让人理解为软件替代一切的SDX理念，后来衍生到软件定义存储SDS和软件定义数据中心SDDC的概念

这里说几个虚拟化（存储、计算和网络）的好处：

1 通过虚拟化，屏蔽底层故障，增加手工干预所需时间，便于运维；

2 通过一虚多提高资源使用效率，节省成本；

3 便于集中管理资源，为云计算的服务提供坚实基础支持；

这里需要提及下，一台物理机虚拟多个虚拟机时虚拟化，多个物理机虚拟一台虚拟机同样是虚拟化。虚拟机和物理机同时被云平台管理也是现阶段很多场景需要的，包括Openstack的组件里有管理虚拟机的Nova和相应管理裸机的Ironic。

这里澄清下几个概念：SDN提出的时候并没有区分所控制的软件转发层面是虚拟网元还是物理网元，但是从SDN的理念开放的南向接口这项来看，OpenvSwitch这类虚拟网元支持的Openflow协议速度比硬件支持实现肯定要快很多（这里并不是说OVS是第一种SDN里的网元，也不是说SDN里先支持虚拟网元后支持物理网元），多多少少关联了些NFV（Network Function Virtualization）的思想（NFV的理念现在很多被设计为VMaas，SDN结合NFV在部署和网络管理上提供更多的相互支撑）。

但是SDN的名称和对OVS支持，让系统工程师和运维工程师多多少少会认为SDN就是软件代替硬件网络和SDN就是运维网络的工具；当系统工程师和运维工程师云SDN津津乐道的时候，而此时的网络工程师在做什么哪？理论上讲SDN是属于网络领域的概念，而SDN产生前期的时候绝大多数的网络工程师（到现在还有很多设备商的网络工程师）还是沉浸在数据包转发和网络协议的开发中，几乎对SDN没有什么概念。

我们现在经常看到各种分享和峰会里，提及SDN应用的很多是互联网公司的运维工程师（需求是网络可视，突破网络协议OSPF/BGP等不可控的约束对网络操作，作为一种运维工具实现可视化网络）和云计算公司的系统工程师（软件实现网络，摆脱理解不了的硬件盒子，使用软交换或白盒交换机实现可控），设备商的网络工程师分享SDN的则相比不是太多。

个人观点：最懂网络设计的工程师还在于世界上各大设备商公司里，SDN这种新架构的落地要靠他们（当然包括他们从设备商跳槽或创业后后到互联网和云计算公司从事的SDN网络设计落地工作，以及协助集成商落地SDN）。

做网络开发的对虚拟网元的网络原理都懂，上手代码也会很快；但是没有玩过网络设备的工程师搞网络，对黑盒子都会始终有很多迷惑的认知，这些往往是导致出网络问题的根源，曾经出现过某云平台因为交换机问题导致的云平台故障
OpenvSwitch现在来说是比较出名的虚拟网元，还有思科的Nexus 1000V，微软的Hyper-v Vswitch，Vmware的VSS/VDS等；OpenvSwitch来讲，相比于硬件交换机，支持的功能逐渐完整，并且已经发布集成Conntrackd的有状态规则（OVN已经实用之来作为Neutron里替代Iptables实现安全组，但最新2.4版本的OVS未发布该特性），这点作为新特性的创新来说是传统硬件交换机支持不了的；

但是OVS在Egress Pipeline Processing方面支持度还有待进一步增强（Openflow1.5才有这个支持），包括流表对出口的匹配、端口出方向QOS带宽限速、出入方向对BUM报文的抑制等，但是OVS的性能和现在万兆的交换机相比，还相差很远。

个人观点：所以在虚拟化网络不成熟的今天，需要虚拟交换机这类来不断完善新特性；但是纵观网络发展，包括杀毒硬件、L7交换机等类似产品，以及博通等芯片厂商硬件开始支持端口虚拟化和虚交换机等，网络虚拟化产品最终也应以网络设备的虚拟化来实现为主，从而释放出所占用的服务器 CPU等资源。

这里再说下传统网络的SDN应对的问题：以前的大规模网络互通是靠路由协议实现路由发布实现数据转发面互通（此时路由协议的交互基本是通过数据转发面来实现即带内），路由协议一旦启用人类很少能主动干预，这种不可控导致了一些问题；

无法动态为所部署的业务分配所需网络资源（为何以前不能分配所需？因为以前的网络资源还不足够多，现在随着网络设备能力增强带宽只是个数字而已）；大象流集中到某些链路导致网络带宽使用率不理想等；大象流超过单链路带宽如果走多路径ECMP会导致接收端服务器对报文重排序非常耗CPU；

这也是为何单端口带宽一直上升的原因，从千兆到万兆，现在又盛行升级到25G，然后40G/100G，后续还会再增加。

传统网络还有一些问题：比如各厂家堆叠基本都是各厂家自身产品几个有限型号才能堆叠，这就导致了另一个问题，作为汇聚或核心层设备进行HA的时候，一旦一台设备在某种场景下触发了BUG或问题，另一台同型号设备的话则也会有同样的问题，使得HA失效。

上面讲了这么多，主要是说SDN出现的一些背景，这里简单说下SDN的概念，SDN主要是说能够将应用和底层网络转发关联起来，让上层应用控制底层数据转发，所以SDN的名称ADN（Application Defined Network） 更符合一些；

那这就要底层转发网元和管理面做一些相应的改进，SDN有三个特征：控制转发（逻辑）分离 ，开放的（不是开源）的编程接口 ；集中（逻辑）的网络控制。所以SDN的本质个人认为是：
一种新型的可视化网络设计架构

一种网络资源管理和优化使用方式 一种节约资源降低网络成本的技术 一种体现对网络需求增速变慢的技术体现点

另外SDN不是：

SDN不是网络虚拟化或NFV ，即SDN不是软件实现网络， SDN不是网络设备，包括OVS和白盒交换机 SDN不是某种网络协议，包括Openflow（含TTP) SDN不是网络的必须或主宰技术 ，和其他技术一样，需求推动 SDN不是纯粹的网络配置工具 SDN不是纯粹的网络运维工具 SDN不是软件网元替代硬件网元 SDN不是提升转发面网元本身性能的工具，只是网络资源使用方式的改变，换句话说SDN只是换了种对网元的使用方式，将其自身的最佳性能得到了发挥；所这点来讲，对于苛求或批判SDN方案（尤其是Neutron结合SDN）提升网元自身转发性能的同学，只能说还不理解SDN或者还不理解网络

SDN的各向接口：

北向暂时没有标准，各家控制器基本都有自己的接口，这点北向标准还不如Neutron 南向:Openflow，Netconf，BGP、OVSDB及思科的Openflex等等（一款控制器可以同时使用多种南向协议） 东西向：BGP等等（有个SDN东西向的Draft：SDNi，还有篇paper提出了East-west bridge） SDN级联，包括了SDN的南向和东西流流量，暂时未看到标准

这里着重说下最后一点，Openstack的L版添加了Port的Qos特性API，另外企业网尤其是中小企业的小规模网络会不会从SDN里收益？大家一致的印象是只有大规模设备用SDN才划算，对此个人观点是找到合适的应用场景SDN一样可以让小规模网络收益，包括企业办公网等。

说完了SDN也顺便聊下NFV，NFV自身是说为了解决当前hardware-based情形下，随着应用更新的加快，硬件跟不上应用需求的步伐，导致硬件设备寿命缩短导致浪费，需要对存储、计算等所需的网络功能进行虚拟化，来加快创新，并节省对硬件设备的投资。

个人理解，NFV是英特尔等CPU厂商用X86和虚拟化厂商用虚拟化技术进军网络研发领域的一种策略；首先，上层应用对网络所需的特性并没有那么多的个性化定制，尤其是随着先交换机白盒智能化和存储设备的白盒化，应对创新需求只是这些厂商对运营商的单方说辞；其次，无论NFV在运营商的产品化形态如何（VMaas就是一种形态），运营商对网络设备的需求都是不可少的，但NFV对传统网设备商还是有了一定的智能化促；

最后英特尔等也同时硬件设备领域没有放手，通过收购FM研发硬件交换芯片，并结合X86推出基于FM10000的ServerSwtich，使其网络方面虚拟网元和硬件网元优化一体化解决方案的战略内容之一。所以NFV可谓是“项庄舞剑，意在沛公”，Openstack里也越来越多的NFV特性比如Service chain方面的支持。

现在来看云计算方面的内容，云计算中大二层需求、网络虚拟导流所用隔离技术包括Vlan Mpls Vxlan Nvgre STT Geneve 等，Vxlan逐渐 成为趋势 ，但OVS 2.4.0版本Geneve支持basic 版本；所以这里抛出一个问题，现有技术的规模还是受限，如何做到隔离域有无限大的可能哪？

因为现在来看可能IPV6的地址数目128比特和STT在内隔离域数目最多为64bit，但是终将还是个固定值，相对于将来的星球间宇际通信来说，数目还是少的可怜（当然星球间通信是不是以太网或IP还是未知数）。

然后回到分享开头所提及的虚拟机技术，个人观点现在KVM/XEN/Hyper-v/ESX等都是半虚拟化，实现了VM跨主机的才是真正意义上的虚拟化，虚拟化方面包括现在盛行的Docker 引入的网络管理组件都是仅是用了已有的网络技术，对网络技术的本质创新都没有做出贡献，仅仅是在使用样式上有了翻新；

但这些确实促进了技术的发展，包括在计算服务器通用后的存储和网络的白盒化，网络方面也促进了服务器网卡虚拟化（SR-IOV等）和交换机的虚拟化（交换芯片的虚拟化和端口hair-pin等特性），服务器网卡收发包方面DPDK的出现也有一定的影响。

这里才到今天真正的主题里说下Neutron相关的内容，Neutron是什么？

Openstack开源社区网络配置管理组件 Neutron的网络服务包括L2-L7 Neutron只是管理配置VM所用网络 Neutron有很多SDN控制器作为plugin

Neutron的主要功能：L2功能（Port、Subnet、Network、Qos、安全组等）、L3(Router/DVR、DCHP等)、L4-L7(FWaas、LBaas、VPNaas、DNSaas-Designate等)。对应的网络功能底层网元实现来看，Port对应VM挂载的VNIC相应TAP/TUN设备，Subnet只是一个IP Pool的数据集合，Network则要对应分配网络类型和相应隔离域ID，Qos功能可以基于OVS来实现，安全组最初基于linux bridge上的iptables，这种有状态的规则前面也提及现在可以基于OVS来实现了；

L3上Router实现是通过linux的Namespace，不过Dragonflow则是通过OpenvSwitch的流表，DHCP和DNS服务最初是通过Dnsmasq；L4-L7的服务开源实现方案里，FWaas是通过Router里的Iptables，LBaas是通过Haproxy，VPNaas则是Openswan，当然现在很多设备厂商比如Juniper、思科、华为和F5将L4-L7的底层实现换成了自己的设备。

Neutron的机制是通过plugin/driver/agent等方式实现不同底层网元实现的集成，plugin里L2-L3称之为core plugin，L4-L7成为service plugin；driver是同一个plugin下替换不同网元实现的方式，而agent是部署在底层网元一侧的相应Driver代理，来对网元转换参数并下发到网元里；

Dragonflow/OVN是Neutron比较新的Core plugin，不过都想将service plugin也统一起来。Neutron的未来，这里借用下华为同事章宇（sina微博：一棹凌烟）的话说：将来只剩下Neutron的北向API及Neutron server；这点比较赞同；

Openstack本来只是一个框架，底层实现应该让云平台厂商来定制化。

Neutron毕竟是份开源代码，现有实现ML2等有比较多的缺点：

过多的臃肿代码，维护和修改比较困难

这么多plugin，这么多种类plugin，也是醉了

系统工程师思维搞网络，软件才可控

无法理解和集成硬件是其永远的痛，设备商的加入才走向网络正规

开源实现思路，实现优先，产品化次之

企业厂商产品化道路多舛，有碍Neutron社区发展

多方利益博弈，规划道路多变

主张所用技术经常被颠覆，积累容易付诸东流

Neutron的演进：

Nova-network是前身 Core plugin完成L2/L3/DHCP等基本功能 Service plugin完成L4~L7功能升级 DVR等实现系统层次的HA可用 Neutron结合SDN实现网络可控为终极形态 ，Neutron有很多SDN控制器作为plugin

这里提及下DVR，解决同路由下跨网段的三层东西流量卸载 ，减轻集中式网络节点负担 ，因为同网段二层通信本来就不经过网络节点，DVR的实现软硬都可以，并不只有OVS等虚拟网元才能实现。