EMC World 2012– The New VMAX – Part 2- RecoverPoint Splitter


Among one the New VMAX familiy features, we released the RecoverPoint Splitter to ALL the new VMAX models.

Before discussing the Symmetrix write splitter, lets quickly review some key RecoverPoint concepts. The EMC RecoverPoint solution provides a point-to-point, heterogeneous, bi-directional, dynamic synchronous and asynchronous remote replication across an IP WAN or SAN infrastructure and local synchronous replication. The RecoverPoint Appliance (RPA) runs as a 2 to 8 (per site) node cluster configuration that allows for active-active failover between nodes.

RecoverPoint Continuous Data Protection (CDP) is a continuous synchronous product that mirrors SAN volumes in real time between one or more arrays at a local site. RecoverPoint Continuous Remote Replication (CRR) provides bidirectional, heterogeneous block-level replication across any distance using asynchronous, synchronous, and snapshot technologies. RecoverPoint Continuous Local and Remote (CLR) provides both CDP and CRR protection for the same production volumes.

RecoverPoint uses write splitters that monitor writes and ensure that a copy of all writes to a protected volume are tracked and sent to the local RPA. RecoverPoint supports three types of write splitters, array-based, intelligent fabric-based, and host-based. The Symmetrix RecoverPoint write splitter is an array-based write splitter.


RecoverPoint replication is based on a logical entity called a consistency group. A consistency group contains one or more replication sets. Each replication set consists of a production volume and the corresponding replica (target) volumes. These volumes must be seen by the appropriate host servers and RPAs.

Other important volume types in a RecoverPoint configuration include the Repository volume and the Journal volumes. The Repository volume stores pertinent replication environment information. This volume is only used by RecoverPoint so it must be seen by the RPAs on the site local to the Repository. Journal volumes store the consistent point-in-time images for the target site and will tend to have very high I/O activity. There is at least one Journal for each copy of the data within each consistency group. These volumes should also only be seen by the RPAs.


here are some common operational terms that apply to a RecoverPoint environment.

Snapshots stored on a replica journal represent the data that has changed on the production storage since the closing of the previous snapshot. Specifically, snapshots represent the data as it existed at a particular point-in-time.

In synchronous mode each write received by the RPA is considered a snapshot. In asynchronous mode the RPA gathers several writes into a snapshot.

A bookmark is a label applied to a snapshot so that the snapshot can be explicitly referenced during recovery processes. Bookmarks can be created manually by the user or automatically by the system at pre-defined intervals or in response to specific system events.

The distribution phase is the replication phase responsible for the writing of the production changes to the target replica storage, which is performed by the target RPA.

Image Access Mode is a user-triggered operation performed on a replica journal to recover the image to a selected point-in-time.

The Symmetrix RecoverPoint write splitter is an array-based write splitter. It splits (mirrors) incoming host write I/O to the RPA appliances (cluster nodes). Each configuration requires (one or more) primary production source devices as well as an equal number of secondary target (replica) devices. In a CDP configuration the replication is from source to local journal and target devices. Note that the RPA cluster has write access to the journal and replica volumes. Additionally, the RPA nodes 1 and 2 each need 8 dedicated Gatekeepers (additional RPA nodes do not need Gatekeepers).

Lets take a look at a write operation with the Symmetrix write splitter in a RecoverPoint CDP configuration.

1) An application server issues a write to a LUN that is being protected by RecoverPoint. This write is “split,” then sent to the RPA.

2) When the copy of the write is received by the RPA the backlog is synchronously mirrored to another RPA then the write is acknowledged back to the array splitter. Then the “ack” is sent back to the host.

3) Once the RPA has acknowledged the write, it moves the data into the local journal volume, along with a timestamp and any application, event, or user-generated bookmarks for the write.

4) Once the data is safely in the journal, it is distributed to the target volumes ensuring that write order is preserved during this distribution

Note that the Symmetrix splitter does not have a backlog component within itself. The solution is to synchronously mirror the backlog to another RPA as described in step 2. This will avoid a full sweep in case of an RPA failure before data is replicated. This process is called Backlog Mirroring (BLM).


In a CRR configuration the replication is applied from local source to remote journal and target devices. Note that the Symmetrix splitter is supported in CDP, CRR and CLR configurations.

Lets take a look at a write operation with the Symmetrix write splitter in a RecoverPoint CRR configuration. RecoverPoint CRR differs from CDP in that replication is occurring over the WAN to a remote site.

1) An application server issues a write to a LUN that is being protected by RecoverPoint. This write is “split,” then sent to the RPA.

2) When the copy of the write is received by the RPA, it is immediately acknowledged back from the local appliance when running in asynchronous mode. When running in synchronous mode, the “ack” is delayed until the write has been received at the remote site.

3) Once the appliance receives the write, it will bundle this write up with others into a package. The writes are sequenced and stored with their corresponding timestamp and bookmark information. The package is then deduplicated and compressed, and an MD-5 checksum is generated for the package.

4) The package is then scheduled for delivery to the remote appliance.

5) Once the package is received there, the remote appliance verifies the checksum to ensure the package was not corrupted in the transmission. The data is then uncompressed and inflated.

6) Next the data is written to the journal volume.

7) Once the data has been written to the journal volume, it is distributed to the remote volumes, ensuring that write-order sequence is preserved.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s