VNX Remote Protection Suite Fundamentals

Welcome to VNX Remote Protection Suite Fundamentals.
Click the Notes tab to view text that corresponds to the audio recording.
Click the Resources tab to download a PDF version of this eLearning.
Copyright 1996, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 EMC Corporation. All
Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to
change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES
OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC2, EMC, Data Domain, RSA, EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC
SourceOne, EMC Storage Administrator, Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos,
Authentica, Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution,
C-Clip, Celerra, Celerra Replicator, Centera, CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook
Correlation Technology, Common Information Model, Configuration Intelligence, Configuresoft, Connectrix, CopyCross, CopyPoint, Dantz,
DatabaseXtender, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab,
EmailXaminer, EmailXtender, Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File
Virtualization, Graphic Visualization, Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express,
Invista, Ionix, ISIS, Max Retriever, MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale, PixTools, Powerlink,
PowerPath, PowerSnap, QuickScan, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor,
SAN Copy, SAN Manager, Smarts, SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler,
Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, VMAX, Vblock, Viewlets, Virtual
Matrix, Virtual Matrix Architecture, Virtual Provisioning, VisualSAN, VisualSRM, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression,
xPresso, YottaYotta, the EMC logo, and where information lives, are registered trademarks or trademarks of EMC Corporation in the
United States and other countries.
All other trademarks used herein are the property of their respective owners.
Copyright 2013 EMC Corporation. All rights reserved. Published in the USA.
Revision Date: 10/2014
Revision Number: MR-1WP-VNXRPSFD.5.33.x
Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.
VNX Remote Protection Suite Fundamentals
The subject, target audience and objectives of this training are explained in this slide.
This course covers the VNX Remote Protection Suite solutions. It includes an overview
of VNX MirrorView, VNX Replicator, and RecoverPoint/SE Remote Protection
architecture, principles, features, and functionality.
Here we see all of the software suites available for the VNX series array. These various
suites each contain a unique set of solutions to improve efficiency by simplifying and
automating many storage tasks.
This training will focus on the Remote Protection Suite. The Remote Protection Suite is
used for protecting and repurposing data by creating remote file and block replicas.
The Remote Protection Suite is part of the Total Protection Pack and the Total
Efficiency Pack and offers protection against localized failures, outages, and disasters.
It delivers disaster recovery protection for any host and any application on blockbased or file-based storage without compromise and with immediate DVR-like
rollback to a point-in-time. Capabilities include compression and deduplication for WAN
bandwidth reduction and application-specific recovery point objectives. Replication
options are available for many to one fan-in replication for centralized backup
operations, as well as one-to-many disaster recovery configurations. The Remote
Protection Suite includes VNX MirrorView Asynchronous and MirrorView/Synchronous,
VNX Replicator and RecoverPoint/SE Remote Protection.
This module focuses on the EMC VNX MirrorView block-based replication features.
During this module we will discuss the business uses for the MirrorView Synchronous
and MirrorView Asynchronous product and its architecture, features and functionality.
This module will also discuss the VNX MirrorView interoperability with peripheral
products.
This lesson covers the VNX MirrorView key terminology, operating principles and
configurations. This lesson will also describe the VNX MirrorView in business
environments.
EMC VNX MirrorView software offers two storage system-based remote mirroring
products: MirrorView/Synchronous and MirrorView/Asynchronous. These solutions
provide end-to-end data protection by replicating the contents of a primary volume to
a secondary volume that resides on a different VNX storage system. MirrorView/S
offers a zero data loss option, while MirrorView/A offers an alternative when minutes
of data loss may be tolerable.
The primary goal of MirrorView is to provide a block-based storage-system disaster

