验收easystack escloud云平台运维手册

1、1.1.1rootnode-1NovaNova计算虚拟检化查组service-list件状态#nova根据输出，查看 Se 是否存在 down 的情况，如果没有证明整个集群工作正常。如果有 down 的情况需及时进行处理。Nova 服务 down 掉，不会影响虚机运行， 但对相关物理机上的虚机操作会有影响（如开关机，迁移等等）。可尝试重启相应服务。1.2 Nova 常用命令列出可用的实例nova list -all-tenantnovalist-all-tenant-hostnode-4.tld查看实例详细信息nova show testvm01列出可用的 flavornova flavor-

2、list定制 flavor，flavor name=test500 flavornova flavor-create test500 500 512 1 2id=500ram=512Mbcpu=2创建一个vm实例先获取 flavor idnova flavor-list |grep 500获取 image id glance image-list获取网络 id neutron net-list创建 vm 实例 testvm01nova boot -image f911dbae-aaee-4969-8b99-c535d6e18eaa -flavor test500 -nic net-id=b21

3、a53d6-b4c0-4e49-ac78-50a8d66c310f testvm01注释：-image 后面加镜像 UUID，使用 glance image-list 查看-flavor 后面加 flavor 的 UUID，使用 nova flavor-list 查看，也可以新建 flavor-nic net-idsubnet后面加网络 UUID，使用 neutron net-list 查看， 主要是 net，部署-availability-zone 如果不指定由 nova-scheduler 根据策略自动指定主机部署，默认是 nova。可以通过 zone_name:node-name 将虚拟

4、机部署到指定的主机上面，比如：ernal_Zone:node-11.tld前面是 zone 名称，后面是宿主机的主机名先查看未分配 ip，然后分配 floating ip 到实例先获取未使用的 floating ip 地址neutron floatingip-list然后获取 nova 的 idnova list将指定的 floating ip 指定分配给指定的 novanova floating-ip-asste 8919cdf8-25c3-4488-b9ee-fa9580e49b5034创建一个实例的快照获取实例的名称 testvm01nova list创建实例的快照 testvm01_s

5、1nova image-create testvm01testvm01_s1启动/关闭/删除一个实例获取实例的 idnova通过指定实例 id 启动实例nova start 3f84a737-e26b-4cee-a5d9-ff44d9458172通过指定实例关闭实例listgnova stop 3f84a737-e26b-4cee-a5d9-ff44d9458172通过指定实例 id 删除实例nova delete 3f84a737-e26b-4cee-a5d9-ff44d9458172Nova 常见问题Nova 服务相关问题A.Compute服务down Nova-cert，nova-put

6、e 服务。nova 服务分布在控制节点和计算节点上。 其中控制节点上有consoleauth，nova-scheduler，nova-conductor， 计算节点上只有其中控制节点上 nova 服务 down 掉的几率不大。 计算节点pute 服务 down 掉时，先 检 查 相 应 节 点 的 网 络 连 接 ， 确 认 管 理 网 络 正 常 。网络检查正常后，可尝试 ssh 至问题节点， /etc/init.duterestart 来尝试重启pute 服务。 此操作不会影响正在运行的虚机。注：导致pute down 的原因还有可能是 ceph不可、rabbitmq 有异常、ntp 时间

7、不同步等原因，一般云时 ， 根 据 /var在运行过程中，这些条件不会触发，当出现异常puog日志信 息定位 问题。B.Compute服务无法重启us有时会在重启pute 服务后，可执行/etc/init.dute来确认服务是否正常启动。 如果现实有 progress is not rugnning butx is running.则服务正常。file exist 的 报 错 。 此 时 需 要 删 除再次重启即可。 如果还有问题，请检查系统/vaute.文件，rsyslog 服务，一般出现这种情况，都是由于系统 rsyslog 服务卡死，先重启 rsyslog 服务后，再检查 compute

8、 服务。注：rsyslog 出现异常时，除了导致pute 有异常之外，还有可能会导致neutron 的一些服务异常，如 neutron-dhcp-agent、neutron-l3-agent，解决的方法是确保 rsyslog 服务正常，之后再重启有故障的服务。1.3.2 虚拟机操作问题A .部署，迁移，调整虚机失败有时，由于某些原因，虚机在迁移，修改大小后报错，虚机状态为”error”， 可用下列命reset-令回-active复其状机态uuidnovae nova-conductor.lognova-scheduler.log 如果都没问题，则检查相应计算节点上的puog。B. 创建虚拟机失

