多云互联的现实困境与开源SDN之路丨首场TFMeetup演

点击下载文档，查看本文所有相关资料。https://163.53.94.133/assets/uploads/files/open-source-sdn-kk.pdf

专注于为中小企业提供成都做网站、成都网站建设、成都外贸网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业尖扎免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了成百上千企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

昨天，TF中文社区新年首场Meetup如约而至，关心多云互联的众多嘉宾赶来“赴约”，活动现场成为开源SDN爱好者的一次聚会。来自Tungsten Fabric技术研发和一线使用者，与大家分享了多云环境部署的现状、SDN开源技术及应用案例。现场气氛热烈，讨论延长近两小时，不仅有专家和参会者的互动，也有参会者之间的讨论和支招。Tungsten Fabric在中国的广泛应用正在越来越真切的走来。

我们将陆续发布本次活动的精彩内容，首先带来TF中文社区技术代表、瞻博网络中国区合作伙伴技术经理张建勋的演讲，分享多云现实的困境及出路。

TF中文社区技术代表、瞻博网络中国区合作伙伴技术经理 张建勋

大家好！抛开厂商的身份而言，一直以来我抱着一个很“戏谑”的态度来看待SDN，SDN的英文名称是software defined network，我更喜欢把他翻译成---“啥都弄”，好像所有和网络沾边的东西都往SDN上靠。当然，戏说归戏说，在实际的应用场景中，客户的IT建设旅程中客户越来越去关心关于多云，关于开源，关于SDN落地的现实问题。

在和大量客户沟通的过程中，我们发现客户的IT基础架构建设到一定规模的时候，在网络层面一定会遇到各种各样的问题。这些问题在以前的时候并没有碰到过，在多云的场景下，SDN遇到了挑战，以至于它的业务并没有真正的执行，或者说业务并没有真正通过SDN的方式去实现。

接下来我演讲的内容，一方面是基于技术的细节，另一方面是从发展趋势和客户的反馈来做分享。

我们天天在讨论多云，为什么会有多云？客户为什么会去选择这样一个架构？是求新求炫，我想原因是多方面的，而现实情况下，多云是很多客户IT基础架构向前发展的必经阶段。

站在技术演进的角度来说，最早客户开始做IT的时候，就是买服务器、装操作系统、装数据库、做各种各样的应用，对吧？当时是没有任何虚拟化的，这种情况下也谈不到云，就是所谓的烟囱式的架构，一个业务就是一套系统，数据-存储-网的这样一套系统。

后来有了虚拟化的概念，这是大家都知道的一个共识，虚拟化是云的基础，引入了一些商业化的虚拟化软件，再后来有了第三方开源的虚拟化编排系统，几年前特别火的就是OpenStack，我相信在座的很多从业人员，一定都是从OpenStack里面一步一步跟着演进过来的。在经历了架构变化后，加上这种开源的虚拟化，大家对云的认识逐渐走向了成熟。

在三、五年前的时候，我们去跟客户沟通，还要跟他们讲云能带来什么好处，现在就很少讲这个了。客户更多想要的是，我怎么去实际做一个云。IT的技术，尤其是网络部分，越来越紧密地和业务应用结合起来。

不过，所有的业务在开启、迁移的过程中，在实现所谓的弹性的过程中，从业务系统、计算、存储的角度，都有自己的弹性化设计，但网络不一定有，这就会带来很大的问题。当客户接受了更深层的云化技术之后，这两年我们突然发现，虚拟化的形式发生了变化，从原来VM的形式变成了柔性化的形式。K8s逐渐火了起来，真的是解放了大量的生产力，但是也带来了非常多的问题。

整个行业里面云的平台和技术都有变化，但不是那种颠覆式革命性的变化，而是呈阶段性的，不同的平台，不同的技术共存，共同支撑客户IT架构这样一个情况。

另外，客户的IT应用实际上是有它自己的技术特征的，对于高可用性技术的依赖和使用，意味着业务可能会放在不同的平台下。

再进一步，在技术不断提升的过程中，客户还有对于技术把控性的需求，像金融，互联网企业，大型的企业客户，他们都会出于本身技术创新性的考虑，我要利用新的技术去实现我们自主创新。

这导致在现有场景下，客户至少会有两、三个平台的存在，同时也可能会有物理机的存在，在这个情况下，多云实际上就不是以往厂商的角度，而是客户在他的设计规划以及演进的过程中一个必然的状态。

在迈向多云的过程中，我们可以去学习各种技术，但是整体的企业IT架构最难的部分其实是管理，是我们如何把这些多云环境统一为我们所用，这一点是最难的，也是最复杂的。这种管理包括资源调配，包括网络通信，包括业务能否真正映射到下面的基础架构中，在技术的管理之外，还涉及到整个体系的管理。

在选择使用云服务的时候，客户乃至整个行业都能够得到一个共识，云可以改变IT架构，可以将资源集中，可以让我们的业务更具经济性、更具弹性。但是，基于目前的多云部署现实，网络环境和基础架构采用多云环境，又使得资源从原来极度的分散，变成一种多云的集合。

