<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Design on Ramen</title><link>https://ramendr.github.io/ramen/docs/design/</link><description>Recent content in Design on Ramen</description><generator>Hugo</generator><language>en</language><atom:link href="https://ramendr.github.io/ramen/docs/design/index.xml" rel="self" type="application/rss+xml"/><item><title>CephFS Regional DR Consistency Group</title><link>https://ramendr.github.io/ramen/docs/design/cephfs-rdr-consistencygroup/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://ramendr.github.io/ramen/docs/design/cephfs-rdr-consistencygroup/</guid><description>&lt;h1 id="cephfs-regional-dr-consistency-group"&gt;CephFS Regional DR Consistency Group&lt;/h1&gt;&#10;&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;&#10;&lt;p&gt;Currently, Ramen only supports non-consistency-group CephFS RDR (Regional&#10;Disaster Recovery). However, with the upcoming support for consistency groups in&#10;CephFS, Ramen can expand its capabilities to include consistency-group RDR for&#10;CephFS.&lt;/p&gt;&#10;&lt;h2 id="motivation"&gt;Motivation&lt;/h2&gt;&#10;&lt;p&gt;Consistency Groups are pivotal in maintaining data integrity during&#10;synchronizing related datasets across regions, mitigating the risk of data&#10;corruption or loss during failover events. They constitute essential components&#10;of Regional Disaster Recovery, enabling organizations to minimize risks and&#10;ensure the availability and integrity of their data across geographical&#10;locations.&lt;/p&gt;</description></item><item><title>Global VolumeGroupReplication Design Document</title><link>https://ramendr.github.io/ramen/docs/design/global-vgr-design-doc/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://ramendr.github.io/ramen/docs/design/global-vgr-design-doc/</guid><description>&lt;h1 id="global-volumegroupreplication-design-document"&gt;Global VolumeGroupReplication Design Document&lt;/h1&gt;&#10;&lt;h2 id="1-design"&gt;1. Design&lt;/h2&gt;&#10;&lt;p&gt;Some storage backends manage replication at the LUN or filesystem level, where&#10;all applications sharing the same storage unit belong to a single replication&#10;group and must transition state together. Global VGR builds on top of Ramen&amp;rsquo;s&#10;offloaded storage support to coordinate a shared VGR across all VRGs in such a&#10;replication group, with multi-level consensus, label propagation, status&#10;validation, watchers, and observability through conditions, metrics, and alerts.&lt;/p&gt;</description></item><item><title>Incremental Sync for Consistency Groups</title><link>https://ramendr.github.io/ramen/docs/design/incremental-sync/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://ramendr.github.io/ramen/docs/design/incremental-sync/</guid><description>&lt;!--&#10;SPDX-FileCopyrightText: The RamenDR authors&#10;SPDX-License-Identifier: Apache-2.0&#10;--&gt;&#10;&lt;h1 id="incremental-sync-for-consistency-groups"&gt;Incremental Sync for Consistency Groups&lt;/h1&gt;&#10;&lt;p&gt;Extends &lt;a href="https://ramendr.github.io/ramen/docs/design/cephfs-rdr-consistencygroup/"&gt;Cephfs-RDR-ConsistencyGroup.md&lt;/a&gt;&#10;.&lt;/p&gt;&#10;&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;&#10;&lt;p&gt;When &lt;code&gt;drplacementcontrol.ramendr.openshift.io/enable-diff: &amp;quot;true&amp;quot;&lt;/code&gt; is set on a&#10;DRPC, Ramen preserves VolumeGroupSnapshots across sync cycles and uses the&#10;&lt;a href="https://github.com/RamenDR/ceph-volsync-plugin"&gt;ceph-volsync-plugin&lt;/a&gt;&#10; External&#10;mover to transfer only changed blocks between consecutive snapshots.&lt;/p&gt;&#10;&lt;h2 id="annotation-propagation"&gt;Annotation Propagation&lt;/h2&gt;&#10;&lt;pre tabindex="0"&gt;&lt;code&gt;DRPC → VRG → RGS (ReplicationGroupSource)&#10; → RGD (ReplicationGroupDestination)&#10;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Follows the same flow as &lt;code&gt;UseVolSyncAnnotation&lt;/code&gt;: the user sets the annotation on&#10;the DRPC instance, which propagates it to the VRG via ManifestWork. The&#10;annotation is whitelisted in &lt;code&gt;constructVRGFromView&lt;/code&gt; so it survives hub&#10;round-trips. DRPC annotation changes trigger reconcile automatically via the&#10;default &lt;code&gt;For(&amp;amp;DRPlacementControl{})&lt;/code&gt; predicate.&lt;/p&gt;</description></item><item><title>VRG Type Sequence</title><link>https://ramendr.github.io/ramen/docs/design/vrg-typesequence/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://ramendr.github.io/ramen/docs/design/vrg-typesequence/</guid><description>&lt;!--&#10;SPDX-FileCopyrightText: The RamenDR authors&#10;SPDX-License-Identifier: Apache-2.0&#10;--&gt;&#10;&lt;h1 id="vrg-type-sequence"&gt;VRG Type Sequence&lt;/h1&gt;&#10;&lt;h2 id="overview"&gt;Overview&lt;/h2&gt;&#10;&lt;p&gt;RamenDR can use Velero to capture Kubernetes object information. By default,&#10;Velero will back up all object types in arbitrary order. However, many&#10;applications have internal dependencies that require specific ordering by object&#10;type. The VRG Type Sequencer attempts to address this deficiency by taking&#10;multiple partial backups, with the order defined a the user.&lt;/p&gt;&#10;&lt;h2 id="example-use-case-backup"&gt;Example Use Case: Backup&lt;/h2&gt;&#10;&lt;h3 id="backup-overview"&gt;Backup Overview&lt;/h3&gt;&#10;&lt;p&gt;Take an example Backup that requires the following sequence:&lt;/p&gt;</description></item></channel></rss>