9、败创建虚拟机是一个复杂的操作，涉及到 openstack 很多的服务。当用户提交创建虚拟机的请求时，请求首先会到达 nova-api 服务，nova-api 会用户的请求，随后调用pute 完成虚拟机的创建工作。在创建虚拟机的过程中，pute 会调用glance 获取镜 像，调用 neutron 创建网卡，调用 cinder 挂载 volume，调用 ceph 创建系统盘。任何一个步骤失败都会导致虚拟机创建失败，所以，在排除虚拟机创建失败时，需要了解 openstack 的总体架构，熟悉 nova 创建虚拟机的流程，然后根据虚拟机的状态及 nova 服务的日志判断创建虚拟机 的操作执行到哪步失

10、败了。创建虚拟机的过程中调度失败故障描述: 执行虚拟机创建操作之后，很长时间虚拟机还在“创建中”。虚拟机创建的过程中，需要 nova-scheduler 服务确定在哪个物理服务器上运行刚刚创建的虚拟机，如果 nova-scheduler 服务不响应调度任务，则虚拟机可能一直处于scheduling 状态。# source /root/openrc# nova show （注意：虚拟机 uuid 要用具体虚拟机的 uuid 替换）如上图所示，有几个关键的字段可以帮助下：判断具体的原因。这几个关键字段的含义如字段字段含义Sus在浏览器里面，用户看到的状态。sus 是虚拟机task_se、vm_se

11、、er_se 综合起来的结果。OS-EXT-STS:task_senova 管理服务正在对虚拟机执行的操作。如果为-，则表示没有人在管理此虚拟机。OS-EXT-SRV-ATTR:host虚拟机所在宿主机的 hostname。如果为-，则表示虚拟机还没有确定，一般在刚创建虚拟机的过程中，调度器还没有完成调度时会显示为该状态。如果 OS-EXT-STS:task_se 为scheduling， 而且 OS-EXT-SRV-ATTR:host 为-，则表示还在等待调度程序确定运行虚拟机的宿主机。由此可以判断 nova-scheduler服务出问题了。如果调度没有问题，或者没有可用的宿主机，调度程序都

12、会很快返回，不会一直停留在scheduling的状态。解决问题出现上面的故障有两种可能性，一种是整个集群没有可用的 nova-scheduler 实例；另一种是 nova-scheduler 服务出问题了。对此，首先要查看整个集群是否有 nova- scheduler 服务在运行。查看方法如下：Nova service-list | grep scheduler整个集群至少需要一个 nova-scheduler 实例处于up状态。需如果集群中至少有一个nova-scheduler 实例的状态是up的，就需要查看查看 nova-scheduler 的日志来进一步确定原因了。到控制节点上，查看/v

13、ar/log/nova/scheduler 日志。tail -f /var/log/nova/schedulernova-scheduler 服务不能正常工作最常见的一个原因是连不上 RabbitMQ 服务，或者能连上就是不消费队列中的消息。为此需要查看消息队列中 nova-scheduler 服务未消费的消息数目。具体方法是在控制节点上执行下面令：如上图所示，上面令输出的第二列是队列未消费的消息数量，第一列是队列的名称。nova-scheduler 服务使用的队列名称是以scheduler开头，每个 nova-scheduler 会两个队列，一个是 scheduler.server-xx 表

14、示这个实例运行在server-xx 上面；另一个是 scheduler_fanout_xx 这个队列是用来接收调度服务的广播消息。如果这些队列中的消息数量一致大于零，就表示队列中的消息没有人消费。可能是网络连接，也可能是 nova- scheduler 服务本身。对于这种情况，可以重启下 所有的 nova-scheduler 实例看看问题是否能得到解决。具体如下：/etc/init.d/openstack-nova-scheduler restart创建虚拟机过程中报 NoValidHost执行虚拟机创建操作之后，虚拟机的状态没有变为“运行中”，而是变为了“错误”，用 nova show 查看

