基础概念

什么是 OpenStack？

答：OpenStack 是一个开源的云计算平台，提供基础设施即服务（IaaS）。它通过多个组件协同工作，提供计算、存储、网络等核心云服务，支持自动化部署和管理虚拟化资源。OpenStack 采用分布式架构，通过 RESTful API 提供所有服务能力。

OpenStack 的核心组件有哪些？

答：OpenStack 主要包含以下核心组件：

组件	服务名称	功能
Nova	计算服务	管理虚拟机的生命周期（创建、启停、删除）
Neutron	网络服务	提供虚拟网络、子网、路由、浮动IP等功能
Cinder	块存储服务	为虚拟机提供持久化块存储卷
Glance	镜像服务	存储和管理虚拟机镜像
Keystone	认证服务	统一身份认证、授权和服务目录管理
Swift	对象存储服务	大规模分布式对象存储（非结构化数据）
Horizon	控制面板	基于 Web 的图形化管理界面
Heat	编排服务	模板化基础设施自动化部署
Ceilometer	计量服务	资源使用数据收集和计费
Ironic	裸金属服务	裸金属服务器管理

OpenStack 与 Kubernetes 的区别是什么？

特性	OpenStack	Kubernetes
定位	IaaS 基础设施即服务	PaaS 容器编排平台
抽象级别	虚拟化硬件资源（CPU、内存、网络、存储）	容器化应用编排
核心功能	虚拟机管理、SDN 网络、块/对象存储	容器部署、自动伸缩、服务发现
部署复杂度	较高，组件多，依赖关系复杂	相对较低
适用场景	私有云/公有云基础设施、传统应用上云	微服务、云原生应用、DevOps
隔离级别	硬件级虚拟化（KVM）隔离更强	进程级隔离，共享内核

企业面试高频追问：很多企业实际会同时使用 OpenStack 和 K8s，OpenStack 提供底层 IaaS 资源，K8s 运行在上层的虚拟机或裸金属上。例如用 Magnum 项目在 OpenStack 上直接创建 K8s 集群，或用 Kuryr 实现 Neutron 与 K8s 网络打通。

OpenStack 的整体架构是怎样的？

答：OpenStack 采用分布式微服务架构：

控制节点：运行 Keystone、Nova-API、Neutron-Server、Glance-API、Cinder-API、Horizon 等管理服务，以及数据库（MySQL/ MariaDB Galera）、消息队列（RabbitMQ）
计算节点：运行 Nova-Compute、Neutron-Agent（OVS/Linux Bridge），承载虚拟机实例
存储节点：运行 Cinder-Volume、Swift-Proxy/Object，提供块存储和对象存储

组件之间通过消息队列（RabbitMQ）通信，状态数据持久化到数据库（MySQL）。所有组件通过 Keystone 进行认证和授权。

企业面试高频题

以下题目来自一线互联网企业和传统企业的真实 OpenStack 面试记录，重点考察实战经验。

你们公司 OpenStack 的规模有多大？架构是怎么规划的？

答：这是面试中最常见的开场题，考察真实项目经验。建议从以下几个维度回答：

规模维度：

计算节点数：如 50 台 / 200 台 / 500 台+
虚拟机总量：如 2000+ / 10000+ 台
存储规模：如 Ceph 集群 200TB+ / 500TB+
租户数：如 20+ 部门 / 100+ 项目

架构规划：

控制节点：3 节点 HA 集群（Pacemaker + HAProxy + Galera + RabbitMQ 镜像队列）
计算节点：按业务类型分集群（普通计算集群、GPU 集群、高内存集群）
存储：Ceph 统一存储（三副本），SSD 做缓存层
网络：Spine-Leaf 架构，VXLAN overlay 网络，DVR（分布式虚拟路由）

回答技巧：没有实际经验可以说"我们参考了 xx 企业的架构设计，我了解的最佳实践是……"

生产环境中 OpenStack 版本怎么选？升级方案怎么设计？

答：版本选择原则：

企业稳定优先：选择 LTS 类版本或社区维护期长的版本（如 Wallaby、Yoga、Antelope）
避开大版本前两个小版本：如 X 版本刚发布时 Bug 较多，建议等 X.1 或 X.2
关注组件兼容性矩阵：升级前一定要确认所有组件版本兼容

升级方案：

滚动升级：逐台升级控制节点服务，先升级非关键服务（Keystone、Glance），再升级核心服务（Nova、Neutron）
N-1 升级原则：最多跳过一个版本升级，如从 Yoga 到 Bobcat 而非直接从 Yoga 到 Caracal
回滚预案：升级前对数据库和配置文件做全量备份，保留旧版本 RPM/容器镜像
数据面验证：每升级完一个组件都要验证核心功能（创建VM、挂载卷、网络连通）

真实案例：某金融企业从 Queens 升级到 Wallaby，耗时 3 个月，先搭建新版本环境做兼容性测试，确认业务无影响后再在线迁移。

虚拟机创建失败怎么排查？（企业最爱问）

答：这是 OpenStack 运维面试的必考题，考察排错思路。按照以下链路逐层排查：

1. API 层

检查 nova-api 日志：/var/log/nova/nova-api.log
确认 Keystone Token 有效：openstack token issue
检查配额是否超限：openstack quota show <project>

2. 调度层

检查 nova-scheduler 日志：是否有 NoValidHost 报错
确认计算节点资源充足：openstack hypervisor stats show
检查 Filter 是否过于严格（如 RAMFilter、DiskFilter）

3. 计算层

检查 nova-compute 日志：/var/log/nova/nova-compute.log
确认 Hypervisor（KVM）正常：virsh list --all
检查磁盘空间：df -h，确认 /var/lib/nova/instances 有足够空间
检查镜像下载状态：Glance 是否能正常提供镜像

4. 网络层

检查 Neutron 端口创建状态：openstack port list --server <vm_id>
确认 DHCP 正常分配 IP
检查安全组规则是否阻止了必要流量

5. 存储层

检查 Cinder 卷创建状态：openstack volume list
确认 Ceph 集群健康：ceph -s，检查是否 HEALTH_OK
确认后端存储配额充足

排错口诀：先看日志、再看资源、后看网络、最后看存储。

