云计算基础架构工程师”面试通关 Checklist

---

✅ 1. 能清晰解释 OpenStack 组件与通用云概念的映射

回答：

OpenStack 是 IaaS 层的开源实现，其核心组件与公有云服务存在明确映射关系：

OpenStack 组件	公有云对应服务	通用云概念
Nova	AWS EC2 / 阿里云 ECS	虚拟机生命周期管理、资源调度、热迁移
Cinder	AWS EBS / 腾讯云 CBS	块存储服务，支持快照、克隆、多后端
Neutron	AWS VPC / 阿里云 VPC	软件定义网络（SDN），支持子网、路由、安全组
Glance	AWS AMI / 阿里云镜像市场	镜像管理服务，支持 QCOW2、RAW 等格式
Ironic	AWS Bare Metal / 阿里云神龙	裸金属服务器管理，支持 PXE、IPMI、Redfish
Keystone	IAM（身份与访问管理）	认证授权中心，支持 OAuth、Federation

这种映射说明：OpenStack 不是过时技术，而是理解现代云平台设计原理的最佳实践沙盒。我在开发中不仅使用这些组件，更深入其架构，理解其抽象边界和扩展机制。

---

✅ 2. 准备 3 个以上深度优化案例（带数据）

回答：

以下是我在 OpenStack 项目中的三个典型优化案例：

案例 1：Nova 调度器性能优化（万节点集群）

• 问题：在 10,000+ 物理机集群中，虚拟机创建平均耗时 5 秒，调度成为瓶颈。

• 根因：Filter 阶段全量扫描主机状态，DB 查询压力大。

• 方案：

  • 引入 Placement 缓存层（Redis），缓存主机资源视图，TTL=2s；
  • 将 RamFilter、DiskFilter 改为异步预检；
  • 启用 分片调度，按 AZ 划分调度域。

• 结果：调度 P99 延迟从 5s 降至 800ms，API 成功率提升至 99.99%。

案例 2：Cinder Ceph RBD Driver 小文件写优化

• 问题：数据库类 workload（4KB 随机写）IOPS 仅 300，远低于物理盘能力。

• 根因：RBD 默认配置未启用缓存，且 QEMU 层未对齐 IO。

• 方案：

  • 启用 rbd cache = true + rbd client io threads = 16；
  • 在 Nova libvirt 配置中设置 io='native' + ioeventfd='on'；
  • 使用 io_uring 替代传统 aio（需 QEMU 6.0+）。

• 结果：4KB 随机写 IOPS 从 300 提升至 1100，延迟降低 60%。

案例 3：Neutron DVR 故障自愈机制

• 问题：某 compute node 宕机后，其上 floating IP 无法自动漂移，导致南北向流量中断。

• 根因：DVR 依赖 L3 agent 心跳，但无主动探测机制。

• 方案：

  • 开发 L3 Agent Watchdog：通过 OVS 流表存活检测；
  • 集成 Keepalived VRRP 实现 floating IP 快速切换；
  • 在 Conductor 层增加 网络拓扑重建任务。

• 结果：网络中断时间从 >5 分钟缩短至 <30 秒，满足 SLA 要求。

---

✅ 3. 掌握计算/存储/网络各 5 道高频题的标准答案

回答：

我已系统梳理三大领域高频问题，以下为精简版答案要点：

🔧 计算（Compute）

1. Q：Nova 如何支持 GPU 直通？
   A：通过 PCI passthrough，配置 pci.passthrough_devices，在 flavor 中指定 pci.device_spec。
2. Q：热迁移失败常见原因？
   A：存储后端不支持（如 LVM）、内存脏页率过高、NUMA 拓扑不一致。
3. Q：如何实现超分（overcommit）？
   A：在 nova.conf 中设置 cpu_allocation_ratio、ram_allocation_ratio，Placement 会据此计算可用资源。
4. Q：KVM vs QEMU 角色？
   A：KVM 提供内核级虚拟化（CPU/Memory），QEMU 提供设备模拟（磁盘/网卡）。
5. Q：如何监控 VM 性能？
   A：Ceilometer + Gnocchi（旧），或直接对接 Prometheus（通过 libvirt exporter）。

💾 存储（Storage）

1. Q：Cinder multi-attach 安全吗？
   A：仅当上层使用集群文件系统（如 GFS2）时安全，否则会导致 FS 损坏。
2. Q：快照是 Copy-on-Write 吗？
   A：取决于后端。Ceph RBD 是 CoW，LVM 是快照卷，NetApp 是 FlexClone。
3. Q：如何限制 volume IOPS？
   A：通过 QoS specs，在 cinder type 中定义 total_iops_sec，由后端（如 Ceph）或 hypervisor（如 QEMU blkio）执行。
4. Q：Cinder backup 和 snapshot 区别？
   A：Snapshot 是增量、本地、快速；Backup 是全量、可跨区域、用于灾备。
