存储扩容需按架构选择路径：lvm支持在线热扩，vsan受限于磁盘组与ftt策略，raid5扩容须重建或依赖厂商工具，分布式存储靠节点横向扩展但需关注网络与cpu瓶颈。
存储扩容不是加块硬盘就完事，而是一条从硬件到文件系统的完整链路。关键不在“能不能扩”，而在“扩得稳不稳、用得上不用得上”。不同架构下路径差异极大：LVM靠逻辑抽象实现热扩容，vSAN依赖磁盘组结构与FTT策略约束，RAID5受初始最小盘容量锁定，分布式存储则靠节点横向伸缩。选错路径，轻则空间浪费，重则业务中断。
Linux LVM在线扩容：四步走通业务零感知
适用于已部署LVM的服务器、虚拟机或云主机，目标是扩大挂载点（如/data）可用空间。
-
确认基础状态：运行
pvs、vgs、lvs和df -h，明确当前PV是否还有空闲PE、VG是否有剩余空间、LV所在文件系统类型（ext4/xfs） -
扩展底层设备：如果是云盘或虚拟磁盘（如Hyper-V的VHDX），先在宿主机侧完成扩容；物理机则需确认新硬盘已识别（
lsblk可见） -
吸收新空间：对新盘执行
pvcreate /dev/sdX，再用vgextend vg_name /dev/sdX加入卷组；若原PV已扩容，则用pvresize /dev/sdY刷新其大小 -
延伸逻辑卷与文件系统：执行
lvextend -l +100%FREE /dev/vg_name/lv_name，再根据文件系统类型运行resize2fs（ext4）或xfs_growfs（xfs）——这一步必须做，否则df看不到新增空间
vSAN纵向扩容：磁盘组是核心边界
vSAN扩容不能只看“加几块盘”，必须卡在磁盘组（Disk Group）的物理与逻辑限制里。
- 单主机上限硬约束：每台ESXi主机最多5个磁盘组；每个磁盘组限1块缓存盘+7块容量盘；缓存盘容量建议不低于该组总容量的10%
- 加盘前先判断路径：若当前磁盘组未满“1+7”，直接添加容量盘最高效；若已满且主板还有空余槽位，才考虑新建磁盘组——否则新加的盘会被vSphere标记为“未认领”
- FTT策略决定真实收益：FTT=1时，加1块2TB容量盘，vSAN实际可用仅约1TB；FTT=2时，可用进一步压缩至约0.67TB。扩容前务必用vSAN Sizer工具重新测算
- 重同步不可跳过：新加磁盘后，vSAN会自动触发数据重平衡（Resync）。可通过vSphere Client > Monitor > vSAN > Skyline Health > Resyncing Objects 查看进度，避免在重同步未完成时继续加盘
RAID5扩容陷阱：别被“换大盘”假象骗了
RAID5阵列扩容不是替换硬盘就能释放空间，其可用容量由初始最小成员盘决定。
- 逐一替换无效：3块160GB盘组成的RAID5，可用320GB；即使全换成1TB盘，控制器仍按160GB/盘计算，剩余空间被锁定不可用
- 真正可行的两种方式：一是备份全部数据→删除旧阵列→用新大容量盘重建RAID5；二是部分厂商支持在线迁移（如某些LSI卡+MegaCLI命令），但需确认控制器固件版本与文档支持
- 升级前必查兼容性：新旧硬盘型号、转速、缓存大小应尽量一致；混用SSD与HDD、或不同品牌企业级/桌面级盘，易引发降速、掉盘甚至阵列降级
分布式存储横向扩容：加节点即扩容
区别于传统存储的纵向堆叠，Ceph、vSAN、Nutanix等分布式方案通过增加节点实现容量与性能双增长。
- 节点加入即生效：新节点完成OS部署、网络配置、服务启动后，集群自动识别并分配PG（Ceph）或对象（vSAN），无需人工干预分区或迁移数据
- 容量≠立即可用：新增节点上线后，系统会启动后台数据重分布（Rebalancing），期间IO性能可能短暂下降；建议避开业务高峰时段操作
- 网络与CPU是隐性瓶颈：节点间通信依赖万兆网络，若使用千兆交换机，扩容后反而因同步流量拥塞导致整体延迟上升；同时，擦除编码（EC）模式会显著提升CPU占用，需预留资源余量
