Azure Blob Storage vs Red Hat Ceph Storage

• Reduced cost. We were able to reduce our storage infrastructure by several hundred terabytes by consolidating redundant copies and dedupe/compression on files.
• Extremely high level of redundancy. We can replicate data in a variety of ways that we would never have been capable of on our own hardware.

Read full review

• Very scalable solution
• Providing very fast storage
• Very good integration with KVM, libvirt and OpenStack through Cinder

Read full review

• One thing we wish was done better is more guidance for building it out from day one. We did not know what we were doing and until we hired an implementation person that understood what we wanted to do. We spent a lot of time and money doing things over several times.
• Help customers hook up with talented (local) implementation specialists would be great.

Read full review

• Ceph is very difficult to set up when we used it. One had to be very careful in how they assigned their crush maps and cache tiering to get it to work right otherwise performance would be impacted and data would not be distributed evenly. From the .96 version I ran, it really is intended to be used for massive data centers in the petabytes. Beyond that the command line arguments for ceph-deploy and ceph are very involved. I would strongly recommend this as a back end for Open Stack with a dedicated Linux savvy storage engineer. Red Hat also said they are working to turn Calamari in to a full featured front end to manage OSD nodes which should make this much easier to manage in the future.
• It should not be run off of VMs themselves since it is not optimized for a VM Kernel. This advice is coming directly from Red Hat. Unfortunately this means that smaller use cases are out of the question since it literally requires 10 physical machines, each with their own OS to become individual OSD nodes.
• I believe this is an issue with the OSDs and not the monitors which ran fine for us in a virtual machine environment.
• We where looking at using this as a NFS work alike and in our experiments encountered a couple of issues. the MDS server struggled to mount the CephFS file system on more than a few systems without seizing up. This isn't a huge concern when it is used as a back end for Open Stack however when using this as shared storage for production data on a web cluster proved to be problematic to us. We also would have liked to have NFS access to the Ceph monitors so we could attach this to VMWare in order to store our VMDKs since VMWare does not support mounting CephFS. When we spoke with VMWare about 7 months ago they said NFS support is in the pipeline which will address all of these concerns.

Read full review

• Azure Blob Storage is just way cheaper than anything we could afford to do on-prem. Forecasting spend is way easier with predictable growth than it is with large capital expenditures every few years, and that ability to grow or shrink dynamically is simplifies things.

Read full review

• CephFS was unable to handle several mounts at the same time. We will revisit NFS capabilities once available.
• We gained quit a bit of experience with Ceph and we have a cluster on hand if our storage vendor doesn't pan out at any time in the future.
• It had a negative impact in the time it took for us to test set up and test the cluster. Like I explained earlier, it was quite difficult to set up for experimentation. That said though, we have a very broad understanding of Ceph for our future products.

Read full review