《云数据中心网络与SDN：技术架构与实现》——3.3.3　服务链

3.3.3　服务链

服务链是指，业务流量需要按照特定的业务逻辑有次序地经过特定的服务节点，如从Internet进入数据中心访问云中Web服务的流量，需要先经过FW进行过滤，然后再经过LB在多个Web服务器实例间进行分流，最后才会发送给某一Web服务器实例。传统的数据中心网络中，FW/LB/IPS均使用专业硬件设备来实现，这些硬件设备的价格十分昂贵，一两个节点就需要负责处理全部的流量，设备的体积通常也很庞大，部署的灵活性较差。在实际部署中，受限于传统的路由机制，这些服务节点或者被旁挂在汇聚设备上，或者被串在汇聚设备和核心设备之间。在旁挂的方式中，需要在汇聚设备上手动配置PBR去实现引流，使得流量能够按照特定的顺序经过这些设备；在串联的方式中，不需要做额外的配置，但是服务节点处理流量的压力太大，很可能会成为性能方面的瓶颈。

随着NFV的发展，服务节点的形态正逐步从专用硬件向VNF转变，形态上的虚拟化使得服务节点的部署不再受物理位置所局限，VNF可以插入到网络边缘的任意位置，有时还会在不同的位置间进行迁移。因此，传统的路由机制无法满足虚拟化环境中服务链的实现需求，而SDN凭借着高度的自动化以及对路由的灵活修饰能力，已经成为数据中心服务链的支撑性技术，而其中流量的分类和引导是SDN实现服务链的基础。

1.流量的分类

流量分类的目的，是识别出来哪些是服务链流量，哪些不属于服务链流量。从概念上来说，流量的分类需要通过专用的流量分类设备来完成，由SDN控制器向流量分类设备下发流量分类策略。但在实际中，分类的功能往往集成在转发设备中进行实现，此时分类策略所能达到的粒度也由转发设备来决定。粗放一点的粒度可以是以端口为单位的，以租户为单位的精细一点的粒度往往需要对L2～L4中的字段进行组合来识别“流”。当然，也可以在转发的设备上集成DPI对流量进行应用层面的分类。

通常来说，流量的分类结果往往是确定的，分类也只需要在服务链的入口设备上进行一次就可以了，但是考虑到某些VNF会对流量的字段进行改写，如NAT会改写源IP地址、LB可能会改写源/目的IP地址，那么经过这些服务节点的改写后，针对原始流量特征的分类结果可能就会失效了，因此就需要控制器向转发设备下发规则对流量重新进行分类。某些VNF会对流量进行更为细致的分类，比如IPS会根据流量的动态特征分析可能的恶意流量源，据此将黑名单上主机所发出的流量引导到堡垒主机上。这时，也需要IPS将分析出来的黑名单告知控制器，控制器向转发设备下发高优先级的分类策略以识别恶意流量。当IPS发现攻击已经结束时，黑名单解除，相应的分类策略控制器要及时地清除。

当然，上面所举的NAT、LB和IPS的例子，都可以看作针对Per Session的动态处理。要求控制器能够动态地获取VNF的处理结果，并维护Session的状态，实现难度较高。相比之下，静态地下发Per Flow的分类策略的实现则要简单得多。

2.流量的引导

有了流量分类作为基础，即可对流量进行引导，使之按需特定的顺序经过VNF。要实现流量的引导，最为核心的就是对数据进行重新封装。封装的思路无外乎有下面几种：

1）在数据包原有字段间插入新的垫层；

2）使用数据包的保留字段或已有的但不会用到的字段；

3）为数据包封装外层包头；

4）改写现有字段。

封装的字段需要有效地携带服务链转发所需的信息，主要包括以下三类：流量所属的服务链ID、流量当前在服务链上所处的位置以及下一跳的目的地址。

除了上述三类基本信息外，某些场景下封装还要携带VNF的处理结果，以便后续的VNF或者转发设备能够根据处理结果调整流量处理或者转发的策略。这些处理结果的信息通常被称为Context，Context的定义与VNF的处理机制密切相关，因此不同的VNF使用的Context的语义可能会非常灵活，这就需要控制器来协调Context的分配，同时要求数据平面的封装可以灵活地进行扩展。

流量的引导通常还需要保证上下行流量所经过的路径是对称的，这不仅要求双向经过的VNF顺序是对称的，还要求必须经过相同的VNF实例，以防某些VNF上出现半开连接而将流量丢弃。当VNF进行在线迁移时，需要动态地调整流量的引导规则，此时应尽量保证数据包不乱序，并且尽可能地减少由于路径调整造成的业务中断时间。

基于SDN的服务链有很多种实现方式。得益于OVS在数据中心的普及，基于OpenFlow来实现服务链是最为常见的，OpenFlow在网络边缘可以精确地识别流量，然后通过流表引导流量在不同的VNF间进行跳转。其他的实现方式还包括VLAN Stitching、PBR、BGP VPN、NSH、SR等。PBR和OpenFlow的原理类似，本质上都属于ACL，相比于传统方式下在汇聚设备上手配策略路由，控制器可以自动化地配置PBR。VLAN Stitching方式中，控制器会为服务链上的每一跳配置专用的VLAN，通过在这些VLAN中进行的泛洪，流量就能够自然地流经各个VNF。BGP VPN方式中，控制器会为服务链分配专用的VPN标识，并根据VNF的分布信息集中地修改BGP的下跳来实现引流。NSH为服务链设计了新的包头，引入了新字段SPI和SI来转发流量NSH作为一种数据面的封装，可以配合OpenFlow来使用。SR原生地支持源路由，控制器会根据VNF的分布生成label stack，直接在header中指定要经过的各个VNF。

3.其他方面的考虑

为了保证VNF工作的性能，同时考虑到安全性的问题，不同的服务链可能会被分配不同的VNF实例，当某种类型的VNF的性能要求较高时，可以分配该类VNF的多个实例。为了实现多个VNF间的负载均衡，SDN控制器需要通过一些监测技术来维护这些VNF实例的负载状态，同时需要运行一些负载均衡算法来保证多个VNF实例的高可用。

在服务链中引入OAM，主要是对服务链路径的状态进行监测，这一块业界目前还没有形成标准，参考IETF相关的Draft，可以看到对于服务链路径状态的监测包括主要以下几个方面。

连通性。包括可达性、Path MTU、包的乱序和损坏等。

连续性。包括链路故障、路径故障、VNF故障等，可以通过BFD来实现。

路径跟踪。包括路径上逐跳的跟踪，当存在多链路时需要跟踪ECMP路径，需要中继设备能够支持对OAM的探针进行回复。

性能。包括时延、丢包，需要支持时间戳以及时间同步机制（如NTP、GPS）。

基于SDN实现服务链是一个新兴的技术领域，无论是在工程实现还是学术研究中，目前都存在着很多的空白，这里无法逐一而述。另外，服务链的实现不仅依赖于SDN对流量的识别和引导，还依赖于NFV对VNF的管理与监测。SDN与NFV系统间需要进行接口——交互和功能切割，这超出了本书的讨论范围，有兴趣的读者请自行了解。