ZFS数据丢失场景

Question

我希望构建一个大型的ZFS (150TB+)，我希望听到人们关于硬件故障导致的数据丢失场景的经验，特别是区分只丢失了一些数据的实例与整个文件系统(如果ZFS中甚至有这样的区别)。

例如:假设vdev是由于诸如外部驱动器外壳失去电源或控制器卡故障等故障而丢失的。根据我所读到的，池应该进入错误模式，但是如果返回vdev，池应该恢复吗？还是不想？或者，如果vdev部分损坏，是否会丢失整个池、一些文件等？

如果ZIL设备失败了会发生什么？还是几个ZIL中的一个？

真正的，任何和所有的轶事或假想的场景支持深刻的技术知识是值得赞赏的！

谢谢!

更新：

因为我们是一家小企业(9个人左右)，所以我们这样做是很便宜的，但是我们产生了相当数量的成像数据。

这些数据大多是小文件，据我统计，每TB大约有500000个文件。

数据是重要的，但不重要。我们计划使用ZFS池镜像48 to“活动”数据数组(使用3年左右)，并将其余的存储部分用于“归档”数据。

池将使用NFS共享。

机架应该在一个建筑物的备用发电机线路上，我们有两个装甲运兵车UPSes，能够在满负荷时为机架供电5分钟左右。

Answer 1

设计正确的方式和您将尽量减少ZFS数据丢失的可能性。不过，你还没有解释你在泳池里储存了什么。在我的应用程序中，它主要是为VMWare VMDK服务，并在iSCSI上导出zvols。150 on并不是一个微不足道的数字，所以我会依靠一个专业人士进行缩放建议。

我从未丢失过ZFS.

的数据

我经历过其他的一切：

• 12次SSD故障(有些在L2ARC职责中)
• 多个失败的池磁盘
• 无法预测的SATA驱动器错误需要最终替换为近线SAS磁盘
• 错误配置的去重复努力的余尘
• 从安全模式恢复已损坏或故障的z池
• 坏的10 bad网口/电缆
• 频繁的操作系统崩溃
• 雷击..。

但通过所有这些，从来没有明显的数据损失。只是休息时间。对于位于此存储之上的VMWare VMDK，通常需要在事件发生后进行fsck或重新引导，但不会比任何其他服务器崩溃更糟糕。

至于ZIL设备的丢失，这取决于设计、存储的内容以及I/O和写入模式。我使用的ZIL设备相对较小(4GB-8GB)，功能类似于写缓存。有些人反映他们的热情装置。使用高端STEC SSD设备使镜像成本高得令人望而却步.我用单一的DDRDrive PCIe卡代替。计划电池/UPS的保护，并使用SSD或PCIe卡与超级电容器备份(类似于RAID控制器生物武器公约和FBWC实现)。

我的大部分经验都是关于Solaris/OpenSolaris和NexentaStor方面的。我知道人们在FreeBSD上使用ZFS，但我不知道zpool版本和其他特性有多落后。对于纯存储部署，我建议采用Nexentastor路由(并与有经验的合伙人对话)，因为它是一个目的构建的操作系统，而且在Solaris衍生工具上运行的重要部署比FreeBSD更重要。

Answer 2

我意外地在OpenSolaris的最后一个版本中覆盖了两个ZILs，这导致了整个池的不可挽回的丢失。(我犯了很大的错误！我不明白失去热情就意味着失去泳池。幸运的是，在停机时从备份中恢复。)

但是，自从151 a版本(不知道ZPool版本意味着什么)之后，这个问题就解决了。而且，我可以证明它有效。

除此之外，我在一台20 to服务器上丢失了零数据--包括由于用户错误、多个电源故障、磁盘错误管理、错误配置、多个故障磁盘等情况。尽管Solaris上的管理和配置接口在版本之间频繁而疯狂地变化，并提出了一个重要的不断变化的技能目标，但它仍然是ZFS的最佳选择。

我不仅没有丢失关于ZFS的数据(在我犯了可怕的错误之后)，而且它一直保护着我。我不再经历数据损坏--过去20年来，无论我做什么，我都会在任何服务器和工作站上困扰着我。沉默(或“相当安静”)的数据损坏已经杀死了我无数次，当数据滚出备份旋转，但实际上已成为损坏的磁盘上。或备份备份损坏版本的其他方案。这是一个大得多的问题，而不仅仅是一次以一次大的方式丢失数据，而这几乎总是被备份的。由于这个原因，我非常喜欢ZFS，也无法理解为什么校验和自动修复已经十年没有成为文件系统中的标准特性了。(诚然，真正的生死攸关的系统通常有其他确保完整性的方法，但企业数据完整性也很重要！)

告诉智者，如果你不想进入ACL-地狱，不要使用CIFS服务器内置到ZFS。用桑巴。(你说过你使用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绝对是摇滚乐。