Tungsten Fabric入门宝典系列文章 ，来自技术大牛倾囊相授的实践经验，由TF中文社区为您编译呈现，旨在帮助新手深入理解TF的运行、安装、集成、调试等全流程。如果您有相关经验或疑问，欢迎与我们互动，并与社区极客们进一步交流。更多TF技术文章，请点击公号底部按钮＞学习＞文章合集。

作者：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 架构解析 系列文章——

ITPub博客

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

最新文章