Re: RFC: High availability replication/raid-like filesystem

Hi,

This reminds me alot of AFS (andrew file system)
that seem to have been quite intensively developed
by OpenAFS.org since 1999 when I worked with a proprietary
AFS implementation.

It had then already, most of the features you mention
(except may be for replicating and/or striping of individual files
matching the regex, which I personally find unnecessary exotic,
anyway)

Replication is definitly a requirement for me. As for the raid-like
behavoir, I'm not really meaning plain striping though, I'm more
thinking in the line of RAID 1, 3, 4, 5, 6.This can spread disk storage
over many geographical different locations, can also provide redundancy
should one location go down and one needs to rebuild the FS on the fly.

My problem is ... if I have all my storage in 1 location, an earthquake
hits and the disk falls through to the middle of the earth ... I can
basically kiss the clients using that service goodbye. I cannot depend
on 1 location for redundancy, time and time again, through power
outages, ups failures, core router failures, distribution switch
failures I've had downtime ... and for every minute of downtime I need
to refund clients (100% SLA).

Now ... if I can replication about 200Tb of mail (lets leave the
webspace out of it for now) over fiber between say California and Hong
Kong and keep them in sync, if either location gets eaten up by
whatever natural disaster or freak IDC failure, i switch dns to the
other and pick up the peices later. (assuming one uses plain
replication)

And, it was stable enough to run a corporate network of about
5000 servers spread over the globe.

Support semantics and syntax were rather cryptic, comparing to
traditional filesystems, or even to new ZFS from Sun, but large part of

this complexity was brought in by Kerberos ACLs over traditional
UNIX file permissions.

I see the docs are a bit cryptic. I also looked at GFS, but for the
life of me I cannot determine what it does apart from probably allowing
you to mount disks over the net and *maybe* using raid 0 above it?

To summarize, I personally would rather prefere to see the missing
features added to OpenAFS, than a new overlapping project.

I agree.... but a filesystem under FUSE is aimed at userspace
implementation, not kernel space. This would make it easier to develop
and less intrusive. Also appears FUSE filesystems work under FreeBSD
where openafs doesn't.

*shrug*

I need replication .... and using the least intrusive and easiest
means.... FUSE ontop of ext2/3, reiser, xfs of jfs just seems to be the
most logical choice. If FUSE goes to hell in a handbasket, just stop it
and use the FS as it is. Also makes it easier in emergency scenarios to
use normal tools to accomplish different tasks, rahter than for
instance trying to fsck an ACME disk partition or ACME FS.

Both AFS and GFS look great, but require kernel modifications, so you
can say goodbye to commercial support contracts from some vendors...
which means the clients I have won't be interested in it.

I'm just throwing stones in the bush here to see what people think, but
you can maybe get a feel for the scenario I'm in and the sort of
problems I face? I don't want to re-invent the wheel, thats just
stupid, but I need a clean, easy and effective way to solve my problem
:o)

Kind Regards
Nigel

.

Relevant Pages