最开始接触 OpenStack 的时候我一度以为 Nova 就是那个什么都能干的大管家创建实例、查状态、关虚拟机看起来都在 Nova 里操作。真正在生产环境跑过一轮之后才明白Nova 更像是一条流水线上的核心工位它负责计算资源的调度和生命周期管理但一个实例从空请求变成能登录的云主机背后至少要和四个外部组件来回握手Keystone 负责认人Glance 负责给镜像Neutron 负责拉网线Cinder 负责挂硬盘。任何一个环节配合不到位虚机要么起不来要么起来了也访问不了、存不了数据问题还往往不在 Nova 自己身上。这篇文章我不会讲太多理论而是围绕 Nova 和 Glance、Neutron、Cinder、Keystone 这几个组件的实际协作链路把一次实例引导流程拆开讲明白。适合刚上手 OpenStack、正被各种服务间调用关系搞晕的运维和开发同学也适合已经部署完环境、想理清故障排查思路的人。1. 先把职责边界理清楚Nova 管计算那其他人管什么很多初学者会把OpenStack和Nova画等号这是理解后续所有问题的最大障碍。OpenStack 是由多个独立服务组成的分布式系统每个服务管一块领域服务之间通过 REST API 进行通信。Nova 的定位非常聚焦它负责管理计算节点上的虚拟机实例生命周期包括实例的创建、删除、重启、迁移、调整规格等。它并不负责保存镜像文件不负责分配 IP 地址也不负责存储数据。但实例要真正跑起来这些资源又缺一不可。于是 Nova 就扮演了一个资源统筹者的角色按照既定的业务流程去调用其他服务的 API。听上去很优雅但代价也很明确任何外部组件不稳定、配错、或者网络不通都会直接反噬到 Nova 上。组件核心职责与 Nova 的关系Keystone身份认证、令牌签发、服务目录、权限管理Nova 的 API 请求要先通过 Keystone 认证同时 Nova 还要用 Keystone 的服务目录动态发现其他组件的地址Glance镜像存储与元数据管理Nova 在创建实例时向 Glance 请求镜像文件把镜像格式转换并落到本地磁盘作为实例根磁盘Neutron虚拟网络、子网、端口、安全组、路由器Nova 在创建实例前要获得 Neutron 分配的端口计算节点上的虚拟网卡要根据 Neutron 的 binding 信息挂载到对应 bridgeCinder块存储卷管理Nova 在实例需要额外数据盘时调用 Cinder 创建卷、建立存储连接并把卷作为块设备挂载到虚拟机用一句生活化的类比Nova 是开发商Keystone 是小区门禁Glance 是建材仓库Neutron 是水电网络Cinder 是外置硬盘仓库。开发商不可能自己挖建材、自己拉网线它要做的是一门心思把房子盖起来然后不断去催别的部门把资源到位。在部署层面这些组件通常分布在不同的主机上。控制节点跑 Keystone、Glance、Neutron 的 server 端、Cinder 的 API 服务计算节点则主要跑 nova-compute、neutron-openvswitch-agent 等 agent。由于服务实例分散Nova 和外部组件之间的通信都是走网络而不是进程内调用这就意味着任何防火墙规则、路由配置、或者消息队列故障都可能表现成Nova 操作失败了而且报错信息常常只说结果不说原因。还有一点必须提Nova、Glance、Neutron、Cinder 之间的复杂关系不仅是调用方和被调用方很多流程里还存在互相回调。比如 Neutron 在计算节点上得通过 nova-compute 的接口获取虚拟机的 VIF 信息Cinder 卷在挂载时需要 nova-compute 在宿主机上完成设备的扫描和分区。理解了这一点你会明白为什么排查 OpenStack 故障不能只看单组件日志而要有跨组件的全局视角。2. Nova 与 Keystone每个 API 请求前的身份确认环节平常我们调 Nova 的 API随手就敲一条nova list或者openstack server create可能没太注意这个请求第一站并不是 Nova而是 Keystone。OpenStack 的 API 层几乎全部由 Keystone 提供认证保护Nova 也不例外。客户端拿着用户名密码去 Keystone 换一个临时的 token之后所有请求都带着这个 tokenNova 收到请求后先要验证 token 是否有效、请求用户是否对这个项目具备相应权限然后才真正进入业务逻辑。2.1 Nova 如何接入 KeystoneNova 的各种服务进程比如 nova-api、nova-scheduler、nova-conductor、nova-compute它们的配置文件里都有一段身份认证配置指向 Keystone 的地址和鉴权方式。以最常见的nova.conf为例[keystone_authtoken] auth_url http://keystone.example.com:5000/v3 www_authenticate_uri http://keystone.example.com:5000/v3 username nova password 你的密码 project_name service project_domain_name Default user_domain_name Default auth_type password [service_user] send_service_user_token True这里有个容易被忽略的细节nova.conf里的用户名是nova这是一个在service项目里的服务账号不是管理员账号。OpenStack 的安全性建立在项目隔离之上每个服务启动后会用它自己的服务账号去 Keystone 换取 token。而[service_user]这个配置是后来版本比较推荐的。它让 Nova 在收到来自最终用户的请求后另外再拿一个服务账号的 token专门用来在调用 Neutron、Glance、Cinder 时做身份认证。好处是即使最终用户的 token 权限不够Nova 自己仍然能以服务身份去执行某些受限操作。很多老环境没配这个段Nova 调用外部组件时就只能用用户 token一旦用户 token 权限收紧就会莫名其妙出现 403。2.2 服务目录如何让 Nova 找到其他组件Keystone 除了做认证还承担了服务注册中心的功能。Glance、Neutron、Cinder 在安装时都会向 Keystone 登记自己的 endpoint也就是把每个服务的 public 地址、internal 地址、admin 地址写进服务目录。Nova 在调用某个组件时并不是写死 IP而是带着自己的 token 去 Keystone 请求服务目录根据自己的接口类型匹配到实际的 URL。openstack catalog list这个命令可以看到当前环境里的服务目录条目。常见格式大致是------------------------------------------------------- | Name | Type | Endpoints | Region | ------------------------------------------------------- | nova | compute | publicURL... | RegionOne | | glance | image | internalURL | RegionOne | | neutron | network | internalURL | RegionOne | | cinderv3 | volumev3 | internalURL | RegionOne | -------------------------------------------------------Nova 在不同场景下会选择不同接口。一般情况下内部服务之间的调用优先走 internal URL避免绕到公网减少延迟也降低暴露面。如果服务目录里缺少某个组件的登记或者 endpoint 的地址在计算节点上不可达会出现一个非常经典的报错EndpointNotFound或者Unable to find ... endpoint。这种问题的根子多半不在 Nova而在 Keystone 的 endpoint 配置。2.3 令牌过期和跨服务调用失败之间那点事Keystone 签发的 token 有一定有效期默认通常是 1 小时。正常情况下这不会带来任何影响因为每次调用都会重新换取或续期。但如果你有一个耗时很长的操作例如从 Glance 下载一个大镜像或者 Cinder 在创建一个大卷时等待存储后端就绪中间 token 过期Nova 再去调用外部组件就会碰到 401。这种问题在日志里极具迷惑性因为它常常表现为ERROR nova.api.openstack.wsgi Unexpected error: keystoneauth1.exceptions.http.Unauthorized你第一反应会去查 Keystone 的日志甚至改密码但实际上重启 Keystone 也没用因为根因是调用链太长token 的生命周期不够用。处理办法通常是在 nova.conf 里合理设置各项超时时间或者在代码层面让 Nova 在长耗时操作前主动刷新 token。部署层面最容易做的是把 Keystone token 的过期时间调长一些做临时缓解但长期看还是应该依靠服务账号 token 的自动刷新机制。在调试跨服务认证问题时我习惯直接用 curl 验证链路。先拿 service 账号换 token再带 token 请求 Nova 和 Neutron 的 API# 从 Keystone 获取 token curl -s -X POST http://keystone.example.com:5000/v3/auth/tokens \ -H Content-Type: application/json \ -d { auth: { identity: { methods: [password], password: { user: { name: nova, domain: {name: Default}, password: 你的密码 } } }, scope: { project: { name: service, domain: {name: Default} } } } } | python3 -m json.tool响应头里的X-Subject-Token就是后续请求要用的 token拿它去调 Neutron 接口curl -s -H X-Auth-Token: $TOKEN \ http://neutron.example.com:9696/v2.0/networks如果认证配置正确会返回网络列表如果返回 401再检查 token 是不是没写对、服务账号是否存在于 service 项目、以及用户到底有没有访问该 API 的角色权限。3. 从 glance 镜像到内存页Nova 调度与镜像交互的完整链路创建实例时镜像是第一个要被落实的基础资源。这个环节的交互明明发生在 Nova 和 Glance 之间却常常被误以为是 Nova 自己把镜像跑起来了。3.1 Nova 是怎么把镜像拉下来并变成根磁盘的假设你执行了openstack server create --image ubuntu-22.04 ...Nova 侧的操作是先从 Glance 获取镜像元数据得知该镜像的 ID、格式、大小然后由 nova-compute 的实际执行者——可能是 libvirt 虚拟机管理程序也可能是其他虚拟化驱动——调用 Glance 的 API 下载镜像文件。下载完成后镜像不会直接被虚拟机使用。计算节点的 virt 驱动要先判断镜像格式。例如 Glance 里存储的是 qcow2如果虚拟化驱动想要原生 raw 格式就需要做一次格式转换。转换会很消耗 CPU 和磁盘所以大量镜像相同、节点较多的生产环境通常会启用 nova 的镜像缓存功能让常用镜像在每个计算节点本地留下副本后续再创建实例时直接用 localStorage 里的缓存文件省去重复下载和转换。这一步在用户视角上表现为创建实例卡在 BUILD 状态会在 nova-compute 日志里看到类似INFO nova.virt.libvirt.imagecache Checking for base image: uuid INFO nova.virt.libvirt.imagecache Generating image for instance uuid如果镜像文件很大而且 Glance 服务部署在控制节点、计算节点与它之间的网络带宽又有限那么就算 Nova 本身调度逻辑再快整个创建过程也会被镜像分发拖慢。这也是为什么有些团队会把 Glance 的镜像存储放到分布式存储上或者用多数据中心的镜像分区尽量让镜像离计算节点更近。3.2 快照流程同样要回写到 GlanceNova 与 Glance 的合作不止发生在创建实例时还有创建快照这个很常见的操作。用户执行openstack server image createNova 需要把实例当前磁盘的状态制作成新镜像再上传到 Glance。这里有个隐含问题如果实例的根磁盘是 qcow2 格式Nova 通常会用 qemu 的块快照能力获取一个一致性相对不错的磁盘镜像如果是 raw 格式就很可能需要先对磁盘做一次在线快照或者干脆短暂挂起实例。生产环境里一个正在高频写入的大实例做快照既可能拖慢 IO也可能导致快照文件尺寸远超预期上传到 Glance 时又会对控制节点网络造成压力。所以我建议把快照流程和实例本身的负载分开看待。低负载的测试机随便快照没问题高负载的数据库实例做快照最好配合应用层的一致性保障或者用 Cinder 存储后端的快照能力而不是走 Nova 到 Glance 这条通用链路。3.3 Glance 故障如何影响 NovaGlance 如果宕机Nova 并不会立刻完全瘫痪。对于已经存在本地的镜像缓存计算节点仍然可以继续创建实例但任何需要获取新镜像、或者从 Glance 拉取未缓存镜像的请求都会失败。典型报错是ERROR nova.virt.libvirt.utils ImageDownloadFailed: ... Unable to connect to Glance在监控层面我会额外盯 Glance 的 API 响应时间。如果它响应变慢Nova 的创建请求也会跟着变慢因为 nova-compute 在等待下载镜像时通常会阻塞当前实例的创建任务。虽然 Nova 里有一些并发配置能缓解但根源还是要保证 Glance 的存储性能和 API 高可用。另一个值得注意的点Glance 多存储后端时如果某些后端存储不可用Nova 可能会在下载镜像时失败。所以配置 Glance 的存储后端时要把 Nova-compute 访问该存储的网络也需要一并通过安全组或路由打通别只检查了 Glance API 的可达性。4. 让实例有网络Neutron 与 Nova 之间的 port 交接在 OpenStack 环境里虚拟机的网卡并不是插上就能上网。Nova 负责把虚拟机的 vNIC 交给 hypervisorNeutron 负责定义这个 vNIC 要连到哪个虚拟网络、用什么 IP、有哪些安全组规则。两者的接驳点就是 Neutron 里的 port 资源。4.1 创建实例前Nova 先找 Neutron 拿 port执行创建实例命令时Nova 会根据用户指定的网络network ID向 Neutron 请求创建一个 port。这个 port 会绑定一个 MAC 地址、分配一个 IP并关联到对应网络和安全组。Nova 拿到 port 之后才会继续往调度和计算节点走。如果用户没有明确指定网络而是用自动分配的方式Nova 会在默认网络里选一个可用网络创建 port。早期版本里如果环境有多个网络Nova 可能直接报错说Multiple possible networks found最近版本会策略性地选择或者要求用户明确指定。这也是初学者比较常踩的坑明明配好了网络却因为不知道要指定--nic net-idxxx导致创建失败或进入 NAT 网络。创建一个实例时我们可以在 Neutron 侧看到 port 的device_owner变成了compute:None或compute:RegionOne随后变成compute:实例ID。用命令查看openstack port show port-uuid重点看几个字段binding:host_id指出这个 port 被绑定到哪个计算节点binding:vif_type虚拟接口类型常见是bridge或ovsdevice_owner谁占用了这个 portsecurity_group_ids该网卡应用的安全组如果binding:host_id显示为空说明 Neutron 还没有完成到计算节点的 VIF 绑定实例的网络很可能处于故障状态。4.2 Nova-compute 在宿主机上插网线Neutron 创建好 port 后Nova 并不是直接把 port 信息交给虚拟机。实际流程是 nova-compute 根据 Neutron 返回的 port 信息计算节点上的 neutron agent如 neutron-openvswitch-agent 或 neutron-linuxbridge-agent会在宿主机上创建对应的虚拟网卡设备、接入正确的 bridge、配置安全组规则。配置完成后虚拟机的 vNIC 才能出现在 hypervisor 中。这一步骤最常见的故障是 vif plugging 超时。默认情况下 nova-compute 会在一定时间内等待 Neutron agent 完成端口绑定如果等待超时会进入网络故障状态。日志通常长这样ERROR nova.virt.libvirt.vif Virtual interface plugin requires VIF ... WARNING nova.virt.libvirt.vif Timeout while waiting for plugging of VIF看到这类报错不要第一时间怪 Nova去计算节点上查看 neutron agent 状态确认 agent 是否存活以及计算节点和 Neutron 服务间的消息队列通信是否正常。在实际运维中用openstack network agent list查看所有 agent 的 alive 状态是排查网络故障的第一步。4.3 安全组和 DHCP 的问题经常被误诊为起不了网Neutron 不只管虚拟网络拓扑还负责安全组的实现。安全组规则在计算节点上由 neutron agent 通过 iptables/ebtables 规则落地。如果实例起来了但 ping 不通、SSH 连不上很多人会去查 Neutron 路由器、查 DHCP agent却忘了看看安全组。默认安全组通常是只出不进也就是说允许虚拟机主动访问外部但外部主动访问虚拟机的流量会被丢弃。你创建一台新虚拟机后直接 ping 它的 IP大概率 ping 不通因为 ICMP 流量被安全组拦了。这不代表网络坏了而是安全组规则没放行。正确的排查顺序是先在openstack security group rule list里确认是否有放行 icmp、ssh 的规则再去看网络层面。另外Neutron 的 DHCP agent 负责给虚拟网卡下发 IP 地址。如果 DHCP agent 挂掉虚拟机拿不到 IPNova 侧看起来实例是 ACTIVE 的但登录不进去。所以实例状态正常但网络不通的场景多半是 Neutron 的 DHCP 或 L3 服务出了问题而不是 Nova 的问题。5. 给虚机挂硬盘Cinder 卷在 Nova 侧怎么落地数据盘是云主机最基础的扩展方式。Nova 本身不负责持久化存储的管理这方面的能力由 Cinder 提供。创建云主机时指定--boot-from-volume或者在创建后执行openstack server add volume背后都是 Nova 与 Cinder 的复杂协作。5.1 卷创建到挂载的完整接力当你向 Nova 发出一条挂载卷请求时Nova 会先检查卷的状态是否available然后调用 Cinder 的 API 来建立 attachment。Cinder 侧会做这么几件事建立卷和 Nova 实例的关联关系记录attached_mode和instance_uuid根据卷的后端类型决定连接协议常见的有 iSCSI、NVMe-oF、光纤通道、RBD 等调用存储后端把卷映射到具体的计算节点返回一份连接信息其中包含存储设备的 IP、端口、IQN、认证信息等。Nova-compute 拿到这份连接信息后会在宿主机上执行类似iscsiadm的登录操作让宿主机内核识别到新的块设备然后才会以/dev/vdb或/dev/sdb之类的设备名出现在虚拟机里。这里有一个关键点不同存储协议对 Nova 侧的配置要求完全不同。如果是 RBD 这类共享存储可能根本不需要在宿主机上添加连接直接由 qemu 访问远程存储如果是 iSCSI就需要确保计算节点安装了open-iscsi而且存储网络是通的。用一个表来梳理比较直观存储协议nova-compute 需要什么常见问题iSCSIopen-iscsi 客户端、存储网络可达主机重启后 iscsi session 未重建卷不可见NVMe-oFnvme-cli、硬件/驱动支持多路径配置不一致光纤通道FC HBA 卡、多路径软件zone 未配置导致卷无法发现RBD/Cephceph-common、cephx 认证文件nova-compute 与 Ceph 集群网络隔离5.2 挂载卷之后的状态变更Cinder 的卷生命周期有三类核心状态available、in-use、reserved。当 Nova 建立 attachment 后卷会先变为reserved再进入in-use。如果你在操作过程中卷长时间卡在reserved一般是 API 调用出了问题比如 Neutron 侧网元挂了或者 Cinder 调度失败。反向操作卸载卷时也容易踩坑。Nova 会先通知虚拟机完成设备的安全卸载再让宿主机删除连接。如果虚拟机里有进程还在使用这个磁盘卸载很可能报volume is busy最终 Cinder 侧卷会变成error_detaching。这种情况下千万别在 Neutron 或者 Nova 里强行继续 detach正确的思路是先在虚拟机的操作系统里把文件系统 unmont然后再执行 detach。5.3 连接数爆炸和超时问题Cinder 后端如果是一套统一的商业存储要特别小心连接数上限的坑。每个卷挂到计算节点都会建立一个存储连接机器规模一大、卷数量一多存储上 session 数可能会激增表现就是 Nova 挂载卷时超时Cinder 日志里显示连接被拒绝。这时候不是 Nova 或 Cinder 的软件 bug而是存储容量和连接数规划出了问题。我的建议是做容量规划时除了看总容量还要估算最大并发挂载数有条件的用 RBD 这类的共享协议避免每个卷都占独立连接。另外Cinder 的os_volume_connector概念很关键它记录了计算节点获取卷连接信息的能力如果这台机器没有在 Cinder 里登记正确的 host 信息卷就可能一直挂不上。6. 串一遍完整流程从 API 请求到实例真正 ACTIVE 的每个阶段前几章把每个组件拆开了这一章把整个流程串起来看一次。这也是标题里基本流程 sequence想表达的核心Nova 的创建实例动作是一次跨组件的接力赛理解了这个顺序你才能在故障时快速判断现在跑到哪一步了该看哪个服务的日志。6.1 以一次openstack server create为例的时序拆解假设我们在终端执行openstack server create --flavor m1.small --image ubuntu-22.04 \ --network public-net --key-name mykey my-instance背后的主要步骤大致如下客户端向 Keystone 发送认证请求拿到有效 token。带着 token 向 Nova API 发送创建实例请求。Nova API 校验 token、权限、参数并生成一个实例记录此时状态为BUILD同时下发消息给 nova-conductor。nova-conductor 通过消息队列把请求转给 nova-scheduler。nova-scheduler 结合 Flavor、镜像、网络等条件调用 Placement 服务确定哪个计算节点满足资源需求选出目标主机。nova-conductor 把任务交给目标计算节点上的 nova-compute。nova-compute 开始准备虚拟机的根磁盘先向 Glance 请求镜像下载到本地并完成格式处理。nova-compute 向 Neutron 请求创建/获得 pre-created port并触发计算节点上的 neutron agent 完成 VIF 绑定。如果有 Cinder 卷nova-compute 再向 Cinder 建立 attachment把块设备挂载到宿主机。nova-compute 调用 hypervisor例如 libvirt创建虚拟机域把 root disk、vNIC 以及卷设备组装进去。虚拟机启动状态变为ACTIVE。在实际日志中可以在 nova-api、nova-conductor、nova-scheduler、nova-compute 四个进程日志里看到这个完整链路。对运维人员来说最有价值的一个习惯是记住 request 在哪个服务里流转在 neo 层面调 API 卡住了先查 nova-api 日志实例一直 BUILD再按步骤去检查 nova-scheduler 应该 Pick 没 Picknova-compute 在下载镜像还是构建网络。6.2 Nova、Neutron、Cinder 之间的先后依赖这里面最容易混乱的是端口和卷的先后顺序。Nova 的策略是先创建 port 并绑定网络再去挂载卷然后启动虚拟机。也就是说Neutron 的 VIF 准备一般发生在 Cinder 挂卷之前。这样做的好处是如果网络绑定失败就不必再去创建存储连接浪费 Cinder 的资源。也有例外。如果你在创建实例时指定的镜像本来就存放在 Cinder 卷上比如启动方式为--boot-from-volume那么 Nova 会先让 Cinder 完成卷创建从镜像灌数据的流程然后再进入端口绑定和实例启动阶段。这个场景下 Glance 的角色变成给 Cinder 提供镜像数据源而不是直接给 Nova 提供文件。6.3 如何快速定位流程堵在哪一步排查跨组件流程时最忌讳大海捞针。我习惯按下面这个思路来压迫式排查实例卡在BUILD且状态为中先看nova-api日志确认请求是否已经进入调度再看nova-scheduler日志确认是否选出了目标主机如果选出了主机立即去对应计算节点看nova-compute日志在 nova-compute 日志里检索ImageDownload、VIF plugging、Volume attach这几个关键词能很快定位是卡在 Glance、Neutron还是 Cinder 环节。如果组件的 API 请求耗时异常可以同时打开对应组件日志例如 Neutron 的neutron-server、Cinder 的cinder-api。很多跨组件超时问题其实是单向网络延迟导致服务间互相等待这时用curl直接测 API 响应时间反而最简单。7. 这些互通环节在生产环境最容易出问题我的排查清单讲完协作流程最后分享几个我实际运维中反复遇到的问题和解决思路。这些坑并不高端但每一个都可能在关键时刻让你加班到半夜。7.1 服务目录里的 endpoint 地址写错多 Region 部署或网络改版后最容易出现的就是 Keystone 服务目录里的 internal URL 还指向旧 IP。Nova 去调用 Neutron 时走了错误地址日志里表现为Connection refused但端口和网络本身都正常。经验做法是每次网络规划变更后第一时间执行openstack endpoint list确认所有组件的 public、internal URL 都可达。7.2 计算节点上没有装对应存储客户端Cinder 卷挂载失败的案例里有一半以上是计算节点缺少open-iscsi、nvme-cli等客户端包。Nova 即使调通了 Cinder API最终还要靠宿主机内核识别设备。建议在批量部署计算节点时就把存储相关的客户端、多路径软件、认证文件全部预装好。7.3 大镜像和低网络带宽组合成的创建慢Nova 的创建流程对网络非常敏感。如果你有 20GB 的镜像而计算节点和控制节点之间只有千兆网络首次创建必然非常慢。经验做法是提前做好镜像缓存或者把 Glance 的存储服务搬到与计算节点同一套分布式存储内让镜像下载走内部高速网络。7.4 并发创建时消息队列阻塞大批量创建实例的瞬间Nova 各服务进程会往消息队列写大量消息如果 RabbitMQ 或类似消息队列配置不高就会出现服务间通信超时。当时的现象非常像一个模块 bugnova-scheduler 明明选好了节点nova-compute 却迟迟收不到任务。处理办法是启用限流、提高消息队列的并发能力同时控制批量创建的速率。7.5 跨组件 request_id 不做透传排查全靠猜OpenStack 组件之间相互调用时其实是有一定关联追踪能力的。Nova 在调用 Neutron、Cinder 时可以携带自身的 request id 或者使用同样的 trace context。生产环境里如果每个组件的日志日期对不上、时间戳有偏差排查分布式问题时你就只能靠猜。建议部署时就把统一的日志采集和时间同步做好NTP 在这套系统里不是可有可无而是必需品。# 时间同步检查 chronyc tracking # 计算节点与控制节点时间差 timedatectl show -p TimeUSec时间不同步会导致 token 过期判断错乱、服务间调用超时判断不准是一个非常隐蔽但严重的问题。我把这些经验写出来是想强调一件事Nova 从来不是一个孤立运行的计算服务它和 Keystone、Glance、Neutron、Cinder 之间的协作机制才是 OpenStack 的核心难点也是排查一切莫名其妙问题的钥匙。每当你怀疑 Nova 出了 bug 时先顺着调用链去看看它当时正在和哪个外部组件打交道说不定答案就在那里。