对于一个客户而言，他可能既有公有云的平台，也有私有云的平台。在私有云的平台中，还可能会有混合部署的环境，包括VMware、OpenStack、K8s、OpenShift等各种各样的网络基础架构。

从云的本质上来说，我们是有计算资源、存储资源、网络资源，以及相应的协调和编排，但由于选择得了多云环境，产生的一个结果就是，每一个云都是孤立的，每一个云都像是一个信息的孤岛。这也是为什么我们说网络在这两年变得更加重要。

在行业拥抱云的过程中，是想要用管理的方式去解决的，而对于一个企业而言，更希望看到的是什么呢？不管云是什么形态，什么结构，什么内容，都能够有一个统一的界面，下面管理的不再是裸机的服务器，不再是原来的那些交换机，而是云。

资源就像自来水一样，想得到什么就是什么，而不需要关心下层究竟是怎么样的。于是更多企业开始考虑，在多云的环境下，在技术平台上放置一个CMP云管平台，去做多云的统一管理。

但这个过程不是那么容易的，没有任何一个通用厂家的产品可以做到，你没法做排列组合，它一定是很定制化的，因为每一个客户用的云平台可能是不一样的，对技术的诉求是不一样的，对云的资源的使用流程是不一样的，对云投资和保护反馈的信息是不一样的。

这实际上就是行业中大家共同的一个愿景，通过资源的管理，实现可创建的自动化，可迁移的自动化，可编排的自动化。要真正实现这个愿景，我们需要从网络的角度，下沉到不同的技术要求当中去。

SDN就是伴随着云的发展而来的，在SDN中我们可以将功能去做一个拆解，这种拆解包含于数据中心的不同环节。而针对于数据中心内部，我们只有一个非常朴素、简单，而且很重要的功能，就是在多云平台环境下，在数据中心内部实现统一的网络打通，进一步是underlay硬件设备的管理；而在数据中心之间，我们希望实现业务在多个数据中心之间的双活，包括流量管理以及运营调动；随着混合云进入人们的视野，我们更多会关注针对于不同的公有云平台，能否实现统一的网络打通，能否实现统一的SDN的调配和管理。

同时，在网络环境中进一步增加业务的统一安全策略，从而实现联，智，展，安这几个基本功能。

所以，针对于整个网络而言，最基本的诉求就是，任何一个位置，我都可以将你的业务通过自动化的方式去打通。而在多云环境的现实中，SDN实际上在真正使用的过程中，还是遇到了各种各样的难题。

这种难题主要在于，我们部署的环境所采用的技术并非是开放的技术，而是过分依赖于网络交换设备的平台，由于我们将云平台做了不同环境的割裂，所以在网络这一块，并没有实现统一的调配。

比如说，我们今天要建设一个小的数据中心，那么这样一个数据中心要用某一个平台，或者某一个架构，你可能所有业务的联系都要由该设备的厂商来提供，或者说都会有这一部分硬件的交换。

这在小型数据中心的环境里是没问题的，但如果我们将数据中心延伸，或者要扩展一个数据中心，还要去采购另外一套硬件的设备，在采购的过程中就会出现这样的情况。

这对于客户所带来的挑战是，你需要了解每一个硬件SDN，它所支撑的功能是怎样的；其次，所有的硬件SDN之间很难实现互联互通和统一管理；第三，如果我们将服务进一步去打通，增加云中的应用服务，比如服务链的功能，基本上就是无法实现的，同时，还会存在技术的演进和挑战问题。

所以我们在想，在客户的多云发展历程中，我们应该提供的是统一的网络，不受任何硬件设备的限制，也不受任何软件平台的影响。在我们去致力于推广Tungsten Fabric的时候，想做的事情，就是在这样一个环境下，将云网络的功能从原来的硬件设备的部分迁移到软件的部分，所有SDN执行对应的技术细节，都将由软件来完成，并且它还是一个开源的软件。

这种思路和想法，实际上也是行业中存在的共识。比如说，我们去看Amazon、Google这样的国外的公有云，当他们去部署SDN和云的时候，是不会受制于任何一个硬件交换机厂家的。国内也是一样，我们去看腾讯、阿里、百度，它们整个云化数据中心的部署，同样有很多硬件设备供应商的参与，但这些厂家并不会加入任何私有化的数据中心技术在里面。

计算的资源可以统一调度管理，存储的资源也可以统一调度管理，唯独网络，当网络被撕裂之后，我们整个数据中心就会被拆解得七零八落，很难统一地架构起来。我们希望达到的效果，就是在部署的过程中，所有的上层云平台下发的，关于网络的要求和指令，都由一个统一的SDN控制器来完成。

这个统一的SDN控制器，会将它要求的服务和策略直接下发到底层的软件层面，而这时我们在中间负责转发实际数据的硬件交换机，仅仅作为最简单的数据传输的服务就可以。