recovery solution for mirroring local production data to a remote/disaster recovery
site. MirrorView protects the secondary volume from tampering or corruption by only
making the volume available for server access when initiated through MirrorView.
Even though disaster recovery is the primary use of MirrorView, it is versatile enough
to be used in other ways. MirrorView and SnapView work well together. The
Administrator can take a Snapshot of primary or secondary images and use it for
backup purpose. Note that the ability to clone a secondary image allows applications
testing/development using a full copy of the data.
MirrorView common terms and its definitions are listed on this table. Please take a
moment to pause the training and read them.
This slide details the requirements and considerations for configuring MirrorView on a
VNX array. MirrorView allows for a large variety of topologies and configurations. In all
configurations, the primary and secondary images must have the same server-visible
capacity (user capacity), because they are allowed to reverse roles for failover and
failback. But do not need to have the same RAID configuration. In order to use
MirrorView, the software needs to be loaded on both arrays. Secondary LUNs will not
be accessible to hosts during the mirroring. Bi-directional mirroring is fully supported
as long as the primary and secondary images within any mirror reside on different
storage systems.
VNX Remote Protection Suite Fundamentals 10
MirrorView can also be used to consolidate or fan-in information on one remote VNX
Array for consolidated backups, simplified failover, or consolidated remote processing
activities.
The Administrator can mirror up to four source VNX Arrays to a single VNX Array
target system. The source systems and target systems can be in any location.
The 4 to 1 ratio is also applicable to both MirrorView/S and MirrorView/A.
Fan-out mirroring may be used to replicate data from one primary LUN to up to two
secondary LUNs residing on different arrays.
Shown here is an example of MirrorView/S fan-out functionality. This enables the
administrator to synchronously mirror one primary image to two different secondary
images or in the case of MirrorView/A, one primary image to a single secondary
image.
The secondary images are managed independently but must reside on separate VNX
Array storage systems. No secondary image can reside on the same storage system as
a primary image of the same mirror.
MirrorView use dedicated ports on supported storage systems - the specific port used
on each Storage Processor depends on the VNX model, and whether FC or iSCSI is
being used for replication. All MirrorView traffic goes through one port of each
connection type (FC and/or iSCSI) per Storage Processor. For systems that have only
FC ports, MirrorView traffic goes through one FC port of each Storage Processor. For
FC/iSCSI systems, one FC port and one iSCSI port are available for MirrorView traffic.
A path must exist between the MirrorView ports of Storage Processor A of the primary
and Storage Processor A of the secondary system. The same relationship must be
established for Storage Processor B. The MirrorView port may be shared with host I/O
(though this may be undesirable in some environments).
Once an image has been mirrored, the image may be in one of three availability
states. The inactive mirrored state means that the Administrator has intentionally
stopped mirroring. An active status is considered a normal state where all I/Os are
allowed on the image. An attention state indicates that something has happened to
the mirrored image and action by an Administrator is required.
In terms of the mirrored image consistency and relationship with the source image,
MirrorView contains five data states. Out-of-sync means that a full sync is in order.
The In-sync and synchronizing states indicate that the primary and secondary
contains identical data and the operation is in process. A consistent state means that
the mirroring has been stopped and a write intent or fracture log is needed to continue
the mirroring. Rolling back is the act of returning a primary to a predefined point-intime.
Synchronization is a copy operation MirrorView performs to copy the contents of the

primary image to the secondary image. This is needed to establish newly-created
mirrors or to reestablish existing mirrors after an interruption. Initial synchronization
is used to create a baseline copy of the primary image on the secondary image for
new mirrors. In almost all cases, when a secondary image is added to a mirror, this
initial synchronization is required. Primary images remain online during the sync
process and until the synchronization is complete, the secondary image is unusable.
Synchronization rates are user selectable and set a relative priority for completing
updates.
A secondary image is promoted to the role of primary when it is necessary to run

production applications at the disaster recovery site. This can only occur if the
secondary image is in the consistent or synchronized state.
Once the promotion occurs, the secondary image is placed in a new mirror as the
primary image. This new mirror has the same name but a different mirror ID. The
existing mirror is either maintained or destroyed, depending on the nature of the
failure and whether in-band communication still exists between the primary and
secondary images.
A fracture stops MirrorView replication from the primary image to the secondary
mirror image. Administrative fractures are initiated by the user typically to suspend
replication, as opposed to a system fracture which is initiated by the MirrorView
software. A system fracture entitles a communication failure between the primary and
secondary systems.
With MirrorView/S, writes continue to the primary image but are not replicated to the
secondary during a fracture. Replication can resume when the user issues a
synchronize command.
With MirrorView/A, the current updates stop during a fracture, and no further updates
start until a synchronize request is issued. The last consistent copy remains in place
on the secondary image if the mirror is to be updated.
Consistency Groups allow all LUNs belonging to a given application, usually a