15、虚拟机状态，发现关键字 NoValidHost登录控制节点，执行下面 # source /openrc# nova show 令显示虚拟机的详细信息：（虚拟机 UUID 是创建失败的虚拟机的 UUID）如上图所示，关键信息是 fault 字段中包含了 No valid host was found 这样的信息。如果出现这类关键信息，可以参考下面的解决办法。上面的错误信息是 nova-scheduler 服务返回的，表明上的意思是没有可用的宿主机，也就是说请求的资源太多了，现在集群中没有哪个宿主机有那么多资源，所以请求失败。由于 nova-scheduler 会封装为了确定确切的原因，可以通过如

16、下pute 所遇到的错误，所以上面的消息不一定准确。令来查看整个集群的资源占用情况。#+nova hypervisor-ss+|+Property|Value |+|+count current_workload disk_available_least free_disk_gb free_ram_mblocal_gb local_gb_used memory_mb memory_mb_used running_vms vcpusvcpus_used|2| 01226|1702| 43522| 100|204801802|64002|5|1144|+上面令可以显示集群总体的资源使用情况。相关字

17、段的含义如下：字段名称字段含义memory_mb所有宿主机内存总量memory_mb_used已经分配给虚拟机的内存总量；openstack 允许内存复用比大于一，所以，这个值可能比 memory_mb 还大vcpus所有宿主机中 cpu 数量（总线程）已分配的虚拟机的 vcpus 总量；openstack 允许 CPU 复用比大于一，所以，这个值可能比 vcpus 还大vcpus_usedrunning_vms已经创建的虚拟机的总数，包括关机状态的虚拟机以及命令；nova hypervisor-shownode-x.tld 来查看单台服务器的使用情况。如果集群系统不够用了，上面统计的已经分配

18、给虚拟机的 vcpus & 内存应该都比较高。否则的话，有可能是pute 上某些操作执行失败了。默认情况下，调度器会尝试三次，在不同的宿主机上运行虚拟机，如果都失败，也会报 No valid host 的错误。 pute 创建虚拟机失败可能有很多原因，可能是调用 ceph 创建系统盘失败，也可能是调用 neutron 创建网卡失败，也可能是 虚拟化层的错误。对于这种情况，需要进一步查看pute 及相关服务的日志确定具体的原因。具体方法如下：# catpuog | grep -v INFO |grep -v AUDIT | less的情况，强行部署虚机。 可在其实，也可以不使用某些 filter

19、， 如忽略掉内存/etc/nova/nova.conf文件中修改下列配置：创建虚拟机过程中申请内存失败执行虚拟机创建操作之后，虚拟机的状态没有变为“运行中”，而是变为了“错误”，用 nova show 查看虚拟机状态，发现关键字 Cannot allocate memory.由于 openstack 允许的内存复用比是可配置的，而且可以大于 1，所以，有的时候物理机的可用内存可能所剩无几，但是 nova-scheduler 可能仍然会将虚拟机调度到该物理机运行。当pute 调用底层的虚拟化组件运行虚拟机时，虚拟化组件可能会因为申请不到足够的内存而失败。如果是这种原因导致了创建虚拟机失败，那么在

20、虚拟机状态、pute 的日志、libvirt 的日志中都会相关的错误。所以，还是比较好定位。查看pute 的日志，可以看到类似的错误。具体操作如下：5792957c-7935-422a-bd72-7da744c731cb Cannot set up guest memory pc.ram:Cannot allocate memory2015-12-08 14:16:22.726 117355 TRACE5792957c-7935-422a-bd72-7da744c731cbpute.manager instance:如果有这种日志，就可以确定是因为创建虚拟机失败的原因是内存。如果创建虚拟机因为

21、内存而失败，需要检查是不是虚拟机所请求的内存太大了。如果不是，可能是因为集群内存使用率已经比较高了。这时候，需要检查所有计算节点的内存占用情况。如果总体内存占用比价高，就需要空闲的资源，或者进行扩容了。另外如果创建出来的虚拟机如果都是运行比较耗内存的业务，最好将内存的复用比调低。具体的方法是修改计算节点的配置文件，调整 DEFAULT section 下面的 ram_allocation_ratio，将其设置为 1.0 或者更低（因为其他服务也需要消耗内存）。具体如下：# cat /etc/nova/nova.confDEFAULTram_allocation_ratio = 1.0修改完配置

