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

2020-06-08 14:52:06 浏览数 (1)

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

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

  1. 在虚拟机或容器启动时分配端口。
  2. 将其“插入（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），将要完成两件事：

  1. 为VM连接的dv-portgroup端口设置一个vlan-id。
  2. 在具有接口（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，就变得容易得多。

·END·

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

1. 首次启动和运行指南

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

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

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

0 人点赞