手动安装Nova前必读：RabbitMQ与Keystone配置详解

1. 为什么手动装 Nova 之前得先把 RabbitMQ 和 Keystone 这两块地基打牢搞 OpenStack 的人多少都有个共识Nova 是整个云平台的“调度大脑”虚机的创建、迁移、销毁全靠它指挥。但很多人一上来就急着apt install nova-api nova-compute结果服务起不来日志里全是AMQP connection refused或者Unauthorized然后开始满世界找答案。我踩过这个坑不止一次后来才想明白一件事——Nova 本身不存状态它所有的协调动作都依赖两个外部组件一个是消息队列一个是身份认证。这两样没配好Nova 就是个空壳。这篇内容就是围绕“手动安装 Nova 之前RabbitMQ 和 Keystone 到底该怎么配”来展开的。适合谁看如果你正在跟着官方文档一步步搭 OpenStack或者想搞清楚 Nova 各服务之间到底怎么通信、怎么鉴权那这篇就是给你准备的。我会把每个配置项背后的逻辑讲清楚不只是告诉你“填这个值”而是告诉你“为什么是这个值”。手动安装的好处就在于每一步你都得自己动手反而能把组件之间的依赖关系摸透这比用自动化部署工具学到的多得多。先说结论性的判断RabbitMQ 负责 Nova 内部各服务之间的异步消息传递Keystone 负责所有 API 请求的身份验证和服务目录注册。Nova 的nova-api、nova-scheduler、nova-conductor、nova-compute这几个服务彼此之间不直接调用全靠 RabbitMQ 中转而任何外部请求进来或者服务之间需要确认对方身份都得走 Keystone。所以这两个组件配错了后面所有步骤都是白费。2. 整体设计思路为什么是 RabbitMQ 加 Keystone 这个组合2.1 Nova 的通信模型决定了消息队列的选型Nova 的架构是典型的“去中心化协作”模式。你创建一个虚机请求先到nova-api它把任务丢进消息队列nova-scheduler从队列里拿到任务去选计算节点选完再丢回队列nova-conductor负责数据库操作最后nova-compute在目标节点上真正执行。这几个服务可能跑在不同机器上它们之间没有直接的 RPC 调用全靠消息队列做解耦。那为什么选 RabbitMQ 而不是别的OpenStack 社区早期确实支持过 Qpid 和 ZeroMQ但 RabbitMQ 因为成熟度高、社区活跃、AMQP 协议标准化程度好成了事实标准。手动安装场景下RabbitMQ 的配置也相对直观——你只需要一个虚拟主机vhost、一个用户、一组权限就能让 Nova 跑起来。我实测下来RabbitMQ 3.x 系列配合 Nova 的兼容性最稳建议用 3.8 以上的版本。这里有个设计上的关键点Nova 不同服务用的是同一个 RabbitMQ 用户但通过不同的 exchange 和 queue 来区分消息类型。你不需要为每个服务单独建用户但 vhost 要独立出来避免和其他 OpenStack 组件比如 Neutron、Cinder的消息混在一起。这个隔离思路很重要后面排查问题时你会感谢自己当初分了 vhost。2.2 Keystone 的角色不只是登录认证那么简单很多人对 Keystone 的理解停留在“用户名密码验证”其实它在 Nova 手动安装里承担了三件事。第一是服务注册Nova 的每个服务api、conductor、scheduler、compute都要在 Keystone 里注册一个 service 和对应的 endpoint否则其他组件找不到它。第二是用户与权限Nova 各服务之间通信要用专门的 service 账号不能用 admin 账号凑合。第三是令牌签发所有 API 请求携带的 token 都由 Keystone 颁发和校验。手动配置 Keystone 时最容易出错的地方是 endpoint 的 URL 格式。Nova 的 endpoint 分 public、internal、admin 三种类型端口都是 8774但 URL 里的 host 要根据你的网络规划来填。如果你所有服务都在一台机器上做实验那三个 URL 可以一样但如果是多节点部署public 用对外 IPinternal 用管理网 IPadmin 用 localhost 或管理网 IP这个区分必须提前想清楚。我见过有人三个都填了公网 IP结果内部通信绕了一圈公网延迟高得离谱。2.3 两者的配置顺序有讲究正确的顺序是先 Keystone 后 RabbitMQ原因很实际Keystone 装好后你可以立刻验证认证是否正常而 RabbitMQ 的用户权限配置需要你确认服务账号已经存在。如果你先配 RabbitMQ 再装 Keystone中间出了问题你分不清是消息队列的锅还是认证的锅。另外Nova 的配置文件里[DEFAULT]段的transport_url和[keystone_authtoken]段是分开写的但服务启动时会先连 Keystone 拿 token再连 RabbitMQ 发消息所以 Keystone 不通的话RabbitMQ 配得再对也没用。3. Keystone 依赖配置的完整实操3.1 数据库与基础服务的准备Keystone 自己也需要数据库。手动安装时先在 MySQL 里建库建用户CREATE DATABASE keystone; GRANT ALL PRIVILEGES ON keystone.* TO keystonelocalhost IDENTIFIED BY 你的密码; GRANT ALL PRIVILEGES ON keystone.* TO keystone% IDENTIFIED BY 你的密码;这里有个细节keystone%这条授权在多节点场景下必须加否则其他节点上的服务连不上 Keystone 的数据库。但如果你只是单机实验加localhost就够了。密码别用太简单的后面 Keystone 的配置文件里要明文写进去虽然可以加权限保护但基础强度还是要保证。装包的时候注意版本对齐。如果你用的是某个 Linux 发行版自带的 OpenStack 软件源keystone包的版本要和后面装的nova包版本匹配。我一般会先apt policy keystone看一眼可用版本确认和 Nova 是同一个 release比如都是 Wallaby 或 Yoga。版本错配是手动安装里最隐蔽的坑症状往往是服务能启动但 API 返回 500日志里报一些莫名其妙的字段缺失。3.2 keystone.conf 的关键配置项拆解配置文件在/etc/keystone/keystone.conf手动改的话重点看三个段[database] connection mysqlpymysql://keystone:你的密码控制节点IP/keystone [token] provider fernet [DEFAULT] log_dir /var/log/keystone[token]段的provider fernet是必须的。早期版本用过 UUID token但 Fernet 是现在的默认推荐它自带加密和过期机制不需要每次验证都查数据库性能好很多。配完这个之后要执行keystone-manage fernet_setup和keystone-manage credential_setup来生成密钥这两个命令分别生成 token 加密密钥和 credential 密钥缺一不可。然后初始化数据库su -s /bin/sh -c keystone-manage db_sync keystone这条命令用keystone系统用户执行避免权限问题。执行完你可以进 MySQL 看一眼keystone库里有没有生成一堆表有就说明数据库连接配置对了。3.3 引导 Keystone 服务与创建 Nova 所需账号引导命令是手动安装里最关键的一步keystone-manage bootstrap --bootstrap-password 管理密码 \ --bootstrap-admin-url http://控制节点IP:5000/v3/ \ --bootstrap-internal-url http://控制节点IP:5000/v3/ \ --bootstrap-public-url http://控制节点IP:5000/v3/ \ --bootstrap-region-id RegionOne这条命令做了三件事创建 admin 项目、创建 admin 用户、把 Keystone 自己注册为服务。RegionOne是区域名单区域部署随便填但多区域时要和后续 Nova 的配置对应上。接下来创建 Nova 需要的项目和服务账号。Nova 各服务之间通信用的是nova用户这个用户要有service项目的admin角色openstack project create --domain default --description Service Project service openstack user create --domain default --password nova服务密码 nova openstack role add --project service --user nova admin然后注册 Nova 的服务和 endpointopenstack service create --name nova --description OpenStack Compute compute openstack endpoint create --region RegionOne compute public http://控制节点IP:8774/v2.1 openstack endpoint create --region RegionOne compute internal http://控制节点IP:8774/v2.1 openstack endpoint create --region RegionOne compute admin http://控制节点IP:8774/v2.1注意endpoint 的 URL 末尾是/v2.1不是/v2。Nova 的 API 版本是 2.1填错了后面openstack命令行工具会报版本不匹配。3.4 验证 Keystone 是否真的可用配完别急着往下走先验证。最直接的方式是设置环境变量然后查服务列表export OS_USERNAMEadmin export OS_PASSWORD管理密码 export OS_PROJECT_NAMEadmin export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_DOMAIN_NAMEDefault export OS_AUTH_URLhttp://控制节点IP:5000/v3 export OS_IDENTITY_API_VERSION3 openstack token issue openstack service listtoken issue能返回一个 token 就说明认证链路通了。service list里应该能看到keystone和nova两个服务。如果token issue报 401大概率是密码错了或者OS_AUTH_URL的版本路径不对如果报连接拒绝检查 Keystone 服务是否真的在 5000 端口监听ss -tlnp | grep 5000看一眼。4. RabbitMQ 的安装与 Nova 专用配置4.1 安装与基础服务启动RabbitMQ 的安装相对简单但依赖 Erlang包管理器一般会自动处理apt install rabbitmq-server systemctl enable rabbitmq-server systemctl start rabbitmq-server启动后默认监听 5672 端口AMQP 协议和 15672 端口管理界面需要单独启用插件。手动安装场景下我强烈建议启用管理插件rabbitmq-plugins enable rabbitmq_management启用后你可以用浏览器访问http://控制节点IP:15672默认账号密码都是guest。但guest账号只能从 localhost 登录远程访问会被拒绝这是 RabbitMQ 的安全默认值。所以下一步必须创建 Nova 专用账号。4.2 创建 vhost、用户与权限的完整流程先建 vhost我习惯命名为nova和组件对应rabbitmqctl add_vhost nova rabbitmqctl add_user nova nova消息队列密码 rabbitmqctl set_permissions -p nova nova .* .* .* rabbitmqctl set_user_tags nova administratorset_permissions的三个.*分别对应 configure、write、read 权限。生产环境可以收紧但手动安装初期用全权限能减少排查干扰等跑通后再按需限制。set_user_tags给administrator标签是为了让这个用户能在管理界面看到所有队列状态方便调试。这里有个实操心得vhost 名字和用户名可以一样但密码一定要和 Keystone 里 nova 用户的密码区分开。我见过有人图省事全用同一个密码结果后面排查问题时分不清是认证失败还是消息队列认证失败日志里两种错误长得太像了。4.3 Nova 配置文件里的 transport_url 怎么写Nova 的主配置文件/etc/nova/nova.conf里[DEFAULT]段需要写[DEFAULT] transport_url rabbit://nova:nova消息队列密码控制节点IP:5672/nova这个 URL 的结构是rabbit://用户名:密码主机:端口/vhost。注意 vhost 是放在路径里的不是查询参数。如果密码里有特殊字符比如、/需要做 URL 编码否则解析会出错。我一般建议密码只用字母数字省得折腾编码。[oslo_messaging_rabbit]段还有一些可选调优项手动安装初期可以先不碰但有两个值得关注[oslo_messaging_rabbit] rabbit_retry_interval 1 rabbit_retry_backoff 2 rabbit_max_retries 0rabbit_max_retries 0表示无限重试配合前两个参数实现指数退避。这个配置在服务启动时 RabbitMQ 还没完全就绪的场景下很有用能避免 Nova 服务因为连不上队列直接退出。默认值其实也够用但如果你遇到服务启动顺序问题调这三个参数比反复重启服务有效。4.4 用命令行验证消息队列连通性配完后别只看配置文件实际验证一下。最直接的方式是用rabbitmqctl看连接rabbitmqctl list_connections rabbitmqctl list_queues -p nova name messages如果 Nova 服务还没启动list_connections是空的这正常。你可以先用一个简单脚本测试认证rabbitmqadmin -H 控制节点IP -u nova -p nova消息队列密码 -V nova list queuesrabbitmqadmin是管理插件提供的命令行工具能列出队列就说明用户、密码、vhost、权限全对了。如果报ACCESS_REFUSED回去检查set_permissions是不是漏了-p nova参数——这个参数指定 vhost漏了就会配到默认的/vhost 上而 Nova 连的是novavhost自然对不上。5. 两个组件联调时的常见问题与排查实录5.1 服务启动顺序引发的连锁报错手动安装时最容易遇到的问题是Nova 服务启动了但日志里反复报AMQP connection refused或者Unable to establish connection to Keystone。这通常不是配置错了而是启动顺序问题。Keystone 和 RabbitMQ 必须先于所有 Nova 服务就绪。我的做法是写一个简单的检查脚本在启动 Nova 之前跑一遍#!/bin/bash # 检查 Keystone curl -s -o /dev/null -w %{http_code} http://控制节点IP:5000/v3 | grep -q 200 || echo Keystone 未就绪 # 检查 RabbitMQ rabbitmqctl status /dev/null 21 || echo RabbitMQ 未就绪两个都返回正常再启动 Nova。这个习惯能省掉大量“服务起了又挂”的无效排查。5.2 认证失败与消息队列失败的区分方法这两种失败在 Nova 日志里都表现为服务起不来但错误关键词不同。Keystone 相关的问题通常包含Unauthorized、401、Invalid token、Could not find serviceRabbitMQ 相关的问题包含AMQP、Connection refused、ACCESS_REFUSED、NOT_ALLOWED。我整理了一个速查表实际排查时对着看能快速定位日志关键词大概率原因排查动作Unauthorized/401Keystone 密码错或 token 过期用openstack token issue验证账号密码Could not find serviceNova 的 service/endpoint 没注册openstack service list确认 nova 存在AMQP connection refusedRabbitMQ 没启动或端口不通ss -tlnp | grep 5672检查监听ACCESS_REFUSEDRabbitMQ 用户权限或 vhost 不对rabbitmqctl list_permissions -p novaNOT_ALLOWED用户没有对应 vhost 的访问权限重新执行set_permissions5.3 几个我踩过的坑和独家避坑技巧第一个坑是Fernet 密钥没生成就启动 Keystone。症状是 Keystone 能启动但token issue报 500日志里说找不到密钥文件。解决方法是回到keystone-manage fernet_setup那一步确认/etc/keystone/fernet-keys/目录下有文件生成。这个目录的权限也要注意必须是keystone用户可读。第二个坑是RabbitMQ 的loopback_users配置。默认情况下guest用户只能本地登录但如果你创建的新用户也遇到远程连不上检查/etc/rabbitmq/rabbitmq.conf里有没有loopback_users相关配置。新版本 RabbitMQ 默认只限制guest但老版本可能行为不同。我一般直接在新用户上测试不依赖guest。第三个坑比较隐蔽Nova 配置文件的段名拼写。[keystone_authtoken]这个段名里是下划线不是连字符也不是驼峰。我见过有人写成[keystone-authtoken]服务启动不报错但认证永远失败因为配置根本没被读取。这种问题只能靠仔细核对官方文档的示例来避免。提示每次改完nova.conf启动服务前先用nova-api --config-file /etc/nova/nova.conf --debug前台跑一下能看到配置解析的详细过程比直接systemctl start然后翻日志高效得多。6. 配置完成后的验收清单与后续衔接6.1 一份可以直接照着勾的验收清单在进入 Nova 实际安装之前我建议按这个清单逐项确认全部打勾再往下走Keystone 的token issue能正常返回 tokenopenstack service list能看到keystone和novaopenstack endpoint list里 nova 的 public/internal/admin 三个 endpoint 都存在且 URL 正确RabbitMQ 的novavhost 存在nova用户有全权限rabbitmqadmin -V nova list queues能正常执行nova.conf里transport_url的 vhost 和 RabbitMQ 里建的一致nova.conf里[keystone_authtoken]段的用户名、密码、项目名和 Keystone 里创建的一致这份清单看着简单但每一条都对应一个实际会卡住人的点。尤其是 endpoint 的 URL 和transport_url的 vhost这两个地方的手误率最高。6.2 从依赖配置到 Nova 服务启动的衔接要点这两个组件配好后Nova 的安装其实就顺了。nova-api启动时会先向 Keystone 注册自己如果配置了[service_user]段的话然后连 RabbitMQ 开始监听消息。nova-compute启动时会通过 RabbitMQ 向nova-conductor报到同时用 Keystone 的 service token 做身份确认。这里有个衔接细节值得提前知道Nova 的[keystone_authtoken]段里除了username、password、project_name还需要auth_url、auth_type、memcached_servers等参数。memcached_servers指向的 memcached 服务如果没装token 缓存会失效虽然不影响功能但性能会差。手动安装时可以先不配 memcached等基础跑通再补。另外[service_user]段是 Nova 服务之间互相认证用的和[keystone_authtoken]是两套配置。前者用于服务间调用后者用于接收外部请求时的 token 校验。手动安装初期可以只配[keystone_authtoken]等需要跨服务调用时再补[service_user]。这个区分在官方文档里写得比较分散我第一次配的时候在这两个段之间来回折腾了很久。我个人在实际操作中的体会是手动装 OpenStack 最耗时的部分从来不是敲命令而是理解每个配置项在组件协作中的位置。RabbitMQ 和 Keystone 这两块地基打好了后面 Nova 的各个服务就像积木一样往上搭出问题也容易定位——因为你知道消息从哪来、认证走哪条路。反过来如果这两块是糊里糊涂配过去的后面任何一个服务起不来你都得从头排查那才是真正的噩梦。所以宁可在这两步多花半小时验证也别急着往下冲。