![VMware、LVM 和 Linux:临时扩展卷,无需停机](https://linux22.com/image/648744/VMware%E3%80%81LVM%20%E5%92%8C%20Linux%EF%BC%9A%E4%B8%B4%E6%97%B6%E6%89%A9%E5%B1%95%E5%8D%B7%EF%BC%8C%E6%97%A0%E9%9C%80%E5%81%9C%E6%9C%BA.png)
我们的标准设置中的存储层如下:
- 操作系统之外:
- SAN 上的 LUN
- LUN 上的 VMware VMFS 卷
- VMFS 上的虚拟磁盘 (VMDK)
- 操作系统内部(Linux):
- VMDK 对应于设备上的 LVM PV(物理卷)(无分区)
- 1 PV = 1 VG = 1 LV,最终包含:
- 文件系统 (ext3)
请注意,我们这里不讨论根磁盘。
现在来回答这个问题。
有时用户需要更多卷空间暂时地。意思是:他们做完之后想把空间还给我。/他们做完之后想把空间拿回来。
一些注意事项:
- 这并不像创建指向第二个卷的符号链接那么简单,我们可以暂时创建该符号链接,以便稍后再次删除。这是因为有时我们无法提前知道确切需要的空间。此外,在这种情况下,它可能不是 100% 透明的,因为可能需要为此移动数据。所以我认为这不是一个可接受的答案。
- 我不会扩展物理卷(因为那样就需要使 VMDK 变得更大,而且你不能轻易地再次使其变小)。
- 这同样适用于文件系统。
- 因此唯一的解决方案似乎是使用 LVM 层,随意扩展和缩小它都没有问题。
- 但是:其上的文件系统只能轻松扩展,而不能缩小。
那么,有没有可能即时完成这一操作,并且不产生任何停机时间,从而完全透明呢?
答案1
这完全是一个需要更好规划的案例...也许还需要改进部署和配置过程。
VMware 上的 LVM 有点多余,特别是因为您可以动态添加/删除精简配置的 VMDK 磁盘。您已排除此功能,但这是一种有效的方法。
如果存储需求确实是动态的,那么进行 LVM 设备更改和扩展/缩小文件系统的额外风险是不值得的。这也许可以通过更好的分区来解决。