database, to be treated as a single entity and managed as a whole. This helps to
ensure that the remote images are consistent. As a result, the remote images are
always re-startable copies of the local images, though they may contain data which is
not as new as that on the primary images. Once a mirror is part of a Consistency
Group, most operations on individual members are prohibited. This is to ensure that
operations are automatically performed across all the member mirrors. It is a
requirement that all the local images of a Consistency Group be on the same VNX
Array, and that all the remote images for a Consistency Group be on the same remote
VNX Array. Consistency Groups may be fractured, synchronized, or promoted as a
singular mirrored image.
Support for Virtual Provisioning with MirrorView enables remote replication protection
of virtually provisioned LUNs. When mirroring a thin LUN to another thin LUN, only
consumed capacity is replicated between the storage systems. When mirroring from a
thin LUN to a classic or thick LUN, the thin LUNs host visible capacity must be equal to
the classic LUNs capacity or the thick LUNs user capacity.
MirrorView/S checks the space available to the secondary before adding a secondary
image to a mirror and before starting synchronization on an existing mirror; however
it is possible for other thin LUN activity in the same pool to consume pool capacity
while the synchronization is in progress. MirrorView/A does NOT have any checks to
consider Pool space on secondary array. If there is not enough space, it is treated like
a failed write and an administrative fracture occurs.
MirrorView can be managed by Unisphere or Secure CLI software. Unisphere also

includes a MirrorView Wizard to guide the user through the configuration.
Peripheral products associated with MirrorView are listed here.

MirrorView/Cluster Enabler software enables geographically dispersed Microsoft
Failover Clusters across MirrorView links. MV/CE works with applications designed to
take advantage of Failover Clusters, such as Exchange and SQL Server.
VMware Site Recovery Manager (SRM) works with Storage Replication Adapters
(SRAs) to automate site recovery using the VNX replication software. It supports
MirrorView/A and MirrorView/S.
EMC Replication Enabler for Microsoft Exchange Server 2010 is a software plug-in that
provides replication and disaster recovery for Microsoft Exchange databases.
This lesson covers the VNX MirrorView/Synchronous architectures, theory of operation,

features and functionality.
The mirroring in MirrorView/S is synchronous, meaning that every time a host writes
to the primary array, the secondary array mirrors the write before an
acknowledgement is returned to the host. MirrorView ensures that there is an exact
byte-for-byte copy at both the local VNX array and the remote VNX array. Since
MirrorView/S is storage-based software, no host CPU cycles are used. MirrorView/S
operates in the background, transparent to any hosts or applications. MirrorView/S is
fully integrated with snapshots, the array-based software that creates consistent
point-in-time copies. Those copies allow access to local or remote data. MirrorView/S
is managed from within Unisphere Management software. Remote replication is
supported for both Fibre Channel and iSCSI connections.
This slide shows the steps involved in a VNX Synchronous Mirroring operation. Once a
write I/O is received from the client into the primary array, the write I/O is also
transmitted to the secondary array for mirroring. Once the write I/O is cached by the
secondary array, an acknowledgement is sent to the primary array, and another
acknowledgement is sent back to the host. The host needs to wait for the
acknowledgement before sending more write I/Os to the primary array.
The fracture log is a bitmap held in the memory of the storage processor that owns
the primary image. The log indicates which physical areas of the primary have been
updated since communication was interrupted with the secondary image. The fracture
log is automatically invoked when communication with the secondary image of a
mirror is lost for any reason and the mirror becomes fractured. It could be initiated by
the administrator or system. It tracks changes on the primary image for as long as the
secondary image is unreachable. When the secondary LUN returns to service, the
secondary image must be synchronized with the primary. This is done by reading
those areas of the primary addressed by the fracture log and writing them to the
secondary image. This occurs in parallel with any writes coming into the primary and
mirrored to the secondary.
The Write Intent Log keeps track of writes that have not yet been made to the remote
image for the mirror. A record of recent changes to the primary image is stored in
persistent memory on a private LUN reserved for the mirroring software. If the
primary storage system fails, the optional write intent log can be used to quickly
synchronize the secondary image, when the primary storage system becomes
available. This eliminates the need for full synchronization of the secondary images,
which can be a lengthy process on very large LUNs.
This lesson covers the VNX MirrorView/Asynchronous architectures, theory of

operation, features and functionality.
MirrorView/A provides a host (OS, network, applications, and database) independent

