第2章杂谈SDN

上一章提到过，网络技术当下属于SDN的时代，数据中心则正是SDN的主战场。不过在介绍SDN在数据中心的应用之前，有必要先来好好地聊聊SDN。SDN的入门资料在网上俯拾皆是，所以本书不再赘述。本章主要是谈观点，希望能够引导读者对SDN做一些深入的思考，既能看得到面子，又能瞧得见里子。

2.1　SDN与传统网络——新概念下的老问题

SDN是个时髦的概念，但是它和传统的网络技术究竟有什么区别呢？这是个没有标准答案的问题，一千个人对SDN有一千种理解，但是万变不离其宗，无论是由谁通过怎样的方式来定义网络，其作为通信系统的本质和内核是不会变的。SDN只不过是变革了网络的交付模式，而它在技术上所面临的大部分问题实际上在传统网络中都有迹可循。本节旨在帮助读者认清SDN新概念下的老问题。这是个不小的话题，总要找到些思路上的依托。在较为普遍的认识中，SDN具有三大特征，包括网络可编程、转发与控制相分离以及集中式控制，下面就从这三个特征进行切入。

1.转发与控制分离

路由设计之初，专用的转发芯片尚不成熟，转发通常是基于通用内核来做的。这个阶段的转发和控制都是由CPU来实现的。对于每一个数据包，CPU都要通过复杂的软件查找算法来匹配转发逻辑，因此在转发速度上有很大瓶颈。再加上CPU还要对网络控制消息进行处理，转发和控制对有限CPU资源的竞争时常会导致网络性能出现很大——波动。随着ASIC的成熟，业界通通转向了将转发和控制相分离的架构：设备里面ASIC和CPU各司其职，CPU负责计算密集型的控制逻辑的处理，完成计算后通过特定的通道（如PCIe）将转发规则下发给ASIC；ASIC负责按照转发规则进行高速转发。ASIC的灵活性较差，于是又出现了NP、FPGA等，不过转控分离的架构得以保留，目前的网络设备中已经看不到由CPU包办一切的情况了。这和SDN提出的转控分离是形似的。

估计很多的读者要问了，不是吧？传统设备是在盒子内部“1cm”的转控分离，而SDN的控制逻辑可是在远端的。这是个非常普遍的错误理解，笔者在最开始接触SDN的时候也是这么想的，因此曾经长期困惑于一个问题：如果SDN的控制逻辑一定是在远端的，那么控制器下面肯定不能是对着一个设备，那么“集中式控制”是否是“转控分离”一个必然的结果呢？

实际上，SDN“转控分离”的内涵并不在于远端，而在于开放。ForCES作为最早的SDN标准是没有要求CE和FE一定要离得有多远的。传统设备的转发与控制的确是分离的，但是转发的接口可不是标准的，更谈不上是开放的，不同ASIC上同一种控制逻辑是没有办法直接移植的。换句话说，架构上转控是分离了，但逻辑上转控仍然是强绑定的厂商们正是靠着这一点来捆——绑了硬件和软件。对于厂商来说，这种捆——绑通常意味着高技术门槛、超额的利润以及牢固的用户锁定，因此他们的一切战略都是围绕着盒子的整体交付来铺开的。商业上不可言说的原因为网络的创新铐上了沉重的枷锁，而SDN要求软件和硬件解耦合，这就是厂商们抵触SDN的根本原因。

因此OpenFlow和ASIC的SDK并没有本质的区别，更多情况下只是对相同硬件的不同控制方式而已，抽象程度不同罢了。很多人攻击OpenFlow说PacketIn和FlowMod的性能问题没有办法得到解决，可是传统设备的收敛也是要有一个过程的，转发表总不可能是凭空生成的，ASIC和CPU间的双向通信同样不可避免。如果特别在乎与远端的控制器间通信的时延，那么把OpenFlow控制器放在设备本地就好了。当然，这放弃了OpenFlow集中式控制的能力，但是仍然可以获得开放转发与控制间接口的种种好处。对于OpenFlow的误解还有很多，这里先卖个关子，下一节会为OpenFlow做一个“平——反”。

目前业界SDN实现可分为狭义和广义两种，狭义SDN的典型实现包括ForCES和OpenFlow，上面说过其本质在于转发与控制间开放的标准接口。而要理解广泛意义上的SDN，则可以直接从SDN的名称入手：既然称为“软件定义网络”，可编程才是SDN的基本特征，所有允许通过编程控制的网络都属于广义SDN，可以通过编程来控制网络的技术都是SDN技术。概念上有了“可编程”作为基础，厂商们找到了从转控分离逃离出来的理由，从API的角度来切入SDN。实际上，SDN的先驱们在起这个名字的背后可能包含了技术外的多方面考虑——它能够给厂商一个缓冲的机会，或者反过来说这也是SDN至今仍然能够活下来的必要妥协。

2.网络可编程

可编程性自从网络出现以来一直是个热点话题，并不是什么SDN独特的创举。脚本就是最为初级的编程，通过对CLI进行组合与包装来提供网络的自动化。当面对两三台设备的时候，手敲CLI然后show一下是最为稳妥的方式。当面对十几台设备的时候，或许写个简单的脚本是更好的选择。当设备的数量有几十台的时候，脚本几乎就是唯一的选择了。可是，当面对整个数据中心的设备时，简单的脚本可能就不能满足需求了，一边心里念叨着“这该死的IT”，一边祈祷网络不要出现故障。

