1. 问题背景与现象分析
最近在给麒麟银河V10系统扩容时遇到了一个典型问题:通过超融合平台给虚拟机增加了60GB磁盘空间,但新增空间并未独立显示,而是合并到了原有的vda虚拟磁盘中(总容量显示为310GB)。然而通过fdisk -l查看时,发现实际可识别的分区(vda1+vda2)总和只有250GB,剩下的60GB空间处于"消失"状态。
这种情况在实际运维中并不少见,通常由以下几个原因导致:
- 虚拟磁盘扩容后未触发操作系统重新识别:虽然底层虚拟磁盘容量已增加,但操作系统内核未更新磁盘信息
- 分区表类型限制:使用传统的MBR分区表时,单个分区最大只能支持2TB,且最多4个主分区
- LVM配置问题:银河麒麟默认采用LVM逻辑卷管理,新增空间需要经过特定操作才能加入现有卷组
重要提示:操作前务必对关键数据进行完整备份!磁盘扩容操作存在一定风险,错误的操作可能导致数据丢失。
2. 磁盘空间状态诊断
2.1 确认当前磁盘布局
首先需要通过以下命令获取准确的磁盘信息:
bash复制# 查看物理磁盘信息
lsblk
fdisk -l
# 查看LVM结构
pvdisplay
vgdisplay
lvdisplay
典型输出示例:
code复制NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 310G 0 disk
├─vda1 252:1 0 200G 0 part /boot
└─vda2 252:2 0 50G 0 part
├─klas-root 253:0 0 200G 0 lvm /
└─klas-swap 253:1 0 8G 0 lvm [SWAP]
2.2 分析空间分配情况
通过对比lsblk和fdisk的输出,可以明确:
- 虚拟磁盘vda总容量:310GB
- 已分配分区:vda1(200G) + vda2(50G) = 250GB
- 未分配空间:60GB(存在于磁盘但未被任何分区使用)
3. 扩容操作全流程
3.1 方案选择与原理说明
针对这种情况,有三种可行的解决方案:
-
创建新分区并加入LVM(推荐)
- 优点:操作安全,不影响现有数据
- 缺点:需要额外步骤挂载新空间
-
扩展现有分区
- 优点:空间连续性更好
- 缺点:风险较高,需要移动分区
-
重建分区表使用GPT格式
- 优点:彻底解决问题
- 缺点:操作复杂,需全盘重分区
本文重点介绍最安全的第一种方案。
3.2 详细操作步骤
步骤1:创建新分区
bash复制# 进入fdisk交互界面
fdisk /dev/vda
# 在fdisk中按序执行:
n # 新建分区
p # 主分区
3 # 分区号(假设vda1/vda2已存在)
回车 # 使用默认起始扇区
回车 # 使用所有剩余空间
t # 修改分区类型
3 # 选择新建的分区
8e # 设置为LVM类型
w # 写入并退出
步骤2:重读分区表
bash复制# 让内核重新读取分区表
partprobe /dev/vda
# 确认新分区已创建
lsblk | grep vda3
步骤3:将新分区加入LVM
bash复制# 创建物理卷
pvcreate /dev/vda3
# 扩展卷组
vgextend klas /dev/vda3
# 扩展逻辑卷
lvextend -l +100%FREE /dev/mapper/klas-root
# 调整文件系统大小
resize2fs /dev/mapper/klas-root
操作注意:如果使用xfs文件系统,最后一步应使用
xfs_growfs /而不是resize2fs
4. 验证与问题排查
4.1 成功验证
bash复制# 检查最终空间分配
df -h | grep klas-root
# 预期输出类似:
/dev/mapper/klas-root 300G 150G 150G 50% /
4.2 常见问题解决
问题1:fdisk看不到新增空间
解决方法:
bash复制# 刷新SCSI设备
echo 1 > /sys/class/block/vda/device/rescan
# 或者重启系统
问题2:vgextend报错"Volume group not found"
解决方法:
bash复制# 先确认正确的卷组名
vgdisplay
# 如果确实不存在,需要先创建
vgcreate klas /dev/vda3
问题3:resize2fs报错"filesystem is mounted"
解决方法:
- 这是正常提示,表示正在调整已挂载的文件系统
- 如果报其他错误,应先检查文件系统类型
5. 进阶技巧与优化建议
5.1 自动化脚本方案
对于需要频繁执行扩容的环境,可以准备如下脚本:
bash复制#!/bin/bash
DEVICE="/dev/vda"
PARTNUM=$(lsblk | grep "^${DEVICE}" | wc -l)
NEWPART="${DEVICE}$((PARTNUM+1))"
# 交互式确认
read -p "Will create new partition ${NEWPART}, continue? [y/N] " confirm
[[ $confirm == [yY] ]] || exit 1
# 自动化分区
echo -e "n\np\n$((PARTNUM+1))\n\n\nt\n$((PARTNUM+1))\n8e\nw\n" | fdisk ${DEVICE}
# 后续LVM操作
pvcreate ${NEWPART}
vgextend klas ${NEWPART}
lvextend -l +100%FREE /dev/mapper/klas-root
resize2fs /dev/mapper/klas-root
5.2 性能优化建议
-
条带化设置:如果有多块磁盘,创建物理卷时可指定条带大小
bash复制
pvcreate --dataalignment 1M /dev/vda3 -
预留空间:建议保留5%空间不分配,防止性能下降
bash复制
lvextend -l +95%FREE /dev/mapper/klas-root -
在线扩容:银河麒麟支持在线扩容,但建议在业务低峰期操作
6. 替代方案对比
6.1 方案对比表
| 方案 | 复杂度 | 风险 | 停机时间 | 适用场景 |
|---|---|---|---|---|
| 新建LVM分区(本文) | 中 | 低 | 无需 | 大多数扩容场景 |
| 扩展现有分区 | 高 | 高 | 需要 | 必须连续空间的场景 |
| GPT重建分区表 | 很高 | 极高 | 需要 | MBR突破2TB限制时使用 |
6.2 选择建议
- 常规扩容:优先采用本文的LVM方案
- 必须连续空间:考虑使用
gparted等工具离线调整 - 超大磁盘(>2TB):必须转换为GPT分区表
我在实际运维中发现,90%的磁盘扩容需求都可以通过LVM方案安全解决。特别是在生产环境中,这种非破坏性的扩容方式可以最大程度保证业务连续性。