protection solution that duplicates changes in production site data to a secondary site
at regular intervals after an initial full synchronization. Update Intervals can be defined
by the user in minutes.
MirrorView/A uses SnapView Snapshot technology for data protection on the primary
and secondary systems. On the primary image, snapshot technology tracks changes
and creates a point-in-time image. On the secondary system, a protective copy of the
secondary image is created termed as gold copy that ensures there is a usable copy
on the secondary at all times. The operation happens in the background, and is
transparent to any hosts or applications.
Because of its asynchronous nature, MirrorView/A seldom has data on the secondary
image identical to that on the primary image, which requires the tracking of changes,
so that they may be shipped to the secondary image at regular intervals.
MirrorView/A is distance-independent and allows replication over IP networks, SAN
and WAN topologies at extended distances.
MirrorView/A is used primarily for longdistance mirroring. Data on the Primary

volumes and the Secondary volumes are at most two replication cycles behind. Whats
important is that MirrorView/A provides a consistent pointintime view of the
production data at the Secondary site at all times. Show here is the MirrorView/A
theory of operation. Notice that the main difference between MirrorView/A and
MirrorView/S is the acknowledgement that the host receives before the write is
mirrored to the secondary array.
MirrorView/A uses SnapView change tracking technology to create Delta Sets for
incremental updates. These updates are tracked at 2 KB granularity. It replicates only
the changed blocks during the MirrorView/A update cycle and transfers the changed
blocks at 2-64 KB granularity. Provisioning of adequate space in the Reserved LUN
Pool on the primary and secondary storage systems is vital to the successful operation
of MirrorView/A. The exact amount of space needed may be determined in the same
manner as the required space for SnapView is calculated. The Delta Set is sent to
secondary periodically and the customer defines the update frequency. The secondary
array is automatically protected via a point-in-time gold copy during the update cycle.
This ensures a consistent, usable remote copy and protection against partial-update
scenarios.
This module covered the VNX MirrorView data replication solution, operating
principles, terms, functionality and capabilities.
This module focuses on the EMC VNX Replicator file-based replication features. During
this module, we will discuss the business uses for the VNX Replicator product and its
architecture, features and functionality. This module will also discuss the VNX
Replicator interoperability with a peripheral product.
This lesson covers the VNX Replicator architecture, theory of operation and
terminology. This lesson will also cover the VNX Replicator in business environments.
VNX Replicator is an IP-based replication solution that produces a read-only, point-intime copy of a source or production system. The VNX Replication service periodically
updates this copy, making it consistent with the production file system. Replicator
uses internal checkpoints to ensure availability of the most recent point-in-time copy.
These internal checkpoints are based on VNX SnapSure technology. This read-only
replica can be used by an Data Mover X-Blade in the same VNX cabinet or an Data
Mover X-Blade at a remote site for content distribution, backup, and application
testing. When a replication session is first started, a full backup is performed. After
initial synchronization, Replicator only sends changed data over IP.
The primary goal of VNX Replicator is to provide a read-only, point-in-time copy of a

source production file system at a destination. The VNX Replicator duplicates a copy of
production file systems that can be replicated to a remote site where they can be
brought online with little downtime in case of a major disaster. The administrator also
can use this type of replication for content distribution, backup, reporting, and
software testing.
This table shows the definition of Replicator terms. Please take a moment to review
them.
The Data Mover interconnect defines the communications path between a given pair of
Data Mover X-Blades located on the same cabinet or different cabinets. Before
creating a replication session, both sides of a Data Mover interconnect must be
established to ensure communication between the Data Mover X-Blade pair that
represents the source and destination. Interconnect for remote replication is created
between a local Data Mover X-Blade and a remote Data Mover X-Blade on another
system. The Administrator must first create the interconnect on the local side and
then on the destination side, before successfully creating a remote replication session.
Each Data Mover X-Blade, by default, has a loopback interconnect which cannot be
removed or modified. The loopback interconnect is used for loopback replication
sessions. Only one interconnect can be established between a given Data Mover XBlade pair. Each physical link can have multiple IP addresses. An interconnect cannot
be deleted if it is used by a replication or copy session.
Replicator uses internal checkpoints for file system replication. These checkpoints are
point-in-time views of a file system that are not a copy or a mirror image of the
original file system. Rather, the Checkpoint file system, is a logical presentation of
what the production file system looked like at a particular time. The checkpoint is a
read-only view of the production file system prior to changes at that particular time.
Each live file system with a checkpoint has an associated save volume, or SavVol. The
first change made to each file system data block following a checkpoint triggers the
software to copy that data block to the SavVol. It also holds the changes made to a
writeable checkpoint and Replicator checkpoints.
Loopback replication of a source object occurs on the same Data Mover X-Blade in the
cabinet. In other words, the source Data Mover X-Blade and destination Data Mover XBlade are the same. Communication is established by using the Data Mover X-Blade
loopback interconnect, established automatically for each Data Mover X-Blade in the
cabinet. The internal loopback of 127.0.0.1 is used in communicating control signals
back and forth. Since an internal IP address is used, theres no need to involve the
network stack for data transfer.
Local replication occurs between two Data Mover X-Blades in the same VNX cabinet.
Both Data Mover X-Blades must be configured to communicate with one another by
using a Data Mover interconnect. After communication is established, a local
replication session can be set up to produce a read-only copy of the source object for
use by a different Data Mover X-Blade in the same VNX cabinet. The source and
destination file systems are stored on separate volumes.
Remote replication occurs between a local Data Mover X-Blade and a Data Mover XBlade on a remote VNX. Both VNXs must be configured to communicate with one
another by using a common passphrase, and a Data Mover interconnect. After
communication is established, a remote replication session can be set up to create and
periodically update a source object at a remote destination site. The initial copy of the
source file system can either be done over an IP network or by using the tape
transport method. After the initial copy, replication transfers changes made to the
local source object to a remote destination object over the IP network. These transfers
are automatic and are based on definable replication session properties and update
policy.
When a replication session is created, Replicator creates a destination object

