Openstack云操作系统介绍

1、Openstack云操作系统介绍21整体架构2计算组件运维34存储组件运维网络组件运维5认证和镜像运维3OpenStack 简单视图4OpenStack架构概览 5控制节点服务及高可用实现6控制节点服务与HA78云操作系统单数据中心部署图9部署网（PXE）：自动化部署工具通过该网络部署物理机操作系统和云操作系统其他组件管理网（mgmt）：云操作系统计算、网络、存储、认证等服务间通过该网络互相调用；虚拟主机通过该网络将业务IO写入磁盘存储网（storage）：分布式存储中各个磁盘之间通过该网络进行数据副本的同步私网（private）：虚拟主机的东西向流量通过该网络进行通信业务网（app）：虚拟主

2、机的南北向流量通过该网络与数据中心内其他系统进行通信IPMI网络：物理主机带外管理接口，为了配置计算节点/混合节点的hostha，需要连通控制节点的mgmt网络（或者pxe，或者storage）和计算/混合节点的ipmi接口网络。1011分布式存储架构12131415161整体架构2计算组件运维34存储组件运维网络组件运维5认证和镜像运维17Nova架构18设置环境变量rootnode-1 # source openrc19Nova组件状态检查rootnode-1 # nova service-list根据输出，查看State是否存在down的情况，如果没有证明整个集群工作正常。如果有down

3、的情况需及时进行处理。 Nova服务down掉，不会影响虚机运行， 但对相关物理机上的虚机操作会有影响（如开关机，迁移等等）。可尝试重启相应服务。20Nova常用命令列出可用的实例 nova list -all-tenantnova list -all-tenant -host node-4.domain.tld21Nova常用命令rootnode-1 # nova show testvm0122Nova常用命令列出可用的flavorrootnode-1 # nova flavor-list定制flavor，flavor name=test500 flavor id=500 ram=512Mb

4、 cpu=2rootnode-1 # nova flavor-create test500 500 512 1 223Nova常用命令-创建虚机-image 后面加镜像UUID，使用glance image-list查看-flavor 后面加flavor的UUID，使用nova flavor-list查看，也可以新建flavor-nic net-id 后面加网络UUID，使用neutron net-list查看，主要是net，部署subnet-availability-zone 如果不指定由nova-scheduler根据策略自动指定主机部署， 默认是nova。可以通过zone_name:no

5、de-name将虚拟机部署到指定的主机上面，比如：Internal_Zone:node-11.domain.tld前面是zone名称，后面是宿主机的主机名24先获取flavor id: nova flavor-list |grep 500获取image id: glance image-listNova常用命令-创建虚机25Nova常用命令获取网络 id: neutron net-list创建vm 实例testvm01nova boot -image f911dbae-aaee-4969-8b99-c535d6e18eaa -flavor test500 -nic net-id=b21a53d

6、6-b4c0-4e49-ac78-50a8d66c310f testvm0126启动/关闭/删除一个虚机获取实例的id: nova list通过指定实例id启动实例nova start 3f84a737-e26b-4cee-a5d9-ff44d9458172通过指定实例关闭实例nova stop 3f84a737-e26b-4cee-a5d9-ff44d9458172通过指定实例id删除实例nova delete 3f84a737-e26b-4cee-a5d9-ff44d945817227Nova常见问题-服务相关A. Compute服务down nova服务分布在控制节点和计算节点上。 其中

7、控制节点上有Nova-cert，nova-consoleauth，nova-scheduler，nova-conductor， 计算节点上只有nova-compute服务。其中控制节点上nova服务down掉的几率不大。 计算节点nova-compute服务down掉时， 先检查相应节点的网络连接，确认管理网络正常。网络检查正常后，可尝试ssh至问题节点，/etc/init.d/openstack-nova-compute restart 来尝试重启nova-compute服务。 此操作不会影响正在运行的虚机。28Nova常见问题-服务相关B .Compute服务无法重启 在重启nova-co

8、mpute服务后，可执行/etc/init.d/openstack-nova-compute status 来确认服务是否正常启动。 如果现实pid xxxx is running. 则服务正常。 有时会有 progress is not rugnning but pid file exist 的报错。 此时需要删除 /var/run/nova/nova-compute.pid 文件， 再次重启即可。 如果还有问题，请检查系统rsyslog服务，一般出现这种情况，都是由于系统rsyslog服务卡死，先重启rsyslog服务后，再检查compute服务。29Nova常见问题-虚机操作问题A .部

