有些朋友一看这个问题可能会有些不知所云，如果SDN控制器不管物理交换机，那么它管什么呢?答案是只管理虚拟交换机。这里，博主需要插入一个简短的科普。自从云计算盛行以来，主机虚拟化技术已经深入人心。任何一台物理主机上都可以同时运行多个虚拟机(docker是另外一个话题)。那么问题来了，一台虚拟机的网络接口是如何接入到物理网络的呢?最初，人们会在物理主机上跑一个软件hub，所有虚拟机的网口都会接入到这个软件hub。这个hub会有一些端口和物理主机的网卡相连。随着主机虚拟化技术的不断完善，这个软件hub逐渐被软件交换机(software switch)所取代，其中最具代表性的是open virtual switch(OVS)。虽然叫交换机，但其实它也可以做三层路由，访问控制(ACL)甚至是一些动态的路由协议。在SDN和OpenFlow的概念最初被提出时，它的原型系统就是由一个SDN控制器集中控制多个OVS，在OVS之间建立全互联的隧道(full mesh tunnel)。在这样的架构下，SDN控制器和OVS都是普通的软件，不需要任何特殊的硬件支持。于是SDN控制器和OVS都得到了快速的迭代。这种SDN架构也成就了Nicira。时至今日，Nicira的SDN解决方案仍然是用控制器控制所有的OVS。物理网络仍然采用传统的二层三层协议。业界往往称Nicira的SDN架构为overlay方案。这种方案最大的好处有两点：首先，所有的OVS流表都装在服务器内存里，理论上可以支持巨大的流表。第二，overlay方案根本不控制物理交换机，部署灵活，就如同在服务器上装一个软件，单凭这一点就可以快速赢得客户。

用SDN控制器管理物理交换机最早出现在2008年的Sigcomm上。与overlay方案对应， 博主把这种方案成为underlay。由于绝大多数硬件交换芯片是为二层和三层交换设计的，而OpenFlow的转发模型却是wildcard match + action，导致在很长的一段时间以内人们只能把OpenFlow消息转化为TCAM表项。即便到了今天，最成熟的商用硬件交换芯片也仅仅支持10^3数量级的TCAM表项，这成为了使用SDN控制器控制物理交换机最大的瓶颈。围绕这个瓶颈，世界各地的专家们前赴后继。目前主要分为两个阵营。Nick McKeown教授作为SDN的发起人之一，主张彻底重新设计硬件交换芯片，目的是让硬件交换芯片支持多级流表，每一级流表都支持match + action。另外一个阵营则以Rob Sherwood为代表，主张挖掘现有硬件交换芯片的潜力，充分的排列组合OpenFlow协议中的match和action，尽量把match+action在二层和三层的流表中实现。TCAM流表仅仅用来应对一些复杂ACL。无独有偶，盛科张卫峰总的主张也和这个观点不谋而合。看来学院派的人士充满了理想主义情怀，工业界人士倾向于渐进式的创新。

科普完毕，业界有人在采用overlay的方案，也有人在尝试underlay的方案。那么那个选择更合理呢?在这里希望大家做个深呼吸，稍微深入的思考一下这个问题。博主的教训是无论选择哪个技术流派，你都为自己挖下了一个巨大的坑，这个坑你逃不过。在某一个阶段，你一定会或多或少的后悔：如果当初做另外一个选择就好了。我们不妨先看看业界大佬的观点是啥。你会突然发现：大佬们原来也在努力从自己挖的坑里爬出来啊。

Scott Shenker, 这位大神就没必要介绍了，作为著作被引用最多的计算机科学家，作为SDN的发起人之一，ONF的发起人之一，他的观点犀利且富有前瞻性。关于SDN他有两次广为流传演讲，分别在2011年(The Future of Networking, and the Past of Protocols)和2013年(Software-Defined Networking at the Crossroads)。对比这两次演讲，大家不难发现对于用SDN控制器管理整个物理网络，Scott从坚定的支持派变成了反对派。他转变的主要原因其实只有一点：不计其数的网络服务需要灵活部署，不计其数的网络策略需要快速准确的执行，所有这些从网络边缘实施会更加容易高效，边缘以内的物理网络仅仅需要扮演一个水管的角色，是否用SDN集中控制不重要。在他描述的世界中，SDN控制器控制OVS给网络报文打上不同的tag，物理网络只需要根据tag转发就好了。

在另一个方面，虽然Nicira是overlay SDN解决方案的旗帜性公司，但Nicira也逐步开始管理物理交换机了，至少是开始管理top-of-rack(ToR)了。这里我们不妨看一下Nicira大神Bruce Davie的两篇博客。在2011年，用open virtual switch打隧道棒极了，部署灵活，服务多样，各种流表无限大，性能也号称没有明显的瓶颈[link]。但是在2013年,Bruce忽然话风一转，开始把隧道放在了ToR上，他把原因主要归结于支持bare metal服务器[link]。所谓bare metal服务器是指那些没有采用虚拟化技术的主机，在这些主机上，没有OVS，overlay方案自然也无计可施。为了在这种环境中部署overlay SDN解决方案，隧道被很自然的打在了ToR上。在Bruce 2013年那篇博客的结尾，他这样总结了两种方案的取舍“Our expectation is that software gateways will provide the greatest flexibility, feature-richness, and speed of evolution. Hardware VTEPs will be the preferred choice for deployments requiring greater total throughput and density”。博主我真是太佩服这些大神的说话技巧了。如果我们仔细揣摩它的后半句，不难发现，Bruce在暗指用OVS打隧道可能会成为吞吐量的瓶颈。兄弟这里没有数据，于是斗胆引用盛科张卫峰总的一篇微博“做VPC网络性能对比测试的，发现单向打包测试的时候，1G情况下，软硬件方案性能差异也就10%的差距，而一旦测试双向打包，发现性能对比一下子明显了，差不多有40%的差距。另外一个明显的对比是10G下的时延测试，软件是毫秒级，硬件方案是微秒级”。博主我猜这里的VPC是指“Virtual Private Cloud”而不是指其他东西，我不了解此项测试的具体内容和方法，在此引用是希望让广大的工程狮兄弟们在决定跳入overlay大坑的时候对性能要格外关注，特别是在决定要大规模部署之前。

