[877] in arla-drinkers
RE: Replicated servers, milko?
daemon@ATHENA.MIT.EDU (Lyle Seaman)
Thu Jun 17 10:58:38 1999
From owner-arla-drinkers@stacken.kth.se Thu Jun 17 14:58:37 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 15259 invoked from network); 17 Jun 1999 14:58:36 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 17 Jun 1999 14:58:36 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id QAA23561
for arla-drinkers-list; Thu, 17 Jun 1999 16:51:24 +0200 (MET DST)
Received: from gw.stormsystems.com (stormsystems.com [209.49.190.30])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id QAA23557
for <arla-drinkers@stacken.kth.se>; Thu, 17 Jun 1999 16:51:17 +0200 (MET DST)
Received: from fs1.office.stormsystems.com (exchange.office.stormsystems.com [172.29.1.5])
by gw.stormsystems.com (8.9.3/8.9.1) with ESMTP id KAA12345
for <arla-drinkers@stacken.kth.se>; Thu, 17 Jun 1999 10:50:45 -0400
Received: by fs1.stormsystems.com with Internet Mail Service (5.5.2448.0)
id <NBCRA311>; Thu, 17 Jun 1999 10:50:45 -0400
Message-ID: <B5C3AE5DDF77D211BD2500A0C9D3A6A11BFFCA@fs1.stormsystems.com>
From: Lyle Seaman <LSeaman@stormsystems.com>
To: arla-drinkers@stacken.kth.se
Subject: RE: Replicated servers, milko?
Date: Thu, 17 Jun 1999 10:50:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
AFS doesn't quite do the level of read-write failover that you're looking
for.
The server is stateful, and that state would be lost when the first server
fails. There is presently no mechanism by which the take-over server could
recover the lost state.
It's probably a few man-months of work to design and implement the failover
protocol, and Transarc may already have such a project underway. You should
contact them.
(basically, what's needed is a set of modifications to the cache manager so
that dirty chunks are not permanently discarded from the cache until after
they've been "committed", which could occur after they've been replicated,
or at least sync'ed to a shared disk. The other thing that's needed is a
callback and lock recovery protocol, so the new server can learn about which
callbacks and locks have been granted already. One way to do this quickly
would be to have the first server "log" to a shared filesystem, or via ubik,
the identities of clients which have been granted callbacks and locks, so
that the takeover server could proactively query all of those clients for
state recovery. I think that's it, though I haven't thought about lately,
so I may be missing something.)
> -----Original Message-----
> From: Magnus Ahltorp [mailto:map@stacken.kth.se]
> Sent: Thursday, June 17, 1999 7:01 AM
> To: Mitja Sarp
> Cc: arla-drinkers@stacken.kth.se
> Subject: Re: Replicated servers, milko?
>
>
> > How experimental is milko? I've been given the task
> > of creating a duplicated set of fileservers meeting
> > the high-availability requirements.
>
> Milko is not ready for production use yet.
>
> > Can milko do server replication at this point, or should I go ask
> > transarc?
>
> Since file server replication is implemented in the client, I would
> say it can handle it, but don't expect milko to do much more than
> serve files right now. A volserver is yet to be written, and the
> database replication is not implemented. There are also other things
> that should be written.
>
> /Magnus
> map@stacken.kth.se
>