9、署，迁移，调整虚机失败有时，由于某些原因，虚机在迁移，修改大小后报错，虚机状态为”error”， 可用下列命令恢复其状态nova reset-state -active这种问题出现的可能性有很多， 需要分析相应的log。 分析日志的顺序为控制节点上的nova-api.log- nova-conductor.log-nova-scheduler.log 如果都没问题， 则检查相应计算节点上的nova-compute.log。30Nova常见问题-虚机操作问题B. 创建虚拟机失败 创建虚拟机是一个复杂的操作，涉及到openstack很多的服务。 当用户提交创建虚拟机的请求时，请求首先会到达nova

10、-api服务，nova-api 会记录用户的请求，随后调用nova-compute完成虚拟机的创建工作。在创建虚拟机的过程中，nova-compute会调用glance获取镜像，调用neutron创建网卡，调用cinder挂载volume，调用ceph创建系统盘。 任何一个步骤失败都会导致虚拟机创建失败，所以，在排除虚拟机创建失败的问题时，需要了解openstack的总体架构，熟悉nova创建虚拟机的流程，然后根据虚拟机的状态及nova服务的日志判断创建虚拟机的操作执行到哪步失败了。31Nova常见问题-虚机创建失败创建虚拟机的过程中调度失败故障描述: 执行虚拟机创建操作之后，很长时间虚拟机还

11、在“创建中”。虚拟机创建的过程中，需要nova-scheduler服务确定在哪个物理服务器上运行刚刚创建的虚拟机，如果nova-scheduler服务不响应调度任务，则虚拟机可能一直处于scheduling状态。# source /root/openrc# nova show 32Nova常见问题-虚机创建失败字段含义status在浏览器里面，用户看到的状态。status是虚拟机task_state、vm_state、power_state综合起来的结果。OS-EXT-STS:task_statenova管理服务正在对虚拟机执行的操作。如果为-，则表示没有人在管理此虚拟机。OS-EXT-SRV

12、-ATTR:host虚拟机所在宿主机的hostname。如果为-，则表示虚拟机还没有确定，一般在刚创建虚拟机的过程中，调度器还没有完成调度时会显示为该状态。如果OS-EXT-STS:task_state为scheduling， 而且 OS-EXT-SRV-ATTR:host 为-，则表示还在等待调度程序确定运行虚拟机的宿主机。由此可以判断nova-scheduler服务出问题了。如果调度没有问题，或者没有可用的宿主机，调度程序都会很快返回，不会一直停留在scheduling的状态。33Nova常见问题-虚机创建失败解决方法出现上面的故障有两种可能性，一种是整个集群没有可用的nova-sched

13、uler实例；另一种是nova-scheduler服务出问题了。对此，首先要查看整个集群是否有nova-scheduler服务在运行。查看方法如下：nova service-list | grep scheduler 整个集群至少需要一个nova-scheduler实例处于up状态。需如果集群中至少有一个nova-scheduler实例的状态是up的，我们就需要查看查看nova-scheduler的日志来进一步确定原因了。到控制节点上，查看/var/log/nova/scheduler 日志。tail -f /var/log/nova/scheduler34Nova常见问题-虚机创建失败 no

14、va-scheduler服务不能正常工作最常见的一个原因是连不上RabbitMQ服务，或者能连上就是不消费队列中的消息。为此需要查看消息队列中nova-scheduler服务未消费的消息数目。具体方法是在控制节点上执行下面的命令： nova-scheduler服务使用的队列名称是以scheduler开头，每个nova-scheduler会监听两个队列，一个是 scheduler.server-xx 表示这个实例运行在 server-xx 上面；scheduler_fanout_xxxxx 这个队列是用来接收调度服务的广播消息。如果这些队列中的消息数量一致大于零，就表示队列中的消息没有人消费。对

