amuck-landowner

Distributed Filesystem Cluster

shovenose

New Member
Verified Provider
I would like to find a way to store files and stuff using various not the same servers in various datacenters with various providers. If one goes down the whole data should be intact.
 
Last edited by a moderator:

trewq

Active Member
Verified Provider
I would like to find a way to store files and stuff using various not the same servers in various datacenters with various providers. If one goes down the whole data should be intact.
Do you mean, like backups?
 

tchen

New Member
Just mirror. Gossip/balancing over WAN is horrible and brittle unless you have a low rate/low volume file system, in which case, why not just mirror?


Don't automatically lump disaster recovery with DC survivability.
 

Mun

Never Forget
gluster works well, but you need the fuse driver so you will need to ask if you are using OPENVZ for the fuse driver installed on each server.

Tahoe-LAFS supposedly doesn't have this issue?

Mun
 

perennate

New Member
Verified Provider
gluster works well, but you need the fuse driver so you will need to ask if you are using OPENVZ for the fuse driver installed on each server.

Tahoe-LAFS supposedly doesn't have this issue?

Mun
If you want to mount the DFS at mount point with POSIX interface then you need FUSE. Tahoe-LAFS can be accessed with other methods, but then you'd need to write most of your web application around it. Also Tahoe-LAFS doesn't store metadata like file permissions and it could be very hard to use.
 
Last edited by a moderator:

perennate

New Member
Verified Provider
Regarding glusterfs: while it is a pretty stable filesystem and offers extensibility, their approach to replication and striping is complete shit. You have to define explicit replication and striping "bricks", which are basically sets of node that can be used for doing that. If you want both striping and replication it starts to get so complicated that maintaining the cluster is a pain. Of course if you are storing only small/medium size files then it's not a big deal.

But probably you still want replication; and gluster doesn't seem to care much about it. They have no documentation on automatic failover (moving a replica to another node, or in their case it'd have to be another brick, when one node in a brick goes down) so probably it doesn't even exist. I don't understand how people can possibly manage large gluster clusters.

Edit: granted, replica sets do have advantage of isolating failures. But that doesn't excuse seeming lack of automatic replica management. Unless that exists and just isn't well documented.
 
Last edited by a moderator:
Top
amuck-landowner