1. 项目概述为什么 Placement 不是“可有可无”的配角而是 OpenStack 资源调度的中枢神经OpenStack Placement 服务部署全流程——这八个字背后藏着一个被大量新手和运维人员严重低估的关键事实从 Pike 版本2017年起Placement 就不再是 Nova 的一个可选插件而是整个 OpenStack 云平台资源调度体系的强制性基础设施。如果你跳过 Placement 或部署失败nova-compute 服务根本无法注册上线nova-scheduler 会直接报错退出你连创建第一台虚拟机的命令都执行不了。这不是理论风险而是我亲手在三套不同规模的生产环境里反复验证过的硬性门槛。很多人看到“Placement”这个词下意识觉得它只是个“放东西的地方”类似数据库里的一个表结构。但实际完全相反——Placement 是 OpenStack 的“资源总账本”“调度情报中心”。它不负责计算、不负责存储、不负责网络但它必须精确知道哪台物理服务器有多少 CPU 核、多少内存、多少本地磁盘哪个 Ceph 存储池还剩多少 GB 可用空间哪块网卡支持 SR-IOV、哪块支持 OVS-DPDK甚至某台主机是否安装了特定型号的 GPU、是否接入了专用 InfiniBand 网络。这些信息不再由 Nova 自己零散地、周期性地轮询上报而是由 Placement 统一建模、统一索引、统一提供查询接口。这就解释了为什么标题里强调“全流程”——它不是装个包、启个服务就完事。Placement 的部署成败直接取决于你对 OpenStack 整体架构的理解深度。比如它的数据库必须独立于 Nova 数据库因为 Nova 的 nova_api 库只存虚拟机元数据而 Placement 的 placement 库要承载所有资源提供者Resource Provider的库存Inventory、使用量Usage、特征标签Traits、聚合分组Aggregates四维数据模型。再比如它的认证必须走 Keystone 的 password 认证方式且用户必须绑定 service 项目下的 admin 角色否则 Nova 组件在调用 Placement API 时会因权限不足被拒错误日志里只会显示模糊的401 Unauthorized根本不会告诉你缺的是哪个环节。更关键的是Placement 的价值在多资源类型混合场景下才真正爆发。举个真实案例我们曾为一家广电客户部署 OpenStack他们既有传统 x86 计算节点又有搭载 AMD EPYC 处理器的渲染集群还有专用于 AI 推理的 A100 GPU 节点。如果不用 PlacementNova 只能靠简单的 CPU/内存过滤器粗筛结果就是渲染任务被调度到普通计算节点上跑得极慢GPU 任务又因缺乏显存感知而频繁失败。引入 Placement 后我们给渲染节点打上CUSTOM_RENDER_CLUSTER标签给 GPU 节点打上CUSTOM_AI_ACCELERATOR标签并在创建实例时通过--hint traitCUSTOM_RENDER_CLUSTER强制指定调度成功率从 63% 直接拉升到 99.8%。这种细粒度的资源画像能力正是 Placement 存在的根本意义。所以当你看到热搜词里“手把手教你搭建 openstack”“基于 packstack 的三节点部署”时请务必清醒那些教程如果没把 Placement 单独拎出来讲透、没演示如何验证其 API 是否真正可用、没说明它与 Nova 的交互链路那它们教的只是半套 OpenStack。本文接下来要做的就是带你从零开始把 Placement 这个“看不见的调度大脑”完整地、可验证地、抗压地部署起来每一步都附带原理拆解和避坑提示让你部署完不是“能跑”而是“跑得稳、查得清、扩得开”。2. 核心设计逻辑为什么必须独立部署、为何不能复用 Nova 数据库、API 端口为何锁定 87782.1 架构定位决定部署必须独立从 Nova 的“子模块”到 OpenStack 的“一级公民”Placement 的演进路径清晰揭示了其部署逻辑的必然性。它最早在 Newton 版本2016年作为 Nova 代码树中的一个 API 模块孵化此时它确实可以和 Nova 共享数据库、共用服务进程。但 Ocata 版本2017年开始社区明确将其定位为“独立服务”核心动因是解耦与扩展性。试想一下如果 Placement 还寄生在 Nova 里当你要对接外部存储如 Pure Storage、外部网络如 Cisco ACI、甚至外部 GPU 管理平台如 NVIDIA DGX Manager时每一次新增资源类型都得修改 Nova 的核心代码、重新编译、重启整个 Nova 服务——这对生产环境是不可接受的停机风险。因此Stein 版本2019年Placement 彻底脱离 Nova 代码库成为 OpenStack 社区的第 15 个独立项目。这意味着它的部署必须遵循 OpenStack “服务自治”原则独立进程、独立配置、独立数据库、独立日志、独立监控端点。你不能用systemctl start openstack-nova-api顺带启动 Placement也不能把placement.conf配置写进nova.conf里。它必须像 Keystone、Glance 一样拥有自己的 systemd unit 文件openstack-placement-api.service自己的配置目录/etc/placement/自己的 WSGI 应用/usr/lib/python3.6/site-packages/placement/api.py。这是架构层面的铁律任何试图“偷懒合并”的做法都会在后续升级或故障排查时付出十倍代价。2.2 数据库隔离的深层原因资源模型与业务模型的本质差异为什么 Placement 必须拥有专属数据库很多教程只说“按文档操作”却从不解释背后的数据库设计哲学。关键在于Nova 数据库描述的是“谁用了什么”而 Placement 数据库描述的是“什么能被谁用”。Nova 的nova_api.allocations表记录的是具体消费行为consumer_id虚拟机 UUID、resource_provider_id计算节点 UUID、resource_class_idVCPU/MEMORY_MB、used已分配数量。这是事务性的、一次性的、不可逆的“记账”。Placement 的placement.resource_providers、placement.inventories、placement.allocations表则构建了一个动态的、可查询的“资源地图”resource_providers表定义了所有资源提供者物理机、存储池、网络设备的元信息inventories表定义了每个提供者能提供哪些资源、总量多少allocations表则实时反映当前已被占用的资源量。这是一个持续更新的“状态快照”而非历史流水。这种模型差异导致数据库负载特征完全不同。Nova 的 allocations 表写入频率高每次创建/删除虚拟机都写、查询模式简单按 consumer_id 查Placement 的 inventories 表写入频率低仅资源提供者上线/下线时变更、但查询极其复杂allocation_candidatesAPI 需要跨resource_providers、inventories、allocations、traits四张表做多层 JOIN 和聚合计算。如果强行共用数据库当 Placement 执行一个复杂的GET /allocation_candidates?resourcesVCPU:4,MEMORY_MB:8192,DISK_GB:100requiredCUSTOM_GPU查询时其锁表时间可能阻塞 Nova 的虚拟机创建流程造成雪崩式超时。独立数据库本质是用存储成本换取服务稳定性。2.3 API 端口锁定 8778 的工程考量避免端口冲突与标准化运维Placement API 默认监听 8778 端口这个数字并非随意指定而是 OpenStack 社区经过长期实践形成的端口公约Port Convention。在 OpenStack 服务端口规划中8000-8999 区间被专门划给“API 服务”其中8000-8099预留给人工智能/ML 相关服务如 DAI8100-8199预留给容器/编排服务如 Zun8200-8299预留给安全审计服务如 Barbican8777-8779明确分配给 Placement 服务8777 为旧版兼容8778 为主力8779 为备用选择 8778 而非更“顺口”的 8000 或 8080核心是为了规避与常见 Web 服务的端口冲突。8080 是 Tomcat、Nginx 的默认 HTTP 端口8000 是 Django、Flask 开发服务器常用端口80 是标准 HTTP 端口。如果 Placement 也用 8080在单节点 All-in-One 部署中httpdApache和 Placement WSGI 应用会争抢同一个端口导致服务启动失败。而 8778 这个“冷门”端口在绝大多数 Linux 发行版和企业防火墙策略中都是空闲的极大降低了部署时的端口调试成本。更重要的是端口标准化带来了运维一致性。当你在生产环境中部署数十个 OpenStack 服务时运维脚本、监控告警规则、防火墙策略都可以基于端口号快速匹配。例如Zabbix 监控模板可以直接写net.tcp.port[{HOST.IP},8778]来检查 Placement API 是否存活而无需为每个服务单独维护端口映射表。这种看似微小的约定实则是大型云平台可维护性的基石。3. 部署全流程详解从数据库初始化到 API 可用性验证的每一步实操3.1 数据库准备创建专用库、授权、字符集校验的完整命令链Placement 数据库的创建远不止CREATE DATABASE placement;这一行命令。一个健壮的生产环境部署必须包含字符集、排序规则、用户权限的精细化控制。以下是我在 CentOS 7 MariaDB 10.3 环境下验证通过的完整操作序列# 1. 以 root 用户登录 MariaDB 控制台 $ mysql -u root -p # 2. 创建 placement 数据库并显式指定字符集和排序规则 # 关键点必须使用 utf8mb4而非旧版 utf8以支持完整 Unicode如 emoji、中文生僻字 MariaDB [(none)] CREATE DATABASE placement CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 3. 创建专用数据库用户 placement并授予最小必要权限 # 注意这里只授予 placement.* 的权限而非全局 *.*符合最小权限原则 MariaDB [(none)] GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON placement.* TO placementlocalhost IDENTIFIED BY StrongPass123!; # 4. 授予从任意 IP%连接的权限适配多节点部署场景 # 生产环境建议将 % 替换为具体的 controller 节点 IP如 192.168.1.10 MariaDB [(none)] GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON placement.* TO placement% IDENTIFIED BY StrongPass123!; # 5. 刷新权限使配置立即生效 MariaDB [(none)] FLUSH PRIVILEGES; # 6. 退出 MariaDB MariaDB [(none)] EXIT;提示密码StrongPass123!仅为示例生产环境必须使用密码管理工具生成高强度随机密码并通过 Ansible Vault 或 HashiCorp Vault 加密存储严禁明文写入配置文件或脚本。完成数据库创建后务必进行连接性验证这是最容易被忽略却最关键的一步# 使用刚创建的用户连接数据库测试基本读写能力 $ mysql -u placement -pStrongPass123! -h localhost placement -e SHOW TABLES; # 预期输出空结果因为尚未初始化表结构但不应报错 # 测试远程连接从其他节点 ping controller 的 3306 端口 $ telnet controller 3306 # 如果连接失败需检查 MariaDB 的 bind-address 配置/etc/my.cnf.d/server.cnf 中应为 bind-address 0.0.0.0 或具体 IP3.2 Keystone 服务注册用户、角色、服务条目、端点的四步闭环Placement 作为 OpenStack 服务必须在 Keystone 中完成完整的身份注册形成“用户-角色-服务-端点”四要素闭环。任何一环缺失Nova 都无法通过 Keystone 获取 Placement 的访问令牌Token。以下是严格按依赖顺序执行的操作# 1. 加载 admin 凭据确保已正确配置 admin-openrc 文件 $ . admin-openrc # 2. 创建 placement 用户密码需与 placement.conf 中配置一致 $ openstack user create --domain default --password-prompt placement # 输入密码StrongPass123! 与数据库密码相同便于记忆但生产环境建议分离 # 3. 将 placement 用户添加到 service 项目并赋予 admin 角色 # 关键点必须是 service 项目且角色必须是 admin这是 Placement API 认证的硬性要求 $ openstack role add --project service --user placement admin # 4. 创建 Placement 服务条目type 必须为 placement $ openstack service create --name placement --description Placement API placement # 5. 创建三个端点public/internal/adminURL 必须指向 controller 主机名或 IP # 注意URL 中的 controller 必须能在所有节点包括 compute 节点上 DNS 解析 $ 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注意openstack endpoint create命令返回的id字段是唯一的可用于后续故障排查。如果执行时报错No endpoint found for placement说明前一步openstack service create未成功需先检查服务条目是否存在openstack service list | grep placement。验证 Keystone 注册是否成功的最直接方法是模拟 Nova 的认证流程# 获取 placement 用户的 token此 token 将被 Nova 用于调用 Placement API $ openstack token issue --os-username placement --os-password StrongPass123! --os-project-name service --os-user-domain-name default --os-project-domain-name default --os-auth-url http://controller:5000/v3 # 输出中应包含 id 字段即有效的 token 字符串形如 gAAAAAB...长度约 300 字符 # 如果报错 The request you have made requires authentication.说明 Keystone 认证环节失败需回溯检查用户、项目、角色绑定3.3 Placement 服务安装与核心配置placement.conf的逐项解析与安全加固在控制节点controller上安装 Placement 服务包并对其进行深度配置是部署的核心环节。以下是在 CentOS 7 上的标准操作# 1. 安装 openstack-placement-api 包RHEL/CentOS 系 $ yum install -y openstack-placement-api # 2. 备份原始配置文件永远的第一步 $ cp /etc/placement/placement.conf /etc/placement/placement.conf.bak.$(date %Y%m%d) # 3. 编辑主配置文件 /etc/placement/placement.conf $ vi /etc/placement/placement.conf配置文件需重点修改以下四个区块每一项都有其不可替代的作用[DEFAULT] 区块基础服务行为[DEFAULT] # 日志级别设为 INFO便于初期调试生产环境可调为 WARNING 以减少日志量 debug false # 日志文件路径确保 /var/log/placement 目录存在且 placement 用户有写入权限 log_dir /var/log/placement # 服务监听地址0.0.0.0 表示监听所有网卡生产环境建议绑定内网 IP bind_host 0.0.0.0 # 服务监听端口必须与 Keystone 端点 URL 中的端口一致8778 bind_port 8778[placement_database] 区块数据库连接[placement_database] # 数据库连接字符串格式为 mysqlpymysql://user:passwordhost/db # 关键点host 必须是数据库服务器的可解析主机名或 IP不能是 localhost除非 DB 与 Placement 同机 connection mysqlpymysql://placement:StrongPass123!controller/placement # 连接池大小根据并发请求量调整默认 30 对中小规模云足够 max_pool_size 30 # 连接超时时间秒避免长时间挂起 idle_timeout 3600[api] 区块API 层配置[api] # 认证策略必须为 keystone这是 Placement 的唯一支持方式 auth_strategy keystone # 启用 CORS跨域资源共享便于前端 Web UI 调用如 Horizon 插件 enable_cors true # CORS 允许的来源生产环境应限制为 Horizon 的域名 cors_allowed_origin http://controller[keystone_authtoken] 区块Keystone 认证集成[keystone_authtoken] # Keystone v3 认证 URL必须与 admin-openrc 中的 auth_url 一致 auth_url http://controller:5000/v3 # Memcached 服务器地址用于 Token 缓存提升性能 memcached_servers controller:11211 # 认证类型为 password与 openstack user create 方式匹配 auth_type password # 项目域和用户域均为 default project_domain_name default user_domain_name default # 项目名称必须为 service这是 Placement 用户所属的项目 project_name service # 用户名和密码必须与 Keystone 中创建的 placement 用户完全一致 username placement password StrongPass123! # 服务域名称固定为 default service_domain_name default # 服务用户名固定为 placement service_username placement # 服务用户密码同上 service_password StrongPass123!实操心得配置完成后务必使用placement-manage db sync命令初始化数据库表结构。该命令会读取/usr/lib/python3.6/site-packages/placement/db/sqlalchemy/migrate_repo/versions/下的迁移脚本逐条执行 SQL 创建resource_providers、inventories等核心表。如果执行时报错ModuleNotFoundError: No module named pymysql说明 Python MySQL 驱动未安装需执行pip3 install PyMySQL。3.4 数据库同步与服务启动placement-manage工具的底层原理与排错placement-manage db sync命令是 Placement 部署的“临门一脚”其背后是 SQLAlchemy-Migrate 框架驱动的数据库版本管理。理解其工作原理能让你在同步失败时快速定位# 1. 以 placement 用户身份执行同步确保权限最小化 $ su -s /bin/sh -c placement-manage db sync placement # 2. 同步成功后检查数据库表是否创建 $ mysql -u placement -pStrongPass123! -h controller placement -e SHOW TABLES; # 预期输出应包含alembic_version, allocations, inventories, resource_providers, traits, ...placement-manage工具的工作流如下读取/usr/lib/python3.6/site-packages/placement/db/sqlalchemy/migrate_repo/versions/目录下的所有.py迁移脚本如001_initial.py,002_add_traits.py查询alembic_version表获取当前数据库的版本号初始为空按脚本文件名的数字序号依次执行upgrade()函数创建对应表结构每执行完一个脚本将新版本号写入alembic_version表。如果同步失败最常见的原因是数据库连接失败检查placement.conf中的connection字符串确认 host、port、user、password、database 名称全部正确且网络可达权限不足placement用户缺少CREATE或ALTER权限需回到 3.1 节重新授权字符集不匹配数据库创建时未指定utf8mb4导致某些字段如traits.name创建失败需删除数据库并重做。服务启动与验证# 1. 启动 httpd 服务Placement 通过 Apache httpd 的 mod_wsgi 托管 $ systemctl enable httpd $ systemctl start httpd # 2. 检查 httpd 是否监听 8778 端口 $ ss -tlnp | grep :8778 # 输出应类似LISTEN 0 128 *:8778 *:* users:((httpd,pid12345,fd6)) # 3. 检查 Placement 服务状态通过 httpd 的日志 $ tail -f /var/log/httpd/placement_error.log # 正常启动应无 ERROR 级别日志只有 INFO 级别的 Starting placement API3.5 API 可用性终极验证curl 命令直连、响应码解读、JSON 结构分析部署完成的最终标志是 Placement API 能够稳定响应标准 HTTP 请求。以下是一套完整的、生产级的验证方案# 1. 获取管理员 token用于后续 API 调用 $ ADMIN_TOKEN$(openstack token issue -f value -c id) # 2. 调用 /resource_providers 接口获取所有已注册的资源提供者 # 这是 Placement 的“健康检查”接口返回空数组 [] 也代表服务正常 $ curl -s -H X-Auth-Token: $ADMIN_TOKEN -H OpenStack-API-Version: placement 1.21 http://controller:8778/resource_providers | python3 -m json.tool # 3. 调用 /allocation_candidates 接口模拟 Nova 的调度查询 # 此请求会触发 Placement 的核心逻辑JOIN 多张表、计算资源余量、应用 Traits 过滤 $ curl -s -H X-Auth-Token: $ADMIN_TOKEN -H OpenStack-API-Version: placement 1.21 \ http://controller:8778/allocation_candidates?resourcesVCPU:1,MEMORY_MB:1024,DISK_GB:10 | python3 -m json.tool # 4. 检查 HTTP 响应码必须为 200 $ curl -o /dev/null -s -w %{http_code}\n -H X-Auth-Token: $ADMIN_TOKEN http://controller:8778/resource_providers # 输出应为200一个典型的allocation_candidates响应 JSON 结构解析{ allocation_requests: [ { allocations: { 5c5a578f-51b0-481c-b38c-7aaa3394e585: { resources: { VCPU: 1, MEMORY_MB: 1024, DISK_GB: 10 } } } } ], provider_summaries: { 5c5a578f-51b0-481c-b38c-7aaa3394e585: { resources: { VCPU: { used: 0, capacity: 512 }, MEMORY_MB: { used: 0, capacity: 60670 } } } } }allocation_requests字段告诉 Nova“你可以把这台虚拟机的资源分配到 UUID 为5c5a578f...的资源提供者上”provider_summaries字段告诉 Nova“这个提供者当前还有 512 个 VCPU、60670 MB 内存可用”。实操心得如果curl返回401 Unauthorized说明 Keystone 认证失败检查placement.conf中的keystone_authtoken配置如果返回500 Internal Server Error检查/var/log/httpd/placement_error.log90% 的情况是数据库连接字符串错误或placement用户权限不足如果返回503 Service Unavailable说明 httpd 未正确加载 Placement WSGI 应用需检查/etc/httpd/conf.d/10-placement.conf文件是否存在且内容正确。4. 核心功能实战Resource Provider Aggregates 与 Resource Traits 的生产级应用4.1 Resource Provider Aggregates超越 Host Aggregate 的资源分组新范式Resource Provider AggregatesRPA是 Placement 提供的、比 Nova 原生 Host Aggregate 更底层、更灵活的资源分组机制。它的核心价值在于Host Aggregate 是面向“主机集合”的逻辑分组而 RPA 是面向“资源提供者”的物理分组它能跨越计算、存储、网络等不同资源类型进行统一聚合。在生产环境中RPA 的典型应用场景是异构硬件资源池的精细化管理。例如我们为一家金融客户部署的 OpenStack其计算资源分为三类通用型GeneralIntel Xeon Silver 4210128GB RAMSATA SSD高性能型High-PerfAMD EPYC 7742512GB RAMNVMe SSDGPU 型GPUIntel Xeon Gold 6248R NVIDIA A100256GB RAM。如果仅用 Nova 的 Host Aggregate你只能把主机分组但无法表达“高性能型主机上的 NVMe 存储”和“GPU 型主机上的 A100 显卡”之间的关联。而 RPA 允许你为每个资源提供者Resource Provider打上多个聚合标签实现多维度交叉管理。实操步骤# 1. 创建三个 Aggregates获取其 UUID $ openstack aggregate create --zone nova general_pool $ openstack aggregate create --zone nova high_perf_pool $ openstack aggregate create --zone nova gpu_pool # 2. 获取计算节点的 Resource Provider UUID假设节点名为 compute01 $ openstack resource provider list | grep compute01 # 输出| 5c5a578f-51b0-481c-b38c-7aaa3394e585 | compute01 | ... | # 3. 将 compute01 的 RP 添加到 general_pool注意此处操作的是 RP不是主机 $ openstack resource provider aggregate set 5c5a578f-51b0-481c-b38c-7aaa3394e585 \ $(openstack aggregate show general_pool -f value -c id) # 4. 创建一个存储资源提供者Ceph Pool并将其加入 high_perf_pool # 假设 Ceph Pool 的 RP UUID 为 a99bad54-a275-4c4f-a8a3-ac00d57e5c64 $ openstack resource provider aggregate set a99bad54-a275-4c4f-a8a3-ac00d57e5c64 \ $(openstack aggregate show high_perf_pool -f value -c id)调度验证# 查询仅属于 high_perf_pool 的资源提供者能提供的候选方案 $ curl -s -H X-Auth-Token: $ADMIN_TOKEN \ http://controller:8778/allocation_candidates?resourcesVCPU:4,MEMORY_MB:16384,DISK_GB:100member_of$(openstack aggregate show high_perf_pool -f value -c id) | python3 -m json.tool此请求将只返回那些同时满足资源需求且被标记为high_perf_pool的 RP从而确保高性能虚拟机一定调度到高性能硬件上。4.2 Resource Traits为资源打上“DNA 标签”的自定义特征系统Resource Traits 是 Placement 最强大的抽象能力之一。它允许你为任何资源提供者无论是物理机、存储池还是网络设备定义任意的、可查询的特征标签。这些标签不是简单的字符串而是被 Placement 内部索引的、支持高效布尔查询的“特征位”。Trait 命名规范与最佳实践所有自定义 Trait 必须以CUSTOM_开头这是 Placement 的硬性规定用于区分社区预定义 Trait如HW_CPU_X86_SSE2名称应具有业务含义避免缩写歧义例如CUSTOM_FINANCE_SECURE_ENCLAVE优于CUSTOM_FSETrait 名称应全大写用下划线分隔单词保持风格统一。创建与应用 Trait 的完整流程# 1. 创建一个自定义 Trait标识“支持国密算法” $ curl -X PUT -H X-Auth-Token: $ADMIN_TOKEN \ http://controller:8778/traits/CUSTOM_SM4_ENCRYPTION # 2. 为某台物理主机RP UUID: 5c5a578f-...添加该 Trait # 注意PUT 操作是“全量覆盖”所以必须先 GET 当前 Traits再追加 $ CURRENT_TRAITS$(curl -s -H X-Auth-Token: $ADMIN_TOKEN \ http://controller:8778/resource_providers/5c5a578f-51b0-481c-b38c-7aaa3394e585/traits | jq -r .traits[] | tr \n , | sed s/,$//) $ NEW_TRAITS[$CURRENT_TRAITS,\CUSTOM_SM4_ENCRYPTION\] # 3. 更新 RP 的 Traits 列表需要带上 resource_provider_generation防止并发冲突 $ GENERATION$(curl -s -H X-Auth-Token: $ADMIN_TOKEN \ http://controller:8778/resource_providers/5c5a578f-51b0-481c-b38c-7aaa3394e585 | jq -r .generation) $ curl -X PUT -H X-Auth-Token: $ADMIN_TOKEN \ -H Content-Type: application/json \ -d {\resource_provider_generation\: $GENERATION, \traits\: [$NEW_TRAITS]} \ http://controller:8778/resource_providers/5c5a578f-51b0-481c-b38c-7aaa3394e585/traits # 4. 验证 Trait 是否生效 $ openstack resource provider trait list 5c5a578f-51b0-481c-b38c-7aaa3394e585调度应用# 创建虚拟机时强制要求其运行在支持国密算法的主机上 $ openstack server create --flavor m1.small --image cirros \ --nic net-idnet1 --hint traitCUSTOM_SM4_ENCRYPTION \ --security-group default secure-vmNova Scheduler 在调用 Placement 时会自动在allocation_candidates请求中加入requiredCUSTOM_SM4_ENCRYPTION参数Placement 将只返回那些 Traits 列表中包含该标签的 RP。注意事项Trait 的添加/删除操作是原子性的但resource_provider_generation字段必须正确传递否则会收到409 Conflict错误。这是 Placement 的乐观锁机制用于防止并发更新冲突。generation值在每次 RP 的任何变更如添加 Trait、更新 Inventory后都会自增因此必须在 GET 后立即使用。5. 常见问题与排查技巧实录从 401 到 500 的全链路故障树5.1 认证失败401 UnauthorizedKeystone 配置的七种死因401 Unauthorized是 Placement 部署中最常见的错误它意味着 Placement 无法通过 Keystone 验证请求者的身份。以下是我在生产环境中遇到并解决的全部七种根因故障现象根本原因排查命令解决方案curl返回401但 Keystone token 本身有效placement.conf中keystone_authtoken.auth_url指向了错误的 Keystone 地址如http://localhost:5000/v3grep auth_url /etc/placement/placement.conf修改为http://controller:5000/v3确保 controller 可被所有节点解析openstack placement service list报错401Keystone 中 placement 用户未被赋予admin角色到service项目openstack role assignment list --user placement --project service --names执行openstack role add --project service --user placement adminplacement-manage db sync报错401placement-manage工具内部调用 Keystone API 时未正确读取
OpenStack Placement服务部署全流程详解
1. 项目概述为什么 Placement 不是“可有可无”的配角而是 OpenStack 资源调度的中枢神经OpenStack Placement 服务部署全流程——这八个字背后藏着一个被大量新手和运维人员严重低估的关键事实从 Pike 版本2017年起Placement 就不再是 Nova 的一个可选插件而是整个 OpenStack 云平台资源调度体系的强制性基础设施。如果你跳过 Placement 或部署失败nova-compute 服务根本无法注册上线nova-scheduler 会直接报错退出你连创建第一台虚拟机的命令都执行不了。这不是理论风险而是我亲手在三套不同规模的生产环境里反复验证过的硬性门槛。很多人看到“Placement”这个词下意识觉得它只是个“放东西的地方”类似数据库里的一个表结构。但实际完全相反——Placement 是 OpenStack 的“资源总账本”“调度情报中心”。它不负责计算、不负责存储、不负责网络但它必须精确知道哪台物理服务器有多少 CPU 核、多少内存、多少本地磁盘哪个 Ceph 存储池还剩多少 GB 可用空间哪块网卡支持 SR-IOV、哪块支持 OVS-DPDK甚至某台主机是否安装了特定型号的 GPU、是否接入了专用 InfiniBand 网络。这些信息不再由 Nova 自己零散地、周期性地轮询上报而是由 Placement 统一建模、统一索引、统一提供查询接口。这就解释了为什么标题里强调“全流程”——它不是装个包、启个服务就完事。Placement 的部署成败直接取决于你对 OpenStack 整体架构的理解深度。比如它的数据库必须独立于 Nova 数据库因为 Nova 的 nova_api 库只存虚拟机元数据而 Placement 的 placement 库要承载所有资源提供者Resource Provider的库存Inventory、使用量Usage、特征标签Traits、聚合分组Aggregates四维数据模型。再比如它的认证必须走 Keystone 的 password 认证方式且用户必须绑定 service 项目下的 admin 角色否则 Nova 组件在调用 Placement API 时会因权限不足被拒错误日志里只会显示模糊的401 Unauthorized根本不会告诉你缺的是哪个环节。更关键的是Placement 的价值在多资源类型混合场景下才真正爆发。举个真实案例我们曾为一家广电客户部署 OpenStack他们既有传统 x86 计算节点又有搭载 AMD EPYC 处理器的渲染集群还有专用于 AI 推理的 A100 GPU 节点。如果不用 PlacementNova 只能靠简单的 CPU/内存过滤器粗筛结果就是渲染任务被调度到普通计算节点上跑得极慢GPU 任务又因缺乏显存感知而频繁失败。引入 Placement 后我们给渲染节点打上CUSTOM_RENDER_CLUSTER标签给 GPU 节点打上CUSTOM_AI_ACCELERATOR标签并在创建实例时通过--hint traitCUSTOM_RENDER_CLUSTER强制指定调度成功率从 63% 直接拉升到 99.8%。这种细粒度的资源画像能力正是 Placement 存在的根本意义。所以当你看到热搜词里“手把手教你搭建 openstack”“基于 packstack 的三节点部署”时请务必清醒那些教程如果没把 Placement 单独拎出来讲透、没演示如何验证其 API 是否真正可用、没说明它与 Nova 的交互链路那它们教的只是半套 OpenStack。本文接下来要做的就是带你从零开始把 Placement 这个“看不见的调度大脑”完整地、可验证地、抗压地部署起来每一步都附带原理拆解和避坑提示让你部署完不是“能跑”而是“跑得稳、查得清、扩得开”。2. 核心设计逻辑为什么必须独立部署、为何不能复用 Nova 数据库、API 端口为何锁定 87782.1 架构定位决定部署必须独立从 Nova 的“子模块”到 OpenStack 的“一级公民”Placement 的演进路径清晰揭示了其部署逻辑的必然性。它最早在 Newton 版本2016年作为 Nova 代码树中的一个 API 模块孵化此时它确实可以和 Nova 共享数据库、共用服务进程。但 Ocata 版本2017年开始社区明确将其定位为“独立服务”核心动因是解耦与扩展性。试想一下如果 Placement 还寄生在 Nova 里当你要对接外部存储如 Pure Storage、外部网络如 Cisco ACI、甚至外部 GPU 管理平台如 NVIDIA DGX Manager时每一次新增资源类型都得修改 Nova 的核心代码、重新编译、重启整个 Nova 服务——这对生产环境是不可接受的停机风险。因此Stein 版本2019年Placement 彻底脱离 Nova 代码库成为 OpenStack 社区的第 15 个独立项目。这意味着它的部署必须遵循 OpenStack “服务自治”原则独立进程、独立配置、独立数据库、独立日志、独立监控端点。你不能用systemctl start openstack-nova-api顺带启动 Placement也不能把placement.conf配置写进nova.conf里。它必须像 Keystone、Glance 一样拥有自己的 systemd unit 文件openstack-placement-api.service自己的配置目录/etc/placement/自己的 WSGI 应用/usr/lib/python3.6/site-packages/placement/api.py。这是架构层面的铁律任何试图“偷懒合并”的做法都会在后续升级或故障排查时付出十倍代价。2.2 数据库隔离的深层原因资源模型与业务模型的本质差异为什么 Placement 必须拥有专属数据库很多教程只说“按文档操作”却从不解释背后的数据库设计哲学。关键在于Nova 数据库描述的是“谁用了什么”而 Placement 数据库描述的是“什么能被谁用”。Nova 的nova_api.allocations表记录的是具体消费行为consumer_id虚拟机 UUID、resource_provider_id计算节点 UUID、resource_class_idVCPU/MEMORY_MB、used已分配数量。这是事务性的、一次性的、不可逆的“记账”。Placement 的placement.resource_providers、placement.inventories、placement.allocations表则构建了一个动态的、可查询的“资源地图”resource_providers表定义了所有资源提供者物理机、存储池、网络设备的元信息inventories表定义了每个提供者能提供哪些资源、总量多少allocations表则实时反映当前已被占用的资源量。这是一个持续更新的“状态快照”而非历史流水。这种模型差异导致数据库负载特征完全不同。Nova 的 allocations 表写入频率高每次创建/删除虚拟机都写、查询模式简单按 consumer_id 查Placement 的 inventories 表写入频率低仅资源提供者上线/下线时变更、但查询极其复杂allocation_candidatesAPI 需要跨resource_providers、inventories、allocations、traits四张表做多层 JOIN 和聚合计算。如果强行共用数据库当 Placement 执行一个复杂的GET /allocation_candidates?resourcesVCPU:4,MEMORY_MB:8192,DISK_GB:100requiredCUSTOM_GPU查询时其锁表时间可能阻塞 Nova 的虚拟机创建流程造成雪崩式超时。独立数据库本质是用存储成本换取服务稳定性。2.3 API 端口锁定 8778 的工程考量避免端口冲突与标准化运维Placement API 默认监听 8778 端口这个数字并非随意指定而是 OpenStack 社区经过长期实践形成的端口公约Port Convention。在 OpenStack 服务端口规划中8000-8999 区间被专门划给“API 服务”其中8000-8099预留给人工智能/ML 相关服务如 DAI8100-8199预留给容器/编排服务如 Zun8200-8299预留给安全审计服务如 Barbican8777-8779明确分配给 Placement 服务8777 为旧版兼容8778 为主力8779 为备用选择 8778 而非更“顺口”的 8000 或 8080核心是为了规避与常见 Web 服务的端口冲突。8080 是 Tomcat、Nginx 的默认 HTTP 端口8000 是 Django、Flask 开发服务器常用端口80 是标准 HTTP 端口。如果 Placement 也用 8080在单节点 All-in-One 部署中httpdApache和 Placement WSGI 应用会争抢同一个端口导致服务启动失败。而 8778 这个“冷门”端口在绝大多数 Linux 发行版和企业防火墙策略中都是空闲的极大降低了部署时的端口调试成本。更重要的是端口标准化带来了运维一致性。当你在生产环境中部署数十个 OpenStack 服务时运维脚本、监控告警规则、防火墙策略都可以基于端口号快速匹配。例如Zabbix 监控模板可以直接写net.tcp.port[{HOST.IP},8778]来检查 Placement API 是否存活而无需为每个服务单独维护端口映射表。这种看似微小的约定实则是大型云平台可维护性的基石。3. 部署全流程详解从数据库初始化到 API 可用性验证的每一步实操3.1 数据库准备创建专用库、授权、字符集校验的完整命令链Placement 数据库的创建远不止CREATE DATABASE placement;这一行命令。一个健壮的生产环境部署必须包含字符集、排序规则、用户权限的精细化控制。以下是我在 CentOS 7 MariaDB 10.3 环境下验证通过的完整操作序列# 1. 以 root 用户登录 MariaDB 控制台 $ mysql -u root -p # 2. 创建 placement 数据库并显式指定字符集和排序规则 # 关键点必须使用 utf8mb4而非旧版 utf8以支持完整 Unicode如 emoji、中文生僻字 MariaDB [(none)] CREATE DATABASE placement CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 3. 创建专用数据库用户 placement并授予最小必要权限 # 注意这里只授予 placement.* 的权限而非全局 *.*符合最小权限原则 MariaDB [(none)] GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON placement.* TO placementlocalhost IDENTIFIED BY StrongPass123!; # 4. 授予从任意 IP%连接的权限适配多节点部署场景 # 生产环境建议将 % 替换为具体的 controller 节点 IP如 192.168.1.10 MariaDB [(none)] GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON placement.* TO placement% IDENTIFIED BY StrongPass123!; # 5. 刷新权限使配置立即生效 MariaDB [(none)] FLUSH PRIVILEGES; # 6. 退出 MariaDB MariaDB [(none)] EXIT;提示密码StrongPass123!仅为示例生产环境必须使用密码管理工具生成高强度随机密码并通过 Ansible Vault 或 HashiCorp Vault 加密存储严禁明文写入配置文件或脚本。完成数据库创建后务必进行连接性验证这是最容易被忽略却最关键的一步# 使用刚创建的用户连接数据库测试基本读写能力 $ mysql -u placement -pStrongPass123! -h localhost placement -e SHOW TABLES; # 预期输出空结果因为尚未初始化表结构但不应报错 # 测试远程连接从其他节点 ping controller 的 3306 端口 $ telnet controller 3306 # 如果连接失败需检查 MariaDB 的 bind-address 配置/etc/my.cnf.d/server.cnf 中应为 bind-address 0.0.0.0 或具体 IP3.2 Keystone 服务注册用户、角色、服务条目、端点的四步闭环Placement 作为 OpenStack 服务必须在 Keystone 中完成完整的身份注册形成“用户-角色-服务-端点”四要素闭环。任何一环缺失Nova 都无法通过 Keystone 获取 Placement 的访问令牌Token。以下是严格按依赖顺序执行的操作# 1. 加载 admin 凭据确保已正确配置 admin-openrc 文件 $ . admin-openrc # 2. 创建 placement 用户密码需与 placement.conf 中配置一致 $ openstack user create --domain default --password-prompt placement # 输入密码StrongPass123! 与数据库密码相同便于记忆但生产环境建议分离 # 3. 将 placement 用户添加到 service 项目并赋予 admin 角色 # 关键点必须是 service 项目且角色必须是 admin这是 Placement API 认证的硬性要求 $ openstack role add --project service --user placement admin # 4. 创建 Placement 服务条目type 必须为 placement $ openstack service create --name placement --description Placement API placement # 5. 创建三个端点public/internal/adminURL 必须指向 controller 主机名或 IP # 注意URL 中的 controller 必须能在所有节点包括 compute 节点上 DNS 解析 $ 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注意openstack endpoint create命令返回的id字段是唯一的可用于后续故障排查。如果执行时报错No endpoint found for placement说明前一步openstack service create未成功需先检查服务条目是否存在openstack service list | grep placement。验证 Keystone 注册是否成功的最直接方法是模拟 Nova 的认证流程# 获取 placement 用户的 token此 token 将被 Nova 用于调用 Placement API $ openstack token issue --os-username placement --os-password StrongPass123! --os-project-name service --os-user-domain-name default --os-project-domain-name default --os-auth-url http://controller:5000/v3 # 输出中应包含 id 字段即有效的 token 字符串形如 gAAAAAB...长度约 300 字符 # 如果报错 The request you have made requires authentication.说明 Keystone 认证环节失败需回溯检查用户、项目、角色绑定3.3 Placement 服务安装与核心配置placement.conf的逐项解析与安全加固在控制节点controller上安装 Placement 服务包并对其进行深度配置是部署的核心环节。以下是在 CentOS 7 上的标准操作# 1. 安装 openstack-placement-api 包RHEL/CentOS 系 $ yum install -y openstack-placement-api # 2. 备份原始配置文件永远的第一步 $ cp /etc/placement/placement.conf /etc/placement/placement.conf.bak.$(date %Y%m%d) # 3. 编辑主配置文件 /etc/placement/placement.conf $ vi /etc/placement/placement.conf配置文件需重点修改以下四个区块每一项都有其不可替代的作用[DEFAULT] 区块基础服务行为[DEFAULT] # 日志级别设为 INFO便于初期调试生产环境可调为 WARNING 以减少日志量 debug false # 日志文件路径确保 /var/log/placement 目录存在且 placement 用户有写入权限 log_dir /var/log/placement # 服务监听地址0.0.0.0 表示监听所有网卡生产环境建议绑定内网 IP bind_host 0.0.0.0 # 服务监听端口必须与 Keystone 端点 URL 中的端口一致8778 bind_port 8778[placement_database] 区块数据库连接[placement_database] # 数据库连接字符串格式为 mysqlpymysql://user:passwordhost/db # 关键点host 必须是数据库服务器的可解析主机名或 IP不能是 localhost除非 DB 与 Placement 同机 connection mysqlpymysql://placement:StrongPass123!controller/placement # 连接池大小根据并发请求量调整默认 30 对中小规模云足够 max_pool_size 30 # 连接超时时间秒避免长时间挂起 idle_timeout 3600[api] 区块API 层配置[api] # 认证策略必须为 keystone这是 Placement 的唯一支持方式 auth_strategy keystone # 启用 CORS跨域资源共享便于前端 Web UI 调用如 Horizon 插件 enable_cors true # CORS 允许的来源生产环境应限制为 Horizon 的域名 cors_allowed_origin http://controller[keystone_authtoken] 区块Keystone 认证集成[keystone_authtoken] # Keystone v3 认证 URL必须与 admin-openrc 中的 auth_url 一致 auth_url http://controller:5000/v3 # Memcached 服务器地址用于 Token 缓存提升性能 memcached_servers controller:11211 # 认证类型为 password与 openstack user create 方式匹配 auth_type password # 项目域和用户域均为 default project_domain_name default user_domain_name default # 项目名称必须为 service这是 Placement 用户所属的项目 project_name service # 用户名和密码必须与 Keystone 中创建的 placement 用户完全一致 username placement password StrongPass123! # 服务域名称固定为 default service_domain_name default # 服务用户名固定为 placement service_username placement # 服务用户密码同上 service_password StrongPass123!实操心得配置完成后务必使用placement-manage db sync命令初始化数据库表结构。该命令会读取/usr/lib/python3.6/site-packages/placement/db/sqlalchemy/migrate_repo/versions/下的迁移脚本逐条执行 SQL 创建resource_providers、inventories等核心表。如果执行时报错ModuleNotFoundError: No module named pymysql说明 Python MySQL 驱动未安装需执行pip3 install PyMySQL。3.4 数据库同步与服务启动placement-manage工具的底层原理与排错placement-manage db sync命令是 Placement 部署的“临门一脚”其背后是 SQLAlchemy-Migrate 框架驱动的数据库版本管理。理解其工作原理能让你在同步失败时快速定位# 1. 以 placement 用户身份执行同步确保权限最小化 $ su -s /bin/sh -c placement-manage db sync placement # 2. 同步成功后检查数据库表是否创建 $ mysql -u placement -pStrongPass123! -h controller placement -e SHOW TABLES; # 预期输出应包含alembic_version, allocations, inventories, resource_providers, traits, ...placement-manage工具的工作流如下读取/usr/lib/python3.6/site-packages/placement/db/sqlalchemy/migrate_repo/versions/目录下的所有.py迁移脚本如001_initial.py,002_add_traits.py查询alembic_version表获取当前数据库的版本号初始为空按脚本文件名的数字序号依次执行upgrade()函数创建对应表结构每执行完一个脚本将新版本号写入alembic_version表。如果同步失败最常见的原因是数据库连接失败检查placement.conf中的connection字符串确认 host、port、user、password、database 名称全部正确且网络可达权限不足placement用户缺少CREATE或ALTER权限需回到 3.1 节重新授权字符集不匹配数据库创建时未指定utf8mb4导致某些字段如traits.name创建失败需删除数据库并重做。服务启动与验证# 1. 启动 httpd 服务Placement 通过 Apache httpd 的 mod_wsgi 托管 $ systemctl enable httpd $ systemctl start httpd # 2. 检查 httpd 是否监听 8778 端口 $ ss -tlnp | grep :8778 # 输出应类似LISTEN 0 128 *:8778 *:* users:((httpd,pid12345,fd6)) # 3. 检查 Placement 服务状态通过 httpd 的日志 $ tail -f /var/log/httpd/placement_error.log # 正常启动应无 ERROR 级别日志只有 INFO 级别的 Starting placement API3.5 API 可用性终极验证curl 命令直连、响应码解读、JSON 结构分析部署完成的最终标志是 Placement API 能够稳定响应标准 HTTP 请求。以下是一套完整的、生产级的验证方案# 1. 获取管理员 token用于后续 API 调用 $ ADMIN_TOKEN$(openstack token issue -f value -c id) # 2. 调用 /resource_providers 接口获取所有已注册的资源提供者 # 这是 Placement 的“健康检查”接口返回空数组 [] 也代表服务正常 $ curl -s -H X-Auth-Token: $ADMIN_TOKEN -H OpenStack-API-Version: placement 1.21 http://controller:8778/resource_providers | python3 -m json.tool # 3. 调用 /allocation_candidates 接口模拟 Nova 的调度查询 # 此请求会触发 Placement 的核心逻辑JOIN 多张表、计算资源余量、应用 Traits 过滤 $ curl -s -H X-Auth-Token: $ADMIN_TOKEN -H OpenStack-API-Version: placement 1.21 \ http://controller:8778/allocation_candidates?resourcesVCPU:1,MEMORY_MB:1024,DISK_GB:10 | python3 -m json.tool # 4. 检查 HTTP 响应码必须为 200 $ curl -o /dev/null -s -w %{http_code}\n -H X-Auth-Token: $ADMIN_TOKEN http://controller:8778/resource_providers # 输出应为200一个典型的allocation_candidates响应 JSON 结构解析{ allocation_requests: [ { allocations: { 5c5a578f-51b0-481c-b38c-7aaa3394e585: { resources: { VCPU: 1, MEMORY_MB: 1024, DISK_GB: 10 } } } } ], provider_summaries: { 5c5a578f-51b0-481c-b38c-7aaa3394e585: { resources: { VCPU: { used: 0, capacity: 512 }, MEMORY_MB: { used: 0, capacity: 60670 } } } } }allocation_requests字段告诉 Nova“你可以把这台虚拟机的资源分配到 UUID 为5c5a578f...的资源提供者上”provider_summaries字段告诉 Nova“这个提供者当前还有 512 个 VCPU、60670 MB 内存可用”。实操心得如果curl返回401 Unauthorized说明 Keystone 认证失败检查placement.conf中的keystone_authtoken配置如果返回500 Internal Server Error检查/var/log/httpd/placement_error.log90% 的情况是数据库连接字符串错误或placement用户权限不足如果返回503 Service Unavailable说明 httpd 未正确加载 Placement WSGI 应用需检查/etc/httpd/conf.d/10-placement.conf文件是否存在且内容正确。4. 核心功能实战Resource Provider Aggregates 与 Resource Traits 的生产级应用4.1 Resource Provider Aggregates超越 Host Aggregate 的资源分组新范式Resource Provider AggregatesRPA是 Placement 提供的、比 Nova 原生 Host Aggregate 更底层、更灵活的资源分组机制。它的核心价值在于Host Aggregate 是面向“主机集合”的逻辑分组而 RPA 是面向“资源提供者”的物理分组它能跨越计算、存储、网络等不同资源类型进行统一聚合。在生产环境中RPA 的典型应用场景是异构硬件资源池的精细化管理。例如我们为一家金融客户部署的 OpenStack其计算资源分为三类通用型GeneralIntel Xeon Silver 4210128GB RAMSATA SSD高性能型High-PerfAMD EPYC 7742512GB RAMNVMe SSDGPU 型GPUIntel Xeon Gold 6248R NVIDIA A100256GB RAM。如果仅用 Nova 的 Host Aggregate你只能把主机分组但无法表达“高性能型主机上的 NVMe 存储”和“GPU 型主机上的 A100 显卡”之间的关联。而 RPA 允许你为每个资源提供者Resource Provider打上多个聚合标签实现多维度交叉管理。实操步骤# 1. 创建三个 Aggregates获取其 UUID $ openstack aggregate create --zone nova general_pool $ openstack aggregate create --zone nova high_perf_pool $ openstack aggregate create --zone nova gpu_pool # 2. 获取计算节点的 Resource Provider UUID假设节点名为 compute01 $ openstack resource provider list | grep compute01 # 输出| 5c5a578f-51b0-481c-b38c-7aaa3394e585 | compute01 | ... | # 3. 将 compute01 的 RP 添加到 general_pool注意此处操作的是 RP不是主机 $ openstack resource provider aggregate set 5c5a578f-51b0-481c-b38c-7aaa3394e585 \ $(openstack aggregate show general_pool -f value -c id) # 4. 创建一个存储资源提供者Ceph Pool并将其加入 high_perf_pool # 假设 Ceph Pool 的 RP UUID 为 a99bad54-a275-4c4f-a8a3-ac00d57e5c64 $ openstack resource provider aggregate set a99bad54-a275-4c4f-a8a3-ac00d57e5c64 \ $(openstack aggregate show high_perf_pool -f value -c id)调度验证# 查询仅属于 high_perf_pool 的资源提供者能提供的候选方案 $ curl -s -H X-Auth-Token: $ADMIN_TOKEN \ http://controller:8778/allocation_candidates?resourcesVCPU:4,MEMORY_MB:16384,DISK_GB:100member_of$(openstack aggregate show high_perf_pool -f value -c id) | python3 -m json.tool此请求将只返回那些同时满足资源需求且被标记为high_perf_pool的 RP从而确保高性能虚拟机一定调度到高性能硬件上。4.2 Resource Traits为资源打上“DNA 标签”的自定义特征系统Resource Traits 是 Placement 最强大的抽象能力之一。它允许你为任何资源提供者无论是物理机、存储池还是网络设备定义任意的、可查询的特征标签。这些标签不是简单的字符串而是被 Placement 内部索引的、支持高效布尔查询的“特征位”。Trait 命名规范与最佳实践所有自定义 Trait 必须以CUSTOM_开头这是 Placement 的硬性规定用于区分社区预定义 Trait如HW_CPU_X86_SSE2名称应具有业务含义避免缩写歧义例如CUSTOM_FINANCE_SECURE_ENCLAVE优于CUSTOM_FSETrait 名称应全大写用下划线分隔单词保持风格统一。创建与应用 Trait 的完整流程# 1. 创建一个自定义 Trait标识“支持国密算法” $ curl -X PUT -H X-Auth-Token: $ADMIN_TOKEN \ http://controller:8778/traits/CUSTOM_SM4_ENCRYPTION # 2. 为某台物理主机RP UUID: 5c5a578f-...添加该 Trait # 注意PUT 操作是“全量覆盖”所以必须先 GET 当前 Traits再追加 $ CURRENT_TRAITS$(curl -s -H X-Auth-Token: $ADMIN_TOKEN \ http://controller:8778/resource_providers/5c5a578f-51b0-481c-b38c-7aaa3394e585/traits | jq -r .traits[] | tr \n , | sed s/,$//) $ NEW_TRAITS[$CURRENT_TRAITS,\CUSTOM_SM4_ENCRYPTION\] # 3. 更新 RP 的 Traits 列表需要带上 resource_provider_generation防止并发冲突 $ GENERATION$(curl -s -H X-Auth-Token: $ADMIN_TOKEN \ http://controller:8778/resource_providers/5c5a578f-51b0-481c-b38c-7aaa3394e585 | jq -r .generation) $ curl -X PUT -H X-Auth-Token: $ADMIN_TOKEN \ -H Content-Type: application/json \ -d {\resource_provider_generation\: $GENERATION, \traits\: [$NEW_TRAITS]} \ http://controller:8778/resource_providers/5c5a578f-51b0-481c-b38c-7aaa3394e585/traits # 4. 验证 Trait 是否生效 $ openstack resource provider trait list 5c5a578f-51b0-481c-b38c-7aaa3394e585调度应用# 创建虚拟机时强制要求其运行在支持国密算法的主机上 $ openstack server create --flavor m1.small --image cirros \ --nic net-idnet1 --hint traitCUSTOM_SM4_ENCRYPTION \ --security-group default secure-vmNova Scheduler 在调用 Placement 时会自动在allocation_candidates请求中加入requiredCUSTOM_SM4_ENCRYPTION参数Placement 将只返回那些 Traits 列表中包含该标签的 RP。注意事项Trait 的添加/删除操作是原子性的但resource_provider_generation字段必须正确传递否则会收到409 Conflict错误。这是 Placement 的乐观锁机制用于防止并发更新冲突。generation值在每次 RP 的任何变更如添加 Trait、更新 Inventory后都会自增因此必须在 GET 后立即使用。5. 常见问题与排查技巧实录从 401 到 500 的全链路故障树5.1 认证失败401 UnauthorizedKeystone 配置的七种死因401 Unauthorized是 Placement 部署中最常见的错误它意味着 Placement 无法通过 Keystone 验证请求者的身份。以下是我在生产环境中遇到并解决的全部七种根因故障现象根本原因排查命令解决方案curl返回401但 Keystone token 本身有效placement.conf中keystone_authtoken.auth_url指向了错误的 Keystone 地址如http://localhost:5000/v3grep auth_url /etc/placement/placement.conf修改为http://controller:5000/v3确保 controller 可被所有节点解析openstack placement service list报错401Keystone 中 placement 用户未被赋予admin角色到service项目openstack role assignment list --user placement --project service --names执行openstack role add --project service --user placement adminplacement-manage db sync报错401placement-manage工具内部调用 Keystone API 时未正确读取