15、于这种情况，可以重启下 所有的 nova-scheduler 实例看看问题是否能得到解决。/etc/init.d/openstack-nova-scheduler restart35Nova常见问题-虚机创建失败创建虚拟机过程中报NoValidHost执行虚拟机创建操作之后，虚拟机的状态没有变为“运行中”，而是变为了“错误”，用 nova show 查看虚拟机状态，发现关键字 NoValidHost登录控制节点，执行下面的命令显示虚拟机的详细信息：# source /openrc# nova show （虚拟机UUID是创建失败的虚拟机的UUID）如上图所示，关键信息是 fault 字段中包含

16、了 No valid host was found 这样的信息。如果出现这类关键信息，可以参考下面的解决办法。36Nova常见问题-虚机创建失败上面的错误信息是nova-scheduler服务返回的，表明上的意思是没有可用的宿主机，也就是说请求的资源太多了，现在集群中没有哪个宿主机有那么多资源，所以请求失败。由于nova-scheduler会封装nova-compute所遇到的错误，所以上面的消息不一定准确。为了确定确切的原因，可以通过如下的命令来查看整个集群的资源占用情况。字段名称含义memory_mb所有宿主机内存总量memory_mb_used已经分配给虚拟机的内存总量；openstac

17、k允许内存复用比大于一，所以，这个值可能比 memory_mb 还大vcpus所有宿主机中cpu数量（总线程） vcpus_used已分配的虚拟机的vcpus总量；openstack允许CPU复用比大于一，所以，这个值可能比 vcpus 还大running_vms已经创建的虚拟机的总数，包括关机状态的虚拟机37Nova常见问题-虚机创建失败以及命令；nova hypervisor-show node-x.domain.tld 来查看单台服务器的使用情况。 如果集群系统不够用了，上面统计的已经分配给虚拟机的 vcpus & 内存应该都比较高。否则的话，有可能是nova-compute上某些操作执

18、行失败了。默认情况下，调度器会尝试三次，在不同的宿主机上运行虚拟机，如果都失败，也会报 No valid host 的错误。具体错误，可以查看scheduler.logrootnode-1 # tail -f /var/log/nova/nova-scheduler.lognova-compute创建虚拟机失败可能有很多原因，可能是创建系统盘失败，也可能是调用neutron创建网卡失败，也可能是 虚拟化层的错误。对于这种情况，需要进一步查看nova-compute及相关服务的日志确定具体的原因。具体方法如下：# cat /var/log/nova/compute.log | grep -v I

19、NFO | grep -v AUDIT | less38Nova常见问题-虚机迁移nova live-migration 为在线迁移，迁移过程中，网络几乎不会中断Nova migrate 为冷迁移，虚机为关机状态的迁移39Nova相关日志文件控制节点：/var/log/nova/api.log/var/log/nova/conductor.log/var/log/nova/scheduler.log计算节点 ：/var/log/nova/compute.log/var/lib/nova/instance 401整体架构2计算组件运维34存储组件运维网络组件运维5认证和镜像运维41Neutron

20、架构42Neutron状态检查检查Neutron servicerootnode-1 # neutron agent-list重点查看alive列的状态是否正常，L3 agent和DHCP agent至少要有一个正常。43Neutron状态检查检查l3-agent的namespace从上面的状态可以看到l3-agent在node-1，所以在node-1上查看namespacerootnode-1 # ip netnsrootnode-1 # ip netns exec qrouter-95e6d480-7607-477e-a11a-67ca68604619 ip a环境中如果没有启用L3-ro

21、uter， 无需检查。44Neutron状态检查查看dhcp-agent的namespace在node-1上查看namespacerootnode-3 # ip netns exec qdhcp-xxxxxx ip a可以看到一个tap设备，ip是dhcp的IP。如果虚机分配不到IP，请检查dhcp服务是否正常。45rootnode-3 # ps aux | grep dhcpNeutron状态检查46rootnode-3#cat /var/lib/neutron/dhcp/3344c78a-d5a8-419c-bbc6-60424bf0ef14/hostNeutron状态检查如果正常这个ho

22、st文件里会有虚机的mac地址和分配的IP的记录，当dhcp服务出问题时，不会影响现有虚机运行， 只会造成新建虚机无法获取IP地址，同时无法写入主机名和密码。47Neutron常用命令neutron net-list查看所有子网neutron subnet-list查看所有路由器neutron router-list查看所有网络48编辑子网Neutron常用命令创建路由器,名称 es_hr_routerneutron router-create es_hr_router49连接路由器到外网先获取router名称neutron router-list然后获取外网名称public_netneutr

