我能看到的唯一一个就是它可以更容易地看到磁盘上是否存在数据,例如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,在整体的厚置备VMDK文件上正常分区.必须预先分配存储空间,这迫使我以与真实硬件类似的方式思考Linux设计.我正在为操作系统创建36GB,72GB,146GB的VMDK,对通常的/,/ boot,/ usr,/ var,/ tmp进行分区,然后为“数据”或“增长”分区添加另一个VMDK(无论是/ home,/ opt或特定于应用程序的东西).同样,在这个时代,物理硬盘大小的最佳点是146GB,并且由于预分配是必需的(除非使用NFS),我需要保守空间.
精简配置的出现
VMware在后来的ESXi 4.x版本中开发了大约Thin provisioning个更好的功能,这改变了我开始安装新系统的方式.随着5.0 / 5.1中添加的完整功能集,一种新的灵活性允许更多的创意设计.请注意,这与虚拟机的增强功能保持同步,包括多少vcpuS以及可以为单个VM提供多少RAM.与过去相比,可以虚拟化更多类型的服务器和应用程序.这是正确的,因为计算环境开始变得完全虚拟化.
LVM很糟糕……
当虚拟机级别的完全热添加功能到位且普遍(2011-2012)时,我正在与一家致力于不惜任何代价(愚蠢)维护客户虚拟机正常运行时间的公司合作.因此,这包括在线VMware cpu / RAM增加以及在现有VMDK上调整风险的LVM磁盘大小.此环境中的大多数Linux系统都是单个VMDK设置,在LVM之上具有ext3分区.这很糟糕,因为LVM层将complexity and unnecessary risk添加到操作中.例如,/ usr中的空间不足可能会导致一连串糟糕的决策,最终意味着从备份中恢复系统……这部分是与流程和文化相关的,但仍然……
分区势利……
我借此机会试图改变这一点.我是Linux中的一个分区势利者,并认为应该将文件系统分开以满足监控和操作需求.我也不喜欢LVM,尤其是VMware和能够做你所询问的事情.所以我将VMDK文件的添加扩展到了可能增长的分区.如果需要,/ opt,/ home可以获取自己的虚拟机文件.那些将是原始磁盘.有时这是一种更容易扩展特定尺寸不足的分区的方法.
奥巴马医改……
随着very high-profile client的入职,我的任务是设计Linux VM参考模板,该模板将用于创建极其可见的应用程序环境.应用程序的安全性要求需要unique set of mounts,因此与开发人员合作尝试将非增长分区塞入一个VMDK,然后为每个具有增长潜力或具有特定要求(加密,审计等)的安装添加单独的VMDK因此,最终,这些VM由5个或更多VMDK组成,但为将来调整大小和保护数据提供了最大的灵活性.
我今天做了什么……
今天,我对Linux和传统文件系统的一般设计是在一个瘦VMDK(分区)上的操作系统,以及用于其他任何事情的离散VMDK.我会根据需要加热添加.对于像ZFS这样的高级文件系统,它是操作系统的一个VMDK,另一个用作ZFS zpool的VMDK,可以调整大小,分成其他ZFS文件系统等.
