VNX Local Protection Suite Fundamentals

Welcome to the VNX Local Protection Suite Fundamentals course.
Copyright 1996, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 , 2014
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 2014 EMC Corporation. All rights reserved. Published in the USA.
Revision Date: 10/2014
Revision Number: MR-1WP-VNXLPSFD
Copyright 2014 EMC Corporation. All rights reserved.
VNX Local Protection Suite Fundamentals
This course covers an introduction to the VNX Local Protection Suite solutions. We will discuss
the architecture, features, and functionality of the VNX SnapView, VNX Snapshots, VNX
SnapSure, and RecoverPoint/SE Local Protection products.
This module focuses on the solutions available in the VNX Local Protection Suite. During this
module, we will also outline the various VNX software suites that are available.
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 focuses on the VNX Local Protection Suite. The VNX Local Protection Suite
solutions are used for protecting and repurposing data by creating local file and block replicas.
The VNX Local Protection Suite offers local replication solutions that can significantly enhance
a customers business and technical operations. This is done by providing access points to
production data that enables parallel-processing activities such as backups. These accesspoints can also be used for such things as disk-based recovery after corruptions and creating
test environments for application testing.
The VNX Local Protection Suite contains four products: VNX SnapView, VNX Snapshots, VNX
SnapSure, and RecoverPoint.
VNX SnapView creates block-based logical point-in-time views of production information
using snapshots and point-in-time copies using clones. Snapshots use only a fraction of the
original disk space, while clones require the same amount of disk space as the source.
VNX Snapshots create block based logical point-in-time views of production information
using snapshot technology. By using a different approach to the way new writes to the
production file system are handled, VNX Snapshots provide an improvement to the overall
performance and consumes less allocated storage space.
VNX SnapSure creates logical point-in-time views of production file systems using
snapshots. SnapSure uses only a fraction of the original disk space used by the source file
system.
RecoverPoint Local Protection is a synchronous product that mirrors volumes in real time
between one or more arrays at a local site. RecoverPoint maintains a history journal of all
changes that can be used to roll back the mirrors to any point in time.
This course will cover each one of the products offered by the VNX Local Protection Suite in
separate modules which describe and contrast their functionality, and benefits.
This module focuses on the VNX SnapView block-based replication features. During this
module we will take a look at the business uses for the SnapView product along with the
products features and functionalities.
SnapView is a group of software products that run on the VNX. Since SnapView runs on the
storage system, zero host cycles are spent managing information giving SnapView an
advantage over host-based products.
SnapView creates block-based logical point-in-time views of production information using
snapshots and point-in-time copies using clones. Snapshots use only a fraction of the original
disk space, while clones require the same amount of disk space as the source.
SnapView allows companies to make efficient use of their most valuable resource
informationby enabling parallel information access. SnapView allows multiple business
processes to have concurrent, parallel access to information utilizing multiple point-in-time
replicas.
If there is a need to return the Source LUN to a previous data state, both clones and
snapshots have restore to source LUN capabilities. If there is a need to restore data, the
primary host will see the data immediately causing minimal disruption to production.
Snapshots and clones also have an optional consistency feature which allows data to be
copied from multiple Source LUNs at exactly the same point in time. This ensures that data
stored across several LUNs, such as database data and database logs, can be used to create a
useable point-in-time copy.
Unisphere allows easy management of SnapView features. Unisphere has been simplified by
the addition of two wizards, one each for clones and snapshots. The wizards allow the user to
create point-in-time copies without having to get involved in complex details.
SnapView snapshots and clones enable users to perform various tasks on a given data set as
required in a typical business environment without compromising the access to the data.
SnapView technologies have a wide variety of business uses. The primary goal of SnapView is
to allow system backups to run concurrently with application processing. When performing
backups, consistent data must be written to the backup medium. If the application uses
several related LUNs for storage, all those LUNs must be in the same state when the backup
is performed. SnapView snapshots and clones can take care of this issue with data
consistency.
While backups are the primary use for SnapView, it is versatile enough to be used in other
ways. For example, point-in-time copies can be taken every hour for critical applications. This
allows easy recovery from corrupted or damaged files. Also, decision support systems can use
point-in-time copies, allowing them to use real data, with minimal effect to the application.
Other uses for SnapView replicas include local data replication and making copies of data to
be used as a source for remote data replication.
Now well take a look at some of the different technologies associated with local replication.
Pointer based technology uses pointers to indicate where data is currently located. Data can
be located on the source LUN (Classic, Thin, or Thick ), or may have been copied to the Save
Area as a result of the technology used. When using pointer based technology, the pointer
based LUN typically uses less space than when using full copy based technology. Though it
appears to the host to be an actual LUN, it is a virtual LUN, with data located elsewhere. As a
rough guide, pointer based technology uses about 20% of the space used by its Source LUN.
In contrast to pointer based technology, full copy based technology makes a full copy of the
Source LUN data, and therefore uses additional disk space equal to 100% of the space used
by the Source LUN. Because data can be copied back to the Source LUN, there is always a
requirement that the Source LUN and Full Copy Based LUN be exactly the same size. When a
Full Copy Based LUN is detached from the Source LUN, changes to both LUNs are tracked.
This enables the LUNs to be resynchronized at a later time without having to perform another
full copy. It also allows for the restoration of the source LUN back to the point in time when
the LUN was detached.
10
SnapView Snapshots use pointer-based replication to indicate where data is currently located.
It may be on the source LUN (Classic, Thin, or Thick) or may have been copied to the
Reserved LUN Pool which is the private area used to contain Copy on First Write (CoFW) data
chunks.
The SnapView Snapshot consists of 3 managed objects. The first is the Snapshot which is a
point-in-time copy of a Source LUN, the second is the Snapshot Session which defines a
point-in-time designation by invoking CoFW activity for updates to the Source LUN, and the
third is the Reserved LUN Pool.
As a result of the Copy on First Write technology used, SnapView snapshots may use
appreciably less space than a full copy, such as a SnapView clone, would use. As a rough
guide, a snapshot will use around 20% of the space occupied by its Source LUN.
11
To take advantage of the SnapView snapshot features, the VNX uses a Reserved LUN Pool.
The Reserved LUN Pool is global to the VNX storage system. The LUNs that are used in the
Reserved LUN Pool are created in the same manner as any other LUN; however instead of
being placed in Storage Groups and allocated to hosts, they are used internally by the storage
system software. This slide shows the LUNs in the Reserved LUN Pool referred to as private
LUNs private in this case means that they cannot be used or seen by attached hosts.
Each VNX system model has a maximum number of LUNs it will support and therefore, each
has a maximum number of LUNs that can be added to the Reserved LUN Pool. LUNs in the
Reserved LUN Pool count towards the maximum number of LUNs allowed on the VNX. Those
limits define the maximum number of snapshot Source LUNs on the VNX
The first step in configuring SnapView is the creation and assignment of LUNs to the Reserved
LUN Pool. Only then are SnapView sessions allowed to start. Remember that as snapable
LUNs are added to the VNX, the Reserved LUN Pool size may have to be reviewed and
adjusted. If changes to the Reserved LUN Pool are needed, they can be made online.
12
The Copy on First Write mechanism involves saving an original data chunk into the Reserved
LUN Pool when that data chunk is changed for the first time on the Source LUN. The chunk is
saved only once per snapshot. This ensures that the view of the LUN is consistent and, unless
writes are made to the snapshot, it is always a true indication of what the Source LUN looked
like at the time it was snapped.
Saving only chunks that have been changed allows for efficient use of the available disk
space; whereas a full copy of the LUN would use additional space equal in size to the Source
LUN. A snapshot typically uses about 20% of the space, on average.
13
In the example shown here, a snapshot session is active and started on the Source LUN.
When the host writes new data Chunk-C to the Source LUN, the original data Chunk C, is first
copied to the Reserved LUN Pool, then the write is processed against the Source LUN. This
maintains the consistent, point-in-time copy of the data for the ongoing snapshot. Now after
the write has been processed, the reporting host now points to both the unchanged data on
the Source LUN, plus the original data that was copied to the Reserved LUN Pool.
14
A SnapView clone is a complete copy of a Source LUN that uses copy-based technology. In
order to start the copy process, a Source LUN and a clone LUN need to be placed into a clone
group.
While the clone is a part of the clone group and un-fractured, any production write requests
made to the Source LUN are simultaneously copied to the clone. Once the clone contains the
desired data, you can fracture the clone.
Fracturing the clone separates it from its Source LUN, after which you can make it available to
a secondary server. This technology allows users to perform additional storage management
functions with minimal impact to the production host.
While fractured, changes to both the Source LUN and the Clone are tracked using the Clone
Private LUNs (discussed later in this module). By tracking the changes it allows for the clone
to be incrementally synchronized with the Source LUN to obtain any updates that have been
written to the Source LUN since the fracture.
Alternately, a reverse synchronization can be performed from the Clone back to the Source
LUN. This allows you to revert to an earlier copy of the Source LUN if the source becomes
corrupted, or if new Source LUN writes are not desired.
15
Clone Private LUNs are at least 1 GB in size and two of them need to be created before any
other clone operations can commence on the VNX. Clone Private LUNs record information
about modified data extents on the Source LUN and clone LUN after the clone is fractured.
A modified data extent is an extent of data that a production or secondary server changes by
writing to the Source LUN or the clone LUN.
A bitmap in the clone private LUN called the fracture log records this information, but no
actual data is written to the clone private LUN. The log reduces the time it takes to
synchronize or reverse synchronize a clone and its Source LUN as the software only copies
modified extents.
16
There are several differences between snapshots and clones. One such difference is when a
secondary host is accessing the snapshot or the clone. When a host accesses the snapshot,
the data is immediately available as soon as the snapshot is started; whereas, when a host
accesses the data on a clone, it must wait until the clone is fully synchronized and fractured
before it is allowed to access the data.
In contrast however, there is no performance impact when using clones as clones are
independent of their Source LUNs when fractured. Since snapshots rely on the source LUN the
Copy on First Write technology increases response times.
There are several other differences between snapshots and clones, please take a moment to
review them.
17
This module covered the VNX SnapView block-based replication product. We looked at the
business uses for the SnapView product, the different technologies used in the product, and
the differences between snapshots and clones.
19
This module focuses on the VNX Snapshots block-based replication product. We will take a
look at the business uses for the VNX Snapshots product and discuss its features and
functionality.
20
VNX Snapshots improve the SnapView Snapshot capabilities by better integrating with pools.
VNX Snapshots is a point-in-time copy of a source LUN using Redirect on First Write
technology. This functionality differs significantly from the previous method of Copy on First
Write technology used by SnapView.
When using Redirect on First Write, there is increased write performance while causing no
impact to host I/O response time as the number of snapshots per primary LUN increases.
Also, the use of Pool LUNs for both primary LUN and snapshots provide a 90% increase on
storage utilization efficiency.
The Redirect on First Write technology addresses the limitations of Copy on First Write
technology, allowing for 256 writable snapshots per LUN.
VNX Snapshots allow snapshots of snapshots, which provide point-in-time copies of snapshots
that can be written to for such cases as code and application testing. Other uses are
snapshots for backups, VMware VDI/VSI deployments, and reporting.
VNX Snapshots are application consistent and can be used to quickly and efficiently provision
copies of source data to Consistency Groups. VNX snapshots also provide restore capabilities
of snapshots to Primary LUNs.
VNX snapshots operations can be performed via Unisphere, Navisphere Secure CLI, and
snapCLI. The Secure CLI uses the same security features embodied in Unisphere. Users are
authenticated via a username, password, and scope combination associated with each CLI
command sent to the storage system. A host-based utility, snapCLI, can perform a subset of
the VNX Snapshot management operations as well.
21
VNX Snapshots enable data access for several applications in a typical business environment
without compromising the access to production data. VNX Snapshots are designed to provide
point-in-time data copies for system backups, testing, decision support scenarios, fast local
data recovery, and local data migration.
For critical applications, point-in-time copies may be taken every hour to allow easy recovery
from corrupted or damaged files.
Decision support systems benefit from using point-in-time copies, as they are using real data,
and have a minimal effect on the production application.
In virtualized environments VNX Snapshots can provide local-level protection for VMware
VDI/VSI deployments.
22
There are several differences between VNX snapshots and SnapView snapshots.
One of the main differences is that VNX Snapshots improve upon the SnapView Snapshot
capabilities by better integrating with pools.
Also, VNX Snapshots use Redirect on First Write technology. This functionality differs
significantly from the previous method of Copy on First Write used by SnapView. With
Redirect on First Write, it is no longer necessary to read and write old data blocks to a
reserved area when new writes from the application are processed to the source LUN.
Other differences include the maximum number of snapshots per source LUN and maximum
number of snapshots per VNX and the ability of VNX snapshots to take a snapshot of a
snapshot.
There are several other differences between VNX snapshots and SnapView snapshots. Please
take a moment to review them.
Note: CGs (Consistency Groups) and SMP (Snapshot Mount Point).
23
The Redirect on First Write technology is significantly different from SnapView Copy on First
Write. It is no longer necessary to write old data blocks to a reserved area when new writes
from the application are processed to the source LUN.
With Redirect on First Write, new writes to the primary LUN are stored in a new area within
the same VNX Pool as the snapshot data. Reads to these data blocks are directed to the new
location. In the same manner, writes to a snapshot are directed to the new location to
preserve the snapshot, and reads to these modified data blocks are referenced to the new
data location.
24
When using Redirect on First Write, when a host writes to the source, the new data is written
to new area and then subsequent reads to that data reference the new location.
When writes are performed to the snapshot, these writes are also sent to the new area.
When reads are done to the first snapshot, all data is read from the source LUN unless writes
to the snapshot have occurred. In that case the data will be read from the new area.
If a second snapshot is made after writes to the Primary LUN have taken place, data will be
read from the original (Primary LUN) location as well as the new data area.
25
A Snapshot Mount Point is the mechanism that attaches the VNX Snapshot to the host. Hosts
cannot attach to the snapshot unless the Snapshot Mount Point is created and added to the
hosts storage group on the VNX.
Once attached, the Snapshot Mount Point appears and can be used as a regular LUN.
Snapshot Mount Points provide the ability for hosts to write to and change snapshots without
the need to rescan the SCSI bus on the client.
26
Copying an unattached VNX Snapshot creates an identical replica except for the snapshot
name and the allowReadWrite flag which is by default set to no.
These copies reside in the same pool as the Primary LUN and the source VNX Snapshot and
will preserve the properties of the Primary LUN.
This process can be performed only on snapshots that are not attached to a Snapshot Mount
Point. Attached Snapshots are branched by the process of snapping Snapshot Mount Points,
which is called Cascading Snapshots.
Copying a VNX Snapshot will increase the snapshot count by one and will observe the Max
Snapshots per source limit of 256.
27
A Consistency Group is an object that groups either a list of Primary LUNs or Snapshot Mount
Points that are associated with a host and/or server application Consistency Groups cannot
mix Primary LUNs and Snapshot Mount Points. These LUNs are treated as a single entity for
taking write-order consistent snapshots.
Snapping the Consistency Group creates a snapshot set that represents the snapshots of the
individual Consistency Group members.
Typical uses are transactional databases and logs stored in separate LUNs that belong to an
application server. When a snapshot of a Consistency Group is initiated, all writes to Primary
LUNs are held until their snapshots have been created.
28
Expired snapshots are destroyed at regular intervals. The VNX scans for expired snapshots
once an hour keep in mind the Auto-Delete process does not process destruction of expired
snapshots; the destruction is handled by another software layer. When the expiration time is
reached, the snapshot may not go away immediately. It is deleted by the process started at
the next running interval.
The destruction of a snapshot triggers a storage reclamation process to return consumed
capacity back to the pool. The expiration field is a user settable number in
days/hours/months/years. When the expiration date is reached, the snapshot is deleted but
may not go away until the driver deletes expired snapshots or snapshot sets. Snapshots that
are attached to a Snapshot Mount Point or that are involved in restores are not destroyed by
the Expiration process. Also, enabling Auto-Delete for a Snapshot automatically clears the
Expiration timestamp for that Snapshot and the user is warned in Unisphere.
29
VNX Snapshots share the same pool as the Primary LUN. More storage space might be
necessary to accommodate the changes to a Primary LUN and its point-in-time copies. Autodelete is a mechanism that provides automated space management and capacity reclamation
to a storage pool that is filling up in order to protect the Thin LUNs.
Auto-delete is a background process that scans the pool for eligible Primary LUNs, Snapshot
Mount Points, Consistency Groups, snapshots, and snapshot sets. All eligible expired
snapshots are deleted before processing for snapshots with the auto-delete option enabled
and the expired snapshots are deleted regardless of pool auto-delete thresholds.
Auto-delete is triggered using two independent thresholds consumed pool space and
consumed snapshot space. The process is stopped when the threshold conditions are met, or
if no eligible snapshots remain to be deleted or the process is manually stopped.
Storage reclamation is independent from auto-delete; therefore, free pool capacity may be
realized slowly. Attached snapshots are excluded from auto-delete regardless of other
settings. Also, enabling auto-delete on a snapshot with an expiration date set will cause the
expiration date to automatically be cleared.
30
This module covered the VNX Snapshots Block-based replication product. We discussed the
business uses for the VNX Snapshots product, the technology used within the product, and
the differences between the VNX snapshots and VNX SnapView products.
32
This module focuses on the VNX SnapSure File-based replication product. During this module
we will explore the business uses for the VNX SnapSure product and review the features and
functionality of the product.
33
VNX SnapSure provides read only or read/write point in time views of VNX File system.
These logical views are called snapshots and saves disk space and time by allowing multiple
snapshot versions of a VNX file system. SnapSure is not a discrete copy product and does not
maintain a mirror relationship between source and target volumes. It maintains pointers to
track changes to the primary file system and reads data from either the primary file system or
from a specified copy area. The copy area is referred to as a SavVol, and is defined as a VNX
metavolume.
VNX SnapSure is fully supported in both Unisphere and Navisphere Secure CLI.
34
Read-only and writeable snapshots can serve as a direct data source for applications that
require point-in-time data.
Read-only snapshots can be used as a data source for automated backup engines performing
backup to tape or disk. You can also use a read-only or a writeable snapshot to restore a
Primary File System or part of a file system, such as a file or directory, to the state in which it
existed when the snapshot was created. Snapshots are integrated and can be used with
Windows Volume Snapshot Service.
Writeable snapshots can be used for applications such as simulation testing, data warehouse
population, and can also serve as a source for applications that require incremental,
temporary changes.
For example, a VNX file system may host an Oracle database on which a customer wants to
test changes without actually applying those changes back to the production view. Another
example is an administrator applying a database patch. It is first applied to the writeable
snapshot and tested. If everything works, then a snapshot Restore is used to commit the
changes from the writeable snapshot back to the Primary File System.
Another use is when an administrator wants to perform sanity checks to the Primary File
System, without taking it offline, the administrator can do this by running an fsck against a
writeable snapshot instead of the Primary File System.
35
Lets have a look at how the SavVol functionality works. We start with a Production File
System with data blocks containing the letters A through F. When the first file system
snapshot is created, a SavVol is also created on disk to hold the bitmap, the original data
from the Production File System, and that particular snapshots blockmap. Each bit of the
bitmap will reference a block on the Production File System.
Next, a user or application makes some modification to the Production File System. In this
example, we are writing an H in place of B, and a K in place of E.
Before these writes can take place, SnapSure will place a hold on the I/Os and copy the B
and E to the SavVol.
Then, the blockmap will be updated with the location of the data in the SavVol. In this
example, the first column of the blockmap refers to the block address in the Production File
System, and the second column refers to the block address in the SavVol.
Next, the bitmap is updated with 1s wherever a block has changed in the Production File
System. A 0 means that there were no changes for that block.
After all this process takes place, SnapSure will then release the hold on the I/Os and the
writes can be established. If these same two blocks are modified once again, the writes will go
through and nothing will be saved in the SavVol. This is true because the Copy on First Write
principle we already saved the original data from that point in time and anything after that
is not Snapshot 1s responsibility.
36
With VNX SnapSure, you can create, delete, and restore writeable snapshots.
Writeable snapshots are branched from the baseline read-only snapshots and can be
mounted and exported as read-write file systems.
A baseline snapshot exists for the lifetime of the writeable snapshot. Any writeable snapshot
must be deleted before the baseline is deleted.
Writeable snapshots cannot be refreshed or be part of a snapshot schedule.
37
Writeable snapshots share the same SavVol with read-only Snapshots. The amount of space
used is proportional to the amount of data written to the writeable snapshot file system. Keep
in mind that block overwrites do not consume more space. The SavVol will grow to
accommodate a busy writeable snapshot file system. There is no SavVol shrink, the space
cannot be returned to the cabinet until all snapshots of a file system are deleted. A deleted
writeable snapshot returns its space to the SavVol.
38
The Checkpoint Virtual File System is a navigation feature that provides NFS and CIFS clients
with automatic read-only access to all read-only snapshots from within an automatically
created hidden directory in the Primary File System. This reduces or eliminates the need for
help-desk involvement in user-level file and directory restore requests, and minimizes the
necessity of using the backups for these small restore requests.
NFS clients can access the Checkpoint Virtual File System by mounting the UNIX host and
navigating to the hidden directory.
CIFS clients access the Checkpoint Virtual File System via the ShadowCopyClient which is a
Microsoft Windows feature that allows Windows users to access previous versions of a file via
the Microsoft Volume Shadow Copy Server. The ShadowCopyClient is supported by the VNX to
enable Windows clients to list, view, copy, and restore files in snapshots created with VNX
SnapSure. All read-only snapshots of the Primary File System are immediately visible to VSS
clients as previous versions. Remember that Writeable Snapshots cannot be accessed
through the Checkpoint Virtual File System.
39
This module covered the VNX SnapSure file-based replication product. We explored the
business uses for the VNX SnapSure product and reviewed the features and functionality of
the product.
41
This module focuses on the RecoverPoint/SE Local Protection block-based replication product.
During this module we will explore the business uses for the RecoverPoint/SE Local Protection
product and review the products features and functionality.
42
RecoverPoint/SE Local Protection does not use the WAN to replicate data. Instead of
compressing the data and sending it over the WAN to a remote volume, it writes the data to a
local volume. As there is no WAN involved, and hence no latency concern, RecoverPoint/SE
Local Protection can synchronously track every write in the local Journal and distribute the
write to the target volume, without impacting the application servers performance.
The process begins with the production host writing data to the production volumes.
The write is intercepted by the splitter, and the splitter sends the write data to the
RecoverPoint Appliance. Immediately upon receipt of the write data, the RecoverPoint
Appliance returns an acknowledgement to the splitter.
The splitter then writes the data to the production storage volume. Next, the storage system
returns an acknowledgement to the splitter upon successfully writing the data to storage.
Finally, the splitter sends an acknowledgement to the host acknowledging the write has been
completed successfully.
43
RecoverPoint/SE Local Protection is an enterprise-scale solution designed to protect

