在ZFS中使用精简configuration时，如何确保不会耗尽物理磁盘空间？

原谅我，如果这似乎是一个基本的问题，但我真的不能在Google上find具体的东西，我不是一个交易的系统pipe理员。

我们正在使用具有8个磁盘的RAID Z3configuration（8 x 1.36 TB驱动器）的NexentaStor在我们的办公室build立一个SAN，并且正在configuration一切。

目前，就总磁盘空间而言，我们在SAN上有大约10.8 TB的“真实”存储，全部分配在一个zpool / zvol中。我正在考虑对zvol进行精简configuration（为了争论起见）100TB的空间来解释未来的增长。

理论上这似乎很简单：当我们接近耗尽实际的磁盘空间时，我们只是添加一些新的驱动器，它将“正常工作”：无需担心文件系统resize或停机时间。

但是，我们如何知道何时需要增加更多容量，而不是每隔几小时login到SAN，并确保我们仍然有剩余空间？

例如，这通常是通过设置一个cron作业来处理的，或者NexentaStor（或者ZFS本身）在你接近容量的时候提供警告，或者是预计你应该“知道”你在给定的空间上剩下多less空间时间，必须自己跟踪它？

如果有帮助，10.8 TB zvol将用作我们的虚拟服务器和testing虚拟机（也是精简configuration）的后备存储（通过iSCSI），所以我看到的部分问题是可以很容易地运行如果我们不断地创build/快照/恢复虚拟机（当testing不同的机器configuration和软件环境时，我们做了很多工作），磁盘空间不足。

在Nexenta方面，有一个volume-check脚本，默认设置为每小时运行一次。它会：
Check volume health and capacity, clear correctable device errors, validate mountpoints.
它还通过电子邮件发送每周总结报告。

但是，在为您列出的目的规划Nexenta存储解决scheme时，您应该考虑一些事项。

您可能需要考虑拥有多个灵活性池。一个池可以工作，但有时需要移动数据，或者只需在本地存储上select第二个池。
ZFS zvols可以随时扩展/收缩。例如，如果将20TB分配给精简configuration的zvol，则可以非常轻松地将其更改为30TB或100TB。如果您目前没有这个function，您不需要为将来提供超过100TB的资源。
使用精简configuration的zvols，一旦使用了空间，就不能回收它。如果在10TB池中精简configuration2TB zvol，填充zvol，然后删除该zvol上的虚拟机，则池仍然只显示8TB空闲。 2TB将保持。
你会使用ZFS压缩还是重复数据删除？一种情况是，如果您使用内联压缩和高度可压缩的数据，那么过度configuration是有意义的。相同的数据被删除。在我的情况下，我使用的数据集压缩了60％-80％，所以我提供了比实际存储量更大的zvols。
使用镜像与raidz1 / 2/3可以更容易地扩展底层存储。您可以将镜像磁盘对添加到zpool，但是除非添加另一个vdev（raidz（x）磁盘组），否则不能展开raidz1 / 2/3。您还需要重新平衡内部的数据以在磁盘之间重新分配。
你将使用哪种虚拟化技术？如果VMWare，你可以精简configuration。我相信你会看到数据库警告接近80％的利用率。如果你处于快照大小增长的危险境地，VMware也会抱怨。
如果您正在进行大量虚拟机testing，或者虚拟机的大小有所波动，build议您使用iSCSI和zvols作为testing虚拟机的相对静态的虚拟机和NFS（如果这是您首选虚拟化解决scheme的选项）。使用NFS，您可以更有效地使用存储空间，因为您看到zpool的全部可用大小，并且没有任何大小上限值得担心。

总之…我不会为了未来的增长而过度提供服务。这不是必需的。 Nexenta每小时检查一次以提醒空间利用率。还要考虑是否使用压缩（重复数据删除需要更多的计划）。 testing一下，看看虚拟机足迹在投入生产之前的样子。事后改变将更加困难。

如果您有像Nagios这样的监控系统，您可以轻松地编写一个评估zpool list输出的检查，并根据您的舒适区域内的阈值进行检查。

如果您没有监控系统，则应该利用这个机会来安装一个 – 如果您不希望由于磁盘有缺陷而导致停机或数据丢失，SAN需要持续监控的基础设施设备的关键部分，空间不足的情况，硬件故障或连接问题。

只是要提到，如果你使用RAID-Z，你可能不会轻易地为任何RAID-Z“添加更多的驱动器”。