有效定位和解决OpenStack问题

本文以OpenStack虚拟机启动流程为例,介绍了OpenStack故障排查的方法。包括启动虚拟机涉及的组件、Nova组件架构、启动流程、关键状态、日志位置及辅助工具等内容。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

对OpenStack这样一个庞大的系统来说,遇到问题很正常,如何对遇到的问题进行精确的定位和解决才是关键?但在很多时候,从用户表象上看到的现象和后端真正的错误往往会有一些偏差。本文以OpenStack虚拟机启动工作流为基础,对OpenStack troubleshooting做一个介绍。从了解整个OpenStack中最核心的虚拟机管理,来对整个OpenStack的设计架构有个了解,为今后更复杂的问题提供一些参考。

从启动虚拟机说起

在开始之前,如果你曾经使用过OpenStack,那请你花几分钟时间回忆一下,你所了解的虚拟机创建过程。如果你还没来得及安装OpenStack,那我建议你先安装一个,这样以便于让你能更好的对下面的内容进行学习。

启动一个虚拟机需要涉及的组件

  • CLI:OpenStack命令行工具,可以通过命令来创建虚拟机。
  • Horizon:OpenStack图形化界面,可以更友好的通过图形化来操作虚拟机。
  • Nova:OpenStack计算核心组件,调用后端的虚拟化平台API接口来最终通过镜像创建虚拟机。
  • Glance:OpenStack镜像管理组件,虚拟机创建过程中需要从这个组件获取虚拟机镜像。
  • Cinder:OpenStack存储管理组件,管理后端存储资源,并为虚拟机提供持久化存储的能力。
  • Neutron:OpenStack网络管理组件,虚拟机创建过程中需要通过此组件获取网络信息。
  • Keystone:OpenStack认证组件,虚拟机创建过程中用户和服务认证需要此服务支撑。
  • MQ(RabbitMQ):消息中间件,支持OpenStack组件内通讯。
Nova组件架构和通讯方式

Nova组件是整个虚拟机启动过程中最重要的组件,Nova的整个设计如下图所示:

整个Nova的设计可以总结如下几点:

  • Nova组件内部模块之前通讯采用AMQP
  • Nova组件和其它组件之间通讯采用RESTful API
  • Nova组件有本身数据库存储持久化数据

可以通过Nova的架构图回味一下Cinder、Neutron、Ceilometer的结构,会发现OpenStack设计上都有类似的地方。当了解了Nova组件内和组件间的交互形式,就可以更好的把之前说到的整个虚拟机创建过程中涉及到的所有组件串起来,下面用一个虚拟机创建的流程想想说明这个过程。

启动虚拟机流程

在OpenStack中,启动虚拟机整个过程看似几秒钟完成的工作,其涉及的相关知识还是相当丰富。曾近有人统计了所涉及的技术,应该在100个知识点以上,这里就不拿出来吓唬大家。重点把整个虚拟机启动过程的图就我的理解进行了整理,如下(有部分是盗用):

虚拟机启动过程如下:

  1. 界面或命令行通过RESTful API向keystone获取认证信息。
  2. keystone通过用户请求认证信息,并生成auth-token返回给对应的认证请求。
  3. 界面或命令行通过RESTful API向nova-api发送一个boot instance的请求(携带auth-token)。
  4. nova-api接受请求后向keystone发送认证请求,查看token是否为有效用户和token。
  5. keystone验证token是否有效,如有效则返回有效的认证和对应的角色(注:有些操作需要有角色权限才能操作)。
  6. 通过认证后nova-api和数据库通讯。
  7. 初始化新建虚拟机的数据库记录。
  8. nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
  9. nova-scheduler进程侦听消息队列,获取nova-api的请求。
  10. nova-scheduler通过查询nova数据库中计算资源的情况,并通过调度算法计算符合虚拟机创建需要的主机。
  11. 对于有符合虚拟机创建的主机,nova-scheduler更新数据库中虚拟机对应的物理主机信息。
  12. nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
  13. nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
  14. nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。(Flavor)
  15. nova-conductor从消息队队列中拿到nova-compute请求消息。
  16. nova-conductor根据消息查询虚拟机对应的信息。
  17. nova-conductor从数据库中获得虚拟机对应信息。
  18. nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
  19. nova-compute从对应的消息队列中获取虚拟机信息消息。
  20. nova-compute通过keystone的RESTfull API拿到认证的token,并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
  21. glance-api向keystone认证token是否有效,并返回验证结果。
  22. token验证通过,nova-compute获得虚拟机镜像信息(URL)。
  23. nova-compute通过keystone的RESTfull API拿到认证k的token,并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
  24. neutron-server向keystone认证token是否有效,并返回验证结果。
  25. token验证通过,nova-compute获得虚拟机网络信息。
  26. nova-compute通过keystone的RESTfull API拿到认证的token,并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
  27. cinder-api向keystone认证token是否有效,并返回验证结果。
  28. token验证通过,nova-compute获得虚拟机持久化存储信息。
  29. nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

