Replication use cases

Replication allows you to move Delphix objects such as dSources and virtual databases (VDBs) between Delphix Engines. These topics describe how you can use replication to meet different use cases:

• Replicating to the Public Cloud: With Delphix replication you can send data from engines deployed on-premise to the public cloud. In this case, you may have a Delphix engine in the production zone to ingest data securely with replication set up to the public cloud for development access and rapid, on-demand testing.

• Disaster Recovery: In the event of a disaster, you may need to failover your engine. Delphix replication enables you to configure a failover Delphix Engine to preserve the data and Delphix objects from the source engine for disaster recovery.

• Geographically Distributed Development: Often, development teams access data from all over the world. In this scenario, you may want to replicate data to be local to the developers who require access. With Delphix replication, you can provide developers with local access to Delphix datasets.

• Data Migration: Delphix supports simple migration of data and resources between Delphix Engines. There may be cases when you need to consolidate workloads between different Delphix Engines. With replication, you can easily migrate data as needed.

With Delphix replication, you can achieve the ideal Delphix deployment:

1. Ingesting data in production with a Delphix Engine deployed within the production zone.

2. Masking the data in production using Delphix Masking.

3. Replicating the masked data to a non-production environment, using Selective Data Distribution (SDD). SDD enables you to securely replicate masked data without compromising sensitive data from the source engine. For more information, read Selective Data Distribution Overview.

For more information on a few examples of Replication use cases, view the sections below.

Replicating to the public cloud

Enterprises will usually have the separate infrastructure for production systems and non-production development environments. For example, in the hybrid-cloud model, on-premise data centers are used to allow the company maximum ownership of these systems, while the public cloud is leveraged by development and automated testing teams to accelerate software development.

Delphix engine deployed in the public cloud

• Once a Delphix Engine has been deployed in the public cloud (using a supported cloud platform as described in Deployment) you can begin replicating from any source engine to that target engine.

• This enables you to provide access to production data from a Delphix Engine deployed on-premise to a Delphine Engine deployed in the cloud platform of your choice.

Disaster recovery

Replication is often used to provide recovery in the event of a disaster, where a data center or site becomes completely unavailable. To prepare for this, you may configure a failover Delphix Engine, which we will refer to as the replication target Engine. This target Engine will regularly receive replication updates from the original, or source, Engine so that if the source ever becomes unavailable, the target can be activated immediately.

Configuration steps

• Passive target engine

  • For disaster recovery, the target engine should be kept in a passive state until the source engine is lost. This prevents failover conflicts that may occur during the replication process.

  • At this point, a failover is performed that breaks subsequent replication updates and activates objects so that you can manage them on the target side.

• Same configuration for source and target engines

  • Target hosts and systems should exist at the target that matches the configuration of those at the primary engine. For example, if the source engine has two Red Hat environments discovered with four Oracle databases, the target engine should have exactly two Red Hat environments and four Oracle databases as well.

  • The failover engine should be provisioned with identical resources as the primary engine. For example, both engines should have the same number and types of disks attached as storage.

  • Finally, both engines should have the same network and storage topologies.

Failover object management

Once a failover occurs, there are two scenarios that will affect how you manage replicated objects, which include dSources, VDBs, and Environments.

• Failure of Infrastructure Running the Delphix Engine Only

  • You can enable dSources and VDBs and reconnect to the original environments that existed on the Source Engine. 

  • You can reconfigure environments on the target Engine prior to failover as well.

• Failure of Infrastructure Running the Delphix Engine and Delphix-connected Environments

  • Environments will then have to be adjusted to point to the new systems on the target side.

  • If there is not a 1:1 mapping, then you can migrate the VDBs to new systems on the target, and you can detach dSources and attach them to the standby system in the target environment.

Follow the best practices below to simplify failover and meet performance expectations in the event of a disaster:

• To the extent possible, the failover Engine should mirror the primary Engine

  • Maintain a 1:1 relationship between source and targets. All data-related objects such as dSources, VDBs, and Environments as well as their configurations such as users and policies.

• The target Engine should remain passive and not be actively used for other workloads

Geographically distributed development

Organizations often have development teams distributed across different networks as well as different geographical locations. To improve performance or even meet security requirements, it may be necessary to replicate data from one location to another. The Delphix Engine allows for VDBs to be provisioned from replicated dSources and VDBs, as described in Provisioning from Replicated Data Sources or VDBs.

This use case differs from Disaster Recovery as replication is never broken and failover is never performed. You can refresh remote VDBs as long as the parent objects continue to exist on the source. If they are deleted, then remote VDBs will continue to exist but cannot be refreshed or updated from their original source VDB.

Configuration steps

• Avoid Heavy VDB Workloads on the Source: Because each replication stream induces load on the source system:

  • Minimize the number of simultaneous replication updates. Each source engine can support replicating to multiple target engines, but you should try to keep simultaneous updates to under three target engines per source.

  • If possible, avoid heavy VDB workloads on the Source Engine

• The permanence of Source Objects: Provision only from sources that are effectively permanent, since replicated VDBs cannot be refreshed once the source is deleted. If you delete a source object you will need to re-replicate the VDBs if they need to be refreshed.

• Additional Storage Capacity on the Target Engine: Provision additional storage capacity on the target Engine

  • Remotely provisioned VDBs can consume shared storage (via NFS mounts) on the target even when the parent is deleted on the source

This use case supports more complex models such as 1-to-many and many-to-1. However, replication can only replicate objects that exist in the primary namespace. Consider a Delphix deployment with three Engines: Engine A, Engine B, and Engine C. The following workflow is supported:

1. 

   Engine A Replicates to Engine B

2. Provision a Replica VDB on Engine B

3. Engine B Replicates to Engine C 

In this scenario, you can replicate from Engine A to Engine B. Then, on Engine B provision a replica VDB into the primary namespace. Finally, add that object into a replication specification to replicate to Engine C. Note: Engine B can only replicate objects that exist in the primary (live) namespace to Engine C.

It is important to note the interim step of provisioning an on Engine B is required. For example, the following usage is not allowed:

1. 

   Engine A Replicates to Engine B

2. Engine B Replicates to Engine C 

You can replicate from Engine A to Engine B. But on Engine B, it is not possible, nor supported, to create a replication specification with objects in the replication namespace that are desired to be replicated to Engine C.

Data migration

You can use replication to perform a one-time migration of resources, such as virtual databases or environments, from one Delphix Engine to another. While the hypervisor provides tools to move virtual appliances between physical systems, there are times when migration is necessary, such as:

• Migrating between different physical storage

• Consolidating or distributing workloads across Delphix Engines

In these cases, you can use replication to copy a subset of objects across different topologies.

For migration, follow these best practices:

• Send full updates, followed by incremental updates, until the time required for incremental updates meets your downtime window

• Disable all objects to be migrated on the source, to ensure that they are not actively changing

• Send a final incremental update before failing over the target Engine

• After failover, delete any migrated objects on the source, or the entire Engine