openstack HA 环境中批量创建虚拟机（boot from image & create a new volume） 的bug （2）

本篇介绍bug调查过程。中间涉及到nova配置/haproxy配置/mariaDB配置。

======================

接上文。首先查看nova-compute.log, 发现_await_block_device_map_created这个函数raise Exception的。

下载nova源码来看看（也可以直接看openstack环境中的源码，不过查上下文就不方便了。）

了解nova创建boot from image & create a new volume这种类型的Instance时，创建volume的api请求就是由nova-compute提交的。

过程是_prep_block_device() 创建volume，然后由_await_block_device_map_created检查是否成功创建。

首先就想，会不会是因为_await_block_device_map_created等待volume创建完成的时间不够长，超时导致错误呢？

查询代码发现_await_block_device_map_created使用block_device_allocate_retries和block_device_allocate_retries_interval控制等待时间：

block_device_allocate_retries ：重试次数

block_device_allocate_retries_interval ： 两次重试之间的间隔时间 单位s

找到参数就好办了：修改nova.conf文件（只用修改compute节点就行。controller节点的nova.conf不用修改），改成

改成如下样式：

block_device_allocate_retries = 10

block_device_allocate_retries_interval = 10

重启nova-compute ， 发现问题照旧。

但是每次测试时Error Instance平均数量减少，说明还是有效的。只不过还有其他问题，继续调查。

接着调查cinder api的log（controller节点上的），检查nova compute提交的create volume请求log，果然发现问题了。

create volume的请求log如下：

2016-04-19 14:34:28.566 29548 INFO cinder.api.openstack.wsgi [req-8f767998-3492-4a65-aaa8-097c29e696e6 acf3e77478c44f5892c345ce44158889 4399216c4fd945039901df0ee5ba6fb0 - - -] POST http://192.168.210.132:8776/v2/4399216c4fd945039901df0ee5ba6fb0/volumes
2016-04-19 14:34:28.570 29548 INFO cinder.api.v2.volumes [req-8f767998-3492-4a65-aaa8-097c29e696e6 acf3e77478c44f5892c345ce44158889 4399216c4fd945039901df0ee5ba6fb0 - - -] Create volume of 2 GB

2016-04-19 14:34:28.794 29548 INFO cinder.volume.api [req-2aad9380-fc45-432e-a6b9-e8287d026bf0 - - - - -] Availability Zones retrieved successfully.

2016-04-19 14:34:29.595 29548 INFO cinder.volume.api [req-019b1ef2-7ee1-4a3f-8112-709a880948d9 - - - - -] Volume created successfully.

其中第一行的 "POST http://192.168.210.132:8776/v2/4399216c4fd945039901df0ee5ba6fb0/volumes" 就是nova compute提交的request。

现在有7个instance，那么应该有7个如上的请求。可是log中竟然只有6个！

最初我猜测会不会是因为nova compute提交的请求在通过rabbitmq mirrored queue的时候丢失了。

后来请教高人，答曰这种api调用请求不走queue，而是直接被提交到对应api server端的。

因为我的环境是HA，所有http 请求都是会走haproxy进行转发，所以判断是haproxy转发出现问题。

检查haproxy配置文件，发现转发方式是"source" (根据源IP来进行转发，具体信息请百度)。 估计应该是负载过大导致丢包？（可是也就是7个请求而已，算大么？）

不管了，死马当作活马医，改成"roundrobin"。 重启haproxy服务后，发现POST请求不再丢失 （-_-!!)

但是，这只是解决了create请求不丢失。 后续测试，发现虽然volume数量可以跟instance一一对应了，但是部分volume在创建过程中失败。

查询log发现无法从db中查询到该volume id。（大概创建流程是 ：接收api请求 => 写db = > 分析quota => 创建volume， 其中volume id在写db的过程中生成。具体cinder volume 分析可以参考http://blog.csdn.net/gaoxingnengjisuan）

于是判断是写数据库出现问题。

我们的数据库用的是galera, 猜测估计是缓存原因：因为3台controller都是master，都能写db。但是缓存只存在每台controller的内部，没有共享。

修改/etc/my.cnf.d/galera.cnf中的innodb_flush_log_at_trx_commit参数

innodb_flush_log_at_trx_commit=0 （默认为1：作用是只有数据commit之后，才会写入硬盘。改为0就是每秒自动写入硬盘。该值还可以为2.但是osp官网也建议设置为0）

重启galera，volume创建再也不报错了~

至此该bug总算解决了。后续调试过程中还有些其他优化选项：

1. haproxy的galera的timeout时间设置的大些。比如90m

2. nova-consoleauth service在Active/Active的HA环境中有问题，只能设置成Active/Passive （该问题后续会另起一篇分析）