Tungsten Fabric安装的示例分析

本文主要介绍钨织物安装的实例分析，非常详细，具有一定的参考价值。感兴趣的朋友一定要看完！

00-1010如果计划是为关键流量设置的，您总是需要使用高可用性。

钨织物有很好的HA实现，以下文件中有相关信息。

http://www . open contril . org/open contril-architecture-documentation/# section 2 _ 7

这里我想说的是，cassandra的keyspace在configdb和analyticsdb之间有不同的复制因子。

configdb:

https://github.com/Juniper/contril-controller/blob/master/src/config/common/VNC _ Cassandra . py # L609

分析：

https://github.com/Juniper/contil-analytics/blob/master/contil-collector/db _ handler . cc # L524

因为configdb的数据已经被复制到所有的cassandras，所以即使某些节点的磁盘崩溃，需要被擦除，也不太可能丢失数据。另一方面，由于analyticsdb的复制因子始终设置为2，如果两个节点同时丢失数据，数据可能会丢失。

Tungsten Fabric 组件的HA行为

安装钨结构时，在许多情况下需要安装多网卡，例如，管理平面和控制/数据平面都是独立的网卡。

焊接不在此讨论范围内，因为焊接0可以由VROUTER_GATEWAY参数直接指定。

我需要澄清vRouter在这种情况下的有趣行为。

对于控制器/分析，它与典型的Linux安装没有太大区别，因为Linux可以很好地与多个网卡及其自己的路由表(包括静态路由)一起工作。

另一方面，在vRouter节点中，您应该注意到vRouter在发送消息时总是将消息发送到网关IP，而不是使用Linux路由表。

这可以通过在vrouter-agent容器的环境变量中使用concert-vrouter-agent.conf和VROUTER_gateway中的GATEWAY参数来设置。

因此，在设置多网卡安装时，如果需要指定VROUTER_GATEWAY，则需要小心。

如果未指定，并且互联网访问的路由(0.0.0.0/0)由管理网卡而不是数据平面网卡覆盖，则vrouter-agent容器将选择存储此节点默认路由的网卡，尽管它不是正确的网卡。

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

由于这些行为，您在将消息从虚拟机或容器发送到网卡(而不是vRouter使用的网卡)时仍然需要小心，因为它也不检查Linux路由表，并且它总是使用与其他vRouter通信的相同网卡。

据我所知，来自本地链接服务或没有网关的消息也显示出类似的行为。

在这种情况下，您可能需要使用简单网关或SR-IOV。

https://github.com/Juniper/contil-controller/wiki/Simple-Gateway

00-1010对于钨织物簇的一般尺寸，可以使用下表。

https://github.com/hartmutsroeder/contirandhorsp 10 # 21控制器节点和虚拟机的大小

如果集群规模较大，则需要大量资源来保证控制平面的稳定性。

请注意，自5.1版以来，分析数据库(以及分析的某些组件)已成为可选的。因此，如果您只想在钨织物中使用控制平面

，我建议使用5.1版本。

• https://github.com/Juniper/contrail-analytics/blob/master/specs/analytics_optional_components.md

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

• 我曾经尝试用一个K8s集群（
  https://kubernetes.io/docs/setup/cluster-large/）部署了近5,000个节点。在它与一个具有64个vCPU和58GB内存的控制器节点配合使用时效果很不错，尽管当时我并没有创建太多的端口、策略和逻辑路由器等。

• 这个Wiki也描述了一些有关海量规模集群的真实经验：
  https://wiki.tungsten.io/display/TUN/KubeCon+NA+in+Seattle+2018

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

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

• https://bugs.launchpad.net/juniperopenstack/+bug/1471637

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

• 所有控制节点均具有4个vCPU和16GB内存
  

当控制节点的数量为15时，XMPP的连接数最多只有113，因此CPU使用率不是很高（最高只有5.4％）。

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

因此，如果您需要部署大量的节点，那么可能需要仔细规划控制节点的数量。

kubeadm

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

• https://bugs.launchpad.net/juniperopenstack/+bug/1761137

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

• https://kubernetes.io/docs/setup/independent/high-availability/

• https://github.com/Juniper/contrail-ansible-deployer/wiki/Provision-Contrail-Kubernetes-Cluster-in-Non-nested-Mode

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

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

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

• https://github.com/tnaganawa/tungstenfabric-docs/blob/master/cni-tungsten-fabric.yaml.orig

• https://github.com/tnaganawa/tungstenfabric-docs/blob/master/cni-tungsten-fabric.yaml

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

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

在创建cirros部署后，就像“启动并运行”部分所描述的一样，两个vRouter节点之间已经可以ping通了。

• 输出是相同的，但现在在两个vRouter之间使用的是MPLS封装！

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

终于，coredns也处于活动状态，集群已完全启动！

以上是“Tungsten Fabric安装的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注行业资讯频道！