SDN的出现是希望让网络变得更加智能，SDN“可编程”也并没有要求一定是“转发可编程”，从概念上来说只要是编了码都可以算得上是广义上的SDN。因此，“可编程”可以说是个相当宽泛的概念，这也导致了目前业界SDN技术的百家争鸣。网络运维基于SSH或者RPC做远程集中式的脚本开发，省去了到设备前去配CLI的，这种算不算是SDN呢？网管系统开发基于SNMP来做接口包装、界面呈现，SDN提倡的网络可视化SNMP也有极为丰富的支持，这种又算不算是SDN呢？SNMP有可读性差和不支持事务操作等缺点，于是NETCONF/YANG被提了出来，可是YANG不过是Yet Another Next Generation，而NETCONF在2006年由Juniper提出来的时候也没人提SDN，为什么现在就火了呢？BGP几乎所有的路由器都支持，弄一台服务器做BGP反射，然后通过调用数据库接口来做一些选路策略，为什么大家都认可这很SDN呢？这些都是容易引发争议的话题，不过在新的时代，传统的技术确实是可以被赋予新的概念的。既然先驱们起了SDN这个名字，那么就要辩证地来看，不过这个话题的讨论还是要有底线的，否则SDN就变成了“大锅汇”，会出现很多“看起来很奇怪”的选手。

从脚本到程序，SDN只是为了塑造一个“更好的网络”，而并不是一个“完全不一样的网络”。这原本是一件好事，却让相当一部分搞网络的人心里打了鼓，让程序员这个“具有野心”的行当成了网络界的“阶级敌人”一般的存在。实际上，SDN试图推动的是网络界精细化分工的过程，而编程只是其中的一个环节。IT的各个行业都希望得到既懂编码又懂业务的复合型人才，但这样的人毕竟是有限的，网络的蛋糕足够大，是可以同时容得下只懂网络架构和只懂代码的专才的。

3.集中式控制

与转控分离和可编程不同，对于SDN的另一个特征“集中式控制”的争论，则更多地出于技术方面。传统网络架构上是基于分布式路由协议的，但是并不是没有一点集中式的影子在里面，大家熟知的WLAN中的AC就是典型的例子。诚然，相比于分布式，集中式在可用性和扩展性方面确实有一些不足，但是这些问题实际上并不是无解的，传统网络就是最好的老师。

在可用性方面，传统的设备看起来就那么一个盒子，除了协议一直在打补丁、端口速度不断进化着以外，好像看不出别的什么学问来，但是把盒子拆开了来看，里面的设计架构实际上和SDN是类似的。大型的盒子里面，业务板都是多插槽，背板也很可能有多块，这些业务板和背板上的逻辑都是由引擎来集中式控制的。那么引擎挂了怎么办，是不是业务板和背板就都不能用了？当然不是，想获得高可用性，可以为盒子多准备一块引擎做冗余。如果两块引擎都挂了或者要在线升级，那么可以使用NSF、GR、ISSU这些来保护业务的数据通道。要是盒子整体挂掉了怎么办，那就多买盒子做主备或者多活。

在扩展性方面，传统网络的扩展性是由分布式来保证的，BGP撑起了Internet的基础。然而在大规模网络中，BGP都需要有一个RR作为路由的集中点，否则由于Full-Mesh也是难于实现可扩展的。每个路由器都和这个点去建邻居，这个点统一收集大家的路由然后再去分发。那么，这个还是分布式吗？是的，因为路由的计算还是路由器自己完成的，集中式的RR只负责原封不动地反射。可是不管怎么样，这个点和SDN控制器还是处在相同的位置上。而且多数情况下为保证控制平面的性能，RR是不会跑转发的，这和SDN控制器就更像了。RR不会有扩展性的问题吗？答案是会的，解决的办法是专门对BGP代码进行优化，来把性能做强。可是经过优化过后，一个RR最多也就可以带几百个BGP邻居，如果仍然不能满足需求，那么就再为RR引入分簇做冗余或者分级做层次化。

因此，SDN的集中式为人诟病的可用性和扩展性的问题，并不是传统网络没有遇到，而是它们已经花了多年的时间把问题解决了。但是，传统网络的可用性和扩展性也不是免费的，核心交换机和路由器那么昂贵的价格，每个炫酷的Feature可都是做出了自己的贡献的。当然，如果有一天SDN也演进到和传统网络一样成熟，其成本也不会太低。不过，转控分离和可编程为SDN带来了更为开放的生态以及更低的实现门槛，这些才是传统网络向SDN转型的本质驱动力。另外，控制器的CPU和内存相比于盒子而言可以看作海量的，控制器的性能不再完全受限于代码的实现质量，一定程度上还可以靠“堆资源”来进行弥补。

这一节的讨论粒度是比较粗的，只是希望能帮助读者认识到SDN并不是“网络异——教徒”，相反，SDN恰恰是网络界再次开动技术引擎的助燃剂。后面几个小节，将会对SDN的几个特征进行更为深入的讨论。