Re: tlug: Coda filesystem

[Frank Bennett <bennett@example.com>]

"J. David Beutel" <jdb@example.com> writes:

> > couple of neat extra features like server replication and
> > disconnected operation out of client file-cache.
> 
> Server replication sounds interesting.  Is that like an automated
> local mirror of a whole tree, which many clients can access via LAN,
> to save WAN bandwidth?  Then, are changes from one site distributed
> efficiently, instead of copying the whole tree?

My understanding of Coda's data structures still has serious
holes in it -- which means I can answer this really briefly and
"completely", in a very local sense.  :)

"Server replication" means keeping a hot copy of server data on
another machine, complete with a running Coda server.  In the
event that the master machine fails, the replica (or one of them
if there are several) steps up to bat in its place.  It's a
strategy for providing high availability of services.

In Coda, the unit for handling data sync between servers is the
"volume".  A volume is, in Unix terms, something like a
filesystem mounted with loopback.  Therefore, in hardware terms,
it should be a good deal smaller than the disk partition, so that
it's possible to balance disk loading by shifting volumes between
partitions on a Coda server.

So although the top-level docs in the Coda archive talk about
"server replication", it looks like you can dice up a server into
its volumes, and replicate a monster server piecemeal across a
bunch of smaller machines.  The whole cluster, scattered out
across the Internet, should function as a single filesystem when
mounted by a Coda client.

For a practical example, the idea is that you have maybe one
machine running Coda, and containing all of your users' data.
Your users are, say, emergency relief workers in the field, and
it's not good enough to restore the server data from tape if it's
been destroyed in the earthquake that they're supposed to be busy
coping with.  You need everything working throughout the crisis
without missing a beat.

By replicating server data to a bunch of different sites, you can
provide this high availability.  What I'm not yet clear on
(because I haven't read enough yet) is how the changeover is
handled.  I assume that clients are given a list of servers, and
the servers provide info on who's-on-first, what's-on-second so
that clients can fetch and push their data to the right machine
or machines.

In Coda, replication can be done read-only or read-write.  With
read-only, servers handling the same volume are in a master-slave
relationship, and data in the slave always lags behind the master
server.  This is said to be a quick and efficient means of
providing backup of data that doesn't change very often; because
most accesses are read accesses, clients accessing data from a
server in New York get the same stuff as clients contacting the
Tokyo server.

Read-write replication is meant for user volumes -- home
directories.  Here, the user in an multinational organization
(corporation or NGO :) might be in the New York or Tokyo or Dar
Es Salaam office.  Wherever she is, she needs to be able to write
to her home directory as well as read.  In read-write
replication, therefore, all servers handling the volume are able
to act as master in the relationship with the others, so the
write into "the server" can be to the nearest available hardware.
(Read-write replication requires more CPU and more bandwidth,
which is why we also have read-only replication.)

The process of updating takes place at the filesystem level, so
yes, it is going to be more "efficient" over a short interval of
time than sending a burst of all the data in a filesystem to
another machine (that is, it will cost less in bandwidth).

For info from people who actually know what they're talking
about (unlike me on this occasion :) see:

  http://www.coda.cs.cmu.edu/

Seems to me that for consultants and administrative staff, this
could be good for one's career in a country that is, uh,
expecting a major earthquake to strike sometime soon?  Depends on
the Complacency Index, I suppose.

Cheers,
-- 
-x80
Frank G Bennett, Jr         @@
Faculty of Law, Nagoya Univ () email: bennett@example.com
Tel: +81[(0)52]789-2239     () WWW:   http://rumple.soas.ac.uk/~bennett/

---------------------------------------------------------------
Next Nomikai: 20 November, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 12 December, 12:30 Tokyo Station Yaesu central gate
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp