obe*_*tet 5 freebsd zfs storage iscsi
我正在考虑一个基于 ZFS/iSCSI 的架构，用于在普通 PC 硬件的小节点上运行并运行 FreeBSD 9 的 HA/横向扩展/无共享数据库平台。
它会起作用吗？什么是可能的缺点？
建筑学
存储节点具有直接连接的廉价 SATA/SAS 驱动器。每个磁盘都导出为单独的 iSCSI LUN。请注意，该层不涉及 RAID（无论是硬件还是软件）、分区、卷管理或任何类似的东西。每个物理磁盘只有 1 个 LUN。
数据库节点运行 ZFS。ZFS 镜像 vdev 是从来自 3 个不同存储节点的iSCSI LUN 创建的。在 vdev 之上创建了一个 ZFS 池，并在其中创建了一个文件系统，该文件系统又支持一个数据库。
当磁盘或存储节点出现故障时，相应的 ZFS vdev 将继续在降级模式下运行（但仍有 2 个镜像磁盘）。一个不同的（新的）磁盘被分配给 vdev 来替换出现故障的磁盘或存储节点。ZFS 重新同步发生。如果故障存储节点或磁盘再次可用，它总是会被完全回收。
当一个数据库节点出现故障时，该节点以前使用的 LUN 是空闲的。启动一个新的数据库节点，它从发生故障的数据库节点留下的 LUN 重新创建 ZFS 虚拟开发/池。出于高可用性的原因，不需要数据库级复制。
可能的问题
如何检测vdev的降级？每 5 秒检查一次？ZFS 有任何可用的通知机制吗？
甚至可以从构成 vdev 的现有 LUN 重新创建新池吗？有什么陷阱吗？
这不是您问题的直接答案，但对于此类事情的更传统架构是使用HAST和CARP来处理存储冗余。
基本大纲（有关详细信息，请参阅链接的文档）：
这里需要注意的是，HAST 仅适用于主/从级别，因此您需要为要导出的每个 LUN/一组 LUN 配备成对的机器。
另一件需要注意的事情是，您的存储架构不会像您提出的设计那样灵活：
使用 HAST，您可以放入一对机器中的磁盘数量受到限制。
使用您提出的 ISCSI 网状结构，理论上您可以添加更多机器，导出更多 LUN 并根据您的需要增长（到您的网络限制）。
这种灵活性的权衡为您提供了一个经过测试、经过验证、记录在案的解决方案，任何 FreeBSD 管理员都可以立即理解（或者能够阅读手册并弄清楚）——对我来说，这是一个值得的权衡:-)
小智 4
“zpool status -x”将输出所有池是否健康或输出不健康池的状态。如果 iSCSI LUN vdev 脱机，则运行基于该命令的脚本的 cron 作业应该会为您提供一种定期发出 cron 警报的方法。
“zpool import”应该能够从 iSCSI LUN vdev 导入现有 zpool。如果池未完全导出，您可能必须强制导入，但内部元数据应该使数据保持一致状态，即使写入因数据库节点故障而中断。
| 归档时间： |
|
| 查看次数： |
10299 次 |
| 最近记录： |