22、之后，还需要重启pute 才能生效。C. 虚拟机 live-migration 无法完成如何迁移虚机：1. 确定要迁移的虚机，nova show 获取虚机的 uuid，虚机所在的计算节点，虚机的名字（比如 instance-0000004c）。2.3.4.找一个可以迁移上去的计算节点。在 dashboard 上做热迁移。在虚机原来的计算节点上执行如下命令查看迁移的进度，比如下面是迁移一个 128G 内存的虚机，可以看到刚开始 Memory remaining: 127.994 GiB。rootnode-7 #Job type: Time elapsed:virsh domjobinfo ins

23、tance-00000183Unbounded7803 ms8.961 MiBData prosed:Data remaining:127.994 GiB128.008 GiB 8.961 MiB127.994 GiB128.008 GiB 1106263810.305 MiBDa Memory MemoryMemoryotal:prosed:remaining:total:Constant pages: Normal pages:Normal data:Expected downtime:30ms一直使用上面命令查看 Memory remaining，如果虚机内存变化太快，Memoryrem

24、aining 基本会减少到几百兆左右以后，一直上下浮动，这样的话，虚机都迁移不完，这时，使用命令 virsh suspend 将虚机暂停一下，那么虚机在几秒之内就很快迁移完成。这样的话，虚机暂停的时间就可以控制在几秒内。对业务也就只有几秒钟的影响。 上面的 128G 内存虚机在 12 分钟迁移完成。如果迁移时间太长，会导致 nova 更新虚机迁移后的状态超时，这时需要手动更新nova 数据库。Nova reset-s e -active -e use nova; update instanwhere uuid=set node=,host=1.3.3 VNC 常见问题为方便用户登录和管理虚拟机

25、，openstack 提供了 vnc服务，用户通过浏览器就可以虚拟机的终端，为用户的管理提供了很大的方便。由于 vnc服务也是要多个服务相互协作才能完成，此外还和虚拟机的状态也有关系，所以也比较容易出问题。用户通过浏览器虚拟机的过程大致如下：1. 浏览器给 nova-api 发送请求，获取虚拟机的 console 的 URLa. 请求首先到达 nova-api，nova-api 再转给puteb.pute 调用底层的虚拟化接口，获取 vnc server 的地址和端，并生产一个随机的 token，并通过 nova-consoleauth 对 token 进行。一个 URL 返回给浏览c.put

26、e 将 vnc server 的连接地址和 token 组器。2. 浏览器获取 console URL 之后，连接 nova-novncproxy 服务，建立 websocket 连接a.b.c.浏览器连接 nova-novncproxy 获取静态文件、css 文件、jsjs连接到 nova-novncproxy 建立 websocket 连接nova-novncproxy 收到 websocket 连接之后，会连接 nova-consoleauth 验证用户的 token，如果 token 有效，nova-consoleauth 会返回 vnc server 的连接地址和端口。d. Nova

27、-novncproxy 建立 websocket 到 vnc server 的端口转发，一旦端口转发建立起来，用户就可以在浏览器里面登陆虚拟机了。如果pute 服务有问题，第一步就会失败，获取不了 console URL；如果websocket 建立失败，有可能是虚拟机关机了，也有可能是配置不对，也有可能是 nova-novncproxy 服务出问题了。具体的排查见下文。A. 获取 console URL 失败故障描述获取 console URL 是 VNC 登陆虚拟机时要完成的第一个操作，如果这步出错，那么VNC 登录虚拟机肯定会出错。如果遇到 VNC 登陆不了虚拟机查是否能够获取 cons

28、ole URL。，排查的第一步就是检问题定位为了确定 VNC 登陆虚拟机失败是不是无法获取 console URL，只需要登录集群控制节点，然后执行下面令就可以知道。# source /openrc# nova get-vnc-console novnc如果命令执行的结果如下：那说明获取虚拟机的 console URL 没有问题，是其他导致不能登录虚拟机，需要参考下面的文档继续进行排查。如果上面令执行结果如下：ERROR (CntException): The server has either erred or is incapable ofperforming the requested

