How do you handle large Ceph object storage cluster?
Hi Everyone, My company is dealing with quite large Ceph cluster (>10k OSDs, >60 PB of data). It is entirely dedicated to object storage with S3 interface. Maintenance and its extension are getting more and more problematic and time consuming. We consider to split it to two or more completely separate clusters (without replication of data among them) and create S3 layer of abstraction with some additional metadata that will allow us to use these 2+ physically independent instances as a one logical cluster. Additionally, newest data is the most demanded data, so we have to spread it equally among clusters to avoid skews in cluster load. Do you have any similar experience? How did you handle it? Maybe you have some advice? I'm not a Ceph expert. I'm just a Ceph's user and software developer who does not like to duplicate someone's job. Best, Paweł
Well you are probably in the top 1% of cluster size. I would guess that trying to cut your existing cluster in half while not encountering any downtime as you shuffle existing buckets between old cluster and new cluster would be harder than redirecting all new buckets (or users) to a second cluster. Obviously you will need to account for each cluster having a single bucket namespace when attempting to redirect requests to a cluster of clusters. Lots of ways to skin this cat and it would be a large and complicated architectural undertaking. Respectfully, *Wes Dillingham* wes@wesdillingham.com LinkedIn <http://www.linkedin.com/in/wesleydillingham> On Mon, Oct 16, 2023 at 10:53 AM <pawel.przestrzelski@gmail.com> wrote:
Hi Everyone,
My company is dealing with quite large Ceph cluster (>10k OSDs, >60 PB of data). It is entirely dedicated to object storage with S3 interface. Maintenance and its extension are getting more and more problematic and time consuming. We consider to split it to two or more completely separate clusters (without replication of data among them) and create S3 layer of abstraction with some additional metadata that will allow us to use these 2+ physically independent instances as a one logical cluster. Additionally, newest data is the most demanded data, so we have to spread it equally among clusters to avoid skews in cluster load.
Do you have any similar experience? How did you handle it? Maybe you have some advice? I'm not a Ceph expert. I'm just a Ceph's user and software developer who does not like to duplicate someone's job.
Best, Paweł _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
[...] (>10k OSDs, >60 PB of data).
6TBs on average per OSD? Hopully SSDs or RAID10 (or low-number, 3-5) RAID5.
It is entirely dedicated to object storage with S3 interface. Maintenance and its extension are getting more and more problematic and time consuming.
Ah the joys of a single large unified storage pool :-). https://www.sabi.co.uk/blog/0804apr.html?080417#080417
We consider to split it to two or more completely separate clusters
I would suggest doing it 1-2 years ago...
create S3 layer of abstraction with some additional metadata that will allow us to use these 2+ physically independent instances as a one logical cluster.
That's what the bucket hierarchy in a Ceph cluster instance already does. What your layer is going to do is either: 1) Lookup the object ID in a list of instances, and fetch the object from the instance that validates the object ID; 2) Maintain a huge table of all object IDs and which instances they are in. But 1) is basically what CRUSH already does and 2) means giving up the Ceph "decentralized" philosophy based on CRUSH. BTW one old practice that so few systems follow is to use as object keys neither addresses nor identifiers, but *both*: first access the address treating it as a hint, check that the identifier matches, if not do a slower lookup using the object identifier part to find the actual address.
Additionally, newest data is the most demanded data, so we have to spread it equally among clusters to avoid skews in cluster load.
I usually do the opposite, but that depends on your application. My practice is to recognize that data is indeed usually stratified by date, and regard filesystem instances as "silos" and create a new filesystems instance every some months or years, and direct all new file creation to the latest instance, and then get rid progressively of the older instances or copy their "active" data onwards into the new instance, and the "inactive" data to offline storage. http://www.sabi.co.uk/blog/12-fou.html?121218b#121218b If you really need to keep all data forever online, which is usually not the case (that's why there are laws that expire matters after N years) the second best option is to keep old silos powered up indefinitely, and they will take very little attention beyond refreshing the hardware periodically and migrating the data to new instances when that stops being economical.
participants (3)
-
pawel.przestrzelski@gmail.com
-
pg@ceph.list.sabi.co.UK
-
Wesley Dillingham