> Date: Thu, 05 Feb 2004 12:59:54 -0800
> From: Douglas Phillipson <dougp@intermind.net>
> Subject: Before I get in too deep...
> To: lustre-discuss@lists.clusterfs.com
>
> I''m looking for a filesystem that can write and read data to
multiple
> redundant servers that are geographically separated.
>
> Specific case:
>
> I would have 3 servers, one in Vegas, one in Wash DC, one in Chicago
> running a Lustre filesystem that is mounted by a client machine in
> Vegas. When the client machine writes a file it is stored on all three
> servers at nearly the same time, save the transaction overhead of
> metadata or whatever. Now if a server in the "filesystem" were
to go
> down, after which the user had written dome data, when the server comes
> back up it should "resync" itself with any changes the other two
servers
> have. Copies of the data should be on all three servers and during a
> write to the filesystem, if a server goes down, no error should be given
> to the user writing the data and the data should just be written to the
> other two servers.
Lustre 2.0 will provide mechanisms that allow this to happen. The key
problem here is to make decisions what to do if the updates are
conflicting, when multiple servers are being used, but the network is
down.
For example, two sites may have written to the same file while there
was no network connection. To make it worse, they can keep this file
open, even when the network comes back up.
Do you have ideas about what copy/copies of the data Lustre should
preserve? Should it send email to the system administrator asking
him to execute a conflict resolution policy.
Of course, it is fair to make this the problem of the user, so that
Lustre at least works in cases where there is no conflict.
> Can Luster provide this functionality?
Yes, subject to these kind of problems that are fundamentally
insoluble at the file system level.
> If so, how will the user
> percieve the write is complete? Will the users application
"hang" until
> the write is finished on all three servers?
No, we could let the write complete "locally" and replicate it in the
background.
Remote users using another server to access the data would ask for a
lock, a side effect of getting that lock would be to flush the
replication cache from the first server.
Other replication mechanisms are to write to all or more than 50% of
available servers, or to the local one and a "primary" server (the
configuration is likely to be star or tree based).
> Or when the "nearest" server
> has the data, control is returned to the user and the
"filesystem" then
> replicates the data to the other servers behind the scenes?
I think that is the best policy.
> I hope I''m
> understanding what Luster can do. I don''t want the functionality
of
> Microsoft''s DFS which just pulls diverse data under a single
mountpoint
> which Unuix/linux has done for 25 years.
I am sorry to let you know we can do that also :)
The basics of this are being built right now, we would love a couple
of early adopters, who have some cash to allow us to fix bugs and
stabilize this further.
- Peter -
> Thanks for your time
>
> Regards
>
> Doug P