我正在考虑一种基于 ZFS/iSCSI 的架构，用于在普通 PC 硬件的弱节点上运行 HA/横向扩展/无共享数据库平台并运行 FreeBSD 9。
它会起作用吗？可能存在哪些缺点？
建筑学
存储节点直接连接廉价的 SATA/SAS 驱动器。每个磁盘都作为单独的 iSCSI LUN 导出。请注意，此层不涉及 RAID（无论是硬件还是软件）、分区、卷管理或类似内容。每个物理磁盘只有 1 个 LUN。
数据库节点运行 ZFS。ZFS 镜像 vdev 是从 3 个 iSCSI LUN 创建的不同的存储节点。在 vdev 之上创建一个 ZFS 池，并在其中创建一个文件系统，该文件系统又支持数据库。
当磁盘或存储节点发生故障时，相应的 ZFS vdev 将继续以降级模式运行（但仍有 2 个镜像磁盘）。将为 vdev 分配一个不同的（新）磁盘来替换发生故障的磁盘或存储节点。进行 ZFS 重新同步。发生故障的存储节点或磁盘如果再次可用，则始终会完全回收。
当数据库节点发生故障时，该节点先前使用的 LUN 将被释放。启动新的数据库节点，从发生故障的数据库节点留下的 LUN 重新创建 ZFS vdev/pool。出于高可用性的原因，无需进行数据库级复制。
可能的问题
如何检测 vdev 的性能下降？每 5 秒检查一次？ZFS 是否有任何可用的通知机制？
是否有可能从组成 vdev 的现有 LUN 重新创建新池？有什么陷阱吗？
答案1
这不是对你问题的直接回答，但对于这种事情来说，更传统的架构是使用高速串行总线和鲤鱼照顾存储冗余。
基本概述（有关详细信息，请参阅链接的文档）：
机器 A（“主”）
- 配置 HAST 守护进程并为每个池成员设备创建适当的资源。
- 使用 HAST 设备，像在任何单个系统上一样创建 ZFS 镜像设备。
机器 B（“从属”）
- 配置 HAST 守护进程的方式与在主节点上的操作类似，但将其作为辅助/从属节点启动。
（HAST 将为您将所有数据从主节点镜像到从属节点）
两台机器
- 按照描述配置 CARP在 FreeBSD 手册的 HAST 文档中。
所有故障转移魔法都将为您处理。
这里最大的警告是 HAST 仅在主/从级别上工作，因此您需要为要导出的每个 LUN/LUN 集准备一对机器。
需要注意的另一件事是，您的存储架构不会像您提出的设计那样灵活：
使用 HAST，您可以放入一对机器的磁盘数量是有限的。
使用您提出的 ISCSI 网格结构，理论上您可以添加更多机器，导出更多 LUN，并根据需要进行扩展（直至网络极限）。
这种灵活性的权衡为你带来了一个经过测试、证明和记录的解决方案，任何 FreeBSD 管理员都可以开箱即用地理解（或者能够阅读手册并弄清楚）——对我来说，这是一个值得的权衡 :-)
答案2
“zpool status -x” 将输出所有池是否健康或输出不健康池的状态。如果 iSCSI LUN vdev 脱机，则运行基于该命令的脚本的 cron 作业应该可以为您提供定期发出 cron 警报的方法。
“zpool import” 应该能够从 iSCSI LUN vdevs 导入现有的 zpool。如果池未完全导出，则可能必须强制导入，但即使数据库节点发生故障导致写入中断，内部元数据也应使数据保持一致状态。