automatically. The Administrator may also choose to create his own destination object
and then direct Replicator to the object during the configuration of the session. Next,
Replicator creates two internal checkpoints for both source and destination objects.
Then, a full copy of the production data is transferred from the source objects
checkpoint 1 to the destination object in order to populate it.
After the initial full copy has been completed, the destination object now contains data
from the source object at the time that the Checkpoint was originally taken. The
amount of time taken to complete the initial full copy depends on the bandwidth of the
Network and the size of the source object. In this example, it took 30 minutes to
transfer the initial full copy. Once the full copy has been completed, Replicator
refreshes the destination objects first checkpoint so it can contain the same view as
the first checkpoint from the source object. Now the common base for both source and
destination is Checkpoint 1.
Once a certain amount of time has passed, depending on the update policy, Replicator
needs to transfer over any changes that were made on the source since the last
checkpoint was taken. To do this, Replicator refreshes Checkpoint 2 of the production
data and compares this checkpoint to the common base Checkpoint 1. Any changes
are then sent over to the destination. Once the transfer is complete, the second
Checkpoint on the destination is refreshed. Now, Checkpoint 2 on both source and
destination will be the new common base. This cycle continues until the replication
session is stopped or deleted.
VNX Replicator can be managed by Secure CLI or Unisphere with the VNX Replicator
license enabled.
This lesson covers the VNX Replicator features and functionality. The disaster recovery
options, policies and configuration will be discussed. This lesson will also describe the
interoperability between the VNX Replicator and a peripheral product.
A replication failover operation sets the replicated objects on the destination VNX to
Read/Write so that data access can resume. The failover operation is performed only
on the destination VNX. The execution of the failover operation is asynchronous and
results in data loss if all the data is not transferred to the destination site prior to
issuing the failover. The failover process starts when the source side of replication
becomes unavailable and the normal replication process stops. This could be due to a
disaster at the source side of replication, a power-outage or a network outage. Next
the replication failover command is issued to the destination VNX. The replicated
objects on the destination VNX are changed from being mounted read-only to
read/write. If the source VNX becomes available its replicated objects is mounted
read-only. Data access resumes from the destination side VNX. Its data is consistent
with the last successful data transfer from the source.
The Administrator can perform a reverse operation from the source side without data
loss. This operation reverses the direction of the replication session thereby making
the destination read/write and the source read-only. First, the destination object is
synchronized with the source object. Next, the source object is mounted read-only and
replication is stopped. The destination object is mounted with read/write access. Then,
replication is started in the reverse direction from a differential copy and with the
same configuration parameters.
A replication session may be switched over to perform synchronization of the source

