服务器与大带宽专家 · 持牌IDC/CDN/ISP服务商
简米科技官网JIANMI TECH
资讯 2026-10-13 更新于 2026-10-13 简米科技 4,342 字 10 分钟阅读

虚拟机卷组如何实现跨主机动态扩容与高可用?卷组高可用怎么扩容

导读虚拟机卷组跨主机动态扩容怎么做?答案其实不复杂:把卷组底层的数据盘放到宿主机共享的块存储上,借助集群卷组管理工具统一调度,扩容动作就能从一台宿主机延伸到整个集群,设想一个常见场景:你维护着一套MySQL集群,三台宿主机各自启动一台数据库虚拟机,数据却只存在其中一台的本地盘上,哪天磁盘满了,你立刻发现本地卷组只能……

虚拟机卷组跨主机动态扩容怎么做?答案其实不复杂:把卷组底层的数据盘放到宿主机共享的块存储上,借助集群卷组管理工具统一调度,扩容动作就能从一台宿主机延伸到整个集群。

设想一个常见场景:你维护着一套MySQL集群,三台宿主机各自启动一台数据库虚拟机,数据却只存在其中一台的本地盘上,哪天磁盘满了,你立刻发现本地卷组只能在那台机器内部做vgextend,别的宿主机根本看不见这块盘这就是虚拟机卷组跨主机扩容的痛点,要实现跨主机管理,得先从卷组的底层机制说起。

虚拟机卷组跨主机动态扩容怎么做:核心在共享块设备

先回顾一下LVM的基本结构,物理卷(PV)划出卷组(VG),卷组切成逻辑卷(LV),最终挂载到虚拟机内部使用,每台宿主机上的PV设备都有自己的元数据区域,记录了这个VG的完整成员信息,单机环境下,VG元数据只被本机内核访问,不需要和别人商量,所以一切动作都由本地LVM工具包办。

可一旦把VG放到多台宿主机面前,问题就来了:元数据本身没有分布式锁,A机器在改VG的同时B机器也在改,两边对写入的理解不一致,卷组结构直接损坏。 这也是为什么纯粹在虚拟机内部做分区扩盘,永远无法实现真正意义上的跨主机卷组管理,你扩的只是文件系统,卷组归属权还在原来那台宿主机上。

解决思路也很直接:让VG的元数据和锁管理支持多节点并发访问,这项能力在LVM2中已经存在多年,叫集群逻辑卷管理(CLVM),配套使用分布式锁管理器(DLM)协调各宿主机的读写,把物理磁盘从“本机独有”变成“共享块设备”,再统一注册到集群锁域,卷组就能被多台宿主机安全地共同管理。

实际操作中最常见的共享块设备有三种,对应不同的基础设施条件:

  • iSCSI SAN阵列:最经典的方式,存储侧划分LUN,宿主机通过iSCSI协议发起连接,盘符出现在本机后就可以用lvm命令操作。
  • 分布式存储(Ceph RBD等):云原生阵营的主流选择,块设备由存储集群动态提供,宿主机端映射成虚拟RBD盘,天然适合多节点并行挂载。
  • 云厂商共享块存储:公有云平台推出的多挂载类型云盘,比如简米云的共享块存储,多台ECS可以同时挂载同一个LUN,兼容CLVM。

这三种方式都能让PV在宿主机之间“见面”,但高可用程度和建设成本差别很大,选型时需要权衡。

共享存储卷组高可用方案如何选型:三种主流路子

不少运维同行问过我怎么选,这里直接给一个对比维度清晰的表格,表里的信息没有虚构数字,是基于这几年各类生产环境落地方案得出来的经验值。

虚拟机卷组如何实现跨主机动态扩容与高可用?卷组高可用怎么扩容

