You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Ivan Andika (Jira)" <ji...@apache.org> on 2025/02/11 08:10:00 UTC

[jira] [Comment Edited] (HDDS-12307) Realtime Cross-Region Bucket Replication

    [ https://issues.apache.org/jira/browse/HDDS-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925887#comment-17925887 ] 

Ivan Andika edited comment on HDDS-12307 at 2/11/25 8:09 AM:
-------------------------------------------------------------

This is still in a very early phase. Any ideas are welcome.


was (Author: JIRAUSER298977):
This is still in a very early phase. Any ideas welcome.

> Realtime Cross-Region Bucket Replication
> ----------------------------------------
>
>                 Key: HDDS-12307
>                 URL: https://issues.apache.org/jira/browse/HDDS-12307
>             Project: Apache Ozone
>          Issue Type: New Feature
>            Reporter: Ivan Andika
>            Assignee: Ivan Andika
>            Priority: Major
>
> Currently, there are a few cross-regions (geo-replicated) DR solution for Ozone bucket
>  * Run a periodic distcp from the source bucket to the target bucket
>  * Take a snapshot on the bucket and send it to the remote site DR sites ([https://ozone.apache.org/docs/edge/feature/snapshot.html])
> There are pros and cons for the current approach
>  * Pros
>  ** It is simpler: Setting up periodic jobs can be done quite easily (e.g. using cronjobs)
>  ** Distcp implementation will setup a map reduce jobs that will parallelize the copy from the source and the cluster
>  ** No additional components needed
>  * Cons
>  ** It is not “realtime”: The freshness of the data depends on how frequent and how fast the distcp runs
>  ** It incurs significant overhead to the source cluster: It requires scanning of all the files in the source cluster (possibly in the target cluster)
> Cloudera Replication Manager ([https://docs.cloudera.com/replication-manager/1.5.4/replication-policies/topics/rm-pvce-understand-ozone-replication-policy.html)] adds an incremental replication support after the initial bootstrap step by taking the snapdiff between two snapshots. This is better since there is no need to list all the keys under the bucket again, but it's not technically realtime.
> This ticket is track possible solutions for a realtime bucket async replication between two clusters in different regions (with 100+ms latency). The current idea is have a CDC (Change Data Capture) framework on the OM which will be sent to a Replication Queue to be processed by a Replicator to the target cluster.
>  * The CDC component can subscribe and receive any updates for the buckets through the gRPC bidirectional streaming APIs
>  ** The choice of the "change data" can be either Raft logs / RocksDB WAL logs / OM Audit logs
>  * Replication Queue can be something like Kafka topic / Ratis logservice (https://issues.apache.org/jira/browse/RATIS-271)
>  * Replicator uses a master-worker patterns
>  ** The master will consume the replications from the replication queue and assign a worker to run the cross-region replication tasks
>  *** If any worker failed, the master will reassign the replication to another task
>  ** The worker will run the replication task assigned from the master



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org