百万并发下 Neutron 网络性能瓶颈怎么解决？

答：大规模 OpenStack 集群中，Neutron 通常是最大瓶颈。常用优化手段：

1. DVR（分布式虚拟路由）

传统模式：所有流量经过网络节点，单点瓶颈
DVR 模式：每个计算节点本地处理路由和 Floating IP，消除网络节点瓶颈

2. OVS 流表优化

使用 OVS-DPDK：用户态转发，绕过内核协议栈，性能提升 2-5 倍
合并流表规则：减少流表条目数，避免 OVS 流表膨胀
开启 OVS 硬件卸载（把流表卸载到网卡，需要支持 SR-IOV 的网卡）

3. SR-IOV 直通

将物理网卡直接分配给虚拟机，绕过虚拟交换机层
性能接近物理机，适合高吞吐场景（NFV、大数据）
代价：丧失热迁移能力

4. 控制面优化

Neutron-Server 多 worker 进程配置：workers=24
消息队列（RabbitMQ）性能调优：Erlang 虚拟机内存优化、连接池调大
数据库慢查询优化：Neutron 数据库定期 VACUUM 和 ANALYZE

OpenStack + Ceph 集成有哪些坑？（企业高频题）

答：OpenStack 和 Ceph 是黄金搭档，但集成中有很多实际坑点：

常见问题：

Ceph 认证配置错误
- 坑：ceph.conf 中 auth_cluster_required、auth_service_required 配置不一致
- 解决：确保 OpenStack 节点的 ceph.conf 和服务端的配置一致
Ceph 池（Pool）命名不一致
- 坑：Glance 用 images 池，Cinder 用 volumes 池，Nova 用 vms 池，容易搞混
- 规范做法：统一命名规范，在 cinder.conf、glance-api.conf、nova.conf 中明确指定
RBD 内核模块版本不兼容
- 坑：rbd map 报错，内核 RBD 模块与 Ceph 版本不匹配
- 解决：保持内核版本 >= 4.15，Ceph 客户端和服务端版本一致
Cinder 备份和快照性能
- 坑：大量快照导致 Ceph 性能下降，rbd diff 扫描耗时很长
- 解决：控制快照数量，定期清理过期快照，使用 Ceph 的 trash 功能管理删除
存储 RBD 锁冲突
- 坑：两个计算节点同时挂载同一个 volume，导致文件系统损坏
- 解决：正确配置 Cinder 的锁机制，使用 rbd lock 和 cinder volume attach 的排他性

真实案例：某电商企业遇到 rbd map 报错 RBD image is still being used，原因是 Nova 没有正确清理挂载，最后通过 rbd lock list 找到并手动释放锁。

控制节点挂了怎么办？高可用如何实现？

答：这是面试中考察架构设计能力的高频题。

高可用架构设计：

组件	高可用方案	节点数
Keystone	HAProxy + Keepalived，多实例	≥2
Nova-API	HAProxy 负载均衡	≥2
Neutron-Server	HAProxy + 主备模式	≥2
MySQL	Galera 多主集群	≥3（奇数）
RabbitMQ	镜像队列集群	≥3
Cinder-API	HAProxy 负载均衡	≥2
Horizon	HAProxy + 多实例	≥2

控制节点故障恢复流程：

单节点故障：HAProxy 自动摘除故障节点，其他节点继续服务
数据库故障：Galera 自动选举，剩余节点继续服务
消息队列故障：镜像队列从备节点接管
全网故障：使用 Pacemaker + Corosync 做资源管理，VIP 自动漂移

面试追问：如果所有控制节点都挂了怎么办？答：建立灾备环境，数据库做异步复制到灾备站点，使用 DNS/GSLB 做站点级切换。

为什么不直接用 VMware 而选择 OpenStack？

答：这是面试中非常容易考到的选型题。

对比维度	OpenStack	VMware vSphere
开源/成本	开源免费，只需硬件和人力成本	商业授权，按 CPU 插槽计费，成本高昂
开放性	API 完全开放，支持二次开发	API 开放但存在厂商锁定
组件灵活性	可自由选择存储/网络后端	集成在 VMware 生态中
门槛	部署运维复杂度高，需专业团队	相对简单，文档成熟
生态集成	与 K8s、Ceph、Prometheus 等开源生态无缝集成	有自家的 Tanzu、NSX、vSAN 生态
支持服务	社区支持 + 商业支持（Red Hat、Mirantis）	商业支持完善，响应快

企业真实选择场景：

选 OpenStack：大规模（200+节点）、成本敏感、需要深度定制、开源生态集成
选 VMware：中小规模、运维团队能力有限、已有 VMware 生态依赖、业务对稳定性要求极高
混合方案：部分企业同时使用，核心业务在 VMware，非核心业务和开发测试环境用 OpenStack

Keystone（认证服务）

Keystone 的核心功能是什么？

答：Keystone 是 OpenStack 的统一身份认证服务，核心功能包括：

身份认证：验证用户和服务的身份
授权管理：通过 Role 控制用户对资源的访问权限
令牌管理：签发和管理访问 Token
服务目录：维护所有 OpenStack 服务的端点（Endpoint）注册信息
联邦认证：支持 LDAP、SAML、OIDC 等外部认证源集成

Keystone 的 Domain、Project、User、Role 是什么？

答：

Domain（域）：最顶层隔离单元，代表组织或租户群体，可以包含多个 Project 和 User
Project（项目）：资源隔离单位，用于组织和管理计算、存储、网络等资源（旧版本称为 Tenant）
User（用户）：可以使用 OpenStack 服务的实体，用户属于某个 Domain
Role（角色）：权限集合，定义用户对资源的操作权限（如 admin、member、reader）
Group（组）：用户组，简化权限管理，一个组可以关联多个 Role

Token 的类型和工作原理

答：Keystone 支持以下几种 Token 类型：

Token 类型	特点	使用场景
UUID Token	固定长度 32 字节，需在 Keystone 服务端验证	简单场景，不推荐生产使用
PKI Token	包含签名信息，可本地验证，但体积大（可达 KB 级别）	旧版本使用，已淘汰
Fernet Token	无需持久化存储，对称加密，体积小，是目前推荐类型	企业生产环境标准配置

