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



  • 作者:Tatsuya Naganawa 译者:TF编译组

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

    e9bb06b6-25e0-49f1-b722-65800bee2bce-image.png
    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的插件。

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

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

    Kubernetes

    当与Kubernetes一起使用时,其行为类似于OpenStack的情况,尽管它使用nova-vif-driver的CNI,以及使用neutron-api的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,就变得容易得多。

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

    1. 首次启动和运行指南

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

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

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


Log in to reply