[RGW] Setup 2 zones within a cluster does not sync data
Hi, Currently I'm testing replication ability between 2 zones in the same cluster. But only metadata is synced, not the data. I checked endpoints, system_key,... all good. If anyone have any idea, please guide me to resolve this situation. Thanks The radosgw shows this log on both side, primary and secondary: rgw rados thread: ERROR: failed to run sync ... RGW-SYNC:data:sync:shard[54]: ERROR: failed to read remote data log info: ret=-5 RGW-SYNC:data:sync:shard[90]: ERROR: failed to read remote data log info: ret=-5 meta sync: ERROR: RGWBackoffControlCR called coroutine returned -5 meta sync: ERROR: RGWBackoffControlCR called coroutine returned -5 Here is my configure (it might be long): zonegroup hn which contains hn-1 and hn-2, each zone have its own endpoint and radosgw instance on two different node: { "id": "36c29ef1-332b-4d6e-a341-ecc9cc2ef281", "epoch": 4, "predecessor_uuid": "e1981515-7355-4029-b26c-6be3de943be0", "sync_status": [], "period_map": { "id": "36c29ef1-332b-4d6e-a341-ecc9cc2ef281", "zonegroups": [ { "id": "9ced5b3b-5322-4ec9-862c-521bfff85c91", "name": "hn", "api_name": "hn", "is_master": true, "endpoints": [ "http://10.3.55.66:8080" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "zones": [ { "id": "0c5aac15-c899-46aa-bff9-353bf17f9602", "name": "hn-2", "endpoints": [ "http://10.3.53.107:8080" ], "log_meta": false, "log_data": true, "bucket_index_max_shards": 11, "read_only": false, "tier_type": "", "sync_from_all": true, "sync_from": [], "redirect_zone": "", "supported_features": [ "compress-encrypted", "resharding" ] }, { "id": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "name": "hn-1", "endpoints": [ "http://10.3.55.66:8080" ], "log_meta": false, "log_data": true, "bucket_index_max_shards": 11, "read_only": false, "tier_type": "", "sync_from_all": true, "sync_from": [], "redirect_zone": "", "supported_features": [ "compress-encrypted", "resharding" ] } ], "placement_targets": [ { "name": "default-placement", "tags": [], "storage_classes": [ "STANDARD" ] } ], "default_placement": "default-placement", "realm_id": "cb7337a4-5b38-41de-9763-ef7e22a79e17", "sync_policy": { "groups": [] }, "enabled_features": [ "resharding" ] } ], "short_zone_ids": [ { "key": "0c5aac15-c899-46aa-bff9-353bf17f9602", "val": 3534260942 }, { "key": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "val": 1656529937 } ] }, "master_zonegroup": "9ced5b3b-5322-4ec9-862c-521bfff85c91", "master_zone": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "period_config": { "bucket_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, "user_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, ...ratelimit... }, "realm_id": "cb7337a4-5b38-41de-9763-ef7e22a79e17", "realm_name": "ss-realm", "realm_epoch": 2 } zone hn-1: { "id": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "name": "hn-1", "domain_root": "hn-1.rgw.meta:root", "control_pool": "hn-1.rgw.control", "gc_pool": "hn-1.rgw.log:gc", "lc_pool": "hn-1.rgw.log:lc", "log_pool": "hn-1.rgw.log", "intent_log_pool": "hn-1.rgw.log:intent", "usage_log_pool": "hn-1.rgw.log:usage", "roles_pool": "hn-1.rgw.meta:roles", "reshard_pool": "hn-1.rgw.log:reshard", "user_keys_pool": "hn-1.rgw.meta:users.keys", "user_email_pool": "hn-1.rgw.meta:users.email", "user_swift_pool": "hn-1.rgw.meta:users.swift", "user_uid_pool": "hn-1.rgw.meta:users.uid", "otp_pool": "hn-1.rgw.otp", "system_key": { "access_key": "LIW8M2OTOCOHA41OJUGO", "secret_key": "KxD3fIWrW5GMpaY1ynCp10j2ccCP3fkfCcgyNBDT" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "hn-1.rgw.buckets.index", "storage_classes": { "STANDARD": { "data_pool": "hn-1.rgw.buckets.data" } }, "data_extra_pool": "hn-1.rgw.buckets.non-ec", "index_type": 0, "inline_data": true } } ], "realm_id": "cb7337a4-5b38-41de-9763-ef7e22a79e17", "notif_pool": "hn-1.rgw.log:notif" } zone hn-2: { "id": "0c5aac15-c899-46aa-bff9-353bf17f9602", "name": "hn-2", "domain_root": "hn-2.rgw.meta:root", "control_pool": "hn-2.rgw.control", "gc_pool": "hn-2.rgw.log:gc", "lc_pool": "hn-2.rgw.log:lc", "log_pool": "hn-2.rgw.log", "intent_log_pool": "hn-2.rgw.log:intent", "usage_log_pool": "hn-2.rgw.log:usage", "roles_pool": "hn-2.rgw.meta:roles", "reshard_pool": "hn-2.rgw.log:reshard", "user_keys_pool": "hn-2.rgw.meta:users.keys", "user_email_pool": "hn-2.rgw.meta:users.email", "user_swift_pool": "hn-2.rgw.meta:users.swift", "user_uid_pool": "hn-2.rgw.meta:users.uid", "otp_pool": "hn-2.rgw.otp", "system_key": { "access_key": "LIW8M2OTOCOHA41OJUGO", "secret_key": "KxD3fIWrW5GMpaY1ynCp10j2ccCP3fkfCcgyNBDT" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "hn-2.rgw.buckets.index", "storage_classes": { "STANDARD": { "data_pool": "hn-2.rgw.buckets.data" } }, "data_extra_pool": "hn-2.rgw.buckets.non-ec", "index_type": 0, "inline_data": true } } ], "realm_id": "cb7337a4-5b38-41de-9763-ef7e22a79e17", "notif_pool": "hn-2.rgw.log:notif" }
Hi, according to [1] those are non-fatal errors:
These are the same non-fatal errors from above, where 404 errors from other zones are converted to -ENOENT. The RGWBackoffControlCR will continue to poll these objects for changes. These ERROR messages are unnecessarily spammy though, so I'd be in favor of removing them.
Can you show the sync status? Have you tried a full sync? Regards, Eugen [1] https://www.spinics.net/lists/ceph-users/msg53477.html Zitat von Huy Nguyen <viplanghe6@gmail.com>:
Hi, Currently I'm testing replication ability between 2 zones in the same cluster. But only metadata is synced, not the data. I checked endpoints, system_key,... all good. If anyone have any idea, please guide me to resolve this situation. Thanks
The radosgw shows this log on both side, primary and secondary:
rgw rados thread: ERROR: failed to run sync ... RGW-SYNC:data:sync:shard[54]: ERROR: failed to read remote data log info: ret=-5 RGW-SYNC:data:sync:shard[90]: ERROR: failed to read remote data log info: ret=-5 meta sync: ERROR: RGWBackoffControlCR called coroutine returned -5 meta sync: ERROR: RGWBackoffControlCR called coroutine returned -5
Here is my configure (it might be long):
zonegroup hn which contains hn-1 and hn-2, each zone have its own endpoint and radosgw instance on two different node: { "id": "36c29ef1-332b-4d6e-a341-ecc9cc2ef281", "epoch": 4, "predecessor_uuid": "e1981515-7355-4029-b26c-6be3de943be0", "sync_status": [], "period_map": { "id": "36c29ef1-332b-4d6e-a341-ecc9cc2ef281", "zonegroups": [ { "id": "9ced5b3b-5322-4ec9-862c-521bfff85c91", "name": "hn", "api_name": "hn", "is_master": true, "endpoints": [ "http://10.3.55.66:8080" ], "hostnames": [], "hostnames_s3website": [], "master_zone": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "zones": [ { "id": "0c5aac15-c899-46aa-bff9-353bf17f9602", "name": "hn-2", "endpoints": [ "http://10.3.53.107:8080" ], "log_meta": false, "log_data": true, "bucket_index_max_shards": 11, "read_only": false, "tier_type": "", "sync_from_all": true, "sync_from": [], "redirect_zone": "", "supported_features": [ "compress-encrypted", "resharding" ] }, { "id": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "name": "hn-1", "endpoints": [ "http://10.3.55.66:8080" ], "log_meta": false, "log_data": true, "bucket_index_max_shards": 11, "read_only": false, "tier_type": "", "sync_from_all": true, "sync_from": [], "redirect_zone": "", "supported_features": [ "compress-encrypted", "resharding" ] } ], "placement_targets": [ { "name": "default-placement", "tags": [], "storage_classes": [ "STANDARD" ] } ], "default_placement": "default-placement", "realm_id": "cb7337a4-5b38-41de-9763-ef7e22a79e17", "sync_policy": { "groups": [] }, "enabled_features": [ "resharding" ] } ], "short_zone_ids": [ { "key": "0c5aac15-c899-46aa-bff9-353bf17f9602", "val": 3534260942 }, { "key": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "val": 1656529937 } ] }, "master_zonegroup": "9ced5b3b-5322-4ec9-862c-521bfff85c91", "master_zone": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "period_config": { "bucket_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, "user_quota": { "enabled": false, "check_on_raw": false, "max_size": -1, "max_size_kb": 0, "max_objects": -1 }, ...ratelimit... }, "realm_id": "cb7337a4-5b38-41de-9763-ef7e22a79e17", "realm_name": "ss-realm", "realm_epoch": 2 }
zone hn-1:
{ "id": "2760e65c-b9d1-415a-929e-f5de2098d5cf", "name": "hn-1", "domain_root": "hn-1.rgw.meta:root", "control_pool": "hn-1.rgw.control", "gc_pool": "hn-1.rgw.log:gc", "lc_pool": "hn-1.rgw.log:lc", "log_pool": "hn-1.rgw.log", "intent_log_pool": "hn-1.rgw.log:intent", "usage_log_pool": "hn-1.rgw.log:usage", "roles_pool": "hn-1.rgw.meta:roles", "reshard_pool": "hn-1.rgw.log:reshard", "user_keys_pool": "hn-1.rgw.meta:users.keys", "user_email_pool": "hn-1.rgw.meta:users.email", "user_swift_pool": "hn-1.rgw.meta:users.swift", "user_uid_pool": "hn-1.rgw.meta:users.uid", "otp_pool": "hn-1.rgw.otp", "system_key": { "access_key": "LIW8M2OTOCOHA41OJUGO", "secret_key": "KxD3fIWrW5GMpaY1ynCp10j2ccCP3fkfCcgyNBDT" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "hn-1.rgw.buckets.index", "storage_classes": { "STANDARD": { "data_pool": "hn-1.rgw.buckets.data" } }, "data_extra_pool": "hn-1.rgw.buckets.non-ec", "index_type": 0, "inline_data": true } } ], "realm_id": "cb7337a4-5b38-41de-9763-ef7e22a79e17", "notif_pool": "hn-1.rgw.log:notif" }
zone hn-2:
{ "id": "0c5aac15-c899-46aa-bff9-353bf17f9602", "name": "hn-2", "domain_root": "hn-2.rgw.meta:root", "control_pool": "hn-2.rgw.control", "gc_pool": "hn-2.rgw.log:gc", "lc_pool": "hn-2.rgw.log:lc", "log_pool": "hn-2.rgw.log", "intent_log_pool": "hn-2.rgw.log:intent", "usage_log_pool": "hn-2.rgw.log:usage", "roles_pool": "hn-2.rgw.meta:roles", "reshard_pool": "hn-2.rgw.log:reshard", "user_keys_pool": "hn-2.rgw.meta:users.keys", "user_email_pool": "hn-2.rgw.meta:users.email", "user_swift_pool": "hn-2.rgw.meta:users.swift", "user_uid_pool": "hn-2.rgw.meta:users.uid", "otp_pool": "hn-2.rgw.otp", "system_key": { "access_key": "LIW8M2OTOCOHA41OJUGO", "secret_key": "KxD3fIWrW5GMpaY1ynCp10j2ccCP3fkfCcgyNBDT" }, "placement_pools": [ { "key": "default-placement", "val": { "index_pool": "hn-2.rgw.buckets.index", "storage_classes": { "STANDARD": { "data_pool": "hn-2.rgw.buckets.data" } }, "data_extra_pool": "hn-2.rgw.buckets.non-ec", "index_type": 0, "inline_data": true } } ], "realm_id": "cb7337a4-5b38-41de-9763-ef7e22a79e17", "notif_pool": "hn-2.rgw.log:notif" } _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, Thanks for you reply. I'm not sure what do you means by full sync. I tried data/metadata sync init/run but nothing happened. I tried with a fresh cluster but still can't make it work. Here is the sync status: realm 26c6fd00-56f3-473f-8d9b-e583efb58a2b (multi-region) zonegroup bc664368-6a1c-43fb-9e86-99b62e579236 (hn) zone 92b1769f-8266-495d-a6df-3b89797f21d5 (hn1) current time 2024-07-24T07:56:34Z zonegroup features enabled: resharding disabled: compress-encrypted metadata sync no sync (zone is master) data sync source: 4fe607da-8eb7-44ae-a34d-e6b5e47b6065 (hn2) syncing full sync: 0/128 shards incremental sync: 128/128 shards data is caught up with source
I'm not sure what's wrong, it says "data is caught up with source", how do you determine that it's not? Can you explain in more detail? I currently only have two different test clusters which I had to fix, they weren't replicating either, but due to a certificate issue. But since you don't use https endpoints this isn't applicable to your situation. There are people with way more rgw experience on this list than me, I hope someone can chime in. Zitat von Huy Nguyen <viplanghe6@gmail.com>:
Hi, Thanks for you reply. I'm not sure what do you means by full sync. I tried data/metadata sync init/run but nothing happened. I tried with a fresh cluster but still can't make it work. Here is the sync status:
realm 26c6fd00-56f3-473f-8d9b-e583efb58a2b (multi-region) zonegroup bc664368-6a1c-43fb-9e86-99b62e579236 (hn) zone 92b1769f-8266-495d-a6df-3b89797f21d5 (hn1) current time 2024-07-24T07:56:34Z zonegroup features enabled: resharding disabled: compress-encrypted metadata sync no sync (zone is master) data sync source: 4fe607da-8eb7-44ae-a34d-e6b5e47b6065 (hn2) syncing full sync: 0/128 shards incremental sync: 128/128 shards data is caught up with source _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Yes, that is the strange part. It says "data is caught up with source", but in secondary data pool (hn2.rgw.buckets.data), nothing in there. The data has been uploaded before the multisite setup is not replicated.
The data has been uploaded before the multisite setup is not replicated.
Do you mean that you uploaded the data while there was not replication zone? Does it sync anything if you upload new data? Zitat von Huy Nguyen <viplanghe6@gmail.com>:
Yes, that is the strange part. It says "data is caught up with source", but in secondary data pool (hn2.rgw.buckets.data), nothing in there. The data has been uploaded before the multisite setup is not replicated. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi Huy, The sync result you posted earlier appears to be from master zone. Have you checked the secondary zone with 'radosgw-admin sync status --rgw-zone=hn2'? Can you check that: - sync user exists in the realm with 'radosgw-admin user list --rgw-realm=multi-region' - sync user's access_key and secret_key are set on both zones with 'radosgw-admin zone get --rgw-zone=hn1' and 'radosgw-admin zone get --rgw-zone=hn2' - you pulled the realm on both RGWs after deployment - you restarted both gateways. Thing is you need to respect a certain order to set up the synchronization ; the sync user has to be part of the realm and its credentials need to be set on both zones, but you'll only be able to create this sync user after the realm is created which implies creating the master and default zonegroup and creating (or setting) a master and defaut zone to this zonegroup. If the master and default zone already exists with buckets and data in it, you could try these commands below: - Set vars: realm='multi-region' zonegroup='hn' master_zone='hn1' secondary_zone='hn2' syncuser='synchronization-user' master_endpoint='http://10.3.55.66:8080' secondary_endpoint='http://10.3.53.107:8080' - create realm: radosgw-admin realm create --rgw-realm=${realm} --default - create master and default zonegroup: radosgw-admin zonegroup create --rgw-zonegroup=${zonegroup} --endpoints=${master_endpoint} --rgw-realm=${realm} --master --default - create (or modify if exist) master and default zone **without** access and secret keys (since the sync user does not exist at this time): radosgw-admin zone [create|modify] --rgw-zonegroup=${zonegroup} --rgw-zone=${master_zone} --endpoints=${master_endpoint} --master --default - commit changes: radosgw-admin period update --commit - restart master zone's RGW: ceph orch daemon restart $(ceph orch ps | grep rgw.${realm}-${zonegroup}-${master_zone} | awk '{print $1}') - create sync user in the realm radosgw-admin user create --uid="${syncuser}" --display-name="Synchronization User" --system - set access_key and secret_key (needs jq) access_key=$(radosgw-admin user info --uid=${syncuser} --format json | jq -r '.keys[].access_key') secret_key=$(radosgw-admin user info --uid=${syncuser} --format json | jq -r '.keys[].secret_key') - create secondary zone **with** access_key and secret_key (now that the sync user exists) radosgw-admin zone create --rgw-zonegroup=${zonegroup} --rgw-zone=${secondary_zone} --endpoints=${secondary_endpoint} --access-key=${access_key} --secret-key=${secret_key} - modify master zone to add access_key and secret_key radosgw-admin zone modify --rgw-zonegroup=${zonegroup} --rgw-zone=${master_zone} --endpoints=${master_endpoint} --access-key=${access_key} --secret-key=${secret_key} --master --default - commit changes: radosgw-admin period update --commit - pull the realm on both gateways: on master zone's RGW: radosgw-admin realm pull --url ${secondary_endpoint} --access-key ${access_key} --secret-key ${secret_key} --rgw-zone=${master_zone} on secondary zone's RGW: radosgw-admin realm pull --url ${master_endpoint} --access-key ${access_key} --secret-key ${secret_key} --rgw-zone=${secondary_zone} Both commands should output the same result. - restart both gateways: ceph orch daemon restart $(ceph orch ps | grep rgw.${realm}-${zonegroup}-${master_zone} | awk '{print $1}') ceph orch daemon restart $(ceph orch ps | grep rgw.${realm}-${zonegroup}-${secondary_zone} | awk '{print $1}') - watch for sync status: watch radosgw-admin sync status --rgw-zone=${master_zone} watch radosgw-admin sync status --rgw-zone=${secondary_zone} - watch for RGW logs (journalctl or /var/log/ceph/$(ceph fsid)/ceph-client.rgw.*) - waych for any sync errors: radosgw-admin sync error list Uploading new data should not be necessary to trigger the synchronization between the 2 zones. Synchronization should happen right away. Also, you shouldn't have to create any rados pools. RGWs take care of each pool and hn[1-2].rgw.bucket.data pools should get created as soon as you upload new data or data synchronization starts. Been playing a bit on 19.1.0 RC lately and had success with these commands. I hope there's no typo. Otherwise, let us know. Regards, Frédéric. ----- Le 24 Juil 24, à 10:00, Huy Nguyen viplanghe6@gmail.com a écrit :
Hi, Thanks for you reply. I'm not sure what do you means by full sync. I tried data/metadata sync init/run but nothing happened. I tried with a fresh cluster but still can't make it work. Here is the sync status:
realm 26c6fd00-56f3-473f-8d9b-e583efb58a2b (multi-region) zonegroup bc664368-6a1c-43fb-9e86-99b62e579236 (hn) zone 92b1769f-8266-495d-a6df-3b89797f21d5 (hn1) current time 2024-07-24T07:56:34Z zonegroup features enabled: resharding disabled: compress-encrypted metadata sync no sync (zone is master) data sync source: 4fe607da-8eb7-44ae-a34d-e6b5e47b6065 (hn2) syncing full sync: 0/128 shards incremental sync: 128/128 shards data is caught up with source _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
I'm very grateful for your detailed guide. I follow your commands, also upload some objects to hn1 before creating hn2. After ensuring realm pull on both endpoints output the same result, I need to upload one more file to hn1 to trigger the replication on old objects and new objects. This is a bit strange, but anyway, your instructions work well. Thanks
participants (3)
-
Eugen Block
-
Frédéric Nass
-
Huy Nguyen