Fernet Token 工作原理：

Keystone 使用一组对称密钥加密 Token 信息
Token 中携带用户身份、项目、角色、过期时间等
接收方用相同的密钥解密验证，无需查询数据库
密钥需要定期轮换（keystone-manage fernet_rotate）

Keystone 如何与 LDAP/AD 集成？

答：企业环境中 OpenStack 通常集成公司已有的 AD/LDAP 实现统一认证。

配置要点：

ini

[identity]
driver = ldap

[ldap]
url = ldap://ad.example.com
user = cn=admin,dc=example,dc=com
password = xxxxx
suffix = dc=example,dc=com
user_tree_dn = ou=Users,dc=example,dc=com
user_objectclass = person
user_id_attribute = sAMAccountName
user_name_attribute = sAMAccountName
user_mail_attribute = mail
user_enabled_attribute = userAccountControl
user_enabled_mask = 2

面试重点：LDAP 集成后，OpenStack 中的用户和组由 AD 管理，Role 仍在 Keystone 中管理。常见的坑是 AD 用户被禁用后 OpenStack 侧仍能使用 Token，需要配置 Token 过期时间。

Nova（计算服务）

Nova 的主要功能和核心组件

答：Nova 负责管理虚拟机实例的完整生命周期：创建、启动、停止、重启、删除、快照、迁移等。

核心组件：

nova-api：提供 RESTful API 接口
nova-scheduler：调度器，决策虚拟机落在哪个计算节点
nova-compute：运行在计算节点上，管理 Hypervisor（KVM/Xen）创建和管理虚拟机
nova-conductor：代理 nova-compute 对数据库的访问，提升安全性
nova-consoleauth：控制台代理认证
nova-novncproxy：提供 VNC/SPICE 远程控制台访问
nova-placement：资源追踪服务，管理计算节点的资源使用情况

Nova-Scheduler 的调度策略和工作原理

答：Nova-Scheduler 采用 两步过滤法：

第一步：Filter（过滤）——排除不符合条件的节点

RetryFilter：过滤已经尝试过的节点（防重试）
AvailabilityZoneFilter：按可用区过滤
ComputeCapabilitiesFilter：按计算能力过滤
ImagePropertiesFilter：按镜像属性过滤（如架构要求）
ServerGroupAntiAffinityFilter：反亲和性，避免相同组 VM 在同一节点
NumInstancesFilter：节点 VM 数量上限
AggregateInstanceExtraSpecsFilter：主机聚合标签过滤

第二步：Weight（加权）——在候选节点中打分选最优

RAMWeigher：按剩余内存排序
CPUWeigher：按 CPU 负载排序
DiskWeigher：按磁盘剩余空间排序
权重可自由配置，企业通常使用自定义权重

企业优化：大规模集群中，建议将 scheduler_max_attempts 调大，避免调度失败；同时开启 scheduler_host_subset_size 减少候选节点数，提高调度性能。

虚拟机启动完整流程（面试高频）

答：这是企业面试中考察是否真正理解 OpenStack 内部机制的关键题。

用户请求 → nova-api → nova-scheduler → nova-compute → 创建 VM

详细流程如下：

用户发起请求：通过 CLI、Horizon 或 API 发起创建虚拟机请求
nova-api 接收：验证 Token 和请求参数，写入数据库创建 instance 记录（状态为 BUILD）
消息队列分发：nova-api 通过 RabbitMQ 发送 build_and_run_instance RPC 请求
nova-scheduler 调度：监听队列，读取 instance 信息，执行 Filter + Weight 算法，选择目标计算节点
更新调度结果：调度器更新数据库中的主机分配信息
通知 nova-compute：通过消息队列将任务分发到选定的计算节点
准备镜像：nova-compute 调用 Glance API 获取镜像，下载到本地缓存目录
创建虚拟网络：调用 Neutron API 创建 port，分配 IP，配置安全组
准备存储：调用 Cinder API 创建或挂载存储卷（如果有）
生成 XML 定义：nova-compute 生成 libvirt domain XML，包含 CPU、内存、磁盘、网络配置
启动虚拟机：调用 virsh define + virsh start 启动虚拟机
上报状态：更新数据库中的 instance 状态为 ACTIVE

企业追问：如果第 5 步调度失败（NoValidHost），请说明可能的原因和排查方法（见上方面试题）。

大规模集群调度优化

答：当计算节点超过 200+ 时，默认调度器性能会显著下降。企业常用优化手段：

1. Cell 架构（Nova Cells）

将集群划分为多个 Cell，每个 Cell 有独立的数据库和消息队列
API 节点在 Cell 间路由请求，提高可扩展性
适合 500+ 计算节点的大规模场景

2. 调度缓存

开启 scheduler_discovery_override，缓存调度结果
配置 scheduler_max_attempts 降低失败重试带来的开销

3. 主机聚合（Host Aggregate）

按硬件特征分组（如 GPU 集群、高内存集群、SSD 集群）
用户通过 flavor 的 extra_specs 选择目标集群

热迁移和冷迁移的区别

答：

特性	热迁移（Live Migration）	冷迁移（Cold Migration）
业务中断	几乎零中断	需要停机
数据同步	内存数据持续同步	-
前置条件	共享存储（NFS/Ceph）或支持块迁移	无特殊要求
对网络要求	高，需要足够带宽	低
适用场景	硬件维护、负载均衡	计划性迁移
风险	较高，内存脏页多可能迁移失败	低

企业实践：

热迁移前务必检查：虚拟机是否有 CPU pinning、是否有 SR-IOV 直通设备、是否挂载了本地磁盘
大内存 VM（128GB+）的热迁移建议在业务低峰期进行
使用 nova migration-list 监控迁移进度

Neutron（网络服务）

Neutron 的核心功能

答：Neutron 提供 OpenStack 的网络虚拟化能力，主要功能：

虚拟网络管理：Provider Network 和 Self-service (Tenant) Network
子网管理：IP 地址分配和管理
路由服务：虚拟路由器，提供跨网段通信和 Floating IP（NAT）
安全组：有状态防火墙，基于 5 元组控制流量
负载均衡（LBaaS）：为租户提供负载均衡服务（已转移到 Octavia）
VPN 服务：站点到站点 VPN 连接
端口管理：管理虚拟端口及其 Mac/IP 绑定关系