and destination without data loss for failover testing or migration purposes. A
replication switchover is performed when the source is functioning and available. The
Administrators performs this operation on the source VNX only.
When a replication switchover is implemented, the destination object is synchronized
with the source object. Next, replication is stopped and the source object is mounted
read-only. The destination object is mounted with read/write access to act as the new
source object. Unlike a reverse operation, a switchover operation does not start the
replication session.
VNX Replicator includes support for failover and reverse, as well as Virtual Data Mover
(Or VDM) support. Combining these features provides an asynchronous data recovery
solution for CIFS servers and CIFS file systems mounted on a VDM. In a CIFS
environment, in order to successfully access file systems on a remote secondary site,
the Administrator must replicate the entire CIFS working environment including local
groups, user mapping information, Kerberos, DNS, shares and event logs. All that
information is copied over via the VDM. The Administrator must replicate the
production file systems attributes, access the file system through the same UNC path,
and find the previous CIFS servers attributes on the secondary file system. A CIFS
Data Recovery solution with VNX Replicator is possible if the CIFS servers are
configured on VDMs. All the CIFS information and configuration is replicated with that
VDM. Because of this, clients continue to access CIFS servers in the event of a failover
from the primary site to the secondary site.
Replicator has policies to control how often the destination object is refreshed by using
the max_time_out_of_sync setting. The Administrator can define a
max_time_out_of_sync value for a replication session or perform on-demand, manual
updates. The max_time_out_of_sync value represents the elapsed time window within
which the system attempts to keep the data on the destination synchronized with the
data on the source. The destination could be updated sooner than this value.
Replicator also allows the administrator to control throttle bandwidth by specifying
bandwidth limits on specific days, specific hours, or both. By default, Replicator uses
all available bandwidth unless a bandwidth schedule is configured.
A cascade configuration involves two replication sessions, one destination serves as

the source for another replication session. The first session runs replication from the
source to the first destination. The second session runs replication from the first
destination, serving as the source, to the second destination. These sessions are
configured individually and are independent of one another.
When using incremental attach in a cascade replication configuration, the
administrator would first manually create a checkpoint of the source file system, and
the destination file system on the first leg of the cascade and use them with the
Incremental Attach option to refresh the session.
This slide shows a basic cascade configuration for file system replication and also
using the incremental attach feature. The first session has two checkpoints for the
source and two for the destination object. For the second replication session, two
more checkpoints are created for the new source object, formerly the destination in
session one, and two more are created for the second destination object. The data on
the session two destination object can be quite different depending on the time-outof-sync values for both sessions.
To use the incremental attach feature, a set of checkpoints are manually created by
the administrator. First a checkpoint is created of the Source file system and the
Destination file system on the first leg of the cascade. The incremental attach option is
used to refresh the session. Next, a checkpoint of the final destinations file system is
manually created, and along with the first destinations checkpoint, is used to refresh
the replication session using the incremental attach option. This sets the checkpoints
as the common base for all the sessions. If the middle storage system is unavailable
due to disaster or hardware malfunction, the original source can directly replicate to
the final destination with just an incremental copy because of the common base that
was formed.
VNX Replicator may be configured in two different ways for one-to-many

configurations. In a one-to-many configuration, multiple replication sessions can be
set up to different destination objects from one source object. A maximum of four
destinations can be associated with one source object. This type of configuration
requires a separate replication session for each destination. These sessions are
configured individually and are independent of one another.
In a one-to-many configuration with incremental attach, an administrator can
manually create a user checkpoint on the source and the first destination, then refresh
the replication session pointing to the checkpoints. Using the same user checkpoint on
the source, the administrator refreshes the other replication sessions to a user created
checkpoint on the other destinations. Once this has been completed, if the source
system becomes unusable due to hardware malfunction or disaster, replication can
continue with one of the previous destinations becoming the new source and an
incremental copy used to start the session referencing the user checkpoints. This
replication scenario can also be used to replace aging systems with new VNX models
by adding in the VNX as a one-to-many configuration, removing the original source,
and restarting replication with the VNX as the new source.
Displayed here is a basic one-to-many configuration for ongoing replication of a given

source file system to multiple destinations, which can be up to four. This type of
configuration requires a separate replication session for each destination. Each
replication session generates two internal Checkpoints on the source. It can also be
done one-to-many using incremental attach, which again can be up to four.
To implement incremental attach, an administrator manually creates a user checkpoint
on the source and the first destination, and then refreshes the replication session
pointing to the checkpoints. Using the same user checkpoint on the source, the
administrator refreshes the other replication sessions to a user created checkpoint on
the other destinations.
Once this has been completed, if the source system becomes unusable due to
hardware malfunction or disaster, replication can continue with one of the previous
destinations becoming the new source and an incremental copy being used to start the
session referencing the user checkpoints.
This module covered the VNX Replicator solution, its operation principles, terms and
functionality.
This module focuses on the EMC RecoverPoint/SE Remote Protection replication

