☰

VMware 卷的容量波动

tag-icon • tag-icon vmware-esxi vmware-vsphere
VMware 卷的容量波动

我们正在运行四台 ESXi 6.5.0 VMware 主机，通过 vSphere Web 客户端进行管理。

最近，我在我们的存储中添加了一个新的 VMFS 6 卷，最初创建的容量为 2TB，但在实际投入生产之前很快扩展到 3TB。从那时起，我就无法获得一致的卷容量读数。例如：一个客户系统最初在另一个卷上有一个 1700GB 的磁盘；我将其迁移到新卷，然后尝试扩大它。因此，在更改设置中，磁盘显示为 1700GB，最大大小为 2.77TB - 但是当我尝试将其设置为 2000GB 时，我收到警报“磁盘容量不足”，而且 - 瞧 - 最大大小已降至 1.86TB！这样，我设法将 1700GB 增加到 1900GB ......

在“配置”-“常规”-“容量”下检查卷信息时，有时会显示容量为 1.86TB（已分配），但有时没有任何特殊情况，它会显示 2.77TB（已分配 1.86TB）。有时显示较低的容量，单击“更新容量”不会有任何变化。

在“设备支持”下，它显示 2.77TB（据我所知没有波动？）。

在“监视”-“性能”-“概览”下，我有时会看到 2.77，有时还会看到 1.86TB。

等等 ...

四台主机中的每一台都正确显示该卷为 LUN 10 = 2.77TB。

奇怪的是，该卷的事件日志显示了几个条目“容量...从 2047894093824 字节扩大到 3047816167424 字节”。更具体地说，我在 2019-07-05 11:44:16 发生了“卷创建”事件，在 2019-07-05 13:33:44、2019-07-05 13:37:04、2019-07-05 15:23:28、2019-07-05 15:53:40、2019-07-05 16:23:41、2019-07-05 17:19:30、2019-07-10 07:58:05、2019-07-10 09:58:01 发生了“容量扩展”事件。到现在为止已经有八次了，远远超过例如每个主机一次，并且大部分（但不完全）与我打开 vsphere 的时间相关，总而言之，我无法真正解释。

问题：

  • 观察到的这些波动可能由什么原因造成？
  • 如何才能修复？
  • 一旦修补好了，我怎么能确定它已经修补好了永久（我不想扩展磁盘然后在随机时刻被告知磁盘的某些部分不“存在”）？

答案1

我有一些想法，但我无法确认它们是否确实是你所看到的：

  1. 您在每个系统上运行的是哪个版本的 VMFS？旧版本处理大文件（接近 2TB）的方式似乎与新版本不同。
  2. 有没有什么卷修复操作可以尝试？可能是一个或多个磁盘上的元数据已过期，当 VMware 尝试读取时会报告错误的值。
  3. 用作 VMFS 后端的单个存储有多大？它们是否足够大以容纳单个 2TB 文件？我不确定 VMFS 是否可以分发单身的跨多个节点的虚拟机磁盘。
  4. 我其实不太了解 VMFS，但我知道 ZFS 和 BTRFS（写时复制文件系统）有时无法准确告诉您磁盘上单个文件的大小，这是因为集群/inode 松弛、快照、​​元数据和其他东西在查询文件大小本身时可能不会被计算在内。使用 ZFS，您可以zfs list -o space准确地显示哪些文件用于什么用途，也许 VMFS 有一些类似的选项？

这是 VMFS 的维基百科页面，供参考，请注意，它有很多限制，特别是在旧版本中，这些限制可能与您的用例相关。https://en.wikipedia.org/wiki/VMware_VMFS

希望这可以帮助！

答案2

您的服务器可能会将内存交换到磁盘吗？ Vmware 有一个选项可以禁用此功能：https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-C0DBB2A3-4B44-45BE-927E-10EEB2EB8CBE.html

答案3

没有变化。

这取决于如何解释空间：十进制的假空间还是二十进制的真实空间。HDD 制造商以十进制列出假空间中的空间，一些程序以类似的方式读取它。

这对您来说意味着：您的假 3TB 卷实际上有 3 000 000 000 000 B，在真正的二进制空间中意味着 2.72TB。如果您想要真正的 3TB，则必须创建一个大小为 3 221 225 472 000 B 的卷。

类似地，2TB 的十进制容量实际上有 1.81TB。

您的卷 2047894093824 B 小于 2TB。这最好转换为 2 000 000 000 KB，即 1.86TB。如果您想要 2TB，请将其设置为 2199023255552 B（或者，如果对您来说更方便，则设置为 2200000000000）。

您分配的 1700GB（以 TB 为单位）大小为 1.66TB。1900G 为 1.8555TB，因此它可以起作用。

为了消除混淆，不久前官方提出以 KiB/MiB/GiB/TiB 来表示二进制真值，并以旧名称表示十进制真值，但很多人并不同意这种命名方式。

因此，如果您创建卷，请确保考虑二进制值，而不是它们的 10 基数转换。

如果您创建一个 2048GB 的​​卷，且您指定的 GB 值是二进制格式，则它实际上将正好具有 2TB，如果不是，则仍然会更少。

相关内容