​Tungsten Fabric入门宝典丨关于安装的那些事(上)



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

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

    在“启动并运行”的部分,描述了1个控制器和1个vRouter的设置,没有涵盖HA的情况(也没有overlay流量的情况)。下面来描述更现实的情况,每个编排器包含3个控制器和2个计算节点(可能还包含多NIC)。

    在本章中,我将使用opencontrailnightly:latest repo,因为5.0.1版本中有几个功能还不可用,但是请注意,在某些情况下此repo可能会有点不稳定。

    Tungsten Fabric 组件的HA行为

    如果计划设置用于关键流量,则始终需要使用HA。

    Tungsten Fabric拥有不错的HA实施,已经以下的文档中有相关信息。

    这里我想多说的一件事,cassandra的keyspace在configdb和analyticsdb之间具有不同的replication-factor。

    由于configdb的数据已复制到所有的cassandras,因此即使某些节点的磁盘崩溃并需要抹掉,也不太可能丢失数据。另一方面,由于analyticsdb的replication-factor始终设置为2,因此如果两个节点同时丢失数据,那么数据就可能会丢失。

    多NIC安装

    在安装Tungsten Fabric时,许多情况下都需要进行多NIC安装,例如用于管理平面和控制/数据平面的,都是单独的NIC。

    • 绑定(bonding)不在此讨论中,因为bond0可以直接由VROUTER_GATEWAY参数指定

    我需要明确一下在此设置中vRouter的有趣的行为。

    对于controller/analytics来说,与典型的Linux安装并没有太大区别,这是因为Linux可以与多个NIC和其自己的路由表(包括使用静态路由)很好地协同工作。

    另一方面,在vRouter节点中您需要注意的是,vRouter在发送报文时不会使用Linux路由表,而是始终将报文发送到网关IP。

    • 这可以使用concert-vrouter-agent.conf中的网关参数和vrouter-agent容器的环境变量中的VROUTER_GATEWAY进行设置

    因此,在设置多NIC安装时,如果需要指定VROUTER_GATEWAY,那么您需要小心一点。

    如果没有指明,并且Internet访问的路由(0.0.0.0/0)是由管理NIC而不是数据平面NIC所覆盖,那么vrouter-agent容器将选择保存该节点默认路由的NIC,尽管那不会是正确的NIC。

    在这种情况下,您需要显式指定VROUTER_GATEWAY参数。

    由于这些行为的存在,当您要将报文从虚拟机或容器发送到NIC(除了vRouter使用的NIC之外的其它NIC)时,仍然需要谨慎一些,因为它同样不会检查Linux路由表,并且它始终使用与其它vRouter通信相同的NIC。

    • 据我所知,来自本地链接服务或无网关的报文也显示出类似的行为

    在这种情况下,您可能需要使用简单网关(simple-gateway)或SR-IOV。

    调整集群大小

    对于Tungsten Fabric集群的一般规格(sizing),您可以使用下面的表。

    如果集群规模很大,则需要大量资源来保障控制平面的稳定。

    请注意,从5.1版本开始,analytics数据库(以及analytics的某些组件)成为了可选项。因此,如果您只想使用Tungsten Fabric中的控制平面,我建议使用5.1版本。

    尽管没有一个方便的答案,但集群的大小也是很重要的,因为它取决于很多因素。

    由于可以随时从云中获取大量资源,因此最好的选择应该是按照实际需求的大小和流量来模拟集群,并查看其是否正常运行,以及瓶颈是什么。

    Tungsten Fabric在应对海量规模方面拥有一些很好的功能,例如,基于集群之间的MP-BGP的多集群设置,以及基于3层虚拟网络的BUM丢弃功能,这大概就是其具备可扩展性和稳定性虚拟网络的关键。

    为了说明控件的横向扩展行为,我在AWS中创建了一个包含980个vRouter和15个控件的集群。

    • 所有控制节点均具有4个vCPU和16GB内存
      1229b35b-0782-47d2-b1c2-8da9ddd731f3-image.png

    当控制节点的数量为15时,XMPP的连接数最多只有113,因此CPU使用率不是很高(最高只有5.4%)。

    650b1639-4826-4bc8-8c11-a86ebe9da2f0-image.png

    但是,当其中12个控制节点停止工作时,剩余的每个控制节点的XMPP连接数将高达708,因此CPU使用率变得很高(21.6%)。

    因此,如果您需要部署大量的节点,那么可能需要仔细规划控制节点的数量。
    d9ba545f-770c-4a6a-bf75-949bcf3ba2fc-image.png

    kubeadm

    在撰写本文档时,ansible-deployer尚未支持K8s master HA。

    由于kubeadm已经支持K8s master HA,因此我将介绍集成基于kubeadm的k8s安装和基于YAML的Tungsten Fabric安装的方法。

    与其它CNI一样,也可以通过“kubectl apply”命令直接安装Tungsten Fabric。但要实现此目的,需要手动配置一些参数,例如控制器节点的IP地址。

    对于此示例的设置,我使用了5个EC2实例(AMI也一样,ami-3185744e),每个实例具有2个vCPU、8 GB内存、20 GB磁盘空间。VPC的CIDR为172.31.0.0/16。

    639e17a0-e709-4650-a73b-5beba9446df2-image.png

    我将附上一些原始和修改的yaml文件以供进一步参考。

    然后,您终于有了(多数情况下)已经启动了的具有Tungsten Fabric CNI的kubernetes HA环境。

    注意:Coredns在此输出中未处于活动状态,我将在本节稍后的部分对此进行修复。

    e2d673c8-919f-4c3f-88fd-b393c6121af6-image.png
    在创建cirros部署后,就像“启动并运行”部分所描述的一样,两个vRouter节点之间已经可以ping通了。

    • 输出是相同的,但现在在两个vRouter之间使用的是MPLS封装!
      ab64cc8a-02cf-408a-9104-2758ed05c616-image.png

    注意:要使coredns处于活动状态,需要进行两项更改。

    56a27b80-f4be-4dbe-b296-eb2b8d3c52be-image.png

    终于,coredns也处于活动状态,集群已完全启动!

    be9ff17e-ff63-427b-b111-d403437735e7-image.png

    由于MP-BGP支持两个集群之间的缝合(stitching),因此这些集群很容易扩展到多集群环境。

    • 每个集群的前缀路由都将泄漏到其它集群

    我将在附录部分描述此设置的详细信息。

    (编者按:下一篇文章,我们将介绍关于OpenStack和vCenter的HA安装,以及在新的安装中选择什么标签的问题。)

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

    首次启动和运行指南
    TF组件的七种“武器”
    编排器集成

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

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


Log in to reply