对比维度 iSCSI阵列 Ceph RBD 云厂商共享块存储
硬件依赖 需要额外采购存储设备,一次性投入大 依赖服务器和 SSD,成本分散在集群中 无自建硬件,按容量付费
扩容方式 存储侧分配LUN后重新映射,操作偏手工 在线扩容,自动均衡数据 控制台点选,分钟级生效
运维门槛 中等,需要熟悉存储侧命令行 较高,需掌握Ceph故障排查 低,云平台已封装好大部分操作
适合场景 传统企业已有SAN投资,改造少 私有云、容器平台、规模较大的存储池 公有云内做高可用架构的中小团队

如果预算敏感,企业又有现成的存储阵列,iSCSI方案依然是性价比最高的选择。 行业共识认为,虚拟化场景下的存储瓶颈大多不在链路而在并发锁处理,iSCSI加上合理的多路径配置,足以支撑业务高峰期的读写需求,核心在于存储设备本身的可靠性,链路方面多做冗余就没有大问题。

如果是从零搭建私有云,尤其已经在跑Kubernetes或OpenStack,Ceph RBD会好整合得多,它的优势在于存储层自带副本机制,宿主机宕机后RBD盘可以在另一台节点重新挂载,不需要存储阵列那样的双控制器切换逻辑。

云厂商共享块存储则适合不想碰底层硬件、保持部署敏捷的团队,按需扩容的弹性很舒服,但延迟通常比本地盘和自建SAN高一个量级,对性能敏感的核心数据库业务要谨慎,这类盘多数绑定区域的可用区,跨地域做双活时还得依赖上层数据库复制方案,卷组层帮不了那么多。

跨主机卷组扩容全流程实操:从iSCSI对接到底层文件系统扩展

方案定下来后,咱们把操作流程走一遍,以iSCSI共享存储为例,两台宿主机都是CentOS 7,目标是为运行中的MySQL虚拟机扩容数据卷组。

第一步:宿主机发现并登录iSCSI target

在每台宿主机上执行相同的命令:

# 在存储侧设定好LUN后,宿主机发起发现
iscsiadm -m discovery -t sendtargets -p 192.168.10.20
# 登录target,获取磁盘设备
iscsiadm -m node -T iqn.2024-08.com.example:mysql-data --login

登录后使用pvs、lvs确认新磁盘是否已被系统识别,如果看不到盘符,检查存储侧是否给两台宿主机都分配了LUN,以及网络层的存储VLAN是否连通。

虚拟机卷组如何实现跨主机动态扩容与高可用?卷组高可用怎么扩容

第二步:配置LVM全局过滤规则

这一步是跨主机环境最容易踩坑的地方,宿主机上往往挂着系统盘、数据盘、还有刚接入的共享盘,LVM默认会扫描所有块设备,一旦把宿主机本地的系统盘误识别成PV并误加入共享VG,后果是灾难性的。

编辑/etc/lvm/lvm.conf,在devices段设置严格的filter,只允许共享盘被LVM管理:

devices {
    filter = [ "a|/dev/sdb|", "r|/dev/sda|", "r|/dev/sd[c-z]|" ]
}

每台宿主机上的实际盘符可能不同,确认准确路径再写入,之后执行pvscan --cache重新建立元数据缓存。

第三步:创建PV并加入共享卷组

假设新盘识别为/dev/sdb,在其中一台宿主机上操作:

# 创建物理卷
pvcreate /dev/sdb
# 扫描确认
pvs
# 将新PV加入现有卷组(比如vg_data)
vgextend vg_data /dev/sdb
# 查看卷组新容量
vgs vg_data

这里有个关键点:PV的创建和加入动作只需要在一台宿主机上执行,但另宿主机必须能立刻看到这个变更,CLVM的锁机制会保证多节点同步元数据,如果另外一台机器的vgs输出里没更新,多半是锁服务或DLM没运行起来,用systemctl status lvmlockd排查看日志。

第四步:扩展逻辑卷并同步文件系统

卷组扩容后,把空间分配给虚拟机对应的逻辑卷:

# 为lv_mysql再增加200G空间
lvresize -L +200G /dev/vg_data/lv_mysql
# 在虚拟机内部扩展文件系统
xfs_growfs /mysql