23、on net-external-list连接路由器es_hr_router到外网public_netneutron router-gateway-set es_hr_router public_net再次确认路由器已经连接至外网neutron router-listNeutron常用命令50命令行创建l2网络在控制节点上，执行如下命令：#创建net,vlan为421neutron net-create net_421 -provider:network_type=vlan -provider:physical_network=physnet2 -provider:segmentation_id

24、=421#其中，net_421为此net的名字，网络类型为vlan， segmentation_id为vlan号。#创建子网neutron subnet-create -name subnet_421 -disable-dhcp -no-gateway -allocation-pool start=,end= -host-route destination=/0, nexthop=0 net_421 /27#其中，subnet_421位子网名字，禁用了dhcp，no-gateway参数指明不使用默认的l3. Allocation-pool为地址池， nexthop指明下一跳至网关， 此子网属于

25、net_421 /27网络下。5152Neutron常见问题Neutron服务相关问题检查方法 neutron-agent list相关报错：A. 控制节点服务状态异常在控制节点(HA环境)任意节点执行crm status命令检查部分neutron服务状态，正常状态显示如下图，没有failed，没有stopped，这里pacemaker监控四个neutron服务：neutron-openvswitch-agent、neutron-metadata-agent、neutron-dhcp-agent和neutron-l3-agent(纯L2环境忽略，也可以移除不再监控)，这时不需要任何处理。53N

26、eutron常见问题如果服务异常，node-3的neutron-openvswitch-agent异常stopped了。同时会伴有failed error，此时需要手动干预。以node-3上的neutron-openvswitch-agent服务异常为例，需要ssh到node-3，先source openrc，然后执行crm resource cleanup p_neutron-openvswitch-agent稍等一下，stopped和failed会被清理掉，依次处理其他问题，直至服务恢复正常。54Neutron常见问题如果在云平台异常的情况下，有服务在三个节点全部down，则不会再crm

27、status中再显示，即不被pacemaker管理，这是需要使用crm source list查看。如图，crm status已经看不到mysql状态了，使用crm resource list可以看到mysql已经在三个控制节点全stopped了55Neutron常见问题 如果使用crm status看不到全部四个neutron服务则使用crm resource list看一下是不是已经全部stopped了。如果出现这种情况则需要在任意控制节点执行crm resource restart p_mysql 这个时间可能会长一点，等启动完成再使用crm status查看，如图则为恢复正常，如果没有

28、恢复则需要查看相关log：/var/log/neutron/dhcp-agent.log、/var/log/neutron/metadata-agent.log、/var/log/neutron/openvswitch-agent.log、/var/log/neutron/l3-agent.log以及/var/log/neutron/server.log具体问题具体分析。 除了以上外，控制节点还有一个neutron-server服务没有被pacemaker管理，可以直接使用service neutron-server status查看其状态，显示running状态即服务正常。Neutron-s

29、erver服务一般很少出问题，但此服务严重依赖rsyslog，在默认情况下控制节点rsyslog server指向roller，这是如果roller长时间不通或导致rsyslog服务down，从而引发neutron-server异常，此时网络其他服务也会出现异常，需要重启rsyslog服务，然后重启neutron-server以及其他服务即可恢复。56Neutron常见问题计算节点openvswitch服务down如图这里我们主要看计算节点的neutron服务，在计算节点的neutron服务只有一个：neutron-openvswitch-agent，alive一栏显示全为笑脸则表示服务正常。

30、下图中，node-6的neutron-openvswitch-agent服务挂了，则需要重启。可以在控制节点远程查看node-6的neutron-openvswitch-agent服务并重启，本次看到的查看node-6的服务是running的，但是误报了，有时候是缺失failed了。57Neutron常见问题这个问题出现，我们需要先查看控制节点CPU和内存使用率，这里只有node-6异常，表示控制节点正常，可以确认下。一般引起该服务异常是计算节点内存或者CPU负载。我们登录到node-6看一下。先使用free g看一下内存，果然free为3g了，我们看其实大部分内存都被cache了。这个时候可

