Best practice for high availability ZFS pool

[Palle Girgensohn]

> 16 maj 2016 kl. 15:51 skrev Borja Marcos <borjam at sarenet.es>:
> 
> 
>> On 16 May 2016, at 12:08, Palle Girgensohn <girgen at freebsd.org> wrote:
>> 
>> Hi,
>> 
>> We need to set up a ZFS pool with redundance. The main goal is high availability - uptime.
>> 
>> I can see a few of paths to follow.
>> 
>> 1. HAST + ZFS
> 
> Which means that a possible corruption causing bug in ZFS would vaporize the data of both replicas.
> 
>> 3. ZFS replication (zfs snapshot + zfs send | ssh | zfs receive)
> 
> If you don’t have a hard requirement for synchronous replication (and, in that case, I would opt for a more application
> aware approach) it’s the best method in my opinion.

That was exactly my thought 18 months ago, and we set up two systems with zfs snapshot + zfs send | ssh | zfs receive. It works, but the problem is it just too slow and a complete sync takes like 10 minutes for all the file systems. We are forced to sync the file systems one at a time to get the kind of control and separation we need. Even if we could speed that up somehow, we are really looking for a more recilient system. Also, constant snapshotting and writing makes scrub very slow so we need to tune down the amount of syncing every fourth week-end to scrub. It's OK but not optimal, so we're pondering for something better.

My first choice is really HAST at the moment, but I also dont find much written in the last couple of years, apart from some articles about setting it up in very minimal testbeds or posts about performance and stability troubles. This makes me wonder, is HAST actively maintained? Is it stable, used and loved by the community? I'd love to hear some success stories with farily large installations of at least 20 TB or so.

Palle

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160517/d0bb1066/attachment.sig>