features. During this module we will discuss the business uses for the RecoverPoint/SE
product and its architecture, features and functionality.
This lesson covers the RecoverPoint overview, key terminology, theory of operation
and volumes. This lesson will also discuss the RecoverPoint in business environments.
EMC RecoverPoint is an enterprise-scale solution designed to protect application data

on heterogeneous SAN-attached servers and storage arrays. RecoverPoint provides
many features that make it a unique and tested solution for backup and recovery. It
allows for the access of a point-in-time image, either locally or at another site, while
still performing replication. The ability to access data from a copy allows for testing
without sacrificing protection. This feature also is integrated with various applications,
such as Exchange, SQL, and VMware. This allows for application-driven point in time
copies. Point in time copies can be created for each write, or the user can choose the
amount of data lag that can be tolerated for an application. This option is configurable
for each group of volumes, and can be edited at any time.
The right remote-replication solution can limit the exposure to planned and unplanned
downtime, enabling non-stop operation. Perhaps the Administrator also need to
provide the organization with efficient data replication to meet corporate or
governmental standards, while still meeting the total-cost-of-ownership requirements.
In addition, the Administrator need a flexible solution that changes as the needs
change.
No matter what the challenge is, there is one underlying theme: data protection and
faster business restart in the event of a disaster or unplanned outage are critical
across the organization.
Using replication software to maintain a complete copy of the data in a remote
location allows for business continuity and increased functionality. When disaster
recovery is required, remote replication software and remote clusters ensure that all
the mission-critical information has been captured. Using replicas rather than tape
means the production can be up and running in hours as opposed to days. In addition,
the second cluster can be used for application testing and remote backups. Replication
enables non-stop operation with full access to the production data and the replicas.
This table shows the definition of RecoverPoint terms. Please take a moment to review
them.
When an application server issues a write to a LUN that is being protected by

RecoverPoint, this write is duplicated by an array splitter running in the VNX storage
processor or optionally on the application host.
The VNX array will intercept all writes to LUNs being protected by RecoverPoint, and
will send a copies to the RecoverPoint appliance. In all cases, the original write travels
though its normal path to the production LUN.
Once the appliance receives the write, redundant blocks are eliminated, the writes are
sequenced and stored with their corresponding time stamp information.
The package is then compressed, and sent across the IP network to the remote
appliance.
At remote site the data is uncompressed and written to the journal volume.
Once the data has been written to the journal volume, it is distributed to the remote
volumes, ensuring that write-order sequence is preserved.
The RecoverPoint Appliance (RPA) is the data-protection controller for RecoverPoint.

RPA nodes utilize private LAN and shared RPA volumes for communications using
standard TCP protocol. No FC/IP converters are needed to replicate across the WAN.
Each RPA cluster can include between one and eight RPAs. In normal operation, all
RPAs in a cluster are active all of the time. Consequently, if one of the RPAs in a
cluster goes down, the RecoverPoint system supports immediate switchover of the
functions of that box to another RPA in the cluster.
Virtual RecoverPoint Appliance (vRPA) is a virtual machine that run the RecoverPoint
software. It accesses the repository, journal, production, and copy volumes via the
iSCSI protocol, and therefore do not require any FC infrastructure. One important
consideration is that vRPAs are only available for use with the VNX storage array.
vRPAs can replicate any block data, regardless of how the hosts are connected to the
VNX. iSCSI SLICs are required for the VNX arrays.
RecoverPoint uses software running on the CPUs of the arrays to perform WriteSplitting. This software copies all incoming writes for volumes protected with
RecoverPoint. A copy is written to the production volume and a copy is sent to the
RecoverPoint appliance. Previous versions of RecoverPoint used Write-Splitters located
on the Host or SAN. RecoverPoint 4.0 and above only uses the array-based version of
Write-Splitters.
The VNX splitter runs in each storage processor of a VNX and splits (mirrors) all
writes to a VNX volume, sending one copy to the original target and the other copy to
the RecoverPoint appliance. Both RecoverPoint and RecoverPoint/SE support the VNX
splitter. The VNX splitter is supported on both iSCSI and FC attached volumes.
Replication volumes or Replicas are the production storage volumes and their
matching target volumes which are used during replication.
Target volumes must be the same size (or larger) than the source volumes. Any
excess size (above the source sites size) will not be replicated or visible to the host.
This is an important design consideration for heterogeneous storage environments.
Journal volumes hold snapshots of data to be replicated. The type and amount of
information contained in the journal differs according to the journal type. Each Journal
volume holds as many point in time images as its capacity allows, after which the
oldest image is removed to make space for the newest. Journals consist of 1 or more
volumes presented to all the RPAs for the cluster. Space can be added, to allow a
longer history to be stored, without affecting replication. The size of a Journal volume
is based on several factors:
The change rate of the data being protected.
The amount of time between point in time images (could be as small as each write).
The number of point in time images that are kept.
The repository is a special volume that must be dedicated on the SAN-attached

