序言
本次将三言两语对openstack中ovs相关的二层网络服务泛泛而谈，以提供整体而不失真的认知。
主题
1.neutron-server的作用
2.neutron-openvswitch-agent的作用
3.neutron-server跟neutron-openvswitch-agent之间的关系及基本运作
正文
1.neutron-server
众所周知，neutron是openstack中一个很重的的服务组件，用于提供虚拟化的网络服务。因此，理解openstack的网络功能是如何从“肉眼可见的网线网桥”转型成“隐形”的服务支撑一台台肉眼不可见的虚拟化计算机（virtual machine）的通信对于理解网络虚拟化很有必要。
neutron-server，从名字上可以认为，它是提供neutron网络服务的服务器。任何有网络需求的个体发出的请求都会发给这样一个server进行网络请求。在openstack中，neutron-server变成了接受请求、汇总请求、调度请求的老板。有请求，必有响应，但实际的网络请求并不由neutron-server全权完成（没有会自己撸袖子写代码的管理啵）。因此，在neutron服务中，真正对各种网络请求做出动作响应的是各种agents。而本次要侃的openvswitch-agent便是使用最多的二层agent。（如果知道二层服务具体含义的，可以参考OSI七层模型深入理解一下）
2.neutron-openvswitch-agent
在介绍agent之前，不妨介绍一下底层实际提供二层通信服务的“劳苦百姓”–openvswitch（ovs）。如其名，这是个switch（交换机），不同于家里机房看到的铁壳子大块头的设备，这是个开源（open）的虚拟（virtual）的交换机（软件）——在无形的虚拟机世界里，它扮演无形的交换机，连接虚拟机让彼此通信；在实际真是连接网络的世界里，它以软件形式绑定实际存在的网卡，表现为网线之间、设备之间真实存在的网络。
而像openstack这类整体概念很强的平台，不可能提供一个网络服务还需要人为手动全装配置一个其他的开源软件来实现二层网络的通信，因此，neutron项目组写出来这么个neutron-openvswitch-agent的程序对ovs进行管理（增加删除虚拟端口、创建vlan、决定转发策略等等）。因此，neutron-server –> neutron-openvswitch –> ovs俨然成了“老板–经理–码农”的角色。
3.server跟agent之间的关系及运作方式
从上述，粗略画出如下结构图：
server对于获得请求，通过跟ovs-agent消息交互对ovs进行配置，并将相关信息（虚接口、网段等）写入neutronDB数据库中。
显然这么粗浅的东西，说了是没有意思的。下面结合很少的代码部分介绍两者之间的运作配合。
不妨设想一下，neutron的二层服务启动时，要对ovs进行配置啥的，起码要知道人家好好的ovs上已经有了啥、还缺啥、要补充啥信息——因此，设计了一个叫ovs-agent初始化的动作。
（盗一张香港会议的图）
其他暂且不用深入那么细节，直接理解思路7、9——初始化之后agent会向server请求已有的网络设备（device就可以简单理解为配置的虚拟端口啦）的详细信息来对ovs进行管理，之后对ovs上的device信息提交给server进行更新。（有兴趣研究ovs-agent初始化获取设备信息的同学可以参考neutron-server端代码：/usr/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py中get_devices_details()方法）
在ovs-agent启动初始化之后，在neutron-server跟ovs-agent频繁交互message周期检测ovs上的端口状态（可以在ovs-agent端tail -f /var/log/neutron/openvswitch-agent.log看到周期交互的相关细节）。在周期检查的背后，实际上是ovs-agent代码进入主函数之后持续进行rpc_loop()循环状态检查、更新（有兴趣可以参考代码/usr/lib/python2.7/site-packages/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py中主函数rpc_loop（）部分）。