31、以释放一下cache占用的内存，操作如下：echo 1 /proc/sys/vm/drop_caches #不建议使用3/etc/init.d/openstack-ceilometer-compute restart/etc/init.d/openstack-nova-compute restart #这两个服务长期运行容易假死且占用大量内存，建议每个月重启一次这个时候也建议检查下所有节点的可用内存以及CPU负荷。释放内存后的如图58Neutron常见问题Neutron Server无法启动的原因分析 其一，neutron-server异常failed(neutron-server服务异常会引

32、起控制节点其他网络服务异常)，无法正常start的情况，此类情况需要优先检查rsyslog状态(如果该服务异常则优先解决该问题)，查看CPU负载和可用内存(必须保证CPU负载和内存有资源可用)，如果问题依旧存在，可查看/var/log/neutron/server.log定位具体问题; 其二，由于内存消耗、CPU负载异常导致neutron相关服务failed或者假死，需要手动重启相关服务，有时候会出现progress is not running but pid file exist，需要查看CPU负载和内存占用情况(优先处理)，确认没有问题执行rm /var/run/neutron/neut

33、ron-openvswitch-agent.pid，然后重启看一下，如果问题依旧存在则查看/var/log/neutron/下相关服务的log定位具体问题； 其三，当控制节点crm status出现failed action时，通常需要登陆相关节点使用crm resource cleanup 重启相关服务，如果无法正常启动，或者启动不久又failed，需要确认该节点CPU负载和内存占用情况，持续ping检查网络是否出现偶尔中断或者高延迟的情况，查看/var/log/neutron下相关log定位具体原因。 其四，rabbitmq服务异常会引起网络服务及云平台服务不稳定，此时问题会比较严重，但对

34、纯l2的环境已有的虚机无影响，此时需要停止在dashboard上的创建删除等操作，然后使用crm resource stop p_rabbitmq-server先停止该服务，这个时间会比较长，一般十几分钟或者二十分不等，然后start该服务，提示启动成功需要等待几分钟才会出现在crm status中，所以不用反复重启。不用直接使用restart时间会更长，或者卡住。 59Neutron常见问题检查rabbitmq的方法可以参考rabbitmq模块，命令如下：crm statusrabbitmqctl cluster_statusrabbitmqctl list_queues | sort k2

35、n其五，服务异常且不能重启，不能使用neutron命令，有可能会是keystone或者mysql集群异常导致，需要根据neutron log定位具体问题，如果是keystone(一般极少出问题)或者mysql(异常断电容易引起mysql异常)引起请参考相关模块排查。总结：释放内存的方法前文已经提过；控制节点一般占用内存较多的服务是mysql和mongoDB，清理方法请参考相关模块；计算节点占用内存较多的是ceilometer-agent和nova-compute服务，重启即可释放。60Neutron常见问题运行中的虚机IP丢失状况是运行着的虚机突然不通了，通过console查看，发现网卡没有了

36、IP地址，或者有两个ip地址，一个是原地址，一个是169.x.x.x，一般是获取不到地址才分配的，而且169.x.x.x是优先的，也就是在两个地址都存在的情况下，元地址不可用。这种情况基本是由于DHCP租期到期，在获取IP地址的时候由于网络异常，或者超时引起，解决这个问题的方法有两个：其一，虚机获取IP之后，手动将网卡配置成固定IP；其二，默认DHCP租期为86400s，可以修改为十年，即可避免此问题。61Neutron常见问题案例：虚机floating ip无法ping通问题产生原因： 某日凌晨1:00左右,node-1上的系统负载达到80%，crm获取Neutron服务状态超时, 导致cr

37、m尝试重启Neutron服务，由于负载太高,服务异常. 导致该节点上的l3-agent无法工作。node-3上, crm启动openvswitch agent后, 服务又被人为手动启动, 导致有两个进程同时存在, 发生冲突。 部分租户的router没有成功绑定l3-agent. 判断是由于crm检测neutron状态超时, 印发router迁移. 迁移的目标控制节点又由于负载太高导致router没有正常启动成功.所以问题产生原因主要是负载高导致的crm不正常工作，其次是手动启动了crm管理的服务这两个原因造成的。62Neutron常见问题针对问题的处理方法：改动1： 原来crm监控neutro

