前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >TF Live丨KK/建勋:多云、SDN,还有网工进化论

TF Live丨KK/建勋:多云、SDN,还有网工进化论

原创
作者头像
Tungsten Fabric
修改2020-06-09 14:46:17
6670
修改2020-06-09 14:46:17
举报

一场疫情,改变了所有人的生产与生活,在时代的不确定性面前,我们应该怎么做?

3月18日,第一场【TF Live】如约而至,活动持续了两个多小时,在线人数将近1000人,互动讨论热闹十足。TF中文社区技术代表、瞻博网络全国合作伙伴技术经理张建勋(江湖人称KK),与大家聊了多云网络演变、SDN开放、Tungsten Fabric创新和网工转型等话题,关键词就是一个“变”字,在当下的特殊时期,尤其值得每个人认真思考。

直播活动由SDNLAB和TF中文社区联合举办。

【直播活动视频回放】 https://v.qq.com/x/page/z0936fbc8fo.html

云卷云舒,SDN应时而变

时代在变,单一混合云,逐渐演变成了多云的环境。多云是混合云的进步。

任何企业的IT发展,都不是革命性推倒重来的,而是逐渐累积,就像给你一笔钱理财,你会分散投资一样,IT也是根据自身的能力,根据技术适应场景去做选择。问题来了,不同厂家都有自己的理念、思路和方法,挑战是什么?

人们发现,SDN不是万能的,很多问题不是SDN能解决的,SDN不要增加问题就不错了。而在硬件SDN上,存在三方面的问题:SDN功能和设备锁定;功能扩展上受制于厂家设备;做NFV和服务链集成时,安全设备引流只能局限在同一厂家。

换一个思路如何?将虚拟网络层统一,由上层控制器统一管理,下发网络的时候,使用统一的策略,下发到每一个对应服务器的虚拟网络设备上。这里存在一个情况,裸机服务器怎么办?需要由物理交换机承担虚拟交换机的工作。

如果将每一个服务器上的kernel层,都安装一个虚拟交换机,下面的网络,通过核心层设备+底层设备,跨越了硬件的交换机,underlay承载的工作就会非常简单,只负责物理设备,只负责IP Fabric服务器之间IP流量的互传,而不用去关心硬件的交换机究竟是什么产品。这种设计思路,在目前主流厂家中很常见,尤其是在公有云环境中。

无论是国外的主流公有云,还是国内的几家,他们的SDN和硬件交换机都是解耦的。SDN应该要做的事情,就是让虚拟机能够在不同的平台运行,业务之间自动的打通。不关心上层是什么平台,K8s也好,Openstack或VMware也好,就单纯为业务创建网络。

我理解现在的SDN就是tradeoff,其实就是平衡,而平衡就是混合,软件SDN的方式,目前在性能上是可以满足需求的,如果一定要追求更高性能,也可以在裸机上实现。

未来将会如何?

首先,未来SDN一定是开放解耦的架构,从全部硬件SDN,变为部分硬件+部分软件。SDN的功能,应该像真正的公有云环境中SDN的功能一样,和硬件交换机是一个松散的关系,解耦的逻辑。

第二,硬件交换机本身,也会有硬件和软件的解耦,也就是白盒化的进一步升级。

第三,在企业云的设计中,最重要的还是IT管理,可能催生出来的机会就是CMP,统一的云化管理,而这个平台一定是定制化的,是和业务紧密挂钩的。无论是集成业务商,还是企业自己建设平台,定制化云管平台都是实现IT转型的很好方式。


Q: 内部云平台可以统一管理,但是多云呢?怎么管理到阿里云、腾讯云和内部统一,怎么统一下发策略?

A: 以AWS为例,私有云和公有云在设计的时候,地址的管理是很难统一的,针对地址或网段的管理,我们在K8s环境下和AWS有个互联互通的测试。我们可以把阿里云的平台,理解成自留地资源,安装了相应的环境和平台,把其中网络的部分理解成underlay,虚拟网络的部分交给Tungsten Fabric来做,其实就是overlay的方式。在AWS、Azure上,都可以采用这样的方式。K8s的集群是可以跨越不同点的。

(演示Tungsten Fabric的多平台访问demo)

可以看到,在K8s、OpenStack、BMS多个平台上,是可以通过开源的软件,实现统一网络管理的,不管虚拟机也好,docker也好,它们可以在一个网里面,也可以在不同的网,根据你自己的需求而定,我们的策略是基于标签tag的,做了一个网络访问策略,是SDN overlay的网络策略,不用去考虑在什么平台下,一旦部署策略,策略就是基于逻辑,基于归属的。

