一、概述
天翼云自研的SDN控制器需要对接OpenStack Neutron网络，这就需要用到Neutron的ML2(Modular Layer 2) 插件机制，Networking-controller就是作为SDN控制器的驱动程序，实现了Neutron L2和L3的API的请求数据转化并转发到后端的自研SDN控制器。
二、功能介绍
Networking-controller 作为OpenStack Neutron的一种driver连接OpenStack 和SDN控制器，主要提供以下功能：
2.1 Neutron ML2机制驱动
Networking-controller是Neutron ML2 Mechanism Driver(机制驱动)的一种具体实现，遵循ML2的网络技术架构实现了precommit 和postcommit方法来操作网络资源，如network, subnet 和port的创建、删除和更新。ML2的技术架构如下图：
ML2技术架构图
机制驱动暴露方法的规则为action_resource_precommit 和action_resource_postcommit。Precommit 主要验证resource 的操作合法性并记录请求元数据到数据中。Postcommit 方法主要负责操作资源，并且把资源的变化同步给后端Backend, 但该机制驱动其实没有具体实现。
2.2 Journal机制
Journal机制操作流程图
- 该机制驱动的重要功能就是journal机制，把OpenStack Neutron请求过来的元数据记录在一个journal库表中，而不是直接把OpenStack的请求数据传递给后端控制器。
- Journal机制的通过异步处理来转发数据到后端，前面的precommit操作会把数据先记录到journal 表中， 后续后起一个定时任务器Periodic Task Processor,该主进程会去启动一个journal thread,周期性的监测journal表中数据的变化，按时队列Queue的特性一条一条(journal entry)处理数据,发送请求到SDN控制器的北向接口。
- Journal表提前记录了数据，这样当同步失败或是两端任一服务器故障都不会造成数据的不一致，保证了资源的同步。
- Journal机制的多线程的，网络资源请求会分隔成多个journal entry,如subnet创建会有 subnet创建和port创建的Journal entry，所以当前端压力大的时候，后端的请求会成倍增加，多线程的实现保证了压力下的稳定运行。
- Journal entry的状态管理，包含有四种状态：pending、processing、completed和failed。
- 新建journal entry 状态为pending；
- 一个journal thread 选中(先进先出原则)entry后，状态置为processing, entry是非线程安全的，要进行加锁；
- 线程把entry转化为REST call,发送到后端控制器，请求成功后，状态置为completed；
- 如果请求失败，对于预料之中(网络连接，控制器主机宕机或是服务中止)的错误状态重新置为pending,对于预料之外的错误，会retry 5次(默认值，可调)，仍失败状态置为failed。
Journal状态管理流程图
从上图我们可以看到会遗留一种状态failed没有处理，这又引出下面maintenance机制中的recovery操作。
2.3 Maintenance机制
严格说，maintenance机制也属于journal机制的一部分，这里先这样划分。
上面说到的Periodic Task Processor同样也会启动一个Maintenance线程，来执行4种任务：delete completed、cleanup processing、journal recovery 和full sync。
- Journal recovery
接上文先来说一下journal recovery任务，主要就是处理状态为failed 的entry。失败的entry就一直会存在journal表中，积累大量的失败的entry会对性能的影响很大。
Journal recovery 流程图
- Delete completed
这个任务还是比较好理解，就是定期把状态为completed的journal entry 清理掉。
- Cleanup processing
如果entry正在处理过程中遇到宕机或是程序意外中止，都会屋entry的状态停留在processing，如果状态不及时更新，这些entry就会一直得不到处理，Cleanup任务就是定期把processing状态重置为pending，以使entry下次被正确处理。
- Full sync
这里用到了金丝雀(Canary)测试的原理来同步journal表和控制器端的资源是否一致，不一致则进行资源同步操作。