5. Q：如何加速镜像下发？
   A：Glance + P2P（如 BitTorrent）、或使用 image caching（nova-compute 本地缓存）。

🌐 网络（Networking）

1. Q：VXLAN 封装开销多少？
   A：50 字节（VXLAN 8B + UDP 8B + IP 20B + Ethernet 14B），MTU 需设为 1550+。
2. Q：Security Group 原理？
   A：Neutron 在 compute node 上生成 iptables 规则（或 OVS conntrack），实现东西向防火墙。
3. Q：DVR 和 centralized router 区别？
   A：DVR 分布式路由，东西向流量不绕行网络节点；centralized 所有流量经网络节点。
4. Q：如何排查虚拟机不通网？
   A：四层检查：OVS port → Linux bridge → iptables → namespace route。
5. Q：ML2 plugin 作用？
   A：ML2 是 Neutron 的核心插件框架，支持同时使用多种 mechanism driver（如 OVS + Linux Bridge）。

---

✅ 4. 能对比 OpenStack 与公有云（AWS/Azure）的设计差异

回答：

维度	OpenStack	公有云（以 AWS 为例）	差异本质
架构	微服务松耦合，组件可插拔	高度集成，黑盒化	开放 vs 封闭
控制面	基于 DB + MQ（同步+异步混合）	基于分布式 KV Store（如 DynamoDB）	最终一致性 vs 强一致性
扩展性	水平扩展有限（DB 成瓶颈）	无状态服务 + 分片，百万级实例	Scale-up vs Scale-out
硬件抽象	通过 Driver 适配厂商	自研 Nitro 系统统一硬件	兼容性优先 vs 性能优先
运维模型	用户自运维	全托管	责任共担 vs 全托管

关键洞察：公有云牺牲了灵活性，换取极致性能和自动化；OpenStack 牺牲了性能，换取开放性和可定制性。未来的混合云，需要两者融合——例如用 OpenStack 管理私有资源，通过 API 对接公有云。

---

✅ 5. 了解 eBPF、DPU、MicroVM 等前沿技术

回答：

我持续跟踪云基础设施前沿技术，并思考其与 OpenStack 的结合：

• eBPF：

  • 可替代 Neutron 的 iptables/OVS，实现高性能安全组和负载均衡；
  • 项目如 Cilium 已证明 eBPF 可提升网络吞吐 30%+；
  • 在 OpenStack 中，可通过 Kuryr 或自定义 Neutron plugin 集成。

• DPU（Data Processing Unit） ：

  • 将虚拟化、网络、存储卸载到 SmartNIC；
  • AWS Nitro、阿里云神龙均采用此架构；
  • 对 OpenStack 意味着：Nova Compute Agent 可轻量化，Ironic 需支持 DPU 固件管理。

• MicroVM（如 Firecracker） ：

  • 启动快（<125ms）、内存开销小（~5MB）；
  • 适用于 Serverless/FaaS 场景；
  • OpenStack 社区已有 Zun 和 Shaken Fist 项目探索集成。

我认为：OpenStack 的未来不是被取代，而是作为“混合云控制平面”，调度包括 VM、Container、MicroVM、Bare Metal 在内的异构资源。

---

✅ 6. 准备 1-2 个系统设计题的完整方案

回答：

我重点准备了以下系统设计题：

题目：设计一个支持 10 万虚拟机的高可用计算平台

方案要点：

1. 架构分层：

   • API 层：无状态，Nginx 负载均衡 + TLS 终止
   • 调度层：独立 Placement 服务（基于 Cassandra），支持资源视图缓存
   • 控制层：Conductor 集群，按租户分片，避免全局锁
   • 代理层：Compute Agent 轻量化，心跳上报 + 指令队列

2. 高可用设计：

   • 数据库：MySQL MGR（Multi-Primary）或 TiDB
   • 消息队列：RabbitMQ 镜像队列 或 Kafka
   • 自愈机制：Agent 失联 >30s 自动重建 VM

3. 性能优化：

   • 调度缓存：Redis 缓存主机状态（TTL=2s）
   • 异步操作：创建 VM 先返回 202 Accepted，后台完成
   • 资源池化：按 AZ/硬件类型划分资源池，减少调度搜索空间

4. 可观测性：

   • Prometheus + Grafana 监控调度延迟、VM 创建成功率
   • ELK 收集日志，Trace ID 贯穿 API → Conductor → Compute

此设计已在某金融客户私有云落地，稳定支撑 8 万 VM。

---

✅ 总结

通过以上六项准备，我不仅能展示 扎实的 OpenStack 工程能力，更能体现 对云计算底层原理的深刻理解 和 面向未来的架构视野。这正是云计算基础架构工程师的核心价值。

最后一句：
“我不是 OpenStack 的使用者，而是云基础设施的构建者。”