简单策略,跨越复杂部署 

Tungsten Fabric就是一个面向未来的SDN解决方案,想要实现的是:多云的部署方式+统一的策略。

Tungsten Fabric是一个SDN产品,支持统一策略、服务链管理、安全策略等。原来的名字是OpenContrail,2013年正式开源,2017年加入到Linux Foundation,2018年更名为Tungsten Fabric。

在Tungsten Fabric的体系架构里,下层就是IP Fabric,由虚拟交换机对应下层每一个虚机之间的通讯,上层有一对儿TF控制器,对上层是汇合对接不同的云平台/编排系统,同时将网络信息以虚拟化的方式下发。至于裸机服务器,则通过Netconf的方式实现TOR的配置。

Tungsten Fabric是一个非常成熟的开源产品,是一个“共生”的开源——它是商业化产品开源出来的,而不是开源产品商业化,在成熟度上是经过验证的。

通过这几年版本的迭代,Tungsten Fabric已经比较成熟了,很多硬件SDN没有的功能,也能支持得很好,集成度也比较高,特别适合技术创新,拿来作为自己云平台的网络管理部分,解决云网里面“网”的逻辑,使用起来也是统一的,并且可以解除一些产品的锁定。

我们有自己的TF中文社区,希望降低大家学习网络新知的难度,了解并熟悉Tungsten Fabric这个开源SDN的产品,能够很快上手,真正运用起来,帮助到自己的企业和行业。

对于公有云的连接和管理,我的想法是这样的,还是从需求出发。因为公有云本身有自己的网络环境和地址管理,因此这种管理本身和私有云平台可能就会产生兼容性的问题,所以如果从统一管理的角度来说,统一成同一个网络并不是特别的现实,至少我目前没有合适的想法。

真是要实现可能有如下几个模式:

第一个,就是做一个打通和互联,不存在“大二层”的需求,那么就是老样子,IPSec 网关和路由打通,这是现在比较普遍的方式。当然,你买了公有云的专线,另当别论。

第二个,在网络中先把地址规划做好,比如VPC的网络地址分配不冲突,不可能统一分配,但是至少做好管理,然后安装一个支持大二层比如EVPN功能的GW,假定是Juniper的VMX,那么这时可以实现VMX和Contrail(同Tungsten Fabric)的EVPN互通,用EVPN对的方式打通所谓的“二层”,某种程度上来说,相当于两个二层的缝合,而这时公有云的虚机的网关不再是VPC原有的网关,而是我们做的VMX,这个也是可能实现的。

第三个,还有一个是CEM里面的multicloud gw,这个只能在K8s平台下是OK的。

Multicloud gateway (MC-GW) node interconnects different Virtual Private Cloud (VPC)/Virtual Networks (VNets) in cloud. Additionally, MC-GW extends on-premise resources to cloud.

链接如下:

https://www.juniper.net/documentation/en_US/contrail19/topics/task/installation/deploy-multicloud-contrail-command.html


Q: Tungsten Fabric与NSX到底有啥区别?

A: 在技术实现的理念上完全一样,都是使用server overlay的方式。在实现的方式上,除了一个花钱一个不花钱以外,NSX实现一定是在VMware平台,Tungsten Fabric实现是多平台的。在和VMware的互通上方式,需要有技术选择,第一个是全网使用VMware只做IP Fabric,但是可以和vCenter建立关系;第二个是将vRouter安装到每一个虚拟机下面做网关。实际上,对于VMware客户其实已经是选择了私有化方案,不会选择其他平台。不同的实现场景,解决不同的问题。

Q: 大量BGP路由收敛的话,收敛时间是否会成为一个问题?

A: 从实践和测试的角度来说,为什么会选择BGP或者说EVPN,就是因为它整个的效率是一个平衡的效率,这是协议的设计上决定的,不管是量大还是量小,选择的都是比较成熟的协议。BGP是行业里收敛和变化最稳定的一个,和传统的IGP路由协议不一样(附注:旨在说明不存在路由算法),跟OpenFlow方式也不一样,它是一个比较朴素的分布式部署的方式,通过RR的方式,每个vRouter看到的邻居其实是两个RR,,采用按需更新的方式,在这种情况下,收敛性方面不是问题。

Q: vRouter万一挂了怎么办?

