主题
OpenStack 模拟面试手册
包含 5 套完整模拟面试题
每套含: 面试官问题 + 参考答案 + 评分标准
建议: 找人互相模拟练习，每套 45-60 分钟
模拟面试 A — 初级运维工程师（1-2年）
面试时长: 45分钟 | 难度: ★★☆☆☆
A1: 自我介绍 + 基础题 (10min)
面试官: 请做一下自我介绍，然后回答：什么是 OpenStack？它和 VMware vSphere 有什么区别？
参考答案:
OpenStack 是开源 IaaS 云平台，管理计算/存储/网络三大资源。
与 vSphere 的核心区别:
1. 开源 vs 商业: OpenStack 免费，vSphere 按 CPU 授权
2. 架构: OpenStack 松耦合微服务，vSphere 单体架构
3. 网络: OpenStack 用 OVN/OVS (SDN)，vSphere 用 NSX
4. 存储: OpenStack 常搭配 Ceph，vSphere 用 vSAN
5. 扩展性: OpenStack 原生支持千节点，vSphere 集群规模受限
6. 社区: OpenStack 全球社区驱动，更新快
相同点: 都提供 VM 管理、虚拟网络、块存储、镜像管理。评分: ★★★★☆ (能说出 3 点以上区别，且理解本质差异)
A2: 计算服务 (10min)
面试官: 请描述创建一个 VM 的完整流程，从用户点击"创建"到 VM 变为 ACTIVE。
参考答案:
完整流程:
1. 用户点击创建 → Horizon 发送 POST /servers 请求
2. nova-api 验证 Token (调 Keystone) + 验证参数
3. nova-api 在 DB 创建 instance 记录 (status=building)
4. nova-api 发 RPC 消息给 scheduler
5. scheduler 执行 Filter 过滤 (排除不可用节点)
6. scheduler 执行 Weigher 打分 (选最优节点)
7. scheduler 选定目标节点，发 RPC 给 nova-compute
8. nova-compute:
a. 调 Neutron 创建端口 (分配 IP)
b. 调 Cinder 创建/挂载卷
c. 调 Glance 获取镜像 (本地无则下载)
d. 生成 libvirt XML
e. 调用 libvirt 创建 VM
f. libvirt → QEMU/KVM 进程启动
9. 状态更新为 ACTIVE，返回用户评分: ★★★★★ (能说出 scheduler 的 Filter/Weigh 阶段，提到 RPC 通信)
A3: 网络基础 (10min)
面试官: 租户 A 创建了一个网络 10.10.1.0/24，租户 B 也创建了同样的网段。会不会冲突？为什么？
参考答案:
不会冲突。
原因:
1. OpenStack 使用 overlay 网络 (Geneve/VXLAN)
2. 每个租户网络有独立的 VNI (VXLAN Network Identifier)
3. VNI 在隧道层面隔离了不同租户的流量
4. 即使 IP 网段相同，不同 VNI 的流量不会互串
5. 安全组进一步保证: 默认禁止跨租户访问
类比: 就像两个公司的内网都用 192.168.1.0/24，
但它们是完全隔离的。评分: ★★★★☆ (能说出 VNI/overlay 隔离，且类比清晰)
A4: 存储 (5min)
面试官: Cinder 卷挂载到 VM 后，VM 内如何操作？如何在线扩容？
参考答案:
挂载后操作 (Linux VM):
1. fdisk -l # 查看新卷 (如 /dev/vdb)
2. mkfs.ext4 /dev/vdb # 格式化
3. mount /dev/vdb /data # 挂载
4. echo "/dev/vdb /data ext4 defaults 0 0" >> /etc/fstab
在线扩容:
1. OpenStack: openstack volume set --size 200 vol-01
2. VM 内: partprobe /dev/vdb # 重扫分区
3. VM 内: resize2fs /dev/vdb # 扩展文件系统
4. 无需重启 VM评分: ★★★★☆ (能说出完整步骤且知道在线扩容不需重启)
A5: 故障排查 (10min)
面试官: 用户反馈他的 VM SSH 连不上，你如何排查？
参考答案:
排查步骤 (由外到内):
1. 确认 VM 状态
openstack server show <vm> -c status -c addresses
→ 如果是 ERROR，查看 fault 字段
2. 确认安全组规则
openstack security group rule list <sg-id>
→ 是否允许 TCP 22 入方向
3. VNC 控制台检查
openstack console url show <vm>
→ 浏览器打开，确认 VM 系统是否正常运行
4. 检查网络连通性
→ 从同网段其他 VM ping 目标 VM IP
→ 如果 ping 不通，检查 OVN/OVS 流表
5. 检查 SSH 服务
→ VNC 登录后: systemctl status sshd
→ 检查防火墙: iptables -L
→ 检查 sshd_config: PermitRootLogin
6. 检查浮动 IP (如果是通过浮动 IP 访问)
→ 浮动 IP 是否绑定
→ 路由器是否关联 external network评分: ★★★★★ (有清晰的排查思路，由外到内层层深入)
模拟面试 B — 中级运维工程师（2-4年）
面试时长: 60分钟 | 难度: ★★★☆☆
B1: Neutron 深入 (15min)
面试官: 请画出 OVN 的架构图，并解释 Northbound DB 和 Southbound DB 各自存储什么？
参考答案:
OVN 架构:
API → neutron-server → OVN NB DB → ovn-northd → OVN SB DB
↓
ovn-controller (每节点)
↓
OVS (br-int)
NB DB (Northbound):
- 逻辑交换机 (Logical Switch)
- 逻辑路由器 (Logical Router)
- 逻辑端口 (Logical Switch Port)
- ACL 规则 (安全组)
- DHCP 选项
- 负载均衡器
SB DB (Southbound):
- Chassis (物理节点注册)
- 逻辑流表 (Logical Flow)
- 端口绑定 (Port Binding)
- MAC 绑定表
- DNS 记录
ovn-northd 的角色:
将 NB 的逻辑网络定义翻译成 SB 的逻辑流表
(类似: "用户说我要一个网络" → "翻译为 OVS 流表规则")评分: ★★★★★ (能清晰说出 NB/SB 各自存什么，ovn-northd 的角色)
B2: 热迁移 (10min)
面试官: 热迁移有哪些前提条件？迁移过程中 VM 的内存如何同步？
参考答案:
前提条件:
1. CPU 兼容 (同型号或 host-model/host-passthrough)
2. 共享存储 (Ceph RBD) 或启用块迁移
3. 迁移网络互通 (专用迁移网络推荐)
4. libvirt 版本兼容
5. VM 没有绑定本地设备 (如 PCI passthrough)
内存同步过程 (Pre-copy):
1. 第一轮: 复制全部内存页到目标节点
2. 第N轮: 仅复制脏页 (被修改过的页)
3. 重复直到脏页量足够小 或 达到最大迭代次数
4. 最后: 暂停源 VM → 复制最后脏页 → 切换 → 目标 VM 启动
关键参数:
- 暂停时间: 通常 < 100ms (用户无感知)
- 如果脏页速率 > 复制速率:
- 启用 auto-converge (降速 VM CPU)
- 或切换到 post-copy 模式
- 超时: live_migration_completion_timeout 配置
失败处理:
- 超时 → 自动回滚到源节点
- 网络断开 → 源节点继续运行评分: ★★★★★ (能说出 Pre-copy 流程、脏页问题、auto-converge)
B3: 高可用 (15min)
面试官: MariaDB Galera 集群一个节点挂了会发生什么？两个节点同时挂呢？
参考答案:
场景1: 1个节点挂 (5节点集群)
- Galera 自动检测 (心跳超时)
- 剩余 4 节点继续服务 (quorum 满足: 4 > 5/2)
- 读写正常，性能略降
- HAProxy 检测到节点 down → 从 backend 移除
- 节点恢复后自动重新加入 + 数据同步
场景2: 2个节点同时挂 (5节点集群)
- 剩余 3 节点 (quorum: 3 > 5/2) → 仍可用 ✅
- 读写正常，性能进一步下降
场景3: 3个节点同时挂 (5节点集群)
- 剩余 2 节点 (quorum: 2 < 5/2) → 失去仲裁 ❌
- 集群进入 non-Primary 状态，拒绝写入
- 需要手动恢复: 选一个节点 --wsrep-new-cluster
脑裂预防:
- 奇数节点设计避免 50/50 分裂
- 可用 Galera Arbitrator (garbd) 作为额外投票节点
- 网络分区时: 少数派节点自动停止服务
监控指标:
- wsrep_cluster_status = Primary (正常)
- wsrep_cluster_size = 5 (期望值)
- wsrep_local_state_comment = Synced (已同步)评分: ★★★★★ (理解 quorum 机制，能计算多数派)
B4: 性能调优 (10min)
面试官: 用户反馈 API 响应很慢，你会从哪些方面排查和优化？
参考答案:
排查框架:
1. 确认慢的范围
- 哪个 API？(Nova/Neutron/Cinder)
- 全局慢还是特定操作慢？
2. API Worker 层面
- 检查 worker 数: ps aux | grep nova-api
- 是否等于 CPU 核心数
- 调优: api_workers = <CPU cores>
3. 数据库层面
- SHOW PROCESSLIST → 是否有慢查询
- 连接数: Threads_connected / max_connections
- 调优: 增大 innodb_buffer_pool_size
- 检查: 是否需要添加索引
4. RabbitMQ 层面
- 消息堆积: rabbitmqctl list_queues messages
- 消费者是否在线
- 调优: 增大 consumer_timeout
5. 连接池
- max_pool_size: 默认 5，千节点建议 50
- max_overflow: 默认 10，建议 100
- 检查日志: "pool timeout" 关键词
6. Token 验证
- Keystone token 验证是否走缓存
- Memcached 命中率: stats 命令查看
- 调优: token_cache_time = 600
7. 网络延迟
- API 节点到 DB 延迟 < 1ms
- API 节点到 MQ 延迟 < 1ms评分: ★★★★☆ (有系统的排查框架，每个层面都有具体调优项)
B5: 场景题 (10min)
面试官: 你要在一个新机房部署 200 台计算节点的 OpenStack 集群，请描述你的部署计划和注意事项。
参考答案:
部署计划:
1. 硬件准备 (1周)
- 服务器上架 + 布线 (电源/网络/BMC)
- BIOS 配置: 开启 VT-x, 关闭 HyperThreading (视需求)
- 网络配置: Bond, VLAN, MTU=9000
- IPMI 测试: 远程开关机
2. 基础环境 (1周)
- OS 安装 (Rocky 9 / Ubuntu 22.04)
- NTP 同步 (关键!)
- Docker 安装 + 配置
- 内核参数调优
- Ansible 免密 SSH
3. 控制平面 (2天)
- Kolla-Ansible deploy
- 验证所有服务健康
- 配置 Ceph 集群
4. 计算节点分批部署 (1周)
- 每批 50 台
- 部署 → 验证 → 下一批
- 每批后检查 scheduler 能发现新节点
5. 网络配置 (3天)
- Provider network (外部)
- 租户网络模板
- 安全组基线
6. 功能验证 (3天)
- VM 创建/迁移/快照
- 网络连通性
- 存储 IO 测试
注意事项:
- NTP 必须同步 (差>0.05s 会导致 Galera/RabbitMQ 异常)
- 分批部署避免同时加入过多节点
- 监控先部署，部署过程中就要能看到指标
- 文档化所有操作，便于后续维护评分: ★★★★★ (有清晰的时间线和阶段划分，知道关键注意事项)
模拟面试 C — 高级工程师（4-6年）
面试时长: 60分钟 | 难度: ★★★★☆
C1: 架构设计 (15min)
面试官: 请设计一个支撑 1000 计算节点的 OpenStack 架构，说明你的选型理由。
参考答案:
架构设计:
控制平面 (5 节点):
- 理由: Galera 需要奇数，5节点支持2节点故障
- 配置: 32C/256G/2x1.92T NVMe
- 服务: 所有 API + MariaDB + RabbitMQ + OVN NB/SB
计算节点 (1000+):
- 配置: 64C/512G
- CPU 超分: 4:1 (通用) / 2:1 (高性能业务)
- 使用 Cells v2 划分 (每 Cell 200 节点)
存储 (Ceph, 30 OSD 节点):
- 理由: 分布式、高可用、与 OpenStack 深度集成
- 3副本 + CRUSH 跨机架
- NVMe DB/WAL 加速
网络 (OVN):
- 理由: 比传统 OVS agent 性能好 10x
- 支持千节点验证
- 集中式控制 + 分布式转发
高可用:
- HAProxy + Keepalived (VIP)
- MariaDB Galera (同步复制)
- RabbitMQ 镜像队列 (Raft)
- OVN NB/SB Raft 集群
关键设计决策:
1. Cells v2: 解决单 DB 瓶颈
2. OVN 替代 OVS agent: 减少每节点 agent 开销
3. Ceph 替代本地存储: 热迁移无需块迁移
4. 5 控制节点: 支持 2 节点同时故障评分: ★★★★★ (架构完整，每个选型都有理由，考虑了扩展性)
C2: 故障场景 (15min)
面试官: 凌晨 3 点，监控告警：Ceph 集群 HEALTH_ERR，10 个 OSD down。如何处理？
参考答案:
处理流程:
第1步: 评估影响 (2min)
- ceph status → 看 HEALTH 详情
- ceph osd tree → 确认哪些 OSD down
- 判断: 是否影响数据可用性 (3副本下，10个OSD down 可能安全)
第2步: 检查数据可用性 (3min)
- ceph osd df → 看 PG 状态
- ceph pg stat → 确认无 degraded/undersized PG
- 如果所有 PG 仍有 3 副本 → 数据安全，可从容处理
- 如果有 PG degraded → 优先处理
第3步: 排查 OSD 原因 (5min)
- 是同一机架/交换机？→ 网络问题
- 是同一批次硬件？→ 批量故障
- docker logs ceph_osd.<id> → 具体错误
- 常见原因:
a) OSD 进程 crash → docker restart
b) 磁盘故障 → smartctl -a /dev/sdX
c) OSD full → 检查空间使用
d) 网络分区 → 检查交换机
第4步: 恢复 (视情况)
- 进程 crash: 重启 OSD 容器
- 磁盘故障: 标记 out，更换磁盘，重建 OSD
- 网络问题: 修复网络后 OSD 自动恢复
第5步: 后续
- 如果短时间无法恢复: ceph osd out <id>
→ 触发 rebalance，保证副本数
- 编写事故报告
- 制定预防措施评分: ★★★★★ (有条理，先评估影响再行动，考虑了多种可能原因)
C3: 数据库深入 (10min)
面试官: Nova 数据库中有 200 万条 instance 记录，性能下降，如何优化？
参考答案:
优化方案:
1. 归档 (Archive)
- nova-manage db archive --max-rows 10000
- 将已删除/过期的 instance 移到 shadow 表
- 定期执行 (cron 每周一次)
2. Cells v2
- 将集群划分为多个 Cell
- 每个 Cell 独立数据库
- 200万/5 Cell = 40万/Cell (可接受)
3. 索引优化
- 检查慢查询: slow_query_log
- 添加缺失索引: EXPLAIN 分析
- 常见需要索引的字段:
* instances.project_id
* instances.host
* instances.uuid
4. 连接池
- max_pool_size = 50 (默认5)
- max_overflow = 100
- pool_timeout = 30
5. 读写分离
- 只读查询走 replica
- 写入走 master
- 需要应用层支持
6. 分区表
- 按时间分区 instance 表
- 老数据自动归档到冷存储
7. 监控
- SHOW PROCESSLIST 定期检查
- 关注 Threads_connected 趋势
- 关注 innodb_buffer_pool_read_requests vs reads评分: ★★★★☆ (有多种方案，知道 archive 和 Cells v2 是关键)
C4: 升级策略 (10min)
面试官: 如何将生产环境的 OpenStack 从 2023.2 升级到 2024.2？
参考答案:
升级计划:
前置准备 (2周):
1. 阅读 Release Notes，确认兼容性
2. 在测试环境完整演练升级
3. 准备回滚方案 (快照 + 配置备份)
4. 通知用户维护窗口
控制节点升级 (第1天):
1. 备份: DB dump + Ceph 快照 + 配置文件
2. 更新 Kolla-Ansible 版本
3. 修改 globals.yml 版本号
4. 拉取新镜像: kolla-ansible pull
5. 滚动升级: kolla-ansible upgrade
- 先升级 1 个控制节点 (--limit ctrl-01)
- 验证健康后继续
- 逐个升级剩余控制节点
6. 数据库迁移:
- nova-manage db sync
- neutron-db-manage upgrade head
- cinder-manage db sync
计算节点升级 (第2-5天):
1. 分批升级 (每批 100 节点)
2. 每批流程:
a. disable nova-compute
b. live migrate VM 到其他节点 (可选)
c. kolla-ansible deploy --limit <batch>
d. enable nova-compute
e. 验证 VM 正常运行
3. 批次间间隔 2-4 小时观察
验证 (第6天):
1. 全量健康检查
2. 性能基线对比 (API 响应/VM 启动时间)
3. 功能回归测试
回滚方案:
- 控制节点: 恢复 DB 快照 + 重新部署旧版本
- 计算节点: 重新部署旧版本 (VM 不受影响)评分: ★★★★★ (有完整的计划、分批策略、回滚方案)
C5: 开放讨论 (10min)
面试官: OpenStack 未来会怎样？与 Kubernetes 如何共存？
参考答案:
我的观点:
OpenStack 的定位变化:
- 过去: 独立的 IaaS 平台
- 现在: 基础设施层，为 K8s 提供 VM/裸金属
- 未来: 混合云管理平台的一部分
OpenStack + K8s 共存模式:
1. OpenStack 提供基础设施 (VM/存储/网络)
K8s 运行在 OpenStack VM 上
→ 最简单，大多数企业采用
2. Magnum: OpenStack 管理 K8s 集群
→ 自动创建/销毁 K8s 集群
3. K8s 上运行 OpenStack (LOKI/Airship)
→ 用 K8s Operator 管理 OpenStack 服务
→ 新一代部署方式
4. 裸金属 + GPU 直通
→ OpenStack Ironic 管理 GPU 服务器
→ 为 AI 训练提供基础设施
OpenStack 不会被替代的原因:
- 企业有大量 VM 工作负载
- 合规要求 (数据主权、审计)
- 与公有云互补 (混合云策略)
- 成熟稳定，经过大规模验证评分: ★★★★☆ (有见解，理解 OpenStack 在新生态中的定位)
模拟面试 D — 架构师/技术负责人（6年+）
面试时长: 60分钟 | 难度: ★★★★★
D1: 技术选型 (15min)
面试官: 公司要建设私有云平台，备选方案有 OpenStack、VMware、Rancher (纯K8s)。如何选型？
参考答案:
选型矩阵:
| 维度 | OpenStack | VMware vSphere | Rancher/K8s |
|------|-----------|----------------|-------------|
| 成本 | 低 (开源) | 高 (授权) | 低 (开源) |
| VM 管理 | ★★★★★ | ★★★★★ | ★★☆☆☆ |
| 容器 | ★★★☆☆ | ★★★☆☆ | ★★★★★ |
| 运维难度 | ★★★★☆ | ★★☆☆☆ | ★★★☆☆ |
| 扩展性 | ★★★★★ | ★★★☆☆ | ★★★★☆ |
| 生态 | ★★★★☆ | ★★★★★ | ★★★★★ |
| 人才 | ★★★☆☆ | ★★★★☆ | ★★★★★ |
推荐方案: OpenStack + K8s (分层)
- OpenStack 管理基础设施 (VM/存储/网络/裸金属)
- K8s 运行在 OpenStack 上，面向应用层
- 理由:
1. 公司仍有大量 VM 工作负载 (传统应用)
2. 新业务用 K8s，但不排斥 VM
3. 成本可控 (开源)
4. 团队有 Linux/OpenStack 经验
不推荐纯 K8s 的原因:
- 传统应用 (数据库/Windows) 仍需 VM
- K8s 不擅长管理底层基础设施
- 网络隔离、合规审计仍需 VM 级别评分: ★★★★★ (有清晰的选型矩阵，推荐方案合理，能解释 why not)
D2: 成本优化 (15min)
面试官: 集群资源利用率只有 40%，如何提升利用率并降低成本？
参考答案:
成本优化方案:
1. 超分策略优化
- 分析实际负载: CPU/内存利用率热力图
- 通用业务: CPU 超分 4:1 → 6:1 (验证后提升)
- 轻负载 VM: 识别并迁移合并
- 预计提升利用率: 40% → 60%
2. 资源回收
- 清理僵尸 VM: 30天无流量自动标记
- 清理过期卷: available 状态 > 90天
- 清理未绑定浮动 IP
- 回收未使用安全组规则
3. Flavor 治理
- 分析 VM 实际使用 vs Flavor 规格
- 引导用户使用更合适的 Flavor
- 推出 burstable flavor (类似 AWS T2)
4. 调度优化
- 装箱算法 (Bin Packing): 尽量填满节点
- 反亲和策略: 仅在真正需要时使用
- 冷热分离: 高频/低频 VM 分开放
5. 容量规划
- 设置 70% 水位线告警
- 按需扩容 (而非预留大量余量)
- 使用 Spot 实例 (竞价/低优先级)
6. 技术优化
- Ceph EC (纠删码) 替代 3 副本 → 存储利用率提升 50%
- CPU pin 给高性能 VM，其余超分
预期效果: 利用率从 40% 提升到 65-70%
节省: 约 30% 硬件成本评分: ★★★★★ (方案全面，有量化目标，兼顾技术和治理)
D3: 灾难恢复 (15min)
面试官: 整个数据中心断电 4 小时，恢复后你会怎么做？
参考答案:
灾难恢复流程:
Phase 1: 电力恢复后立即检查 (1h)
1. 检查所有硬件是否正常开机
2. 检查网络交换机/存储是否正常
3. 检查 NTP 同步 (断电后时钟可能漂移)
Phase 2: 基础设施恢复 (2h)
1. 启动控制节点 (按顺序):
a. 先启动 MariaDB: 选最后关闭的节点
→ systemctl start mariadb --wsrep-new-cluster
→ 验证: wsrep_cluster_status = Primary
b. 启动 RabbitMQ: 等待集群自动形成
→ rabbitmqctl cluster_status
c. 启动 Memcached
d. 启动 HAProxy + Keepalived
e. 启动所有 OpenStack 服务
2. Ceph 集群:
a. 启动所有 MON 节点
b. 启动所有 OSD 节点
c. 等待 HEALTH_OK (可能需 rebalance)
d. 检查 PG 状态: ceph pg stat
Phase 3: 计算节点恢复 (2h)
1. 批量启动计算节点
2. nova-manage cell_v2 discover_hosts
3. 检查所有服务状态:
openstack compute service list | grep down
4. VM 恢复:
- 配置了 resume_guests_state_on_host_boot = true
- VM 会自动恢复运行
- 手动检查关键 VM 状态
Phase 4: 验证 (1h)
1. 健康检查脚本
2. 关键业务功能测试
3. API 响应时间基线对比
4. 通知业务方恢复
Phase 5: 事后总结
1. 编写事故报告
2. 分析恢复时间 (RTO)
3. 改进: UPS 配置、自动恢复脚本评分: ★★★★★ (有清晰的分阶段流程，知道 Galera 恢复要点)
D4: 团队建设 (15min)
面试官: 你如何组建和管理一个 OpenStack 运维团队？
参考答案:
团队结构 (1000 节点规模):
OpenStack 运维团队: 8-12 人
├── 架构师 (1-2人): 架构设计、技术选型、容量规划
├── 平台运维 (3-4人): 日常运维、故障处理、变更管理
├── 存储工程师 (1-2人): Ceph 运维、容量管理
├── 网络工程师 (1人): OVN/SDN、网络排障
├── 自动化/DevOps (2人): 工具开发、CI/CD
└── On-call 轮值: 7x24 响应
关键实践:
1. 知识管理: 内部 Wiki + 故障案例库
2. On-call: 分级响应 (L1→L2→L3)
3. 变更管理: 评审 → 测试 → 灰度 → 全量
4. 培训: 每周技术分享、季度外部培训
5. 演练: 季度故障演练 (Chaos Engineering)
KPI 指标:
- 集群可用性: 99.95% (年停机 < 4.4h)
- 故障恢复时间 (MTTR): < 30min
- 变更成功率: > 99%
- 工单响应时间: < 15min评分: ★★★★☆ (团队结构合理，有管理实践和量化指标)
模拟面试 E — 快速压力面（所有级别）
面试时长: 30分钟 | 难度: ★★★★☆
面试官快速连续提问，考验应变能力和知识广度
E 轮速问速答 (每题 2 分钟)
Q1: OpenStack 用 RabbitMQ 做什么？不用行不行？
答: 组件间异步通信 (RPC)。Nova-API 发消息给 Scheduler，
Scheduler 发消息给 Compute。不用也行，但需替换为
Kafka/ZeroMQ (社区有实验性支持)。Q2: 为什么 Neutron 要从 OVS 迁移到 OVN？
答: OVS agent 模式: 每节点一个 agent，千节点 = 千个 agent，
控制面压力大。OVN: 集中控制+分布转发，
性能提升 10x，运维复杂度降低。Q3: Placement API 是干什么的？为什么从 Nova 中独立出来？
答: 资源追踪与分配。记录每个节点有多少 vCPU/内存/磁盘，
谁用了多少。独立原因: 1) 多个服务都需要 (Nova/Cinder/Neutron)
2) 独立部署减少 Nova 耦合 3) 性能更好。Q4: 什么是 NUMA？OpenStack 如何利用 NUMA？
答: Non-Uniform Memory Access，CPU 访问本地内存快，
远端内存慢。OpenStack 通过 flavor extra_specs
(hw:numa_nodes, hw:cpu_policy=dedicated) 让 VM
绑定到特定 NUMA node，提升内存访问性能。Q5: SR-IOV 是什么？在 OpenStack 中怎么用？
答: Single Root I/O Virtualization，让 VM 直接访问
网卡硬件 (PF 切分为多个 VF)。性能接近裸金属。
OpenStack 通过 Neutron SR-IOV agent 管理，
flavor 指定 pci_passthrough:alias。Q6: 什么是 Ceph PG？PG 数如何计算？
答: Placement Group，数据分布的基本单位。
每个 Pool 有 N 个 PG，数据通过 CRUSH 映射到 OSD。
计算公式: PG数 = (OSD总数 × 100) / 副本数
取整到 2 的幂。太少=热点，太多=开销大。Q7: OpenStack 如何实现多站点联邦？
答: 1) Keystone Federation: 统一认证跨站点
2) Nova Cells: 跨 Cell 调度
3) Tricircle: 多站点网络互联
4) Cinder active-active: 跨站点卷复制
实际生产多数用: 每站点独立集群 + 统一认证 + DNS 调度Q8: 如何监控 OpenStack？关键指标有哪些？
答: Prometheus + Grafana + AlertManager
关键指标:
- API 响应时间 (P50/P99)
- VM 创建时间
- Nova 服务状态 (up/down)
- Neutron Agent 状态
- Ceph HEALTH
- DB 连接数 + 慢查询
- RabbitMQ 消息堆积
- 节点 CPU/内存/磁盘使用率Q9: Token 过期了怎么办？
答: 1) 自动刷新: openstackclient 自动处理
2) 过期时间: [token] expiration = 3600 (默认1小时)
3) 长时间任务: 使用 Trust 或 Application Credential
4) 服务间: Service Token 不受用户 Token 过期影响Q10: 说出 5 个 OpenStack 项目你不知道/没用过的？
答 (示例):
1. Ironic: 裸金属管理
2. Zun: 容器管理
3. Tacker: NFV 编排
4. Senlin: 集群管理
5. Vitrage: RCA (根因分析)
6. Freezer: 备份/恢复
7. Masakari: 实例 HA
8. Cyborg: 加速器管理 (GPU/FPGA)