随笔- 1793 文章- 1 评论- 61 阅读- 297万

【转】浅谈SDN

原文：https://zhuanlan.zhihu.com/p/144676870

----------------

最近工作啊学习啊，比较忙，少有时间抽出身来做其它事情，今天，简单来说说一直很火又不温不火的SDN，也就是软件定义网络。

作为一名游手好闲的网络工程师，多年前，我就开始不看BGP、不看OSPF了，听说SDN挺好，我决心要看看，玩一把新鲜，睡觉前，想起了一个什么概念，起来加个夜班，网上翻翻资料，甚至会因为对某一个知识点的新领悟弄得兴奋不已辗转反侧，然而，然而，现实确是残酷的，因为，瞎折腾了许久，还是，无从下手，不少小伙伴其实都有类似痛苦，不是不愿意学习，而是，说起SDN，很多时候是真不知道从何学起。

SDN是一个很宽泛的概念，分为很多的技术流派，但主要，还是分为以下几类：

第一类：网络设备厂商派系——要玩一起玩，不然，再见！

这里，说说网络厂商的大爷CISCO数据中心级别SDN，思科作为宇宙最大牌的网络设备厂商，早些年也参与了很多网络协议的制定和规范，稳稳地处于leader地位，当然也有很多自己的私有协议，据说部分也已经开放了，但其实不重要，思科在SDN领域内其实逐渐在丧失话语权，所谓软件定义网络，如果你不懂软件，那就更别说使用软件去定义了，思科的SDN方案很有意思，最终交付给用户的就是几台服务器和一堆交换机还有一套软件，这套软件就是SDN的大脑，聪明的你只需要登陆上web控制台，手别抖，鼠标拿稳了，点点点，点完了，完成配置了，可以交付了，这时，花了几万大洋考过CCIE的你会有种被侮辱的感觉，摆明了让你难堪，但是思科的SDN就是这么简单，不需要敲什么命令，你甚至可以不懂BGP不懂vxlan，让你真正体验到用tplink的方式去操作cisco，交换机一堆控制器几台足够提供可靠性，SDN上线后，在性能上，10G-100G转发都不是问题，管理上，简化了网络变更时繁杂的操作步骤，不再需要逐个设备去敲命令，一堆设备一个控制台即可搞定，你还可以制定各种不同的业务路径链接起来形成一套标准化的策略，比如和防火墙和负载均衡进行联动，听起来高大上，但是软件定义你都玩完了，那身为用户的我们玩啥，厂商说，没关系，我把API提供给你，你可以自己进行二次开发，但，前提是，你必须带上我一起玩。

身为老大哥思科的方案这么定了，于是华为、华三的方案也都来了，大同小异，但各厂商之间协议不互通，可谓是戴着镣铐在舞蹈，毕竟，厂商是要充分考虑盈利问题的，卖设备卖平台半点不马虎，至于使用体验，若有机会，我会加入各个厂商SDN方案的详细部署和简单使用评测，这里先不作评论。

第二类：虚拟化派系——会玩自己玩，不会玩我带你玩

说到软件厂商，曾经思科的盟友VMware，在虚拟化方面这家厂商持续保持着全球第一的份额，他们家SD（软件定义）的范围非常广，服务器是虚拟出来的，存储是虚拟出来的，网络自然也是虚拟出来的，当之无愧的软件定义，曾经，思科开特意为VMware开发了一款虚拟化交换机，但在vxlan技术广泛使用后，两兄弟分道扬镳，VMware说，只要保证我的网络能通，我都能给你虚拟化了，交换机、路由器、防火墙、负载均衡都不用买设备了。思科表示纳闷，那你还要我干嘛？分手！于是，各奔东西。vmware的SDN方案使用了vxlan技术，在现有底层网络的基础之上虚拟出一张大二层网络，这就是Overlay网络，所以并不关心你是用思科华为谁家的交换机，虚拟化之后的网络功能可以在每个节点(esxi)上进行实现，理论上来说，或多或少会影响到节点的性能，另外从节点出局后依旧需要依赖底层网络，虽然不关心品牌型号，但底层网络的高效性和稳定性也是VMware解决方案的必备基础条件，由于是运行在各个节点之上，控制使用一套单独控制系统，同样，控制与转发是分离的，即使节点挂了网络组件随即失效，虚拟机可以飘走，也不会有太大影响。还有一个问题应该考虑，即便不买硬件设备了，那么软件价格呢，我想还是聊点别的，VMware的确是好，但同时，也是真的贵。