A: 是否足够稳定,要看运行环境是什么样的。目前的实践来看,vRouter挂的情况比较少。问题在于,当做到生产环境的时候,需要考虑整个服务器的硬件匹配,操作系统的匹配,包括KVM版本、kernel版本、K8s版本等的匹配。同时,TF本身也会有vRouter的检测,会去看它的状态,在troubleshooting的时候,也会做相应检查,另外我们可以通过控制器对它进行重启和重置。在这一点上,我对Juniper自身路由协议和路由处理方面的代码还是有信心的。


IT快跑,网工如何转型?

从多云的角度来说,还是面临着各种情况,做云的过程中难免面临技术争议,包括技术选择的问题和困境。企业IT有两种模式或形态——稳态和敏态,本身是由由稳态走向敏态,不断更新,不断变化的。

用户为什么选择云,其实也是市场的原因,市场对他们的要求提高了,比如制造业、餐饮、服装等行业,他们在进行业务变革的时候,速度会很快,倒逼着IT变化也很快。

这里就有一个值得大家思考的问题,我们网络从业者、网工,在这个不断变化的时代,应该怎么做?

两年前,我就听到说,网工已经成立了落后生产力的代表。因为我们总是在满足业务的需求,而不是积极的响应,很有可能业务会因为网络的原因不能实现敏捷,需要我们反思的是,负责服务器的,负责数据库的,负责网络的,当我们真正去做IT的时候,最好的方式是大家坐下来,确定统一的业务目标,统一的技术方向,这样才能把IT做得更稳妥,任何一个冒尖或者落后,都会带来问题。

未来,我们要更多了解业务,了解云是怎么设计的,让网络发挥最大的能力。我们要去看企业进行数据中心管理时的样子,要了解他们选择了什么云平台,为什么选择这个平台,还要看在做什么业务,为什么做这个业务,以及数据库、应用结构等。一旦有了云的设计,业务和IT的挂钩,就会越来越紧密,应用研发和网络的关系也越来越紧密。

云肯定是未来方向,但在选择上有不少困境。Tungsten Fabric是可以帮助企业实现技术把控的一种很好的手段,在熟悉了这个工具之后,在网络的自主可控上,可以进行各种扩展,使用起来更加方便。

疫情期间,这段时间每个人都在思考,IT的发展怎么样?我相信,没有冬天不会过去,没有春天不会到来。


Q: 传统网工该如何转型?要学习的好多好复杂,不知如何学起?

A: 网工是不是被边缘化了?传统知识不能满足现在的需求,这是必然的。IT行业是不断变化的行业,门槛不断降低,网络设备价格不断降低,每个10G端口的成本不断下降,但并没有降低人的要求和素质。网络是IT必不可少的部分,如果不了解生成树、VLAN、基础知识,没办法更深的内容,EVPN,VXLAN,Segment Routing,都是要学习的内容。技术基础的持续学习是第一位的。

第二,与其说转型,不如叫升级,增加一些看问题的视角。云对网络的变化有很多要求,但不同企业和行业对云的认识差异还非常大,这里有很多内容网工可以投入进去,一些技术因为时间精力背景的原因不能深入,但至少要有全局的认识。

第三,提高自己自动化的水平,如果仅仅做CLI的,只是一个工人,要让自己通过一些手段方法,把数据可视化,把经验的东西程式化,转化成工具。看Google或Facebook,他们的网工,每个人手里都有几把武器,检测网络的时候,人家编个脚本就上去了,但这种自动化编程,不是搞数据库,就是先学现卖,拿来主义。如果你想有一些进步的话,看看其他老网工在做些什么。

第四,网络安全是未来的一个趋势,针对安全的服务大有可为。

大家可能知道,疫情期间能看到很多行业受到影响,但是我发现疫情期间打印机卖的特别火,因为很多“神兽”在家,有打印的需求,因此我猜再开学的时候,学校周边的打印店就不好开了。所以说,真正“搞垮”你的不一定是同行。同样道理,我们为什么要去学自动化?传统企业服务可能永远用不到这个知识,就是要应对不确定性的变化,做好充分的准备,不拘泥一个厂商,而是根据看待行业本身的需要去寻找自身的优势和劣势,迎接变革的到来。

彩蛋

Tungsten Fabric最新版本v2003版,将于近期发布!敬请关注TF中文社区,并加入我们的社群,与行业大牛一起讨论学习,未来社区还将探索更多在线活动玩法,敬请期待。


原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 彩蛋
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档