Tungsten Fabric入門寶典系列文章，來自技術大牛傾囊相授的實踐經驗，由TF中文社區爲您編譯呈現，旨在幫助新手深入理解TF的運行、安裝、集成、調試等全流程。如果您有相關經驗或疑問，歡迎與我們互動，並與社區極客們進一步交流。更多TF技術文章，請點擊【TF中文社區】公號底部按鈕＞學習＞文章合集。
作者：Tatsuya Naganawa 譯者：TF編譯組
服務鏈
儘管有很多用例，但NFVI將成爲Tungsten Fabric最突出的用例之一，這是由於NFVI許多獨特的功能，使其成爲實現軟件的基礎。
其中最著名的功能就是服務鏈（service-chain），該功能可在不更改VNF IP的情況下管理流量，從而可以實時插入和刪除VNF。
由於vRouter可以在內部包含VRF，因此它可以在VNF的每個接口上都具有VRF，並且可以通過虛假的下一跳處理流量，例如發送給下一個VNF。
Tungsten Fabric的服務鏈是通過這種方式實現的，因此一旦創建服務鏈，你將看到很多個VRF被創建，並且將插入下一跳，將流量發送到服務鏈中的下一個VNF。
- VRF（在control的術語中是routing-instance）被命名爲domain-name:project-name:virtual-network-name:routing-instance-name。在大多數情況下，virtual-network-name和routing-instance-name是相同的，但是服務鏈是該規則的一個例外
要設置一個服務鏈示例，可以按照以下視頻中的步驟進行操作：
- https://www.youtube.com/watch?v=h5qOqsPtQ7M
之後，你可以看到左側virtual-network具有右側virtual-network的前綴，並帶有更新的下一跳，該前綴指向VNF的左側接口，對於右側virtual-network反之亦然。
注意：據我所知，在使用服務鏈v2時，僅使用“左”和“右”接口進行服務鏈計算，而“管理”和“其它”接口則被忽略
L2, L3, NAT
有許多具有不同流量類型集的VNF，因此NFVI的SDN也需要支持多種流量類型。
爲此，Tungsten Fabric服務鏈支持三種流量類型，即l2，l3，nat。
l2服務鏈（也稱爲透明服務鏈）可以與透明VNF一起使用，透明VNF與網橋具有相似的功能，並基於arp響應發送報文。
儘管vRouter始終使用相同的mac地址（00:01:00:5e:00:00），
- https://github.com/Juniper/contrail-controller/wiki/Contrail-VRouter-ARP-Processing#vrouter-mac-address
但這種情況是該規則的例外，VNF左側的vRouter使用dest mac: 2:0:0:0:0:2發送流量，而VNF右側的vRouter使用dest mac 1:0:0:0:0:1發送流量。因此，bridge-type的VNF會將流量發送到其接口的另一側。
請注意，即使使用l2 vnf，左側virtual-network和右側virtual-network也需要具有不同的子網。這可能有點反常，但是由於vRouter可以進行l3路由，因此可以使用vRouter - L2VNF - vRouter，就像router - L2VNF – router是可以接受的一樣。
另一方面，l3服務鏈（也稱爲in-network服務鏈）將在不更改mac地址的情況下將流量發送到VNF，因爲在這種情況下，VNF將根據其目標IP進行路由（類似於路由器的行爲）。除mac地址外，其行爲與l2的情況幾乎相同。
Nat服務鏈類似於l3服務鏈，因爲它希望VNF根據目標IP進行路由。一個很大的區別是，它將右側virtual-network的前綴複製到左側virtual-network，但是不會將左側virtual-network的前綴複製到右側virtual-network！
- 因此左/右接口需要仔細選擇，因爲在這種情況下它是不對稱的
這種服務鍊形式的典型用例是，在用於Internet訪問的SNAT等情況下，VNF的左側接口具有私網IP，而右側接口具有全局IP。由於私網IP無法導出到Internet，在這種情況下，左側virtual-network的前綴無法複製到右側virtual-network。
ECMP，多VNF
服務鏈功能還支持ECMP設置，用於規模化部署。
- 配置基本相同，但需要將多個端口-元組分配給一個服務實例。
在這之後，你會發現，流量將根據5個數據包的5元組進行負載平衡。
多VNF也可以設置，如果將多個服務實例分配到一個網絡策略上，則可以設置多VNF。
當使用l3服務鏈時，雖然可能會有反直覺，但需要將兩個VNF分配給同一個虛擬網絡。
- 因爲所有來自VNF的數據包都會在服務鏈的獨立VRF中，所以它們可以有相同的子網。
也支持同時使用l2和l3，不過在這種情況下，需要將l2 vnf分配到不同的虛擬網絡中，其中一個網絡政策是附加的。
- 在這篇博文中描述了設置示例：https://tungsten.io/building-and-testing-layer2-service-images-for-opencontrail/
子接口
這也是NFVI中使用的功能，因此這裏我也要提一下。
VNF會基於各種原因發送帶標籤的報文。在這種情況下，如果vlan標籤不同，則vRouter可以使用不同的VRF。
- 類似於Junos術語“set routing-instances routing-interface-name interface
xxx”中的子接口
這裏描述了具體操作：
https://www.youtube.com/watch?v=ANhBQe_DS2E
DPDK
vRouter具有使用DPDK與物理NIC交互的功能。
它將經常用於NFV類型的部署，因爲基於純Linux kernel的網絡堆棧，要獲得與典型VNF（本身可能使用DPDK或類似技術）相當的轉發性能仍然不容易。
- https://blog.cloudflare.com/how-to-receive-a-million-packets/
要通過ansible-deployer啓用此功能，需要設置這些參數。
bms1:
roles:
vrouter:
AGENT_MODE: dpdk
CPU_CORE_MASK: “0xe” ## coremask for forwarding core (Note: please don't include first core in numa to reach optimal performance :( )
SERVICE_CORE_MASK: “0x1” ## this is for non-forwarding thread, so isolcpu for this core is not needed
DPDK_CTRL_THREAD_MASK: “0x1” ## same as SERVICE_CORE_MASK
DPDK_UIO_DRIVER: uio_pci_generic ## uio driver name
HUGE_PAGES: 16000 ## number of 2MB hugepages, it can be smaller
當設置爲AGENT_MODE: dpdk時，ansible-deployer將會安裝一些容器，例如vrouter-dpdk——這是一個針對物理NIC運行PMD的進程。因此在這種情況下，將基於DPDK實現從vRouter到物理NIC的轉發。
注意：
1.由於vRouter鏈接到PMD的數量有限，因此要使用某些特定的NIC，可能需要重新構建vRouter
- https://github.com/Juniper/contrail-vrouter/blob/master/SConscript#L321
2.對於某些NIC（例如XL710），不能使用uio_pci_generic。在這種情況下，需要改用vfio-pci
- https://doc.dpdk.org/guides-18.05/rel_notes/known_issues.html#uio-pci-generic-module-bind-failed-in-x710-xl710-xxv710
由於在這種情況下，vRouter的轉發平面不在kernel空間中，因此無法使用tap設備從VM獲取報文。爲此，QEMU具有“vhostuser”的功能，用於在用戶空間中將報文發送到dpdk進程。當vRouter配置爲AGENT_MODE: dpdk時，nova-vif-driver將自動創建vhostuser vif，而不是創建用於kernel vRouter的tap vif。
- 從VM方面看，它看起來仍然像virtio，因此可以使用常規的virtio驅動程序與DPDK vRouter進行通信。
一個警告是，當QEMU將要連接到vhostuser界面時，qemu還需要爲此提供巨大的支持。使用OpenStack時，此knob將爲每個VM分配大量頁面。
openstack flavor set flavorname --property hw:mem_page_size=large
- hw:mem_page_size=2MB, hw:mem_page_size=1GB also can be used
爲了達到最佳性能，kernel和dpdk進程本身都有很多調整參數。對我來說，在kernel方面以下兩篇文章是最有幫助的。
- https://www.redhat.com/en/blog/tuning-zero-packet-loss-red-hat-openstack-platform-part-1
- https://www.redhat.com/en/blog/going-full-deterministic-using-real-time-openstack
- cat /proc/sched_debug也可用於查看核心隔離是否運行良好
而在vRouter方面，這一點可能需要注意。
1.vRouter將使用基於5-tuple的核心負載均衡，因此爲了獲得最佳性能，可能需要增加流的數量
- https://www.openvswitch.org/support/ovscon2018/6/0940-yang.pptx
注意：當使用vrouter-dpdk時，使用untagged數據包可能會帶來更多的吞吐量（這意味着在不使用–vlan_tci的情況下提供vrouter-dpdk）
BGPaaS
BGPaaS也是Tungsten Fabric中比較獨特的功能，該功能用於在VNF中插入VRF的路由。
- 從某種意義上說，它有點類似於AWS VPN網關，因爲它會自動從VPC路由表中獲取路由
從操作角度來看，使用vRouter的網關IP和服務IP，vRouter中的VNF將具有IPV4 bgp對等方。
一個值得注意的用例是設置ipsec VNF，它可以通過VPN網關連接到公共雲。在這種情況下，VPC的路由表將被複制到VNF，並將通過BGPaaS複製到vRouter的VRF，因此，當在公共雲的VPC中新添加修改的子網時，所有前綴均會被正確分配。
Service Mesh
Istio運行良好，多集羣也是其中很有趣的主題。
- https://www.youtube.com/watch?v=VSNc9qd2poA
- https://istio.io/docs/setup/kubernetes/install/multicluster/vpn/
Tungsten Fabric入門寶典系列文章——
1.首次啓動和運行指南
2. TF組件的七種“武器”
3. 編排器集成
4.關於安裝的那些事（上）
5.關於安裝的那些事（下）
6.主流監控系統工具的集成
7.開始第二天的工作
8.8個典型故障及排查Tips
9.關於集羣更新的那些事
10.說說L3VPN及EVPN集成
Tungsten Fabric 架構解析系列文章——
第一篇：TF主要特點和用例
第二篇：TF怎麼運作
第三篇：詳解vRouter體系結構
第四篇：TF的服務鏈
第五篇：vRouter的部署選項
第六篇：TF如何收集、分析、部署？
第七篇：TF如何編排
第八篇：TF支持API一覽
第九篇：TF如何連接到物理網絡
第十篇：TF基於應用程序的安全策略