Neutron 核心组件架构

答：

neutron-server：提供 RESTful API 接口，接受并路由请求
ML2 Plugin：模块化二层插件框架，统一管理多种网络后端
- Type Drivers：定义网络类型（VLAN、VXLAN、GRE、Flat）
- Mechanism Drivers：对接具体交换机方案（OVS、Linux Bridge、OVN）
neutron-l3-agent：三层路由代理，管理虚拟路由器和 Floating IP（非 DVR 模式时在网络节点运行）
neutron-dhcp-agent：DHCP 代理，为租户网络提供 DHCP 服务
neutron-metadata-agent：为虚拟机提供元数据服务（cloud-init 依赖）
neutron-ovs-agent：在计算节点上运行，管理 OVS 网桥和流表

面试知识点：新版本中 OVN（Open Virtual Network）正在取代传统的 ML2/OVS 架构，成为 Neutron 推荐的核心网络方案。

企业网络生产问题：虚拟机无法获取 IP

答：这是 Neutron 排错的高频场景。

排查步骤：

确认 DHCP 服务正常

bash

# 检查 DHCP Agent 状态
openstack network agent list

# 查看 DHCP 命名空间
ip netns list
ip netns exec qdhcp-<net_id> ip a

检查端口状态

bash

openstack port list --server <vm_id>
openstack port show <port_id>

检查 binding:vif_type 和 status 是否为 ACTIVE

确认安全组没有屏蔽 DHCP
- 检查安全组中是否放行了 UDP 67/68 端口

检查网络节点的 DHCP 日志

bash

tail -100 /var/log/neutron/dhcp-agent.log

验证 DHCP 地址池
bash
```
openstack subnet show <subnet_id>
```
确认地址池未耗尽，allocation_pools 中还有可用 IP

真实案例：某企业扩容后新创建虚拟机全拿不到 IP，排查发现 dhcp-agent 配置中 dhcp_lease_time=86400 + 虚拟机数量超过了 DHCP 地址池容量，调整后恢复。

Provider Network 和 Self-service Network 的区别

答：

特性	Provider Network	Self-service Network
创建者	OpenStack 管理员	普通租户用户
网络类型	Flat / VLAN	VXLAN / GRE（隧道封装）
IP 分配	物理网络 DHCP	Neutron DHCP 分配
三层路由	物理网络路由器	Neutron L3 Router（VRRP）
性能	高（无封装开销）	较低（VXLAN 封装损耗约 5-10%）
隔离方式	VLAN ID（4096 限制）	VNI（1600 万+，几乎无限）
跨宿主机	依赖物理网络配置	VXLAN 隧道自动打通

企业选型建议：生产环境通常混合使用——管理 API 使用 Provider Network，租户业务网络使用 Self-service Network（VXLAN），兼顾性能和灵活性。

ML2 插件和 OVN 是什么？

答：

ML2（Modular Layer 2）：Neutron 的模块化二层框架，支持在同一部署中运行多种网络技术。它包括：

Type Drivers：flat、vlan、vxlan、gre、geneve
Mechanism Drivers：openvswitch、linuxbridge、ovn、l2population

OVN（Open Virtual Network）：当前 OpenStack 推荐的下一代网络方案，由 OVS 团队开发：

提供原生 L2/L3 虚拟网络，取代传统 neutron-*-agent 的复杂架构
使用 OVN-Northbound/Southbound DB 模型，状态集中管理
支持分布式网关（DVR）、ACL、负载均衡等原生能力
性能更好，排错更简单

企业迁移趋势：新部署的 OpenStack（Wallaby+）强烈建议直接使用 OVN，存量的 ML2/OVS 架构也建议逐步迁移到 OVN。

Floating IP 的实现原理和 SNAT/DNAT 链路

答：Floating IP 本质是通过 iptables NAT 规则实现的 1:1 映射。

DNAT（外网访问虚拟机）：

用户 → Floating IP → 物理路由器 → 网络节点/计算节点
    → iptables PREROUTING DNAT → 转换为虚拟机 Fixed IP
    → Neutron 路由命名空间 → 虚拟机

SNAT（虚拟机访问外网）：

虚拟机 → iptables POSTROUTING SNAT → 转换为 Floating IP
    → 物理路由器 → 互联网

排查链路：

bash

# 查看路由命名空间
ip netns exec qrouter-<router_id> iptables -t nat -L -n -v

# 查看 Floating IP 绑定
openstack floating ip list
openstack floating ip show <fip_id>

# 测试连通性
ip netns exec qrouter-<router_id> ping <vm_ip>

Cinder（块存储服务）

Cinder 核心功能和组件

答：Cinder 为虚拟机提供持久化块存储，核心功能包括：

创建、删除、扩展存储卷
存储卷快照和备份
存储卷类型管理（不同性能层）
多存储后端支持

核心组件：

cinder-api：RESTful API 接口
cinder-scheduler：调度器，选择存储后端
cinder-volume：在存储节点上管理实际存储
cinder-backup：提供卷备份到对象存储
cinder-manage：管理工具

企业存储后端选型对比

答：企业生产环境需要根据业务场景选择合适的存储后端：

存储后端	性能	成本	运维复杂度	推荐场景
LVM	高（本地磁盘）	低	低	测试环境、单机场景
Ceph RBD	中（网络延迟）	中	高	企业私有云标准选择
NFS	低	中	中	小规模场景、非关键业务
商业存储（EMC/NetApp）	高	极高	中	金融、医疗等核心业务
分布式存储（MinIO）	中	低	中	对象存储场景

企业趋势：Ceph + OpenStack 已成为私有云事实标准。三副本配置下有效容量为原始容量的 1/3，规划时要考虑。

Cinder 后端多路径和性能调优

答：当 Cinder 后端使用 Ceph RBD 时，企业级调优点包括：

ini

# cinder.conf Ceph 后端调优
[rbd]
rbd_pool = volumes
rbd_user = cinder
rbd_secret_uuid = xxxxx
rbd_flatten_volume_from_snapshot = false
rbd_max_clone_depth = 5
rbd_store_chunk_size = 4
rados_connect_timeout = -1
rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_keyring_conf = /etc/ceph/ceph.client.cinder.keyring

# 性能相关
rbd_qemu_cache_options = writeback:directsync
volume_dd_blocksize = 64M

多路径（Multi-path）：

当存储节点和 Ceph 集群之间有多个网络路径时，配置多路径 IO
安装 device-mapper-multipath，配置 multipath.conf
显著提升存储吞吐量和可靠性

Glance（镜像服务）

Glance 功能和镜像格式

答：Glance 管理和存储虚拟机镜像，核心功能包括：

镜像上传、下载、删除
镜像格式转换
镜像元数据管理（操作系统类型、内核版本、架构）
镜像快照（从实例创建镜像）
多存储后端支持

支持格式：RAW、QCOW2（推荐，支持写时复制和快照）、VHD、VMDK、VDI、ISO

企业镜像管理和优化

答：企业级镜像管理中遇到的问题和解决方案：

问题	解决方案
镜像体积过大导致创建慢	使用 QCOW2 压缩格式，清理系统缓存和日志，最小化镜像
镜像安全漏洞	定期扫描镜像（Trivy/Clair），设置镜像有效期，过期自动清理
镜像分发效率低	启用 Glance 缓存，在多 Region 间使用镜像同步
Windows 镜像激活	使用 KMS 激活，预配置 sysprep
镜像类型繁多	分类管理（OS 镜像、应用镜像、安全基线镜像），按项目隔离

企业镜像瘦身实践：

bash

# 使用 virt-sysprep 清理镜像
virt-sysprep -a centos7.qcow2

# 转换为瘦格式
qemu-img convert -O qcow2 -c fat.qcow2 thin.qcow2

# 上传到 Glance
openstack image create --file thin.qcow2 --disk-format qcow2 \
  --container-format bare --property os_type=linux CentOS-7.9

Swift（对象存储服务）

Swift 核心功能和组件

答：Swift 提供大规模可扩展的分布式对象存储，适合非结构化数据存储（备份文件、日志、静态资源等）。

核心组件：

Proxy Server：处理用户请求，定位数据位置
Account Server：账户元数据管理
Container Server：容器（目录）元数据管理
Object Server：实际对象数据的存储
Ring：一致性哈希环，决定数据在集群中的分布位置
Replicator：数据复制，保证副本数
Auditor：数据完整性校验和修复

Swift 和 Ceph RGW 对比

答：企业选型中常见的选择问题：

特性	Swift	Ceph RGW
架构	原生 OpenStack 组件	Ceph 子组件，通过 RGW 提供 S3/Swift 兼容
API 兼容	Swift API	S3 + Swift API 双兼容
一致性	最终一致性	强一致性
性能	小文件有优势	大文件有优势
运维复杂度	中等	较高（依赖 Ceph 集群）
与 OpenStack 集成	原生集成	通过 Cinder/Glance 后端集成
推荐场景	中小规模、纯 OpenStack 环境	大规模、同时需要块存储和对象存储

架构设计与部署实战

企业级 OpenStack 部署方案对比

部署方案	优点	缺点	适用场景
手动部署	完全可控，深度定制	部署慢，出错率高	学习环境、特殊定制场景
Kolla-ansible	容器化部署，易于维护，支持滚动升级	学习成本较高	企业生产推荐方案
TripleO	使用 OpenStack 部署 OpenStack	复杂度高	Red Hat 生态
OpenStack-helm	基于 Kubernetes 部署，云原生	需要 K8s 环境	已有 K8s 基础设施
DevStack	快速部署，开发调试方便	不适合生产	开发测试环境

企业趋势：Kolla-ansible 已成为生产环境的主流选择，所有组件容器化运行，方便版本管理和升级。

多 Region 和多 AZ 架构设计

答：企业在大规模部署时需要规划多 Region 和多 AZ。

Region（区域）：

完全独立的 OpenStack 部署，共享 Keystone（或独立 Keystone）
物理上通常对应不同数据中心
场景：两地三中心灾备、多机房资源统一管理

Availability Zone（可用区）：

同一 Region 内的逻辑分区，共享同一控制面
物理上对应不同机架、不同网络设备
场景：同一数据中心内故障隔离、硬件差异化（如 GPU AZ、普通计算 AZ）

配置示例：

bash

# 创建 AZ
openstack aggregate create --zone=az-gpu gpu-cluster
openstack aggregate create --zone=az-compute compute-cluster
openstack aggregate add host gpu-cluster compute01
openstack aggregate add host compute-cluster compute02

# 用户在 AZ 中创建虚拟机
openstack server create --availability-zone az-gpu --flavor gpu-flavor ...

裸金属管理（Ironic）

答：Ironic 是 OpenStack 的裸金属服务，用于管理物理服务器。

核心概念：

将物理服务器像虚拟机一样管理（PXE 部署 + IPMI 控制）
支持自动发现、部署、重启、重置物理机
与 Nova 无缝集成，可以使用 Neutron 网络

适用场景：

高性能计算（HPC）：需要直接访问物理硬件
大数据平台：避免虚拟化性能损耗
数据库集群：需要稳定的物理资源隔离
NFV（网络功能虚拟化）：需要 SR-IOV、DPDK

部署流程：

注册裸金属节点（mac 地址、IPMI 信息、硬件规格）
配置部署镜像和驱动
Ironic 通过 PXE 启动部署 agent
Agent 写入磁盘镜像到物理机
节点状态转为 ACTIVE

故障排查实战（真实企业案例）

案例 1：Nova-Compute 服务无故宕机

现象：某个计算节点上的所有虚拟机突然消失，nova-compute 服务异常

排查过程：

bash

# 1. 检查服务状态
systemctl status nova-compute
journalctl -u nova-compute --since "1 hour ago"

# 2. 查看日志中的关键错误
tail -200 /var/log/nova/nova-compute.log

# 3. 检查系统资源
free -h
dmesg -T | tail -50  # 检查是否有 OOM killer

# 4. 检查 rabbitmq 连接
rabbitmqctl list_connections

根本原因：内存不足触发 OOM Killer，Nova-Compute 进程被内核杀掉

解决方案：

