一位同事问我为什么我们应该使用 LVM。凭借我有限的 LVM 知识,我说因为它允许您轻松调整/管理卷!
他的想法是这样的:
我们使用 ESX,并且能够增加磁盘大小。他提出了以下方案,而不是使用 LVM:
- 在 vSphere Client 中将 /dev/sdb 增加 100GB
- 回到 Linux 重新扫描 /dev/sdb: echo 1 > /sys/block/sdb/device/rescan
- 在线调整文件系统大小:resize2fs /dev/sdb
完毕。
这似乎没问题。但我不确定。与使用 LVM 相比,这种情况有什么问题?允许磁盘扩展的更好选择是什么?
答案1
当您不在虚拟环境中时,LVM 非常适合此用途。当磁盘可以从环境外部克隆和增长时,这种好处会大大减少。
答案2
我不会在 VMWare 解决方案中使用 LVM。这会产生一些开销,有点多余,并且需要重新设计您当前的系统。我认为这又回到了规划上,但在构建服务器之前,您应该对磁盘空间需求有所了解。至少使用 VMWare,添加空间非常容易,正如您所指出的那样。
我个人避免使用 LVM。也许这是一种老式的方法,或者我被 HP SmartArray RAID 控制器宠坏了,但我发现我可以根据应用程序要求和环境预测和规划磁盘利用率需求。大多数系统都有一个或两个“增长分区”,具体取决于应用程序。它可能/home
适用于多用户系统。/opt
适用于应用程序服务器。/var
适用于日志记录繁重的系统或/var/lib/pgsql
数据库服务器……需要增长的分区应该是表中的最后一个分区或其自己的硬件卷上的最后一个分区。
另请参阅:LVM 的危险和注意事项
多个分区有其用途,基于文件系统层次标准。在下面的例子中,/var
和/appdata
具有最多的活动。/appdata
设置为在必要时增长。/var
有足够的空间用于周期性日志记录活动。/usr
和/boot
不经常更改。/
可能会增长一点,但如果这成为一个问题,请在该层次结构下安装另一个文件系统。 这在各个操作系统发行版中相当一致。
Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p2 9.7G 3.4G 5.9G 37% /
/dev/cciss/c0d0p7 996M 34M 911M 4% /tmp
/dev/cciss/c0d0p6 3.0G 1023M 1.8G 37% /var
/dev/cciss/c0d0p3 5.9G 2.0G 3.6G 37% /usr
/dev/cciss/c0d0p1 99M 23M 71M 25% /boot
/dev/cciss/c0d0p8 79G 6.5G 73G 9% /appdata
tmpfs 2.4G 0 2.4G 0% /dev/shm
答案3
LVM 的另一种情况,即使在虚拟主机上:它也允许您跨多个磁盘或磁盘组扩展文件系统。
假设您正在运行没有 SAN 的 ESX,并且保存需要更多空间的特定 VM 的数据存储区中的空间不足;如果您添加更多物理磁盘,它们通常会创建新的数据存储区,您可以将虚拟磁盘添加到其中;这些虚拟磁盘可以作为新的物理卷添加到您的 LVM 卷组中。