Keeping in mind I've never done this so no idea how well it works. I'd say a combination of
Global File System - http://sources.redhat.com/cluster/gfs/ and Global Network Block Device - http://sourceware.org/cluster/gnbd/ should do the trick, this document explains how http://sources.redhat.com/cluster/wiki/DRBD_Cookbook?highlight=(CategoryHowTo) On Sat, Apr 05, 2008 at 09:52:55AM +1100, Crossfire wrote: > I've just spent some time quickly researching this to no real satisfaction. > > What I'm looking for is a way to do real-time hot-replication of a whole > filesystem or filesystem tree over 2 nodes (and strictly 2 nodes) without > STOMITH[1]. > > The scenario is I have two identical systems with local (software) RAID1. > They will be tethered onto their internet feed via ethernet, and can > optionally be tethered to each other via Gig. > > I want to be able to set it up so /home (and maybe other filesystems) are > replicated from one to the other, in both directions, in real time so they > can run in an all-hot redundant cluster. > > The environment should be mostly read-oriented, so I can live with > write-latent solutions as long as they handle the race/collision > gracefully (preferably by actually detecting and reporting it if they > can't avoid it). > > The options I've investigated so far: > > * Lustre (MDS requirements[2] make this not an option) > * GlobalFS (STOMITH requirements make this not an option. Oriented > towards shared media too, which I am not using) > * tsync (Naive concurrent operation model, but otherwise viable) > * MogileFS (not quite what I was looking for, but none the less useful). > * OpenAFS (read-only replication only, loss of the node hosting the > write volume still renders the volume unwritable). > > Is anybody aware of any other options that I've missed? > > C. > > [1] "Shoot The Other Machine In The Head" - the ability for any node to > forcibly powerdown any other node believed to be malfunctioning. > [2] Single instance MDS only, only clusterable through shared storage. > d'oh. > [3] People suggesting rsync will be taken out back and shot for not > reading the requirements. > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- John http://www.inodes.org/ -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