29、operation. (HTTP 500)那表示获取虚拟机的 console URL 失败了。问题解决如果不能获取 console URL，需要先通过 nova show 查看虚拟机所在的宿主机，然后查看对应宿主机的pute 服务的日志，根据服务日志进行后续的排查。普遍解决方法：可在三个控制节点上，均重启 nova-api,nova-consoleauth 和 nova-novncproxy 服务。/etc/init.d/openstack-nova-api/etc/init.d/openstack-nova-consoleauth/etc/init.d/openstack-nova-novn

30、cproxyrestart restartrestart之后，可在控制节虚点机上uuid执行novnc#novaget-vnc-console会直接获取到控制台的 ip 地址，直接输入至浏览器，即可打开该虚机控制台。1.3.4 Hos配置修改控制结点配置文件rootnode-1 easystack# vi /etc/easystack/ DEFAULTuse_rpc=Falsedebug = False.conflog_file = inspectors ganglia action_map将虚机迁移/var/log/nova/hagent.log=,ganglia#先检测，再检测s = ga

31、nglia:evacuate#hanglia检测失效，则触发 evacuate 动作，#warn_inspectors=ipmi#warn_action_maps=ipmi:livemigratecheck_erval = 5on_shared_storage = TrueAuthusername整 passwordauth_url=admin#admin如果修改，记得调=adminproject_idganglia= admingmetad_host = gmetad_port =max_reported_8651erval = 20 #测试可以用 20，生产环境需要调大如 60，提高判断率

32、packet_count = 1wait_deadline = 3#调大 提高判断准确性，3# 调大 提高判断准确性,10ipmidefault_vendor = Dell retry_timeout=60mand_erval=5#IPMI 可能误判，默认不使用conf_file_path = /etc/easystack/ipmi.confmax_log_erval=3600warn_checke_methods=single_bine=aller重起服务resource restart easystack-用 ps -ef |grep确认进程存在，此进程只在三台控制节点的其中一台hagen

33、thagenthagent此 HA 只在宿主机 down 机，或者网络线路断开的情况下，正常如果网络经常抖动则容易出现问题，不建议配置在生产环境。1.3.5A.其为某 些余常用机为 其操挂挂 载作，载狗 ，配加挂 载置介密 方 式 如绍狗下 ：虚应 用 需 要有 1.2.时加 密首先，通过 nova list命令， 找到需要挂载加 密狗的虚机， 以及 其 uuid其次通过 nova show 命令，得到虚机所在的物理机，及其 instance-name如 上 图 ， 该 虚 机 在node-5 上 ，instance_name为 instance-00000413. 将加密狗插到 node-5

34、 上， ssh 至 node-5 ， 执行 virshlist -all存install， 根据instance_name确上 ，lsusb认安 装命虚usbutils机包查是否在。4.5.在使node-5用。询Yum插usbutils令，上的加密狗上图 中， Aladdin KnowledgeSystem即为 加密 狗。 记住ID 0529:00036.编辑生成usb_device.xml文件#vimusb_device.xmlvendor7.id即 为挂id的 前 半载部，product加id为 后 半 部 。密狗usb_device.xml#virshDeviceattach-devic

35、eattached sucsfullyB.虚live-migration拟机迁移应 用 。nova为迁移 ， 迁 移 过 程 中 ， 不 会 影 响Novamigrate 为冷迁移，虚机为关机状态的迁移虚拟机无法单向热迁移：node-2 是控制节点，node-1 和 node-4 是仅存的计算+节点， node-3 和 node-5 已经移除。从 node-1 迁移虚机到 node-4 正常，但是云主机从 node-4 迁移到node-1 报错，无法完成迁移。以下是node-1 的 CPU 型号和版本，可以看出是E5-2620v3以下是node-4的CPU型号，是E5-2620v2版本从上面两

36、图可以看出，两台服务器的 CPU 型号一致，但是 CPU 版本不一样，这样导致云主机从 V3 迁移到 V2 版本正常，但是 V2 的云主机可能无法迁移到 V3 的宿主机中。还有一种情况，会导致迁移失败。在 compute 日 志 中 ， 会 看 到如 下 报 错：error:ernal error Attempt to migrate guest to the same host 00020003-0004-0005-处理方法是：查看两个节点的 system-uuid 是否一样，如果一样需要修改 libvirt 的配置文件。可以通过如下令查看：rootcontroller1 # dmideco

