From c6400ed79b1233a2238342e4931edf341f1c7b9f Mon Sep 17 00:00:00 2001 From: Zac Dover Date: Sat, 8 Jul 2023 03:35:15 +1000 Subject: [PATCH] doc/radosgw: add Zonegroup policy explanation Add revised Zonegroup policy for "multi-zonegroups". This commit includes changes that Casey Bodley made in https://github.com/ceph/ceph/pull/52324#discussion_r1253482258 and that I have integrated into the docs only now. Co-authored-by: Casey Bodley Signed-off-by: Zac Dover --- doc/radosgw/multisite.rst | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/doc/radosgw/multisite.rst b/doc/radosgw/multisite.rst index 4c3722a603d53..847acce1ef79a 100644 --- a/doc/radosgw/multisite.rst +++ b/doc/radosgw/multisite.rst @@ -46,26 +46,24 @@ configurations for the Ceph Object Gateway: a global object namespace. This global object namespace ensures unique object IDs across zonegroups and zones. - It can be useful to create multiple zonegroups in cases where isolation of - the RADOS object data is desirable when those datasets exist in a shared - namespace of users and buckets. It might be that you have several connected - sites that share storage, but only require a single backup for purposes of - disaster recovery. In such a case, it could make sense to create several - zonegroups with only two zones each to avoid replicating all objects to all - zones. - - In other cases, it might make more sense to isolate RADOS object data in - separate realms, with each having a single zonegroup. Zonegroups provide + Each bucket is owned by the zonegroup where it was created (except where + overridden by the :ref:`LocationConstraint` on + bucket creation), and its object data will only replicate to other zones in + that zonegroup. Any request for data in that bucket that are sent to other + zonegroups will redirect to the zonegroup where the bucket resides. + + It can be useful to create multiple zonegroups when you want to share a + namespace of users and buckets across many zones, but isolate the object data + to a subset of those zones. It might be that you have several connected sites + that share storage, but only require a single backup for purposes of disaster + recovery. In such a case, it could make sense to create several zonegroups + with only two zones each to avoid replicating all objects to all zones. + + In other cases, it might make more sense to isolate things in separate + realms, with each realm having a single zonegroup. Zonegroups provide flexibility by making it possible to control the isolation of data and metadata separately. - Metadata (for example, users and buckets) replicates to all zonegroups, but - object data replicates only within a single zonegroup. A bucket is "owned" by - the zonegrup that created it (except in cases in which the - ``LocationConstraint`` has overridden this upon creation of the bucket). Any - request for data in that bucket that are sent to other zonegroups redirect to - the zonegroup where the bucket resides. - - **Multiple Realms:** Beginning with the Kraken release, the Ceph Object Gateway supports "realms", which are containers for zonegroups. Realms make it possible to set policies that apply to multiple zonegroups. Realms have a -- 2.39.5