Linux on VMware-为什么使用分区？

在虚拟环境（在我的情况下为ESXi）中安装Linux VM时，是否有任何令人信服的理由对磁盘进行分区（使用ext4时），而不仅仅是为每个安装点添加单独的磁盘？

我唯一能看到的是，它使使用fdisk这样的磁盘上的数据是否存在变得更加容易。

另一方面，我可以看到不使用分区的一些很好的理由（显然，除了/ boot以外）。

• 扩展磁盘要容易得多。只是增加VM的磁盘大小（通常在VCenter中），然后在VM中重新扫描设备，然后在线调整文件系统大小。
• 将分区与基础LUN对齐没有更多问题。

我在这个话题上没有发现太多。我错过了重要的事情吗？

这是个有趣的问题...

我认为没有确切的答案，但是我可以提供一些历史背景，说明围绕该主题的最佳实践可能会随着时间而改变。

自2007年以来，我必须支持在各种VMware环境中以各种形式部署的数千个Linux VM。我的部署方法已经发展，并且我拥有继承和重构其他工程师构建的系统的独特（有时是不幸的）经验。

过去...

早在2007年，我的早期VMware系统就像裸机系统一样进行了分区。在VMware方面，我使用的是2GB分割的厚文件来构成VM的数据，甚至都没有考虑多个VMDK的概念，因为我很高兴虚拟化甚至可以工作！

虚拟基础架构...

在ESX 3.5和早期的ESX / ESXi 4.x发行版（2009-2011年）中，我使用的是Linux，在一般的单片Thin Provisioned VMDK文件上进行了分区。必须预先分配存储空间，这迫使我以与实际硬件类似的方式考虑Linux设计。我为操作系统创建了36GB，72GB，146GB的VMDK，对通常的/，/ boot，/ usr，/ var，/ tmp进行了分区，然后为“数据”或“增长”分区添加了另一个VMDK（无论是/主页，/ opt或特定于应用程序的内容）。同样，在这个时代，物理硬盘大小的最佳点是146GB，并且由于必须进行预分配（除非使用NFS），所以我需要对空间保持保守。

精简配置的问世

VMware 在更高版本的ESXi 4.x发行版中围绕Thin Provisioning开发了更好的功能，这改变了我开始安装新系统的方式。在5.0 / 5.1中添加了全部功能集之后，一种新型的灵活性允许进行更多创造性的设计。提醒您，这与虚拟机上不断增加的功能保持同步，即可以将多少个vCPUS和多少个RAM分配给单个VM。与过去相比，可以虚拟化更多类型的服务器和应用程序。当计算环境开始完全虚拟化时，这是正确的。

LVM太糟糕了...

在虚拟机级别上全面的热添加功能到位并普遍使用时（2011年至2012年），我已经与一家公司合作，力争以不计任何代价（愚蠢的）为其客户的虚拟机维护正常运行时间。因此，这包括增加在线VMware CPU / RAM以及在现有VMDK上调整LVM磁盘大小的风险。在此环境中，大多数Linux系统都是单个VMDK设置，在LVM上带有ext3分区。这很糟糕，因为LVM层增加了操作的复杂性和不必要的风险。例如，/ usr中的空间不足可能导致一系列错误的决定，这些错误的决定最终意味着从备份中还原系统。这部分与过程和文化相关，但仍然...

分区势利...

我借此机会尝试对此进行更改。我在Linux中有点分区标识，并认为应将文件系统分开以监视和操作需求。我也不喜欢LVM，尤其是使用VMware以及能够执行您所要求的功能的LVM。因此，我将VMDK文件的添加扩展到了可能增长的分区。如果需要，/ opt，/ var，/ home可以获取自己的虚拟机文件。那将是原始磁盘。有时，这是一种动态扩展特定较小分区的简便方法。

奥巴马医改...

随着一个引人注目的客户端的入职，我受命设计Linux VM参考模板，该模板将用于创建其极为可见的应用程序环境。应用程序的安全要求需要一套独特的安装，因此与开发人员一起尝试将非增长分区塞满一个VMDK，然后为每个具有增长潜力或有特定要求的安装添加单独的VMDK（加密，因此，最后，这些VM由5个或更多VMDK组成，但是为将来调整大小和保护数据提供了最佳的灵活性。

我今天做什么...

今天，我对Linux和传统文件系统的总体设计是在一个瘦VMDK（分区）上的OS，以及在其他任何事物上的离散VMDK。我将根据需要进行热添加。对于像ZFS这样的高级文件系统，它是一个OS的VMDK，另一个是充当ZFS zpool的VMDK，可以对其进行调整大小，并刻入其他ZFS文件系统等。

从很多方面来说，您是对的，我可以理解这一论点-但是有一个问题可能会很棘手。如果您使用资源池（但我知道我不会，那是可恶的事情），那么VM如果拥有更多磁盘，则可以获得更多的IO时间-在极端资源限制的情况下，具有两个磁盘的VM可以获得的IO资源是拥有两个磁盘的VM的两倍。一个磁盘。对您来说，这可能不是问题，但我想指出这一点。

编辑-哦，这也会使捕捉速度稍微慢一些，但这又可能不是问题。

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

增加虚拟磁盘非常容易，在实时操作系统中拾取新设备的大小相对容易（在/ sys中戳一下），实时调整ext3 / 4文件系统的大小很容易，但是似乎总是不可能的（实时进行）是调整分区大小。

