[nasalgoat]

Not sure if much has changed, but the last time I tried to install Ceph it wouldn't work under CentOS. That, and it was far too complicated to set up.

GlusterFS, on the other hand, was incredibly easy, although I am not a fan of FUSE due to the high CPU usage.

[fintler]

I still see Ceph as competition to supercomputer filesystems and not really as competition to GlusterFS. For example, the design of it directly attacks the problem of centralized metadata (especially useful after the DARPA project to bring it to Lustre failed).

I was working on an unrelated project with one of the designers of Ceph (UCSC's Scott Brandt) and in conversation he also seems to concur that Ceph was really built as a replacement for PanFS or Lustre (but still may be useful for other things of course).

Using it to replace GlusterFS still seems odd to me. It feels like they're both solutions to different problems.

[noahdesu]

Recent gluster vs ceph debate at LCA.

http://www.youtube.com/watch?v=JfRqpdgoiRQ

[fintler]

Nice talk, but I think I was basically trying to say that Ceph really shines when you compare it to Lustre and PanFS.

It's not a clear winner when you compare it to GlusterFS because the original design wasn't intended to replace GlusterFS (although it may do a good job of this anyway).

[stonith]

Ceph is still a very long way behind Lustre for streaming bandwidth, so to say it shines would be a little much. Lustre's weakness is in scaling to support large file counts, but in real deployments this can be mitigated by using an MDS server with a lot of grunt. Ceph can't compete with Lustre for HPC deployments until it supports RDMA, and even with that it's still going to take a long time to reach Lustre's performance (which is close to line rate at this point)

[noahdesu]

Platform support (http://ceph.com/docs/master/install/os-recommendations/#plat...) and deployment tools have come a long way. In the past setup has been complicated (Ceph is inherently more complex than other systems), but it is getting much easier. There is also extensive documentation at http//ceph.com/docs, as well as very active IRC channel and mailing lists for support.

Ceph is much larger than just the file system (as the article points out). And while many Ceph products/subsystems are used extensively in production environments (RBD block store, RGW, and RADOS), CephFS isn't officially supported as production-ready.

Despite that, we run Hadoop on top of CephFS, and can deal with the occasional metadata server problem. CephFS is actively being hardened.

[komljen]

Correct, Ceph is much larger than the file system. As I said at beginning of article I'm using each Ceph component, RBD, RadosGW and CephFS and I will write article for each of that. This is just some sort of getting started guide. I'm interested at running Hadoop on top of CephFS, is it stable enough?

[noahdesu]

The instability we have seen is with the metadata server, but have been able to relatively quickly push fixes to upstream as we encounter them. The focus has been on stability, and we have been running pretty large terasort jobs without issue. In the upcoming release of Cuttlefish, due out any time now, there will be locality information exposed to Hadoop for better task scheduling. We will start focusing on improving Hadoop performance soon, now that things have stabilized.

[Nux]

Ceph has a yum repo for Centos, although Cephfs still does not work (maybe it will be backported to the "ancient" EL6 kernel someday). You can use the fuse client instead.

Configuration-wise, Ceph involves quite a bit of voodoo compared to Glusterfs, it's an area where I hope to see some improvement.

[tssva]

Is the metadata server still a single point of failure?

[laymil]

The metadata server has never been a single point of failure in Ceph.

[giulivo]

One more feature I found very interesting in GlusterFS is the ability to export the volumes via NFS, transparently, to the NFS clients.