In the first post of this series, we have covered the new naming for VxFlex OS which is now PowerFlex and also covered the new, HTML5 based User Interface.

The new UI is not the only new feature in this release, so here is what else is new:

Native Asynchronous Replication

Use Cases:

  1. Disaster Recovery
    – Database or application data protection
    – Warm standby servers
    – DR Testing
    2. Remote / secondary site offloading
    – Distributing workloads to secondary environments:
    Operational BI, Analytics, Data Warehousing, Demand Planning, What-if analysis
    – Big Data – buffering data changes to secondary
    – Testing systems in parallel
    3. Data Migration

Native Asynchronous Replication

Storage Data Replicator (SDR)

What is it?
• A new software entity that handles replication activities

A new entity that handles replication activities

Is deployed on the same server as the SDS

Only IOs of replicated volumes will flow through SDR

  • All traffic goes through the SDR (both reads and writes)

Responsibilities of SDR at source domain include:

  • Log application’s writes to a journal
  • Close cycles when instructed
  • Perform write-folding on journal
  • Transfer journals to destination SDS

The MDMs exchange control data between the two sites.

SDRs exchange data between the 2 sites.

What does it do?
At the source:
• Forwards incoming writes to target volume SDSs
• Journals incoming writes
• Continuously sends journal data to target system
At the target:
• Receives, stores, and applies journal data to
target volumes in a consistent manner

Simplified I/O Flow of Replication

Steps to Enable VxFlex OS Replication

Export and import CA certificates on source and target systems
– Ensures data security and mutual trust
• Ensure (or add) storage capacity for the replication journal volumes on both
source and target
– Guidelines on sizing journal capacity will be provided
• Configure IPs addresses for replication at source and destination domains
• Create a pairing relationship between the MDMs in both domains.
• Add SDRs to the cluster
– Added via system expansion, like any other component

Create Replication Consistency Group (CG)
– Defined by: Replication pairs, replication direction and
replication policies
Replication Pair: A volume on the source domain
and its counterpart on the target domain
• Volumes on the source and target must be precreated and have the same size
• Can span different protection domains and
storage pools
• Can have different attributes: MG / FG
• All pairs in an RCG are cross-consistent and
maintain write fidelity
Replication direction:
• Source domain → Target domain
Replication policies: desired RPO
• 30 seconds to 1 hour

RPO & interval

1. RPO defines the maximal data loss, in time units, that the client is willing to lose.
2. The length of the data collection & data transmission intervals is bounded by the RPO

First time initialization is a process where all source
volume data is transferred to the paired target volume
• At the end of initialization, all target volume images are
consistent and normal replication can begin
• Uses online synchronization
– Application IOs on source domain continue while data is
being synced
– Can be deferred after CG creation

Steady State

On all the SDRs in the source domain:
– Writes are accumulated into an interval-Journal
– At the end of the collection interval the interval journal is closed (and a new interval is opened)
– The interval-journal data is transmitted to the target
On all the SDRs in the target domain:
– Transmitted data is received to a journal
– Once all the data for the interval-journal,
the data is applied to the application volume
› Consistency is maintained by the application process

Supported Topologies

Below, you can see a demo of the new replication engine

Leave a Reply