新搭 OpenStack 集群时一定会问的问题：Neutron 后端选 Linuxbridge 还是 OVS？本文是我在生产 + 测试两套集群跑了两年后的结论。

一句话答案

• 没特殊需求 → Linuxbridge：简单、稳、排查容易
• 要 SDN / DPDK / 复杂网络策略 → OVS：功能强、性能更好、但学习曲线陡
• 要分布式 router / SR-IOV / vxlan offload → OVS（或者更激进的 OVN）

对比维度

Linuxbridge 的优点（容易被低估）

1. 就是 Linux 桥：所有 Linux 网络工具直接能用，没有抽象层
2. 没有 OpenFlow flow 表：一个 vlan 一个 bridge，看一眼就懂
3. tcpdump 直接抓包：哪个 tap 卡了立刻定位
4. 重启 agent 不会断流：因为内核态的 bridge 不依赖用户态进程

我们一个生产集群跑 Linuxbridge 三年，零网络故障。

OVS 的痛点（也容易被低估）

1. flow 表难读：ovs-ofctl dump-flows br-int 出来几百条，肉眼看是看不懂的
2. ovs-vswitchd 挂了断网：进程死了所有 VM 网络断（Linuxbridge 不会）
3. 重启 ovs-vswitchd 抖动：百毫秒级丢包，搞过的都懂
4. 加 flow 不刷新可能有缓存：诡异问题

但优点真的很顶：

1. vxlan offload：网卡支持的话性能直接翻倍
2. DVR（分布式 router）：南北向流量不再走 network node
3. 细粒度 QoS / 流量镜像 / ACL：Linuxbridge 干不了

一个非常坑的事

如果你选 OVS，强烈建议直接上 OVN，别用 ML2/OVS。原因：

• ML2/OVS 是 Neutron agent 算 flow 推到 OVS，agent 挂了网络新建就停
• OVN 是控制面（ovn-northd）下发到节点的 ovn-controller，去掉了 Neutron agent
• OVN 的 logical switch / router 模型比 ML2 干净

但 OVN 切换成本不低，老集群在线切几乎不可能，规划期就要选好。

我的选型建议

切换的代价

我们做过 Linuxbridge → OVS 的迁移：

• 涉及节点：35 台 compute
• 准备时间：1 个月（包括功能测试、性能压测、回滚方案）
• 执行时间：3 个晚上的维护窗口
• 业务影响：每台节点的 VM 需要 live-migrate 走再切，单台约 30 分钟

不是不能切，是确实折腾。

教训一句话：网络后端是 OpenStack 最难切的东西，搭集群前花一天评估，比上线后花一个月迁移划算。

OpenStack 经典面试题"nova boot 失败怎么排查"，但生产环境的失败往往更狡猾，因为可能是任何子系统的错。本文是我处理过的 7 类典型根因，按发生频率排序。

0. 万能起手式

openstack server show <uuid>
openstack server event list <uuid>
openstack server event show <uuid> <req-id>

event show 里的 traceback 是定位关键，一定先看这个再去翻日志。

如果 event 信息不够，按子系统翻：

# nova-compute（最常用）
tail -200 /var/log/nova/nova-compute.log | grep -i "ERROR\|TRACE"

# nova-scheduler（调度失败 NoValidHost）
tail -200 /var/log/nova/nova-scheduler.log

# neutron-server（网络绑定失败）
tail -200 /var/log/neutron/neutron-server.log

1. NoValidHost — 调度找不到节点

最常见。可能原因：

• 资源不够：openstack hypervisor list --long 看 CPU/RAM 剩余
• 超分被打满：cpu_allocation_ratio / ram_allocation_ratio 已经被吃满
• filter 把节点排除了：AvailabilityZoneFilter / AggregateInstanceExtraSpecsFilter 经常是元凶
• PCI 设备/SR-IOV 不匹配

排查：scheduler 日志开 DEBUG，看 Filter X returned 0 hosts。

2. PortBindingFailed — 端口绑定不到节点

nova-compute.log: PortBindingFailed: Binding failed for port xxx

90% 是 OVS agent / Linuxbridge agent 在目标节点上挂了，或者 bridge_mappings 没配对：

openstack network agent list
# 重点看 alive=True / state=UP

另一个坑：vnic_type=direct（SR-IOV）但目标节点没 sriov-agent。

3. 镜像问题

• 镜像格式不对：qcow2 但 backend 是 LVM，需要转换
• 镜像 size 没设：从 Glance 拉下来还要校验，size 不对会 hang
• HTTPS 自签证书：nova-compute 拉镜像时 SSL 校验失败

排查：glance image-show <uuid> 看 checksum 和 status=active。

4. Cinder 挂卷超时