37、de -s system-uuid查看 /etc/libvirt/libvirtd.conf 中的 host_uuid 发现该行被注释，将该注释去掉，并需要对 host_uuid 的值进行修改。在两台机器上分别用 cat /proc/sys/kernel/random/uuid的值。的值来替换原来 host_uuid2.2.CinderCinder块管理查1组件状态检rootnode-1 # cinder service-list查看 Se 列是否存在 down 的情况，如果存在需要及时进行相应处理。2.2 Cinder 常用命令1. 列出正在运行的 cinder service，查看状态ci

38、nder service-list2. 创建一个 volume，显示名称 testvol01,大小 1Gbcinder create -display-name testvol01 13:挂载一个 volume 到一个 vm 实例获取 volume idcinder list获取实例 id nova list将指定的 volume id 挂载到指定的 vm 实例 id 上novavolume-attachauto4:从 vm 实例卸载一个 volume获取 volume idcinder list获取实例 idnova list将指定的 volume id 从指定的 vm 实例 id 上卸载n

39、ova volume-detach 5:删除 volume获取 volume id cinder list删除指定 volume id 的 volumecinder delete b3c3c099-16c6-43a2-a17f-d0fc5dcf26916. 改变 volume 大小cinderb3c3c099-16c6-43a2-a17f-d0fc5dcf2691extend7. 改变 volume 状态CinderCinder常见相问题题服list务关问检查方法 cinder-service相关报错：服务状态为downCinder 服务仅存在于控制节点上， 服务 down 掉

40、的几率很小。如果配置多个 ceph 集群，则 cinder 不 能 通 过 service 方 式 重 启 ， 需 通 过命 令 重 启 。Cinder 服务 down 掉，不影响正在运行的虚机，也不影响已挂载的云硬盘， 会影响新云硬盘的创建和挂载2.3.2 云硬盘挂载，删除相关问题由于云硬盘挂载和卸载操作设计到 nova 和 cinder 两个项目，需要两个项目执行一系列操作，因此很难实现事务操作，所以如果云硬盘挂载或卸载操作执行到中途失败，就容易造成 nova、cinder、libvirt 三个地方云硬盘的挂载信息不一致。在修复云硬盘状态不一致时，应以硬盘的实际挂载状态为准，修复前，先检查

41、硬盘的实际挂载状态，然后确定 nova 和 cinder 该如何修复。因为用户可能已经挂载了硬盘，并卸载可能会影响用户的数据。数据了，冒然A. 确定并修复 libvirt 中云硬盘的挂载状态修复云硬盘状态不一致大致分三步走，第一步是确定云硬盘的实际挂载状态。为此，首先要通过nova show确定虚拟机所在的宿主机，然后，通过 libvirt工具 virsh 确定云硬盘的挂载状态。具体命令如下：令行# virshmand -hmp $(ps -ef | grep | grep -oinstance-0-9a-f8 | head -1) info block再执行下面令，看看 libvirt 中虚

42、拟机的配置文件和它是否一致：# virsh domblklist $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1)上面的例子显示：虚拟机在 libvirt 中和实际的挂载状态是一致的，虚拟机有四块硬盘，分别是 vda, vdb, vdd 和 vde，均为 ceph 设备。如果不一致，需要 dump 一份虚拟机的配置，看配置文件中哪部分是多余的。举个例子：# virsh dumpxml $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1)如上所示，一个 .之间的内容就是一个块设备的所有

43、配置信息，可以将其保持到一个单独的文件中，然后通过 virsh attach-device 或命令来动态的挂载或卸载这个块设备。如下：virsh detach-device# cat vde.xmlhosthost port=6789/port=6789/a019a901-70e6-4e74-b44e-5bdfbf9ba4bc=0 x0000 bus=0 x00 slot=0 x08# virsh detach-device $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1) vde.xml确定并修复完 libvirt 的状态之后，就可以

