![ZFS over iSCSI 高可用性解决方案](https://linux22.com/image/593611/ZFS%20over%20iSCSI%20%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88.png)
我正在考虑一种基于 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。如果池未完全导出,则可能必须强制导入,但即使数据库节点发生故障导致写入中断,内部元数据也应使数据保持一致状态。