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

作为OpenStack早期（Essex及之前版本）的核心块存储组件，nova-volume采用紧耦合设计，直接集成于Nova计算模块。其架构包含三个核心组件：nova-volume服务进程、iSCSI目标服务（tgt）和LVM逻辑卷管理。这种设计在早期云环境中实现了快速部署，但存在扩展性瓶颈。

典型部署场景下，nova-volume运行在独立存储节点，通过LVM创建逻辑卷，经tgt暴露iSCSI LUN给虚拟机。与Cinder（Folsom版本引入）相比，nova-volume缺乏独立的API层和驱动框架，导致存储功能扩展需修改Nova核心代码。

二、核心工作机制解析

1. 卷创建流程

当用户通过Nova API发起卷创建请求时，流程如下：

# 简化版卷创建逻辑（nova/volume/manager.py）
def create_volume(self, context, size, name, availability_zone):
    # 1. 分配存储资源
    volume_id = self.db.volume_create(context, {'size': size})
    # 2. 调用LVM驱动创建逻辑卷
    self.driver.create_volume(volume_id, size)
    # 3. 配置iSCSI目标
    self._configure_iscsi_target(volume_id)
    # 4. 更新数据库状态
    self.db.volume_update(context, volume_id, {'status': 'available'})

驱动层通过LVMCreator类执行实际存储操作，使用lvcreate -L {size}G -n {volume_name} vg_name命令创建逻辑卷。

2. 卷挂载机制

虚拟机挂载卷时涉及三阶段通信：

1. Nova-compute请求：通过RPC调用nova-volume的attach_volume方法
2. iSCSI发现：执行iscsiadm -m discovery -t sendtargets -p {target_ip}
3. 设备映射：通过/dev/disk/by-path/ip-*:*-iscsi-*路径访问块设备

关键配置文件/etc/tgt/conf.d/nova.conf示例：

<target iqn.2010-10.org.openstack:volume-00000001>
    backing-store /dev/vg_name/lv_name
    incoming-user username password
    lun 0
</target>

3. 多节点通信协议

跨主机通信依赖RabbitMQ消息队列，采用AMQP协议传输以下关键消息：

• volume.create.start/volume.create.end
• volume.attach/volume.detach
• volume.snapshot.create

消息格式采用JSON序列化，包含操作类型、卷ID、实例UUID等字段。

三、典型问题与解决方案

1. 性能瓶颈分析

问题表现：高并发I/O场景下出现队列堆积，平均延迟超过200ms。

根因定位：

• 单tgt进程处理所有iSCSI连接，CPU占用率达95%
• LVM元数据操作成为瓶颈，lvdisplay命令执行耗时增加

优化方案：

1. 拆分tgt服务为多实例，按卷ID哈希分配
2. 升级至Cinder后启用thin-provisioning驱动
3. 调整/etc/lvm/lvm.conf中的metadata_read_only = 1参数

2. 挂载失败排查

常见错误码：

• 500 Internal Server Error：tgt服务未运行
• 404 Volume Not Found：数据库记录与实际存储不同步
• iSCSI Login Failed：CHAP认证失败

标准化排查流程：

# 1. 检查服务状态
systemctl status nova-volume tgt
# 2. 验证iSCSI目标
iscsiadm -m session -P 3
# 3. 核对数据库记录
openstack volume show <volume_id>
# 4. 检查LVM状态
lvdisplay | grep <volume_name>

3. 数据一致性风险

在非优雅关机场景下，可能出现以下问题：

• 数据库记录显示卷已卸载，但iSCSI会话仍存在
• LVM快照与实际数据不同步

预防措施：

1. 启用libvirt的disk_discard='unmap'参数
2. 定期执行vgscan --mknodes同步元数据
3. 部署分布式锁机制（需修改Nova源码）

四、向Cinder的迁移路径

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

1. 兼容性评估：

   • 检查Nova版本是否≥2012.2（Essex）
   • 验证存储后端是否支持Cinder驱动（如LVM、iSCSI）

2. 分阶段迁移：

   # 1. 安装Cinder服务
   apt-get install cinder-api cinder-scheduler cinder-volume
   # 2. 配置/etc/cinder/cinder.conf
   [DEFAULT]
   enabled_backends = lvm
   [lvm]
   volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
   # 3. 同步数据（需开发转换工具）
   python cinder-manage db sync

3. 回滚方案：

   • 保留原nova-volume服务进程
   • 通过DNS切换实现服务切换

五、最佳实践建议

1. 监控体系构建：

   • 部署Prometheus采集/proc/diskstats指标
   • 设置告警规则：iSCSI会话数 > 500或LVM延迟 > 50ms

2. 容量规划模型：

   总存储需求 = (虚拟机磁盘大小 × 1.2) × (1 + 预留空间比例)
   其中预留空间比例根据快照策略调整（通常15%-30%）

3. 安全加固措施：

   • 启用TLS加密iSCSI通信
   • 定期轮换CHAP密钥（建议每90天）
   • 限制tgt服务的网络访问（仅允许计算节点IP）

尽管nova-volume已逐渐被Cinder取代，但其设计思想仍值得研究。对于存量系统，建议制定明确的迁移时间表，同时保留关键故障处理文档。在实际运维中，应重点关注iSCSI会话管理、LVM元数据完整性和跨服务通信可靠性这三个核心维度。