在虚拟机创建过程中,可以看到一个任务状态(Task),可以通过这个状态初步判断虚拟机处于哪个步骤:

  • scheduling(3~12)
  • networking(23~25)
  • block_device_mapping(26~28)
  • spawing(29)
  • none(虚拟机创建成功)

记住这些状态,这个是在整个排错过程中最重要的一个状态。可以通过这个状态初步判断整个过程处于什么位置,可以很快的把问题缩小在一个比较小的范围。

永远的日志

看到这里估计在排错的时候心里就有底气多了,不会满世界的去找问题。但还是需要提醒大家,有问题——>找日志。别看这个大家都懂的事情,往往在操作起来,大家跟愿意直接找个人问出了什么问题。大概的归类了一下OpenStack的日志:

  • nova
    • /var/log/nova/*(api.log/compute.log)
  • neutron
    • /var/log/neutron/*
  • glance
    • /var/log/glance/*
  • cinder
    • /var/log/cinder/*
  • keystone
    • /var/log/keystone/*
  • libvirtd
    • /var/log/libvirt/*(qemu里的日志很重要!!)

虚拟机涉及文件

一个虚拟机默认情况下启动过程、或者启动后会在其调度的nova-compute节点的/var/lib/nova/instances目录下会生成如下的文件:

  • base目录下一个base镜像
  • libvirt.xml
  • disk
  • disk-raw
  • kernel
  • ramdisk
  • console.log

辅助的工具

工具千千万只是能提升效率的一个点,关键还是在于对整个过程的理解。在OpenStack使用过程中会用到一些工具辅助排除错误,常用工具如下:

工具名称 工具用途 说明
strace 系统调用跟踪 一个简易且十分好用的系统调研跟踪工具
lsof 查看打开文件 可以很容易的对打开的文件进行查看
tcpdump 网络抓包分析 可以通过抓发分析网络不通
kill kill -USR1 最近发现的牛掰用法

strace用法

  • strace -e open ping
  • strace -p process_id
  • strace -c ping
  • strace -e trace=network nc 127.0.0.1 22

lsof用法

  • lsof -p process_id
  • lsof -i :22 -n

tcpdump用法

  • tcpdump -i interface icmp(其它更多参考tcpdump命令)
  • 建议配合wireshark来分析报文

kill -USR1用法

OpenStack提供SIGUSR1用户定义的信号生成Guru Meditation报告,报告包含如下服务的完整信息和状态,这些状态会输出到标准错误输出中,可以在错误日志中查看。

[kevin@stack ~]$ ps -ef|grep nova-api
kevin      4320   3116 30 11:06 pts/7    00:00:03 /usr/bin/python /usr/bin/nova-api
kevin      4335   4320  2 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4336   4320  2 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4339   4320  4 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4340   4320  4 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4349   4320  9 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4350   4320 11 11:06 pts/7    00:00:00 /usr/bin/python /usr/bin/nova-api
kevin      4360   4205  0 11:07 pts/23   00:00:00 grep --color=auto nova-api
[kevin@stack ~]$ kill -USR1 4320

报告包含如下章节:

  • 软件包信息
  • Threads
  • Green Threads
  • 配置文件

总结

OpenStack troubleshooting的过程中,最重要的是梳理OpenStack的流程。在梳理流程的基础上,配合一些工具可以解决大部分在运行过程中遇到的问题。另外一方面,由于OpenStack本身是一个云管理框架,在排错的过程当中,你往往会遇到很多KVM、存储、OVS、iptables这块的问题,对于这块的问题的解决,还是需要对其原理有一个深刻的理解才行。

几个课后练习

  • nova-api服务停止的情况下,nova-list可以列出虚拟机吗?为什么?
  • 用kill命令尝试终止nova-conductor进程,会有什么报错?(提示先从日志开始)
  • 用strace跟踪一下某个进程的系统调用。
<think>好的,用户问的是关于OpenStack出现“identity credentials”问题解决方法。首先,我需要确定这个错误的具体情况。通常,这类错误身份验证有关,可能涉及用户名、密码、项目名称、域或者Keystone服务的配置问题。 第一步,应该检查用户提供的凭据是否正确。包括用户名、密码、项目(tenant)、域(domain)等信息是否有误。比如,用户可能输入了错误的密码,或者项目名称大小写没注意,或者域填写错误,特别是在多域环境中。 接下来,需要确认Keystone服务是否正常运行。可能用户的环境里Keystone服务挂了,或者网络问题导致无法访问。这时候应该检查Keystone的状态,使用systemctl或者docker ps(如果是容器部署)来查看服务是否在线。同时,查看日志文件,比如/var/log/keystone/keystone.log,是否有异常信息,比如数据库连接失败或者权限问题。 然后,网络连通性也是一个常见的问题。用户可能需要检查客户端能否正确访问Keystone的端点(Endpoint)。用curl或者telnet测试端口(通常是5000或35357),看看是否能连通。防火墙设置可能会阻止访问,需要检查iptables或者安全组的规则是否放行了相关端口。 SSL/TLS证书的问题也可能导致身份验证失败。如果配置了HTTPS,证书过期或者路径错误都会引发问题。需要确认证书的有效性,以及客户端是否信任该证书。有时候,自签名证书没有添加到信任库中,也会导致连接失败。 另外,用户的权限不足或者项目不存在的情况也需要考虑。确保用户所属的角色有访问资源的权限,项目名称正确无误。使用openstack project list命令可以列出所有项目,确认用户要访问的项目是否存在。 如果用户的环境变量设置不正确,比如OS_AUTH_URL指向了错误的Keystone地址,或者环境变量中有旧的凭据信息残留,也可能导致问题。这时候,建议用户重新source一下openrc文件,或者手动设置正确的环境变量。 最后,可能需要升级客户端或者服务端的版本。某些情况下,客户端版本过旧无法兼容Keystone API,导致认证失败。可以尝试更新openstack-client或者其他相关软件包到最新版本。 总结下来,解决步骤大致是:检查凭据有效性→验证Keystone服务状态→排查网络连通性→检查SSL证书→确认权限项目→核对环境变量→升级软件版本。如果用户按照这些步骤逐一排查,应该能找到问题源并解决。</think>遇到OpenStack提示“identity credentials”(身份凭证)错误时,通常与Keystone服务(OpenStack身份认证模块)或客户端配置相关。以下是分步排查解决方法: --- ### **1. 验证凭据正确性** - **检查用户名/密码** 确保`OS_USERNAME`、`OS_PASSWORD`、`OS_PROJECT_NAME`、`OS_DOMAIN_NAME`等环境变量或配置文件中填写的值正确。 ```bash # 查看当前环境变量 env | grep OS_ ``` - **注意域(Domain)配置** 若使用多域架构(如`admin_domain`),需显式指定`OS_USER_DOMAIN_NAME``OS_PROJECT_DOMAIN_NAME`,例如: ```bash export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_DOMAIN_NAME=Default ``` --- ### **2. 检查Keystone服务状态** - **确认Keystone是否正常运行** 在控制节点执行: ```bash # 系统服务管理(非容器化部署) systemctl status openstack-keystone # 容器化部署(如Kolla-Ansible) docker ps | grep keystone ``` - **查看Keystone日志** 日志路径通常为`/var/log/keystone/keystone.log`,检查是否有以下错误: ```bash # 常见错误:数据库连接失败、权限不足、端点未注册 tail -f /var/log/keystone/keystone.log ``` --- ### **3. 验证网络连通性** - **测试Keystone端点可达性** 确保客户端能访问Keystone的`publicURL`或`internalURL`: ```bash # 检查端口连通性(默认5000或35357) telnet <keystone-ip> 5000 # 直接调用API curl -v http://<keystone-ip>:5000/v3 ``` - **检查防火墙规则** 确保安全组或iptables允许流量通过Keystone端口: ```bash iptables -L -n | grep 5000 ``` --- ### **4. 检查SSL/TLS证书问题** 如果启用了HTTPS: - **验证证书有效性** 确保证书未过期且路径正确: ```bash openssl x509 -in /etc/keystone/ssl/certs/ca.pem -noout -dates ``` - **客户端信任证书** 若使用自签名证书,需将CA证书添加到客户端的信任链: ```bash # 将CA证书复制到系统目录 sudo cp ca.pem /usr/local/share/ca-certificates/ sudo update-ca-certificates ``` --- ### **5. 确认权限与项目存在性** - **检查用户角色项目** 使用管理员账户验证目标用户是否有权限访问指定项目: ```bash openstack user list openstack project list openstack role assignment list --user <user-name> ``` --- ### **6. 更新客户端或服务版本** - **升级OpenStack客户端** 旧版客户端可能与Keystone API不兼容: ```bash pip install --upgrade python-openstackclient ``` --- ### **7. 重置环境变量** - **重新加载OpenStack RC文件** 避免残留的环境变量干扰: ```bash source admin-openrc.sh # 重新加载认证文件 ``` --- ### **总结流程图** ```plaintext 身份凭证错误 → 检查凭据 → 服务状态 → 网络连通 → SSL证书 → 用户权限 → 环境变量 → 客户端版本 ``` 按以上步骤排查后,通常能定位到具体原因。若问题仍存在,建议提供完整错误日志以进一步分析。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值