Dear Gluster Community, After researching a number of distributed file systems for deployment in a production environment with the main purpose of performing both batch and real-time distributed computing I've identified Gluster as a potential solution. The key properties that our system should exhibit: - an open source, liberally licensed, yet production ready, e.g. a mature, * reliable*, community and commercially supported solution; - ability to run on commodity hardware, preferably be designed for it; - provide high availability of the data with the most focus on reads; - high scalability, so operation over multiple data centres, possibly global; - removal of single points of failure with the use of replication and distribution of (meta-)data. The sensitivity points that were identified, and resulted in the following questions, are: 1) transparency to the processing layer / application with respect to data locality, e.g. know where data is physically located on a server level, mainly for resource allocation and fast processing, high performance, how can this be accomplished using GlusterFS? 2) posix compliance, or conformance: hadoop for example isn't posix compliant by design, what are the pro's and con's? What is GlusterFSs approach with respect to support for posix operations? 3) mainly with respect to evaluating the production readiness of GlusterFS, where is it currently used in production environments and for what specific usecases it seems most suitable? Are there any known issues / common pitfalls and workarounds available? I realize that I've posed quite a lot of questions above but any answer or help, or links to where the information could be found, are very much appreciated :) In addition, specifically for GlusterFS: 4) It seems Gluster has the advantage in Geo replication versus for example Ceph. What are the main advantages here? 5) Finally what would be the most compelling reason to go for Gluster and not for the alternatives? I'm looking forward to your replies. Thanks in advance! :) With kind regards, Tim van Elteren -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131028/27d62dae/attachment.html>