带 volume boot 的 instance 经常这里出事：

Block Device Mapping is Invalid

• iSCSI/RBD 挂载失败：去 cinder-volume.log 看
• 卷状态 error 或 creating 卡住：openstack volume show 看 attachments
• 多路径配置缺失：/etc/multipath.conf 没配

5. DHCP / metadata 拿不到

虚机起来了，但进系统后 IP 拿不到、SSH key 没注入：

• DHCP agent 死了：neutron-dhcp-agent 状态
• metadata-agent 路径不通：检查 neutron-ns-metadata-proxy 进程
• config_drive 没启用：对老镜像或者 cloud-init 没装的，建议强制 config_drive=True

6. Libvirt / Hypervisor 层

罕见但很烦：

• KVM 模块没加载（modprobe kvm_intel / kvm_amd）
• CPU model 不兼容（迁移过来的虚机，目标节点 CPU flag 不够）
• qemu-kvm 版本和 libvirt 版本不匹配

定位看 /var/log/libvirt/qemu/<instance>.log，最直接。

7. quota 满了

QuotaError: Quota exceeded for cores

简单粗暴：

openstack quota show <project>
openstack quota set --cores 200 <project>

但注意 quota 是 per-project 的，admin 看的是自己 project 的 quota，不是用户的。

我自己的 checklist

新环境出问题，按这个顺序看，95% 五分钟内定位：

1. server event show 抓 traceback
2. 看是不是调度问题（NoValidHost）→ scheduler 日志
3. 看 hypervisor 资源水位 → hypervisor list --long
4. 看 neutron agent 是不是都活着
5. 看 nova-compute 日志最近 1 分钟的 ERROR
6. 看 libvirt qemu 日志（最后兜底）

教训一句话：OpenStack 出问题 80% 在 neutron 和 scheduler，先排这两个能省 80% 的时间。

OpenStack 自带监控生态有 Ceilometer/Gnocchi/Aodh，新生代有 Prometheus exporter。怎么选？

老栈：Ceilometer 全家桶

• Ceilometer：采集
• Gnocchi：时序存储
• Aodh：告警
• Panko（已弃）：事件存储

特点：
- 深度集成 OpenStack，支持计费用例
- 配置复杂，运维难
- Gnocchi 性能瓶颈明显（大集群跑不动）

新栈：Prometheus

• openstack-exporter：抓 OpenStack API
• libvirt-exporter：抓 hypervisor
• node-exporter：抓物理机
• Alertmanager：告警
• Grafana：可视化

特点：
- 性能强、生态广
- 不支持计费场景（只看实时状态）
- 配置简单

我的选型

Prometheus 部署关键

scrape_configs:
  - job_name: 'openstack'
    static_configs:
      - targets: ['exporter-host:9180']
    scrape_interval: 60s
    scrape_timeout: 30s

  - job_name: 'libvirt'
    static_configs:
      - targets:
          - 'compute1:9177'
          - 'compute2:9177'
    scrape_interval: 30s

openstack-exporter 默认抓很多指标，scrape_interval 别小于 60s，否则把 Keystone 打挂。

必装的几个告警

groups:
- name: openstack
  rules:
  - alert: NovaComputeDown
    expr: openstack_nova_agent_state{service="nova-compute"} == 0
    for: 5m
  - alert: NeutronAgentDown
    expr: openstack_neutron_agent_state == 0
    for: 5m
  - alert: HypervisorMemoryHigh
    expr: openstack_nova_used_memory_bytes / openstack_nova_memory_bytes > 0.85
    for: 10m
  - alert: VolumeStuck
    expr: openstack_cinder_volumes{status=~"creating|deleting|error"} > 0
    for: 30m

Grafana dashboard

Grafana 官方 dashboard 库搜 "OpenStack"，推荐 ID 9701（openstack-exporter 配套）。

教训：Ceilometer 链路长（采集→存→查），任何一环挂都看不到数据；Prometheus 简单粗暴 pull，定位故障容易 10 倍。

OpenStack 一年俩版本，业内大部分集群都落后 5-10 个版本。本文讲跨 3+ 版本升级的策略。

一个个升 vs 一次跨

官方支持N→N+1 升级（如 Yoga→Zed）。跨多版本理论上不支持，实操有 3 种思路：

思路 1：逐版本升

最稳，但慢。8 个版本就要做 8 次维护窗口。

思路 2：fast-forward upgrade（FFU）

社区工具支持 4-5 个版本一次跨。Red Hat 的 director、Mirantis 的 mcp 都有 FFU 流程。

思路 3：新搭一套 + 数据迁移

最暴力但最干净。适合升级跨度太大、原集群一堆历史包袱的场景。

