Using Coda for server mirroring (in lieu of rsync)

View: New views
2 Messages — Rating Filter:   Alert me  

Using Coda for server mirroring (in lieu of rsync)

by Andy Sy-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

We have a web server setup which we want to
mirror and load-balance.  We basically want to
be able to synchronize the contents of the
htdocs/ directories on two or more different
servers in [more or less] real time.

The common approach would be to have rsync running
on each server copying the most recent version of a
file over to the server(s) that do not yet have it
every few minutes (invoked via cron).

I feel that rsync is really a rather clunky approach
and I was wondering, is Coda a suitable and much better
alternative in this scenario?

Based on my surface reading of how Coda works (forgive
me if I have any egregious misconceptions), in the simplest
case of 2 servers "mirroring" each other, the setup would be
a Vice file server process running on each of the 2 servers,
as well as a Venus process on each providing the
htdocs/ mount.

Would the above be a reasonable, recommended setup?


I am guessing the operation would work very roughly
something like the below:

Updating htdocs/* while connected to server A would naturally
update server A's Vice copy of htdocs/ first which would then
transparently get replicated over to server B's copy eventually.

In a case where server B's Vice process happens to be down, but
with everything else still up, server B's htdocs/ would get
served from/by server A's Vice process transparently?

In the case where server A and B's Vice processes are both
up, accessing htdocs/ would be effectively be nearly as
fast as access to to a, say, normal ext3 mount?







Re: Using Coda for server mirroring (in lieu of rsync)

by M. Satyanarayanan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Wouldn't a much simpler design be two substantial  Coda clients  each running a web server?
The web pages would then be a shared pool stored on N Coda servers ---- N being determined
by capacity and load.  You could experiment with singly-replicated Coda servers to decide if it
works well  -- server replication is needed only to provide additional resiliency to failures. Note
that the Coda clients (i.e. web servers) can handle brief periods of disconnection (few minutes to
tens of minutes, perhaps) without any server replication.

The policy to direct web accesses to specific web servers is outside the above.   You could
just have any web server service any web request.  Or, you could partition the Coda namespace
statically and redirect requests to the other web server if needed.   This would have the
advantage of increasing the locality seen by the cache on each Coda client.   Fancier load
balancing schemes are easier to imagine, but simplicity usually wins the day.

It is worth going back to the dawn of the Web and seeing how AFS was used very successfully at NCSA.
(see Thomas Kwan, Robert McGrath, and Daniel Reed. NCSA's World Web Server: Design and Performance, IEEE Computer 1995(0018-9162):68-74, 1995 --- pdf attached))
Replace "AFS" with "Coda" and you have a simple starting point to explore.


kwan95.pdf (798K) Download Attachment