增加计算节点的物理内存
在 /etc/systemd/system/nova-compute.service.d/limits.conf 中配置 OOMScoreAdjust=-500，降低被 OOM 杀死的优先级
合理分配虚拟机内存，设置 QoS 限制

案例 2：RabbitMQ 消息队列堆积导致集群瘫痪

现象：虚拟机创建超时、API 响应极慢、Horizon 页面加载失败

排查过程：

bash

# 1. 查看 RabbitMQ 状态
rabbitmqctl status
rabbitmqctl list_queues | sort -n -k 2  # 查看堆积队列

# 2. 检查哪个队列堆积
rabbitmqctl list_queues name messages consumers

# 3. 检查连接数
rabbitmqctl list_connections

# 4. 检查磁盘和内存
rabbitmqctl eval 'erlang:memory().'
df -h /var/lib/rabbitmq/

解决方案：

增加 RabbitMQ 集群节点数（生产至少 3 节点）
配置镜像队列策略：rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}'
调优 Erlang 虚拟机参数：+P 65536 +K true +A 64
如果是个别计算节点积压，检查该节点的 Nova-Compute 服务是否正常

案例 3：虚拟机磁盘 IO 高导致宿主机卡死

现象：某个计算节点负载正常但 Hypervisor 响应极慢，virsh list 超时

排查过程：

bash

# 1. 查看磁盘 IO
iostat -x 1 5
iotop -oP

# 2. 查找 IO 高的虚拟机
for vm in $(virsh list --name); do
  echo "$(virsh domstats $vm | grep balloon.current): $vm"
done

# 3. 查看 Ceph 存储状态
ceph -s
ceph osd perf

解决方案：

对 IO 密集型虚拟机启用磁盘 QoS：openstack server set --property quota:disk_read_bytes_sec=...
使用 Ceph 的 QoS 功能限制单 VM 的 IOPS：rbd config pool set volumes limit_max_mbps ...
将高 IO 虚拟机迁移到 SSD 节点或专用集群
调整 QEMU 的 IO 调度为 none 或 deadline

案例 4：租户网络完全不通

现象：同一租户下的虚拟机之间、虚拟机对外均无法通信

排查过程：

bash

# 1. 检查网络 Agent 状态
openstack network agent list

# 2. 查看路由命名空间
ip netns list
ip netns exec qrouter-<id> ip route
ip netns exec qrouter-<id> iptables -t nat -L -n

# 3. 检查 OVS 流表
ovs-vsctl show
ovs-ofctl dump-flows br-int | head -50

# 4. 从路由命名空间 ping 虚拟机
ip netns exec qrouter-<id> ping <vm_ip>

# 5. 检查 L3 Agent 日志
tail -100 /var/log/neutron/l3-agent.log

常见原因：

L3 Agent 异常导致路由器未正确创建
SNAT/DNAT 规则丢失
OVS 流表被误清空
安全组规则过于严格

案例 5：Ceph OSD 故障导致存储卷不可用

现象：虚拟机 IO 挂起、Cinder 卷挂载失败、ceph -s 状态 HEALTH_WARN

排查过程：

bash

# 1. 检查集群健康状态
ceph -s
ceph health detail

# 2. 检查 OSD 状态
ceph osd tree
ceph osd status

# 3. 查看 PG 状态
ceph pg stat
ceph pg dump_stuck inactive|unclean|undersized

# 4. 检查磁盘故障
dmesg -T | grep -i error
smartctl -a /dev/sdb

解决方案：

故障 OSD 自动 down 后，Ceph 会自动 recover（数据在其他副本重建）
如果 OSD 是磁盘故障：标记 out → 替换磁盘 → 重新加入集群
如果 OSD 是网络问题：检查网络连通性和网卡状态
调优：osd_recovery_max_active=3 控制恢复速度，避免影响业务

性能调优

计算性能调优

答：企业生产环境 Nova 计算性能优化的关键手段：

1. CPU Pinning（CPU 绑定）

bash

# 创建 flavor 时指定 CPU pinning
openstack flavor set --property hw:cpu_policy=dedicated \
  --property hw:cpu_thread_policy=isolate my-flavor

将虚拟机的 vCPU 绑定到物理 CPU 核心，避免 CPU 竞争
适用场景：数据库、高频交易等 CPU 敏感型应用

2. 巨页内存（Huge Pages）

bash

# 宿主机配置 1G 巨页
echo 1024 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages

# Nova flavor 配置
openstack flavor set --property hw:mem_page_size=large my-flavor

减少 TLB miss，提升内存访问性能
对内存密集型应用（数据库、大数据）提升明显

3. NUMA 亲和性

bash

openstack flavor set --property hw:numa_nodes=1 my-flavor
openstack flavor set --property hw:numa_mempolicy=strict my-flavor

避免跨 NUMA 节点访问内存，减少延迟
大规格 VM（16vCPU+）必须配置

4. 虚拟化类型优化

使用 KVM（硬件辅助虚拟化）而非 QEMU 纯软件虚拟化
开启 CPU 的 VMX/SVM 特性
配置 QEMU 使用 kvm 加速器

网络性能调优

答：

技术	原理	性能提升	代价
DPDK	用户态轮询，绕过内核协议栈	10G+ 线速，延迟降低 50%+	需要专用网卡，增加 CPU 占用
SR-IOV	物理网卡直通给虚拟机	近乎物理机性能	失去热迁移能力
OVS-DPDK	OVS 运行在 DPDK 上	转发性能提升 3-5 倍	配置复杂，大页内存消耗
Vhost-User	虚拟机与 OVS 共享内存	减少内存拷贝，提升吞吐	需要 DPDK 支持

企业选型建议：

普通业务：默认 OVS 即可
高吞吐场景：OVS-DPDK 或 SR-IOV
NFV/电信场景：SR-IOV + DPDK 组合

数据库和消息队列调优

答：控制节点的 MySQL 和 RabbitMQ 性能直接影响整个集群。

MySQL 优化：

ini

# my.cnf
innodb_buffer_pool_size = 64G        # 物理内存的 60-70%
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2    # 降低 commit 延迟
innodb_io_capacity = 2000             # SSD 场景可以更高
max_connections = 1000
query_cache_type = 0                  # OpenStack 不适合 query cache