虚拟化产品非常丰富，除了VMware，还有像Xen、KVM等，早几年火爆的OPENSTACK则是用来解决若干台服务器同时运行KVM的管理调度问题，通俗的说，就是一个云计算管理平台项目，OPENSTACK的网络组件叫Neutron，我们也可以使用其他开源的网络组件，比如OpenVSwitch（简称OVS），也有很多商业化的SDN产品，如BigSwitch的方案，同样，都是为了解决节点的网络互通性问题，区别在于不同的产品方案使用了不同的方法技术并提供了差异化的功能和服务。

不得不提及到的是，服务器虚拟化技术的诞生大大降低了企业服务器采购成本，通过虚拟化企业用户可以轻松建立自己的私有云，当然，使用久了，弊端便开始显现了，例如我所在的企业，虚拟机开了两千台，但是资源利用率并不高，监控显示，这两千台虚拟机中，计算资源使用率普遍较低，新的问题因此而来，比如有台8核8G硬盘200G的服务器就跑了一个NTP服务，为了提高服务可靠性，又加了一台同样配置的虚拟服务器组成了集群，CPU/内存利用率常年处于1%以下，这样的情况非常常见，很浪费，解决方案其实也有，那就是服务容器化，当前最流行的容器化技术非Docker莫属，一台服务器(虚拟机或者物理服务器)可以运行多个容器，同时提供多个服务，直到你认为这台服务器性能用到差不多了为止，但你认为毕竟是你认为，倘若这台服务器运行的容器数量过多，性能被榨干，服务全挂掉大家谁都别想好，于是又有Kubernetes(简称k8s)来帮你解决，k8s解决了多台运行容器服务的服务器之间的服务编排和资源调度问题，若干个容器组成的集群同时提供一个服务，即便是其中某个容器因为所在服务器的问题无法提供服务，集群中还有其他容器可用，业务依旧会正常运行，讲这么多，引出来另外一个话题，那就是容器化之后的网络，容器和容器之间怎样通信？容器和服务之间怎样通信？容器和外部又是怎样通信？这其实依旧是虚拟化网络的一个部分，逃不开软件定义网络的范畴，作为一个开源项目，搞不明白为何谷歌自己没有把网络这部分充分考虑进去，也因此，k8s中最复杂的应该就数网络架构，当前，k8s的网络插件也越来越多，flannel、calico、Weave等，有足够的技术能力，可以自行开发适合企业本身的网络插件，但技术本身很有可能是我们无比熟悉的，比如flannel使用的vxlan、calico可使用ipinip(gre)或者是bgp，这些在路由器上随手就能敲出来的技术，搬到SDN上来，可能会令你一脸茫然，啥，这还是我熟悉的BGP么.......

第三类：OpenFlow派系——纯正意义上的SDN

OpenFlow是一种SDN控制层面的网络协议，从最早的1.0版本发布至今，已经超过10年，目前最新版本为1.5，各大网络设备厂商均有设备支持，应用较多的版本为1.3，其工作模型中，也同样将控制层面与转发层面进行分离，Controller负责将流量控制策略以流表形式下发给受管理的网络设备，交换机设备只需要按照流表上制定的流表项进行逐一匹配和转发，如此一来，也很容易实现对于每个网络节点设备的统一管理，这里强调一点，SDN的初衷并非是要解决网络性能上的问题，对于传统网络而言，除了管理方式上的改变带来运维效率提升外，很难找到更多的功能亮点，只有在虚拟网络中，比如kvm、k8s环境，基于OpenFlow的虚拟交换机或许能够解决一些功能上的问题，目前支持OpenFlow的控制器有很多款：OpenDaylight(简称ODL)、ONOS、Ryu等等，虽然市面上很多交换机支持OpenFlow，但是也只是支持，是否能够很好的与控制器匹配工作，有待验证，大概，未来的某个时刻，会有越来越多的白盒OpenFlow交换机取代现有传统交换机，企业中的网络将成为一套系统，而不再是一台一台的网络设备，当然，这还需要一个漫长的过程，至少当前，网络厂商是排斥的。

这些如同雨后春笋的SDN网络新技术，看上去是对工程师的要求越来越高了，但我认为，这也是SDN发展缓慢的原因之一，大多数网工不懂程序语言，正如OpenDayLight控制器，倘若没有java基础，入门较困难，Ryu是用Python写的，若不懂Python，也很难有所成就，同样，在国内，程序猿们可能对网络一无所知，他们大多数不理解交换机CAM表不懂得ARP工作原理，也不知道IP寻址路由等等，他们开发的程序更多的使用对象是用户，可能是公司的核心业务，而网络只是基础架构中的一个部分，上级部门是否愿意花费财力和人力进行相关开发也是一个很大的问题。