跳转至

网络与存储

网络和存储是 OpenNebula 最常见的故障来源。平台只负责编排，底层交换机、Linux 网桥、VLAN、MTU、路由、存储权限和性能仍由运维人员负责。

网络模型

VM 网卡
  ↓
KVM Host 上的 Linux Bridge / Open vSwitch
  ↓
VLAN、VXLAN 或普通二层网络
  ↓
物理交换机 / 路由器 / 防火墙

Virtual Network 主要定义：

  • 使用哪个网络驱动和宿主机桥接口。
  • VLAN/VXLAN 等网络标识。
  • Address Range 中可分配的 IP 和 MAC。
  • 网关、DNS、网络掩码等 Context 信息。
  • 安全组和租户可见范围。

分配出 IP 不代表网络一定通。IP 可能只存在于平台地址池中，仍需客户机成功接收配置，底层二层网络和上游路由也必须可达。

常见网络方式

方式 特点 适用场景
Bridge VM 直接接入现有二层网络，结构直观 简单网络、已有 VLAN 规划
VLAN 用 VLAN 隔离租户或业务 交换机支持 Trunk，VLAN 数量受规划管理
VXLAN Overlay 扩展二层网络，减少物理 VLAN 依赖 多租户、跨更大规模网络；需关注 MTU 和封装路径
Open vSwitch 提供更灵活的虚拟交换和流表能力 已有 OVS 运维经验和明确集成需求

不要为了“高级”默认选 VXLAN 或 OVS。简单、可观测且团队能排障的网络通常更可靠。

网络上线检查

onevnet list
onevnet show <VNET_ID>

# 在计算节点检查
ip -br link
bridge link
bridge vlan show
ip route

按顺序确认：

  1. VNet 地址池是否还有可用 IP。
  2. VM 的 NIC 是否挂到预期网络和桥。
  3. 客户机是否收到正确 IP、掩码、网关和 DNS。
  4. Host 端 TAP 接口、Bridge、VLAN 是否正确。
  5. 交换机 Trunk、聚合、MTU 和 MAC 学习是否正常。
  6. 网关、防火墙、安全组和回程路由是否允许流量。

存储数据流

基础 Image
   ↓ 克隆/引用
System Datastore 中的 VM 运行磁盘
   ↓
KVM Host 通过本地盘、共享文件系统、LVM 或 Ceph 访问
存储方案 优点 主要代价
本地文件存储 简单、成本低、故障范围清楚 跨节点迁移与 HA 能力受限
NFS/共享文件系统 部署直观，多个 Host 可访问 服务端可能成为性能或故障瓶颈
LVM 块设备路径清晰，性能稳定 快照、共享和容量管理需额外设计
Ceph 分布式、可扩展，可提供共享块存储 网络、容量水位和恢复过程更复杂

Ceph 的完整原理、部署和运维说明参见 Ceph。

选型应优先回答：是否需要热迁移、预期 IOPS/延迟、故障域、备份方式、恢复时间和团队是否能维护该存储。

容量为什么看起来不一致

一次镜像导入或 VMware 转换可能同时占用：

  • 源 OVA/VMDK。
  • 转换工作目录中的临时文件。
  • Image Datastore 中的目标镜像。
  • VM 实例化后的 System Datastore 空间。
  • 快照、Ceph 副本或稀疏文件实际分配空间。

所以不能只看用户声明的虚拟磁盘容量。要同时监控工作目录、数据存储、底层存储池和副本开销。

存储排障顺序

  1. onedatastore show <ID> 查看平台状态、容量和驱动。
  2. onevm show <ID> 判断失败发生在传输、克隆、启动还是清理阶段。
  3. 检查 Front-end 和 Host 日志中的具体路径与驱动错误。
  4. 在底层确认挂载、权限、容量、inode、延迟和只读状态。
  5. Ceph 等分布式存储还要检查集群健康、恢复流量和容量水位。

不要直接删除数据存储里的陌生目录“释放空间”。先在 OpenNebula 对象、VM 部署记录和底层文件之间建立对应关系。

官方参考：Virtual Networks、Datastores。