RabbitMQ 优化：

ini

# rabbitmq.conf
vm_memory_high_watermark.relative = 0.6    # 内存水位线
vm_memory_high_watermark_paging_ratio = 0.5
disk_free_limit.absolute = 2GB
collect_statistics_interval = 10000

容器与 K8s 集成

OpenStack + Kubernetes 的集成方案

答：企业在云原生转型过程中，经常需要 OpenStack 和 Kubernetes 协同工作。

方案 1：Magnum（OpenStack 原生 K8s 编排）

使用 Heat 模板批量创建 K8s 集群
K8s 节点运行在 OpenStack 虚拟机上
适合需要统一管理 VM 和容器的场景

方案 2：Kuryr（网络打通）

Kuryr 将 Neutron 网络直接映射到 K8s 的 Pod 网络
Pod 直接使用 Neutron 端口和 IP，与 VM 在同一 L2 网络
适合需要 VM 和 Pod 直接互通的场景

方案 3：OpenStack on Kubernetes

使用 OpenStack-Helm 将 OpenStack 服务容器化调度到 K8s
适合已有 K8s 基础设施的企业
降低 OpenStack 运维复杂度

方案 4：VM 内容器化（双层方案）

OpenStack 提供虚拟机资源
在虚拟机上部署 K8s 集群
最传统但也最成熟的方案

Kuryr 如何实现 Neutron 与 K8s 网络互通？

答：Kuryr 是 OpenStack 与 K8s 网络集成的关键项目。

核心原理：

K8s 创建 Pod 时，Kuryr 调用 Neutron API 创建 Port
Pod 的网卡直接连接到 Neutron 的虚拟网络
Pod 获得 Neutron 分配的 IP，与普通 VM 在同一网络平面
K8s Service 通过 Neutron LBaaS（Octavia）实现

优点：

Pod 和 VM 完全二层互通
可复用 Neutron 安全组、Floating IP 等网络能力
统一网络管理

缺点：

Pod 创建速度受 Neutron API 调用影响（较慢）
依赖 OpenStack 环境

自动化和监控

OpenStack 自动化运维实践

答：企业运维 OpenStack 需要完善的自动化体系：

1. 配置管理：Ansible 管理 OpenStack 配置（Kolla-ansible 自带） 2. 扩缩容自动化：

bash

# 自动发现计算节点
openstack compute service list --service nova-compute

# 自动注册新节点
# 新节点上架 → PXE 自动部署 OS → Kolla-ansible 自动部署 nova-compute → 自动注册

3. 自动巡检脚本：

bash

#!/bin/bash
# 每日自动巡检
echo "=== OpenStack 巡检报告 $(date) ==="
openstack compute service list          # 计算服务状态
openstack network agent list            # 网络 Agent 状态
openstack volume service list           # 存储服务状态
ceph -s                                 # Ceph 健康状态
rabbitmqctl cluster_status              # 消息队列状态
mysql -e "show status like 'wsrep%'"   # 数据库集群状态

监控方案

答：企业级 OpenStack 监控方案推荐：

监控层面	工具	监控指标
基础设施	Prometheus + Node Exporter	CPU、内存、磁盘、网络
OpenStack 服务	Prometheus OpenStack Exporter	API 可用性、服务状态、队列深度
消息队列	RabbitMQ 插件 + Prometheus	队列长度、连接数、内存使用
数据库	MySQL Exporter	连接数、慢查询、主从延迟
Ceph 存储	Prometheus Ceph Exporter	OSD 状态、PG 状态、IOPS、延迟
告警	AlertManager	服务宕机、资源不足、性能下降

关键告警规则（企业必备）：

openstack_service_down — 任意 OpenStack 服务宕机
nova_compute_down_30min — 计算节点失联超过 30 分钟
neutron_dhcp_lease_high — DHCP 地址池使用率 > 90%
ceph_health_warn — Ceph 状态非 HEALTH_OK
rabbitmq_queue_growth — 消息队列积压超过阈值

面试送分题：常见的面试陷阱

陷阱 1：OpenStack 是 PaaS 还是 IaaS？

答：OpenStack 是 IaaS（基础设施即服务），提供虚拟机、网络、存储等基础设施资源。不是 PaaS。容易和 Cloud Foundry、OpenShift 等 PaaS 平台混淆。

陷阱 2：OpenStack 所有组件都必须部署吗？

答：不是。OpenStack 采用微服务架构，可以根据需求选择性部署组件。例如：

不需要对象存储 → 不部署 Swift
不需要编排功能 → 不部署 Heat
不需要计量计费 → 不部署 Ceilometer
不需要裸金属管理 → 不部署 Ironic

陷阱 3：OpenStack 的加密通信

答：默认情况下 OpenStack 组件间通信不加密（HTTP、RabbitMQ 明文）。企业生产必须启用：

所有 API Endpoint 使用 HTTPS（配置 TLS 证书）
RabbitMQ 启用 TLS
数据库连接启用 TLS
Memcache 启用 SASL 认证

陷阱 4：OpenStack 虚拟机重启策略

答：OpenStack 的安全策略不支持用户在 Horizon 或 API 中直接重启物理宿主机。重启计算节点需要先迁移 VM 或在运维窗口操作。

OpenStack 版本演进和发展趋势

OpenStack 版本命名规则

答：OpenStack 版本按字母顺序命名，每半年发布一个版本：

A~Z 命名：Austin → Bexar → Cactus → ... → Zed → 2023 年后改为年份命名
新版本命名：2023.1 Antelope、2023.2 Bobcat、2024.1 Caracal

OpenStack 发展趋势（企业关注点）

向云原生演进：OpenStack 服务容器化（Kolla、OpenStack-Helm），运行在 K8s 上
与 K8s 深度融合：Kuryr、Magnum 提供混合 VM+容器管理
边缘计算：StarlingX、OpenStack 轻量化部署适用于边缘节点
硬件加速支持：DPDK、SR-IOV、GPU、FPGA 的深度集成
安全增强：等保合规、加密通信、审计日志
AI 基础设施：GPU 虚拟化（vGPU）、训练/推理集群管理
运营简化：Day-2 运维工具成熟度提升，自动化巡检和自治愈能力增强

基础概念 ​