38、n agents是检查neutron agents的进程来判断neutron agents服务是否正常，如果进程不在或检查出问题，就会重启neutron agents。目前看neutron agents的进程基本不太可能被kill掉，除非人为手动kill，而crm监控出现问题时，一般是负载太高，crm使用ps命令检查超时导致。 我们的改动是crm对neutron agents的监控永远返回ture。如果用户发现进程不在，需要启动时，需要用crm启动。需要修改crm配置文件（/usr/lib/ocf/resource.d/es /neutron-agent-dhcp, /usr/lib/ocf/

39、resource.d/es/neutron-agent-l3, /usr/lib/ocf/resource.d/es/neutron-agent-ovs, /usr/lib/ocf/resource.d/es/neutron-agent-metadata）搜索monitor()，将这个方法的return 0注释，return 0下面语句打开注释。过一会crm会检测到进程没有启动，便自动启动。等进程起来后，把配置文件再改回去。改动2：将l3的auto reschedule功能关闭，目前l3的auto reschedule依赖于mysql，rabbitmq。如果系统负载高，不稳定时，很容易导致re

40、schedule，而在负载高时的 reschedule又容易失败，所以建议将l3的auto reschedule关闭，如果当一个控制节点断电或死机，需要用户手动去reschedule。63Neutron常见问题在好的控制节点执行命令：for i in neutron router-list-on-l3-agent | grep | | tail -n +2 | awk print $2; do neutron l3-agent-router-remove $i; neutron l3-agent-router-add $i; donerootnode-1 # neutron router-li

41、st-on-l3-agent 261b8276-a31e-4e71-9dd0-bffb44a6098564dhcp,metadata相关问题虚拟机无法获取DHCP服务(此时虚机也无法正常注入主机名和密码)其一，检查控制节点DHCP服务是否正常，如果有failed需要参考前文解决该问题，然后重启或者重建该虚机。65其二，确认三个控制节点namespace都存在dhcp，先确认问题网络的UUID，然后参考下图命令检查，如果显示三个则为正常，如果只有一台或者两台控制节点上存在则为异常，通常为rabbitmq异常引起，参考rabbitmq模块解决该问题，然后重启DHCP服务crm resource r

42、estart p_neutron-dhcp-agent，再次查看应该问题会解决。dhcp,metadata相关问题66其三，可能是物理网络不通引起。如果是之前创建的网络运行正常，新建的虚机无法获取IP地址，或者新建的网络不通，则需要检查private网络物理线路是否正常可用，物理交换机对应端口是否配置正常，或者是否有修改过配置。 其四，rabbitmq服务异常造成dhcp服务异常，引起新建虚机无法正常获取IP，跟第二条类似，第二条是创建网络时DHCP服务没有及时正确的创建，本条是之前网络正常，但新建虚机无法正常获取IP，参考rabbitmq模块检查并处理该问题其五，查看控制和该计算节点ipta

43、bles是否应用了dhcp规则，如果没有需要手动添加。 其六，port bind failed，新建虚机偶尔发生无法获取DHCP，经过以上排查发现所有服务都正常，nova show 发现bind failed，查看log有rpc timeout的报错，此时可能是rabbitmq或者neutron或者网络超时导致，偶发现象，很少见。具体原因需要查看neutron log确认。dhcp,metadata相关问题67总结：正常情况下虚机都可以获取到IP，获取不到的情况不多见，有时候问题也不是很好排查，大概是以上几个思路。另外可以通过tcpdump逐级网络设备，来判断问题所在。首先，通过虚机的uuid

44、和ip， 找到相应的port uuid。然后，到相应的计算节点上，通过ip a命令，可以找到所有的网络设备，其中虚机对应的tap设备，qbr设备，qvb，qvo设备的名称均为tap，可用grep找到。dhcp,metadata相关问题68之后，可以在虚机中，执行dhclient命令，来发送广播包，尝试获取dhcp地址。可以在各个设备上执行tcpdump，来看是否能收到广播包，来判断问题所在。也可以去dump dhcp server上的tap设备，需要先到相应的namespace下，如tap设备，均在dhcp的namespace中。如下图:Ip netns exec dhcp-xxxxxx tc

