作者：Umberto Manferdini 譯者：TF編譯組

服務鏈的核心是服務例項。服務例項透過埠元組將鏈（chain）“連結”到虛擬機器，而該虛擬機器就是流量所經過的實際例項。

這個虛擬機器也代表著單點故障！如果VM死亡，則其介面也將死亡，於是，埠元組將引用“死”的介面。結果是什麼？流量的丟失！

保持服務鏈或服務例項的冗餘，是很重要的。

要了解冗餘是如何實現的，有必要回顧一下服務鏈路由的工作方式。

讓我們考慮一下這個例子：

現在，我們在左右VN之間有一個網路策略。

TCP流量傳送到服務例項“usa”，而UDP流量傳送到服務例項“europe”。

在評估流（flow）時，與規則匹配的流量將傳送到相應的“服務”VN。例如，TCP流量將傳送到left_service_usa。在評估網路策略規則時，Tungsten Fabric不會考慮服務例項的狀態。透過這種方式，Tungsten Fabric就不需要關心服務例項的埠元組所引用的介面狀態。

因此，假設我們有一個TCP流，並且服務例項“usa”中埠元組引用的介面已關閉（down）。Tungsten Fabric將如何表現？流量與第一個規則匹配後，將傳送到服務例項“usa”，也就是left_service_usa的VN。那裡沒有有效的下一跳，這導致了流量丟失。

現在，你應該清楚如何透過服務鏈來解決冗餘問題了。冗餘必須允許服務VN中有多個下一跳。

實現它的方法，是在服務例項中配置多個埠元組。

這就是鏈條的由來：

從左側到右側的所有流量，都透過服務例項“pippo”。

在該服務例項內，我們配置兩個埠元組：一個引用vFW1埠，另一個引用vFW2埠。

結果如何？當路由從右側向左側洩漏時，兩個埠元組的左側介面都將設定為下一跳，從而導致透過ECMP下一跳，可以訪問源自右側VN的路由。

例如，右側VN的路由為0/0。如果路由策略允許，該路由將洩漏到左側VN。在洩漏時，Tungsten Fabric會檢查服務例項的所有埠元組，獲取所有剩餘的介面，並將它們設定為下一跳。結果就是，從左側VN的角度來看，0/0的ECMP下一跳具有兩條相等的成本路徑：一條透過vFW1，一條透過vFW2。

如果一個vFW死亡，我們還有另一個！這就實現了冗餘！

從右側到左側的方向，也同樣適用。

站在實際的角度來看，使鏈變得冗餘，只需要我們簡單地根據需要新增任意數量的埠元組：

預設情況下，這種冗餘是active/active的。

在前面的示例中，基於雜湊結果，新的流從左到右可以遍歷vFW1或vFW2。考慮到我們提到了ECMP下一跳，這是顯而易見的。

作為另一種方案，active/backup冗餘也是可以實現的。

為了實現這一目標，我們必須回顧另一個Tungsten Fabric的概念。VMI（虛擬機器介面）是路由元素，因為它們可以在其上配置本地優先順序的值。該值可以由使用者配置。

這裡的想法是，在引用作為active的VNF的埠元組的vmis上保留預設值（LP = 200），而在引用作為backup的VNF的埠元組的vmis上設定更差的值（LP = 100）。

這樣，所有下一跳是backup vFW介面的路由都將具有LP = 100的值。

讓我們再次考慮0/0路由。一旦洩漏到左側VN，我們將獲得該路由的兩個副本：一個透過LP = 200的vFW1，另一個透過LP = 100的vFW2。Tungsten Fabric將執行BGP最佳路徑選擇，當然，透過vFW1的路由將變為active狀態。

與Junos相似，此路由將進入FIB（在本例中為vRouter的FIB）。同時，RIB中已經準備好透過vFW2的另一種路由，一旦發生故障，它將被載入到FIB中，從而幫助我們實現快速收斂！

當然，我們在這裡討論的所有功能仍然有效！透過策略控制洩漏，最重要的是，使用執行狀況檢查來快速檢測故障，並最大程度地利用這種冗餘！

細說TF服務鏈 ——

Tungsten Fabric 架構解析系列文章 ——

細說TF服務鏈丨服務鏈的冗餘是如何實現的