什么是 OpenStack？ ​

OpenStack 的核心组件有哪些？ ​

OpenStack 与 Kubernetes 的区别是什么？ ​

OpenStack 的整体架构是怎样的？ ​

企业面试高频题 ​

你们公司 OpenStack 的规模有多大？架构是怎么规划的？ ​

生产环境中 OpenStack 版本怎么选？升级方案怎么设计？ ​

虚拟机创建失败怎么排查？（企业最爱问） ​

百万并发下 Neutron 网络性能瓶颈怎么解决？ ​

OpenStack + Ceph 集成有哪些坑？（企业高频题） ​

控制节点挂了怎么办？高可用如何实现？ ​

为什么不直接用 VMware 而选择 OpenStack？ ​

Keystone（认证服务） ​

Keystone 的核心功能是什么？ ​

Keystone 的 Domain、Project、User、Role 是什么？ ​

Token 的类型和工作原理 ​

Keystone 如何与 LDAP/AD 集成？ ​

Nova（计算服务） ​

Nova 的主要功能和核心组件 ​

Nova-Scheduler 的调度策略和工作原理 ​

虚拟机启动完整流程（面试高频） ​

大规模集群调度优化 ​

热迁移和冷迁移的区别 ​

Neutron（网络服务） ​

Neutron 的核心功能 ​

Neutron 核心组件架构 ​

企业网络生产问题：虚拟机无法获取 IP ​

Provider Network 和 Self-service Network 的区别 ​

ML2 插件和 OVN 是什么？ ​

Floating IP 的实现原理和 SNAT/DNAT 链路 ​

Cinder（块存储服务） ​

Cinder 核心功能和组件 ​

企业存储后端选型对比 ​

Cinder 后端多路径和性能调优 ​

Glance（镜像服务） ​

Glance 功能和镜像格式 ​

企业镜像管理和优化 ​

Swift（对象存储服务） ​

Swift 核心功能和组件 ​

Swift 和 Ceph RGW 对比 ​

架构设计与部署实战 ​

企业级 OpenStack 部署方案对比 ​

多 Region 和多 AZ 架构设计 ​

裸金属管理（Ironic） ​

故障排查实战（真实企业案例） ​

案例 1：Nova-Compute 服务无故宕机 ​

案例 2：RabbitMQ 消息队列堆积导致集群瘫痪 ​

案例 3：虚拟机磁盘 IO 高导致宿主机卡死 ​

案例 4：租户网络完全不通 ​

案例 5：Ceph OSD 故障导致存储卷不可用 ​

性能调优 ​

计算性能调优 ​

网络性能调优 ​

数据库和消息队列调优 ​

容器与 K8s 集成 ​

OpenStack + Kubernetes 的集成方案 ​

Kuryr 如何实现 Neutron 与 K8s 网络互通？ ​

自动化和监控 ​

OpenStack 自动化运维实践 ​

监控方案 ​

面试送分题：常见的面试陷阱 ​

陷阱 1：OpenStack 是 PaaS 还是 IaaS？ ​

陷阱 2：OpenStack 所有组件都必须部署吗？ ​

陷阱 3：OpenStack 的加密通信 ​

陷阱 4：OpenStack 虚拟机重启策略 ​

OpenStack 版本演进和发展趋势 ​

OpenStack 版本命名规则 ​

OpenStack 发展趋势（企业关注点） ​

基础概念

什么是 OpenStack？

OpenStack 的核心组件有哪些？

OpenStack 与 Kubernetes 的区别是什么？

OpenStack 的整体架构是怎样的？

企业面试高频题

你们公司 OpenStack 的规模有多大？架构是怎么规划的？

生产环境中 OpenStack 版本怎么选？升级方案怎么设计？

虚拟机创建失败怎么排查？（企业最爱问）

百万并发下 Neutron 网络性能瓶颈怎么解决？

OpenStack + Ceph 集成有哪些坑？（企业高频题）

控制节点挂了怎么办？高可用如何实现？

为什么不直接用 VMware 而选择 OpenStack？

Keystone（认证服务）

Keystone 的核心功能是什么？

Keystone 的 Domain、Project、User、Role 是什么？

Token 的类型和工作原理

Keystone 如何与 LDAP/AD 集成？

Nova（计算服务）

Nova 的主要功能和核心组件

Nova-Scheduler 的调度策略和工作原理

虚拟机启动完整流程（面试高频）

大规模集群调度优化

热迁移和冷迁移的区别

Neutron（网络服务）

Neutron 的核心功能

Neutron 核心组件架构

企业网络生产问题：虚拟机无法获取 IP

Provider Network 和 Self-service Network 的区别

ML2 插件和 OVN 是什么？

Floating IP 的实现原理和 SNAT/DNAT 链路

Cinder（块存储服务）

Cinder 核心功能和组件

企业存储后端选型对比

Cinder 后端多路径和性能调优

Glance（镜像服务）

Glance 功能和镜像格式

企业镜像管理和优化

Swift（对象存储服务）

Swift 核心功能和组件

Swift 和 Ceph RGW 对比

架构设计与部署实战

企业级 OpenStack 部署方案对比

多 Region 和多 AZ 架构设计

裸金属管理（Ironic）

故障排查实战（真实企业案例）

案例 1：Nova-Compute 服务无故宕机

案例 2：RabbitMQ 消息队列堆积导致集群瘫痪

案例 3：虚拟机磁盘 IO 高导致宿主机卡死

案例 4：租户网络完全不通

案例 5：Ceph OSD 故障导致存储卷不可用

性能调优

计算性能调优

网络性能调优

数据库和消息队列调优

容器与 K8s 集成

OpenStack + Kubernetes 的集成方案

Kuryr 如何实现 Neutron 与 K8s 网络互通？

自动化和监控

OpenStack 自动化运维实践

监控方案

面试送分题：常见的面试陷阱

陷阱 1：OpenStack 是 PaaS 还是 IaaS？

陷阱 2：OpenStack 所有组件都必须部署吗？

陷阱 3：OpenStack 的加密通信

陷阱 4：OpenStack 虚拟机重启策略

OpenStack 版本演进和发展趋势

OpenStack 版本命名规则

OpenStack 发展趋势（企业关注点）