On 16/07/10 12:31 PM, Daniel Pittman wrote:
Also, lots of different apps, so I might well end up with multiple
solutions.  A good distributed POSIX FS with replication, eventual
consistency, some sensible conflict resolution model, and data center
awareness would have been easy enough to use though.

If I could have my pony. ;)
So as you and Jamie have both alluded to, this is a pretty hard problem to solve. Most of the Enterprise-y solutions I deal with solve it by pushing the problem down the stack and using $expensive_storage_array with synchronous replication. Possibly over also $expensive_dwdm_fibre. The most accessible of these solutions is probably NetApp's MetroCluster tech. If you truly need real-time POSIX compliant synchronous access between sites, this (and it's kin from HDS and EMC) is pretty much your only choice.

Most of the other Open-Source (and indeed, commercial) solutions to doing this at a filesystem-level have left me wanting. We tested and deployed GlusterFS for a large customer project last year, purely for HA file serving, and regretted it so much that we ripped it out in the middle of a busy production period and replaced it with NFS + Rsync (particularly after the customer revised their recovery time objective :)). We've had similar amounts of pain with Microsoft's DFS solution (in Windows land, ugh).

As Jamie notes, it's at this point that you'd usually go back and redefine the problem, particularly after the sales dudes make your eyes bleed. :)

There are a couple of different shapes this problem usually takes in the market - "I want a DR site" or "I need to share files with a remote branch". Considering these, and their various solutions (Publish/two+ subscribers, move the desktops closer to the data, active/passive access, ...) might give you some more ideas about outside-the-box ways to solve the problem.

Your mileage will almost certainly vary.

Cheers,

Matt
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to