在博主看来，优秀的解决方案总是会最终趋同的。这种现象有些时候会被人误解为抄袭。但事实往往是人们通过不同的路径到达了同一个结论。在SDN的世界里，这个结论已经呼之欲出了：我们需要SDN控制器同时管理overlay和underlay，博主把它称作fullstack。也许这个名称并不合适，但大家领会精神就好。在分析这个结论之前，我们看看各个厂家都在做什么。Cisco作为传统的网络设备提供商，早已经把触角伸到了overlay甚至是更上层的各种应用，正在进行的ACI与OpenStack的深度整合就是最好的例证。VMWare在2014年10月份将Guido Appenzeller招致麾下，让人对VMWare涉足物理网络产生无尽联想。Big Switch Networks的overlay和underlay解决方案都已经成熟，目前正致力于将二者结合。各大厂家不约而同的开始向一个方向发力，也印证了fullstack是未来的方向。那么究竟是什么原因让大家弃overlay和underlay而转向fullstack呢?

先说说overlay方案的局限。首先，它太!贵!了!这个账怎么算呢?比如我们要采用overlay的方案建立一个多租户的数据中心。物理网络的解决方案本身就需要花一笔钱。服务器虚拟化解决方案是第二笔钱(更高大上的术语是orchestration，比如OpenStack的nova)。这还不够，我们还需要将overlay SDN解决方案和orchestration系统深度整合，用SDN控制器管理每个服务器上面的OVS，这是第三笔钱。如果采用fullstack，这三笔钱就会变成两笔。第一笔是用orchestration解决方案管理虚拟机和bare metal服务器，第二笔钱是用fullstack SDN方案管理整个网络，物理网络解决方案的开销就完全省掉了。fullstack SDN控制器可以通过plugin的形式和orchestration系统深度整合，正如OpenStack的Nova和Neutron之间的关系，只是在这里Neutron plugin通过fullstack SDN控制器直接控制整个网络，而不是像OpenStack Juno release那样仅仅在OVS上做分布式路由(DVR)。

overlay方案的另外一个致命的问题是它并没有完全的从物理网络解耦合，仍然需要服务器管理团队和网络管理团队的密切合作。一种最常用的多租户解决方案是用vlan区别不同租户，也就是说，在overlay方案中每增加一个租户，网络管理员就需要在物理网络中人工配置一个vlan，这一个人工参与的环节就可能引发诸如配置错误，网络升级困难等问题。另外一种做法是采用vxlan，问题是vxlan需要物理网络支持ip multicast，这个协议troubleshooting起来又相当麻烦。在vxlan和非vxlan交界的地方还需要部署vxlan gateway，但这个vxlan gateway又往往成为性能瓶颈，饱受诟病。这里，博主可以举出更多的例子。但核心观点是: 本来只有一张网，引入overlay之后就需要维护两张网，并且两张网还需要彼此协调，运维成本并不会便宜。

第三个overlay方案可能存在的问题是它的性能，这一点在之前的段落中已经有所涉及。到2014年10月为止，博主并没有做过overlay方案的性能测试，这一段留个空白，以后补齐。

下面我们来看一下underlay方案的不足。现在市场上underlay的解决方案很多，大概分为两类，一种是用控制器集中管理配置，交换机之间仍然采用分布式的二层三层协议。另外一种是用控制器直接控制所有的交换机的转发行为，交换机之间不跑任何分布式协议。不论哪一类，它们离上层的应用都太远了，正如博主在第二篇文章中举的例子那样，每新增一个租户，每部署一个多级的应用或者每插入一个网络服务，都需要网络管理员进行仔细的规划和手工的配置。其实overlay解决方案的产生以及NFV(network function virtualization，在以后的文章中会详细讨论)的兴起本质上都是由于underlay方案的这个不足。

好了，分析完overlay和underlay方案的不足，希望大家也开始理解为什么SDN诞生了那么久，但总给人一种雷声大雨点儿小的感觉。因为现有的SDN解决方案不是overlay就是underlay，它们都有一些自身难以越过的局限。在经历了几年痛苦的学习过程之后，业界终于意识到：如果再在overlay还是underlay这个问题上纠缠，情况不会有任何改观。于是各大厂家都开始向fullstack转型，用一个SDN控制器管理所有的物理交换机和OVS。因为只有这样才能1) 用最经济的方式部署上层应用和网络服务，避免一切的box by box的手动配置，2) 没有overlay方案的性能瓶颈。成熟的fullstack方案已经箭在弦上，对于SDN的大规模部署博主持非常乐观的态度。

作者：xinwu

来源：51CTO