Tungsten Fabric入門寶典丨關於多叢集和多資料中心

由於在內部使用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的內容。

由於此ID也可以手動配置，因此你可以為每個叢集的安全組設定相同的ID，從而允許來自該字首的流量。

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

在處理多個叢集時，DNS是一個很重要的主題。

由於Tungsten Fabric具有類似於OpenStack的預設設定的vDNS實現，因此你可以解析叢集中的vmname，並使這些名稱可以在外部可用。

• 
  

• 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 < 多叢集，。

當計劃安裝單叢集並且資料中心的數量為兩個時，還需要注意一件事。

由於Tungsten Fabric中的Zookeeper / Cassandra當前使用Quorum一致性等級，因此當主站點關閉時，第二個站點將無法繼續工作（Read和Write訪問許可權均不可用）。

•  

  (使用config-api, schema-transformer, svc-monitor, device-manager)

• (使用control, dns)

解決此問題的一種可能選項是，將一致性級別更改為ONE / TWO / THREE，或者LOCAL_ONE / LOCAL_QUORUM，儘管它需要重寫原始碼。

由於Zookeeper沒有這樣的knob，所以我知道的唯一方法，是在主站點關閉後更新weight。

• 即使Zookeeper暫時無法使用，大多陣列件仍繼續工作，儘管它用於HA的元件停止工作了（schema-transformer, svc-monitor, kube-manager, vcenter-plugin, ...）。

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