OpenStack大规模部署详解( 四 ) _虚拟

2. 分配网络失败导致创建虚拟机失败
解决了上一个问题后，发现仍然创建虚拟机失败，虚拟机一直堵塞在状态直到变成error状态，在计算节点调用virsh list命令发现其实虚拟机已经创建成功，只是状态为pause 。Nova-现场日志如下:
2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [req-c2854f9b-9b00-45da-a2dd-561a3194c45d a8bfa47e180c41089e4232e76b16ac04 42e34b92273249ff9be85ef3d4fd38b8 - - -] [instance: 6a7377f5-86ac-4767-9110-29085de44e00] Failed to allocate network(s)2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00] Traceback (most recent call last):2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00]File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1920, in _build_and_run_instance2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00]block_device_info=block_device_info)2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00]File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2596, in spawn2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00]post_xml_callback=gen_confdrive)2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00]File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4858, in _create_domain_and_network2016-12-30 00:56:43.078 84245 ERROR nova.compute.manager [instance: 6a7377f5-86ac-4767-9110-29085de44e00]raise exception.VirtualInterfaceCreateException()
通过源码发现，正常流程下，创建虚拟机时，完成虚拟网卡初始化后会通过机制发送通知到消息队列中，会默认一直等待虚拟网卡初始化成功的事件通知。在多Cell环境下，因为Cell只是Nova的概念，其它服务并不能感知Cell的存在，而Nova的Cell使用了自己的消息队列，服务发往的是公共消息队列，因此Nova-将永远收不到通知，导致等待事件必然超时，Nova误认为创建虚拟网卡失败了，因此创建虚拟机失败。和CERN同样遇到了相同的问题，解决办法为设置l为false，表示忽略消息等待超时问题，继续执行后续步骤。另外需要设置等待的超时时间，因为我们已经确定肯定会超时，因此设置一个较短的时间，避免创建虚拟机等待过长，设置为5秒，可以作为参考。
3. nova show查看虚拟机的与计算节点实际名称不一致。
这是因为默认模板为-x % id，其中id为虚拟机在数据库中的主键id(注意不是UUID)，它是自增长的。比如id为63，转化为十六进制为3f，因此为- 。在多Cell情况下，Top Cell保存了所有的虚拟机信息，而子Cell只保存了其管理Cell的虚拟机信息，保存的虚拟机数量必然不相等，因此同一虚拟机保存在Top Cell和子Cell的ID必然不相同。而我们使用Nova API获取虚拟机信息是从Top Cell中获取的，因此和虚拟机所在的 Cell中的不一致。解决办法为修改te值，使其不依赖于id值，我们设置为虚拟机UUID 。
4.后端存储问题
当部署小规模集群时，我们通常都会使用Ceph分布式共享存储作为的存储后端，此时、Nova和是共享存储系统的，这能充分利用RBD image的COW(Copy On Write)特性，避免了镜像文件的远程拷贝，加快了创建虚拟机和虚拟块设备的速度。但当规模很大时，所有的节点共享一个Ceph集群必然导致Ceph集群负载巨大，IO性能下降。因此考虑每个Cell使用独立的Ceph集群，Nova和共享Ceph集群，是所有Cells的公共服务，需要单独部署并对接其它存储设备。由于和Nova不是共享存储了，因此创建虚拟机时就不能直接Clone了，而必须先从下载Base镜像导入到Ceph集群中。创建虚拟机时，首先看本地Ceph集群是否存在base镜像，存在的话直接Clone即可，否则从远端中下载到本地并导入到Ceph集群中，下次创建虚拟机时就能直接Clone了。存在的问题之一时，目前RBD Image 并没有实现缓存功能，因此需要自己开发此功能。问题之二，如何管理Cell内部的Ceph镜像缓存，镜像已经删除后，如果本地也没有虚拟机依赖，则可以把Base镜像删除了，这需要定时任务来清理。问题之三，创建时如何保证和虚拟机在同一个Cell中，因为不同的Cell是不同的Ceph集群，挂载就会有问题，其中一个可选方案是通过 Zone(AZ)来限制，此时用户在创建虚拟机和时都必须指定AZ，当用户需要挂载到其它Cell的虚拟机时，必须先执行迁移操作。