Skip to content

Commit 60367d5

Browse files
authored
Merge pull request ceph#52360 from zdover23/wip-doc-2023-07-08-radosgw-multisite
doc/radosgw: add Zonegroup policy explanation Reviewed-by: Casey Bodley <[email protected]>
2 parents b985fad + c6400ed commit 60367d5

File tree

1 file changed

+15
-17
lines changed

1 file changed

+15
-17
lines changed

doc/radosgw/multisite.rst

Lines changed: 15 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -46,26 +46,24 @@ configurations for the Ceph Object Gateway:
4646
a global object namespace. This global object namespace ensures unique
4747
object IDs across zonegroups and zones.
4848

49-
It can be useful to create multiple zonegroups in cases where isolation of
50-
the RADOS object data is desirable when those datasets exist in a shared
51-
namespace of users and buckets. It might be that you have several connected
52-
sites that share storage, but only require a single backup for purposes of
53-
disaster recovery. In such a case, it could make sense to create several
54-
zonegroups with only two zones each to avoid replicating all objects to all
55-
zones.
56-
57-
In other cases, it might make more sense to isolate RADOS object data in
58-
separate realms, with each having a single zonegroup. Zonegroups provide
49+
Each bucket is owned by the zonegroup where it was created (except where
50+
overridden by the :ref:`LocationConstraint<s3_bucket_placement>` on
51+
bucket creation), and its object data will only replicate to other zones in
52+
that zonegroup. Any request for data in that bucket that are sent to other
53+
zonegroups will redirect to the zonegroup where the bucket resides.
54+
55+
It can be useful to create multiple zonegroups when you want to share a
56+
namespace of users and buckets across many zones, but isolate the object data
57+
to a subset of those zones. It might be that you have several connected sites
58+
that share storage, but only require a single backup for purposes of disaster
59+
recovery. In such a case, it could make sense to create several zonegroups
60+
with only two zones each to avoid replicating all objects to all zones.
61+
62+
In other cases, it might make more sense to isolate things in separate
63+
realms, with each realm having a single zonegroup. Zonegroups provide
5964
flexibility by making it possible to control the isolation of data and
6065
metadata separately.
6166

62-
Metadata (for example, users and buckets) replicates to all zonegroups, but
63-
object data replicates only within a single zonegroup. A bucket is "owned" by
64-
the zonegrup that created it (except in cases in which the
65-
``LocationConstraint`` has overridden this upon creation of the bucket). Any
66-
request for data in that bucket that are sent to other zonegroups redirect to
67-
the zonegroup where the bucket resides.
68-
6967
- **Multiple Realms:** Beginning with the Kraken release, the Ceph Object
7068
Gateway supports "realms", which are containers for zonegroups. Realms make
7169
it possible to set policies that apply to multiple zonegroups. Realms have a

0 commit comments

Comments
 (0)