HAST + ZFS + NFS + CARP

[Borja Marcos]

> On 17 Aug 2016, at 20:03, Linda Kateley <lkateley at kateley.com> wrote:
> 
> You do risk losing data if you batch zfs send. It is very hard to run that real time. You have to take the snap then send the snap. Most people run in cron, even if it's not in cron, you would want one to finish before you started the next. If you lose the sending host before the receive is complete you won't have a full copy. With zfs though you will probably still have the data on the sending host, however long it takes to bring it back up. RSF-1 runs in the zfs stack and send the writes to the second system. It's kind of pricey, but actually much less expensive than commercial alternatives.

Doing somewhat critical stuff off cron is not usually a good idea. I do ZFS replication with a custom program which makes sure of some important stuff:

- Using holds to avoid an accidental snapshot deletion to require a full send/receive. 

- Avoiding starting a new send/receive on a dataset in case the previous one didn’t finish for whatever reason (the main problem with cron)

- Offering the possibility of some random variation on the replication period so that, in case several happen to start simultaneously, you don’t have a periodically overloaded system.

- Avoiding mounting the replicas so that the receive won’t need a rollback, which would be potentially risky.

- Supports one-to-many replicas, with different periodicity for each destination if required.

I am sorry I can’t share it (company property) but the program is rather silly anyway. The important work was the decision to have the previous
features, and a design decision to avoid destructive and portentially error-prone operations such as rollbacks. 


Most applications that require real time replication are databases, and they usually include a clustering option which can be much simpler to manage (and more robust in this case) than filesystem replication.

For other cases, often you can design around the loss of a small amount of data. I understand that in some cases you have no other option,
but the benefits of asynchronous send/receive are so many, especially if you are on a tight budget, it’s well worth to try to make the most of it.






Borja.