Slashdot Mirror

Redhat has some hot stuff being developed, look at GlusterFS for instance.

http://gluster.org/community/d...

Gluster - Local storage? ok. Remote storage? ok. Redundant sets of data across multiple availability zones in EC2 or different providers or local and remote? ok.). http://www.gluster.org/

Use GlusterFS http://www.gluster.org/ for redundancy spanned across one or more JBOD machines for a much easier hardware and data upgrade path. Use oVirt for easy set up http://www.gluster.com/community/documentation/index.php/GlusterFS_oVirt_Setup_Guide. Mount GlusterFS directly to your clients or export via iSCSI target, fibrechannel target, FCoE, NBD, or traditional NFS for a more advanced shared storage solution. And you can still run more of a NAS type setup with CIFS, WebDAV, or the like.

Instructions to "Build Your Own Dropbox Equivalent." CloudFS is an offshoot of GlusterFS, which is not quite ready for prime time, but getting damn close. So you'd be cautioned about trusting corporate data to this setup. For less vital stuff, it should work well.

E.g. http://www.openafs.org/, http://www.gluster.org/

Lot of different ways to get similar results. You might say I'm cloudy on which of these is really equivalent, is a good idea or the best way to do it, or has good performance.

There is Gluster which sits on top of any existing disk file system, via FUSE, I think. No kernel module needed, only runs a daemon. I tried version 2, and it worked fine, however I didn't demand much of it. They've just come out with version 3.0 that doesn't need libfuse anymore.

Or there's Lustre, which does need a kernel module, and has its own file system.

Are some of the new file systems under development, such as btrfs, going to have distributed, networked operation as a basic feature? I recall hearing that ZFS has some ability along those lines.

Or we don't bother with distribution at the file system level because we're using some sort of cloud where as part of distributing everything, the file systems are distributed too.

I haven't heard of NBD before. Of course there's NFS, which seemingly everyone agrees is slow and obsolete.

Interestingly, it would be easier to store all my data in Freenet and have all my PCs form a darknet with each other.

I guess it would be cool to have a darkLAN, but with Freenet, you have to duplicate your data.

It may make more sense to use GlusterFS or Hadoop for your LAN.

If you want to add crypto, you could store the above data volumes on plain ol EXT(3|4) filesystems inside a TrueCrypt partition.

HA? I use heartbeat in a few situations. (EG: the load balancers) But it has its own limitations.

DRBD masks the fact that you still have a single point of failure: the SAN itself. So I've avoided the expense of a SAN-based solution by distributing the load with an application-level distributed storage system, and glusterfs for the small number of cases where I wasn't able to use the aforementioned application-level storage system. Honestly, its performance is pretty weak, but its ease of use/setup, its reliability, and its distributed nature have compensated nicely. After major bombs when attempting to use NFS on a SAN and DRBD over TCP, GlusterFS is a pretty strong bet.

Our distributed cluster is not 100% complete yet, but so far, the conservative, year-long rollout has been going without any major hitches. I'm anticipating 100% rollout in Jan of this year...

http://www.gluster.org/

Based on fuse, I've searched around for numerous shared filesystems or clustered filesystems and hands down this is the best I've come across.

Not only can you enable cacheing as you mentioned but you can create virtual disk space up to petabytes in size by aggregating all your available gigs of storage you have with servers that are lying around. It supports posix locking along with file replication (a-la raid1) and striping (although its not recommended) with the add on system that it runs with.

Hell, by writing clever config files you can centralize your configs. You can then use autofs to centralize your mounts.

I would say the biggest thing its missing at the moment is hot addition/removal of space.

Gluster just works. The config for it is very well documented and architecturally a breeze compared to the ungodly configuration nightmare of say GFS. Failover and restoring is handled without necessarily having to manually intervene.

Try Gluster. Nothing else comes close and I expect its exactly what you would need in your environment.

GlusterFS (www.gluster.org) is just "THE" best cluster filesystem I have ever studied. I'm testing a few of them for a project here at my job and, at least for my case, GlusterFS is the best. It can scale to the petabytes with as many servers as you want. It can also use InfiniBand as interconnect protocol besides the usual TCP/IP/Ethernet.
It's design is simple is smart. Every feature is a translator that interconnects to other translators. So, you may organize your filesystem they way *you* want it.
Let-me give-you an example: they have 2 translators: 'unify' to unifying harddrives as one and 'afr' for automaticly file replication. Depeding on the order you use it you have two completly different setups. You can have two cluters replicating eachother or you can have a cluster of replicating servers pair.
Beside it's features and design, it's development team is *very* friendly. Yesterday someone (user) asked for a feature in the devel list, a get answered saying: good ideia, i'll do it.
Very good software.
Take a look: http://www.gluster.org/glusterfs.php