一、nova-volume历史定位与架构演变

作为OpenStack早期（Essex及之前版本）的核心块存储组件，nova-volume承担着虚拟机磁盘（Volume）的生命周期管理职责。其设计初衷是为Nova计算节点提供持久化存储支持，采用”计算-存储耦合”架构，通过iSCSI协议实现卷的挂载与访问。

1.1 组件构成与通信模型

nova-volume服务由三部分构成：

• API服务：接收来自Nova-API的卷操作请求（创建/删除/挂载）
• 调度器：基于Filter-Scheduler算法选择后端存储节点
• 存储驱动：支持LVM、iSCSI、Sheepdog等多种后端

通信流程示例（创建卷）：

# Nova-API接收请求后调用nova-volume
def create_volume(request):
    volume = objects.Volume(context=request.context,
                          size=request.size,
                          availability_zone=request.az)
    volume.create()  # 写入数据库
    scheduler.create_volume(volume_id)  # 触发调度

调度器通过RPC调用存储节点的create_volume方法，最终由具体驱动（如LVMDriver）执行物理卷创建。

1.2 与Cinder的演进关系

随着OpenStack迭代，nova-volume的局限性逐渐显现：

• 存储类型扩展困难（仅支持有限后端）
• 跨主机卷迁移能力缺失
• 与Nova强耦合导致升级复杂

Havana版本（2013年）引入独立的Cinder项目后，nova-volume被标记为”legacy”，建议新部署直接使用Cinder+LVM/Ceph方案。但仍有大量遗留系统运行该组件，理解其机制对故障排查至关重要。

二、核心工作机制深度解析

2.1 卷创建全流程

以LVM后端为例，完整流程包含7个关键步骤：

1. 参数验证：检查配额、AZ有效性
2. 数据库写入：创建Volume记录（状态为creating）
3. 调度决策：应用AvailabilityZoneFilter、CapacityFilter
4. 物理卷分配：

   # 伪代码表示的LVM操作
   lvcreate -L ${size}G -n volume-${id} vg_nova

5. iSCSI目标配置：通过targetcli创建LUN
6. 元数据更新：记录iSCSI IQN与LVM路径映射
7. 状态变更：Volume状态转为available

2.2 卷挂载与虚拟机集成

当Nova发起attach_volume请求时，nova-volume执行：

1. 验证卷状态（必须为available）
2. 通过libvirt的storage_pool接口创建磁盘映射
3. 更新虚拟机XML配置：

   <disk type='network'>
     <driver name='qemu' type='raw' cache='none'/>
     <source protocol='iscsi' name='iqn.2010-10.org.openstack:volume-00000001'/>
     <target dev='vda' bus='virtio'/>
   </disk>

4. 触发虚拟机热插拔（需QEMU 1.1+支持）

2.3 快照与克隆实现

nova-volume的快照机制基于LVM的lvcreate --snapshot，关键限制包括：

• 快照期间卷必须处于in-use状态
• 仅支持同一存储池内的克隆
• 性能影响：写操作会被延迟至快照完成

三、常见问题与解决方案

3.1 性能瓶颈分析

典型场景：高并发IO导致iSCSI超时

• 原因：单targetcli进程处理所有连接，CPU成为瓶颈
• 优化方案：

  # /etc/tgt/targets.conf 配置示例
  include /etc/tgt/conf.d/*.conf
  default-driver iscsi
  incoming_user <username> <password>

  拆分大容量卷到多个iSCSI目标，或升级至Cinder的多后端架构。

3.2 兼容性问题

现象：Ubuntu 14.04+系统卷挂载失败

• 根源：Linux 3.13+内核的iSCSI多路径变更
• 修复步骤：
  1. 安装open-iscsi最新版
  2. 修改/etc/iscsi/iscsid.conf：

     node.startup = automatic
     node.session.timeo.replacement_timeout = 20

  3. 重启iscsid服务并重新发现目标

3.3 故障排查方法论

案例：卷状态卡在”attaching”

1. 日志定位：

   grep "volume-00000001" /var/log/nova/nova-volume.log

2. 进程检查：

   ps aux | grep tgtd
   netstat -tulnp | grep 3260

3. 常见原因：
   • 防火墙阻止3260端口
   • LVM卷标签损坏（需vgscan --mknodes）
   • Nova与Cinder版本不匹配（若已迁移）

四、迁移至Cinder的最佳实践

对于仍运行nova-volume的环境，建议按以下步骤迁移：

1. 数据备份：

   vgs --separator : -o vg_name,lv_name,lv_path | grep volume-

2. 并行运行测试：
   • 部署Cinder服务（使用LVM驱动）
   • 创建测试卷并验证功能
3. 渐进式迁移：

   # 伪代码：批量迁移脚本框架
   for volume in db.volume_get_all():
       if volume.status == 'available':
           cinder_volume = cinder.volumes.create(
               size=volume.size,
               source_volid=volume.id)  # 若支持卷克隆
           nova.volumes.delete(volume.id)

4. 监控切换：将原有Nova-Volume监控指标（如nova-volume.api.local_gb_used）替换为Cinder对应指标。

五、技术选型建议

尽管nova-volume已属遗留技术，但在特定场景仍有应用价值：

• 适用场景：
  • 小规模私有云（<50节点）
  • 仅需基础块存储功能的环境
  • 无法升级OpenStack版本的遗留系统
• 慎用场景：
  • 需要存储策略管理（如QoS、复制）
  • 计划使用Ceph/NFS等新型后端
  • 预期3年内进行云平台升级

对于新部署项目，强烈建议直接采用Cinder+LVM/Ceph方案，其模块化设计、丰富的驱动支持及活跃的社区生态能显著降低长期运维成本。

结语：理解nova-volume的工作机制不仅是技术考古，更是掌握OpenStack存储演进脉络的关键。通过分析其设计得失，我们更能体会现代云存储系统”解耦”、”弹性”、”多后端”等核心设计原则的必要性。对于仍在运行该组件的系统，建议制定明确的迁移时间表，避免技术债务累积。