多集群
由于在内部使用MPLS-VPN，因此Tungsten Fabric中的virtual-network可以扩展到其它Tungsten Fabric集群。
·这可能令人有点惊讶，但据我所知，Neutron ML2插件或其它某些CNI不支持此设置
也就是说，由于它们具有不同的数据库，因此需要在它们之间标记共享资源。
为此，我将描述几个bgp参数的用法。
路由（Routing）
由于Tungsten Fabric使用L3VPN进行VRF间的路由，因此，如果在VRF之间正确设置了route-target，则它可以对报文进行路由。
·由于不能在多个集群之间使用network-policy / logical-router，因此需要在每个virtual-network上直接配置route-target。
注意：如果指定了仅做l3转发，即使在内部VRF的转发中，也会使用L3VPN，因此在该设置中将不使用桥接（bridging）。
安全组（security-group）
Tungsten Fabric还具有一些扩展的属性来传达安全组ID的内容。
·https://github.com/Juniper/contrail-controller/wiki/BGP-Extended-Communities
由于此ID也可以手动配置，因此你可以为每个集群的安全组设置相同的ID，从而允许来自该前缀的流量。
注意：据我所知，无法从R5.1分支中的Tungsten Fabric Webui手动配置标签的ID，因此无法在集群之间使用fw-policy。此行为将来可能会更改。
DNS
在处理多个集群时，DNS是一个很重要的主题。
由于Tungsten Fabric具有类似于OpenStack的默认设置的vDNS实现，因此你可以解析集群中的vmname，并使这些名称可以在外部可用。
·https://github.com/Juniper/contrail-controller/wiki/DNS-and-IPAM
·Controller节点有一个contrail-named进程，用于响应外部DNS查询
·要启用此功能，需要从Tungsten Fabric Webui中选择Configure > DNS > DNS Server > (create) > External Access
因此，至少当使用OpenStack（或vCenter）作为编排器，并且不同的集群具有不同的域名时，它可以直接解析其它集群的名称。
·上游DNS转发器需要能够解析所有名称
在使用Kubernetes时，Tungsten Fabric将coredns用作名称解析的来源，而不是在其自己的vDNS。这些IP和域名可以在kubeadm设置中修改。
代码语言：javascript复制cluster0:
kubeadm init --pod-network-cidr=10.32.0.0/24 --service-cidr=10.96.0.0/24
cluster1:
kubeadm init --pod-network-cidr=10.32.1.0/24 --service-cidr=10.96.1.0/24 --service-dns-domain=cluster1.local
cluster1:
# cat /etc/sysconfig/kubelet
-KUBELET_EXTRA_ARGS=
KUBELET_EXTRA_ARGS="--cluster-dns=10.96.1.10"
# systemctl restart kubelet注意：在配置完成后，Tungsten Fabric设置也需要更改（在configmap env中进行设置）
代码语言：javascript复制cluster0:
KUBERNETES_POD_SUBNETS: 10.32.0.0/24
KUBERNETES_IP_FABRIC_SUBNETS: 10.64.0.0/24
KUBERNETES_SERVICE_SUBNETS: 10.96.0.0/24
cluster1:
KUBERNETES_POD_SUBNETS: 10.32.1.0/24
KUBERNETES_IP_FABRIC_SUBNETS: 10.64.1.0/24
KUBERNETES_SERVICE_SUBNETS: 10.96.1.0/24设置好coredns后，它就可以解析其它集群的名称了（coredns IP需要泄漏到各自的VRF，因为这些IP必须是可访问的）
代码语言：javascript复制kubectl edit -n kube-system configmap coredns
cluster0:
### add these lines to resolve cluster1 names
cluster1.local:53 {
errors
cache 30
forward . 10.96.1.10
}
cluster1:
### add these lines to resolve cluster0 names
cluster.local:53 {
errors
cache 30
forward . 10.96.0.10
}因此，即使你有几个单独的Tungsten Fabric集群，在它们之间缝合virtual-network也不太困难。
这样做的原因之一，是要节点数量超过了编排器当前支持的数量，但即使像Kubernetes、OpenStack、vCenter这样的编排器已经能支持大量的虚拟机管理程序。
多数据中心（Multi-DC）
如果流量是跨多个数据中心的，则需要在计划Tungsten Fabric安装时保持格外小心。
有两个选项：1.单集群；2.多集群。
单集群选项更简单而且容易管理——即便数据中心之间的RTT可能是一个问题，这是因为XMPP、RabbitMQ、Cassandra等多种流量都将通过controller（当前并不支持多数据中心的本地支持）
多集群方法将给操作带来更多的复杂性，因为集群都有各自不同的数据库，因此你需要手动设置一些参数，例如route-target或security-group id。
此外，在它们之间实现vMotion也将更加困难。
·即便使用跨vCenter vMotion功能，由于新的vCenter和新的Tungsten Fabric集群将创建一个新的端口，因此它也将使用不同于原始端口的固定IP。
·Nova目前不支持跨OpenStack实时迁移，因此如果使用OpenStack，则无法在它们之间进行实时迁移
由于在数据中心之间vCenter需要150ms的RTT（我找不到KVM的相似值），因此尽管必须针对每种特定情况进行仔细规划，仍然有一个经验法则：单集群 < 150 msec RTT < 多集群，。
·https://kb.vmware.com/s/article/2106949
当计划安装单集群并且数据中心的数量为两个时，还需要注意一件事。
由于Tungsten Fabric中的Zookeeper / Cassandra当前使用Quorum一致性等级，因此当主站点关闭时，第二个站点将无法继续工作（Read和Write访问权限均不可用）。
·https://github.com/Juniper/contrail-controller/blob/master/src/config/common/vnc_cassandra.py#L659 (使用config-api, schema-transformer, svc-monitor, device-manager)
·https://github.com/Juniper/contrail-common/blob/master/config-client-mgr/config_cassandra_client.cc#L458 (使用control, dns)
解决此问题的一种可能选项是，将一致性级别更改为ONE / TWO / THREE，或者LOCAL_ONE / LOCAL_QUORUM，尽管它需要重写源代码。
由于Zookeeper没有这样的knob，所以我知道的唯一方法，是在主站点关闭后更新weight。
·https://stackoverflow.com/questions/32189618/hierarchical-quorums-in-zookeeper
·即使Zookeeper暂时无法使用，大多数组件仍继续工作，尽管它用于HA的组件停止工作了（schema-transformer, svc-monitor, kube-manager, vcenter-plugin, ...）。
当数据中心的数量超过两个时，这将不再是一个问题。
---
Tungsten Fabric入门宝典系列文章——
- 首次启动和运行指南
- TF组件的七种“武器”
- 编排器集成
- 关于安装的那些事（上）
- 关于安装的那些事（下）
- 主流监控系统工具的集成
- 开始第二天的工作
- 8个典型故障及排查Tips
- 关于集群更新的那些事
- 说说L3VPN及EVPN集成
- 关于服务链、BGPaaS及其它
Tungsten Fabric 架构解析系列文章——
- 第一篇：TF主要特点和用例
- 第二篇：TF怎么运作
- 第三篇：详解vRouter体系结构
- 第四篇：TF的服务链
- 第五篇：vRouter的部署选项
- 第六篇：TF如何收集、分析、部署？
- 第七篇：TF如何编排
- 第八篇：TF支持API一览
- 第九篇：TF如何连接到物理网络
- 第十篇：TF基于应用程序的安全策略
---
