50TB 卷上的 zpool 导入需要永远：它在做什么？

Question

我们有一个由两个 OpenSolaris 2009.06 NFS 服务器管理的光纤通道。

• 服务器 1 正在管理 3 个小卷（300GB 15K RPM 驱动器）。它就像一个魅力。
• 服务器 2 管理 1 个大容量的 32 个驱动器（2TB 7200 RPM 驱动器）RAID6。总大小为 50TB。
• 两台服务器都有 Zpool 版本 14 和 ZFS 版本 3。

几个月前安装了缓慢的 50TB 服务器并且运行良好。用户填满 2TB。我做了一个小实验（创建了 1000 个文件系统，每个文件系统有 24 个快照）。一切都包括创建、使用快照访问文件系统以及 NFS 挂载其中的一些。

当我尝试销毁 1000 个文件系统时，第一个 fs 花费了几分钟，然后未能报告 fs 正在使用中。我发出了系统关闭的命令，但用了 10 多分钟。我没有再等下去，关掉了电源。

现在，在引导时，OpenSolaris 挂起。32 个驱动器上的指示灯快速闪烁。我离开了它 24 小时 - 仍然闪烁，但没有任何进展。

在创建 zpool 并尝试导入 zpool 之前，我启动了一个系统快照。

pfexec zpool import bigdata

相同的情况：LED 闪烁，导入永远挂起。

跟踪“zpool import”进程只显示ioctl系统调用：

dtrace -n syscall:::entry'/pid == 31337/{ @syscalls[probefunc] = count(); }'

ioctl                          2499

有没有办法来解决这个问题？编辑：是的。将 OpenSolaris 升级到 svn_134b 就成功了：

pkg publisher # shows opensolaris.org
beadm create opensolaris-updated-on-2010-12-17
beadm mount opensolaris-updated-on-2010-12-17 /mnt
pkg -R /mnt image-update
beadm unmount opensolaris-updated-on-2010-12-17
beadm activate opensolaris-updated-on-2010-12-17
init 6

现在我有了 zfs 版本 3。Bigdata zpool 保持在版本 14。它又重新投入生产！

但是超过 24 小时（在软件升级之前）的大量 I/O 访问在做什么？

Answer 1

使用 ZFS，您真的希望让它直接操作磁盘，因为它提高了并发性。你给它的单个 50TB 磁盘是一个瓶颈。

该 DTrace 脚本仅跟踪系统调用。真正的动作发生在内核内部，如果您想查看消耗大部分 CPU 的内容，请使用 DTrace Toolkit 中的“hotkernel”脚本。

导入池时，ZFS 从磁盘读取配置并对其进行验证。导入池后，它将开始挂载您创建的所有 1000 多个文件系统和快照。这可能需要一段时间。如果您启用了重复数据删除（自从您使用 snv_111 以来您没有启用），则需要更多时间，因为它必须加载重复数据删除表 (DDT)。

关闭系统从来都不是一个好的选择，特别是在 OpenSolaris snv_111 上。您尚未发布池配置（zpool 状态），但是，如果您有 slog 设备并且它们出现故障，则您将无法导入池（最近在 Solaris 11 Express snv_151a 中已解决此问题）。

我的建议是您单独导出 32 个磁盘中的每一个并创建多个 raidz2 vdev，这样您就有更多的读/写磁头。不要用超过 8 个磁盘创建巨大的 vdev，因为性能会很糟糕。

如果您无法承受系统停机这么长时间（大多数人不会），请仔细研究 ZFS 快照以及如何使用 zfs 发送/接收将它们复制到远程服务器。这将允许您快速启动故障转移服务器。