1. OpenStack Placement 服务为什么它不是“可有可无”的配角而是云平台调度的真正中枢你有没有遇到过这样的情况在 OpenStack 云平台上创建虚拟机时明明计算节点还有大量空闲 CPU 和内存nova-scheduler 却死活找不到合适的宿主机或者你给虚拟机指定了一个特定的 Cinder 存储卷结果 nova 却把虚拟机调度到了完全不连通该存储后端的计算节点上导致启动失败又或者你想把一批需要 SR-IOV 网卡的高性能虚拟机只部署在配备了特定网卡型号的服务器上但现有的过滤器Filter却束手无策这些看似“玄学”的调度失败其根源往往不在 Nova 本身而在于一个被很多初学者和运维人员严重低估的服务——Placement。Placement 不是 Nova 的一个子模块也不是一个锦上添花的监控插件。它是从 OpenStack Pike 版本起就强制启用、并在 Stein 版本彻底独立出来的核心基础设施服务。它的存在直接回答了云平台最根本的一个问题“我的资源到底在哪里还剩多少” 在 Placement 出现之前Nova 的 Resource Tracker 只能“数自己家的米”——它只知道计算节点本地的 CPU、内存、磁盘对于由 Cinder 提供的块存储、由 Neutron 提供的网络端口、甚至是由外部 SDS软件定义存储或 NFV网络功能虚拟化设备提供的资源它一概不知。这就像一个只认识自家仓库管理员的采购经理却要负责为整个集团的工厂调配所有原材料其结果必然是混乱与低效。Placement 的核心价值就在于它构建了一个统一、抽象、可扩展的“资源账本”。它将一切可以被消费的实体——无论是物理服务器、GPU 卡、SR-IOV 虚拟功能VF、共享存储池还是一个逻辑上的网络子网——都抽象为一个Resource Provider资源提供者。每个 Resource Provider 都拥有自己的Inventory库存即它能提供多少种资源VCPU、MEMORY_MB、DISK_GB、SRIOV_NET_VF每种资源的总容量和当前已用量是多少同时它还拥有自己的Traits特征标签用来描述其独一无二的属性HW_CPU_X86_AVX2、CUSTOM_HIGH_PERF、MISC_SHARES_VIA_AGGREGATE。当用户发起一个创建虚拟机的请求时nova-scheduler 不再是凭经验“猜”而是向 Placement API 发起一个精确的查询“我需要 2 个 VCPU、4096MB 内存、50GB 磁盘并且这个节点必须支持 AVX2 指令集和 SR-IOV 网络”Placement 则会返回一份详尽的Allocation Candidates分配候选人清单其中不仅列出了哪些资源提供者能满足要求还精确地告诉你它们各自的资源使用率和特征。这才是现代云平台实现精细化、智能化、可编程化调度的基石。如果你正在部署一个生产级的 OpenStack 环境尤其是涉及异构硬件、多后端存储或高级网络功能的场景跳过 Placement 的部署无异于在高速公路上只画了一条虚线却指望所有车辆都能自动对齐行驶。它不是流程的一部分它就是流程本身。2. 核心设计与架构拆解Placement 如何用三层模型重构资源管理范式理解 Placement 的部署绝不能停留在“照着文档敲几行命令”的层面。必须深入其背后的设计哲学否则在后续的排错和调优中你会陷入“知其然不知其所以然”的困境。Placement 的整个架构可以用一个清晰的三层模型来概括Provider 层、Inventory/Traits 层、以及 Consumer/Allocation 层。这三层并非简单的堆叠而是环环相扣、相互制约的有机整体。2.1 Provider 层一切资源的“身份证”与“户口本”在 Placement 的世界里“资源”没有高低贵贱之分只有“提供者”Resource Provider这一种身份。一个计算节点Compute Node是一个 Provider一台物理存储服务器Cinder Backend是一个 Provider一个网络交换机上的一个端口池Neutron Port Pool同样是一个 Provider。甚至一个逻辑概念比如一个用于存放高安全级别虚拟机的“安全隔离区”Security Zone也可以被建模为一个 Provider。这种极致的抽象是 Placement 能够统一纳管所有类型资源的根本原因。每一个 Provider 都有一个全球唯一的 UUID这是它的“身份证号”。更重要的是它还有一个“户口本”即root_provider_uuid和parent_provider_uuid构成的树状结构。例如一台物理服务器Root Provider上可能插着一块 GPU 卡Child Provider而这块 GPU 卡上又划分出了多个 CUDA CoreGrandchild Provider。通过这种父子关系Placement 能够精确地追踪到一个资源请求最终消耗的是哪一块物理芯片上的哪一个计算单元。这解决了传统方案中“资源归属不清”的老大难问题。当你看到parent_provider_uuid字段为空时就意味着这是一个顶级的、不可再分割的物理资源实体。部署时我们首先要确保所有关键的 Provider尤其是计算节点都被正确地注册到 Placement 中这是整个资源账本得以建立的第一步。2.2 Inventory/Traits 层资源的“数量”与“质量”双维度刻画如果说 Provider 是资源的“人”那么 Inventory 和 Traits 就是它的“简历”。Inventory 描述的是“数量”即这个 Provider 能提供什么、能提供多少。它是一组键值对Key 是标准化的Resource Class资源类别如VCPU、MEMORY_MB、DISK_GB、SRIOV_NET_VFValue 则是一个包含total总量、reserved预留量、min_unit最小分配单位、max_unit最大分配单位和step_size步长的 JSON 对象。这里的关键在于reserved字段的存在使得 Placement 可以预留一部分资源给系统自身如 Hypervisor 开销或特定用途避免资源被完全耗尽。Traits 则描述的是“质量”即这个 Provider 具备哪些独特的、非数值化的特征。它是一组字符串标签分为两类一类是社区预定义的、以HW_或CUSTOM_开头的标准 Trait如HW_CPU_X86_AVX2另一类则是用户自定义的、以CUSTOM_为前缀的业务标签如CUSTOM_FINANCE_DEPT。Traits 的强大之处在于其组合性。你可以用requiredHW_CPU_X86_AVX2,CUSTOM_FINANCE_DEPT这样的查询条件精准地筛选出既具备高性能计算能力又归属于财务部门专属资源池的 Provider。这比传统的 Host Aggregate 更加灵活和强大因为它不依赖于 Nova 的调度逻辑而是直接作用于资源数据层。在部署配置中placement.conf文件里的[api]和[keystone_authtoken]部分本质上就是在为这个“简历”管理系统配置访问权限和认证方式确保只有经过授权的服务如 Nova才能读写这份关键的“人才档案”。2.3 Consumer/Allocation 层资源的“消费者”与“占用凭证”当一个虚拟机VM被创建时它在 Placement 的世界里就变成了一个Consumer消费者并获得一个唯一的 UUID通常就是 VM 的 instance_uuid。Consumer 本身不拥有任何资源它只是资源的“使用者”。真正的资源占用体现在Allocation分配记录上。Allocation 表是 Placement 数据库的核心它记录了每一次资源分配的“三方协议”谁consumer_id向谁resource_provider_id申请了什么resource_class_id以及多少used。这个设计极其精妙。它意味着资源的占用状态是“事件驱动”的而不是“状态轮询”的。Nova 在启动 VM 前会先向 Placement 发起一个claim_resources请求Placement 会在数据库中插入一条 Allocation 记录并原子性地更新对应 Provider 的 Inventory 使用量。如果此时另一个并发请求也想占用同一份资源Placement 会因为数据库的唯一约束或乐观锁机制而拒绝从而保证了资源分配的强一致性。这正是 Placement 能够替代 Nova 旧有过滤器CpuFilter 等的根本技术保障——它把资源调度从一个基于“猜测”的概率游戏变成了一个基于“事实”的确定性事务。部署完成后检查allocations表是否为空是验证 Placement 是否真正开始工作的第一个黄金指标。3. 核心部署环节详解从零开始构建 Placement 服务的完整实操链部署 Placement 并非一个孤立的动作它是一个嵌入在整个 OpenStack 控制节点初始化流程中的关键环节。下面我将基于 Rocky 或更高版本的 OpenStack推荐使用 Ussuri 或 Wallaby为你拆解每一个步骤背后的原理、参数选择的依据以及那些文档里绝不会写的“潜规则”。3.1 数据库准备为什么必须用 MySQL/MariaDB而非 SQLitePlacement 服务对数据库的并发读写性能和事务一致性有极高要求。虽然官方文档有时会提到 SQLite 作为开发测试选项但在任何生产环境这都是一个危险的信号。SQLite 是一个文件级数据库其锁粒度是整个数据库文件在高并发的云环境中这会导致严重的性能瓶颈和锁等待。因此我们必须使用一个真正的客户端-服务器架构的数据库如 MariaDBMySQL 的一个主流分支。# 1. 登录数据库创建专用数据库 $ mysql -u root -p MariaDB [(none)] CREATE DATABASE placement CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 2. 创建专用用户并授予权限 # 注意这里我们使用 placement% 而非 placementlocalhost # 因为在分布式部署中Placement API 可能运行在独立的控制节点上需要从网络访问数据库 MariaDB [(none)] GRANT ALL PRIVILEGES ON placement.* TO placement% IDENTIFIED BY YourStrongPassword123!; MariaDB [(none)] FLUSH PRIVILEGES;关键参数解析与避坑心得CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci这是强制要求。Placement 的某些字段如 Traits 名称可能包含 emoji 或其他四字节 Unicode 字符utf8编码在 MySQL 中实际是utf8mb3无法支持会导致插入失败。placement%这是生产环境的黄金配置。如果你错误地只授予了placementlocalhost权限那么当你的 OpenStack 环境是多节点如 controller、compute 分离时Placement 服务将无法连接数据库报错Access denied for user placementcontroller。这个错误非常隐蔽因为controller主机名在数据库看来就是一个远程 IP 地址。密码强度YourStrongPassword123!仅作示例。生产环境必须使用符合复杂度要求的密码且该密码将在后续的placement.conf配置文件中重复出现务必妥善保管。3.2 Keystone 服务注册不只是“走个过场”而是建立信任链Placement 作为一个独立的 OpenStack 服务它必须像 Nova、Glance 一样在 Keystone 的服务目录Service Catalog中注册自己以便其他服务能够发现并调用它。这个过程远不止是创建一个用户那么简单它是在 Keystone 的身份认证体系中为 Placement 建立一条完整的信任链。# 1. 加载 admin 凭据 $ source admin-openrc # 2. 创建 placement 用户注意密码必须与 placement.conf 中的配置一致 $ openstack user create --domain default --password-prompt placement # 输入密码YourPlacementPassword456! # 3. 将 placement 用户添加到 service 项目并赋予 admin 角色 # 这一步至关重要Placement API 需要 admin 权限来执行数据库同步等管理操作 $ openstack role add --project service --user placement admin # 4. 创建 Placement 服务实体 $ openstack service create --name placement --description Placement API placement # 5. 创建三个端点public, internal, admin # 这是 OpenStack 的标准实践确保不同网络区域的服务都能访问 $ 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为什么必须是admin角色Placement 的placement-manage db sync命令本质上是执行一系列 DDL数据定义语言操作如创建表、添加索引、修改字段。这些操作在 Keystone 的 RBAC基于角色的访问控制模型下只有admin角色才被授权。如果你错误地只给了member角色那么在执行数据库同步时你会收到HTTP 403 Forbidden错误提示权限不足。这是一个新手最容易踩的坑也是排查 Placement 启动失败的第一个检查点。3.3 Placement 服务安装与配置placement.conf文件的逐行精读在控制节点上安装 Placement 服务包后核心工作就是编辑/etc/placement/placement.conf文件。这个文件虽小但每一行都牵一发而动全身。[DEFAULT] # 日志级别生产环境建议设为 WARNING 或 ERROR避免日志爆炸 debug false log_dir /var/log/placement [api] # 这是 Placement API 的核心策略必须启用 Keystone 认证 auth_strategy keystone # 这个配置决定了 Placement API 的监听地址和端口 # 默认是 0.0.0.0:8778即监听所有网卡的 8778 端口 # 如果你的控制节点有多个网卡且只想让内部网络访问可以改为 bind_host 192.168.1.10 bind_host 0.0.0.0 bind_port 8778 [placement_database] # 数据库连接字符串必须与前面创建的数据库信息完全一致 # 注意connection 字符串中的密码必须是 URL 编码后的形式 # 如果你的密码包含特殊字符如 , /, :必须进行编码否则连接会失败 connection mysqlpymysql://placement:YourStrongPassword123%21controller/placement [keystone_authtoken] # 这是 Placement 服务向 Keystone 自我证明身份的凭证 # 它告诉 Keystone“我是 placement 服务我属于 service 项目” 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 placement password YourPlacementPassword456! # 这个配置非常重要它指定了 Placement 服务使用的认证域 # 必须与 Keystone 中创建的 placement 用户所在的 domain 一致 # 默认是 default但如果你们的环境使用了自定义 domain这里必须修改 domain_name default最关键的配置项connection字符串的 URL 编码这是我在无数个深夜排错后总结出的血泪教训。mysqlpymysql://连接字符串中的密码如果包含、/、:、?、#等 URL 保留字符必须进行百分号编码Percent-encoding。例如密码Pssw0rd/123必须编码为P%40ssw0rd%2F123。否则PyMySQL 会将之后的内容误认为是主机名导致连接controller失败。一个简单的方法是在配置前先用 Python 的urllib.parse.quote_plus()函数对密码进行编码 from urllib.parse import quote_plus quote_plus(Pssw0rd/123) P%40ssw0rd%2F123把这个编码后的字符串填入connection配置项就能彻底避免这个“幽灵错误”。3.4 数据库初始化与服务启动验证部署成功的“三板斧”完成配置后最后一步是初始化数据库并启动服务。但这一步的验证不能只看systemctl status显示active (running)就万事大吉。# 1. 初始化数据库这一步会创建所有必需的表和索引 $ su -s /bin/sh -c placement-manage db sync placement # 2. 重启 Apache HTTPD 服务Placement API 通常以 WSGI 应用的形式托管在 Apache 下 $ systemctl restart httpd # 3. 验证服务是否真正可用 # 第一板斧检查 Apache 的 error_log确认没有与 placement 相关的 ImportError 或 ConfigurationError $ tail -f /var/log/httpd/error_log | grep -i placement # 第二板斧使用 curl 直接调用 Placement API 的健康检查端点 # 如果返回 HTTP 200说明服务进程和 Web 服务器都正常 $ curl -i http://controller:8778/healthcheck HTTP/1.1 200 OK Content-Length: 2 Content-Type: application/json; charsetUTF-8 Date: Mon, 01 Jan 2024 00:00:00 GMT {} # 第三板斧最关键的一步检查数据库中的 allocations 表是否为空 # 这个表在初始化后应该是空的因为还没有任何资源被分配 $ mysql -u placement -pYourStrongPassword123! placement -e SELECT COUNT(*) FROM allocations; ---------- | COUNT(*) | ---------- | 0 | ----------为什么allocations表必须为空因为allocations表是 Placement 的“心脏”。如果这个表在初始化后就有数据那说明数据库被污染了或者之前的部署残留了脏数据。一个健康的 Placement 服务其allocations表应该从零开始随着 Nova 的资源上报和虚拟机创建而自然增长。如果这里不为零后续的资源调度一定会出错必须清空该表TRUNCATE TABLE allocations;并重新检查。4. 实操过程与核心环节实现从服务启动到资源上报的全链路打通部署完成只是万里长征第一步。真正的挑战在于如何让 Placement 与 Nova 等上游服务无缝协同形成一个闭环。这个过程充满了细节任何一个环节的疏忽都会导致整个资源调度链条断裂。4.1 Nova 侧的配置联动nova.conf中的 Placement 关键配置Placement 服务本身是被动的它只提供 API。真正驱动它运转的是 Nova 的各个组件。因此我们必须在 Nova 的配置文件/etc/nova/nova.conf中进行精确的联动配置。[placement] # 这是 Nova 与 Placement 通信的“地址簿” # 必须与 Keystone 中注册的 Placement public 端点完全一致 os_region_name RegionOne auth_url http://controller:5000/v3 auth_type password project_domain_name default user_domain_name default project_name service username placement password YourPlacementPassword456! # 这个配置决定了 Nova 如何缓存 Placement 的响应 # 在高并发环境下合理的缓存可以极大减轻 Placement 的压力 # 但缓存时间过长又会导致 Nova 获取到过期的资源信息 # 生产环境建议设置为 30 秒这是一个平衡点 cache oslo_cache.memcache memcache_servers controller:11211cache配置的深度解析Nova 的placement部分配置了一个缓存层其目的是为了提升性能。然而这个缓存是一把双刃剑。如果cache配置错误例如memcache_servers指向了一个不存在的 Memcached 服务Nova 在启动时并不会报错但它会默默地退回到无缓存模式导致 Placement API 的请求量激增拖垮整个控制平面。更隐蔽的问题是如果缓存中的数据过期了Nova 可能会基于一个已经失效的资源视图例如一个已经被删除的 Provider做出错误的调度决策。因此在生产环境中我强烈建议在首次部署后先将cache配置注释掉# cache ...待整个系统稳定运行一周后再逐步启用并调整缓存时间。这是一种“宁稳勿快”的务实策略。4.2 资源上报机制nova-compute如何成为 Placement 的“耳目”Nova 的nova-compute服务是 Placement 最重要的“数据采集员”。它会周期性地默认每 30 秒将自己的资源信息CPU、内存、磁盘上报给 Placement。这个过程的成败直接决定了 Placement 的“账本”是否准确。# 1. 确保 nova-compute 服务已启动 $ systemctl start openstack-nova-compute $ systemctl enable openstack-nova-compute # 2. 查看 nova-compute 的日志寻找资源上报成功的标志 $ journalctl -u openstack-nova-compute -f | grep -i reporting to placement # 正常的日志输出应该类似于 # INFO nova.compute.resource_tracker [req-xxx] Successfully reported to placement for resource provider 5c5a578f-51b0-481c-b38c-7aaa3394e585上报失败的典型症状与根因分析如果你在日志中看不到上述成功信息或者看到Failed to report to placement的错误那么问题一定出在nova.conf的[placement]配置上。最常见的根因有三个网络不通nova-compute所在的计算节点无法访问controller:8778。请在计算节点上执行curl -v http://controller:8778/healthcheck进行测试。认证失败nova.conf中的username和password与 Keystone 中的placement用户不匹配。请再次核对。Provider 未注册这是最隐蔽的错误。nova-compute在第一次上报时会尝试在 Placement 中注册自己作为一个 Resource Provider。如果这个注册失败例如Placement 数据库连接异常后续的所有上报都会失败。此时你需要手动检查 Placement 的日志/var/log/placement/placement.log查找ResourceProviderNotFound或DatabaseError相关的错误。4.3 验证与调试用openstackCLI 和curl进行端到端的穿透测试部署的最终目标是让一个虚拟机能够被成功创建。我们可以用一组简洁的 CLI 命令来模拟这个端到端的流程。# 1. 列出所有已注册的 Resource Provider即所有计算节点 $ openstack resource provider list ------------------------------------------------------------------------------------------------------------------------- | uuid | name | generation | root_provider_uuid | parent_provider_uuid | ------------------------------------------------------------------------------------------------------------------------- | 5c5a578f-51b0-481c-b38c-7aaa3394e585 | controller| 26 | 5c5a578f-51b0-481c-b38c-7aaa3394e585 | None | ------------------------------------------------------------------------------------------------------------------------- # 2. 查看某个 Provider 的详细 Inventory资源库存 $ openstack resource provider inventory show 5c5a578f-51b0-481c-b38c-7aaa3394e585 -------------------------------------------------------- | Field | Value | -------------------------------------------------------- | DISK_GB | capacity49, reserved0, ... | | MEMORY_MB | capacity60670, reserved512, ... | | VCPU | capacity512, reserved0, ... | -------------------------------------------------------- # 3. 查询满足特定资源需求的 Allocation Candidates这是调度的核心 # 这个命令会触发 nova-scheduler 向 Placement 发起的第一次 API 调用 $ openstack allocation candidate list --resource VCPU1,MEMORY_MB2048,DISK_GB10 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | # | allocation | resource provider | inventory used/capacity | traits | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 1 | VCPU1,MEMORY_MB2048,DISK_GB10 | 5c5a578f-51b0-481c-b38c-7aaa3394e585 | VCPU5/512,MEMORY_MB3648/60670,DISK_GB7/49 | HW_CPU_X86_SSE2,HW_CPU_X86_SSE,HW_CPU_X86_MMX,HW_CPU_X86_SVM | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- # 4. 可选手动触发一次虚拟机创建观察整个流程 $ openstack server create --flavor m1.small --image cirros --network private test-vm # 如果创建成功立刻去数据库检查 allocations 表 $ mysql -u placement -pYourStrongPassword123! placement -e SELECT * FROM allocations;allocation candidate list命令的实战意义这个命令是 Placement 部署后最有力的“验金石”。它不依赖于 Nova 的任何调度逻辑而是直接调用 Placement API。如果这个命令能成功返回结果就证明 Placement 服务本身、数据库、Keystone 认证、以及 Nova 的配置全部是正确的。反之如果这个命令失败那么问题一定出在 Placement 的核心链路上你可以立即聚焦于此而无需在 Nova 的庞杂日志中大海捞针。5. 常见问题与排查技巧实录那些让你抓狂的“玄学”错误及独家解决方案在无数次的 OpenStack 部署与维护中我整理了一份 Placement 相关的“高频故障速查表”。这些问题往往没有明确的错误信息或者错误信息极具误导性是新人最容易陷入的“黑洞”。5.1 故障现象openstack allocation candidate list命令返回HTTP 401 Unauthorized表面症状执行命令后CLI 报错The request you have made requires authentication.或者Authentication failed.。深层根因与独家排查路径这个问题的根源99% 都在于 Keystone 的admin-openrc文件。请不要急于检查 Placement 的配置而是按以下顺序逐一排查检查OS_AUTH_URLecho $OS_AUTH_URL确认它指向的是http://controller:5000/v3而不是http://controller:35357/v3旧版 Keystone 管理端口已废弃。检查OS_IDENTITY_API_VERSIONecho $OS_IDENTITY_API_VERSION必须是3。如果为空或为2则 Keystone 会尝试用 v2 协议进行认证而 Placement 只支持 v3。检查OS_PROJECT_NAMEecho $OS_PROJECT_NAME必须是admin。openstackCLI 在执行allocation candidate list时会使用当前 shell 环境中的项目Project进行认证。如果OS_PROJECT_NAME是service或其他项目而该项目下的admin用户没有被授予 Placement 服务的访问权限就会导致 401。终极验证绕过 CLI直接用curl模拟认证# 1. 先获取一个 admin token $ curl -i -X POST http://controller:5000/v3/auth/tokens \ -H Content-Type: application/json \ -d { auth: { identity: { methods: [password], password: { user: { name: admin, domain: {name: default}, password: YourAdminPassword } } }, scope: { project: { name: admin, domain: {name: default} } } } } | grep -i x-subject-token # 2. 用获取到的 token 调用 Placement API $ curl -i -X GET http://controller:8778/allocation_candidates?resourcesVCPU:1 \ -H X-Auth-Token: gAAAAAB... \ -H OpenStack-API-Version: placement 1.21如果curl成功而openstackCLI 失败那问题 100% 出在你的admin-openrc环境变量上。5.2 故障现象nova-compute日志中反复出现Failed to report to placement且placement.log中有ConnectionRefusedError表面症状nova-compute无法上报Placement 服务看起来是“活”的systemctl status正常但curl http://controller:8778/healthcheck却超时。深层根因与独家解决方案这几乎可以断定是 Apache 的 WSGI 配置问题。Placement API 是通过 Apache 的mod_wsgi模块加载的其配置文件通常位于/etc/httpd/conf.d/10-placement-api.conf。请检查该文件中WSGIScriptAlias指令的路径是否正确# 正确的配置Rocky 及以后版本 WSGIScriptAlias / /usr/bin/placement-api # 错误的配置Ocata/Pike 版本的遗留配置 WSGIScriptAlias / /usr/bin/placement-api.wsgi在较新版本的 OpenStack 中placement-api已经是一个可执行的 Python 脚本不再需要.wsgi后缀。如果你的配置文件中还保留着旧的.wsgi路径Apache 就会找不到入口点导致所有请求都被拒绝。解决方案是备份原配置文件然后用rpm -ql openstack-placement-api | grep conf命令找到 RPM 包自带的最新配置文件将其覆盖到/etc/httpd/conf.d/目录下再重启httpd。这是 RPM 包升级后最常被忽略的一步。5.3 故障现象openstack resource provider list返回空列表但nova-compute日志显示上报成功表面症状一切看起来都正常但 Placement 的“资源地图”上却一片空白。深层根因与独家解决方案这是一个经典的“时间差”问题。nova-compute的上报是周期性的默认 30 秒而openstackCLI 的查询是即时的。你可能恰好在两次上报的间隙执行了查询命令。但这只是表象真正的根因在于nova-compute的resource_provider配置。请检查/etc/nova/nova.conf文件的[DEFAULT]部分[DEFAULT] # 这个配置项必须存在且值必须为 True # 它告诉 nova-compute“请把我自己注册为一个 Resource Provider” # 如果这个配置项被注释掉或设为 Falsenova-compute 就永远不会向 Placement 注册自己 enable_resource_provider_cache true此外还有一个更隐蔽的配置项[DEFAULT] # 这个配置项决定了 nova-compute 在上报时是使用自己的主机名hostname # 还是使用一个固定的、由管理员指定的名称。 # 如果你的计算节点主机名是 compute01.local但你在 Keystone 中注册的端点是 http://compute01/ # 那么 Placement 可能会因为域名解析问题而无法关联。 # 解决方案是显式指定一个简短、稳定的名称 host compute01独家技巧在nova-compute日志中搜索Creating resource provider。如果看到了这条日志说明注册请求已经发出如果没看到那问题就出在enable_resource_provider_cache配置上。如果看到了但placement.log中没有对应的Created resource provider日志那问题就出在网络或数据库连接上。5.4 故障现象openstack allocation candidate list返回结果但nova-scheduler仍然找不到主机表面症状Placement 的 API 一切正常但虚拟机创建依然失败nova-scheduler日志中显示No valid host was found。深层根因与独家解决方案这说明问题已经从 Placement 层转移到了 Nova 的调度器Scheduler层。Placement 只负责回答“有哪些资源可用”而 Scheduler 还要回答“哪些资源最适合”。nova-scheduler的filter_scheduler会将 Placement 返回的Allocation Candidates再经过一层过滤Filter和权衡Weigher。请检查/etc/nova/nova.conf文件的[filter_scheduler]部分[filter_scheduler] # 这个配置项必须包含 AggregateInstanceExtraSpecsFilter 和 AvailabilityZoneFilter # 它们负责处理 Host Aggregate 和 Availability Zone 的逻辑 enabled_filters RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, AggregateInstanceExtraSpecsFilter, NUMATopologyFilter # 这个配置项必须包含 RamWeigher 和 DiskWeigher # 它们负责根据内存和磁盘的剩余量进行排序 weight_classes nova.scheduler.weights.ram.RamWeigher,nova.scheduler.weights.disk.DiskWeigher最关键的一点ComputeFilter是一个“兜底”过滤器它会检查计算节点的state和status是否为up和enabled。如果nova-compute服务在某个节点上意外停止了
1. OpenStack Placement 服务为什么它不是“可有可无”的配角而是云平台调度的真正中枢你有没有遇到过这样的情况在 OpenStack 云平台上创建虚拟机时明明计算节点还有大量空闲 CPU 和内存nova-scheduler 却死活找不到合适的宿主机或者你给虚拟机指定了一个特定的 Cinder 存储卷结果 nova 却把虚拟机调度到了完全不连通该存储后端的计算节点上导致启动失败又或者你想把一批需要 SR-IOV 网卡的高性能虚拟机只部署在配备了特定网卡型号的服务器上但现有的过滤器Filter却束手无策这些看似“玄学”的调度失败其根源往往不在 Nova 本身而在于一个被很多初学者和运维人员严重低估的服务——Placement。Placement 不是 Nova 的一个子模块也不是一个锦上添花的监控插件。它是从 OpenStack Pike 版本起就强制启用、并在 Stein 版本彻底独立出来的核心基础设施服务。它的存在直接回答了云平台最根本的一个问题“我的资源到底在哪里还剩多少” 在 Placement 出现之前Nova 的 Resource Tracker 只能“数自己家的米”——它只知道计算节点本地的 CPU、内存、磁盘对于由 Cinder 提供的块存储、由 Neutron 提供的网络端口、甚至是由外部 SDS软件定义存储或 NFV网络功能虚拟化设备提供的资源它一概不知。这就像一个只认识自家仓库管理员的采购经理却要负责为整个集团的工厂调配所有原材料其结果必然是混乱与低效。Placement 的核心价值就在于它构建了一个统一、抽象、可扩展的“资源账本”。它将一切可以被消费的实体——无论是物理服务器、GPU 卡、SR-IOV 虚拟功能VF、共享存储池还是一个逻辑上的网络子网——都抽象为一个Resource Provider资源提供者。每个 Resource Provider 都拥有自己的Inventory库存即它能提供多少种资源VCPU、MEMORY_MB、DISK_GB、SRIOV_NET_VF每种资源的总容量和当前已用量是多少同时它还拥有自己的Traits特征标签用来描述其独一无二的属性HW_CPU_X86_AVX2、CUSTOM_HIGH_PERF、MISC_SHARES_VIA_AGGREGATE。当用户发起一个创建虚拟机的请求时nova-scheduler 不再是凭经验“猜”而是向 Placement API 发起一个精确的查询“我需要 2 个 VCPU、4096MB 内存、50GB 磁盘并且这个节点必须支持 AVX2 指令集和 SR-IOV 网络”Placement 则会返回一份详尽的Allocation Candidates分配候选人清单其中不仅列出了哪些资源提供者能满足要求还精确地告诉你它们各自的资源使用率和特征。这才是现代云平台实现精细化、智能化、可编程化调度的基石。如果你正在部署一个生产级的 OpenStack 环境尤其是涉及异构硬件、多后端存储或高级网络功能的场景跳过 Placement 的部署无异于在高速公路上只画了一条虚线却指望所有车辆都能自动对齐行驶。它不是流程的一部分它就是流程本身。2. 核心设计与架构拆解Placement 如何用三层模型重构资源管理范式理解 Placement 的部署绝不能停留在“照着文档敲几行命令”的层面。必须深入其背后的设计哲学否则在后续的排错和调优中你会陷入“知其然不知其所以然”的困境。Placement 的整个架构可以用一个清晰的三层模型来概括Provider 层、Inventory/Traits 层、以及 Consumer/Allocation 层。这三层并非简单的堆叠而是环环相扣、相互制约的有机整体。2.1 Provider 层一切资源的“身份证”与“户口本”在 Placement 的世界里“资源”没有高低贵贱之分只有“提供者”Resource Provider这一种身份。一个计算节点Compute Node是一个 Provider一台物理存储服务器Cinder Backend是一个 Provider一个网络交换机上的一个端口池Neutron Port Pool同样是一个 Provider。甚至一个逻辑概念比如一个用于存放高安全级别虚拟机的“安全隔离区”Security Zone也可以被建模为一个 Provider。这种极致的抽象是 Placement 能够统一纳管所有类型资源的根本原因。每一个 Provider 都有一个全球唯一的 UUID这是它的“身份证号”。更重要的是它还有一个“户口本”即root_provider_uuid和parent_provider_uuid构成的树状结构。例如一台物理服务器Root Provider上可能插着一块 GPU 卡Child Provider而这块 GPU 卡上又划分出了多个 CUDA CoreGrandchild Provider。通过这种父子关系Placement 能够精确地追踪到一个资源请求最终消耗的是哪一块物理芯片上的哪一个计算单元。这解决了传统方案中“资源归属不清”的老大难问题。当你看到parent_provider_uuid字段为空时就意味着这是一个顶级的、不可再分割的物理资源实体。部署时我们首先要确保所有关键的 Provider尤其是计算节点都被正确地注册到 Placement 中这是整个资源账本得以建立的第一步。2.2 Inventory/Traits 层资源的“数量”与“质量”双维度刻画如果说 Provider 是资源的“人”那么 Inventory 和 Traits 就是它的“简历”。Inventory 描述的是“数量”即这个 Provider 能提供什么、能提供多少。它是一组键值对Key 是标准化的Resource Class资源类别如VCPU、MEMORY_MB、DISK_GB、SRIOV_NET_VFValue 则是一个包含total总量、reserved预留量、min_unit最小分配单位、max_unit最大分配单位和step_size步长的 JSON 对象。这里的关键在于reserved字段的存在使得 Placement 可以预留一部分资源给系统自身如 Hypervisor 开销或特定用途避免资源被完全耗尽。Traits 则描述的是“质量”即这个 Provider 具备哪些独特的、非数值化的特征。它是一组字符串标签分为两类一类是社区预定义的、以HW_或CUSTOM_开头的标准 Trait如HW_CPU_X86_AVX2另一类则是用户自定义的、以CUSTOM_为前缀的业务标签如CUSTOM_FINANCE_DEPT。Traits 的强大之处在于其组合性。你可以用requiredHW_CPU_X86_AVX2,CUSTOM_FINANCE_DEPT这样的查询条件精准地筛选出既具备高性能计算能力又归属于财务部门专属资源池的 Provider。这比传统的 Host Aggregate 更加灵活和强大因为它不依赖于 Nova 的调度逻辑而是直接作用于资源数据层。在部署配置中placement.conf文件里的[api]和[keystone_authtoken]部分本质上就是在为这个“简历”管理系统配置访问权限和认证方式确保只有经过授权的服务如 Nova才能读写这份关键的“人才档案”。2.3 Consumer/Allocation 层资源的“消费者”与“占用凭证”当一个虚拟机VM被创建时它在 Placement 的世界里就变成了一个Consumer消费者并获得一个唯一的 UUID通常就是 VM 的 instance_uuid。Consumer 本身不拥有任何资源它只是资源的“使用者”。真正的资源占用体现在Allocation分配记录上。Allocation 表是 Placement 数据库的核心它记录了每一次资源分配的“三方协议”谁consumer_id向谁resource_provider_id申请了什么resource_class_id以及多少used。这个设计极其精妙。它意味着资源的占用状态是“事件驱动”的而不是“状态轮询”的。Nova 在启动 VM 前会先向 Placement 发起一个claim_resources请求Placement 会在数据库中插入一条 Allocation 记录并原子性地更新对应 Provider 的 Inventory 使用量。如果此时另一个并发请求也想占用同一份资源Placement 会因为数据库的唯一约束或乐观锁机制而拒绝从而保证了资源分配的强一致性。这正是 Placement 能够替代 Nova 旧有过滤器CpuFilter 等的根本技术保障——它把资源调度从一个基于“猜测”的概率游戏变成了一个基于“事实”的确定性事务。部署完成后检查allocations表是否为空是验证 Placement 是否真正开始工作的第一个黄金指标。3. 核心部署环节详解从零开始构建 Placement 服务的完整实操链部署 Placement 并非一个孤立的动作它是一个嵌入在整个 OpenStack 控制节点初始化流程中的关键环节。下面我将基于 Rocky 或更高版本的 OpenStack推荐使用 Ussuri 或 Wallaby为你拆解每一个步骤背后的原理、参数选择的依据以及那些文档里绝不会写的“潜规则”。3.1 数据库准备为什么必须用 MySQL/MariaDB而非 SQLitePlacement 服务对数据库的并发读写性能和事务一致性有极高要求。虽然官方文档有时会提到 SQLite 作为开发测试选项但在任何生产环境这都是一个危险的信号。SQLite 是一个文件级数据库其锁粒度是整个数据库文件在高并发的云环境中这会导致严重的性能瓶颈和锁等待。因此我们必须使用一个真正的客户端-服务器架构的数据库如 MariaDBMySQL 的一个主流分支。# 1. 登录数据库创建专用数据库 $ mysql -u root -p MariaDB [(none)] CREATE DATABASE placement CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 2. 创建专用用户并授予权限 # 注意这里我们使用 placement% 而非 placementlocalhost # 因为在分布式部署中Placement API 可能运行在独立的控制节点上需要从网络访问数据库 MariaDB [(none)] GRANT ALL PRIVILEGES ON placement.* TO placement% IDENTIFIED BY YourStrongPassword123!; MariaDB [(none)] FLUSH PRIVILEGES;关键参数解析与避坑心得CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci这是强制要求。Placement 的某些字段如 Traits 名称可能包含 emoji 或其他四字节 Unicode 字符utf8编码在 MySQL 中实际是utf8mb3无法支持会导致插入失败。placement%这是生产环境的黄金配置。如果你错误地只授予了placementlocalhost权限那么当你的 OpenStack 环境是多节点如 controller、compute 分离时Placement 服务将无法连接数据库报错Access denied for user placementcontroller。这个错误非常隐蔽因为controller主机名在数据库看来就是一个远程 IP 地址。密码强度YourStrongPassword123!仅作示例。生产环境必须使用符合复杂度要求的密码且该密码将在后续的placement.conf配置文件中重复出现务必妥善保管。3.2 Keystone 服务注册不只是“走个过场”而是建立信任链Placement 作为一个独立的 OpenStack 服务它必须像 Nova、Glance 一样在 Keystone 的服务目录Service Catalog中注册自己以便其他服务能够发现并调用它。这个过程远不止是创建一个用户那么简单它是在 Keystone 的身份认证体系中为 Placement 建立一条完整的信任链。# 1. 加载 admin 凭据 $ source admin-openrc # 2. 创建 placement 用户注意密码必须与 placement.conf 中的配置一致 $ openstack user create --domain default --password-prompt placement # 输入密码YourPlacementPassword456! # 3. 将 placement 用户添加到 service 项目并赋予 admin 角色 # 这一步至关重要Placement API 需要 admin 权限来执行数据库同步等管理操作 $ openstack role add --project service --user placement admin # 4. 创建 Placement 服务实体 $ openstack service create --name placement --description Placement API placement # 5. 创建三个端点public, internal, admin # 这是 OpenStack 的标准实践确保不同网络区域的服务都能访问 $ 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为什么必须是admin角色Placement 的placement-manage db sync命令本质上是执行一系列 DDL数据定义语言操作如创建表、添加索引、修改字段。这些操作在 Keystone 的 RBAC基于角色的访问控制模型下只有admin角色才被授权。如果你错误地只给了member角色那么在执行数据库同步时你会收到HTTP 403 Forbidden错误提示权限不足。这是一个新手最容易踩的坑也是排查 Placement 启动失败的第一个检查点。3.3 Placement 服务安装与配置placement.conf文件的逐行精读在控制节点上安装 Placement 服务包后核心工作就是编辑/etc/placement/placement.conf文件。这个文件虽小但每一行都牵一发而动全身。[DEFAULT] # 日志级别生产环境建议设为 WARNING 或 ERROR避免日志爆炸 debug false log_dir /var/log/placement [api] # 这是 Placement API 的核心策略必须启用 Keystone 认证 auth_strategy keystone # 这个配置决定了 Placement API 的监听地址和端口 # 默认是 0.0.0.0:8778即监听所有网卡的 8778 端口 # 如果你的控制节点有多个网卡且只想让内部网络访问可以改为 bind_host 192.168.1.10 bind_host 0.0.0.0 bind_port 8778 [placement_database] # 数据库连接字符串必须与前面创建的数据库信息完全一致 # 注意connection 字符串中的密码必须是 URL 编码后的形式 # 如果你的密码包含特殊字符如 , /, :必须进行编码否则连接会失败 connection mysqlpymysql://placement:YourStrongPassword123%21controller/placement [keystone_authtoken] # 这是 Placement 服务向 Keystone 自我证明身份的凭证 # 它告诉 Keystone“我是 placement 服务我属于 service 项目” 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 placement password YourPlacementPassword456! # 这个配置非常重要它指定了 Placement 服务使用的认证域 # 必须与 Keystone 中创建的 placement 用户所在的 domain 一致 # 默认是 default但如果你们的环境使用了自定义 domain这里必须修改 domain_name default最关键的配置项connection字符串的 URL 编码这是我在无数个深夜排错后总结出的血泪教训。mysqlpymysql://连接字符串中的密码如果包含、/、:、?、#等 URL 保留字符必须进行百分号编码Percent-encoding。例如密码Pssw0rd/123必须编码为P%40ssw0rd%2F123。否则PyMySQL 会将之后的内容误认为是主机名导致连接controller失败。一个简单的方法是在配置前先用 Python 的urllib.parse.quote_plus()函数对密码进行编码 from urllib.parse import quote_plus quote_plus(Pssw0rd/123) P%40ssw0rd%2F123把这个编码后的字符串填入connection配置项就能彻底避免这个“幽灵错误”。3.4 数据库初始化与服务启动验证部署成功的“三板斧”完成配置后最后一步是初始化数据库并启动服务。但这一步的验证不能只看systemctl status显示active (running)就万事大吉。# 1. 初始化数据库这一步会创建所有必需的表和索引 $ su -s /bin/sh -c placement-manage db sync placement # 2. 重启 Apache HTTPD 服务Placement API 通常以 WSGI 应用的形式托管在 Apache 下 $ systemctl restart httpd # 3. 验证服务是否真正可用 # 第一板斧检查 Apache 的 error_log确认没有与 placement 相关的 ImportError 或 ConfigurationError $ tail -f /var/log/httpd/error_log | grep -i placement # 第二板斧使用 curl 直接调用 Placement API 的健康检查端点 # 如果返回 HTTP 200说明服务进程和 Web 服务器都正常 $ curl -i http://controller:8778/healthcheck HTTP/1.1 200 OK Content-Length: 2 Content-Type: application/json; charsetUTF-8 Date: Mon, 01 Jan 2024 00:00:00 GMT {} # 第三板斧最关键的一步检查数据库中的 allocations 表是否为空 # 这个表在初始化后应该是空的因为还没有任何资源被分配 $ mysql -u placement -pYourStrongPassword123! placement -e SELECT COUNT(*) FROM allocations; ---------- | COUNT(*) | ---------- | 0 | ----------为什么allocations表必须为空因为allocations表是 Placement 的“心脏”。如果这个表在初始化后就有数据那说明数据库被污染了或者之前的部署残留了脏数据。一个健康的 Placement 服务其allocations表应该从零开始随着 Nova 的资源上报和虚拟机创建而自然增长。如果这里不为零后续的资源调度一定会出错必须清空该表TRUNCATE TABLE allocations;并重新检查。4. 实操过程与核心环节实现从服务启动到资源上报的全链路打通部署完成只是万里长征第一步。真正的挑战在于如何让 Placement 与 Nova 等上游服务无缝协同形成一个闭环。这个过程充满了细节任何一个环节的疏忽都会导致整个资源调度链条断裂。4.1 Nova 侧的配置联动nova.conf中的 Placement 关键配置Placement 服务本身是被动的它只提供 API。真正驱动它运转的是 Nova 的各个组件。因此我们必须在 Nova 的配置文件/etc/nova/nova.conf中进行精确的联动配置。[placement] # 这是 Nova 与 Placement 通信的“地址簿” # 必须与 Keystone 中注册的 Placement public 端点完全一致 os_region_name RegionOne auth_url http://controller:5000/v3 auth_type password project_domain_name default user_domain_name default project_name service username placement password YourPlacementPassword456! # 这个配置决定了 Nova 如何缓存 Placement 的响应 # 在高并发环境下合理的缓存可以极大减轻 Placement 的压力 # 但缓存时间过长又会导致 Nova 获取到过期的资源信息 # 生产环境建议设置为 30 秒这是一个平衡点 cache oslo_cache.memcache memcache_servers controller:11211cache配置的深度解析Nova 的placement部分配置了一个缓存层其目的是为了提升性能。然而这个缓存是一把双刃剑。如果cache配置错误例如memcache_servers指向了一个不存在的 Memcached 服务Nova 在启动时并不会报错但它会默默地退回到无缓存模式导致 Placement API 的请求量激增拖垮整个控制平面。更隐蔽的问题是如果缓存中的数据过期了Nova 可能会基于一个已经失效的资源视图例如一个已经被删除的 Provider做出错误的调度决策。因此在生产环境中我强烈建议在首次部署后先将cache配置注释掉# cache ...待整个系统稳定运行一周后再逐步启用并调整缓存时间。这是一种“宁稳勿快”的务实策略。4.2 资源上报机制nova-compute如何成为 Placement 的“耳目”Nova 的nova-compute服务是 Placement 最重要的“数据采集员”。它会周期性地默认每 30 秒将自己的资源信息CPU、内存、磁盘上报给 Placement。这个过程的成败直接决定了 Placement 的“账本”是否准确。# 1. 确保 nova-compute 服务已启动 $ systemctl start openstack-nova-compute $ systemctl enable openstack-nova-compute # 2. 查看 nova-compute 的日志寻找资源上报成功的标志 $ journalctl -u openstack-nova-compute -f | grep -i reporting to placement # 正常的日志输出应该类似于 # INFO nova.compute.resource_tracker [req-xxx] Successfully reported to placement for resource provider 5c5a578f-51b0-481c-b38c-7aaa3394e585上报失败的典型症状与根因分析如果你在日志中看不到上述成功信息或者看到Failed to report to placement的错误那么问题一定出在nova.conf的[placement]配置上。最常见的根因有三个网络不通nova-compute所在的计算节点无法访问controller:8778。请在计算节点上执行curl -v http://controller:8778/healthcheck进行测试。认证失败nova.conf中的username和password与 Keystone 中的placement用户不匹配。请再次核对。Provider 未注册这是最隐蔽的错误。nova-compute在第一次上报时会尝试在 Placement 中注册自己作为一个 Resource Provider。如果这个注册失败例如Placement 数据库连接异常后续的所有上报都会失败。此时你需要手动检查 Placement 的日志/var/log/placement/placement.log查找ResourceProviderNotFound或DatabaseError相关的错误。4.3 验证与调试用openstackCLI 和curl进行端到端的穿透测试部署的最终目标是让一个虚拟机能够被成功创建。我们可以用一组简洁的 CLI 命令来模拟这个端到端的流程。# 1. 列出所有已注册的 Resource Provider即所有计算节点 $ openstack resource provider list ------------------------------------------------------------------------------------------------------------------------- | uuid | name | generation | root_provider_uuid | parent_provider_uuid | ------------------------------------------------------------------------------------------------------------------------- | 5c5a578f-51b0-481c-b38c-7aaa3394e585 | controller| 26 | 5c5a578f-51b0-481c-b38c-7aaa3394e585 | None | ------------------------------------------------------------------------------------------------------------------------- # 2. 查看某个 Provider 的详细 Inventory资源库存 $ openstack resource provider inventory show 5c5a578f-51b0-481c-b38c-7aaa3394e585 -------------------------------------------------------- | Field | Value | -------------------------------------------------------- | DISK_GB | capacity49, reserved0, ... | | MEMORY_MB | capacity60670, reserved512, ... | | VCPU | capacity512, reserved0, ... | -------------------------------------------------------- # 3. 查询满足特定资源需求的 Allocation Candidates这是调度的核心 # 这个命令会触发 nova-scheduler 向 Placement 发起的第一次 API 调用 $ openstack allocation candidate list --resource VCPU1,MEMORY_MB2048,DISK_GB10 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | # | allocation | resource provider | inventory used/capacity | traits | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 1 | VCPU1,MEMORY_MB2048,DISK_GB10 | 5c5a578f-51b0-481c-b38c-7aaa3394e585 | VCPU5/512,MEMORY_MB3648/60670,DISK_GB7/49 | HW_CPU_X86_SSE2,HW_CPU_X86_SSE,HW_CPU_X86_MMX,HW_CPU_X86_SVM | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- # 4. 可选手动触发一次虚拟机创建观察整个流程 $ openstack server create --flavor m1.small --image cirros --network private test-vm # 如果创建成功立刻去数据库检查 allocations 表 $ mysql -u placement -pYourStrongPassword123! placement -e SELECT * FROM allocations;allocation candidate list命令的实战意义这个命令是 Placement 部署后最有力的“验金石”。它不依赖于 Nova 的任何调度逻辑而是直接调用 Placement API。如果这个命令能成功返回结果就证明 Placement 服务本身、数据库、Keystone 认证、以及 Nova 的配置全部是正确的。反之如果这个命令失败那么问题一定出在 Placement 的核心链路上你可以立即聚焦于此而无需在 Nova 的庞杂日志中大海捞针。5. 常见问题与排查技巧实录那些让你抓狂的“玄学”错误及独家解决方案在无数次的 OpenStack 部署与维护中我整理了一份 Placement 相关的“高频故障速查表”。这些问题往往没有明确的错误信息或者错误信息极具误导性是新人最容易陷入的“黑洞”。5.1 故障现象openstack allocation candidate list命令返回HTTP 401 Unauthorized表面症状执行命令后CLI 报错The request you have made requires authentication.或者Authentication failed.。深层根因与独家排查路径这个问题的根源99% 都在于 Keystone 的admin-openrc文件。请不要急于检查 Placement 的配置而是按以下顺序逐一排查检查OS_AUTH_URLecho $OS_AUTH_URL确认它指向的是http://controller:5000/v3而不是http://controller:35357/v3旧版 Keystone 管理端口已废弃。检查OS_IDENTITY_API_VERSIONecho $OS_IDENTITY_API_VERSION必须是3。如果为空或为2则 Keystone 会尝试用 v2 协议进行认证而 Placement 只支持 v3。检查OS_PROJECT_NAMEecho $OS_PROJECT_NAME必须是admin。openstackCLI 在执行allocation candidate list时会使用当前 shell 环境中的项目Project进行认证。如果OS_PROJECT_NAME是service或其他项目而该项目下的admin用户没有被授予 Placement 服务的访问权限就会导致 401。终极验证绕过 CLI直接用curl模拟认证# 1. 先获取一个 admin token $ curl -i -X POST http://controller:5000/v3/auth/tokens \ -H Content-Type: application/json \ -d { auth: { identity: { methods: [password], password: { user: { name: admin, domain: {name: default}, password: YourAdminPassword } } }, scope: { project: { name: admin, domain: {name: default} } } } } | grep -i x-subject-token # 2. 用获取到的 token 调用 Placement API $ curl -i -X GET http://controller:8778/allocation_candidates?resourcesVCPU:1 \ -H X-Auth-Token: gAAAAAB... \ -H OpenStack-API-Version: placement 1.21如果curl成功而openstackCLI 失败那问题 100% 出在你的admin-openrc环境变量上。5.2 故障现象nova-compute日志中反复出现Failed to report to placement且placement.log中有ConnectionRefusedError表面症状nova-compute无法上报Placement 服务看起来是“活”的systemctl status正常但curl http://controller:8778/healthcheck却超时。深层根因与独家解决方案这几乎可以断定是 Apache 的 WSGI 配置问题。Placement API 是通过 Apache 的mod_wsgi模块加载的其配置文件通常位于/etc/httpd/conf.d/10-placement-api.conf。请检查该文件中WSGIScriptAlias指令的路径是否正确# 正确的配置Rocky 及以后版本 WSGIScriptAlias / /usr/bin/placement-api # 错误的配置Ocata/Pike 版本的遗留配置 WSGIScriptAlias / /usr/bin/placement-api.wsgi在较新版本的 OpenStack 中placement-api已经是一个可执行的 Python 脚本不再需要.wsgi后缀。如果你的配置文件中还保留着旧的.wsgi路径Apache 就会找不到入口点导致所有请求都被拒绝。解决方案是备份原配置文件然后用rpm -ql openstack-placement-api | grep conf命令找到 RPM 包自带的最新配置文件将其覆盖到/etc/httpd/conf.d/目录下再重启httpd。这是 RPM 包升级后最常被忽略的一步。5.3 故障现象openstack resource provider list返回空列表但nova-compute日志显示上报成功表面症状一切看起来都正常但 Placement 的“资源地图”上却一片空白。深层根因与独家解决方案这是一个经典的“时间差”问题。nova-compute的上报是周期性的默认 30 秒而openstackCLI 的查询是即时的。你可能恰好在两次上报的间隙执行了查询命令。但这只是表象真正的根因在于nova-compute的resource_provider配置。请检查/etc/nova/nova.conf文件的[DEFAULT]部分[DEFAULT] # 这个配置项必须存在且值必须为 True # 它告诉 nova-compute“请把我自己注册为一个 Resource Provider” # 如果这个配置项被注释掉或设为 Falsenova-compute 就永远不会向 Placement 注册自己 enable_resource_provider_cache true此外还有一个更隐蔽的配置项[DEFAULT] # 这个配置项决定了 nova-compute 在上报时是使用自己的主机名hostname # 还是使用一个固定的、由管理员指定的名称。 # 如果你的计算节点主机名是 compute01.local但你在 Keystone 中注册的端点是 http://compute01/ # 那么 Placement 可能会因为域名解析问题而无法关联。 # 解决方案是显式指定一个简短、稳定的名称 host compute01独家技巧在nova-compute日志中搜索Creating resource provider。如果看到了这条日志说明注册请求已经发出如果没看到那问题就出在enable_resource_provider_cache配置上。如果看到了但placement.log中没有对应的Created resource provider日志那问题就出在网络或数据库连接上。5.4 故障现象openstack allocation candidate list返回结果但nova-scheduler仍然找不到主机表面症状Placement 的 API 一切正常但虚拟机创建依然失败nova-scheduler日志中显示No valid host was found。深层根因与独家解决方案这说明问题已经从 Placement 层转移到了 Nova 的调度器Scheduler层。Placement 只负责回答“有哪些资源可用”而 Scheduler 还要回答“哪些资源最适合”。nova-scheduler的filter_scheduler会将 Placement 返回的Allocation Candidates再经过一层过滤Filter和权衡Weigher。请检查/etc/nova/nova.conf文件的[filter_scheduler]部分[filter_scheduler] # 这个配置项必须包含 AggregateInstanceExtraSpecsFilter 和 AvailabilityZoneFilter # 它们负责处理 Host Aggregate 和 Availability Zone 的逻辑 enabled_filters RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, AggregateInstanceExtraSpecsFilter, NUMATopologyFilter # 这个配置项必须包含 RamWeigher 和 DiskWeigher # 它们负责根据内存和磁盘的剩余量进行排序 weight_classes nova.scheduler.weights.ram.RamWeigher,nova.scheduler.weights.disk.DiskWeigher最关键的一点ComputeFilter是一个“兜底”过滤器它会检查计算节点的state和status是否为up和enabled。如果nova-compute服务在某个节点上意外停止了
