1. 为什么在 CentOS 7 上部署 Nova 控制节点现在依然值得花时间啃透OpenStack 这个词最近几年在公有云大厂的宣传里确实淡了但如果你真去翻一翻国内中大型企业的 IT 架构图、金融行业灾备系统文档、高校超算中心的运维日志或者制造业私有云平台的交付清单Nova 的服务进程依然稳稳跑在成百上千台物理服务器上。它不是过时的技术而是被“封装”得足够深——你用的某款国产云管平台底层调度虚拟机的那层逻辑大概率还是 Nova 的 API 在说话。而 CentOS 7虽然官方支持已结束但它在存量生产环境中的占比远比任何一份市场报告里的数字更真实。我去年帮一家省级电力公司做云平台健康检查光是核心业务区就还有 47 台运行着 CentOS 7.9 OpenStack Queens 的控制节点它们不 flashy但必须稳如磐石。所以这篇教程不讲“要不要学”只讲“怎么让它真正跑起来”。不是照着官网文档复制粘贴完就宣告成功而是把那些藏在openstack-config命令背后、藏在/var/log/nova/日志末尾、藏在systemctl status状态码里的真实细节一层层剥开。比如为什么nova-api启动后立刻报Failed to bind port为什么nova-conductor日志里反复出现No valid host was found却查不到具体原因为什么nova list返回空但nova service-list显示所有服务都是up这些都不是配置错了而是对 Nova 服务间依赖关系、数据库状态同步机制、以及消息队列心跳逻辑的理解偏差。本篇会从一个干净的 CentOS 7.9 最小化安装开始不依赖任何一键脚本每一步命令都告诉你它在改变什么、为什么必须这样改、如果跳过会埋下什么雷。你不需要记住所有参数但要理解每个环节在 Nova 整体架构里扮演的角色——它不是孤立的服务而是连接 Keystone认证、Glance镜像、Neutron网络和 Placement资源追踪的中枢神经。2. 环境准备从裸机到可部署状态的硬核清理与加固很多人卡在第一步不是因为不会敲命令而是因为没意识到 CentOS 7 的“默认状态”和 OpenStack 的“生产要求”之间横亘着一条由 SELinux 策略、防火墙规则、时间同步精度和内核模块组成的鸿沟。跳过这一步后面所有配置都是在流沙上盖楼。2.1 系统初始化最小化安装后的必做五件事假设你已经通过 VMware 或物理服务器完成了 CentOS 7.9 的最小化安装并获得了 root 权限。请先执行以下操作顺序不能乱# 1. 关闭 NetworkManager启用传统 network 服务OpenStack 组件对 NM 的兼容性极差 systemctl stop NetworkManager systemctl disable NetworkManager systemctl start network systemctl enable network # 2. 配置静态 IP 和主机名以实际环境为准这里用示例 echo 192.168.10.10 controller /etc/hosts hostnamectl set-hostname controller # 编辑 /etc/sysconfig/network-scripts/ifcfg-ens33确保包含 # BOOTPROTOstatic # IPADDR192.168.10.10 # NETMASK255.255.255.0 # GATEWAY192.168.10.1 # DNS1114.114.114.114 # ONBOOTyes # 3. 时间同步是 Nova 的生命线所有节点必须毫秒级一致 yum install -y chrony sed -i s/^pool.*/pool ntp.aliyun.com iburst/g /etc/chrony.conf systemctl enable chronyd systemctl start chronyd chronyc sources -v # 确认输出中有 ^* 表示已同步 # 4. 关闭防火墙生产环境应配置白名单但初学务必先关避免干扰 systemctl stop firewalld systemctl disable firewalld # 5. 关闭 SELinux临时方案生产环境需编写自定义策略但新手阶段强行开启只会无限报错 setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config提示chrony同步状态必须为^*而不是^或^-。我见过太多次因为时间不同步导致nova-scheduler拒绝接收nova-compute的资源汇报最终nova list为空。这不是 bug是设计使然——OpenStack 认为时间漂移超过 3 秒的节点不可信。2.2 软件源与基础依赖绕过repomd.xml: [errno 14]的实战解法热搜词里反复出现http://mirrors.aliyun.com/centos/7/os/x86_64/repodata/repomd.xml: [errno 14]这根本不是网络问题而是 CentOS 7 默认启用了fastestmirror插件它会尝试 ping 所有镜像站并选择最快的但在企业内网或某些虚拟化环境中ping 被禁用插件就卡死。解决方案是彻底禁用它并手动指定稳定源# 禁用 fastestmirror sed -i s/enabled1/enabled0/g /etc/yum/pluginconf.d/fastestmirror.conf # 备份原 repo 文件 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak # 创建新 repo使用阿里云稳定且国内访问快 cat /etc/yum.repos.d/CentOS-Base.repo EOF [base] nameCentOS-$releasever - Base - mirrors.aliyun.com failovermethodpriority baseurlhttp://mirrors.aliyun.com/centos/7/os/$basearch/ gpgcheck1 gpgkeyhttp://mirrors.aliyun.com/centos/7/os/$basearch/RPM-GPG-KEY-CentOS-7 [updates] nameCentOS-$releasever - Updates - mirrors.aliyun.com failovermethodpriority baseurlhttp://mirrors.aliyun.com/centos/7/updates/$basearch/ gpgcheck1 gpgkeyhttp://mirrors.aliyun.com/centos/7/updates/$basearch/RPM-GPG-KEY-CentOS-7 [extras] nameCentOS-$releasever - Extras - mirrors.aliyun.com failovermethodpriority baseurlhttp://mirrors.aliyun.com/centos/7/extras/$basearch/ gpgcheck1 gpgkeyhttp://mirrors.aliyun.com/centos/7/extras/$basearch/RPM-GPG-KEY-CentOS-7 EOF yum clean all yum makecache注意failovermethodpriority是关键它让 yum 按 baseurl 列表顺序尝试而不是盲目 ping。很多教程只教换源却不提这个参数结果换完还是报错。2.3 OpenStack 仓库与 Python 环境Rocky 版本的精准锚定OpenStack 版本迭代极快但 Rocky2018 年发布是 CentOS 7 上最成熟、文档最全、社区支持最久的 LTS 级别版本。它完美适配 Python 2.7CentOS 7 默认避免了后续版本因 Python 3 迁移带来的无数兼容性问题。添加仓库yum install -y centos-release-openstack-rocky yum update -y # 此步会升级 kernel 和关键库重启是必须的 reboot重启后验证仓库是否生效yum repolist | grep openstack # 应看到类似centos-openstack-rocky/7/x86_64 CentOS OpenStack Rocky此时系统已准备好安装 Nova。但请记住我们安装的是openstack-nova-api、openstack-nova-conductor、openstack-nova-scheduler、openstack-nova-novncproxy这四个控制节点核心服务不包括openstack-nova-compute那是计算节点干的活。混淆这两者是初学者最大的认知陷阱。3. 数据库与消息队列Nova 的“心脏”与“神经”Nova 不是单体应用它由多个独立进程组成它们之间不直接通信而是通过共享数据库存储状态和消息队列传递指令来协作。把这俩搞砸整个 Nova 就是瘫痪的。3.1 MySQL 数据库创建专用库与用户OpenStack 官方推荐 MariaDBMySQL 兼容分支CentOS 7 自带。我们不复用 root而是为 Nova 创建专属账户这是安全底线# 启动并设为开机自启 systemctl enable mariadb systemctl start mariadb # 运行安全初始化按提示设置 root 密码其他全选 Y mysql_secure_installation # 登录 MySQL创建 nova 库和用户 mysql -u root -p在 MySQL 提示符下执行-- 创建 nova 数据库字符集必须是 utf8mb4否则中文镜像名会乱码 CREATE DATABASE nova_api CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE DATABASE nova CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE DATABASE nova_cell0 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 创建 nova 用户密码设为 nova123生产环境必须用强密码 CREATE USER novalocalhost IDENTIFIED BY nova123; CREATE USER nova% IDENTIFIED BY nova123; -- 授予所有 nova 库的全部权限 GRANT ALL PRIVILEGES ON nova_api.* TO novalocalhost; GRANT ALL PRIVILEGES ON nova.* TO novalocalhost; GRANT ALL PRIVILEGES ON nova_cell0.* TO novalocalhost; GRANT ALL PRIVILEGES ON nova_api.* TO nova%; GRANT ALL PRIVILEGES ON nova.* TO nova%; GRANT ALL PRIVILEGES ON nova_cell0.* TO nova%; FLUSH PRIVILEGES; EXIT;提示nova_cell0是 Nova 的“细胞零号”用于存放无法被调度的实例如故障迁移失败的实例它必须存在且结构完整。很多教程漏掉这一步导致后续nova-manage db sync报错。3.2 RabbitMQ 消息队列配置高可用与权限RabbitMQ 是 Nova 进程间通信的“快递员”。它不存储数据但必须保证消息不丢失、不重复、不乱序。CentOS 7 默认仓库的 RabbitMQ 版本太低需手动安装# 添加 Erlang 仓库RabbitMQ 依赖 yum install -y https://github.com/rabbitmq/erlang-rpm/releases/download/v23.3.4.11/erlang-23.3.4.11-1.el7.x86_64.rpm # 添加 RabbitMQ 仓库 curl -s https://packagecloud.io/install/repositories/rabbitmq/rabbitmq-server/script.rpm.sh | bash # 安装 yum install -y rabbitmq-server # 启动并设为开机自启 systemctl enable rabbitmq-server systemctl start rabbitmq-server # 启用管理插件方便后续排查 rabbitmq-plugins enable rabbitmq_management # 创建 nova 用户并设置权限这是最关键的一步 rabbitmqctl add_user openstack RABBIT_PASS # RABBIT_PASS 替换为你想设的密码如 openstack123 rabbitmqctl set_permissions openstack .* .* .* rabbitmqctl set_user_tags openstack administrator注意set_permissions命令中的三个.*分别对应配置configure、写write、读read权限。少一个.*nova-scheduler就无法向队列发送调度请求nova-conductor也无法读取响应。这是nova service-list显示down的最常见原因之一。3.3 初始化 Nova 数据库执行迁移脚本的完整链路数据库和消息队列就绪后才能让 Nova 知道“该往哪里存、往哪里发”。这一步调用nova-manage工具它会读取配置文件连接数据库执行一系列 SQL 迁移脚本# 安装 Nova 服务包注意只装控制节点组件 yum install -y openstack-nova-api openstack-nova-conductor openstack-nova-novncproxy openstack-nova-scheduler # 编辑主配置文件 vim /etc/nova/nova.conf在/etc/nova/nova.conf中必须配置以下核心段落其他段落可先留空后续再补[DEFAULT] # 基础标识 transport_url rabbit://openstack:RABBIT_PASScontroller:5672/ my_ip 192.168.10.10 use_neutron true firewall_driver nova.virt.firewall.NoopFirewallDriver [api_database] # 指向 nova_api 库 connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova_api [database] # 指向 nova 主库 connection mysqlpymysql://nova:NOVA_DBPASScontroller/nova [placement_database] # Rocky 版本 Placement 服务尚未独立此段暂不配置留空 [api] auth_strategy keystone [keystone_authtoken] # 此处先占位Keystone 未部署完暂时注释掉等 Keystone 部署后再填 # auth_url http://controller:5000/v3 # memcached_servers controller:11211 # auth_type password # project_domain_name Default # user_domain_name Default # project_name service # username nova # password NOVA_PASS [nova_metadata] # 控制节点不运行 metadata 服务但配置必须存在 metadata_proxy_shared_secret METADATA_SECRET [vnc] enabled true server_listen $my_ip server_proxyclient_address $my_ip [glance] api_servers http://controller:9292 [oslo_concurrency] lock_path /var/lib/nova/tmp [placement] # Rocky 版本 Placement 与 Nova 深度集成必须配置 region_name RegionOne project_domain_name Default project_name service auth_type password user_domain_name Default auth_url http://controller:5000/v3 username placement password PLACEMENT_PASS提示NOVA_DBPASS是你在 MySQL 里给nova用户设的密码如nova123RABBIT_PASS是 RabbitMQ 的openstack用户密码PLACEMENT_PASS是稍后 Keystone 中为placement用户设的密码。所有密码必须严格一致且不能含特殊字符如 , /, $否则 URL 解析会失败。配置完成后执行数据库同步# 替换密码占位符用你实际设的密码 sed -i s/NOVA_DBPASS/nova123/g /etc/nova/nova.conf sed -i s/RABBIT_PASS/openstack123/g /etc/nova/nova.conf # 执行数据库初始化会创建所有表结构 su -s /bin/sh -c nova-manage api_db sync nova su -s /bin/sh -c nova-manage db sync nova # 验证 cell0 注册必须看到 0 cells configured su -s /bin/sh -c nova-manage cell_v2 list_cells nova如果list_cells输出为空或报错说明nova_cell0库未正确初始化需回到 MySQL 步骤检查。4. Keystone 认证集成让 Nova “认得清谁是谁”Nova 本身不负责用户登录它把所有认证请求都转发给 Keystone。没有 KeystoneNova 就是一堆无法被调用的“哑巴”进程。因此在启动 Nova 服务前必须完成 Keystone 的最小化部署并为 Nova 创建服务凭证。4.1 Keystone 最小化部署仅启用 v3 APIyum install -y openstack-keystone httpd mod_wsgi # 编辑 Keystone 配置 vim /etc/keystone/keystone.conf在[database]段配置数据库连接[database] connection mysqlpymysql://keystone:KEYSTONE_DBPASScontroller/keystone在[token]段配置 Fernet 密钥比 UUID 更安全[token] provider fernet初始化数据库su -s /bin/sh -c keystone-manage db_sync keystone keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone keystone-manage credential_setup --keystone-user keystone --keystone-group keystone引导 Keystonekeystone-manage bootstrap --bootstrap-password ADMIN_PASS \ --bootstrap-admin-url http://controller:5000/v3/ \ --bootstrap-internal-url http://controller:5000/v3/ \ --bootstrap-public-url http://controller:5000/v3/ \ --bootstrap-region-id RegionOne配置 Apacheln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/ # 启动 Apache systemctl enable httpd systemctl start httpd4.2 创建 Nova 服务凭证三步走的黄金法则Keystone 部署后必须为 Nova 创建一个service项目、nova用户、admin角色并将三者关联。这是 OpenStack RBAC基于角色的访问控制的核心实践# 设置临时环境变量避免每次输密码 export OS_USERNAMEadmin export OS_PASSWORDADMIN_PASS export OS_PROJECT_NAMEadmin export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_DOMAIN_NAMEDefault export OS_AUTH_URLhttp://controller:5000/v3 export OS_IDENTITY_API_VERSION3 # 1. 创建 service 项目 openstack project create --domain default --description Service Project service # 2. 创建 nova 用户密码设为 nova123 openstack user create --domain default --password-prompt nova # 输入密码nova123 # 3. 将 admin 角色赋予 nova 用户在 service 项目中 openstack role add --project service --user nova admin # 4. 创建 nova 服务实体typecompute 是 Nova 的标识 openstack service create --name nova --description OpenStack Compute compute # 5. 创建 nova 服务端点public/internal/admin 三个 URL 必须都注册 openstack endpoint create --region RegionOne compute public http://controller:8774/v2.1/%\(tenant_id\)s openstack endpoint create --region RegionOne compute internal http://controller:8774/v2.1/%\(tenant_id\)s openstack endpoint create --region RegionOne compute admin http://controller:8774/v2.1/%\(tenant_id\)s # 6. 创建 placement 服务Nova Rocky 依赖 Placement openstack user create --domain default --password-prompt placement # 输入密码placement123 openstack role add --project service --user placement admin openstack service create --name placement --description Placement API placement openstack endpoint create --region RegionOne placement public http://controller:8778 openstack endpoint create --region RegionOne placement internal http://controller:8778 openstack endpoint create --region RegionOne placement admin http://controller:8778提示%\(tenant_id\)s中的反斜杠\是必须的它是 shell 转义符防止被提前解析。漏掉它端点 URL 会变成错误的字符串。4.3 回填 Nova 配置激活 Keystone 认证现在回到/etc/nova/nova.conf取消注释并填写[keystone_authtoken]段[keystone_authtoken] www_authenticate_uri http://controller:5000 auth_url http://controller:5000 memcached_servers controller:11211 auth_type password project_domain_name Default user_domain_name Default project_name service username nova password nova123同时更新[placement]段的密码[placement] ... username placement password placement123最后重启所有 Nova 服务systemctl enable openstack-nova-api openstack-nova-scheduler openstack-nova-conductor openstack-nova-novncproxy systemctl start openstack-nova-api openstack-nova-scheduler openstack-nova-conductor openstack-nova-novncproxy5. 服务验证与排错从nova service-list到nova list的全链路诊断启动服务只是开始真正的考验是验证它们是否健康、能否协同工作。nova service-list和nova list是两个完全不同的检查维度必须分开理解。5.1nova service-list检查 Nova 内部服务的“心跳”# 设置环境变量指向 admin 用户 export OS_USERNAMEadmin export OS_PASSWORDADMIN_PASS export OS_PROJECT_NAMEadmin export OS_USER_DOMAIN_NAMEDefault export OS_PROJECT_DOMAIN_NAMEDefault export OS_AUTH_URLhttp://controller:5000/v3 export OS_IDENTITY_API_VERSION3 # 执行检查 openstack compute service list正常输出应类似---------------------------------------------------------------------------------------- | Id | Binary | Host | Zone | Status | State | Updated At | ---------------------------------------------------------------------------------------- | 1 | nova-scheduler | controller | internal | enabled | up | 2024-05-20T08:12:34.000000 | | 2 | nova-conductor | controller | internal | enabled | up | 2024-05-20T08:12:35.000000 | | 3 | nova-consoleauth | controller | internal | enabled | up | 2024-05-20T08:12:36.000000 | | 4 | nova-novncproxy | controller | internal | enabled | up | 2024-05-20T08:12:37.000000 | ----------------------------------------------------------------------------------------关键指标解读Status enabled表示服务被管理员允许运行可通过openstack compute service set --disable关闭。State up表示服务进程正在运行且能向数据库写入心跳updated_at时间戳在持续更新。Zone internal表示这是内部服务不对外提供计算资源。如果某个服务显示down不要第一反应去systemctl restart。先查日志# 查看 nova-scheduler 日志以 scheduler 为例 tail -f /var/log/nova/nova-scheduler.log # 常见错误ConnectionRefusedError: [Errno 111] Connection refused # 这意味着它连不上 RabbitMQ检查 rabbitmq-server 是否运行密码是否正确5.2nova list检查 Nova 与外部服务的“握手”nova list返回空列表绝不等于 Nova 没运行。它只表示当前没有任何实例被创建。但如果你刚创建了一个实例却看不到问题就出在 Nova 与 Glance镜像、Neutron网络、Placement资源的集成上。排错黄金三步法检查 Placement API 是否可达curl -H X-Auth-Token: $(openstack token issue -f value -c id) http://controller:8778/resource_providers # 应返回一个 JSON 数组包含 resource_providers 列表检查 Glance 镜像是否可访问openstack image list # 如果报错 Unable to establish connection to http://controller:9292, 说明 nova.conf 中的 glance.api_servers 配置错误或 Glance 服务未启动检查 Neutron 网络是否注册openstack network list # Nova 本身不管理网络但它需要 Neutron 提供的网络 ID 来启动实例。如果此命令报错nova boot 必然失败。5.3 实战排错案例No valid host was found的根因定位这是 Nova 最经典的报错表面看是调度失败实则可能源于五个不同层面层面检查命令典型表现解决方案Placement 资源不足openstack resource provider listtotal字段为 0运行nova-manage cell_v2 discover_hosts计算节点未注册openstack compute service list | grep compute无输出或Statedown检查计算节点nova-compute服务及日志主机过滤器拒绝grep filter /var/log/nova/nova-scheduler.logFilter RamFilter returned 0 hosts调整nova.conf中ram_allocation_ratio网络不可达openstack port list --network net-id无输出检查 Neutron agent 状态openstack network agent list安全组规则冲突openstack security group rule list default缺少 ICMP 或 SSH 规则openstack security group rule create --proto icmp default我的经验90% 的No valid host问题根源在 Placement。因为nova-scheduler在调度前会先向 Placement 查询resource_providers和usages。如果 Placement 数据库为空它就认为“全世界都没有资源”直接放弃调度。所以nova-manage cell_v2 discover_hosts这条命令不是可选项是必选项。6. 启动第一个实例从nova boot到 VNC 控制台的端到端验证当所有服务都显示up且 Placement、Glance、Neutron 均验证通过就可以启动第一个实例了。这不仅是功能验证更是对整个控制节点配置的终极压力测试。6.1 准备前置资源镜像、密钥、网络、安全组# 1. 下载 Cirros 镜像轻量适合测试 wget http://download.cirros-cloud.net/0.6.2/cirros-0.6.2-x86_64-disk.img # 2. 上传镜像到 Glance openstack image create cirros \ --file cirros-0.6.2-x86_64-disk.img \ --disk-format qcow2 --container-format bare \ --public # 3. 创建密钥对用于 SSH 登录 ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa_nova -N openstack keypair create --public-key ~/.ssh/id_rsa_nova.pub mykey # 4. 创建网络Provider 网络直连物理网络 openstack network create --share --external \ --provider-physical-network provider \ --provider-network-type flat provider openstack subnet create --network provider \ --allocation-pool start192.168.10.100,end192.168.10.200 \ --dns-nameserver 114.114.114.114 --gateway 192.168.10.1 \ provider-subnet --subnet-range 192.168.10.0/24 # 5. 创建安全组规则放行 ICMP 和 SSH openstack security group rule create --proto icmp default openstack security group rule create --proto tcp --dst-port 22 default6.2 启动实例与获取控制台 URL# 启动实例flavor 为 m1.tiny网络为 provider openstack server create --flavor m1.tiny --image cirros \ --nic net-id$(openstack network list | awk / provider / {print $2}) \ --key-name mykey --security-group default test-instance # 查看实例状态 openstack server list # 等待状态变为 ACTIVE # 获取 VNC 控制台 URL openstack console url show test-instance # 输出类似-------------------------------------------------------------------------------------------- # | Field | Value | # -------------------------------------------------------------------------------------------- # | type | novnc | # | url | http://controller:6080/vnc_auto.html?tokenxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | # --------------------------------------------------------------------------------------------6.3 访问 VNC 控制台解决Connection refused的最后一公里拿到 URL 后在浏览器打开如果提示Connection refused问题一定出在nova-novncproxy服务或其依赖上确认nova-novncproxy服务状态systemctl status openstack-nova-novncproxy—— 必须为active (running)。检查监听端口ss -tlnp | grep :6080—— 应看到nova-novncproxy进程在监听0.0.0.0:6080。检查nova.conf中的vnc配置server_listen必须是0.0.0.0或controller的 IPserver_proxyclient_address必须是controller的 IP即192.168.10.10。检查防火墙即使关了也确认下iptables -L -n | grep 6080—— 确保无 DROP 规则。一旦 VNC 页面成功加载并看到 Cirros 的登录提示login as cirros输入密码gocubsgo你就完成了 CentOS 7 上 Nova 控制节点的完整闭环验证。这不是一个玩具而是 OpenStack 云平台最核心的调度引擎它正安静地运行在你的服务器上等待承载真实的业务负载。7. 后续演进与生产加固从实验室到数据中心的必经之路部署成功只是起点。在真实生产环境中你马上会面临几个无法回避的问题如何让 Nova 在单点故障时继续服务如何监控它每秒处理多少请求如何审计每一次虚拟机的创建操作这些问题的答案构成了从“能用”到“好用”的分水岭。7.1 高可用HA的务实路径从双节点起步单控制节点是学习的起点但生产环境必须考虑 HA。最务实的方案是部署双控制节点controller1/controller2共享同一个 MySQL 集群如 MHA和 RabbitMQ 集群镜像队列。关键在于nova.conf的微调my_ip改为各自节点的真实 IP。transport_url指向 RabbitMQ 集群 VIP如rabbit://openstack:passrabbit-vip:5672/。scheduler_max_attempts从默认 3 提高到 5增加重试韧性。所有openstack-nova-*服务均需在两台节点上启动nova-scheduler会自动进行 leader 选举。提示不要一上来就搞 PacemakerCorosync。对于中小规模云MySQL 主从 RabbitMQ 镜像队列 Keepalived 虚拟 IP就能解决 80% 的可用性问题且运维复杂度可控。7.2 监控与告警盯住nova-api的 99th 百分位延迟nova-api是所有请求的入口它的延迟是用户体验的晴雨表。我习惯用 Prometheus Grafana 监控核心指标nova_api_request_duration_seconds_bucket{le1.0}1 秒内完成的请求比例。告警阈值当rate(nova_api_request_duration_seconds_count[5m])低于 95%或histogram_quantile(0.99, rate(nova_api_request_duration_seconds_bucket[5m])) 2.0时触发告警。日志采集Filebeat 收集/var/log/nova/nova-api.log过滤ERROR和WARNING级别事件。7.3 审计与合规开启 Nova 的详细操作日志默认情况下Nova 只记录 ERROR/WARNING。要满足等保要求需开启 INFO 级别并记录所有 API 请求# 在 /etc/nova/nova.conf 的 [DEFAULT] 段添加 log_level INFO # 在 [oslo_messaging_notifications] 段添加 driver messagingv2 topics notifications然后重启nova-api。所有POST /servers、DELETE /servers/{id}等操作都会在日志中留下完整 trace_id便于事后溯源。最后分享一个小技巧当你需要快速验证