Additional info: (1) Possibly add steps to assign an instance to a zone-group and zone 2) Document ability to write to any location (RGW Multi-site).
Anjana, will you post the link to QE when it's available? Thanks!
(In reply to John Wilkins from comment #4) > Anjana, will you post the link to QE when it's available? Thanks! Sure, John! I will also add it to the bug.
https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/version-2/object-gateway-guide-for-ubuntu/ https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/version-2/object-gateway-guide-for-red-hat-enterprise-linux/
Please modify the master zone config steps in the doc. Refer to BZ 1360396(RGW multisite setup procedure for enabling sync on an existing cluster) c#6 posted by Casey.
Also need to document the following: 1. Modify zone to change master 2. Modify zone to change endpoint/port 3. Delete a zone/zonegroup 4. Rename a zone/zonegroup 5. Configure a zone as read-only (active-passive configuration)
Need to remove "Configuring a Secondary Zone Group" section. Please refer to https://bugzilla.redhat.com/show_bug.cgi?id=1309113#c7
In section 8.5.3. "Create a Master Zone", the zone create commands need to have --endpoints specified. # radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east --master --default --access-key={access-key} --secret={secret} --endpoints=http://rgw1:80 Also specifying what the access and secret keys in this section will be helpful as it is only mentioned at a later section 8.5.4.
Fixed. I added endpoints, but removed access key and secret since they aren't created until the next section, where we have to update the zone with them after creating the user.
(In reply to John Wilkins from comment #12) > Fixed. I added endpoints, but removed access key and secret since they > aren't created until the next section, where we have to update the zone with > them after creating the user. Thanks John.
Sorry for going back and forth, making a secondary zone read-only is one of the important use-cases. It would be good to have it documented in a separate section and add the contents from section 8.6.3, "If the secondary zone should not accept write operations, specify the --read-only flag to create an active-passive configuration between the master zone and the secondary zone." Also it might be worth mentioning how to convert it from r/o to r/w. This can be done by setting "--read-only=False" along with a "period update --commit"
Couple of additions and hopefully the last. 1. There is an admin command to see the sync status that might be helpful in checking if all the data is synced or how many shards are remaining etc. # radosgw-admin sync status The o/p looks something like this: realm f3239bc5-e1a8-4206-a81d-e1576480804d (earth) zonegroup c50dbb7e-d9ce-47cc-a8bb-97d9b399d388 (us) zone 4c453b70-4a16-4ce8-8185-1893b05d346e (us-west) metadata sync syncing full sync: 0/64 shards metadata is caught up with master incremental sync: 64/64 shards data sync source: 1ee9da3e-114d-4ae3-a8a4-056e8a17f532 (us-east) syncing full sync: 0/128 shards incremental sync: 128/128 shards data is caught up with source 2. At the end of section 8.6.6, mentioning that upon creating users and subusers in master zone, it should sync them to secondary zone and then they may create buckets/objects in either of the zones. Also, add that users have to be created only on master zone for syncing purposes while bucket can be created on either of the zones, but the request is always forwarded to the master zone. So customers have to keep in mind that they may create objects on the secondary zone when master zone is down, but bucket creation will fail. 3. We also need to add a section on disaster recovery failover/failback mechanism. If master cluster is down, in order to make the secondary zone fully functional, do the following: a. Make the secondary zone as master by running "zone modify" with parameter --master --default. b. Do a period update --commit. c. Restart the gateway. 4. To failback: a. Once the old master zone is up, run "radosgw-admin period pull --remote=<new-master-zone-id>" b. Now resume the old master zone's original status by running "zone modify --master --default". c. Run period update --commit and restart gateway @Casey, would you like to add or change anything in the above content?
Added two topics. https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/2/single/object-gateway-guide-for-red-hat-enterprise-linux#check_synchronization_status https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/2/single/object-gateway-guide-for-red-hat-enterprise-linux#failover_and_disaster_recovery
4.1.9. Rename a Realm Shilpa and I discussed this recently, and think it would be good to add another note that the rename is only applied locally, so the command should be run on each zone. (the realm name isn't part of the period, so it doesn't get propagated to other zones automatically) 4.3.1. Create a Zone It may be worth noting that if you provide a --rgw-zonegroup argument, the new zone is added to that zonegroup (as if you ran 'zonegroup add'). 4.3.2. Delete a Zone A potential landmine here. Deleting the zone will actually cause the 'period update --commit' command to fail. While it's useful to document the 'zone delete' command itself, I think we should also describe 'Permanently removing a zone from the realm' as a higher-level process. The steps involved here would be: $ radosgw-admin zonegroup remove --rgw-zonegroup=<name> --rgw-zone=<name> $ radosgw-admin period update --commit $ radosgw-admin zone delete --rgw-zone=<name> (and if the zone's data pools aren't going to be used elsewhere, they can be removed with 'rados rmpool') We may also want to document the 'zonegroup remove' command itself, which is the counterpart of 'zonegroup add'.
1. Added comments to rename a realm.https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/2/single/object-gateway-guide-for-red-hat-enterprise-linux#rename_a_realm 2. Added the zonegroup argument. https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/2/single/object-gateway-guide-for-red-hat-enterprise-linux#create_a_zone 3. Add procedure for deleting a zone. https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/2/single/object-gateway-guide-for-red-hat-enterprise-linux#delete_a_zone 4. Added zonegroup remove. https://access.qa.redhat.com/documentation/en/red-hat-ceph-storage/2/single/object-gateway-guide-for-red-hat-enterprise-linux#remove_a_zone_from_a_zone_group
Thanks John. Everything looks good. Moving to verified.