由于在內部使用MPLS-VPN，因此Tungsten Fabric中的virtual-network可以擴展到其它Tungsten Fabric集群。

• 這可能令人有點驚訝，但據我所知，Neutron ML2插件或其它某些CNI不支持此設置

也就是說，由于它們具有不同的數據庫，因此需要在它們之間標記共享資源。

為此，我將描述幾個bgp參數的用法。

由于Tungsten Fabric使用L3VPN進行VRF間的路由，因此，如果在VRF之間正確設置了route-target，則它可以對報文進行路由。

• 由于不能在多個集群之間使用network-policy / logical-router，因此需要在每個virtual-network上直接配置route-target。

注意：如果指定了僅做l3轉發，即使在內部VRF的轉發中，也會使用L3VPN，因此在該設置中將不使用橋接（bridging）。

Tungsten Fabric還具有一些擴展的屬性來傳達安全組ID的內容。

• https://github.com/Juniper/contrail-controller/wiki/BGP-Extended-Communities

由于此ID也可以手動配置，因此你可以為每個集群的安全組設置相同的ID，從而允許來自該前綴的流量。

注意：據我所知，無法從R5.1分支中的Tungsten Fabric Webui手動配置標簽的ID，因此無法在集群之間使用fw-policy。此行為將來可能會更改。

在處理多個集群時，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設置中修改。

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中進行設置）

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必須是可訪問的）

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這樣的編排器已經能支持大量的虛擬機管理程序。

如果流量是跨多個數據中心的，則需要在計劃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, ...）。

當數據中心的數量超過兩個時，這將不再是一個問題。

• 第一篇： TF主要特點和用例

•   第二篇： TF怎么運作

•    第三篇：詳解vRouter體系結構

•    第四篇： TF的服務鏈

•   第五篇： vRouter的部署選項

•    第六篇： TF如何收集、分析、部署？

•    第七篇： TF如何編排

•   第八篇： TF支持API一覽

•   第九篇： TF如何連接到物理網絡

•   第十篇： TF基于應用程序的安全策略