Linux上的VMware – 为什么使用分区?

在虚拟环境中安装Linux虚拟机(在我的情况下是ESXi)时,是否有任何令人信服的理由来分区磁盘(使用ext4时),而不是为每个安装点添加单独的磁盘?

我能看到的唯一的一点是,使用fdisk来查看磁盘上是否有数据存在,可以更容易一些。

另一方面,我可以看到一些很好的理由使用分区(显然不是/ boot)。

  • 扩展磁盘容易得多。 只是增加VM的磁盘大小(通常在VCenter中),然后重新扫描VM中的设备,然后在线调整文件系统的大小。
  • 没有更多的问题将分区与底层LUNalignment。

我在这个话题上没有find太多的东西。 我错过了重要的东西吗?

    这是个有趣的问题…

    我不认为有一个明确的答案,但是我可以给出一些历史背景,说明围绕这个主题的最佳实践可能随着时间而改变。

    自2007年以来,我不得不支持在VMware环境中以各种forms部署的成千上万的Linux虚拟机。我的部署方法已经发展,并且有其他工程师构build的系统inheritance和重构的独特( 有时是不幸的 )经验。

    过去的日子…

    早在2007年,我的早期VMware系统就像我的裸机系统一样被分区。 在VMware方面,我使用分裂的2GB的文件来组成虚拟机的数据,甚至没有考虑多个VMDK的概念,因为我很高兴虚拟化甚至可以工作!

    虚拟基础架构

    通过ESX 3.5和早期的ESX / ESXi 4.x版本(2009-2011),我使用的是Linux,正常情况下在单块configuration的VMDK文件上进行了分区。 不得不预先分配存储空间,迫使我以类似于使用真实硬件的方式来考虑Linuxdevise。 我为操作系统创build了36GB,72GB,146GB的VMDK,对通常的/,/ boot,/ usr,/ var,/ tmp进行了分区,然后为“data”或“growth”分区添加了另一个VMDK(无论是/主页,/ opt或特定应用程序)。 同样,在这个时代,物理硬盘大小的甜点是146GB,由于预分配是一个要求(除非使用NFS),我需要保持空间。

    自动精简configuration的出现

    在后来的ESXi 4.x版本中,VMware围绕精简configuration开发了更好的function,这改变了我开始安装新系统的方式。 随着5.0 / 5.1中增加了完整的function集,新的灵活性允许更多的创意devise。 请注意,这与虚拟机上增加的function保持同步,就多less个vCPUS和多lessRAM可以提交给单独的虚拟机而言。 更多types的服务器和应用程序可以比以前更虚拟化。 这是正确的,因为计算环境开始变得完全虚拟。

    LVM很糟糕…

    当虚拟机层面的全部热添加function已经到位和普遍(2011-2012)的时候,我正在和一家公司合作,不惜一切代价( 愚蠢 )努力维护客户虚拟机的正常运行时间。 所以这包括在线的VMware CPU / RAM增加以及在现有VMDK上调整风险的 LVM磁盘。 此环境中的大多数Linux系统都是在LVM之上使用ext3分区的单个VMDK设置。 这很糟糕,因为LVM层增加了操作的复杂性和不必要的风险 。 例如,在/ usr空间不足,可能会导致一连串的错误决定,最终意味着从备份中恢复系统…这部分是与进程和文化相关的,但仍然…

    分区势利

    我借此机会尝试改变这一点。 我在Linux中是一个分区snob ,觉得文件系统应该分开监视和操作需求。 我也不喜欢LVM,特别是在VMware和能够做你所问的。 所以我扩大了VMDK文件的添加到可能增长的分区。 / opt,/ var,/ home可以根据需要获取自己的虚拟机文件。 而那些将是原始磁盘。 有时候这是一个更简单的方法来扩展特定的小型分区。

    奥巴马医改……

    随着一个非常高调的客户端的入门,我的任务是deviseLinux VM参考模板,这个模板将被用来创build他们非常明显的应用程序环境。 应用程序的安全需求需要一套独特的装载机 ,与开发人员合作,试图将非增长分区塞进一个VMDK,然后为每个具有增长潜力或具有特定需求的装载(encryption,审计等)。最后,这些虚拟机由5个或更多VMDK组成,但为将来的数据调整和保护提供了最佳的灵活性。

    我今天做了什么…

    今天,我对Linux和传统文件系统的总体devise是在一个瘦VMDK(分区)上的操作系统,以及其他任何独立的VMDK。 我会根据需要进行热添加。 对于像ZFS这样的高级文件系统,它是一个用于操作系统的VMDK,另一个用作ZFS zpool的VMDK,可以resize,刻入额外的ZFS文件系统等等。

    你说得很对,我可以看到这个说法 – 但是有一个问题可能会很棘手。 如果你使用资源池(而且我知道我不这样做,可恶的东西),那么如果虚拟机有更多的磁盘,虚拟机可以获得更多的IO时间 – 在极端资源受限的情况下,具有两个磁盘的虚拟机可以获得两倍的IO资源一个单一的磁盘。 这可能不是你的问题,但我想我会指出。

    编辑 – 哦,它会使捕捉稍微慢一点,但是,这可能不是一个问题。

    当我在一家特定的“大型虚拟化软件公司”从事基础架构工作时,我们经常需要增加虚拟机文件系统的大小。 我们当时使用了ext3 / 4。

    增加虚拟磁盘非常容易,在现场操作系统中拾取新设备的大小相对容易一些(在/ sys中),调整ext3 / 4文件系统的容量是很容易的,但总是不可能的调整分区大小。

    您必须使用fdisk使用gparted或重写/调整分区表 – 但它始终被内核locking,并需要重新启动才能使内核获取新的布局(partprobe也没有这样做)。

    我将很多系统移动到LVM,调整文件系统的大小成为一个简单而愉快的体验!

    • 增加虚拟机外部的虚拟磁盘映像
    • 在VM中,
      • 拨号/系统重新扫描磁盘指标(echo“1”> / sys / class / scsi_device //设备/重新扫描)
      • pvresize / dev / sdX(调整LVM中的物理卷大小)
      • lvresize –extents + 100%FREE / dev / VG / lvolXX(调整LVM中的逻辑卷大小)
      • resize2fs(调整文件系统的大小)

    所有这些都可以在现场系统上安全地完成, 而且不需要重新启动!

    为什么不是裸盘? 这让我感到紧张 – 我不觉得裸盘已被广泛接受,但我认为我们正在接受更广泛的边缘。 btrfs邮件列表上有一个与此相关的线程:

    http://www.spinics.net/lists/linux-btrfs/msg24730.html

    但是一个裸磁盘只需要重新扫描和resize2fs。

    所以,总之,是的,如果可以的话,避免分区表。

    虽然你写的问题是关于VMWare(ESXi)的,但我想添加一种情况,在KVM上有相同的想法之后,我切换回使用分区表。

    事实certificate,如果您将LVM卷用作虚拟机的磁盘,并在不使用分区的情况下在虚拟机内创build一个LVM卷组(将整个虚拟磁盘用作PV),则此虚拟机将在主机上的虚拟机之外可见。 如果您使用分区作为PV,则情况并非如此。

    诚然,这是一个angular落的情况,但值得考虑,如果你需要这样的设置。

    是否最好做这个取决于你的系统。

    每个设置都有优点和缺点。

    但是,单个驱动器的主要优点如下:

    1. 简单性:单个驱动器具有单个文件,可以轻松分发和复制。
    2. 提示到主机操作系统:单个文件将被视为单个数据块,因此主机操作系统将知道访客机访问的序列将全部位于该文件中。 这可以在一些主机操作系统configuration上实现,只需将所有驱动器映像放在同一个文件中,但不一定是这样。

    但是,多驱动器是有优势的。

    1. 裸机亲和/手动位置:使用单个驱动器时,您被locking到驱动器的单个裸机关联。
    2. 大小限制:如果您的系统对驱动器大小或文件有限制,您可以在非常大的系统上使用它们。
    3. 只读卷的安全性:这是最大的优势。 如果您的操作系统主卷仅在虚拟机一侧读取,则它提供了主要的安全优势,实质上locking了虚拟机内的程序编辑客户机的基本操作系统的能力。 使用单独的数据驱动器,您可以创build只读驱动器,可以启动读写进行维护和更新,而不需要洁净室模板数据,从而防止从服务器内部完全修改重要的OS目录。

    还有另一种select:在NFS卷上挂载应用程序数据。 你需要很好的文件pipe理器(并不是所有的NFS实现都是一样的)。

    当NFS卷填满时,扩大卷,Linux客户端将立即看到额外的空间。

    您的应用程序和供应商必须支持NFS上的数据,并且您需要谨慎的NASdevise,但是您需要为虚拟化环境提供每种存储解决scheme。

    这种方法的另一个好处是,如果您的存储供应商拥有支持数据的快照/克隆技术(如zfs或Netapp),创buildtesting/开发环境非常简单。

    你仍然需要为某些Linux发行版分区的原因是因为有一个bootloader和所有的旧版本,比如模拟BIOS。 这使得调整磁盘的难度变得更大,而且很多情况下最终会使用LVM或其他类似的无意义的方式。

    可以简单地在整个卷上创build一个文件系统并将其挂载到/ ,这将与一个非常自定义的(或可定制的/非定制的)Linux发行版一起工作。 上次我在Ubuntu 12.04上试了这个,安装程序不知道如何处理它,因为它必须把他们愚蠢的分区表安装到所有的爵士乐上。 这是虚拟世界中的通用分布问题之一。

    另一方面,实际上可以将分区划分为不太传统的用途,例如ChromeOS和CoreOS有两个只读的根分区用于系统升级。

    目前尚未提及的一个原因是,在Google Compute等基础架构中, 磁盘IO性能随着磁盘大小呈线性增长 。 换句话说,一个大的分区驱动器比多个小驱动器具有更好的IO性能。

    请注意,这通常不是这种情况。 正如Chopper3所提到的,通常多个驱动器都会有更好的IO性能。 最终,如果所有虚拟驱动器都映射到单个物理驱动器,则应该没有区别。

    根据我的经验,更好的方法是使用1个VMDK用于操作系统,我通常按以下方式对其进行分区:

     /dev/sda1 - /boot - 256M /dev/sda2 - swap - ~4GB /dev/sda3 - / - ~8GB 

    我发现8GB足以满足/,因为我通常会安装最less的Linux发行版(〜800MB)+我需要的软件。 日志也会进入该分区,但是如果设置正确(logrotate一个星期),并在其他地方(syslog / elasticsearch)发货,它们通常不会造成分区填满。

    数据被添加为另一个VMDK,我通常直接通过裸磁盘格式化文件系统(例如/ dev / sdb)。 这使我可以在VmWare中调整卷的大小,并直接在VM中resize,而无需重新分区/卸载/重新引导。

    我分区有两个原因:

    1. 文档 – 我曾经有一个“训练有素”的EMCpipe理员从我的下面偷走了LUN,因为他们没有logging,似乎没有进行分配,而在深夜,却被一个Oracle数据库分页,突然下线。 他已经为另一个不相关的应用程序重新configuration了我的LUN。 从那以后,我对文件有点偏执。
    2. 超量configuration我的磁盘。 使用盘片可将数据从较慢的气瓶和SSD中分离出来,延长了使用寿命/ MTBF。