Op 21 apr 2024 om 17:14 heeft Anthony D'Atri <aad@dreamsnake.net> het volgende geschreven:

Vendor lock-in only benefits vendors.

Strictly speaking, that isn’t necessarily true. Proprietary standards and the like *can* enhance user experience in some cases. Making it intentionally difficult to migrate is another story.

You’ll pay outrageously for support / maint then your gear goes EOL and you’re trolling eBay for parts.

With Ceph you use commodity servers, you can swap 100% of the hardware without taking downtime with servers and drives of your choice. And you get the source code so worst case you can fix or customize. Ask me sometime about my experience with a certain proprietary HW vendor.

Longhorn , openEBS I don’t know much about. I suspect that they don’t offer the richness of Ceph and that their communities are much smaller.

Of course we’re biased here;)

...

On Apr 21, 2024, at 5:21 AM, sebcio_t@o2.pl wrote:

Hi, I have problem to answer to this question: Why CEPH is better than other storage solutions?

I know this high level texts about - scalability, - flexibility, - distributed, - cost-Effectiveness

What convince me, but could be received also against, is ceph as a product has everything what I need it mean: block storage (RBD), file storage (CephFS), object storage (S3, Swift) and "plugins" to run NFS, NVMe over Fabric, NFS on object storage.

Also many other features which are usually sold as a option (mirroring, geo replication, etc) in paid solutions. I have problem to write it done piece by piece. I want convince my managers we are going in good direction.

Why not something from robin.io or purestorage, netapp, dell/EMC. From opensource longhorn or openEBS.

If you have ideas please write it.

Thanks, S. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io

---

ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io

Den tis 23 apr. 2024 kl 11:32 skrev Frédéric Nass <frederic.nass@univ-lorraine.fr>:

Ceph is strongly consistent. Either you read/write objects/blocs/files with an insured strong consistency OR you don't. Worst thing you can expect from Ceph, as long as it's been properly designed, configured and operated is a temporary loss of access to the data.

This is often more important than you think. All centralized storage systems will have to face some kind of latency when sending data over the network, when splitting the data into replicas or erasure coding shards, when waiting for all copies/shards are actually finished written (perhaps via journals) to the final destination and then lastly for the write to be acknowledged back to the writing client. If some vendor says that "because of our special code, this part takes zero time", they are basically telling you that they are lying about the status of the write in order to finish more quickly, because this wins them contracts or wins competitions. It will not win you any smiles when there is an incident and data that was ACKed to be on disk suddenly isn't because some write cache lost power at the same time as the storage box and now some database have half-written transactions in it. Ceph is by no means the fastest possible way to store data on a network, but it is very good while still retaining the strong consistencies mentioned by Frederic above allowing for many clients to do many IOs in parallel against the cluster. -- May the most significant bit of your life be positive.

Exactly, strong consistency is why we chose Ceph over other SDS solutions back in 2014 (and disabled any non persistent cache along the IO path like HDD disk cache). A major power outage in our town a few years back (a few days before Christmas) and a ups malfunction has proven us right. Another reason to adopt Ceph today is that a cluster you build today to match a specific workload (lets say capacity) will accommodate any future workloads (for example performance) you may have tomorrow, simply by adding specific nodes to the cluster whatever the hardware will look like in decades. Regards, Frédéric. ----- Le 23 Avr 24, à 13:04, Janne Johansson icepic.dz@gmail.com a écrit :

Den tis 23 apr. 2024 kl 11:32 skrev Frédéric Nass <frederic.nass@univ-lorraine.fr>:

...

Ceph is strongly consistent. Either you read/write objects/blocs/files with an insured strong consistency OR you don't. Worst thing you can expect from Ceph, as long as it's been properly designed, configured and operated is a temporary loss of access to the data.

This is often more important than you think. All centralized storage systems will have to face some kind of latency when sending data over the network, when splitting the data into replicas or erasure coding shards, when waiting for all copies/shards are actually finished written (perhaps via journals) to the final destination and then lastly for the write to be acknowledged back to the writing client. If some vendor says that "because of our special code, this part takes zero time", they are basically telling you that they are lying about the status of the write in order to finish more quickly, because this wins them contracts or wins competitions.

It will not win you any smiles when there is an incident and data that was ACKed to be on disk suddenly isn't because some write cache lost power at the same time as the storage box and now some database have half-written transactions in it. Ceph is by no means the fastest possible way to store data on a network, but it is very good while still retaining the strong consistencies mentioned by Frederic above allowing for many clients to do many IOs in parallel against the cluster.

-- May the most significant bit of your life be positive.