电子发烧友App
1.SDN服务链基本概述
由于Overlay网络的发展，使得虚拟网络和物理网络分离，让数据中心的网络控制变得更加灵活，更具有扩展性。然而，在数据中心中，还存在很多介于虚拟网络和物理网络之间的中间件，如防火墙，QoS，负载均衡器等。这些中间件提供了必要的业务处理功能，即Service Function。灵活、便捷、高效、安全地调配流量到Service Function上处理，形成服务链（Service Function Chaining），这就是SFC项目要解决的问题。服务链可以理解为一种业务形式。
过去也有服务链的概念，但传统的网络服务链往往和网络拓扑紧密耦合、部署复杂，在服务链变更、扩容时，都需要改动网络拓扑，重新进行网络设备的配置。而云计算环境广泛使用虚拟化技术，具有动态性、高流动性、规模易变化、多租户等特点，传统网络的服务链无法满足这些需求，SDN的出现让服务链又焕发了生机。因此，当前再谈及服务链时，默认指的是SDN服务链。
与传统DC中配置的网络服务链相比，基于SDN的SFC具有如下的优势：
- 传统的网络服务链往往基于手工配置，很大程度上依赖于具体的网络拓扑，以至于网络设备之间的耦合性很大。而基于SDN的配置，可以动态的添加或者删除链表上的服务节点，不仅方便使用，而且解耦了网络设备之间的关联。
- 在数据流量经过链表的过程中，SFC还支持分类器与服务，服务与服务之间的上下文信息共享。
- 在传统的数据服务链中，数据包往往要经过过次分类，即多次解包、封包的过程。而在SFC中，这个过程大大缩减，一般只需在分类一次即可，使得整个过程更便捷、更高效。2.基于OpenDaylight的服务链项目
2.1 Service Function Chaining 的架构及组件
OpenDaylight的SFC项目是整个控制器平台内部的一个功能模块。用户可以通过控制器提供的北向API来使用的SFC的功能，例如创建、更新或者删除Service Chain，还可以通过配置非透明的metadata数据段用来在Service Function的节点间实现数据共享。
同时，项目可以向Controller的DataStore中注册、配置服务节点，并获取拓扑。南向也支持Netconf，Openflow12等协议。
SFC核心组件如下：
- Classification：根据初始化的（配置好的）policy匹配数据流进行封装，然后转入到Service Function Chain中。
- Service Function(SF): 负责对收到的数据包进行特定功能的处理。作为一个逻辑上的组件，SF在具体实现的上可以是一个虚拟的元素，或者是嵌入在具体网络设备上的某种功能。常见的SF有：防火墙(firewall)，WAN设备加速器，深层报文检测(Deep Packet Inspection,DPI)，NAT等等。
- Service Function Forwarder(SFF):主要负责Service Function Chaining上的流量转发控制。
- Service Function Chain(SFC): SFC定义了一个抽象的Service Function有序集合。经过分类后的包要依次去遍历集合中的Service Function。比如：用户可以配置firewall->qos->dpi三种服务来构建一条SFC。
- Rendered Service Path(RSP) : 数据包实际行走的路径。
- Service Function Path(Service Function Path): SFP是一个逻辑概念，
它是介于SFC和RSP之间的一层抽象，有时候会将SFP与SFC等同。
2.2 ODL的SFC项目工作流原理
那么，SFC项目是怎么综合起上述的组件进行工作的呢？
一种基于NSH封装头的机制是，使用ODL配置并下发一条Service Function Chain，每条Chain都有自己的标识。当host1发送数据包给host2，数据包首先会到分类器中进行筛选。分类出需要经过Service Function Chaining的数据包会进行封装，并打上NSH头。头中包含了很多信息，包括走哪一条服务链，服务链有几跳等。接着数据包会依次经过SFF，由SFF将数据包传递给SF或者下一跳的SFF，直到链的最后。
3.实验
本篇文章旨在通过基本概念的介绍和一个SFC的实验，帮助大家了解SFC是什么，在OpenDaylight中如何去配置基本的SFC。通过对SFC有个大致的了解，有兴趣的同学可以继续深入地去研究NSH，SFC架构及应用等知识。
3.1 实验准备
Python导入包包括：requests,flask,netifaces,paramiko等
在Ubuntu14.04下搭建ODL环境参考：https://wiki.opendaylight.org/view/Install_On_Ubuntu_14.04
在Ubuntu下安装Python3.4及所需包如下：
如果没有Python3.4:
安装一个Python3.4-pip安装器
安装flask包，其他包安装类似，根据版本不同，安装方法或者指令不一定与这里相同：
3.2 术语简表：
- SF : Service Function
- SFF : Service Function Forwarder
- SFP : Service Function Path
- RSP : Rendered Service Path
- ODL : OpenDaylight
- SFC Agent: Service Function Chaining Agent.
3.3 基本配置和安装：
ifconfig查看本地机器的ip，我这边是：192.168.2.134
安装ODL的sfc项目：git clone http://git.opendaylight.org/gerrit/sfc
楼主使用的SFC是5月份的版本：
可以git reset –-hard cd12dda6回到那个版本。
如果读者在实验的时候，用的是最新版本的SFC，在sfc/sfc-py/sfc/nsh/service.py脚本有很多bug，要做适当修改。这里为方便，就使用之前版本演示。
用maven构建一下项目：
mvn clean install –DskipTests
启动ODL:
过一会儿，就可以用浏览器进入SFC的ui界面了：http://localhost:8181/sfc/index.html 用户名和密码都是:admin
刚开始进来都是空的，点击System Info会有404也不要紧张，因为什么都没有配置。另外，在ODL中创建SFC有两种方式：第一，用北向的RESTAPI；第二，用UI来创建。本次实验用将基于UI，这样看起来比较直观，方便理解。后续有兴趣用REST来配置的参见SFC 101文档。
3.4 开始实验
3.4.1 启动SFC Agent
SFC Agent是用Python脚本写的一个仿真工具，位于SFC项目的sfc-py目录下。在实验的过程中，ODL在南向通过REST与Agent进行通信，即ODL通过REST将配置的信息下发给Agent，Agent根据这些信息，在数据平面仿真出相应的元素组件。使用Agent的好处就是在实验中，简化南向接口，易于实现实验。
进入到sfc/sfc-py目录下，打开start_agent.sh文件，修改默认的ip地址为本地主机ip:
也可以将127.0.0.1改成192.168.2.134。
启动Agent:
根据上图可以直到Agent运行的端口是5000。
3.4.2 创建Service Functiont
点击导航栏的Service Function标签，再点击”Add Service Function”，填写表格如下：
点击Submit，在Agent端，有如下信息输出：
表明Agent已经成功为我们创建好了SF1(firewall)。
这里有几个地方要注意：
1.NSH头的使用。我们这里是基于Agent的仿真实验，没有对分类器做配置。选True 和False都没有关系，但是实际情况下会根据NSH头的信息来选择具体的路径。具体可以研究：http://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
2.数据平面的通信方式一定要选，这里选vxlan-gpe。要不然Agent收不到请求。
3.SFF1暂时还没有创建，可以先填入SFF1，后面创建SFF的名字要与这里一致。
3.4.3 创建SFF
在导航菜单中点击Service Function Forwarder，点击”Add Service Function Forwarder”，填写表单信息如下：
右下角的SFF dictionary“Remove”掉，后面的版本也没有这个directory了。如下图：
submit以后,在Agent端，SFF创建成功信息打印如下：
3.4.4 目前拓扑和工作流
3.4.5 创建Service Function Chain
在导航栏点击Service Function Chain标签：
- 点击创建Service Function Chain
- 填入名字“Chain-1”,提交
- 将”firewall”的SF拖拽到右边的Chain-1中
- 保存一下，点击deploy，生成一条Service Function Path，命名为“Chain-1-Path-1”,这样就创建好了Service Function Paht。
3.4.6 创建Rendered Function Path
导航栏中点击”Service Function Paths” ,将会看到我们刚创建的SFP。
根据SFP，点击上图按钮，可以生成一条RSP。如果勾上了”Symmetric path”就会另外生成一条对称反向的RSP。
成功以后，记住RSP的两个重要属性“Path-ID”为63，“starting-index”为255。
这个时候我们可以看到Agent里面打印的消息：
通过从SFC 的创建到SFP，再到RSP的创建，是一个由抽象到具体的过程。从应用的角度来理解，SFC是对Service Function的一层抽象，这里的SFP是具体化每个Service Function到其对应的配置的SF(SF1)，而RSP的生成代表包具体穿过的路径将是怎样的。
3.4.7 发送数据包
我们将发送数据包来遍历这条简单的SFC，“Path-ID”为63，“starting-index”为255。打开sfc/sfc-py/sfc/目录，运行如下命令：
python3.4 sff_client.py --remote-sff-ip 192.168.2.134 --remote-sff-port 4789 --sfp-id 63 --sfp-index 255
Agent获取结果如下：
从上图可以看到客户端（Client192.168.2.134:4790）发送包到SFF，SFF然后再将包发送给SF进行处理。SF处理完再转回给SFF，SFF再寻找下一跳，如果没找到，判断为链表末尾。
3.4.8 实验总结
以上我们简单的演示了一个SFC的使用实验，只包含了一个SFF和SF。通过在ODL中使用北向UI接口配置SF的信息，配置SFF的信息并关联相应的SF下发给Agent。在这个过程里，我们还可以删除，修改这些节点信息，充分体现了基于SDN的服务链的灵活性、拓扑独立性。
用户需要配置服务链的时候，只需要通过控制器的北向接口自由组合节点成有序序列。然后使用的时候，生成一条数据包路径，并下发即可。同时，用户也可以配置多条服务链。
注意，在不修改原始python脚本的情况下，在南向使用Agent可以创建多SF挂到一个SFF上，但只能创建一个SFF。
审核编辑：郭婷
工商网监
评论