主题
OpenStack 面试题详解手册
100+ 道高频面试题，每题含: 问题 → 详解 → 追问 → 实战命令
按难度分级: ★初级 / ★★中级 / ★★★高级
建议: 每天 10-15 题，2 周过完
一、虚拟化基础 (15题)
1.1 ★ KVM 的全虚拟化原理是什么？
详解:
KVM (Kernel-based Virtual Machine) 利用 CPU 的硬件虚拟化扩展:
- Intel VT-x: 引入 VMX root/non-root 两种运行模式
- AMD-V (SVM): 类似机制
工作原理:
Host 内核 (KVM 模块) ←→ VM Guest
↓ ↓
VMX root mode VMX non-root mode
(管理 VM 进出) (Guest OS 无感知运行)
关键操作:
- VM Entry: 从 host 进入 guest (切换 CPU 模式)
- VM Exit: 从 guest 退出到 host (IO/中断触发)
- EPT/NPT: 二级页表，硬件加速内存虚拟化KVM 本质是 Linux 内核模块:
/dev/kvm: 设备文件，用户空间通过 ioctl 与之交互- QEMU: 用户空间程序，模拟硬件设备 (网卡/磁盘/VGA)
- libvirt: API 抽象层，管理 QEMU/KVM
追问: 为什么 KVM 比 Xen 性能更好？
KVM: VM 由 Linux 内核调度 (进程模型)，享受内核所有优化
Xen: 有 Domain 0 管理层，多一层调度开销
KVM 无额外管理层，VM Exit/Entry 更快实战命令:
bash
# 检查 CPU 是否支持 KVM
grep -E "vmx|svm" /proc/cpuinfo
# 检查 KVM 模块
lsmod | grep kvm
# 查看 KVM 性能统计
perf kvm stat live1.2 ★ 什么是 libvirt？它的架构是什么？
详解:
libvirt 是虚拟化管理的 API 抽象层和工具集:
用户层:
virsh CLI / virt-manager GUI / OpenStack nova-compute
↓
libvirt API (C/Python/Go...)
↓
libvirtd 守护进程
↓
┌────────┬────────┬────────┬────────┐
│ QEMU │ Xen │ LXC │ VMWare │
│ Driver │ Driver │ Driver │ Driver │
└────────┴────────┴────────┴────────┘
↓
实际 Hypervisor (KVM/Xen/LXC...)关键组件:
libvirtd: 守护进程，接收 API 请求virsh: 命令行工具virt-install: VM 创建工具libvirt-qemu: QEMU 驱动
在 OpenStack 中:
- nova-compute 调用 libvirt Python API
- 不直接操作 QEMU 进程
- XML domain 定义 → libvirt → QEMU 进程
实战命令:
bash
# 列出所有 VM
virsh list --all
# VM 详细信息
virsh dominfo <vm-name>
# VM XML 定义
virsh dumpxml <vm-name>
# 查看 libvirt 版本
virsh version1.3 ★★ qcow2 与 raw 格式有什么区别？
详解:
| 特性 | qcow2 | raw |
|---|---|---|
| 瘦分配 | ✅ 支持 | ❌ 预分配 |
| 快照 | ✅ 内置 | ❌ 外部 |
| 压缩 | ✅ 支持 | ❌ 不支持 |
| 加密 | ✅ LUKS | ❌ |
| 性能 | 略慢 (元数据开销) | 快 (无开销) |
| Ceph RBD | 需转换 | ✅ 原生支持 |
| 大小 | 实际使用量 | 全尺寸 |
qcow2 内部结构:
┌─────────────────┐
│ Header │ (版本、大小、特性)
├─────────────────┤
│ L1/L2 Table │ (簇映射表)
├─────────────────┤
│ Refcount Table │ (引用计数)
├─────────────────┤
│ Data Clusters │ (实际数据)
├─────────────────┤
│ Snapshot Header │ (快照元数据)
└─────────────────┘
Copy-on-Write:
- 基础镜像: base.qcow2 (10GB)
- VM 磁盘: vm.qcow2 (基于 base, CoW)
- 写操作: 仅写入变化块到 vm.qcow2
- 读操作: 先查 vm.qcow2, 没有则读 base.qcow2追问: Ceph RBD 为什么用 raw 而不是 qcow2？
Ceph RBD 有自己的元数据管理 (RADOS objects)
不需要 qcow2 的元数据层
raw 格式让 Ceph 直接管理块分配，性能更好
RBD 本身支持快照/克隆/瘦分配实战命令:
bash
# 查看镜像信息
qemu-img info disk.qcow2
# 格式转换
qemu-img convert -f qcow2 -O raw disk.qcow2 disk.raw
# 创建 qcow2 (瘦分配)
qemu-img create -f qcow2 new.qcow2 100G
# 压缩 qcow2
qemu-img convert -O qcow2 -c disk.qcow2 disk-compressed.qcow21.4 ★★ 什么是 CPU Pin (CPU 绑定)？
详解:
CPU Pin 将 VM 的 vCPU 绑定到特定的物理 CPU 核心:
不绑定 (默认):
vCPU-0 → 可能运行在 pCPU-0, pCPU-3, pCPU-7...
→ 缓存失效 (Cache miss)，性能不稳定
绑定 (Pinned):
vCPU-0 → 固定在 pCPU-0
vCPU-1 → 固定在 pCPU-1
→ 缓存命中率高，性能稳定可预测OpenStack 配置:
ini
# nova.conf
[compute]
cpu_shared_set = 0-3 # 共享核心 (系统)
cpu_dedicated_set = 4-63 # 专用核心 (VM)
# Flavor extra_specs
openstack flavor set m1.highperf \
--property hw:cpu_policy=dedicated \
--property hw:cpu_thread_policy=require适用场景:
- 数据库 VM (需要稳定低延迟)
- NFV/电信应用 (需要确定性性能)
- 高性能计算 (HPC)
追问: CPU Pin 与超分的关系？
CPU Pin = 1:1 映射 (不超分)
绑定的核心不能被其他 VM 使用
所以: 绑定 VM 的节点不能超分 CPU
通常: 同一节点混合部署绑定和非绑定 VM 不推荐1.5 ★★ NUMA 感知调度是什么？
详解:
NUMA (Non-Uniform Memory Access) 架构:
┌───────────────────────────────────┐
│ QPI/UPI 互联 │
│ │
┌─────┴─────┐ ┌───────┴────┐
│ Socket 0 │ │ Socket 1 │
│ ┌───────┐ │ │ ┌────────┐ │
│ │ CPU │ │ │ │ CPU │ │
│ │Cores │ │ │ │ Cores │ │
│ │0-15 │ │ │ │ 16-31 │ │
│ └───┬───┘ │ │ └───┬────┘ │
│ │ │ │ │ │
│ ┌───┴───┐ │ │ ┌───┴────┐ │
│ │Memory │ │ │ │ Memory │ │
│ │Node 0 │ │ │ │ Node 1 │ │
│ │128GB │ │ │ │ 128GB │ │
│ └───────┘ │ │ └────────┘ │
└───────────┘ └────────────┘
CPU-0 访问 Memory-0: 快 (本地)
CPU-0 访问 Memory-1: 慢 (跨 QPI, 延迟 +30-50%)OpenStack NUMA 调度:
ini
# Flavor 配置 NUMA 感知
openstack flavor set m1.numa \
--property hw:numa_nodes=1 \
--property hw:cpu_policy=dedicated \
--property hw:numa_cpus.0=0-7 \
--property hw:numa_mem.0=16384Scheduler Filter: NUMATopologyFilter 确保 VM 分配在同一个 NUMA node 内。
实战命令:
bash
# 查看 NUMA 拓扑
numactl --hardware
lscpu | grep NUMA
# 查看 VM 的 NUMA 分配
virsh vcpupin <vm-name>二、Nova 计算服务 (20题)
2.1 ★ Nova 有哪些核心组件？各自的作用？
详解:
| 组件 | 部署位置 | 作用 | 进程数 |
|---|---|---|---|
| nova-api | Controller | REST API 入口，接收请求 | 多实例 |
| nova-conductor | Controller | DB 操作代理，隔离 compute 直连 DB | 多实例 |
| nova-scheduler | Controller | 调度 VM 到最优计算节点 | 1-N |
| nova-compute | Compute | 管理 hypervisor，执行 VM 操作 | 每节点1个 |
| nova-novncproxy | Controller | WebSocket→VNC 代理 | 1-N |
| placement-api | Controller | 资源追踪与分配 | 多实例 |
通信模式:
- API → Conductor: RPC (RabbitMQ)
- Conductor → Scheduler: RPC
- Scheduler → Compute: RPC
- Compute → Neutron/Cinder/Glance: REST API
- 所有组件 → MariaDB: 通过 Conductor (compute 不直连)追问: 为什么 nova-compute 不直接访问数据库？
安全原因: compute 节点可能被攻破
如果 compute 直连 DB，攻击者可能篡改所有数据
Conductor 作为中间层，只暴露安全的操作接口
同时: 解耦、便于审计、连接池管理2.2 ★★ Nova Scheduler 的 Filter 有哪些？
详解:
Filter 分两类:
基础 Filter (默认启用):
| Filter | 作用 |
|---|---|
| AvailabilityZoneFilter | AZ 匹配 |
| ComputeFilter | 节点是否 enabled + up |
| ComputeCapabilitiesFilter | CPU/内存/磁盘是否足够 |
| ImagePropertiesFilter | 架构匹配 (x86/ARM/PPC) |
| ServerGroupAntiAffinityFilter | 反亲和 (VM 不在同节点) |
| ServerGroupAffinityFilter | 亲和 (VM 在同一节点) |
可选 Filter:
| Filter | 作用 |
|---|---|
| AggregateInstanceExtraSpecsFilter | 聚合属性匹配 |
| NUMATopologyFilter | NUMA 拓扑匹配 |
| PciPassthroughFilter | PCI 直通设备匹配 |
| RetryFilter | 排除之前调度失败的节点 |
| DifferentHostFilter | VM 不在指定节点 |
| SameHostFilter | VM 必须在指定节点 |
调度流程:
1000 节点 → Filter 过滤 → 剩 50 节点 → Weigher 打分 → 选 Top 1实战命令:
bash
# 查看当前启用的 Filter
openstack compute service list --service nova-scheduler
# 在 nova.conf 中查看
# [filter_scheduler] enabled_filters = ...
# 创建反亲和策略
openstack server group create --policy anti-affinity ha-group
openstack server create --hint group=<group-id> ...2.3 ★★ 什么是 Nova Cells v2？为什么需要它？
详解:
问题背景:
传统架构: 所有计算节点共用一个 MariaDB + RabbitMQ
当节点 > 500:
- DB 连接数爆炸 (每节点 10+ 连接 × 500 = 5000+)
- MQ 消息广播风暴
- 单点性能瓶颈Cells v2 解决方案:
┌──────────────┐
│ API Cell │
│ (Cell 0) │
│ 全局 API │
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
┌─────┴─────┐ ┌───┴─────┐ ┌───┴─────┐
│ Cell 1 │ │ Cell 2 │ │ Cell 3 │
│ 独立 DB │ │ 独立 DB │ │ 独立 DB │
│ 独立 MQ │ │ 独立 MQ │ │ 独立 MQ │
│ 200节点 │ │ 200节点 │ │ 200节点 │
└───────────┘ └─────────┘ └─────────┘每个 Cell 有独立的:
- MariaDB 数据库
- RabbitMQ 消息队列
- Conductor 服务
- Compute 节点组
优势:
- 每个 Cell 的 DB 压力小 (200 节点 vs 1000 节点)
- 故障隔离: Cell 1 故障不影响 Cell 2
- 水平扩展: 增加 Cell 即可扩容
实战命令:
bash
# 查看 Cells
nova-manage cell_v2 list_cells
# 发现新计算节点
nova-manage cell_v2 discover_hosts
# 创建新 Cell
nova-manage cell_v2 create_cell --name cell4 \
--database-connection mysql+pymysql://... \
--transport-url rabbit://...2.4 ★★ 热迁移失败如何排查？
详解:
常见失败原因与解决:
| 原因 | 错误信息 | 解决方案 |
|---|---|---|
| CPU 不兼容 | "CPU not compatible" | 使用 cpu_mode=host-model |
| 内存脏页过快 | "Migration timed out" | 启用 auto-converge |
| 目标资源不足 | "No valid host" | 选择其他目标节点 |
| 网络不通 | "Connection refused" | 检查迁移网络连通性 |
| Ceph 不可达 | "RBD error" | 检查 Ceph 健康状态 |
| VM 有 PCI 设备 | "not supported" | PCI 直通不支持热迁移 |
排查步骤:
bash
# 1. 查看迁移状态
openstack server migration list --server <vm-id>
# 2. 查看 nova-compute 日志
docker logs nova_compute 2>&1 | grep -i "migration\|error"
# 3. 检查 libvirt 迁移日志
journalctl -u libvirtd | grep migrate
# 4. 检查 CPU 兼容性
# 源节点:
virsh capabilities | grep -A10 "cpu"
# 目标节点:
virsh capabilities | grep -A10 "cpu"
# 5. 检查迁移带宽
# 迁移网络是否专用？带宽是否足够？
iperf3 -c <target-ip> -p 5201配置调优:
ini
# nova.conf
[libvirt]
live_migration_tunnelled = true # 加密
live_migration_permit_auto_converge = true # 自动降速
live_migration_permit_post_copy = true # 允许 post-copy
live_migration_timeout_action = 'force_complete' # 超时强制完成
live_migration_completion_timeout = 800 # 超时 800s2.5 ★★★ Nova 中的 Placement API 是什么？
详解:
Placement 是 OpenStack 的资源追踪与分配服务 (从 Nova 独立):
Placement 核心概念:
Resource Provider (资源提供者):
- 每个 compute 节点是一个 RP
- 每个存储后端是一个 RP
- 每个网络 agent 是一个 RP
Resource Class (资源类型):
- VCPU, MEMORY_MB, DISK_GB
- SRIOV_NET_VF, IPV4_ADDRESS
- 可扩展自定义类型
Inventory (库存):
- 每个 RP 拥有的资源量
- 总量 / 已分配 / 预留
Allocation (分配):
- 消费者 (VM) 从 RP 分配资源
- 跟踪: 谁用了什么，用了多少
Consumer (消费者):
- VM 实例
- 网络端口作用:
- Nova Scheduler 查询: "哪些节点有足够 vCPU 和内存？"
- 资源分配: "VM-A 在 compute-01 上使用了 4 vCPU + 8GB"
- 跨服务: Neutron 也可以查询/分配资源
追问: Placement 与 Nova DB 中的资源信息有什么区别？
Nova DB: 记录 VM 状态、元数据、调度结果
Placement: 记录资源库存和分配 (纯数字)
Placement 更轻量，查询更快
Scheduler 查 Placement → 选定节点 → 写 Nova DB实战命令:
bash
# 查看资源提供者
openstack allocation candidate list --resource VCPU=1
# 查看节点资源
openstack resource provider show <compute-host>
openstack resource provider inventory list <compute-host>
# 查看分配
openstack resource provider allocation show <consumer-uuid>2.6 ★★★ Nova 中 VM 的磁盘是如何管理的？
详解:
VM 磁盘架构 (Ceph RBD 后端):
Glance 镜像 (image-uuid)
│ (首次使用下载到计算节点缓存)
↓
/var/lib/nova/instances/<instance-uuid>/
├── _base/ # 镜像缓存
│ └── <image-hash> # 原始镜像 (只读)
└── disk # VM 系统盘 (CoW)
└── Ceph RBD: vms/<instance-uuid>_disk
Ceph RBD 中的结构:
pool: images → Glance 镜像 (只读)
pool: vms → Nova 实例盘 (读写)
pool: volumes → Cinder 数据卷 (读写)
Copy-on-Write 过程:
1. 镜像上传到 Glance → 存入 Ceph images pool
2. 创建 VM → Nova 调 Ceph: rbd clone images/<img> vms/<vm-disk>
3. VM 运行时的写操作 → 写入 vms pool (不影响原镜像)
4. 读操作 → 先查 vm disk，没有则查原镜像追问: 为什么 Ceph RBD 比本地 LVM 更适合大规模部署？
1. 共享存储: 热迁移不需要块迁移 (秒级 vs 分钟级)
2. 快照: CoW 快照秒级完成
3. 高可用: 3 副本，节点故障数据不丢
4. 弹性: 按需扩容 OSD 节点
5. 性能: NVMe DB/WAL 加速元数据操作三、Neutron 网络服务 (20题)
3.1 ★ Neutron 中 Provider Network 和 Self-Service Network 区别？
详解:
| 维度 | Provider Network | Self-Service Network |
|---|---|---|
| 创建者 | 管理员 | 租户用户 |
| 类型 | flat / VLAN | Geneve / VXLAN |
| 映射 | 直接映射物理网络 | overlay 隧道网络 |
| 用途 | 外部网络/存储网络 | 租户内部业务网络 |
| DHCP | 外部 DHCP 或 Neutron | Neutron DHCP |
| 路由 | 无 (二层直通) | 通过 Router 连外网 |
| 隔离 | VLAN ID | VNI (24bit, 1600万个) |
Provider Network 流量路径:
VM → tap → br-int → VLAN tag → 物理交换机 → 外网
Self-Service Network 流量路径:
VM → tap → br-int → Geneve 封装 → 隧道 → 目标节点 br-int → tap → VM实战命令:
bash
# 创建 Provider Network
openstack network create --external \
--provider-network-type vlan \
--provider-physical-network physnet1 \
--provider-segment 100 \
external-net
# 创建 Self-Service Network
openstack network create tenant-net
openstack subnet create tenant-sub \
--network tenant-net --subnet-range 10.10.1.0/243.2 ★★ OVN 与 OVS (ML2/OVS) 有什么区别？
详解:
OVS (ML2/OVS) 架构:
┌──────────────────────────────────┐
│ neutron-server (Controller) │
│ ├── ML2 Plugin │
│ └── L3 Agent / DHCP Agent │
└──────────┬───────────────────────┘
│ RPC (每节点通信)
┌─────┼─────┐
↓ ↓ ↓
┌─────┐┌─────┐┌─────┐
│neutron││neutron││neutron│ ← 每节点一个 agent
│openvsw││openvsw││openvsw│
│agent ││agent ││agent │
└──┬───┘└──┬───┘└──┬───┘
↓ ↓ ↓
OVS OVS OVS
问题: 1000 节点 = 1000 个 agent，控制面压力大OVN 架构:
┌──────────────────────────────────┐
│ neutron-server + OVN NB DB │
│ └── ovn-northd (翻译器) │
│ └── OVN SB DB │
└──────────┬───────────────────────┘
│ (SB DB 订阅, 非 RPC)
┌─────┼─────┐
↓ ↓ ↓
┌─────┐┌─────┐┌─────┐
│ovn- ││ovn- ││ovn- │ ← 轻量控制器
│ctrl ││ctrl ││ctrl │
└──┬──┘└──┬──┘└──┬──┘
↓ ↓ ↓
OVS OVS OVS| 对比 | OVS Agent | OVN |
|---|---|---|
| 控制模式 | RPC (中心化) | DB 订阅 (分布式) |
| 每节点开销 | 重 (agent 进程) | 轻 (ovn-controller) |
| 网络延迟 | RPC 往返 | DB 事件驱动 |
| L3 路由 | 集中式 L3 agent | 分布式 (DVR-like) |
| DHCP | 独立 dhcp agent | OVN 内置 |
| 安全组 | iptables | ACL (OVS 流表) |
3.3 ★★ Geneve/VXLAN 封装的原理？
详解:
VXLAN 封装 (UDP port 4789):
┌──────────────────────────────────────┐
│ Outer Ethernet │ Outer IP │UDP│VXLAN│ Inner Packet │
│ (物理 MAC) │(物理 IP) │4789│VNI │(VM 原始包) │
└──────────────────────────────────────┘
Geneve 封装 (UDP port 6081):
┌─────────────────────────────────────────────┐
│Outer Eth│Outer IP│UDP│Geneve│TLV Opts│Inner │
│ │ │6081│ Hdr │(可扩展) │Packet│
└─────────────────────────────────────────────┘
Geneve vs VXLAN:
- Geneve 是 VXLAN 的升级版
- Geneve 支持 TLV 扩展 (可携带元数据)
- OVN 默认使用 Geneve
- 头部开销: VXLAN=50B, Geneve=58BMTU 计算:
物理网络 MTU = 9000 (Jumbo Frame)
Geneve 头部 = 58 bytes
VM 可用 MTU = 9000 - 58 = 8942
物理网络 MTU = 1500 (标准)
Geneve 头部 = 58 bytes
VM 可用 MTU = 1500 - 58 = 1442 ← 注意!追问: 为什么 overlay 网络建议用 Jumbo Frame？
1. 减少封装开销 (头部占比从 3.8% 降到 0.6%)
2. 减少分片 (大包不需要拆分为小包)
3. 提升吞吐 (单次传输更多有效数据)3.4 ★★ 安全组的底层实现？
详解:
OVS 模式 (iptables):
安全组规则 → iptables 规则
→ 应用在 tap 设备 (VM 虚拟网卡)
流量路径:
VM 出方向: VM → tap → iptables (egress chain) → br-int
VM 入方向: br-int → iptables (ingress chain) → tap → VM
有状态: conntrack 模块追踪连接
- 出方向建立连接后，回程自动放行OVN 模式 (ACL):
安全组规则 → OVN ACL (Northbound DB)
→ ovn-northd 翻译为逻辑流表
→ OVN SB DB
→ ovn-controller → OVS 流表
优势:
- 规则在 OVS 流表中 (内核态)，性能好
- 无需 iptables，减少规则数量
- 集中管理 (NB DB)实战命令:
bash
# 查看安全组规则 (OVN)
ovn-nbctl list acl
# 查看 OVS 流表中的安全组规则
ovs-ofctl dump-flows br-int | grep -i "ct\|conntrack"
# 查看 conntrack 表
conntrack -L | grep <vm-ip>3.5 ★★★ DVR (分布式虚拟路由) 是什么？
详解:
问题: 传统集中式路由，所有 N-S 流量经过 Gateway 节点:
传统模式 (集中式):
VM → 计算节点 → Gateway 节点 → 外网
↑ 瓶颈!
1000 个计算节点的流量全部经过 2-4 个 GatewayDVR 解决方案:
DVR 模式:
East-West: VM → 计算节点本地路由 → 目标 VM (不经过 Gateway)
North-South (有浮动IP): VM → 计算节点 SNAT/DNAT → 外网
North-South (无浮动IP): VM → 计算节点 → Gateway SNAT → 外网
优势:
- E-W 流量完全分布式，无瓶颈
- 有浮动IP的 N-S 流量也分布式
- 仅 SNAT 流量走 Gateway (大幅减少)在 OVN 中:
- OVN 原生支持分布式路由 (无需额外配置 DVR)
- Gateway Chassis: 指定 Gateway 节点处理 SNAT
- 多个 Gateway Chassis 实现 HA
四、Ceph 存储 (15题)
4.1 ★ Ceph 的核心组件有哪些？
详解:
| 组件 | 作用 | 部署数量 |
|---|---|---|
| MON (Monitor) | 集群状态管理、CRUSH map 分发 | 3/5 (奇数) |
| MGR (Manager) | 集群监控、Dashboard、插件 | 2-3 |
| OSD (Object Storage Daemon) | 实际数据存储 | 数百-数千 |
| MDS (Metadata Server) | CephFS 元数据 (块存储不需要) | 2+ |
Ceph 架构:
┌─────┐ ┌─────┐ ┌─────┐
│MON-1│ │MON-2│ │MON-3│ ← Paxos 共识
└─────┘ └─────┘ └─────┘
┌────────────────────────────┐
│ CRUSH Map (数据分布算法) │
└────────────────────────────┘
↓
┌──────┐ ┌──────┐ ┌──────┐ ... ┌──────┐
│OSD-1 │ │OSD-2 │ │OSD-3 │ │OSD-N │
│/dev/sdb│ │/dev/sdc│ │/dev/sdd│ │/dev/sdN│
└──────┘ └──────┘ └──────┘ └──────┘
数据写入流程:
1. Client 向 MON 获取 CRUSH map
2. Client 本地计算: 数据应写入哪些 OSD
3. Client 直接写 OSD (无中心节点)
4. Primary OSD 复制到 Secondary OSD追问: 为什么 Ceph 不需要中心元数据节点？
CRUSH 算法: 伪随机确定性分布
给定 (object_id, CRUSH map) → 确定 OSD 位置
Client 自己计算，无需查询中心节点
→ 无限水平扩展，无单点瓶颈4.2 ★★ CRUSH 算法原理？
详解:
CRUSH = Controlled Replication Under Scalable Hashing
核心思想:
不存储"数据在哪"的映射表
而是通过算法计算"数据应该在哪"
计算过程:
1. 输入: object_id + pool_id
2. Hash → PG (Placement Group)
3. PG + CRUSH rules → OSD 列表
4. 写 Primary OSD → 复制到 Secondary
CRUSH Rule 示例:
rule: replicated_rule_rack
step: take default # 从根节点开始
step: chooseleaf firstn 3 # 选 3 个不同 rack 的 OSD
step: emit # 输出结果
故障域层级:
root → datacenter → room → rack → row → host → osd实战命令:
bash
# 查看 CRUSH 树
ceph osd crush tree
# 查看 CRUSH 规则
ceph osd crush rule dump
# 创建 rack 级别故障域
ceph osd crush add-bucket rack1 rack
ceph osd crush move osd.0 rack=rack1
ceph osd crush rule create-replicated \
rack-rule default rack4.3 ★★ PG (Placement Group) 是什么？数量如何计算？
详解:
PG 是数据分布的基本单位:
Pool → 包含 N 个 PG → 每个 PG 映射到一组 OSD
为什么需要 PG？
- 如果直接 object → OSD: 数十亿 object 的映射表太大
- 引入 PG 中间层: object → PG → OSD
- PG 数量可控 (几百到几千)
PG 数量计算:
PG = (OSD总数 × 100) / 副本数
取整到最近的 2 的幂
例: 360 OSD, 3 副本
PG = 360 × 100 / 3 = 12000
→ 取 8192 或 16384 (2 的幂)
PG 太少: 数据分布不均 (热点)
PG 太多: OSD 间通信开销大实战命令:
bash
# 查看 Pool 的 PG 数
ceph osd pool get volumes pg_num
# 调整 PG 数 (在线调整)
ceph osd pool set volumes pg_num 512
ceph osd pool set volumes pgp_num 512
# 启用自动缩放 (推荐)
ceph osd pool set volumes pg_autoscale_mode on
# 查看 PG 状态
ceph pg stat
ceph pg dump_stuck unclean4.4 ★★★ Ceph 的 Recovery 和 Rebalance 区别？
详解:
Recovery (恢复):
触发: OSD down (暂时故障)
行为: 从其他副本恢复数据到该 OSD
目标: 恢复该 OSD 上的数据到 3 副本
速度: 只影响该 OSD 的数据
Rebalance (重平衡):
触发: OSD out (永久移除) / 新增 OSD
行为: 重新计算 CRUSH 映射，移动 PG
目标: 数据重新均匀分布
速度: 影响大量数据，较慢
场景对比:
1. OSD-5 临时 down:
→ Recovery: 从 OSD-5 的副本恢复到其他 OSD
→ OSD-5 恢复后: 数据回灌 (backfill)
2. OSD-5 永久故障 (osd out):
→ Rebalance: PG 重新映射到剩余 OSD
→ 大量数据移动
3. 新增 OSD-31:
→ Rebalance: 部分 PG 从其他 OSD 移到 OSD-31
→ 数据重新均衡性能控制:
bash
# 限制 recovery 速度 (避免影响业务)
ceph tell osd.* injectargs \
'--osd-recovery-max-active 1 \
--osd-max-backfills 1 \
--osd-recovery-sleep 0.1'
# 业务低峰期加速
ceph tell osd.* injectargs \
'--osd-recovery-max-active 3 \
--osd-max-backfills 3'五、高可用与运维 (20题)
5.1 ★ OpenStack 控制平面如何实现 HA？
详解:
HA 三层架构:
Layer 1: VIP + 负载均衡
Keepalived (VRRP) → VIP 漂移
HAProxy → API 请求分发
Layer 2: 数据库 HA
MariaDB Galera → 同步复制
5 节点，支持 2 节点故障
Layer 3: 消息队列 HA
RabbitMQ 镜像队列 / Quorum 队列
3 副本，消息不丢失
所有 API 服务多实例:
nova-api × 5, neutron-server × 5, ...
HAProxy 后端健康检查追问: 如果 Keepalived 的两个节点同时检测到自己是 master？
脑裂 (Split Brain):
- 通常由网络分区导致
- Keepalived 通过 VRRP 优先级解决
- 高优先级节点保持 master
- 低优先级节点降级为 backup
- 极端情况: 使用 STONITH (fencing) 隔离5.2 ★★ RabbitMQ 消息堆积如何处理？
详解:
消息堆积原因:
1. 消费者处理慢 (Nova-compute 负载高)
2. 消费者数量不足
3. 消费者 crash (未重启)
4. 队列没有消费者
排查步骤:
1. 查看堆积队列
rabbitmqctl list_queues name messages consumers \
| sort -k2 -rn | head -20
2. 检查消费者
rabbitmqctl list_consumers
3. 检查服务状态
openstack compute service list | grep down
解决:
1. 增加消费者: 增大 rpc_workers
2. 重启异常服务
3. 清理僵尸队列 (无消费者且消息过期)
4. 优化处理逻辑 (减少单消息处理时间)配置优化:
ini
# nova.conf
[DEFAULT]
rpc_workers = 8 # RPC worker 数
rpc_state_report_workers = 4 # 状态上报 worker
[oslo_messaging_rabbit]
rabbit_ha_queues = true # 启用 HA 队列
rabbit_retry_interval = 1
rabbit_retry_backoff = 2
rabbit_max_retries = 0 # 无限重试5.3 ★★ 如何设计 OpenStack 监控体系？
详解:
监控三层:
Layer 1: 指标采集 (Prometheus)
├── node-exporter: 系统指标 (CPU/内存/磁盘/网络)
├── openstack-exporter: OpenStack 服务指标
├── ceph-exporter: Ceph 集群指标
├── mysql-exporter: 数据库指标
├── rabbitmq-exporter: MQ 指标
└── haproxy-exporter: 负载均衡指标
Layer 2: 可视化 (Grafana)
├── 集群概览 Dashboard
├── 计算节点 Dashboard
├── 网络 Dashboard
├── 存储 Dashboard
└── 告警 Dashboard
Layer 3: 告警 (AlertManager)
├── Critical: 服务 down / Ceph HEALTH_ERR / VIP 丢失
├── Warning: 资源 > 80% / API P99 > 2s / 消息堆积
└── Info: 容量预警 / 证书过期关键指标:
| 指标 | 告警阈值 | 含义 |
|---|---|---|
| nova_service_state | > 0 | Nova 服务异常 |
| ceph_health_status | == 2 | Ceph 集群错误 |
| api_request_duration_p99 | > 2s | API 响应慢 |
| rabbitmq_queue_messages | > 10000 | 消息堆积 |
| node_cpu_usage | > 90% (持续5min) | CPU 过载 |
| galera_cluster_size | < 3 | Galera 节点不足 |
5.4 ★★★ 如何实现 VM 高可用 (Instance HA)？
详解:
方案 1: Nova 内置 HA (简单)
resume_guests_state_on_host_boot = true
→ 计算节点重启后 VM 自动恢复
方案 2: Masakari (推荐)
OpenStack 实例 HA 服务:
- 监控 compute 节点健康
- 节点故障时自动在其他节点重建 VM
- 支持 VM 级和进程级监控
流程:
1. Masakari 检测 compute-01 无响应 (超时)
2. 通知 Nova: compute-01 故障
3. Nova 将 compute-01 上所有 VM 标记为需要重建
4. Nova 在其他节点重建 VM (使用 Ceph 共享存储)
5. VM 恢复运行 (短暂中断)
方案 3: Pacemaker + libvirt (外部方案)
- Pacemaker 监控 libvirtd 进程
- 节点故障时迁移 VM
- 复杂度高，不推荐Masakari 配置:
ini
# masakari.conf
[host]
monitoring_interval = 60 # 检测间隔 60s
monitoring_samples = 3 # 连续 3 次失败确认
[api]
notification_topic = host_failure六、性能调优 (10题)
6.1 ★★★ OpenStack API 性能如何优化？
详解:
优化 5 层:
1. Worker 层
api_workers = <CPU cores> # 每核心一个 worker
→ 4 核 = 4 workers, 处理能力提升 4x
2. 连接池层
max_pool_size = 50 # DB 连接池 (默认5)
max_overflow = 100 # 溢出连接 (默认10)
pool_timeout = 30 # 获取连接超时
3. Token 层
token_cache_time = 600 # Token 缓存 (Memcached)
→ 减少 Keystone 调用
4. 数据库层
innodb_buffer_pool_size = 64G # 缓存热数据
innodb_io_capacity = 4000 # SSD 优化
→ 减少磁盘 IO
5. 缓存层
[cache] enabled = true # 启用 oslo.cache
backend = dogpile.cache.memcached
→ 缓存重复查询结果验证:
bash
# 压测 API
curl -w "@curl-format.txt" -o /dev/null -s \
-H "X-Auth-Token: $TOKEN" \
http://10.0.1.100:8774/v2.1/servers
# 对比优化前后
# 优化前: P99 = 2.5s
# 优化后: P99 = 0.3s6.2 ★★★ 计算节点性能调优清单？
详解:
bash
# 1. 内核参数
cat > /etc/sysctl.d/99-openstack.conf << 'EOF'
# 网络
net.core.somaxconn = 65535
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
# 内存
vm.swappiness = 10
vm.overcommit_memory = 1
# 文件系统
fs.file-max = 2097152
fs.inotify.max_user_watches = 524288
EOF
# 2. HugePages (大页内存)
# 减少 TLB miss, 提升 VM 内存访问性能
echo 4096 > /proc/sys/vm/nr_hugepages # 4096 × 2MB = 8GB
# Nova 配置:
# [libvirt] hugepages_enabled = true
# 3. CPU Governor
cpupower frequency-set -g performance # 锁定最高频率
# 4. 磁盘调度器
echo mq-deadline > /sys/block/sda/queue/scheduler # SSD
echo bfq > /sys/block/sdb/queue/scheduler # HDD
# 5. NUMA 绑定
# 将 nova-compute 绑定到特定 NUMA node
taskset -c 0-15 docker restart nova_compute
# 6. KSM (Kernel Same-page Merging)
# 合并相同内存页，节省内存
echo 1 > /sys/kernel/mm/ksm/run
# 注意: 有 CPU 开销，高负载时关闭七、安全与合规 (10题)
7.1 ★★ OpenStack 有哪些安全加固措施？
详解:
安全加固清单:
1. 认证安全
- Fernet Token (非 UUID)
- 密码复杂度策略
- 登录失败锁定
- Token 过期时间控制
2. 网络安全
- TLS 加密所有 API
- 安全组默认 deny
- 管理网络隔离
- 防火墙限制端口访问
3. 数据安全
- Ceph 加密 (LUKS)
- Barbican 密钥管理
- 卷加密 (LUKS 后端)
- 审计日志 (全量 API 调用)
4. 虚拟化安全
- sVirt (SELinux for VM)
- 禁用不必要的 VM 设备
- CPU 漏洞缓解 (Spectre/Meltdown)
5. 运维安全
- RBAC 最小权限原则
- 操作审计 (全量日志)
- 变更管理流程
- 定期安全扫描追问: 如何防止租户 VM 逃逸？
1. 使用最新 KVM/QEMU (修补已知漏洞)
2. 启用 sVirt/SELinux 强制访问控制
3. 限制 VM 设备 (不需要 USB/串口就禁用)
4. CPU Pin 隔离 (避免侧信道攻击)
5. 网络隔离 (安全组 + OVN ACL)
6. 定期更新补丁附录: 面试准备 Checklist
□ 虚拟化基础: KVM/libvirt/qcow2/raw/NUMA/SR-IOV
□ Keystone: Token/Fernet/RBAC/Domain/Project
□ Nova: 架构/Scheduler/热迁移/Cells v2/Placement
□ Neutron: OVN/安全组/Geneve/浮动IP/DVR
□ Cinder: 架构/Ceph RBD/快照/扩容
□ Glance: 后端选型/镜像格式/缓存
□ Ceph: CRUSH/PG/Recovery/Rebalance/性能
□ HA: Galera/RabbitMQ/Keepalived/HAProxy
□ 监控: Prometheus/Grafana/告警规则
□ 性能: DB调优/MQ调优/API调优/内核调优
□ 安全: TLS/RBAC/审计/加密/合规
□ 运维: 部署/升级/备份/故障处理/自动化
□ 场景: 大规模设计/成本优化/灾难恢复/迁移