SDN究竟要不要管物理交换机?

有些朋友一看这个问题可能会有些不知所,如果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究竟要不要管物理交换机?

用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的大规模部署博主持非常乐观的态度。

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » SDN究竟要不要管物理交换机?

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址