注意,XFS文件系统只支持在线扩容不支持缩减,ext4用resize2fs。在线扩容期间不需要暂停MySQL业务,但建议先确认文件系统层支持在线扩展,不然还是得靠维护窗口来做。

生产环境卷组扩容需要停机吗:高可用收尾配置

多数情况下是不用停机的,热插拔SCSI盘、在线扩LV、在线扩文件系统,整套链路走下来业务毫无感知,但停机风险并没有完全消失,真正的隐患在于多台宿主机同时管理同一个卷组时的死锁与脑裂问题。

要解决这个问题,需要把卷组管理纳入集群框架,比较成熟的组合是Pacemaker + lvmlockd(或CMAN),Pacemaker负责任务调度和状态管理,lvmlockd提供VG级别的分布式锁,开启方式大致如下:

# 在每台宿主机启动lvmlockd
systemctl start lvmlockd
# 指定VG的锁类型为DLM
vgchange --lock-type dlm vg_data

加入锁域之后,卷组的读写权限由集群统一分配,避免了同一时刻多个节点同时修改VG元数据导致的结构损坏。

虚拟机卷组如何实现跨主机动态扩容与高可用?卷组高可用怎么扩容

高可用层面的另一个要点是fencing,业内专家指出,生产环境里最容易忽视的就是隔离机制,两台宿主机都认为对方挂了,同时接管共享卷组,就会出现双写,配置专门的隔离设备(如IPMI或SBD),确认钓死节点已经被强制下电,服务VIP及LV才允许飘移。任何宣称不需要fencing的集群方案,在真实故障面前都不够扎实。

多宿主机同时挂载同一共享VG时,还要留意磁盘路径的稳定性,iSCSI多路径配置建议用multipath将多个会话聚合为一个设备,避免重启后盘符漂移影响VG识别,每台宿主机看到的数据盘大小也应一致,差异较大的场景下,LVM元数据可能有一部分落在超过容量的区域,引发读取失败,需要回到存储侧把LUN映射统一。

卷组跨主机这件事,本质上是把单机时代的资源管理边界打破,让存储成为集群共享资源,这套机制成熟度很高,真正的复杂度在于与集群软件的衔接和存储层的可靠性,把锁打开、把fencing配好、把设备的稳定路径锚定,动态扩容和高可用就同时落地了。

Q&A:虚拟机卷组跨主机动态扩容常见问题

云主机数据盘扩容与本地卷组扩容哪个更好?

两者适用场景不同,云主机数据盘扩容走的是存储后端重新分配空间,由云平台控制面完成,操作路径短,不依赖宿主机底层命令,但灵活性受限,一般只能扩,不能跨主机迁移,本地卷组扩容完全自主可控,适合自建虚拟化环境,需要自己有共享存储和集群LVM技能,大部分业务混合使用时,先确认扩容是停留在单机增长,还是需要跨宿主机延伸后者才值得引入CLVM和共享存储这类重方案。

多台宿主机同时挂载同一块LVM卷组会不会损坏数据?

如果只是挂载而不涉及并发写入,不会损坏,但LVM卷组的元数据操作(如pvs、lvcreate、vgextend等)天然不允许并发执行,同时在两台机器上跑这些命令极易破坏元数据,启用集群锁后,LVM自己会拒绝未持有锁的节点执行修改操作,数据安全才有保障,没有集群锁的裸共享VG只建议用于只读场景,高可用生产环境务必开启锁服务。

跨主机共享VG中,虚拟机内部能直接用lvm命令扩展系统盘吗?

可以,但前提是宿主机层的卷组已经完成空间分配,虚拟机才能感知到新的逻辑卷大小,建议操作顺序为:宿主机共享VG扩LV,虚拟机内部做文件系统扩展,避免先在虚拟机里执行resize动作导致设备尺寸匹配不上,每次扩容都先跑一遍dmsetup status核验设备映射状况,减少底层状态与文件系统状态不同步的风险。

分享本文
本文为 简米科技官网 原创,已由运维技术专家审核。转载请注明来源:原文链接
售前咨询 服务热线 售后 邮箱