45、pdump -i tapxxxxxx -nne port 67 or port 68 dhcp,metadata相关问题69虚机可以获取IP地址，但是无法正常注入主机名和密码dhcp,metadata相关问题其一，虚机可以获取到IP证明网络是ok的，由于获取metadata是由cloudinit完成的，这个过程在虚机启动的时候获取，所以先查看console log，如果虚机启动过程没有cloudinit，或者cloudinit启动失败，则是cloudinit没有正常运行。如果是其他报错，我们继续排查。通常如果主机名和密码注入失败在虚机 启动过程在console界面会看到报错如下图:70其二，虚

46、机启动过程中cloudinit通过private网络向neutron metadata请求元数据，所以要检查neutron的metadata服务正常运行，如图是正常运行状态，如果alive显示xxx，则需要手动重启该服务，并检查为什么挂了。其三，元数据请求是一个neutron-ns-metadata-proxy的进程响应，在不同的场景下metadata-proxy可能会起在router或者dhcp空间下。如果只是建了一个网络没有关联路由，这时neutron-ns-metadata-proxy会起在DHCP空间内，虚机获得54的路由，这时可以正常获取；如果此时该网络关联路由，再新建虚机还是会走5

47、4路由向DHCP获取元数据，这时会获取不到，然后报错，这时需要重启neutron-dhcp-agent服务，在路由的空间里会起neutron-ns-metadata-proxy服务，这时虚机会通过默认路由向路由获取元数据，不走54了。71其四，跟上一条反过来，如果创建的网络关联了路由那么neutron-ns-metadata-proxy会起在路由下，虚机启动通过默认路向路由申请元数据，dhcp空间没有此服务；如这时路由拿掉了，需要重启neutron-dhcp-agen服务来更新，使neutron-ns-metadata-proxy在dhcp空间内启动并下发54路由。总结：这个问题一般是由网络改

48、动引起，可以通过重启neutron-dhcp-agent和neutron-metadata-agent两个服务来解决。72ovs相关问题查看ovs配置在控制节点执行，ovs-vsctl show73ovs相关问题74手动创建ovs-bondovs-vsctl add-br br-ovs-bond2ovs-vsctl add-br br-roller#创建一个bond，包括物理网卡eth0和eth1ovs-vsctl add-bond br-ovs-bond2 bond2 eth0 eth1#br-roller和br-ovs-bond2之间互相添加端口ovs-vsctl add-port br-

49、roller br-roller-br-ovs-bond2ovs-vsctl set Interface br-roller-br-ovs-bond2 type=patch options:peer=br-ovs-bond2-br-roller ovs-vsctl add-port br-ovs-bond2 br-ovs-bond2-br-rollerovs-vsctl set Interface br-ovs-bond2-br-roller type=patch options:peer=br-roller-br-ovs-bond2#使用ip link命令将三个网桥状态设置为upip lin

50、k set up dev br-ovs-bond2ip link set up dev br-roller ovs相关问题75扩展private vlan 部署时，为private网络指定了一个范围。 在dashboard创建网络时（或命令行创建，不指定segmentation_id时），neutron会自动从这个范围中按顺序取一个，当所有vlan均用完时，创建网络会失败。 这时需要修改这个vlan范围。 修改步骤很简单:修改控制节点上的ml2_conf.ini修改physnet2的range即可。 修改完成后重启neutron服务。761整体架构2计算组件运维34存储组件运维网络组件运维5认

51、证和镜像运维77Cinder架构78Cinder组件状态检查rootnode-1 # cinder service-list 根据输出，查看State是否存在down的情况，如果没有证明整个集群工作正常。如果有down的情况需及时进行处理。Cinder服务down掉，不会影响虚机运行， 只影响云硬盘的挂载操作，可尝试重启相应服务。79Cinder常用命令列出所有已创建的云硬盘cinder list -all-tenant80创建一个volume，显示名称testvol01,大小1Gbcinder create -display-name testvol01 1Cinder常用命令81挂载一个v

52、olume到一个vm实例获取volume idcinder list获取实例 idnova list将指定的volume id挂载到指定的vm 实例id上nova volume-attach autoCinder常用命令82删除volume获取volume idcinder list删除指定volume id的volumecinder delete b3c3c099-16c6-43a2-a17f-d0fc5dcf2691改变volume大小cinder extend b3c3c099-16c6-43a2-a17f-d0fc5dcf2691 100Cinder常用命令83改变volume状态Ci