44、开始修复云硬盘在 nova 的状态了。B. 修复 nova 中云硬盘的状态nova 服务会将虚拟机的挂载的云硬盘信息在一张单独的表里面，这的名称是block_device_map，表结构如下：其中比较关键字段的含义如下：source_type：挂载之前的类型destination_type：挂载之后的类型connection_info：连接信息；虚拟机通过这些信息就可以挂载硬盘了deleted：是否有效instance_uuid: 云硬盘挂载到哪个虚拟机了如果挂载有问题，或者中途失败，connection_info 字段为空。在 nova 中修复云硬盘的状态很简单，只需要修改上面这个表，将没有

45、挂载成功的云硬盘对于的信息标记为 deleted就可以了。也就是说，只需要修改 deleted 字段。如下： update block_device_mapset deleted=x where id=x;修改完数据库，通过 nova show 看到的虚拟机的状态，结果应该不再显示对应的硬盘处于挂载状态了。修复完 nova 中的状态之后，就要修复云硬盘在 cinder 中的状态了。C. 修复 cinder 中云硬盘的状态cinder 中使用了两个表来云硬盘的状态和挂载信息。分别是volumes和volume_attaent。volumes 的表结构如下：volumes 表attach_s了所有

46、的云硬盘的基本信息。其中sus 表明了目前所处的状态，us 表明了云硬盘正在执行的操作。在 cinder 中修复 volume 的状态要修改这个表。将云硬盘为未挂载，具体如下： update volumes set sxx;us=available, attach_sus=detached whereid=这样，就可以修复云硬盘在 cinder 中的状态。修复完成之后，云硬盘在三个地方的状态就是一致的了。2.3.3环境介绍MultiBackend配置一个 controller 节点，一个 compute 节点两个 OSD目标： 创建云硬盘时，可选择使用不同池1. 创建新的 rbd poolce

47、ph cephcephosd osdosdpool poolpoolcreate testp 128 128set testpset testpmin_size 1size 12. 获取当前 crushmapceph osd getcrushmap -ocrush.mapcrushtool -d crush.map -o crush.txt3. 修改 crush.txt# begin tunable tunable tunable tunable # devi devicedevicecrush map choose_local_tries 0 choose_local_fallback_tr

48、ies choose_total_tries 50chooseleaf_descend_once 10osd.0osd.1# typestype type type type type type type type type typetype0123456789osd host chassis rack rowpdu podroomdenterregion10 root#可以看出，crushmap 为树形结构，根节点为type10 root ， 叶节点为这段保持默认即可。type 0 osd ，依次向下。 后面的配置实际上都是在描述这个树。host node-6 id -2# weight 0

49、.250 alg straw# do not change unnesarilyhash itemitem0 # rjenkins1osd.0osd.1weightweight0.1900.060root defaultid -1# weight 0.250 alg straw#do not change unnesarilyhash 0 # rjenkins1#item node-6 weight 0.250item osd.0 weight 0.190root testpool id -3 alg straw hash 0item osd.1 weight 0.060#以上三行是在对节点进

50、行描述。 简单解释以下， 首先定义了一个 node-6， 类型是 host，这个 host 下有两个 OSD， 分别是 osd.0 和 osd.1。 然后这个 host 属于 root default 下。由于希望将两个 osd 分开定义，所以将 root default 下的成员改成了只有 osd.0，又单独定义了一个 root testpool， 成员只有 osd.1。 # rulesrule replicated_ruleset ruleset 0type replicated min_size 1max_size 10step stepsteptake default choosele

51、afemitn 0 type osdrule testrule ruleset 1type replicated min size 1max size 10stepstep steptake testpoolchooseleaf emitn 0 type osd#这里是最后的 rule为 1， “step take将 step chooseleafset 配置， 默认的 ruleset 是 0，新定义一个 rule，rule settestpool” 说明采取 root testpool 所定义的对应关系。 注意需要n 0 type 这一项改为 OSD， 默认为 host。重新编译并应用cru

