Organizations are generating and consuming data at an exponential rate. This data consists of vital pieces of information for an enterprise and is used by business-critical applications such as databases, analytics and messaging. A disastrous situation (natural, technology failure, malicious act or human error) may render business-critical applications useless due to the unavailability of data. Although data replication has been used for disaster recovery (DR) over the years, using Kubernetes constructs to improve DR mechanisms makes the replication process much more efficient and resilient.
Data services, which include data protection and data security, provide a great way to protect this ever-growing data and minimize downtime. In addition to the data security mechanisms introduced with the Diamanti Spektra 2.4, we have also added efficient asynchronous replication to our growing arsenal of data protection mechanisms.
Simple and Efficient Replication on the Diamanti Platform
Asynchronous Replication (or just “replication”) is a mechanism to protect data from disastrous situations by copying it to a remote site. Asynchronous replication, either at volume level or application level, can help to recover data with RPO and RTO of minutes to even seconds.
Diamanti’s replication mechanism is a much more efficient way of replicating data than the filesystem-based or application-based approach. The Diamanti platform uses snapshots for replication. Diamanti Spektra identifies the difference between the previous and current snapshots. This approach not only saves time but is more efficient because it avoids unnecessary copies of data. The snapshots cannot be modified by applications, helping protect the data from accidental modification and conform to disaster recovery requirements. The Diamanti platform also uses the native Kubernetes scheduling mechanism in the replication process which ensures efficient utilization of CPU and memory.
Replication in Diamanti Spektra 2.4
When the replication process is initiated, the data service operator is launched on the source and target. The data service operator is the replication management engine. It is responsible for launching replication drivers. For example, if the source data is to be replicated to multiple targets, then the source data service operator will launch one replication driver for each target. Each replication driver does the actual work of replicating the data. The source replication driver is also responsible for authentication and synchronization with the target replication driver.
Replication is done on a group of PVCs (consistency groups). Figure 1 shows a simple scenario where the data is replicated from one source to one target.
The source replication driver takes the snapshot of the source PVC group and compares it with the previous snapshot to find out which blocks have been changed since the last replication process. It then sends over those blocks to the target replication driver. The target replication driver applies these changed blocks to its PVC group. After the data is replicated, the target replication driver takes a snapshot of the target PVC group to have the latest consistent image of data. The target can use this snapshot in case of application failures.
Ensuring Business Continuity using Replication
Replication is a must-have disaster recovery (DR) mechanism. Replication is not only useful in disaster situations but also in stateful application migration, content distribution & consolidation and follow-the-sun model scenarios. With the Diamanti platform, the replication is done in an intuitive and efficient manner without any impact on the application performance. Thus, asynchronous replication using Kubernetes constructs adds a powerful tool to Diamanti’s data services portfolio.
In addition to ensuring business continuity, explore how the Diamanti platform can Supercharge Stateful Application Performance in Kubernetes. Check out the blog to learn more about Data Services supported on the Diamanti Platform.
