Quickfix (an open source FIX Engine) persists state information and sent/received messages in the filesystem of the server (Linux in this case). For disaster recovery, I should like these files to be kept up to date in near-realtime on a standby server over a WAN, such that said standby could start up and know the state of the system.
The persistence files are human-parseable text, and combined would rarely be more than a gigabyte accumulated throughout the course of a day. They are purged each night.
I would like the synchronization to happen directly, without a remote shared filesystem on a third server. I also need the files to survive the complete and sudden destruction of the primary server.
Rsync is too slow and not near enough to realtime to be useful. DRBD is one alternative that appears to do the job, but I wish to evaluate alternate means.
What are the options for doing something like this beyond DRBD and rsync?
drbd with ocfs2
drbd syncs via network at the block level. You can easily setup master/master. And ocfs2 is a nice clustered filesystem to sit on top of drbd
There's GlusterFS, available on many distros, which allows you to specify replication and distribution requirements among the machines in the cluster. It's very simple and easy to set up, and in my experiments it did not have cluster lock-up issues like I've experienced with OCFS2, though I haven't used GlusterFS as much as OCFS. I believe AFS also can produce similar results, but haven't had a chance to experiment with it. Ceph is the up and coming distributed fault-tolerant file-system but it's still pretty early in it's life-cycle.
I like using a cron script with a remote GIT repo when it makes sense to do so. It may not be the fastest option, but it makes restoration trivial and has been very reliable for me.
Apart from OCFS2 I think there's no real alternative. At least I don't know any.