52、shtool -c crush.txt -o crush.map ceph osd setcrushmap -i crush.map修改新 rbd pool 的 rulesetceph osd pool set testp crush_ruleset 16. 进试dd if=/dev/zero of=testp.pool bs=1M count=20rados Ceph osdm(1,-p testp put testp.object testp.pool osd map testp testp.object33 pool testp (5) object testp.object - pg

53、5.24c133e (5.3e) - upp1) acting (1, p1)#可以看到，这个 object 全部写入到了 osd.1 上。7. 添加 ceph 权限ceph auth list需要为 c#查看现限nt.volumes 这个用户，添加对 testp 池 rwx 的权限ceph auth caps cnt.volumesallow r osd allow class-read object_prefixrbd_children, allow rwx pool=volumes, allow rwx pute, allow rwx pool=testp至此， ceph 配置已经完成，

54、接下来配置 cinder8. 修改 controller 上的 cinder.confpool=backups,allowrx找到enabled_backends一项，取消注释enabled_backends=osd1,osd2在末尾添加如下两项osd1 volume_driver=cinder.volume.drivers.rbd.RBDDriver rbd_pool=volumesvolume_backend_name=osd1 rbd_user=volumes rbd_ceph_conf=/etc/ceph/ceph.conf rbd_flatten_volume_from_snapsh

55、ot=Falserbd_secret_uuid=a5d0dd94-57c4-ae55-ffe0-7e3732a24455 rbd_max_clone_depth=5osd2 volume_driver=cinder.volume.drivers.rbd.RBDDriver rbd_pool=testpvolume_backend_name=osd2 rbd_user=volumes rbd_ceph_conf=/etc/ceph/ceph.confrbd_flatten_volume_from_snapshot=Falserbd_secret_uuid=a5d0dd94-57c4-ae55-f

56、fe0-7e3732a24455rbd_max_clone_depth=59. 创建 cindoerosd1 osd2cinder cinder cinder cindercindertype-createtype-createtype-key osd1 set volume_backend_name=osd1type-key osd2 set volume_backend_name=osd2 extra-specs-list#查看是否成功10. 测试先尝试用命令来创建 volumecinder cindercindercreate -volume_type osd1 -display_nam

57、e test1 1 create -volume_type osd2 -display_name test2 1list #查看在页面上尝试创建云硬盘，创建时可以选择“类型”，下拉菜单中出现 OSD1 和 OSD2，即为之前配置的不同池。用户在使用时，可以从不同池中创建云硬盘，将其挂载到相应的云主机上。 或者选择 boot from volume， 直接在需要的池上创建虚机。 P.S配置完成后，用 cinder service-list 查看 cinder 服务状态时，会发现出现了 osd1和 osd2 的 cinder_volume 服务，原本的 cinder_volume 服务状态为 do

58、wn。修改数据库的方式，将这一条 down 的消去，简化客户的管理。可以通过use cinder;select * from servi delete from servi删 除 后 ， 再 次 用;#查看该条的 idwhere id=X#删除该条cinder service-list 查 看 服 务 ， 就 全 部 正 常 了 。2.3.4 其余常用操作，配置介绍。A. 云硬盘无法挂载云 硬 盘 挂 载 时 ， 遇 到 报 错 ， 日 志 中 有 “device is busy” 信 息 。这时需要去检查 block_device_map下表，查询目标虚机的云硬盘挂载图，如：从表中可见，该虚

59、机目前已挂载了 vdb vdd vde 三块云硬盘。 再次挂载新云硬盘，执行 nova volume-attach 命令时，cinder 会自动使用/dev/vdc 的设备名，但是表中有一条/dev/vdc 的错误挂载，并且状态不为 deleted。 所以会报device。is解决方法有两个：busy错误a)b)从表中删除这条/dev/vdc 的手动在控制节点上执行挂载命令，指定设备名为/dev/vdf 即可。B.从数据库中删除云硬盘有时会出现云硬盘已经删除，但是在页面上依旧可见的情况，这时需要手动将其从数据库中删除。 主要就是删除 volumes 表和 volume_admin_metada

60、ta 中的数据：use cinder;select selectdeletewhere deleted=1 from volumes;* from volume_admin_metadata;from volume_admin_metadata where volume_id = 0d09c6f5-9cc1-478f-91d7-287a45c66330; delete from volumes where id=0d09c6f5-9cc1-478f-91d7-287a45c66330;C.QOS-针对虚机系统盘和 cinder 云硬盘的带宽和 IOPS 进行限速最终效果，在 libvirt x