一、概述
本文以Queens版本为例描述Openstack TaaS服务的相关设计思路。
TaaS，全称为Tap as a Service，其主要功能是将流量镜像到特定的、运行有流量分析软件的虚拟机中，以实现租户流量的可视化。
TaaS中主要定义了两个数据类型，如下：
- Tap Service：指的是一个流量镜像服务的实例，其中一个Tap Service需要关联一个Destination Port(流量需要镜像到的目的地，即：镜像目的地)，同时，一个Tap Service可以包含多个Tap Flow，对于Tap Flow的解释参见如下。Tap Service中定义了若干个字段值，具体如下所示，其中port_id即为关联的Destination Port。
- Tap Flow：指的是一个流量镜像服务的规则，其中一个Tap Flow需要关联一个Source Port(流量从哪里镜像，即：镜像源)。Tap Flow中定义了若干个字段值，具体如下所示，其中direction可以包含IN、OUT、BOTH三个方向值，即分别对应入方向、出方向、出入结合。
为了防止租户间的流量泄露，一个Tap Service只能属于一个租户，相应的关联的Destination Port和Source Port都应该属于该租户。
二、代码结构
主要分为如下几个部分：
- CLI
这部分主要是提供一些CLI供使用者使用TaaS服务。这部分的代码主要在taas_client目录下，该目录下有两个.py文件，分别为tapflow.py和tapservice.py，分别提供了tapflow和tapservice的增、删、改、查CLI。
- DB
这部分主要是定义了tapflow和tapservice的数据库存储格式及其相应的增、删、改、查等数据库操作。这部分的代码主要在db目录下对应的taas_db.py文件。
- Service Plugin
这部分主要的功能是处理CLI传下来的操作请求，在数据库中维护tapservice和tapflow的状态，并将请求投递给相应的Service Plugin Driver。这部分的代码在services/taas目录下的taas_plugin.py文件，该文件定义的TaasPlugin即为Service Plugin。
Service Plugin Driver
接收Service Plugin发下来的请求，通过RPC通道转送给相应的Agent。这部分代码在services/taas/service_drivers目录下的taas_rpc.py文件，该文件定义的TaasRpcDriver即为Service Plugin Driver。
- Agent
通过RPC通道接收Service Plugin Driver发来的请求，并调用相应的Agent Driver来处理这些请求。这部分代码在services/taas/agents/ovs目录下的taas_ovs_agent.py文件，该文件定义的TaasOvsAgentRpcCallback即为对应的Agent。
- Agent Driver
接收Agent下发的请求，并处理，在本地OVS设备上增加或删除一些tap相关的流表。除此之外，该Agent Driver负责在本地OVS设备初始化一些tap相关的流表。这部分代码在services/taas/drivers/linux/ovs_taas.py文件，该文件定义的OvsTaasDriver即为对应的Agent Driver。
三、总体框架
TaaS总体框架如上图所示，主要分为两大部分，即：Service端和Agent端。通常Service端部署在控制节点上，而Agent端部署在计算节点上，二者之间通过RPC通道进行交互信息。图中的Service Driver和Agent Driver都是设计成可插式的，可以替换成其他Driver。
四、流表设计
在介绍流表相关设计之前，需要说明的是：TaaS设计中引入了br-tap桥，串接在br-int和br-tun中间，便于提供更为灵活的镜像策略，如下图所示。图中分别给出了三种流量类型，即：租户流量、本地镜像流量、远程镜像流量。
4.1 流表项
TaaS中存在若干个流表项，如下表所示：
4.2 初始化流表
在没有创建tap service和tap flow之前，br-int上是没有任何与taas相关的流表项，而br-tap和br-tun上在agent driver启动时会下发与taas相关的初始化流表项，这些初始化流表项如下所示：
- br-tap初始化流表
- br-tun初始化流表
4.3 本地镜像
如上图橙色虚线所示，VM1的收发流量被镜像到本地的MON虚拟机中，MON虚拟机里面安装有特定的流量分析软件。因为是本地镜像，所以涉及到所有动态的taas相关的流表(这里称初始化流表为静态的)都安装在Compute1节点上的OVS，Compute2在这暂时不关注。
- 创建tap service
创建tap service，其关联的destination port为MON虚拟机对应的neutron port。创建好tap service之后，br-int、br-tap、br-tun上会动态添加一些与taas相关的流表项，具体如下：
- br-int
下面流表中，port_vlan_id为MON虚拟机关联的neutron port所属的内部vlan id值，ovs_port_id为MON虚拟机关联的neutron port对应在br-int桥上的ofport值。taas_id为tap serivce关联的专用ID值，在内部用作VLAN值，在外部用作VNI使用。下面这条流表意义：从br-tap收到流量后，将vlan值修改成MON虚拟机关联的内部VLAN值，再送给MON虚拟机。
- br-tap
- br-tun
- 创建tap flow
创建tap flow，其关联的source port为VM1虚拟机对应的neutron port。
创建好tap flow之后，br-int、br-tun上会动态添加一些与taas相关的流表项，具体如下：
- br-int
- br-tun
下面我们将对照下图再详细描述下本地流量镜像的匹配流(以VM1出方向的流量为例)。
第1步：VM1发出的流量，匹配taas相关流表，给报文打上VLAN ID=taas_id，再从patch-int-tap出去；
第2/3步：br-tap从patch-tap-int接收到VM1的镜像流量，匹配流表，将报文从入口反射回去，即：从patch-tap-int端口送回；
第4步： br-int从patch-int-tap接 收到VM1的镜像流量，将报文VLAN值修改为MON虚拟机所关联的内部VLAN值，之后将镜像流量送入MON虚拟机。
4.4 远程镜像
如上图绿色虚线所示，VM2的收发流量被镜像到远端的MON虚拟机中，MON虚拟机里面安装有特定的流量分析软件。
无论是Compute1还是Compute2节点上的OVS桥，都拥有相应与TaaS关联的初始化流表，这些初始化流表和4.3节所述一致，这里就不再赘述了。
- 创建tap service
创建tap service，由于关联的destination port处于Compute1节点上，因此，创建tap service后产生的与TaaS关联的动态流表只有Compute1节点上的OVS桥才有，Compute2节点上并没有这些流表项。这些流表项和4.3节所述是一致的，这里就不再赘述了。
- 创建tap flow
创建tap flow，由于关联的source port处于Compute2节点上，因此，创建tap flow后产生的与TaaS关联的动态流表只有Compute2节点上的OVS桥才有，Compute1节点上并没有这些流表项。这些流表项和4.3节所述是一致的，这里就不再赘述了。
下面我们将对照下图再详细描述下远程流量镜像的匹配流(以VM2出方向的流量为例)。
第1步：VM2发出流量到达br-int，匹配taas相关流表，给报文打上VLAN ID=taas_id，从patch-int-tap口送出；
第2步：br-tap收到VM2的镜像流量，匹配流表，发现destination port不在本地(没有动态生成的table=1流表项，因此判断不在本地)，于是将流量从patch-tap-tun送出；
第3步：br-tun收到VM2的镜像流量，匹配流表，送到table=30的流表项继续匹配。table=30表项是通过学习动态生成的单播表项，如果没有学习到任何的单播表项，则会转到table=31(泛洪表项)进行广播泛洪。这里假设没有学习到任何的单播table=30流表项，因此选择广播泛洪，封装报文为VXLAN，VNI为报文的VLAN ID值，而报文原有的VLAN ID值修改成1，接着从所有的VXLAN端口中泛洪出去；
第4步：br-tun收到镜像流量后，走到table=4匹配，将报文的VLAN值暂存到寄存器reg0中(有分类表table=35作进一步分类)，将报文的VLAN值修改为VNI值，送入table=35作进一步分类。这一步流程详细可以参考下图的Pipeline(只给出与taas相关的匹配表)。
第5步：将流量反射给source port，具体参考上图的Pipeline；
第6步：source port所在host的br-tun接收到反射流后，学习单播表项，具体参考上图的pipeline；
第7步：br-tap接收到VM2的镜像流后，从patch-tap-int端口送出；
第8步：br-int接收到VM2的镜像流后，修改报文的VLAN值为MON虚拟机关联的内部VLAN值，最后送入MON虚拟机。
五、总结
TaaS为云平台里的租户流量可视化提供了一个良好的服务，不过由于TaaS的设计是基于In-Band的，因此镜像流量会在一定程度上占用业务流量的带宽。同时，多个source port的流量都镜像到单个destination port会给destination port带来太大的负担。除此之外，当前实现的TaaS还无法对source port的流量做进一步精细化的区分镜像，默认所有的流量都会被镜像到destination port，这些都是TaaS后续需要考虑优化的地方。