您必须使用gparted或使用fdisk重写/调整分区表大小-但它始终被内核锁定，并且需要重新引导才能使内核选择新的布局（partprobe也没有这样做）。

我将许多系统迁移到LVM，调整文件系统大小成为一种轻松，几乎令人愉快的体验！

• 增加虚拟机外部的虚拟磁盘映像
• 在虚拟机中
  • 拨入/ sys以重新扫描磁盘指标（回显“ 1”> / sys / class / scsi_device // device / rescan）
  • pvresize / dev / sdX（在LVM中调整物理卷的大小）
  • lvresize --extents + 100％FREE / dev / VG / lvolXX（在LVM中调整逻辑卷的大小）
  • resize2fs（调整文件系统大小）

所有这些都可以在实时系统上安全地完成- 无需重启！

为什么没有裸盘？这让我感到紧张-我认为裸磁盘还没有被广泛接受，但是我认为我们正处于被广泛接受的边缘。btrfs邮件列表上有一个与此相关的主题：

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

但是裸磁盘只需要rescan和resize2fs。

因此，总的来说，是的，请避免使用分区表。

尽管您所写的问题是关于VMWare（ESXi）的，但我想补充一种情况，在对KVM有了相同的想法之后，我又切换回使用分区表。

事实证明，如果将LVM卷作为VM的磁盘，并在VM中创建LVM卷组而不使用分区（将整个虚拟磁盘用作PV），则该VG在主机上VM外部可见。如果将分区用作PV，则不是这种情况。

当然，这是一个极端的情况，但是如果您需要这样的设置，则值得考虑。

这样做是否更好取决于您的系统。

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

但是，单个驱动器的主要优点如下：

1. 简单性：单个驱动器具有单个文件，可以轻松分发和复制该文件。
2. 指向主机OS的提示：单个文件将被视为单个数据块，因此主机OS将知道来宾计算机访问的序列都在该文件中。只需将所有驱动器映像放在同一文件中，就可以在某些主机OS配置上实现这一点，但不一定是这种情况。

但是，多驱动器具有优势。

1. 裸机关联/手动定位：使用单个驱动器，您将被锁定到驱动器的单个裸机关联。
2. 大小限制：如果您的系统对驱动器或文件的大小有限制，则可以在非常大的系统上使用它们。
3. 只读卷可确保安全性：这是最大的优势。如果用于OS的主卷仅在VM端读取，则它具有主要的安全优势，从本质上来说，可以锁定VM内部程序的功能，使其无法编辑来宾的基本OS。使用单独的数据驱动器，您可以创建只读驱动器，可以以只读方式启动该驱动器以进行维护和更新，而无需仅使用洁净室模板数据，从而可以完全防止在服务器内部修改重要的OS目录。

还有另一种选择：在NFS卷上安装应用程序数据。您需要优秀的档案管理员（并非所有NFS实现都是相同的）。

当NFS卷填满后，展开该卷，Linux客户端将立即看到额外的空间。

您的应用程序和供应商必须支持将其数据存储在NFS上，并且您需要仔细的NAS设计，但是您需要针对虚拟化环境使用每种存储解决方案。

这种方法的另一个好处是，如果您的存储供应商具有快照/克隆技术（例如zfs或Netapp），则备份数据并创建测试/开发环境确实非常容易。

对于某些Linux发行版，仍然需要对磁盘进行分区的原因是由于存在一个引导加载程序以及所有与之配套的旧版组件，即仿真BIOS。这使得调整磁盘大小变得更加困难，并且许多磁盘最终将使用LVM或其他类似的废话。

只需在整个卷上制作一个文件系统并将其安装在上/，即可与非常自定义（或可自定义/非自定义）的Linux发行版一起使用。上一次我在Ubuntu 12.04上尝试此操作时，安装程​​序不知道如何处理它，因为它必须安装所有愚蠢的分区表。这是虚拟世界中通用分布的问题之一。

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

到目前为止尚未提及的一个原因是，在诸如Google Compute之类的某些基础架构中，磁盘IO性能随磁盘大小线性增加。换句话说，一个大分区驱动器将比多个小驱动器具有更好的IO性能。

请注意，虽然通常情况并非如此。正如Chopper3提到的，多数情况下，多个驱动器将具有更好的IO性能。最终，如果所有虚拟驱动器都映射到单个物理驱动器，则应该没有任何区别。

以我的经验，更好的方法是将1个VMDK用于OS，我通常以以下方式对其进行分区：

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

我发现8GB足以容纳/，因为我通常会安装最少的Linux发行版（〜800MB）+我需要的软件。日志也转到该分区，但是如果设置正确（logrotate一周）并运到其他地方（syslog / elasticsearch），它们通常不会给填充分区带来麻烦。

数据作为另一个VMDK添加，我通常直接在裸磁盘（例如/ dev / sdb）上格式化文件系统。这使我可以在VmWare中调整卷的大小，并直接在VM中调整卷的大小，而无需重新分区/卸载/重新启动。

我分区有两个原因：

1. 文档-我曾经有个“受过训练的” EMC管理员从我下面偷走LUN，因为它们没有文档，而且在他看来似乎是未分配的，并在深夜被分页查找突然脱机的Oracle数据库。他已经为另一个不相关的应用程序重新分配了我的LUN的另一个卷。从那时起，我对文档感到偏执。
2. 预留空间过大。借助磁盘，它可以使数据保持在较慢的磁柱上，而对于SSD，则可以延长使用寿命/ MTBF。