我推荐：思路 2（FFU）

实际流程（以 Yoga → 2024.2 为例）：

1. 准备阶段（不影响业务）

• 备份所有数据库：Keystone、Nova、Glance、Neutron、Cinder
• 备份配置文件：/etc/{keystone,nova,glance,neutron,cinder,heat}
• 导出 inventory：所有 VM、网络、卷的元数据
• 跑 release notes 检查：每个版本的 breaking change

2. 控制面升级（业务能跑）

按依赖顺序升：

Keystone → Glance → Placement → Nova → Neutron → Cinder → Heat → Horizon

每个组件：

# 1. 停服务
systemctl stop neutron-server
# 2. 升包
pip install --upgrade neutron==X.Y.Z
# 或 dnf upgrade openstack-neutron
# 3. 数据库迁移
neutron-db-manage upgrade head
# 4. 起服务
systemctl start neutron-server
# 5. 验证
openstack network list

控制面升级期间 API 不可用（5-15 分钟），但已有 VM 正常运行。

3. 数据面升级（要 live-migrate）

Nova-compute、Neutron-agent 升级要节点逐个滚动：

for node in compute1 compute2 compute3; do
    # 1. 把 VM 迁走
    openstack server migrate --live $other_node <vm>
    # 2. 节点上升级
    ssh $node 'dnf upgrade openstack-nova-compute openstack-neutron-*'
    # 3. 重启服务
    ssh $node 'systemctl restart openstack-nova-compute neutron-*-agent'
done

必看 breaking changes

跨版本升级最容易翻车的点：

• placement 从 Nova 拆出来（Stein 之后是独立服务）
• neutron ML2/OVS 转 OVN（Yoga 之后官方推 OVN）
• glance 镜像格式变化（不再支持某些老格式）
• keystone v2 API 移除（Train 之后）
• mysql 5.7 → 8.0 兼容性

回滚预案

每个组件升级前打 snapshot：

• 数据库：mysqldump 全备
• 配置：tar 整个 /etc/<service>/
• 包：记下当前版本 dnf list installed | grep openstack

回滚 = 还原包 + 还原配置 + 还原 DB。

教训：跨 3+ 版本不要赌一把成功——先在 staging 完整演练一遍，把每个组件的坑都踩出来再上生产。

新搭 OpenStack 必问：Cinder 后端选啥？本文按生产场景对比 4 种主流方案。

对比表

Ceph RBD（最常见）

[ceph]
volume_driver = cinder.volume.drivers.rbd.RBDDriver
rbd_pool = volumes
rbd_user = cinder
rbd_secret_uuid = <uuid>
rbd_flatten_volume_from_snapshot = false
rbd_max_clone_depth = 5
volume_backend_name = ceph

优点：
- VM 可以在线迁移：所有 compute 节点都能访问同一个 RBD
- 从镜像 boot 秒级：Glance 镜像也存 Ceph 时，clone 而非 copy
- 快照便宜：COW，几乎不占空间

缺点：
- 延迟比本地 LVM 高（网络往返）
- Ceph 自己也得运维

NFS

[nfs]
volume_driver = cinder.volume.drivers.nfs.NfsDriver
nfs_shares_config = /etc/cinder/nfs_shares
nfs_mount_options = vers=4.1,proto=tcp,rsize=1048576,wsize=1048576

优点：简单到不能再简单。

缺点：
- 性能受 NAS 限制，IOPS 一般
- 单 NAS 挂了所有卷不可用
- 文件锁、缓存一致性偶尔翻车

实际场景：小公司、开发测试环境、已有 NAS 设备。

iSCSI（基于商用 SAN）

[hpe-3par]
volume_driver = cinder.volume.drivers.hpe.hpe_3par_iscsi.HPE3PARISCSIDriver
hpe3par_api_url = https://<3par>:8080/api/v1
hpe3par_username = ...

优点：商用 SAN 自带高可用、压缩去重，性能强。

缺点：
- 贵
- 厂商绑定，换设备就要换驱动
- 配置每家 SAN 不一样

实际场景：传统企业、已有 SAN 投资。

LVM（本地盘）

[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
target_protocol = iscsi
target_helper = lioadm

优点：
- 性能最高（直接本地 NVMe）
- 配置最简单

缺点：
- 卷绑定到 compute 节点，VM 不能跨节点迁移
- 节点挂了卷就丢

实际场景：单节点 all-in-one、性能极致要求。

我的推荐

• 通用生产：Ceph RBD，没有之一
• 已有 SAN 投资：iSCSI，但只在那一栋楼里用
• POC / 学习：LVM 起步，玩明白了再上 Ceph

教训：千万别多种后端混用——卷迁移、备份、监控都会成倍复杂。