瞻博网络杰出工程师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层和开发阶段的应用层才可以进行通信。
同样地，如果你的应用是一个地理分布式的应用，你可以《Tungsten Fabric架构和最新技术进展》（演讲人：SK）通过定义策略，让在地理区域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上面。大家也可以打开下面蓝色的链接，自己去进行类似的实验。
谢谢各位!
