作者：Umberto Manferdini 譯者：TF編譯組
如果你看過任何有關Tungsten Fabric（附註：原文爲Contrail，在本系列文章中，Tungsten Fabric的功能與Contrail一致，文中出現Contrail之處均以Tungsten Fabric替換）的演示，可能都會碰到“服務鏈（service chain）”這個熱詞。現在，是時候對這個功能好好動手研究一番了。
那麼什麼是服務鏈？簡而言之，就是使流量在兩個虛擬網絡之間流動的過程中，經過一項或多項“服務”。
讓我們舉個例子吧！這裏有2個虛擬網絡：pippo和pluto。我們希望這兩個網絡互相通信。在Tungsten Fabric中，只需在兩個虛擬網絡上配置相同的RT（route target）即可實現（虛擬網絡是vrfs，還記得嗎？）。（附註：Route target 即RT，在Tungsten Fabric用來作爲路由的標記，也是MPLS中常用的路由更新標記。）
還有一個選擇，我們可以構建一個網絡策略，同時適用於兩個網絡，就是“允許這些虛擬網絡之間的任何流量”。而在幕後，Tungsten Fabric仍然依賴於路由route target（隱藏和自動生成目標）。
因此我們可以說，這兩種方法是相同的。
這看起來是正確的，但從根本上是錯誤的！使用網絡策略，使我們可以指定在虛擬網絡之間移動時，流量必須通過的一個或多個服務實例。這是第一種方法無法做到的。而這就是服務鏈！（附註：此處作者希望表達的是，儘管結果相同，但是實現的內容不一樣，第一種same RT實現的內容，是不同的網絡之間的路由屬性相同，意味着可以相互泄露和打通，而第二個則不是。）
如前所述，服務鏈可以包括一項或多項服務。這意味着從pippo到pluto的流量可以穿越防火牆，也同時穿越（一個接一個）防火牆和DPI。
乍一看，有人會說：“好，很酷！但我也可以通過路由做同樣的事情……”。沒錯，但這裏真正重要的是——易於部署。Tungsten Fabric負責所有事務，並自動配置所有需要的路由。你只需要告訴Tungsten Fabric自己的意圖即可：“允許這些網絡進行通話，並使流量通過這些服務實例”。我們正處於基於意圖的時代，不是嗎？
當然，這還不是故事的全部。Tungsten Fabric在表中引入了其它功能，例如運行狀況檢查（health checks），以提供高可用性和擴展能力。此外，網絡策略本身也可以用於基於L4的規則拒絕/允許流量。
那麼，現在的問題是：創建服務鏈需要做些什麼？
讓我們來仔細研究所有要素！
首先，我們需要兩個虛擬網絡。無需對它們配置任何route target。
接下來，我們在它們之間配置一個網絡策略，允許所有流量通過：
此時，兩個網絡可以互相通信！是時候轉向服務鏈了。
首先，我們創建一個虛擬機，該虛擬機將成爲我們服務實例的一部分。這是兩個虛擬網絡（VNF）之間的流量將遍歷的虛擬機！
例如，該虛擬機可以是防火牆。該VM必須在Openstack中創建；就像通過Nova創建的任何其它VM一樣。
這是在Openstack上執行的唯一操作。
接下來，回到Tungsten Fabric！我們創建一個名爲服務模板（service template）的對象：
顧名思義，服務模板是對服務的描述。下面五個參數是必須要配置的：
- 版本（version），必須爲v2
- 虛擬化類型（virtualization type），除非你打算使用物理網絡功能（PNF），否則必須爲虛擬機
- 服務類型（service type），可以是防火牆或分析器，我們使用第一個。
- 服務模式（service mode），可以是transparent（bump in the
wire），in-network（最常見），in-network-nat（使用nat時的特殊用例） - 接口列表，通常我們定義兩個接口：左和右
由於這是模板，因此可以多次用於不同VM的配置。例如，Juniper防火牆服務實例和第三方供應商防火牆服務實例都可以用服務模板進行部署。重要的是，在這兩種情況下，在OpenStack中創建的虛擬機都有兩個接口，可以將它們映射到服務模板中定義的接口（左和右）上。
接下來，我們創建服務實例。在服務實例對象中可以配置很多東西。這裏，我們將專注於使鏈條正常工作的最小配置。
服務實例引用服務模板。一旦指定了此引用，就可以將服務模板（左和右）中定義的接口映射到實際的虛擬網絡。例如，在這種情況下，我們向左映射到fourcade，向右映射到wierer。
現在，我們引入一個關鍵對象：端口元組（port tuple）。它是引用虛擬機接口的元組。如前所述，充當防火牆的實際VM不是由Tungsten Fabric定義的，而是像OpenStack中的任何其它VM一樣所創建的。但是，我們需要將該虛擬機“鏈接”到我們的服務實例。這是通過端口元組實現的。“鏈接”在虛擬機接口（vmi）級別執行。
在這種情況下，端口元組將包含兩個元素，一個用於服務模板中定義的每個接口（左和右）。此外，我們將服務模板接口映射到虛擬網絡（向左映射到fourcade，向右映射到wierer）。
現在，讓我們看一下虛擬機。它有3個端口：eth0連接到我們不關心的虛擬網絡，eth1連接到fourcade，eth2連接到wierer。下一步是什麼？很明顯！端口元組將包括eth1和eth2。這就是我們告訴Tungsten Fabric在遍歷服務實例時流量應該流向何處的方式。
沒有什麼能阻止我們讓單個服務實例擁有多個端口元組……ECMP怎麼辦？active/backup如何處理？…有主意嗎？我們稍後會處理。
現在，讓我們先聚焦這個用例。我們現在到哪兒了？來自fourcade網絡中的VM的流量，要發往更wierer網絡中的一個IP地址。流量需要從fourcade到wierer。這個通信在網絡策略中是允許的。由於網絡策略告訴從fourcade到wierer的流量必須經過服務實例，因此數據包被髮送到VM eth1端口，並將從eth2端口進入wierer網絡。
由於Tungsten Fabric是基於流的，因此可以保證對稱性和粘性！
這就是珠穆朗瑪峯的理論。
在下篇文章中，我們將看到一個真實的例子。這將使我們看到創建一條服務鏈有多麼容易，以及Tungsten Fabric如何掩蓋了所有的複雜性！
Tungsten Fabric 架構解析系列文章——
第一篇：TF主要特點和用例
第二篇：TF怎麼運作
第三篇：詳解vRouter體系結構
第四篇：TF的服務鏈
第五篇：vRouter的部署選項
第六篇：TF如何收集、分析、部署？
第七篇：TF如何編排
第八篇：TF支持API一覽
第九篇：TF如何連接到物理網絡
第十篇：TF基於應用程序的安全策略
