我正在考虑基于ZFS / iSCSI的架构，用于运行在普通PC硬件的Wimpy节点上并运行FreeBSD 9的HA /横向扩展/无共享数据库平台。
它会起作用吗？ 什么是可能的缺点？
build筑
存储节点直接连接廉价的SATA / SAS驱动器。 每个磁盘都作为单独的iSCSI LUN导出。 请注意，此层不涉及RAID（硬件和软件），分区，卷pipe理或类似的东西。 每个物理磁盘只有一个LUN。
数据库节点运行ZFS。 ZFS镜像vdev是通过来自3个不同存储节点的iSCSI LUN创build的。 在vdev之上创build一个ZFS池，并在该文件系统内部依次备份数据库。
当磁盘或存储节点发生故障时，相应的ZFS vdev将继续以降级模式运行（但仍有2个镜像磁盘）。 将不同的（新）磁盘分配给vdev以replace发生故障的磁盘或存储节点。 ZFS重新同步发生。 一个失败的存储节点或磁盘总是被完全回收，如果它再次可用。
当数据库节点发生故障时，该节点预先使用的LUN是空闲的。 引导新的数据库节点，从失败的数据库节点剩下的LUN重新创buildZFS vdev /池。 出于高可用性原因，不需要数据库级复制。
可能的问题
如何检测vdev的降级？ 每5秒检查一次？ ZFS提供的任何通知机制？
是否有可能从现有的组成vdev的LUN重新创build一个新池？ 任何陷阱？
这不是对你的问题的直接回答，但是更传统的架构就是使用HAST和CARP来处理存储冗余。
基本概述（更多细节请参阅链接的文档）：
这里需要注意的是，HAST只能在主/从级别上运行，因此您需要为每个要导出的LUN / LUN组配对使用一对机器。
另外需要注意的是，您的存储架构不会像您提出的devise那样灵活：
有了HAST，您只能将其放入一对机器中的磁盘数量。
通过您提出的iSCSI网状结构，您理论上可以添加更多的机器，导出更多的LUN，并根据需要增长（达到networking极限）。
这种折衷的灵活性为您带来了经过testing的，经过validation的文档化解决scheme，任何FreeBSDpipe理员都能理解（或者能够阅读手册并弄清楚） – 对我来说这是一个值得的权衡:-)
将输出“zpool status -x”，无论所有池是否健康，或者输出不是的状态。 如果iSCSI LUN vdev处于脱机状态，那么运行基于该命令的脚本的cron作业应该会为您提供定期发出cron警报的方法。
“zpool import”应该能够从iSCSI LUNs vdevs导入现有的zpool。 如果池未完全导出，则可能必须强制导入，但即使数据库节点发生故障，写入操作也会中断写入，但内部元数据应保持数据处于一致状态。