application data on heterogeneous servers and storage arrays. RecoverPoint/SE Local
Protection protects and supports the replication of data within the local storage environment
and uses the existing infrastructure to integrate seamlessly with existing host applications and
data storage subsystems.
RecoverPoint/SE Local Protection runs on an out-of-band appliance and combines industryleading continuous data protection technology with a bandwidth efficient, no-data-loss
replication technology.
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 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
The RecoverPoint/SE Local Protection Management Application allows you to manage the
RecoverPoint/SE Local Protection system. The application provides access to all boxes in the
local RPA cluster. ll of the information necessary for routine monitoring and configuration of
the RecoverPoint/SE Local Protection system is included in the RecoverPoint/SE Local
Protection Management Application.
44
RecoverPoint/SE Local Protection offers flexible recovery of all your data to any point in time.
It does this by intercepting all writes to a source volume, and mirroring a copy of that write to
the RecoverPoint appliance, which stores a compressed copy of the data in the Journal, then
writes it to the replica LUN.
Recovered images can be used for a variety of purposes such as backup and recovery,
testing, development, and training, surgical recovery of files/folders, seeding a data mining
farm, and cloning a federated environment.
45
The RecoverPoint Journal stores all changes to all LUNs in a Consistency Group. It also stores
metadata that allows an Administrator to quickly identify the correct image to be used for
recovery.
The Journal provides time-stamped recovery points with application-consistent bookmarks. It
also correlates system-wide events (port failure, system error, etc.) with potential corruption
events, very useful when performing root-cause analysis. These application and system
bookmarks are automatic, but users can also enter their own bookmarks into the system.
The Journal also has the ability for application-specific annotations for Microsoft Exchange
Server, Microsoft SQL Server, and has Oracle awareness for Oracle 9i running on Solaris.
46
Each copy of data in a consistency group must contain one or more volumes that are
dedicated to holding point in time history of the data. The type and amount of information
contained in the journal differs according to the journal type.
There are two types of journal volumes copy journals and production journals. The journal
volumes hold snapshots of data to be replicated. 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 one or more volumes presented to all the RecoverPoint
Appliances 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 several factors. The change rate of the data being
protected, the amount of time between point in time images, and the number of point in time
images that are kept.
47
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 will
not be replicated or visible to the host. This is an important design consideration for
heterogeneous storage environments.
48
A special volume called the Repository volume must be dedicated on the SAN-attached
storage for each RecoverPoint Appliance cluster. This volume stores configuration information
about the RecoverPoint Appliances, the cluster, and the consistency groups. This enables a
properly functioning RecoverPoint Appliance to seamlessly assume the replication activities of
a failing RecoverPoint Appliance from the same RecoverPoint Appliance cluster.
There is a Repository volume for every RecoverPoint cluster. The volume is presented to
each RecoverPoint Appliance, either via the SAN or using iSCSI for virtual RecoverPoint
Appliances.
49
The array-based splitter runs in each storage processor of a VNX array and splits all writes to
a volume, sending one copy to the original target and the other copy to the RecoverPoint CDP
appliance. The Array-based splitter is supported on VNX arrays.
50
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. Settings
and policies for data protection are defined for each consistency group. Examples of these
parameters are: compression, bandwidth limits, and maximum lag.
As an example, 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.
51
RecoverPoint supports 3 replication modes.

