细说TF服务链丨一文讲透什么是服务链（多图）

作者：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基于应用程序的安全策略