]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/radosgw: add Zonegroup policy explanation 52360/head
authorZac Dover <zac.dover@proton.me>
Fri, 7 Jul 2023 17:35:15 +0000 (03:35 +1000)
committerZac Dover <zac.dover@proton.me>
Fri, 7 Jul 2023 17:35:15 +0000 (03:35 +1000)
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 <cbodley@redhat.com>
Signed-off-by: Zac Dover <zac.dover@proton.me>
doc/radosgw/multisite.rst

index 4c3722a603d532425fefd072826107af13b80b69..847acce1ef79a0012ad86b39137dd058fd905295 100644 (file)
@@ -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<s3_bucket_placement>` 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