在“启动并运行”的部分，描述了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:
https://github.com/Juniper/contrail-controller/blob/master/src/config/common/vnc_cassandra.py#L609 -
analytics:
https://github.com/Juniper/contrail-analytics/blob/master/contrail-collector/db_handler.cc#L524
由于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版本。
尽管没有一个方便的答案，但集群的大小也是很重要的，因为它取决于很多因素。
-
我曾经尝试用一个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丢弃功能，这大概就是其具备可扩展性和稳定性虚拟网络的关键。
为了说明控件的横向扩展行为，我在AWS中创建了一个包含980个vRouter和15个控件的集群。
当控制节点的数量为15时，XMPP的连接数最多只有113，因此CPU使用率不是很高（最高只有5.4％）。
但是，当其中12个控制节点停止工作时，剩余的每个控制节点的XMPP连接数将高达708，因此CPU使用率变得很高（21.6％）。
因此，如果您需要部署大量的节点，那么可能需要仔细规划控制节点的数量。
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。
我将附上一些原始和修改的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也处于活动状态，集群已完全启动！
由于MP-BGP支持两个集群之间的缝合（stitching），因此这些集群很容易扩展到多集群环境。
- 每个集群的前缀路由都将泄漏到其它集群
我将在附录部分描述此设置的详细信息。
（编者按：下一篇文章，我们将介绍关于OpenStack和vCenter的HA安装，以及在新的安装中选择什么标签的问题。）
Tungsten Fabric入门宝典系列文章——
Tungsten Fabric 架构解析系列文章——
第一篇：
TF主要特点和用例
第二篇：
TF怎么运作
第三篇：
详解vRouter体系结构
第四篇：
TF的服务链
第五篇：
vRouter的部署选项
第六篇：
TF如何收集、分析、部署？
第七篇：
TF如何编排
第八篇：
TF支持API一览
第九篇：
TF如何连接到物理网络？
第十篇：
TF基于应用程序的安全策略
