I don't have a strong opinion about separate pools for index and data-extra. It really depends on your rquirements wrt tenant segregation, how strict it has to be. One could argue that even with separate pools the stored data is still on the same OSDs, so you might want to consider setting up a different device class for a set of OSDs to physically segratate data. If that's not critical in your setup, having a shared index pool might be a better option, except if tenants are not supposed to have knowledge of any bucket metadata etc.

We are in the middle of such a discussion with a customer right now, if tenant separation on bucket level is sufficient or not. If the requirements change, they will have options to adapt, like separate realms and RGW services.

Zitat von Rok Jaklič <[email protected]>:

We do not use multisite configuration.

However is it advisable to create a new pool also for index-pool and
data-extra-pool maybe?

Rok

On Wed, Apr 15, 2026 at 2:12 PM Daniel Parkes <[email protected]> wrote:

Hi,

Yes, we have it in the docs,
https://docs.ceph.com/en/latest/radosgw/placement/#placement-targets :

[image: image.png]

On Wed, Apr 15, 2026 at 2:06 PM Eugen Block via ceph-users <
[email protected]> wrote:

It didn't work in my tests without a realm, so I don't believe grok
:-D But I'd love to be proven wrong.

Zitat von Rok Jaklič <[email protected]>:

> There is:
>
> [root@ctplmon1 ~]# radosgw-admin realm list
> {
>     "default_info": "",
>     "realms": []
> }
> [root@ctplmon1 ~]# radosgw-admin realm get-default
> No default realm is set
> [root@ctplmon1 ~]# radosgw-admin period list
> {
>     "periods": []
> }
> [root@ctplmon1 ~]# radosgw-admin zonegroup list
> {
>     "default_info": "b1e0d55c-f7cb-4e73-b1cb-6cffa1fd6578",
>     "zonegroups": [
>         "default"
>     ]
> }
> [root@ctplmon1 ~]# radosgw-admin zone list
> {
>     "default_info": "c2c70444-7a41-4acd-a0d0-9f87d324ec72",
>     "zones": [
>         "default"
>     ]
> }
>
> Since there is no realm set, I can skip radosgw-admin period update
> --commit entirely if grok is to be believed?
>
> On Wed, Apr 15, 2026 at 11:54 AM Eugen Block via ceph-users <
> [email protected]> wrote:
>
>>  From my understanding the new placement will not be available if the
>> period can't be updated. Your zonegroup/zone configuration seems off
>> compared to the test cluster. Is there a default zonegroup/zone?
>>
>> Zitat von Rok Jaklič via ceph-users <[email protected]>:
>>
>> > So I've created a little plan on how to create a new profile and
assign
>> new
>> > S3 users to EC 8+3 pool. Idea is that all new s3 users are using a
new
>> > pool, and old ones pool with EC 3+2 and data is intact.
>> >
>> > ---
>> > ceph osd erasure-code-profile set ec-83-profile k=8 m=3
>> > crush-failure-domain=host
>> > ceph osd pool create rgw.buckets.ec-83.data 256 erasure ec-83-profile
>> > ceph osd pool application enable rgw.buckets.ec-83.data rgw
>> >
>> > radosgw-admin zonegroup placement add --placement-id=ec-83-placement
>> >
>> > radosgw-admin zone placement add \
>> >   --placement-id ec-83-placement \
>> >   --data-pool rgw.buckets.ec-83.data \
>> >   --index-pool default.rgw.buckets.index \
>> >   --data-extra-pool default.rgw.buckets.non-ec \
>> >   --placement-index-type 0
>> >
>> > radosgw-admin period update --commit
>> >
>> > # restart rgw
>> > systemctl restart ceph-radosgw.target
>> > # verify the new placement
>> > radosgw-admin zone get | grep -A 20 "ec-83-placement"
>> >
>> > # for new s3 users, set the default placement
>> > radosgw-admin user create --uid=<user> --tenant=<tenant>
>> > --placement-id=ec-83-placement
>> > ---
>> >
>> > It seems to work on "test cluster", however I get an error on:
>> >
>> > [root@a8-mon1 ~]# radosgw-admin period update --commit
>> > cannot commit period: period does not have a master zone of a master
>> > zonegroup
>> > failed to commit period: (22) Invalid argument
>> >
>> > Do I actually need to run this command or is "rgw restart" enough?
>> >
>> > Any comments appriciated.
>> >
>> > Rok
>> >
>> >
>> > On Fri, Apr 3, 2026 at 12:42 PM Rok Jaklič via ceph-users <
>> > [email protected]> wrote:
>> >
>> >> Hi,
>> >>
>> >> we expanded the cluster to 12 nodes with 28 osds, but we are still
>> running
>> >> on EC 3+2, since we started cluster with 6 nodes. We would like to
>> change
>> >> it to EC 6+3 or even EC 8+3? Is this reasonable or will 8+3 take too
>> much
>> >> CPU/network capacities? Should I use isa/isa-l instead of jerasure?
>> >>
>> >> Can anyone share experience with 8+3?
>> >>
>> >> Kind regards,
>> >> Rok
>> >> _______________________________________________
>> >> ceph-users mailing list -- [email protected]
>> >> To unsubscribe send an email to [email protected]
>> >>
>> > _______________________________________________
>> > ceph-users mailing list -- [email protected]
>> > To unsubscribe send an email to [email protected]
>>
>>
>> _______________________________________________
>> ceph-users mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>


_______________________________________________
ceph-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]




_______________________________________________
ceph-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to