那就意味着，在这样的过程中，中间层的硬件交换机它是可以被替换的，甚至于它的功能可以进一步去削减。这种方案既减少了客户对硬件设备的功能依赖，同时也让我们在选择一个方案的时候，可以根据软件的要求做进一步的扩展。Tungsten Fabric作为一个开源SDN的解决方案，就是致力于去解决这样一个问题。

Tungsten Fabric原来的名字是OpenContrail，2013年正式开源，2017年加入到Linux Foundation，并在2018年更名为Tungsten Fabric。这是在现在的多云化环境中，一个非常流行的，无论从功能性还是性能角度，都可以为客户带来实际SDN帮助的控制器，而且它是一个开源的平台，这一点非常重要。

这些年我们看到，国内很多的企业和行业，他们在应用云的速度、需求和多样性上会比国外更多。在他们寻找适合自己的云资源管理和调度的过程中，开源带来了更多的创新性。

在进行部署的过程中，我们使用的方式非常简单，就是在服务器层增加一个vRouter，这个虚拟路由器将作为每个服务器节点上的网络控制管理、策略执行，以及转发的平台。它包含两方面内容，在控制平面，会统一地接受SDN控制器的调度，去创建网络，连接网络，以及执行相应的策略。在转发层，是基于LinuxKernel去进行转发，转发过程中可以采用不同的封装方式。

实际上大家可以看到的是，我们现在的网络构架，尤其刚才我提到过客户逐渐走在多云的环境中，他们面临的急迫诉求，就是在不同的环境中如何采用一个统一的网络解决方案，而且这个解决方案一定不是某一个独立的厂家，或者是有独立的产品平台去提供。

从现在的技术发展上来说，Tungsten Fabric现在已经开始使用docker的方式，容器化会成为未来的一个技术方向，本身SDN的平台也需要做进一步的规划。我们的产品从早期的3.0，发展到现在的5.0，已经完全是一个容器化的产品了。从整体部署上来说，我们也支持针对于容器的平台的支撑。

其实这半年我们跟客户拜访的过程中，发现他们面临着很大的问题，不是说K8s本身的问题，而是K8s网络的问题，他在网络设计方面有自己的独特思路，以至于迁移的过程中，会带来很多纠结的部分，内部IP怎么访问啊，ingress和service到底什么关系啊等等。在这一块，开源的Tungsten Fabric K8s平台，可以解决客户在实际的部署场景中网络通信的问题。

更进一步，客户在进行网络以及业务迁移的过程中，比如说从传统OpenStack迁移到K8s，或者说从裸机迁移到K8s，在这个过程中我们去实现网络的打通。

我们再来看安全性，客户经常面临这样的问题，比如说有三个场景，第一个场景是测试的环境，我们从A到B到C有三个业务，这三个业务如果要做一个策略的话，在第一个场景中我们要有一个策略，而且是一个管理层级的下发下去，如果存在第二个数据中心，可能我会有第二个策略，到第三个数据中心，会有第三个策略。

在Tungsten Fabric我们希望实现的，是只使用一个策略，跨越多云，多个环境，那就意味着所有的安全策略将不以位置和平台去做决定，而完全基于客户的业务能力。我们去确定ABC，不管这三个业务分属于哪一个平台，对我来说只使用一个策略，而且在开源的版本中直接可以明确实现。

更进一步，我们希望将策略不只部署在私有云的环境中，还能在不同的公有云环境，以及不同的平台下统一地去做支撑，这是我们希望看到的。在未来的SDN场景下，我们能够为客户提供统一的网络连接，以及统一的安全策略，这是SDN要做的一个非常重要的职责。

总结来说，多云互联的问题实际上是客户发展过程中一个很大的痛点和瓶颈，因为你在不断迁移的过程中势必会有多个不同的平台，既存在于公有平台，也存在于商业化的平台，甚至开源的平台。在此过程中，有一个统一的SDN控制方案进行管理是非常重要的，它可以帮助客户去实现业务的联通，以及安全策略的统一部署。

更进一步，客户希望将技术掌握在自己的手里，当我们进行科研创新的时候，开源技术可以给予我们很多滋养，它是一个开放架构的开源平台。

我相信，在未来整个产业不断发展的过程中，在技术架构上一定是开放的、解耦的，在界面上是统一的，可以为其服务的行业提供统一的云化管理，同时进一步实现国内的云相关技术的自主、可控和创新。

Tungsten Fabric为我们所有行业里的人带来的是什么？我们看到一个自主的，一个可以帮助客户实现多云互联、便于管理，并且不会受到任何硬件设备限制的解决方案。

很感谢今天能来这么多人参加这个会，大家都这么关注开源SDN，我们也需要进一步思考，究竟什么样的SDN对行业是有帮助的。希望相关行业的技术从业人员，可以关注Tungsten Fabric的发展，我们也致力于和客户一起去实现云的自主创新，推动未来的产业发展。

谢谢各位！

---

关注微信公众号：TF中文社区

当前标题：多云互联的现实困境与开源SDN之路丨首场TFMeetup演
地址分享：http://mswzjz.cn/article/johpjs.html