Tungsten Fabric架构和最新技术进展丨TF成立大会演讲实录



  • 本文整理自瞻博网络杰出工程师Sukhdev Kapur在“TF中文社区成立暨第一次全员大会”上的演讲,增加了对于TF功能的描述,pdf点击此处下载。更多会议资料,请在公众号(搜索“TF中文社区”)后台回复“成立大会”获取。

    YYZB1152-128.jpg

    瞻博网络杰出工程师Sukhdev Kapur

    大家好,我叫SukhdevKapur,来自Tungsten Fabric(以下简称TF)社区技术指导委员会,下面我为大家介绍一下TF的架构和技术的现状,以及最新的进展。

    TF架构与部署模式

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_02.jpg

    我们可以看一下这张TF的宏观架构图,整体图描述是设备的物理连接,而右上角有虚机之间的逻辑网络,TF基本的工作原理和机制,就是你创建VM或者POD,然后(通过SDN)把它们放到这些逻辑网络里。

    在这些逻辑网络中,你能够以根据自己业务需要,放置任何虚机、PODS、或者裸服务器,它们的物理位置在哪里没有关系,它们可能会在一个集群里,也可能在一个机架中,这都没有关系。

    大家再看一下它下面底层的部分,TF会利用虚拟的路由器(计算节点上),来负责是这些虚拟的工作负载的转发,而左边是一个物理网络的连接,例如一个裸机的物理网络,一旦你做好了网络定义,它可能会和实际网络连接,也可能会和右边逻辑网络里头虚拟网络的虚机来进行连接

    第四部分(上半部分)是CONTRAILController(SDN控制器),是做配置控制分析和CSN的。

    第五部分是网关的功能,它可能是一个物理网关,或者是一个虚拟的网关,当数据中心的虚机需要对外互联的时候,通过IP的组网——也就是MPLS这种协议——进出骨干网络。

    所有这一切,都是通过一个ORCHESTRATOR编排器去管理,它可能是OpenStack、K8s或OpenShift,通过API来调度TF来工作。

    TF中Vrouter的体系架构概述

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_03.jpg

    这张图说的是TF的路由vRouter的架构,左上角是vRouter的Agent,主要是控制的部分,在这里它会通过路由的学习,VRFs的定义,以及策略的定义,如果虚拟路由器要进行策略的执行,必须是由Agent去控制的:它来决定网络的流量是允许通过,还是拒绝,如果允许的话,应该把它转发到哪个位置。

    你可以看到,vRouter有一个转发的路径,学习的路径进行封装,然后做二层或者三层的数据流量的转发。

    vRouter的部署模式

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_04.jpg

    这是TF虚拟路由器的四种部署模式,左上角是默认的模式,在内核的vRouter部署。

    右上角呢?如果你在一个高吞吐、高流量的状态下,网络支持DPPK的话,TF可以有的DPDKvRouter的部署。

    左下角其实是一种混合部署的模式,如果你有好几个VNF这种虚拟网络的功能,可以用到SR-IOV的话,可以采用SR-IOV和内核的vRouter共存的混合模式。

    第四种就是基于SmartNIC的vRouter,也就是说,这些VM可以充分地利用到所有处理器的能力。

    TF与Kubernetes的集成

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_05.jpg

    大家再来看一下TF和Kubernetes(以下简称K8s)的集成,首先,TF的CONTRAIL Controller会和K8s通过API进行通讯,那么,某一个指定的位置,它是如何得到IP地址以及策略的呢?首先,K8s会和TF的Scheduler也就是调度管理程序进行通讯,再通过调度管理程序和CNI Plugin插件进行联系,在左上角就表示vRouter是如何获得在K8s这边的策略,去进行IPAM的读取和执行的,简单一点说,K8s的管理器会和TF的CONTRAIL Controller进行通讯,确定网络的策略,然后TF的Controller会把这个策略发布到vRouter。

    TF的微服务架构

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_06.jpg

    TF的技术演进,一开始主要是基于虚机部署,后来开始支持容器技术,现在已经演进到了微服务(Microservices)的架构。目前我们的TF在部署是完全采用containers的方式进行部署,大概有27-30个左右的image。

    K8s环境下的网络隔离

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_07.jpg

    K8s是一个非常扁平的网络,租户和租户之间可以进行任意的沟通,工作负载之间也是这样。

    基于这样的场景,我们就通过网络策略的执行,去实现网络中租户的隔离,也就是说,只是在指定区域内的用户之间,才可以进行沟通。

    那么在TF这一层,我们把管理又向前推进了一步,即在一个租户的空间之内,我们也可以决定哪个位置和哪个位置可以沟通,也就是哪个POD和哪个POD通讯。

    TF提供的统一策略管理功能

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_08.jpg

    下面为大家介绍一下TF的独特的策略框架。假设我们有一个应用,该应用有三层,分成三层,分别是Web层、应用层和数据库层。而这个应用的生命周期会有三个阶段,分别是开发的阶段,部署准备的阶段,和最后的生产阶段。

    不同的阶段可能部署在不同的网络环境,甚至于不同的云平台中,那么在最上面的开发阶段,不同的层之间(层也是tie的概念),会有一些安全的访问策略(图中P1的策略也),而这个策略可能在部署准备阶段也需要(图中P2的策略)在生产阶段也需要,在不使用TF的情况下,很有可能会出现重复的策略,而是用TF之后,我们可以只使用一个策略

    我们所做的就是把策略的管理进行了简化,首先就是降低了复杂性,简化管理,提高了可伸缩度。一旦定义好了策略,你就可以在各种各样的环境之下,进行规模性的、可伸缩的复用,包括公有云、私有云,以及多云的环境。

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_09.jpg

    给大家介绍一个实际的策略框架用例。

    假设我们有一个应用,我们允许它的Web层和应用层进行沟通,那么不管是在开发阶段,还是在生产阶段,我们都可以使用这样一个定义,比如在开发阶段的Web层,也可以和生产环境下的应用层进行沟通。

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_10.jpg

    但是,也许我们并不希望有这样的事情发生,我们不希望某一个开发人员能够随意修改在生产环境下的代码。这时你不用去改变策略,只需要在策略里头加上App Match Deployment的标签,它可以去规定——比如说只有在开发阶段的Web层和开发阶段的应用层才可以进行通信。

    同样地,如果你的应用是一个地理分布式的应用,你可以通过定义策略,让在地理区域A的Web层和在地理区域B的应用层之间进行通信。

    如果你不希望这种跨层、跨区域的通信产生,就在AppMatch Deployment的后头再加上End Site。所以说这个match,不光是它的部署,还有它的位置,你都要把它match一下。

    我们再加一层,你看我们第二个策略的意思,就是说只要是这个站点我们match上了,匹配上了,那么它们都可以和数据库进行访问。

    这样的一种策略在管理方面非常的有用。如果你有一个非常大型的跨地理区域分布式的金融应用,它可能使用了多个网络,网络上还有数百种的应用,这个时候你只需要一个策略,就可以对整个分布式的金融应用进行管理。

    一个界面,搞定多云部署

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_11.jpg

    同时,TF还可以实现多云部署的自动化管理。比如说我们在驻地这里自动创建了一个叫做多云的网关MC-GW,它会建立一个通道,和在云端的(比如说AWS上的)同样的部署,自动地进行安全的连接。

    这里也要看,你在云上部署的工作负载到底是什么种类的。有了这个工作负载,你可以在本地云的环境下进行管理,而TF能够给你一个多云的可视性。

    大家可以看一下,如果你自己去进行多云管理,需要通过很多的流程来实现。而TF只需要一个单一的图形用户界面,就能够轻松地进行多云管理,你需要做的,只是做几下点击的动作。

    多云环境的服务链

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_12.jpg

    下面来介绍一下TF的多云服务链。大家看到最上面有两个网络在驻地,左边的是2.2.2.4,右边的是3.3.3.5,然后有一个服务的实例,假设服务实例是POD的虚拟化服务,通过TF的服务链,可以将工作负载从左边的网络传到右边。

    同样地,如果要在不同的公有云上也去部署这样的虚拟网络,你可以通过TF,从驻地到多云建立这样一个服务链。

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_13.jpg

    我来总结一下,只需要一个SDN的控制器,就能够去管理连接——不管是金属裸机、K8s CNI、OpenStack,还是左边的各种边缘的站点——并且提供非常丰富的网络功能。

    TF与Akraino的集成

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_14.jpg

    TF在边缘计算的环境下也做出了自己的贡献,这是另外一个开源的项目,TF实现了和Akraino的集成,能够为边缘计算这样的场景提供支持,它是纯基于K8s原生基础架构的,非常适用于轻量级的,像工业自动化这种应用。基本上它部署的环境是非常小的,目标行业主要是电信运营商和企业级用户。

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_15.jpg

    这是另外一个Akraino和TF集成的用例,主要是打造电信云,目前美国电信运营商AT&T就做了这样的一个架构部署。这里主要是使用SR-IOV这种虚拟化,我们所做的就是把TF作为一个单一的SDN,它的部署模式包含了以上所有类型。

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_16.jpg

    这是第三个用例,它是一种叫做微云的软件堆栈,主要应用于移动的场景,例如手机游戏,工作负载是移动化的这种架构。

    在这里我们是怎么做的?首先,我们有一个DME(分布式的匹配引擎),它知道有多少个设备或者多少个移动用户接入进来,并根据移动用户的数量,启动微云资源管理器去做信息传递;然后微云资源管理器就会匹配到相应的资源;接下来CRM会和TF的控制器进行沟通,来进行这种资源的部署;再到下面一层,通过vRouter的转发层,和TF的控制器进行联系。

    TF与OpenStack的集成

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_17.jpg

    熟悉OpenStack的朋友都知道,它有两种部署模式,一种是单一的插件方式,另一种是基于ML2的部署。

    TF专门有一个Networking Open Contrail,可以将TF作为一个ML2的插件去启动。这样做有什么好处呢?我们可以同时去运行基于OVS、SR-IOV和vRouter的这工作。

    你可以用OpenStack来运行OVS、SR-IOV的工作负载,并且在网络层面使用我们的TF去进行管理。

    Powering Edge cloud and multi-cloud with Tungsten Fabric-Sukhdev Kapur-logo_页面_18.jpg

    接下来我们将为大家进行演示,看看如何把基于OVS的计算迁移到基于vRouter上面。大家也可以打开下面蓝色的链接,自己去进行类似的实验。

    谢谢各位!


Log in to reply