During the last years I’ve been experimenting with GlusterFS and his functionalities as distributed object store; a lot has changed in the software, overall since Red Hat acquired it. I have been using it and find it useful for many projects but not for others: what I love is the community oriented approach with a very responsive team and support for any kind of users (meaning from the 2 nodes web server to a RAID10 Infiniband cluster for high end storage).
My personal story with Gluster starts with a porting of a on-premise architecture in the cloud: moving an existing application to the cloud, instead of redesigning it from scratch, involves a lot of engineering to adapt the current system settings to a scalable infrastructure. Gluster comes handy when talking about scaling: the latest milestone has a very simple and efficient way of reconfiguring the underlying hardware, adding and removing nodes in the storage pool is as simple as inputting a couple of commands from any of the peers in the cluster.
If you’re unfamiliar with Gluster concepts (storage pool, peers, etc…) I suggest you RTFM on Gluster’s website; in this post I will detail a few points you won’t find on documentation and you should definetely know before starting to evaluate Gluster adoption.
If you find Gluster is not suitable for your application, consider analizying a different solution like DRBD: it may not be as cutting edge as Gluster or Ceph but may be the right solution for the job.