Tungsten Fabric入门宝典丨编排器集成

发布时间：2020-08-11 21:30:54 作者：TF中文社区
来源：ITPUB博客阅读：186

作者：Tatsuya Naganawa 译者：TF编译组

Tungsten Fabric已经实现了多个编排器的集成。

在内部，Tungsten Fabric的编排器集成组件基本上对每个编排器都执行相同的操作，包括：

在虚拟机或容器启动时分配端口。
将其“插入（plug）”虚拟机或容器。

接下来我描述一下每个编排器要做的事。

OpenStack

当与OpenStack一起使用时，neutron-plugin将成为OpenStack和Tungsten Fabric Controller之间的主要接口。

Neutron-plugin将直接加载到neutron-api进程中（某些模块需要在neutron.conf中指定），并且该逻辑将执行与Neutron的request/response相关的操作，例如network-list或port-create等等。

该模块的一个特性是它不会使用在MySQL中创建（在典型的OpenStack设置中）的Neutron数据库。

由于它直接使用Tungsten Fabric db，因此某些功能（例如到虚拟机的桥接分配）将难以实现。

据我所知，由于nova仍使用相同的vif分配逻辑，模拟Neutron响应来分配可用于Neutron的特定vif-type并非是不可能的，尽管不是所有组合全都经过测试。
SR-IOV是一个例外，因为它的仿真得到很好的支持和测试。
https://github.com/Juniper/contrail-controller/wiki/SRIOV

当一个端口被分配了vrouter的vif-type时，将通过neutron-plugin由“create port”API自动完成该操作，它将为vRouter使用nova-vif-driver来将执行一些任务，而不仅仅是在调用时创建一个tap设备，例如通过vrouter-port-control脚本在vRouter上创建vif等。（参见https://github.com/Juniper/contrail -nova-vif-driver）

在大多数情况下，你无需深入研究这些行为的细节。尽管在某些情况下（例如实时迁移在某处停止），你可能需要注意vif的状态。

注意：Tungsten Fabric也有基于ml2的插件。

https://www.youtube.com/watch?v=4MkkMRR9U2s
https://opendev.org/x/networking-opencontrail

因此，如果用户已经在MySQL中使用ml2，那么可以首先将vRouter添加为ml2的network-type之一，在特定的虚拟网络中使用它，然后通过detach和attach接口，从其它ml2插件迁移到vRouter。（如果所有迁移完成，则可以选择替换Neutron核心插件。）

此外，还添加了一些安装的详细信息。

https://github.com/tnaganawa/tungstenfabric-docs/blob/master/TungstenFabricKnowledgeBase.md#vrouter-ml2-plugin

Kubernetes

当与Kubernetes一起使用时，其行为类似于OpenStack的情况，尽管它使用nova-vif-driver的CNI，以及使用neutron-api的kube-manager。

https://github.com/Juniper/contrail-controller/tree/master/src/container/cni

https://github.com/Juniper/contrail-controller/tree/master/src/container/kube-manager

在创建容器时，kube-manager将在Tungsten Fabric控制器中创建一个端口，而cni会将端口分配给该容器。

vCenter

由于无法将模块直接安装在ESXi上，因此vCenter与Tungsten Fabric的集成和kvm采取的方法有所不同。

首先，要在ESXi之间实现overlay可用，需要在每个ESXi上创建一个vRouter VM（内部是一个简单的CentOS vm）。

在ESXi上创建虚拟机时，将会附加到由vcenter-plugin（参见 https://github.com/Juniper/contrail-vcenter-plugin ）创建的dv-portgroup上。当在“vCenter”租户中创建虚拟网络时，通过ESXi的ip/user/pass安装在每个vRouter VM上的vcenter-manager（参见 https://github.com/Juniper/contrail-vcenter-manager ），将要完成两件事：

为VM连接的dv-portgroup端口设置一个vlan-id。
在具有接口（vlan）的vRouter VM上创建一个vif，该接口具有与该dv-portgroup端口以及该虚拟网络的VRF相同的vlan-id。

这样，当虚拟机发送流量时，先进入dvswitch并进行标记，然后到达vRouter VM，接着取消标记，再进入该虚拟机所属的特定的VRF。

由于来自每个虚拟机的流量将使用不同的vlan-id进行标记，因此微分段（micro-segmentation）也得以实现。

在流量进入vRouter VM后，其行为就与kvm的情况一样了。

请注意，只有当虚拟机附加到Tungsten Fabric控制器创建的dv-portgroups时，这些行为才会被触发，因此虚拟机的接口仍可以分配给某些vSS或vDS，以使用underlay访问。

甚至可以将vCenter和Tungsten Fabric控制器安装到带有vRouter的同一个ESXi上（如果已分配给“VM Network”，而不是由Tungsten Fabric控制器创建的dv-portgroup）。

由于vRouter的行为与其它情况相同，因此在vCenter和OpenStack之间共享虚拟网络，或它们之间的路由泄漏（route leak）也变得很容易获得。因此，借助Tungsten Fabric，通过共享网络和网络服务（例如fw、lb等），同时使用两个VMI，就变得容易得多。

Tungsten Fabric入门宝典系列文章——

1. 首次启动和运行指南

2. TF组件的七种“武器”

Tungsten Fabric 架构解析 系列文章——

第一篇： TF主要特点和用例
第二篇： TF怎么运作
第三篇：详解vRouter体系结构
第四篇： TF的服务链
第五篇： vRouter的部署选项
第六篇： TF如何收集、分析、部署？
第七篇： TF如何编排
第八篇： TF支持API一览
第九篇： TF如何连接到物理网络
第十篇： TF基于应用程序的安全策略

Tungsten Fabric入门宝典丨编排器集成

Tungsten Fabric入门宝典丨编排器集成

相关阅读