53、nder常用命令84Cinder服务相关问题云硬盘挂载，删除相关问题 由于云硬盘挂载和卸载操作设计到nova和cinder两个项目，需要两个项目执行一系列操作，因此很难实现事务操作，所以如果云硬盘挂载或卸载操作执行到中途失败，就容易造成nova、cinder、libvirt三个地方云硬盘的挂载信息不一致。在修复云硬盘状态不一致的问题时，应以硬盘的实际挂载状态为准，修复前，先检查硬盘的实际挂载状态，然后确定nova和cinder该如何修复。因为用户可能已经挂载了硬盘，并存储数据了，冒然卸载可能会影响用户的数据。A. 确定并修复libvirt中云硬盘的挂载状态B. 修复nova中云硬盘的状态C.

54、修复cinder中云硬盘的状态85A. 确定并修复libvirt中云硬盘的挂载状态 修复云硬盘状态不一致的问题大致分三步走，第一步是确定云硬盘的实际挂载状态。为此，首先要通过nova show确定虚拟机所在的宿主机，然后，通过libvirt的命令行工具virsh确定云硬盘的挂载状态。具体命令如下：# virsh qemu-monitor-command -hmp $(ps -ef | grep | grep -o instance-0-9a-f8 | head -1) info blockCinder服务相关问题86再执行下面的命令，看看libvirt中虚拟机的配置文件和它是否一致：# vir

55、sh 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)Cinder服务相关问题87Cinder服务相关问题88如上所示，一个 .之间的内容就是一个块设备的所有

56、配置信息，可以将其保持到一个单独的文件中，然后通过 virsh attach-device 或 virsh detach-device 命令来动态的挂载或卸载这个块设备。如图：确定并修复完libvirt的状态之后，我们就可以开始修复云硬盘在nova的状态了。Cinder服务相关问题89B. 修复nova中云硬盘的状态nova服务会将虚拟机的挂载的云硬盘信息记录在一张单独的表里面，这张表的名称是 block_device_mapping，表结构如下：其中比较关键字段的含义如下：source_type：挂载之前的类型destination_type：挂载之后的类型connection_info：连

57、接信息；虚拟机通过这些信息就可以挂载硬盘了deleted：是否有效instance_uuid: 云硬盘挂载到哪个虚拟机了如果挂载有问题，或者中途失败，connection_info 字段为空。在nova中修复云硬盘的状态很简单，只需要修改上面这个表，将没有挂载成功的云硬盘对于的信息标记为deleted就可以了。也就是说，只需要修改deleted字段。如下：mysql update block_device_mapping set deleted=xxxx where id=xxxx;Cinder服务相关问题90C. 修复cinder中云硬盘的状态cinder中使用了两个表来记录云硬盘的状态和挂

58、载信息。分别是 volumes 和 volume_attachment。volumes的表结构如右图：volumes表记录了所有的云硬盘的基本信息。其中 status 表明了目前所处的状态，attach_status 表明了云硬盘正在执行的操作。在cinder中修复volume的状态要修改这个表。将云硬盘为未挂载，具体如下：mysql update volumes set status=available, attach_status=detached where id=xxxxx;Cinder服务相关问题911整体架构2计算组件运维34存储组件运维网络组件运维5认证和镜像运维92Glance

59、架构93Keystone常用命令-Tenant相关命令查看Tenant/Project列表创建一个tenant，名字为tenant4labskeystone tenant-create -name tenant4labskeystone tenant-list94删除一个tenant，删除时需要指定tenant idkeystone tenant-delete 422452437d674e5ab81c73cda7bed81fKeystone常用命令95列出所有角色keystone role-list创建角色，角色名为hradminkeystone role-create -name hradm

60、inKeystone常用命令96将指定用户HR01以指定角色hradmin（通过keystone role-list 获得），加入指定tenant Porduction（通过keystone tenant-list获得）keystone user-role-add -user HR01 -role hradmin -tenant Porduction_HRKeystone常用命令97删除指定tenant Porduction中的指定用户 HR01 的指定角色 hradmin （不是删除用户名）keystone user-role-remove -user HR01 -role hradmin