In Synchronous replication, the replica must acknowledge the write transaction before an
acknowledgement can be returned to the host application that initiated the write. Replication
in synchronous mode produces a replica that is 100% up to date with the production source.
Synchronous communications is efficient within the local SAN environment for RecoverPoint.
Asynchronous replication does not conserve bandwidth. Furthermore, and particularly as
volumes increase, it is increasingly susceptible to data loss, as more and more data that has
been acknowledged at the source may not have been delivered to the target. RecoverPoint
can limit the use of asynchronous replication to those situations in which it enables superior
host performance but does not result in an unacceptable level of potential data loss.
Snap-based replication is an alternative Asynchronous replication mode available for VNX
arrays. VNX users can leverage and replicate array snaps during high load periods or
periodically. It reduces the amount of traffic sent from source to target, saving bandwidth and
consuming less journal space.
52
This module covered the RecoverPoint/SE Local Protection block-based replication product.
During this module we explored the business uses for the RecoverPoint/SE Local Protection
product and reviewed the products features and functionality.
54
As we have seen in this course, the VNX Local Protection Suite is comprised of four products.
VNX SnapView, VNX Snapshots, VNX SnapSure, and RecoverPoint/SE Local Protection. Each
of these products has a unique set of features for protecting and repurposing data by creating
local File and Block replicas. This table contrasts the various products contained in the VNX
Local Protection Suite. Please take a moment to review them.
55
This course covered the various technologies that make up VNX Local Protection Suite
solutions. This included an overview of the architecture, features, and functionality of VNX
SnapView, VNX Snapshots, VNX SnapSure, and RecoverPoint/SE Local Protection.
56
57

VNX Local 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 Local Protection Suite Fundamentals

Uploaded by

Copyright:

Available Formats

Welcome to the VNX Local Protection Suite Fundamentals course.

Copyright 2014 EMC Corporation. All rights reserved.