【Nova】nova-conductor学习

nova-conductor是nova-compute与数据库的中间件，nova-compute对数据库的CRUD操作都借由nova-conductor完成，nova-conductor通过rpc对外提供API服务。

为什么要采用这种方式，而不是由服务直接访问数据库呢？原因之一，安全；之二，方便升级，将nova-compute与数据库解耦出来，当数据库schema升级时，只要nova-conductor依旧兼容原始API，那么nova-compute即使不升级也能正常工作；之三，性能，目前我使用的Icehouse版本的nova-compute使用的协程模型实现并发，但是mysql驱动不兼容协程，导致协程会阻塞在数据库操作上，无法实现真正的并发；但是通过rpc调用nova-conductor就可以实现非阻塞调用，继而提升并发性；这一点有待考证？

nova-conductor默认采用多进程运行，在不配置[conductor]worker的情况下，进程数会与服务器的逻辑CPU数一致。

在nova-conductor中有一个ConductorManager类，该类封装了要使用的对数据库进行操作的方法，譬如获取特定uuid的虚拟机实例、对虚拟机实例信息进行修改、获取指定计算节点上的虚拟机实例、获取指定虚拟机实例的安全组等。该类的实例会作为endpoint来创建RPCServer，对应的RPCClient只需要传递请求上下文、要调用的方法名及参数即可进行远程过程调用并接收响应。

nova-conductor默认使用sqlalchemy这个ORM框架对数据库进行操作。

由于nova-compute的数据库操作全部压在nova-conductor上，那么当大规模部署时，nova-conductor就会成为影响系统性能的瓶颈，我们可以运行合适数量的nova-conductor来缓解该问题。nova-conductor使用oslo_messaging这个库来构建rpcserver，oslo_messaging是openstack官方独立出来的一个依赖库，用来对各种消息队列进行抽象封装，以统一的接口来提供对rpc和notifications的支持。

根据nova-conductor的原理，我构造了2个target的topic一样的rpcserver，底层使用的rabbitmq，然后构造了一个rpcclient进行call和cast调用，可以发现一次调用，仅有一个rpcserver会接收到指令并指令，这进一步验证了多nova-conductor避免单点问题的可行性。奇怪的是，在icehouse版本上测试时，rpcclient在call调用时会发生core dump，原因未知；在kilo版本上则没有问题，原因有待进一步发现。