如果这看起来像一个基本问题，请原谅我，但我真的无法在 Google 上找到任何具体的内容，而且我并不是一名专业系统管理员。
我们正在办公室使用 NexentaStor 设置 SAN，采用 8 磁盘 RAID Z3 配置（8 x 1.36 TB 驱动器），并且正在配置一切。
目前，就总磁盘空间而言，我们在 SAN 上有大约 10.8 TB 的“实际”存储空间，全部分配在单个 zpool/zvol 中。我考虑对 zvol 进行精简配置（为了便于讨论）100 TB 的空间，以应对未来的增长。
从理论上看，这似乎很简单：当我们接近用完实际磁盘空间时，我们只需添加一些新的驱动器，它就会“正常工作”：无需担心文件系统大小调整或停机。
然而，我们如何知道当我们需要添加更多容量时，是否需要每隔几个小时登录一次 SAN 并确保仍然有可用空间？
例如，这通常是通过设置cron作业来处理的吗，或者 NexentaStor（或 ZFS 本身）在您接近容量时提供警告，或者是否应该让您“知道”在任何给定时间您还剩下多少空间并且必须自己跟踪它？
如果有帮助的话，10.8 TB zvol 将用作我们的虚拟服务器和测试虚拟机（也是精简配置的）的后备存储（通过 iSCSI），所以我看到的部分问题是如果我们不断创建/快照/恢复虚拟机（在测试不同的机器配置和软件环境时我们会做很多这样的工作），很容易耗尽磁盘空间。
答案1
在 Nexenta 方面，有一个volume-check默认设置为每小时运行一次的脚本。它将：
Check volume health and capacity, clear correctable device errors, validate mountpoints.
它还会通过电子邮件发送每周摘要报告。
但是，在为您列出的目的规划 Nexenta 存储解决方案时，您应该考虑一些事项。
- 您可能要考虑使用多个池以实现灵活性。单个池是可行的，但有时需要移动数据，或者只是选择在本地存储上使用第二个池。
- ZFS zvols 可以随时扩展/收缩。例如，如果您为精简配置的 zvol 分配 20TB，则可以非常轻松地将其更改为 30TB 或 100TB。如果您目前没有 100TB，则无需为将来过度配置它。
- 对于精简配置的 zvol，一旦空间被使用，您就无法回收它。如果您在 10 TB 池中精简配置 2 TB zvol，填满 zvol，然后删除该 zvol 上的虚拟机，您的池仍将只显示 8 TB 可用空间。那 2 TB 将保留。
- 您会使用 ZFS 压缩或重复数据删除还是两者兼而有之？如果您使用内联压缩和高度可压缩的数据，那么过度配置确实有意义。对于重复数据删除的数据也是如此。就我而言，我使用的数据集压缩率为 60%-80%，因此我提供的 zvols 比我实际拥有的存储量要大。
- 使用镜像而不是 raidz1/2/3 可以更轻松地扩展底层存储。您可以将镜像磁盘对添加到 zpool，但除非添加另一个 vdev（raidz(x) 磁盘组），否则无法扩展 raidz1/2/3。您还需要重新平衡其中的数据以在磁盘之间重新分配。
- 您将使用哪种虚拟化技术？如果是 VMWare，您可以进行精简配置。我相信，您将看到数据存储区利用率接近 80% 的警告。如果您处于快照大小增长的危险情况，VMware 也会发出警告。
- 如果您正在进行大量虚拟机测试，或者虚拟机的大小会波动，我建议对相对静态的虚拟机使用 iSCSI 和 zvols，对测试虚拟机使用 NFS（如果这是您首选的虚拟化解决方案的选项）。使用 NFS，您可以更有效地利用存储空间，因为您可以看到 zpool 的全部可用大小，而不必担心任何大小上限。
简而言之...我不会为了应对未来的增长而过度配置。这没有必要。Nexenta 每小时都会进行一次检查，以提醒空间利用率。还要考虑是否使用压缩（重复数据删除需要更多的规划）。在投入生产之前，先测试一下，看看虚拟机占用空间会是什么样子。事后更改会更加困难。
答案2
如果您有像 Nagios 这样的监控系统，您可以轻松地编写检查来评估输出zpool list并根据您的舒适区域内的阈值进行检查。
如果您没有监控系统，您应该利用这个机会安装一个 - SAN 是基础设施设备的关键部分，如果您不想由于磁盘缺陷、空间不足、硬件故障或连接问题而导致停机或数据丢失，则需要对其进行持续监控。
答案3
需要指出的是，如果您使用 RAID-Z，您可能无法轻松地为任何 RAID-Z“添加更多驱动器”。