ZFS 数据丢失情况

Question

我正在考虑构建一个更大的 ZFS 池（150TB+），我想听听人们关于由于硬件故障导致数据丢失情况的经验，特别是区分仅丢失一些数据的实例与整个文件系统（如果在 ZFS 中甚至有这样的区别）。

例如：假设 vdev 由于外部驱动器机箱断电或控制器卡故障等故障而丢失。从我读到的池应该进入故障模式，但如果返回 vdev 池应该恢复？或不？或者如果 vdev 部分损坏，是否会丢失整个池、某些文件等？

如果 ZIL 设备出现故障会怎样？或者只是几个 ZIL 之一？

真正感谢以深厚的技术知识为后盾的所有轶事或假设场景！

谢谢！

更新：

由于我们是一家小型企业（大约 9 人），因此我们以低廉的价格执行此操作，但我们生成了大量成像数据。

数据主要是小文件，据我统计，每 TB 大约有 50 万个文件。

数据很重要，但不是超级关键。我们计划使用 ZFS 池来镜像 48TB 的“实时”数据阵列（使用了 3 年左右），并将其余存储用于“归档”数据。

该池将使用 NFS 共享。

机架应该在建筑物备用发电机线上，我们有两个 APC UPS，能够在满载时为机架供电 5 分钟左右。

Answer 1

设计正确的方式，您将最大限度地减少 ZFS 数据丢失的机会。不过，您还没有解释要在池中存储什么。在我的应用程序中，它主要服务于 VMWare VMDK 并通过 iSCSI 导出 zvol。150TB 不是一个小数目，所以我会依靠专业人士的扩展建议。

我从来没有用 ZFS 丢失过数据。

我已经经历了一切：

• 十几个 SSD 故障（一些在L2ARC 职责中）
• 多个出现故障的池磁盘
• 需要最终更换为近线 SAS 磁盘的不可预测的 SATA 驱动器错误
• 错误配置的重复数据删除工作的后果
• 从安全模式恢复损坏或故障的 zpool
• 坏的 10GbE NIC 端口/电缆
• 频繁的操作系统崩溃
• 一个雷击...

但通过所有这些，从未有过明显的数据丢失。只是停机。对于位于此存储之上的 VMWare VMDK，在事件发生后通常需要 fsck 或重新启动，但不会比任何其他服务器崩溃更糟糕。

至于 ZIL 设备丢失，这取决于设计、您存储的内容以及您的 I/O 和写入模式。我使用的 ZIL 设备相对较小 (4GB-8GB)，功能类似于写入缓存。有些人镜像他们的 ZIL 设备。使用高端 STEC SSD 设备使得镜像成本过高。我改用单个DDRDrive PCIe 卡。规划电池/UPS 保护并使用带有超级电容器备份的 SSD 或 PCIe 卡（类似于 RAID 控制器BBWC 和 FBWC 实施）。

我的大部分经验都在 Solaris/OpenSolaris 和NexentaStor方面。我知道人们在 FreeBSD 上使用 ZFS，但我不确定 zpool 版本和其他功能落后多远。对于纯存储部署，我建议采用 Nexentastor 路线（并与有经验的合作伙伴交谈），因为它是一个专门构建的操作系统，并且在 Solaris 衍生产品上运行的关键部署比 FreeBSD 多。

Answer 2

我不小心在 OpenSolaris 的最后一个版本上覆盖了两个 ZIL，这导致整个池不可撤销地丢失。（我犯了一个非常严重的错误！我不明白失去 ZIL 意味着失去池。幸运的是，从备份中恢复了停机时间。）

从 151a 版本开始（不知道 ZPool 版本是什么意思），这个问题已经得到修复。而且，我可以证明它有效。

除此之外，我在 20 TB 服务器上丢失了零数据 - 包括由于用户错误、多次电源故障、磁盘管理不当、配置错误、大量磁盘故障等原因。即使管理和Solaris 上的配置界面在不同版本之间频繁且令人发狂地变化，并且呈现出重要的不断变化的技能目标，它仍然是 ZFS 的最佳选择。

我不仅没有丢失 ZFS 上的数据（在我犯了可怕的错误之后），而且它一直在保护我。我不再遇到数据损坏 - 在过去的 20 年里，这一直困扰着我在任何数量的服务器和工作站上，以及我所做的。当数据从备份轮换中滚出时，无声（或只是“非常安静”）数据损坏已经杀死了我很多次，但实际上已在磁盘上损坏。或备份备份损坏版本的其他情况。这是一个比一次性大量丢失数据更大的问题，无论如何，数据几乎总是被备份。出于这个原因，我只是喜欢 ZFS 并且无法理解为什么校验和和自动修复在十年内没有成为文件系统中的标准功能。（诚​​然，真正的生死攸关的系统通常有其他方式来确保完整性，

明智的说法是，如果您不想陷入 ACL 地狱，请不要使用 ZFS 内置的 CIFS 服务器。使用桑巴。（你说你虽然使用 NFS。）

我不同意 SAS 与 SATA 的论点，至少对于 ZFS 而言，SAS 总是优于 SATA 的建议。我不知道那个评论 [s] 是指盘片旋转速度、假定的可靠性、接口速度还是其他一些属性 [s]。（或者可能只是“它们成本更高，通常不被消费者使用，因此它们更优越”。最近发布的一项行业调查（我确信仍在新闻中）显示 SATA 实际上比 SAS 平均寿命更长，至少在调查的样本量很大。（这肯定让我感到震惊。）我不记得那是 SATA 的“企业”版本，还是消费者，或者什么速度 - 但根据我的丰富经验，企业和消费者模型同时失败统计显着率。（尽管消费者驱动器在发生故障时需要很长时间才能超时的问题，这在企业中绝对重要 - 但这并没有让我感到困惑，我认为它与硬件控制器更相关，它可能需要整个在这种情况下离线卷。但这不是 SAS 与 SATA 的问题，ZFS 从来没有让我失望。由于这种经验，我现在混合使用 1/3 企业和 2/3 消费者 SATA 驱动器.) 此外，如果配置正确（例如，三向镜像条纹），我没有看到这种 SATA 组合对性能造成显着影响，但是我的 IOPS 需求又很低，因此取决于您的商店有多大和典型用例，YMMV。我确实注意到，在我的用例中，每个磁盘的内置缓存大小对延迟问题的影响比盘片旋转速度更重要。

换句话说，它是一个包含多个参数的信封：成本、吞吐量、IOPS、数据类型、用户数量、管理带宽和常见用例。说 SAS 总是正确的解决方案是忽略这些因素的大量排列。

但无论哪种方式，ZFS 都绝对震撼。