Tungsten Fabric安裝的示例分析

這篇文章主要介紹Tungsten Fabric安裝的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

Tungsten Fabric 組件的HA行為

如果計劃設置用于關鍵流量，則始終需要使用HA。

Tungsten Fabric擁有不錯的HA實施，已經以下的文檔中有相關信息。

• http://www.opencontrail.org/opencontrail-architecture-documentation/#section2_7

這里我想多說的一件事，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。

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

調整集群大小

對于Tungsten Fabric集群的一般規格（sizing），您可以使用下面的表。

• https://github.com/hartmutschroeder/contrailandrhosp10#21sizing-the-controller-nodes-and-vms

如果集群規模很大，則需要大量資源來保障控制平面的穩定。

請注意，從5.1版本開始，analytics數據庫（以及analytics的某些組件）成為了可選項。因此，如果您只想使用Tungsten Fabric中的控制平面，我建議使用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安裝的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！