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



  • 一场疫情,改变了所有人的生产与生活,在时代的不确定性面前,我们应该怎么做?
    
    昨晚,第一场【TF Live】如约而至,活动持续了两个多小时,在线人数将近1000人,互动讨论热闹十足。TF中文社区技术代表、瞻博网络全国合作伙伴技术经理张建勋(江湖人称KK),与大家聊了多云网络演变、SDN开放、Tungsten Fabric创新和网工转型等话题,关键词就是一个“变”字,在当下的特殊时期,尤其值得每个人认真思考。
    
    直播活动由SDNLAB和TF中文社区联合举办。
    

    点击下载文档 https://tungstenfabric.org.cn/assets/uploads/files/tf中文社区演讲-sdnlabv1.pdf 查看本文所有相关资料。

    直播活动视频回放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转型的很好方式。

    [QA环节]

    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

    [QA环节]

    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的发展怎么样?我相信,没有冬天不会过去,没有春天不会到来。

    [QA环节]

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

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

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

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

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

    彩蛋

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


Log in to reply