流浪小鱼我刚接触OpenStack那阵子，最劝退我的不是各种Linux命令，而是那一串串“模块清单”：Keystone、Nova、Neutron、Cinder、Glance、Swift、Heat、Octavia……每一个名字都像是一个独立的品牌，光记住它们干嘛的就能耗掉我半管血。后来真正在一套环境里从镜像上传跑到创建云主机、挂卷、配置网络之后才明白，OpenStack之所以拆成这么多模块，不是因为设计者闲得慌，而是因为它本质上就是一套“数据中心物业公司”——每个模块负责一项专门职能，模块之间通过API和消息队列互相配合。这篇东西我尽量用大白话把OpenStack常见模块的定位、分工、调用关系，以及生产环境里最容易踩的坑一次性讲透。不管你是刚入门想搭一套实验环境，还是工作中要维护现有云平台，都应该能从中找到直接能用的东西。
1. 把OpenStack当物业公司看：先弄清“模块”这个词到底指什么
很多教程一上来直接列模块，很容易让人忽略一个关键问题：所谓“模块”，到底是一个程序、一台机器上的进程，还是一整套服务？
在真实运维中，这个词其实有三种用法。第一种是指顶层服务，比如Nova提供计算能力，Neutron提供网络能力，Cinder提供块存储能力；第二种是指某个服务内部拆出来的子组件，比如Nova就不只是一个服务，它包含nova-api、nova-conductor、nova-scheduler、nova-compute等一堆进程；第三种则会把MySQL、RabbitMQ这类支撑组件也算进“模块”。所以当你看到“某个模块挂了”这种描述，先要确认说的是哪一层，不然排查方向很容易跑偏。
我自己习惯用一个比喻来理解OpenStack的整体架构：把它想象成一个大型物业公司。
- Keystone是门口保安兼前台，负责验证你是谁、给你发临时门禁卡。
- Horizon是访客大厅里那块触摸屏，你通过它提交各种申请，但它自己不做决策。
- Nova是物业客服和工程队的调度中枢，专门负责“给你开一间房”以及后续的上下电、搬迁。
- Neutron是网络施工队，管所有房间的网线、交换机、路由和隔离策略。
- Cinder是硬盘库房，负责给你提供“移动硬盘”，可以插到任意一台云主机上。
- Glance是系统安装盘库房，存着一堆现成的ISO/系统镜像，Nova装系统时去这里取。
- Swift像公司内部的公共网盘，适合存文件，但不适合当数据库磁盘用。
- Heat像装修公司，可以一次按图纸把所有房间、网络、存储全部布置好。
- Octavia像大楼入口的流量分配闸机，负责把请求分摊到多台应用服务器上。
下面这个表更直观，看的时候建议先只看第一列和中间一列，不用急着记进程名。
| 模块/服务 | 大白话定位 | 真实职责 |
|---|---|---|
| Keystone | 前台门卫 | 身份认证、权限校验、服务地址目录 |
| Horizon | 大厅触摸屏 | 提供Web操作界面，本质是API客户端 |
| Nova | 物业调度中心 | 管理虚拟机全生命周期 |
| Placement | 房源空位表 | 记录各计算节点有多少CPU、内存、GPU可分配 |
| Neutron | 网络施工队 | 管理网络、子网、端口、路由、负载均衡、安全组 |
| Glance | 系统安装盘仓库 | 管理虚拟机镜像的元数据和存储位置 |
| Cinder | 移动硬盘库房 | 提供可挂载的块存储卷 |
| Swift | 公共网盘 | 提供对象存储服务 |
| Manila | 共享文件夹 | 提供多台云主机可同时挂载的文件共享 |
| Heat | 装修公司 | 通过模板批量创建和编排整组云资源 |
| Octavia | 流量闸机 | 提供负载均衡服务 |
| Ironic | 裸机出租 | 直接管理物理服务器，不装虚拟化层 |
看这个表可以看出一个规律：OpenStack并不是一个“大而全”的软件，而是把云平台常见的需求一个个拆成独立服务。这个拆法带来两大好处，一是每个模块都能独立升级、独立扩展，计算不够就加计算节点，网络瓶颈就横向扩网络节点；二是模块与模块之间通过API交互，生态好，你可以用其他开源方案替换某个模块。坏处也显而易见——入门成本变高了，排查问题时经常需要跨多个模块看日志。
1.1 先分清楚：服务和组件是两个层级
每个顶层服务内部其实是一群组件在协作。举Nova做例子：你调用创建云主机接口时，请求先到nova-api，它校验权限然后把任务丢给nova-conductor，nova-conductor去数据库和调度器那确认该在哪台物理节点执行，最后消息落到目标节点的nova-compute上，真正动手把虚拟机拉起来。
这里每个nova-xxx都是一个独立进程，部署时可以按角色拆分。比如控制节点可以只跑nova-api和nova-conductor，计算节点只跑nova-compute。这就解释了为什么有时候你用openstack service list看服务状态都是UP，但云主机还是创建失败——问题很可能出在某个计算节点的nova-compute进程状态异常，而不是顶层服务没注册。
看日志的时候也要先分清服务层和组件层。比如Nova相关日志一般在/var/log/nova/下面，里面会按组件分成nova-api.log、nova-compute.log、nova-conductor.log等。我在排障时最常犯的一个错误就是只盯着nova-api.log看，结果真正报错在nova-compute.log里，绕了一大圈才找到原因。
1.2 支撑它们的“基础设施”也别忽略
除了前面那些模块，还有两个隐形基础：数据库和消息队列。几乎每个OpenStack模块都要连MySQL保存自己的业务状态，模块之间有很多异步操作不是靠HTTP同步等结果，而是通过RabbitMQ/AMQP发消息。
还是举例：nova-compute要在某台计算节点创建虚拟机，但nova-api不是直接等虚拟机创建完再返回。实际过程是nova-api把请求写进数据库，然后通过消息队列把任务发给nova-scheduler，调度器算完再把目标主机通过消息队列发给nova-compute。虚拟机最终状态从BUILD变成ACTIVE，是nova-compute异步更新的。
所以如果RabbitMQ出现了积压或连接异常，你看到的典型现象就是“状态一直卡在BUILD半天没反应”，或者“OpenStack页面操作没报错但实际没生效”。这个经验很重要，遇到莫名其妙的任务卡住，第一件事先看Rabbi