网络通信 频道

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

  本文整理自瞻博网络杰出工程师Sukhdev Kapur在“TF中文社区成立暨第一次全员大会”上的演讲,增加了对于TF功能的描述。

  瞻博网络杰出工程师Sukhdev Kapur

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

  TF架构与部署模式

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

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

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

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

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

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

  TF中Vrouter的体系架构概述

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

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

  vRouter的部署模式

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

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

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

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

  TF与Kubernetes的集成

  大家再来看一下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的微服务架构

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

  K8s环境下的网络隔离

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  一个界面,搞定多云部署

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

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

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

  多云环境的服务链

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

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

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

  TF与Akraino的集成

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

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

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

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

  TF与OpenStack的集成

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

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

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

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

  谢谢各位!

0
相关文章