storage for each RPA cluster. This volume stores configuration information about the
RPAs, the cluster, and consistency groups. This enables a properly functioning RPA to
seamlessly assume the replication activities of a failing RPA from the same RPA
cluster.
There is a Repository volume for every RecoverPoint cluster. The volume is presented
to each RPA, either via the SAN or using iSCSI for virtual RPAs.
The RecoverPoint management application is a Java-based GUI that runs on a variety

of host systems, allowing the Administrator to manage RecoverPoint operations. From
the GUI, the Administrator can set up the replication relationships and parameters,
view the replication status, recover to a point in time, and initiate a production
failover.
RecoverPoint 4.0 introduces integrated management within VNX Unisphere.
This lesson covers the RecoverPoint/SE Remote Protection features, disaster recovery
and the Virtual Provisioning support.
Here is a view of RecoverPoint in normal operation. First, an initial synchronization

sends a full copy of the LUNs to the remote site. Then, the clients update the source
LUNs. RecoverPoint uses compression of differential snapshots to replicate changes to
the production LUNs and sends these to the destination. The update will be prioritized
to meet the RPO and bandwidth service levels.
Here is a view of a RecoverPoint failover operation. First, the production site

experiences a disaster and is unavailable. Then, the LUNs in each of the consistency
groups at the disaster recovery site are changed to read/write and designated as
sources. Finally, the clients update the source LUNs at the disaster recovery site.
Here is a view of a RecoverPoint failback operation. First, the production site recovers
from the disaster. The LUNs at the production site are changed to read-only and
designated as destinations so that no servers on the production site can access them.
Then, RecoverPoint uses compressed differential snapshots to replicate any changes
and sends these to the destination at the production site. Finally, after the sites are
re-synchronized, a failback reverses the sources and destinations back to their original
configuration.
Consistency groups define protection for a set of volumes. If two data sets are
dependent on one another (such as a database and a database log), they should be
part of the same consistency group. Consistency groups maintain write order between
the data sets, and Settings and policies for data protection. Examples of these
parameters are: compression, bandwidth limits, and maximum lag.
Imagine a motion picture film. The video frames are saved on one volume, the audio
on another. Neither volume will make sense without the other. The saves must be
coordinated so that they will always be consistent with one another. In other words,
the volumes must be replicated together in one consistency group to guarantee that at
any point in time, the saved data will represent a true state of the film. The
consistency group ensures that updates to the production volumes are also written to
the copies in consistent and correct write-order so the copy can always be used to
continue working from, or to restore the production source.
RecoverPoint supports virtual provisioning. Virtual provisioning is the ability to present

an application with more capacity than is physically allocated to it in the storage array.
The physical storage is then allocated to the application on-demand as it is needed
from a shared pool of capacity. RecoverPoint replicates only the allocated space that is
in use by the application. For example, the application may believe it has 8 GB
allocated, but may only have 2 GB in use. RecoverPoint replicates only the 2 GB.
This module covered the RecoverPoint/SE Remote Protection data replication solution,
operation principles, terms and functionality.
This course covered the architecture, theory of operation, capabilities and

functionalities of VNX MirrorView, VNX Replicator and RecoverPoint at a fundamental
level.
This concludes the training. Proceed to the course assessment on the next slide.

VNX Remote Protection Suite Fundamentals

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VNX Remote Protection Suite Fundamentals

Uploaded by

Copyright:

Available Formats

Welcome to VNX Remote Protection Suite Fundamentals.

Copyright 2013 EMC Corporation. Do not copy - All Rights Reserved.