> http://www.pbs.org/wgbh/evolution/library/01/6/l_016_08.html
*Do not do this* with write access repositories, is my advice from
knowledge of NFS filesystems. Writes, and partial writes, can occur from
one host for the next "commit" but not actually be seen on the next "round
robin" server until a fairly arbitrary amount of time later, due to
propagation delays inherent in NFS. There's a lot tht NFS can do well, but
this is not one of those tasks.
I'd really encourage you, for commercial graide high availability or load
distribution, to look at WanDisco's "Multi-Site" or to use a failover load
balancer setup. If server 1 goes toes up, serer 2 is available, and handles
all the traffic. But mixing and matching back and forth randomly as can
happen with round-robin? That sounds like a dangerous idea likely to bite
you at really, really bad moments due to simultaneous commits through two
different NFS enabled front ends.
On Wed, Sep 4, 2013 at 10:49 PM, Cheyenne Wills <cheyenne.wills_at_gmail.com>wrote:
> I've done several searches, and have found old and conflicting responses
> to the question of sharing a repository via NFS. So what is the current set
> of concerns with sharing repositories using NFS among several web servers?
>
> Here is the scenario, several hundred repositories shared via NFS to a
> couple of webdav (Apache mod-svn) servers. The Apache servers set up via a
> round-robin DNS server (thus they are all sharing a common virtualhost
> name). All user access is via webdav (authentication and access controlled
> by an Apache authentication handler). The users will see a common hostname
> for all repositories. All the servers are "network close" to each other.
>
> Assuming that the NFS is current (NFS 4) with subtree checking disabled
> (as per the FAQ), are there any gotcha's or other concerns.
>
> I currently have a solution using some custom Apache proxying that is
> working, but I'm looking at trying to simplify my solution.
>
Received on 2013-09-08 02:25:04 CEST