Date: Fri, 03 Jun 2016 11:40:11 +0100 From: Pete French <petefrench@ingresso.co.uk> To: stable@freebsd.org Subject: Re: HAST, zfs and local mirroring Message-ID: <E1b8mWR-0000uA-3H@dilbert.ingresso.co.uk> In-Reply-To: <57514843.6010003@norma.perm.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> You message lead me to a though that I could use iSCSI to replicate the > zfs pool from node1 to both iSCSI-provided disk on a node2 in a 4-way > mirror, right ? Are there any obvious obstacles to this, that I don't > see, considering the bandwith will be enough ? I have spent a long time doing this kind of thing - always needing a pair of machines, 2 discs in each and 4-way mirroring. over the last decade weve used ggated/ggatec + gmirrors, iscsi + gmirror, iscsi + zfs and finally hast + zfs. Out of all that I have to say that hnast has been a godsend - its is by far the best of all the solutions. so my recommentation would be to hast the drives into two hast resources and zpool on top of that. yes, you have two hast devices, but why is that an issue ? what we also do is to add separate ether cards into the machines just dedicated to the hast traffic between them, so that is not a bottlneck. the reason hwy hast is so good compared to all the other network block evel solutions we have tried is that it behaves ell in the case when things fail. Theres nothing wrong with either ggatec or iscsi in the normal case, but in the past I had a lot of issues with the mirroring layer not understanding properly when the unerlying devices vanish due to crashes or other unexpected events. As the purpose of all of this is, preseumably, fault tolerance, then thats unfortunate. this may have chnaged, I havent tried these technologies out in a while, but with hast you dont ever see a device simply vanish rom underneath your zpool, and the whole thing continues to work reliably and smoothly until the remote node comes back up, whereupon it resyncs perfectly. really, go with hast + zpool unless you have a good reason not to... -pete.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1b8mWR-0000uA-3H>