MirrorView and SAN Copy Configuration and Management SRG R29

MirrorView and SAN Copy
Configuration and Management

Student Guide
EMC Education Services
November 2009
Copyright © 2009 EMC Corporation. Do not Copy - All Rights Reserved.
MirrorView and SAN Copy Configuration and

Management
© 2009 EMC Corporation. All rights reserved.
Welcome to MirrorView and SAN Copy Configuration and Management.
Course Introduction - 1
Revision History
Rev Number Course Date Revisions
3.24.0.1 January 2007 Complete

3.26.0.1 September 2007 Complete
4.28.0.1 September 2008 Complete
4.28.5 February 2009 Complete
4.29 October 2009 Complete
© 2009 EMC Corporation. All rights reserved. Course Introduction - 2
Copyright © 2009 EMC Corporation. All rights reserved.

These materials may not be copied without EMC's written consent.
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.
EMC² , EMC, EMC ControlCenter, AdvantEdge, AlphaStor, ApplicationXtender, Avamar, Captiva, Catalog
Solution, Celerra, Centera, CentraStar, ClaimPack, ClaimsEditor, ClaimsEditor, Professional, CLARalert,
CLARiiON, ClientPak, CodeLink, Connectrix, Co-StandbyServer, Dantz, Direct Matrix Architecture, DiskXtender,
DiskXtender 2000, Document Sciences, Documentum, EmailXaminer, EmailXtender, EmailXtract, enVision,
eRoom, Event Explorer, FLARE, FormWare, HighRoad, InputAccel,InputAccel Express, Invista, ISIS, Max
Retriever, Navisphere, NetWorker, nLayers, OpenScale, PixTools, Powerlink, PowerPath, Rainfinity, RepliStor,
ResourcePak, Retrospect, RSA, RSA Secured, RSA Security, SecurID, SecurWorld, Smarts, SnapShotServer,
SnapView/IP, SRDF, Symmetrix, TimeFinder, VisualSAN, VSAM-Assist, WebXtender, where information lives,
xPression, xPresso, Xtender, Xtender Solutions; and EMC OnCourse, EMC Proven, EMC Snap, EMC Storage
Administrator, Acartus, Access Logix, ArchiveXtender, Authentic Problems, Automated Resource Manager,
AutoStart, AutoSwap, AVALONidm, C-Clip, Celerra Replicator, CLARevent, Codebook Correlation Technology,
Common Information Model, CopyCross, CopyPoint, DatabaseXtender, Digital Mailroom, Direct Matrix, EDM, E-
Lab, eInput, Enginuity, FarPoint, FirstPass, Fortress, Global File Virtualization, Graphic Visualization, InfoMover,
Infoscape, MediaStor, MirrorView, Mozy, MozyEnterprise, MozyHome, MozyPro, NetWin, OnAlert, PowerSnap,
QuickScan, RepliCare, SafeLine, SAN Advisor, SAN Copy, SAN Manager, SDMS, SnapImage, SnapSure,
SnapView, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix DMX, UltraFlex, UltraPoint,
UltraScale, Viewlets, VisualSRM are trademarks of EMC Corporation.
All other trademarks used herein are the property of their respective owners.
Course Objectives
Upon completion of this course, you will be able to:
y Explain SAN Copy concepts
y Configure and manage SAN Copy
y Explain MirrorView/S and MirrorView/A concepts
y Configure and manage MirrorView/S and MirrorView/A
y Use EMC Navisphere Manager, Navisphere Secure CLI
and admhost in a practical environment
The objectives for this course are shown here. Please take a moment to review them.
NOTE: All information in both the slides and Appendix are used in the creation of exams
to support the EMC Proven Professional Program. It is highly recommended ALL
materials be reviewed in preparation for the exams.
Course Introduction
y This course is aimed at IT and support personnel who are or will:
– Manage CLARiiON remote replication with MirrorView or SAN Copy
– Architect and position customer solutions with MirrorView or SAN Copy
y To understand the content and successfully complete this course, a
student should have knowledge and skills associated with the following:
– CLARiiON models, components, management options and features
– Data integrity and availability features found in a CLARiiON storage platform
– CLARiiON performance, storage configuration and provisioning concepts
– PowerPath performance, transparent recovery and availability features in an open
systems host environment
– SAN terminology, features, architecture, theory of operations, and management
including Fibre Channel and IP Storage networks concepts and EMC Connectrix
switches
– SnapView operation, terminology and performance
– Basic MirrorView and SAN Copy operation
– A list of specific prerequisite courses can be found in EMC Education Services
Learning Management System
The course assumes the student has base knowledge and has met the prerequisites detailed
shown here. Please see PowerLink (http://powerlink.emc.com) for additional information on the
CLARiiON family of arrays.
Class Introductions
y Name
y Company
y Region
y Role
y CLARiiON experience?
y SAN Copy experience?
y MirrorView experience?
The Environment
y Locations
– Restrooms
– Cafeteria – coffee
– Network / Phone Access
– Smoking Area
– First Aid
– Water cooler
y Hours of Class
– 9:00am – 5:00pm, please be on time
– Lunch
– 50 percent lecture 50 percent class exercises and labs
Mornings start with a lecture at 9:00 A.M. and there is an hour long break at lunch time, usually
taken at noon. There are also two 15-minute breaks, one taken in each of the morning and
afternoon sessions. The instructor will set the exact times at the beginning of class.
Classroom Etiquette
y The following must not be in use during lecture:
– Cell phones (set to vibrate if possible)
– Laptops (must be closed during lecture)
– PDAs
– Other reading material
y If the phone rings, answer it as

you step out of class
y Food and drink allowed in classroom, but not lab
y You must inform the instructor of any and all absences
from classroom sessions. Excessive absences will result
in non-certification. Also inform your lab partner
Agenda:
y Day 1
– Introduction
– Module 1: SAN Copy and Incremental SAN Copy
¾ Lesson 01 – SAN Copy and Incremental SAN Copy Features
¾ Lesson 02 – Managing SAN Copy with Navisphere Manager
¾ Lesson 03 – Managing SAN Copy with Navisphere Secure CLI
¾ Lesson 04 – Using admhost with SAN Copy
Lab Exercise 1: Create and Test a Local SAN Copy Session
Lab Exercise 2: Create and Test a Remote SAN Copy Session
Lab Exercise 3: Create and Test an Incremental SAN Copy Session
Agenda:
y Day 1 (continued)
– Module 02 – MirrorView/A and MirrorView/S
¾ Lesson 01 MirrorView/S and MirrorView/A Features
¾ Lesson 02 – MirrorView Consistency Groups
¾ Lesson 03 – Managing MirrorView with Navisphere Manager
¾ Lesson 04 – Managing MirrorView with Navisphere Secure CLI
¾ Lesson 05 – Using MirrorView with SnapView
Lab Exercise 4: Create a Synchronous Remote Mirror
Lab Exercise 5: Promote and Test a Secondary Mirror Image
Lab Exercise 6: Create and Test an Asynchronous Mirror
Lab Exercise 7: Create and Test a MirrorView/A Consistency Group
Lab Exercise 8: Create a MirrorView/A Mirror with the Navisphere TaskBar
MirrorView Wizard
Module 1: SAN Copy and Incremental SAN Copy

Upon completion of this module, you will be able to:
y Configure and manage SAN Copy with Navisphere
Manager
y Configure and manage SAN Copy with Navisphere
Secure CLI
y Use admhost in conjunction with SAN Copy
© 2009 EMC Corporation. All rights reserved. Module 1: SAN Copy and Incremental SAN Copy - 1
The objectives for this module are shown here. Please take a moment to read them.
Module 1: SAN Copy and Incremental SAN Copy - 1

Lesson 1: SAN Copy and Incremental SAN Copy

Features
Upon completion of this lesson, you will be able to:
y Explain the features of SAN Copy and Incremental SAN
Copy
y Discuss the requirements for using SAN Copy and
Incremental SAN Copy in a CLARiiON environment
y Remote Replication Enhancements
The objectives for this lesson are shown here. Please take a moment to read them.

Overview of SAN Copy and Incremental SAN Copy

y Bulk data transfer
– CLARiiON to/from CLARiiON, Symmetrix, and other vendor storage
y Source LUN may be a point in time copy

– SnapView Clone, SnapView Snapshot, Symmetrix point in time copy
y SAN-based (FC or iSCSI) data transfer

– Offloads host traffic – no host-to-host data transfer
– Higher performance – less traffic
– OS independent
– Secure
y Full or incremental copies
SAN Copy allows fast bulk transfer of data between CLARiiON and Symmetrix systems (other
vendor systems are not discussed here) over FC, and transfer between CLARiiONs over iSCSI.
The (full mode) SAN Copy Source LUN is likely to be a point in time copy because of the way
SAN Copy functions when full data copies are used. If Incremental mode is used, then the
source LUN may be the production LUN, and can be online.
Some of the key benefits supplied by the EMC SAN Copy software are shown here. One of the
key benefits is the off-load of host traffic, with an associated increase in copy performance. Data
is copied directly from one storage system to the other, with no host involvement in the copy
process. Copies can be performed without regard to the host operating system, again because no
hosts are involved in the copy. Because ownership of the logical units or volumes does not have
to be shared, host operating system security is not compromised.
SAN Copy requires no special software to be loaded on the peer storage systems. In addition,
unlike MirrorView/S, it does not use a special protocol. This makes SAN Copy efficient and
fast.

SAN Copy Requirements and Recommendations

y A SAN Copy CLARiiON must be involved in any transfer
y SAN Copy CLARiiON ports must be accessible to
attached storage system ports
y Navisphere Agent should be installed on any host that
owns Symmetrix SAN Copy volumes
y Hosts that own Symmetrix volumes may need to be in a
portal configuration
y LUNs must be made available to SAN Copy ports
y SAN Copy cannot share an SP port with MirrorView
Either the source logical unit, destination logical units, or both must reside on a SAN Copy storage
system, a CLARiiON running SAN Copy software.
You must correctly zone (for FC connections) or connect (for iSCSI connections) SAN Copy ports to
peer storage system ports in order for SAN Copy to have access to those systems.
In order for Navisphere Manager to provide the drive letter/file system mapping of participating
Symmetrix volumes, the Navisphere Host Agent must be installed on the hosts that own the volumes, and,
if that host is not also connected to a CLARiiON in the domain, it must be in a portal configuration. If
installing the host agent is not possible, the user may manually enter the WWN of the Symmetrix volume.
Another option may be to install the host agent for as long as is required to set up the SAN Copy
Sessions, then remove the host agent. The same may be done with the portal configuration.
You must make logical units participating in a SAN Copy session accessible to the participating SAN
Copy port; this will involve FC zoning or creating iSCSI connections as well as the use of LUN masking
software.
SAN Copy cannot share an SP port with MirrorView. Both SAN Copy and Incremental SAN Copy may
share ports with host I/O, though the performance impact must be carefully considered.
Zone or connect at least one port from each SP of the SAN Copy storage system to peer storage system
ports participating in SAN Copy sessions.
For FC connections, create a single zone that includes a SAN Copy port and multiple peer ports, create
multiple zones with a single SAN Copy port and a single peer port, or a create a mixture of both zone
types. For iSCSI connections, create the required connection sets.

If performance is the primary concern, zone or connect multiple SAN Copy ports to a peer
storage system. SAN Copy allows multiple sessions to share a single port, but, if there are
multiple ports available, SAN copy will spread multiple sessions across the available SAN Copy
ports to maximize total throughput.
You must make logical units participating in a SAN Copy session accessible to the participating
SAN Copy port.
Access Logix is required on the SAN Copy storage system and any other CLARiiON storage
systems involved in a SAN Copy session. A LUN masking method will need to be used on any
non-CLARiiON storage system participating in a SAN Copy Session.
The SAN Copy port(s) must be added to the storage group on the non-controlling CLARiiON.
This applies regardless of whether the LUN(s) on the non-controlling CLARiiON are used as
source or destination LUNs for a SAN Copy session.
San Copy ports display in Navisphere much the same as any attached host. The SAN Copy port
will be identified by the storage system name rather than the Storage Processor network name,
the owning Storage Processor, and also the port’s World Wide Name.

SAN Copy Features

y Multiple Sessions can run concurrently
y A Session may have multiple destinations
y Sessions can be queued, paused, resumed and aborted
y Checkpoints are written at user-specified intervals
y A throttle mechanism allows transfer speed adjustment
y User can choose connection type
– FC, iSCSI, or Fibre Preferred (which tries FC, then iSCSI)
Major features of SAN Copy include the ability to run concurrent sessions. This allows multiple
source LUNs to be simultaneously transferring data to multiple destination LUNs. The number
of Sessions running concurrently is set at the SP level, but will not exceed the limit for the
storage system model. See the Release Notes for the current limits for each model.
Queued SAN Copy sessions are sessions that have been created but are not active or paused;
typically, they are waiting for another Session to complete before they can start transferring
data, because the storage system is already actively transferring data for the maximum permitted
number of sessions. Note that queued sessions are marked (see explanation later), which implies
that COFW activity can be present for that session. Control over an active session is in the hands
of the administrator. It is possible to pause and later resume a session or abort a session before
completion.
The management tools allow the user full control to create and modify sessions as seen fit, and
to change certain Session parameters.
Checkpoints are written to disk at administrator-defined time intervals. The feature allows SAN
Copy to resume an interrupted session from the last checkpoint, rather than having to restart the
session from the beginning.
The speed of a SAN Copy transfer, and therefore the resources used by the SAN Copy session,
can be controlled through the use of a throttle value, which ranges from 1 (slow) to 10 (fast).

This is the only mechanism that will adjust transfer speed; setting the speed of the network to a
lower value than is actually available will not slow down the transfer rate.
SAN Copy allows simple user control over the connection type. A useful feature is the ‘Fibre
Preferred’ option, which will try to use FC connections between the storage systems involved in
a session, then try iSCSI connections if no FC connections exist. Note that this does not imply
that a session will automatically switch over from one connection type to another in the event of
a failure; the failover is a manual process.

Incremental SAN Copy Features

y Incremental copy
– Changed data tracked at 2 kB granularity; COFW still 64 kB
– Data transferred at 2 kB granularity
– Map of tracked changes stored persistently
y Mark and Unmark operation

– Affects state of ISC SnapView Session
y Modify Incremental Copy Session Properties

– Turn on/off incremental tracking
– Link Bandwidth & Latency
– Sync Required (full copy)
y Resume to only failed destinations
Incremental SAN Copy only copies changes to the destination(s). Changes are tracked by means
of bitmaps, and, if required, a COFW process will be performed (both operations require that a
Reserved LUN is assigned to the Source LUN.)
Networks with speeds starting at T1 connections are supported. SAN Copy will perform a
certain amount of optimization, depending on network speed and latency.
Incremental SAN Copy shares the ‘chunk’ size with SnapView, 64 KB, so that a COFW copies
64 kB of data to the Reserved LUN. When the changed data must be copied to the secondary,
only the 2 kB ‘sub-chunks’ that have changed are actually copied. This makes the link
utilization much more efficient.
The mark and unmark processes start and end the point in time copy process; the tracking of
changes continues, though, and the ISC SnapView Session continues to run. SAN Copy is aware
of which copies have succeeded and can resume to failed destinations only.

Additional Features
y ISC-specific statistics
– Time last marked
– Time copy started
– Blocks to copy in next incremental update
y Auto-Recovery (all SAN Copy Sessions)

– SP Reboot
– LUN trespass
Additional reporting functionality is present for Incremental SAN Copy. SAN Copy can recover
from SP reboots and LUN trespasses; the process is discussed later.

SAN Copy Parameters

y Buffer size
– Default 1024 blocks (512 kB), maximum 2048 blocks (1024 kB)
y Number of buffers per copy
– Default 4, maximum 16
y Number of Concurrent Copies per SP
– CLARiiON model dependent
y Copy Session initial contents
– Source and Destination WWNs, Initial Throttle value, User-assigned name
y Some contents can be modified
– Destinations, Throttle value
y Copy Session status
– Completion status (success or nature of failure)
– Time of completion
– Number of consecutive blocks copied before failure
SAN Copy performance can be affected by some of the configurable parameters.

The default buffer is size is 1024 blocks, with a maximum size of 2048 blocks. This, in
conjunction with the number of buffers per session, will have an effect on the overall
performance of a SAN Copy session.
The buffer size and number of buffers may be changed, but in the absence of detailed
performance analysis, should be left at the default values. Incremental SAN Copy will calculate
the required values for incremental sessions, based on link bandwidth and latency.
Performance is also affected by the number of concurrent copies. The contention for resources
will increase as the number of active copy sessions increases.
See the SAN Copy Release Notes for the latest information about SAN Copy limits.
The values stored in the PSM for when a session is created include both the source and
destination World Wide Names (Fibre) or IQNs (iSCSI) and the initial throttle value and session
name, both of which are user defined.
The throttle value and destinations (add/remove) may be modified after creation by the user. A
name is supplied by SAN Copy and may be changed at Session creation time.
After the session is started the first time, the PSM LUN entries for the session will be updated
with the completion status, the time of completion and, in the case of a failure, the number of
blocks transferred before the failure.

Host Buffer Issues

y Most OS maintain buffers associated with data on LUNs
y The host doesn’t know when SAN Copy reads or writes a
LUN, and doesn’t flush or refresh the buffers
y Most UNIX systems have mount/unmount/flush
commands which can be used to manage the buffers
– Example: The Solaris ‘sync’ command will flush host buffers
y Windows has no such commands, so we supply a host-

based utility called admhost
y admhost commands are identical to three of the
commands supplied with admsnap, but with different
names
The host buffer issues mentioned here are similar to those encountered when using SnapView;
some of the discussion may already be familiar to you.
When a SAN Copy session starts, the integrity of the Source LUN is vital. This can only be
guaranteed if the host has committed all write buffers to the source LUN.
On Unix systems this can be forced through the flush/unmount/mount commands. The unmount
command flushes host buffers, then unmounts the specified filesystem, making it inaccessible to
the host; the mount command makes the filesystem accessible through a specified mount point.
Unix hosts also have a sync command, which flushes host buffers without unmounting the
filesystem.
Windows hosts have no such commands, but a Windows host-based command line utility,
admhost, is provided with SAN Copy to accomplish these actions. Admhost is similar to the
Windows host-based command line utility, admsnap, that is provided with SnapView.

SAN Copy Session Creation Process Flow

y Configure SAN Copy Connections
– Not needed for local copy
– Physical connections – cabling and zoning – must be in place
– CLARiiONs in same domain, or multi-domain management in use
– Portal configured if required
– LUN masking configured
y Create Session
– Designate source storage system and LUN
– Choose Session type – Full or Incremental
– Designate destination storage system(s) and LUN(s)
– Session Name
– Throttle Value
The SAN Copy session can be set to copy data between 2 LUNs in a single CLARiiON, between
CLARiiONs, and between a CLARiiON and a non-CLARiiON storage system. While there are
many similarities when setting up these different sessions, there are also some differences. In
the interest of clarity, each of these session types will be covered in full. The creation of a SAN
Copy session involves a number of steps.
If the source and destination LUN(s) are located in different storage systems, the source storage
system must be connected to the destination storage system(s) as an initiator.
CLARiiONs in the same domain, or in different domains managed through Navisphere
Manager’s multi-domain management feature, can communicate with each other, and share
information about LUNs; all LUNs that may be used for SAN Copy purposes will be displayed
in the dialogs. If one of the storage systems is not a CLARiiON, then management will be vastly
simpler if a portal is configured, and the host that owns the LUNs or volumes used for San Copy
is added to the portal.
Access Logix, in the form of a Storage Group, will be used to perform LUN masking on the
CLARiiON, and make LUNs available to the SAN Copy CLARiiON. If the storage system is
not a CLARiiON, then LUN masking must be configured in the manner required by the storage
system vendor; Symmetrix systems, for example, will use the Volume Logix feature to perform
the masking.
The source LUN and destination LUN are easily selected. The destination must be at least as
large as the source. Each session requires a unique name and the priority of copy traffic can be
set with the throttle value.
Running an Incremental SAN Copy Session

y User creates an Incremental SAN Copy Session
– Default initial copy is a full copy
y User quiesces (freezes) Source LUN

y User starts the ISC Session (ISC marks the Session)
y User unquiesces (thaws) Copy Source LUN
y ISC Session completes (ISC unmarks Session)
y Subsequent copies are Incremental
y Start next ISC copy
– Full copy to any new destinations
– Incremental copy to existing destinations
The procedure for creation of an Incremental SAN Copy Session is shown above. The quiesce
helps to ensure consistency of the Source LUN data.
All copies following the first will be incremental. If an additional destination is added at any
time, a full copy will be performed to that destination only; subsequent copies will be
incremental.

SAN Copy Operation

y SP port becomes an initiator (looks like an HBA to SAN)
y Source LUN should be read-only during full copy
– Can be a point in time copy
y Source LUN may be R/W for ISC Sessions

y Read from Source LUN, write to destination(s)
y Start n reads from Source LUN (n = # Buffers)
y When any read completes, write to destination
y When any write completes, start another read
For SAN Copy to operate correctly, the Storage Processor port must become an initiator and
register with the non-SAN Copy storage system.
While a full copy session is operational, the source LUN should be put into read-only mode. If
this is unacceptable, a Snapshot, Clone, or other point in time copy can be created from the
source LUN and used as the source for the SAN Copy session.
Data is read from the source and written to the destinations. SAN Copy will initiate a number of
reads equal to the number of buffers allocated for the session.
When any read to the buffer is complete, SAN Copy writes the data to the destination LUN.
When the write is complete and the buffer is empty, SAN Copy refills the buffer with another
read from the source.

Create/Start Model
y User creates and stores a Copy Session for each copy
operation
y SAN Copy stores Copy Session parameters persistently
y SAN Copy assigns Session an ID that is unique across
both SPs
y Once stored, Session can be started any number of times
y After first start, Session also contains status of most
recent completion
y Each Session is specific to one SP
– It cannot be started on the peer without transferring it
When the user creates a SAN Copy session, the SAN Copy software stores that information
persistently in the PSM LUN. It is the software’s responsibility to create a unique identifier for
the session and this ID must be unique in the storage system. After the session is created and
stored it may be started any number of times. The session’s status will be updated upon each
completion, after it is started for the first time. When creating a Session, an owning SP is
specified and the Session cannot be started on the peer SP without first transferring the Session
to the peer SP; this is a manual operation.
Note that once a Session has been created, domain and portal information is no longer required
by SAN Copy, and the domain and/or portal may be removed.

SAN Copy Failover

y Sessions do not automatically failover
– If the owning SP fails or the Source LUN is trespassed, the Session
fails
– If a Destination SP fails or destination LUN is trespassed, the
Session terminates (to that destination)
y Sessions can be manually transferred to the peer SP

– Only if not active
– Once transferred, they may be manually started or resumed
– The Session start fails unless the SP it is transferred to has
connectivity to the destination SP, and access to the source and
destination LUNs
– They do not automatically transfer back when the failure is rectified
When a source LUN is not available through the session’s owning Storage Processor, the session
will fail. This will happen if the Storage Processor fails or the Source LUN is trespassed to the
peer Storage Processor.
The Session may be manually transferred from the owning SP to the peer SP only if the Session
is not active, possibly because it has failed. Because the Session has failed, it must be manually
restarted or resumed from the last checkpoint. Before the Session can be started on the peer SP,
the same restrictions apply to the peer as to the original owning SP, namely that the peer SP
must have connectivity with the destination SP and access to both the source and destination
LUNs.

Incremental SAN Copy and SnapView

y SnapView tracks changes (persistently) and provides
Mark/Unmark capabilities
y ISC requires SAN Copy and SnapView to be licensed
– SnapView licensed for system use
– SAN Copy licensed for user
– On SAN Copy storage system (not non-controlling system)
y SnapView Integration presented through SAN Copy UI

y SnapView usage somewhat hidden to user
– Automatic creation of Snapshots and SnapView Sessions during
SAN Copy Session creation
– Requires prior provisioning of Reserved LUNs
– Produces SnapView error messages
Though SnapView is required for Incremental SAN Copy use, it is largely hidden from view
when used as part of SAN Copy. The SAN Copy software will automatically license SnapView
for internal use; a user SnapView license is not required to take advantage of ISC features.
Snapshots and Sessions used by SAN Copy are treated as ‘private’, or reserved, and cannot be
managed by the user. If the SnapView UI is licensed for use, then the SnapView objects are
visible to the end user, but not manageable.

ISC SnapView Snapshot

y Modified SnapView Snapshot – always activated
y Created for and used by Incremental SAN Copy Session
– Name = SANCopy_<ISC Session Name>
y Counts as one of the 8 maximum Snapshots allowed per

Source LUN
y Displayed to user as protected
– Cannot be a Storage Group member
– SnapView management operations prohibited
y Destroyed with Incremental SAN Copy Session or when

Incremental feature is turned off
SAN Copy uses a Snapshot as shown. It is treated as private and not manageable by the user,
though it is visible to the user if the SnapView UI is licensed.

ISC SnapView Session

y Associated with ISC Snapshot
– Name = SANCopy_<ISC Session Name>
y Modified SnapView Session - always Persistent

y Counts as one of the 8 maximum Sessions allowed per
Source LUN
y Operates in one of two modes
– Marked (tracks changes and performs COFW)
– Unmarked (only tracks changes)
y Destroyed with Incremental SAN Copy Session or when

Incremental feature is turned off
y Not user-manageable
Sessions are treated in a similar way. Sessions and their Snapshots will be destroyed when a
Session is destroyed, or when the user disables the incremental feature for a SAN Copy Session.
This means that the Reserved LUN allocated to the ISC Session when it is created will not be
released until the Session is destroyed, or the incremental feature turned off. Note that the
modified SnapView Session used by ISC never stops, even if errors such as a full Reserved
LUN Pool occur.

DeltaMaps
y Bitmaps used for tracking changes for incremental
updates (maintained by SnapView)
y Stored in Reserved LUN (persistent)
y One pair per Incremental SnapView Session
– Transfer - contains changed chunks for current update cycle
– Tracking - used for tracking changes for next update cycle
y DeltaMap roles are swapped during mark

y DeltaMap data is merged during unmark
y 64 kB COFW granularity
– Transfer granularity is 2 kB
DeltaMaps are discussed in the animated slides, and their usage is illustrated there. Note that the
merging of DeltaMaps means that all bits that are set (in a 1 state) are copied to the tracking
DeltaMap.
The difference between the size of the COFW granularity and transfer granularity means that
ISC uses the link efficiently.

ISC Internal Operation

y User creates an ISC Session
– SnapView bound into Source LUN stack
– ISC SnapView Session started
– Sufficient Reserved LUN Pool space must be available for tracking
– ISC SnapView Snapshot created/activated
y User marks ISC Session (or Auto Mark occurs)

– SnapView swaps DeltaMaps, starts COFW
y User unmarks ISC Session (or Auto Unmark occurs)

– SnapView merges DeltaMaps, stops COFW
– Clears Reserved LUN Pool entries (COFW data)
Much of the Incremental SAN Copy operation revolves around the use of SnapView, as shown
above. The operations are user transparent, though the SnapView objects are visible to the user.
The Reserved LUN must be at least 0.2% of the size of the Source LUN. If it is not, there is
insufficient space for the map area, and Navisphere will not allow the ISC session to start. An
error message will be displayed upon this failure.

ISC Internal Operation (continued)

y User starts ISC Session
– SAN Copy bound into ISC Snapshot stack
– SnapView fills read buffer with appropriate data
– SAN Copy copies data to destinations
y Incremental Copy Session Completes

– Auto Unmark (no more COFW, but still tracking changes)
y User removes ISC Session

– ISC SnapView Session stopped (destroyed)
– ISC Snapshot destroyed
– SnapView potentially unbound from Source LUN stack
The notes above are a continuation of the previous slide, again illustrating the close relationship
between SAN Copy and SnapView.
Note one important change, introduced in Release 19, the COFW process uses chunks which are
64 kB in size, as is the case with a normal SnapView Session. Data to be transferred across the
link, however, is tracked in 2 kB extents. This means that only the 2 kB extents which actually
changed, and therefore caused the COFW, will be transferred. This enhancement allows the link
to be used more efficiently.
When an ISC Session is removed (destroyed), SnapView will be unbound from the Source LUN
stack if no ordinary SnapView Sessions are running on that Source LUN.

ISC Restrictions
y Failed destination(s) – can only resume or remove
y Modify ISC Session
– Cannot change ISC Session name or Source LUN
– Cannot clear Initial Sync Required property
– Cannot set Initial Sync Required property if marked
y Mark or unmark ISC Session
– No failed destinations
– Cannot mark if ISC Session not allowing COFW
y Start ISC Session
y Add destination
– Session must be unmarked
Snapshots of Snapshots are not allowed, which means that the Source of an Incremental SAN
Copy operation may not be a Snapshot. It may, however, be a Clone or a FLARE LUN.
The Snapshot and Session used by an ISC Session is private, and therefore not user manageable.
Because of the incremental nature of ISC, it requires that all destinations be in the same state
before updates can occur, hence the restrictions shown above.

Failures and Trespasses

y Trespass ISC Copy Source LUN
– ISC SnapView Session and SnapView Snapshot trespassed
– ISC Session is NOT trespassed
¾ Manually transfer ISC Session, then manually resume ISC Session
y SP Failure
– No auto-trespass of ISC Session
– SAN Copy Session auto resumed on SP reboot
y Destination Failure
– Continue copying to non-failed destinations
– Resume copies to failed destinations, or remove destinations
y Reserved LUN Pool Errors
– COFW error
¾ Active ISC Session fails, and SnapView Session becomes unmarked
¾ Continue tracking changes in DeltaMap
Trespasses of a Source LUN cause the SnapView portion of ISC to trespass, but do not affect the
SAN Copy portion of the ISC session.
Failed destinations need to be brought to the same state as other destinations before incremental
updates can be made, as noted earlier. If they cannot be updated, then removing them from the
destination list is the only other choice.
Errors related to the Reserved LUN Pool are generally related to incorrect provisioning of space.
Note that unlike standard SnapView Sessions, these sessions do not terminate if they run out of
space in the RLP; instead, the COFW process is terminated (and the resources freed up), but
tracking of changes continues.

Auto Recovery on an SP Reboot

y On an SP reboot SAN Copy will automatically try to
resume copy sessions failed due to SP failure, every 180
seconds up to 5 times
y The copy sessions will be marked failed due to SP reboot
if SAN Copy is unable to recover them after the 5 retries
y The copy session status will indicate auto-recovery
progress with this message –
¾ Auto Recovery of a copy session is in progress
y The only operation that can be performed on a copy

session with auto-recovery in progress is STOP
An SP may become unavailable because it has rebooted or because it has failed.

SAN Copy tries to ensure that a Session will survive an SP reboot by allowing sufficient time
for a reboot to have completed before finally giving up, and calling a failure. During the period
it allows, 15 minutes, it will try to resume the session by retrying 5 times at 3 minute intervals.

Remote Replication Enhancements – San Copy

Enhancement Benefits
Provides fine-grained access control of replication tasks
Roles: Local Replication, Replication, and Replication
Replication Roles Recovery
Roles can have local or global scope
y Doubled SnapView SnapShot / SAN Copy limits

Replication Limits
y New 8 Gb/s and 10 Gb/s I/O Module
y Thin Replication is applicable with SAN Copy
y SAN Copy wizard has changes to support Thin LUNs
GUI / Virtual
y Dialogs that help to configure SAN Copy now allow Thin
Provisioning
LUNs/Thin Pools as options when applicable
y Menu actions for Thin LUNs will include SAN Copy
actions
In FLARE Release 29, a new set of replication roles have been developed to provide the
customer with greater control of CLARiiON array replication. These roles are:
y Local Replication - which provides SnapView operations only (no recovery) a role that
would restrict someone to start/stop SnapView operations
y Replication - which provides SnapView, MirrorView, and SAN Copy operations (no
recovery)
y Replication Recovery - which provides SnapView, MirrorView, and SAN Copy operations
plus recovery
These replication roles can have local or global scope. In order to assign a global scope to a
user, all systems in the Domain must be running FLARE release 29. LDAP role mappings are
also supported. Replication roles can see (but not manage) objects outside of their control. This
new feature facilitates coordination of user access to data and operations. It also introduces a
finer granularity of security.
Replication Limits have doubled SnapView SnapShot / SAN Copy limits in Flare 29.
Changes have been implemented to the Navisphere GUI for the SAN Copy wizard to support
Thin LUNs. Dialogs that help to configure SAN Copy now allow Thin LUNs/Thin Pools as
options when applicable. Menu actions for Thin LUNs will include SAN Copy actions.
Thin Replication is applicable with SAN Copy.

Security – New Replication Roles: Flare 29 & Higher

y Provides fine-grained access control of
replication tasks:
– Local Replication – SnapView operations only
(no recovery)
– Replication – SnapView, MirrorView, and SAN
Copy operations (no recovery)
– Replication Recovery – SnapView, MirrorView,
and SAN Copy operations plus recovery
y Replication roles can have local or global
scope
– In order to assign a global scope to a user all
systems in the Domain must be running Flare 29
or above.
– LDAP role mapping also supported
y Replication Roles can see (but not manage) Replication Roles
objects outside their control
– Ensures that the view is not restricted
y Facilitates coordination of user access to data
and operations
Three new roles were introduced in FLARE 29 to provide fine-grained access control of
replication tasks:
y Local Replication – SnapView operations only (no recovery)
y Replication – SnapView, MirrorView, and SAN Copy operations (no recovery)
y Replication Recovery – SnapView, MirrorView, and SAN Copy operations plus recovery
Global Replication roles are only supported in a complete FLARE 29 environment, meaning all
arrays in the domain must be at FLARE 29. Global Replication roles (or LDAP mappings
thereof) cannot be created in domains that contain Pre-FLARE 29 systems. You must first
remove all Pre-FLARE systems from the domain. On the same note, Pre-FLARE 29 systems
cannot be added to domains that define global replication accounts. You would have to first
remove all global replication roles and LDAP replication mappings.
Note: All previous security roles are still in effect in Flare 29.

Replication Roles – San Copy Operations

Local Replication Replication Replication/Recovery
SAN Copy
Start a session No Yes Yes
Stop a session No Yes Yes
Pause a session No Yes Yes
Resume a session No Yes Yes
Mark a session No Yes Yes
Unmark a session No Yes Yes
Verify a session No Yes Yes
Throttle a session No Yes Yes
The chart shown here describes the Replication Roles for San Copy Operations.

Replication Limits with FLARE 29
SAN COPY Increased Replication Limits

CX4-120 CX4-240 CX4-480 CX4-960
R28 R29 R28 R29 R28 R29 R28 R29
SAN Copy
Incremental SAN Copy Sources 128 256 128 256 256 512 512 512
Replication Limits NOT Increased

CX4-120 CX4-240 CX4-480 CX4-960
R28 R29 R28 R29 R28 R29 R28 R29
SAN Copy
SAN Copy Destinations per source 50 50 50 50 100 100 100 100
Concurrent SAN Copy Sessions per
8 8 8 8 16 16 16 16
array
Incremental SAN Copy Sessions per
8 8 8 8 8 8 8 8
Source
Doubled SnapView snapshot limits, and by extension, SAN Copy

y Expands usage of SnapView and SAN Copy
y Limits not increased on CX4-960

8 Gb/s FC and 10 Gb/s iSCSI I/O Module –

SAN Copy
y SAN Copy
– Greater bandwidth
– Sequential I/O
– Large Block I/O
10 Gb/s 8 Gb/s
IP SAN FC SAN
8 Gb/s
10 Gb/s
In 8 Gb/s or 10 Gb/s point-to-point environments IOPS processing can be similar to 4 Gb/s or 1

Gb/s environments. Certain replication products may be able to take advantage of this increased
bandwidth an thus increased IOPS processing speed.
The nature of the I/O (sequential vs. random) and (large vs. small block) will affect how much
IOPS processing increases can be achieved. SAN Copy processing has the most to gain simply
because of how it functions. Full or Incremental SAN Copies are in effect sequential I/O
operations which could be large block in nature. For example, a hospital using SAN Copy is
storing medical imaging data for backup. The larger 8 Gb/s or 10 Gb/s bandwidth could provide
significant improvement in IOPS performance.

Virtual Provisioning & San Copy: Planning and

Design
y Supported with SAN Copy in FLARE 29
y Where does Thin Replication apply?
– Ideally where both the source and destinations are Thin
– Permits mixed LUN types for added flexibility
¾ Traditional LUN > Thin LUN
¾ Thin LUN > Traditional LUN
y The exception to this case is Pull copies

¾ Where the source is on the remote array, the Copy will not be
provisioned as Thin
¾ SAN Copy can only perform a traditional copy when the source is
located on a remote system
In CLARiiON FLARE Release 29, support has been added in SAN Copy to support thin LUNs.
SAN Copy thin replication applies when both the source and destinations are thin LUNs. The
exception would be “pull copies” where the source is on the remote array the copy will not be
provisioned as Thin LUN. SAN Copy can only perform a traditional copy when the source is
located on a remote system.
The ideal combination for using Virtual Provisioning with SAN Copy is to have source and
destination be thin LUNs. The following scenario’s will result in a fully provisioned Thin LUN
which could be an undesirable circumstance:
y 1st scenario - when creating a copy session with Traditional source LUN and a Thin LUN
destination.
y 2nd scenario - when creating a PULL copy session.
y 3rd scenario - when creating a copy session with Thin destination on pre-R29 array

Virtual Provisioning & San Copy – Wizard changes

y SAN Copy wizard supports Thin LUNs (R29)
Thin LUNs will now

be an option for a
SAN Copy source
If the destination array (and the

Source array) support SAN Copy on
Thin LUNs, then Thin LUNs will show
up as a destination possibilities
For the Navisphere GUI, the SAN Copy wizard has changes to support Thin LUNs. Dialogs that
help to configure SAN Copy now allow Thin LUNs/Thin Pools as options when applicable.
Menu actions for Thin LUNs will include SAN Copy actions.
For the Navisphere CLI, no changes to “sancopy” Secure CLI command syntax.

Lesson 2: Managing SAN Copy with Navisphere

Manager
y Configure SAN Copy objects with Navisphere Manager
y Manage SAN Copy objects with Navisphere Manager
The objectives for this lesson are shown here. Please take a moment to review them.

Configuring SAN Copy Connections
Before you can use SAN Copy to copy data between storage systems, SAN Copy ports must have access to
participating logical units in the peer storage systems. To make this happen, you must register each selected SAN
Copy port to ports of the peer storage systems. Once the registration process is complete, you can connect the SAN
Copy port to a Storage Group on the peer CLARiiON storage system.
Each SAN Copy port acts like a host initiator and, therefore, can connect to only one Storage Group at a time in a
storage system.
To select available ports, do the following:
y In the Storage tree, navigate to the storage system in which the Storage Group to which you want to connect
(the peer) resides, and double-click the storage system icon.
y Expand the Storage Groups icon, right-click the icon for the Storage Group to which you want to connect, and
then click SAN Copy > Connections…
y The SAN Copy Connections dialog box opens.
y In SAN Copy System, select the storage system/SP entry that includes the SAN Copy port you want to connect
to the Storage Group.
y Ports to connect lists all available SAN Copy ports for the selected SAN Copy storage system and SP.
y SAN Copy displays only those SAN Copy ports that are in the same zone or connection group as the SP ports
of the Storage Group’s storage system.
y Select all the SAN Copy ports that you want to connect to the selected Storage Group, and click OK.
The storage group in the destination storage system should display the established SAN Copy connections in
addition to the hosts and LUNs in the storage group.
The Tools > SAN Copy > Connections Summary option will also show all current SAN Copy connections.
Note iSCSI connections will appear here as well. A Fibre preferred connection will search for a fibre connection
path to the remote LUN first and an iSCSI connection path second.

SAN Copy Settings
The SAN Copy > Settings… option allows configuration of the number of concurrent sessions
per SP, number of buffers per session, buffer size, and checkpoint interval.
The memory configured here will be used by SAN Copy when running full as well as
incremental sessions. Note that the buffer size, by default 512 kB, ( 1024 blocks) is smaller than
the default LUN write-aside value, which means that SAN Copy writes will hit write cache.
Note: The Cache Write Aside Size sets the size of the largest write request (in blocks) that will
be stored in write cache prior to being written to disk. Write requests that are less than or equal
to this value are written to cache. Write requests that are larger than this value are written
directly to disk. Valid values are 16 through 65534. For example, if the cache write aside size
has been set to 1023, all write requests equal to or less than 1023 will be written to cache. Write
requests larger than 1023 will be written directly to disk.

Session Creation – Wizard Start
To create a CLARiiON to CLARiiON SAN Copy session, right-click the storage system on
which you want to create the session. This storage system must have the SAN Copy software
installed, click SAN Copy, and then click Create Session.
The first wizard screen to appear is a summary of the steps the wizard will take the user through
in the creation of the session. Read the wizard summary and click Next.

Choose Session Type
The Select Session Type window lets you select the type of session; full copy or incremental
copy.

Select Source LUN / Volume
The Select Storage Sources window lets you select the source storage from which you want to
copy data. If the Session is an Incremental Session, only a CLARiiON may be a Source storage
system.
If the storage system containing the source LUN/volume runs EMC SnapView or EMC
TimeFinder, SAN Copy can use a snapshot or clone/BCV as its source logical unit, allowing I/O
with the source logical unit to continue during the copy process.
In Storage Source, select a storage system in which the logical units from which you want to
copy data reside.
In Select Storage Source for Move, select the logical units from which you want to copy data.
If you select more than one source logical unit, SAN Copy creates a session for each source
logical unit. If necessary, you can enter the World Wide Name (WWN) of the source logical
unit. Click Next to open the Select Storage Destination for Storage Sources window.

Select Destination LUN / Volume
In the Select Storage Destination for Storage Sources window, right click the icon for a source logical unit, and then
click Select Destination Storage to open the Select Destination Storage dialog box.
This wizard window allows the selection of the destination storage to which the source data will be copied.
y In Storage Destination, select a storage system in which the destination logical units reside.
y Once a storage system is selected, Available Storage lists all logical units in the destination storage systems that
have the same or greater user capacity as the source logical unit.
y From Available Storage, select the logical units that will be used as destination storage, and click the right
arrow to move them into Selected Storage.
y Once the destination logical units have been selected for use, click OK to close the Select Destination Storage
dialog box and return to the wizard.
With both the source storage and destination storage selected, click the Verify Connections checkbox and click
Next.
If the destination and source Storage Processor ports can not communicate, an error will be displayed. If they can
communicate, a message box will be displayed. Click OK to proceed to the Session Name screen.
The initial steps for creating a full copy session from CLARiiON to Symmetrix are similar to those seen in the
CLARiiON to CLARiiON session, and are not shown here. The first difference appears when destination storage
must be selected.
With the Navisphere Agent from the Symmetrix host system added to a portal, Navisphere Manager is able to view
the volumes the Symmetrix is presenting to that host system. These volumes may be used in a SAN Copy session.
The actual data flow between the CLARiiON LUNs and Symmetrix volumes during a SAN Copy session will pass
directly through the SAN and by-pass the attached host. This is possible because the CLARiiON ports registered as
initiators with the Symmetrix. To select Symmetrix volumes as destinations simply highlight the volumes and click
the Right Arrow button.
Once all the desired destination logical units have been selected for use, click OK to close the Select Destination
Storage dialog box and return to the wizard.

Select Link Bandwidth
The link bandwidth value is entered here. Note that throttling cannot be performed by specifying
a link value lower than that which is actually in use.

Edit Session Name and Throttle Value
Use this Wizard window to edit the name and throttle value for any new session.
The throttle value controls the I/O rate for an active SAN Copy session. You can set the session
throttle to a value between 1 and 10 where 1 is the lowest I/O rate and 10 the is highest. The
default throttle value setting is 6.
A session name can not exceed 64 characters. The default session name is a combination of the
volume name and storage ID.
In the Session Names list, select the session whose properties you want to change.
Click Edit to open the Edit Session dialog box.
Enter a new name and throttle value, and then click Next to open the Summary window.
The Summary window provides a summary of each SAN Copy session that you want to create.
For a CLARiiON to CLARiiON copy session, the Source Storage Info and the Destination
Storage Info should list separate CLARiiON storage systems. Ownership of both of the
involved LUNs is not restricted to both being SPA or SPB. As long as the SP ports are zoned to
each other and the source port has registered with the destination storage system database as an
initiator, communication should be possible.
If you want to change any of the session information, click Back until you reach the wizard
window that lets you can change the session property.
If the session summary is accurate, click Finish to create the sessions.

Session Operations and Status
SAN Copy places an icon for any new sessions in the Storage tree. To view any new sessions,
do the following:
y In the Storage tree, expand the icon for the SAN Copy storage system.
y Expand the SAN Copy Sessions icon, and then the icon for the SP to which the session is
assigned.
Creating a session does not start the session. To start a new session, re-start one that has
completed, or one that has been stopped using the Stop button or due to a fault, do the following:
y In the Storage tree, navigate to the icon for the session you want to start.
y Right-click the icon and then click Start.
SAN Copy asks you to confirm the start of the session, and when you click OK, the copy session
begins.
It is also possible to pause a session either directly from the pop-up menu (as here) or from the
status screen. With the status screen open, clicking on Pause will cause the session to pause.
Confirmation and Success boxes will be displayed and the session will be paused.
The status dialog shows the current status of the Session, and allows management operations.
This Session has completed; if it was partially complete, the Stop and Pause buttons would be
active. Once paused, with the session status window open, clicking Resume will allow the
session to complete. Again, Navisphere displays Confirmation and Success boxes.

Lesson 3: Managing SAN Copy with Navisphere

Secure CLI
y Configure SAN Copy objects with Navisphere Secure CLI
y Manage SAN Copy objects with Navisphere Secure CLI
Many commands are common to SAN Copy in Full Copy Mode and Incremental SAN Copy.
Commands that are unique to one or the other will be called out.

Managing SAN Copy with Secure CLI (1)

y Command syntax
– naviseccli [-h | -address] <SP> sancopy <command> <option> …
y -create
– Create a new Session
y -destinfo
– Display information about destination LUNs for an active Session
y -duplicate
– Make a copy of a Session (copy descriptor)
y -info
– Display information about copy descriptors
Note that the Secure CLI examples assume that a security file has already been created;
username, password and scope are not specified on the command line.
The commands perform the same function as their GUI equivalents.
The create command is lengthy, with a number of switches. A Session name must be specified,
along with information about source and Destination LUNs, and whether this is an incremental
Session. Other options allow the Session to be started, and specify whether an initial full copy is
required.
The info and destinfo commands display status information; info shows full information about a
Session, including Source and Destination LUNs, while destinfo shows status information about
Destination LUNs. The –all switch with destinfo will show additional information, such as
whether the Session is incremental or full.
Duplicate allows an identical copy of a full Session to be created. This can then be edited to fit a
particular need.


y -mark
– (ISC only) Mark a Session; starts COFW activity
y -modify
– Modify a copy descriptor
y -pause
– Pause an active Session
y -remove
– Remove (destroy) a Session
y -resume
– Resume a Session – if paused, from the pause point; if stopped or
failed, from the latest checkpoint
The commands match their GUI counterparts exactly. Note that resume starts from the pause
point if the Session was paused, from the most recent checkpoint if the Session was stopped or
failed, and will restart from the beginning if checkpoints have been disabled.
The modify command allows a number of Session parameters to be changed; these include
changing the Session type and name (full Sessions only), and adding or removing destinations.


y -settings
– Change SAN Copy environmental parameters
y -start
– Start a Session
– Options – copywholelun, nomark [new|all]
y -stop
– Stop an active Session
y -throttle
– Change the I/O rate of a Session
The settings command allows changing the global SAN Copy parameters; number and size of
buffers, number of concurrent Sessions allowed per SP, and checkpoint interval.
The start command has options specific to ISC. The copywholelun option starts a Session that
copies the full content of the Source LUN to the destinations. The nomark option, which may be
used with copywholelun, allows the copy to proceed without a mark (the bulk copy option),
either to new destinations only, or to all destinations.
Stop and throttle work in the same manner as their GUI counterparts.


y -transfer
– Transfer a Session to the peer SP
y -unmark
– (ISC only) Unmark a Session; stops COFW activity
y -updateconnections
– Updates connection and registration information
y -verify
– Verifies that SAN Copy can access a LUN/volume
Transferring a Session is a manual process; Sessions do not trespass. Note that the update
connections and verify commands perform the same function as the GUI menu option and
dialog checkbox, respectively.

Lesson 4: Using admhost with SAN Copy

y Use admhost to perform SAN Copy host operations
The objectives for this lesson are shown here. Please take a moment to review them.

admhost Commands (Windows only)

y admhost lun_activate
– Can assign drive letters
– Re-discovers deactivated LUNs
y admhost lun_deactivate
– Flushes host buffers, then makes LUN invisible to OS
y admhost lun_flush
– Flushes host buffers
y admhost lun_list
– Displays mapping information
The admhost utility is an executable program that you can run interactively or via script. It runs
on the following Microsoft® Windows platforms: Windows NT®, and Windows® 2000/2003.
The admhost commands can activate and deactivate a copy logical unit, flush data from
operating system buffers to ensure that the source logical unit is current, and list logical unit
mapping information on the host.
The admhost commands perform several functions in SAN Copy sessions. The commands and
functions are:
y admhost lun_activate which can be used to assigns drive letters (NT/2K/2K3 only) and re-
discover deactivated LUNs.
y admhost lun_deactivate which can be used to flush data from host buffers to maintain LUN
currency and then make the LUN invisible to the host.
y admhost lun_flush which can be used to which can be used to flush data from host buffers to
maintain LUN currency.
y admhost lun_list which can be used to query the storage systems and display current LUN to
drive letter mapping. This can be especially useful when the Navisphere agent is not present;
the agent would otherwise inform Navisphere of the mapping

admhost lun_activate
admhost lun_activate [-l lun-worldwidename –d drive-letter]
Examples:
admhost lun_activate
Scanning for new devices.
Completed scanning for new devices.
admhost lun_activate -l
60:06:01:EF:74:60:00:00:CD:BD:FE:45:77:9D:D6:11 -d v:
Scanning for new devices.
Successfully assigned v: to CLARiiON LUN
60:06:01:EF:74:60:00:00:CD:BD:FE:45:77:9D:D6:11
Completed scanning for new devices.
On a Windows host, the admhost lun_activate command tells the operating system to scan for
new copy LUNs and to mount each one (make it available to Windows). The software assigns a
drive letter to every new device it finds. Use admhost lun_activate on the hosts connected to
both the source and destination LUNs after a copy completes to make the LUN available/visible
to the hosts. If you omit switches, lun_activate simply scans for new devices and assigns drive
letters to any new LUNs that have a proper file system type on them. The software assigns the
drive letters according to the next available drive letter on Windows.

admhost lun_deactivate
admhost lun_deactivate –o drive-letter
Example:
admhost lun_deactivate -o F:
Deactivated the device on F:
On a Windows host, lun_deactivate flushes all host buffers, unmounts the LUN, and removes
the drive letter assigned by lun_activate. It essentially dismounts a mounted LUN. With
Windows, use lun_deactivate (or flush) command on the host that holds the destination LUN
before starting a copy session.

admhost lun_flush
admhost lun_flush –o [[-d drive-letter] | physicaldriven]
Examples:
admhost lun_flush -o F:
Flushed F:.
admhost lun_flush -o \\.\PhysicalDrive1

Flushed PhysicalDrive1.
On a Windows host, the admhost flush command flushes all data and clears all buffers.
However, unlike lun_deactivate, it does not remove the drive letter, and allows reads from the
LUN to continue. Use flush or lun_deactivate for a source LUN before starting a SAN Copy
session to ensure that all cached data has been written to disk.

admhost lun_list
admhost lun_list [-l lun-worldwide-name] | [-d [drive-letter] | [

physicaldriven]] [-a [driveletter] | [physicaldrive]]
Examples:
admhost lun_list or admhost lun_list -a driveletter
F: => 60:06:01:EF:74:60:00:00:A2:0D:40:24:C2:B5:D6:11
H: => 60:06:01:EF:74:60:00:00:CD:BD:FE:45:77:9D:D6:11
admhost lun_list -a driveletter -d F:
F: => 60:06:01:EF:74:60:00:00:A2:0D:40:24:C2:B5:D6:11
admhost lun_list -a physicaldrive
\\.\PhysicalDrive1 => 60:06:01:EF:74:60:00:00:A2:0D:40:24:C2:B5:D6:11
\\.\PhysicalDrive2 => 60:06:01:EF:74:60:00:00:CD:BD:FE:45:77:9D:D6:11
On a Windows host, lun_list displays the mapping information of the host devices such as drive
letters or physical drives and their corresponding LUN worldwide names (WWNs).
You can use lun_list with the -l switch to display the current drive letter mapped to the specified
LUN WWN or use the -d switch to display the LUN WWN mapped to the specified drive.
Using lun_list and lun_activate in sequence, you can obtain the lun wwn info and change the
drive letter currently mapped to the desired drive with lun_activate.

admhost Usage (Windows)

y Follow these steps for full SAN Copy sessions
– Quiesce Source LUN writes
– admhost lun_deactivate –o <destination drive letter>
¾ On host(s) which has Destination(s) mounted, if any
– admhost lun_flush –o <source drive letter>
¾ On host which has Source LUN mounted
¾ Can lun_deactivate instead, if no need for read-only access
– Start Copy Session
– Wait for copy to complete
– admhost lun_activate
¾ On all hosts mounting Source or Destination(s)
To avoid conflicts with access to the destination LUN or volume, the admhost lun_deactivate command should be
issued against the destination LUN. This will flush all data from the host using the destination and take it off line.
The destination LUN is then exclusively available to the Source LUN as a destination. This step should be
performed for full SAN Copy sessions as well as Incremental SAN Copy sessions. Note that the lun_deactivate
command performs the same function as removing the drive letter from the Windows Disk Management console; it
is easier to script, and thus more readily used.
For full SAN Copy sessions, but not for Incremental SAN Copy sessions, the following is true:
When copying the data from the source to the destination, it is essential that the state of that data be known. The
Source LUN should be quiesced and an admhost lun_flush command issued against it. This will force the host
attached to the Source LUN to commit all buffers to the LUN.
The session can now be started and data flow will take place. While the session is active, the source LUN will be
put into read-only mode. If write access is required during the SAN Copy session, a Snapshot or Clone should be
created of the source LUN and the Snapshot or Clone used as the SAN Copy source.
After the completion of the SAN Copy session, the admhost lun_activate command should be issued against both
the source and destination LUNs to bring them back on-line
Note again that the foregoing applies to full SAN Copy sessions only – Incremental SAN Copy uses a Reserved
Snapshot as the source for all data copying activity, and does not require that the Source LUN be taken offline, or
even that the buffers be flushed. The advantage Incremental SAN Copy offers, therefore, is that host access to the
Production LUN is not impacted during the session.

Unix Buffer Management with Native Commands

y Follow these steps for full SAN Copy sessions
– Quiesce Source LUN writes
– Unmount destination device(s)
¾ On host(s) which has Destination(s) mounted, if any
– Flush source device
¾ On host which has Source mounted
¾ Can (unmount, mount) if flush unsupported
¾ Can unmount instead, if no need for read-only access
– Start Copy Session
– Wait for copy to complete
– Mount Source and Destination(s)
UNIX hosts present the same risks as Windows hosts with regard to data corruption. However,
the commands needed by a UNIX host to manage the host buffers are built into the operating
system. You may use the unmount and mount commands to achieve the same effects as the
admhost commands used on the Windows hosts.
Note again that the foregoing, as with Windows hosts, applies to full SAN Copy sessions only.
Incremental SAN Copy uses a Reserved Snapshot as the source for all data copying activity, and
does not require that the Source LUN be taken offline, or even that the buffers be flushed. The
advantage which Incremental SAN Copy offers, therefore, is that host access to the Production
LUN is not impacted during the session.

LAB
EXERCISES:
y San Copy
y Incremental San Copy
Lab Exercise

Module Summary
Key points covered in this module:
y Configuration and management of SAN Copy with
Navisphere Manager
y Configuration and management of SAN Copy with
Navisphere Secure CLI
y Using admhost in conjunction with SAN Copy
These are the key points covered in this module. Please take a moment to review them.

Module 2: MirrorView/A and MirrorView/S

Upon completion of this module, you will be able to:
y Describe MirrorView/S and MirrorView/A connectivity options
y Explain the operation of the MirrorView/S Fracture Log
y Explain the operation of the MirrorView/S Write Intent Log
y Explain how MirrorView/S and MirrorView/A make remote copies of
LUNs
y List the required steps in MirrorView/S and MirrorView/A
administration
y Describe how MirrorView/S, or MirrorView/A, and SnapView can be
used together
y Describe Consistency Group functionality
© 2009 EMC Corporation. All rights reserved. Module 2: MirrorView/A and MirrorView/S - 1
The objectives for this module are shown here. Please take a moment to read them.
Module 2: MirrorView/A and MirrorView/S - 1

Lesson 1: MirrorView/S and MirrorView/A Features

y Explain the features of MirrorView/S and MirrorView/A
y Discuss the requirements for using MirrorView/S and
MirrorView/A in a CLARiiON environment
y Remote Replication Enhancements

MirrorView/S and MirrorView/A Overview (1)

y Optional storage system-based software
y 1 or 2 Remote Mirror(s) for disaster recovery
– 1 or 2 remote images for MirrorView/S
– 1 remote image only for MirrorView/A
– Snapshot(s) or Clones of mirrored data accessible at remote site
y Mirror topology (connecting primary storage system to

secondary storage systems)
– Uses specific SP ports - may be shared with host traffic
– Direct connect and switched FC topology supported
– iSCSI connectivity supported on CX3-series ‘c’ systems, CX4-series
– WAN connectivity supported using specialized hardware
MirrorView/S and MirrorView/A are optional software supported on the CX4 series
CLARiiON, as well as many previous models.
The design goal of MirrorView/S is to allow speedy recovery from a disaster with a low
Recovery Point Objective (RPO) as well as a Recovery Time Objective (RTO). To accomplish
this, MirrorView/S uses synchronous mirroring, and does not allow direct host access to
secondary images. There may be one or two secondary images per mirror.
MirrorView/A has a similar design goal, but allows lower cost, and longer distance connectivity
options in environments where some data loss is acceptable. It uses an asynchronous interval-
based update mechanism to accomplish this.
Supported connection topologies include direct connect, SAN connect, and WAN connect, when
appropriate FC/IP devices are used, as well as iSCSI where the SPs have the port type.

MirrorView/S and MirrorView/A Overview (2)

y Synchronous mirrors (MirrorView/S)
– Secondary in-sync with primary during normal operation
y Asynchronous mirrors (MirrorView/A)

– Secondary updated periodically - asynchronously
– User-defined update interval (in minutes)
– Golden copy protection for secondary image
¾ Snapshot started before update starts
– Delta Set technology tracks updates
MirrorView/S uses synchronous updates, and the secondary is therefore identical to the primary
during normal operation. Bear in mind that a primary can lose communication with the
secondary, at which point the secondary is unreachable, and cannot be updated, a state known as
the fractured state. In this case, a tracking mechanism logs areas of disk where there may be
differences between the primary and secondary images (see the Fracture Log discussion).
MirrorView/A, because of its asynchronous nature, seldom has the data on the secondary image
identical to that on the primary image. There is also a requirement to track differences, so that
they may be shipped to the secondary image at regular intervals. Internally, the SAN Copy delta
set mechanism is used to track changes to the primary image, and to ship those changes to the
secondary image as required. Before the updates are shipped, a protective snapshot of the
secondary ensures that, in the event of a failure, the data state may revert to a previous known
good state.

MirrorView/S and MirrorView/A Configuration
Site A Site B
Production Host Standby Host
IP or FC SAN
(or WAN with FC/IP hardware)
Production Mirror
A A
Production
Mirror B B
Primary system Secondary system
Note the definitions below:

Primary storage system
y CLARiiON that serves mirrored primary data to a production host
Secondary storage system
y CLARiiON that contains a mirrored secondary image of primary storage system data
y Secondary storage systems are typically connected to standby hosts
Bidirectional mirroring
y A Secondary storage system can also be a Primary storage system for another mirror
Note that the terms ‘primary storage system’ and ‘secondary storage system’ are relative to each
mirror. Because MirrorView/S and MirrorView/A support bidirectional mirroring, a storage
system which hosts primary images for one or more mirrors may also host secondary images for
one or more other mirrors.

MirrorView/S Fracture Log and Write Intent Log

y Fracture Log
– Resident in SP memory, hence volatile
– Tracks changed regions on Primary LUN when Secondary is unreachable
– When Secondary becomes reachable, Fracture Log is used to
resynchronize data incrementally
– Fracture Log is not persistent if Write Intent Log is not used
y Write Intent Log (WIL)
– Persistently stored - uses private LUNs
– Optional in CX3 R26 and below– allocated per mirror Primary LUN
– Enabled by default in CX4 R28 on mirror creation, all mirrors are now
allowed to use the WIL
¾ No option in GUI to disable the WIL
¾ Need to use the CLI “–nowriteintentlog” option with mirror creation to create a
WIL-less mirror
– Used to minimize recovery in the event of failure on Primary storage system
– Two LUNs of at least 128 MB each (strictly 250,000 blocks or more)
This functionality is MirrorView/S-specific; MirrorView/A neither needs nor implements the logging
mechanism described here.
In normal operation, data is committed to the secondary image as part of the I/O processing before the
system acknowledges the write back to the host. However, if a secondary LUN is unreachable, then
MirrorView/S marks the secondary image as “fractured” and records the write on the primary LUN in a
fracture log. The fracture log tracks regions as they change on the primary LUN for as long as the
secondary LUN is unreachable. When the secondary LUN returns to service, the secondary image must
be synchronized with the primary. Synchronization is the process of committing data from the primary
LUN to the secondary LUN, as recorded in the fracture log. When synchronization finishes, the data on
both primary and secondary LUNs is consistent.
The use of a fracture log avoids the need for a full copy of the entire primary image, resulting in
substantial time savings. I/O from the host continues during synchronization, so the host experiences no
difference in running operations, apart from a possible degradation in performance. A tunable parameter
is available to lessen this performance impact if it is unacceptable.
Enhancements in FLARE R26 lessened the impact of using the WIL; its use is now recommended for as
many mirrors as will support it in the storage system. With the release of the CX4 array and FLARE R28
it is now enabled by default on mirror creation. Another change is that all mirrors are now allowed to use
the WIL, instead of just half the mirror limit as with previous versions. There is no option in the GUI to
disable this, one must use the “–nowriteintentlog” option with mirror creation to create a WIL-less mirror.

Synchronization and the Fractured State

y Mirror Synchronization
– Mechanism to copy data from Primary LUN to a Secondary LUN
– After mirror synchronization, Primary LUN (or previous point in time
copy) and Secondary LUN are identical
– Mechanism may use Fracture Log or Write Intent Log to avoid full
LUN data copy (MirrorView/S)
– May use SnapView and SAN Copy internally to perform an
incremental update (MirrorView/A)
y MirrorView Fractured state

– Condition when a Secondary Image is unreachable by the Primary
Image
– Fracture can be invoked by administrative command
Synchronization is the process used to ensure that secondary images are rapidly made identical
with primary images (or, in the case of MirrorView/A, with point in time copies of primary
images) after initial creation of the mirror, or after the secondary becomes reachable after
having been fractured. The fractured condition is one in which the secondary image is not
reachable from the primary image, either because of a failure in the environment or because of
administrative action.
MirrorView/A performs incremental synchronization operations at intervals prescribed by the
user, configured when the mirror is created.

Ports and SP Definitions

y HBA Ports
– Remote Mirror connections go from the specified port on each local
SP to the specified port on the corresponding remote SP
y Controlling SP
– SP that owns Primary Image or Secondary Image
– Controlling Primary SP communicates with controlling Secondary SP
y Secondary SP
– Peer SP to the controlling SP for Primary or Secondary Image
– Used if the controlling SP is unreachable/unavailable
MirrorView/S and MirrorView/A use dedicated ports on supported storage systems - the specific
port used on each SP depends on the CLARiiON model, and whether FC or iSCSI is being used
for replication. The MirrorView port may be shared with host I/O (though this may be
undesirable in some environments), but may not be shared with SAN Copy.

Mirror Availability
y Mirror Availability States
– Inactive - no host I/O allowed
– Active - host I/O allowed (normal state)
– Attention - administrative action required. Host I/O allowed
y Heartbeat
– Messages used to determine when a Secondary storage system
becomes reachable after it was determined unreachable
The three mirror states are inactive, active and attention. These states vary in the ways that they
respond to read and write requests from a host. Transitions between the states is either automatic
or by administrative control.
Note that while a mirror is in any state, normal administrative operations can occur, such as
adding or deleting a secondary image.
y Inactive – The default state for a newly created mirror. An inactive mirror rejects all host
data access. This restriction ensures an orderly transition for such operations as the
destruction of the mirror.
y Active – The normal state for a mirror in operation. Allows full read and write host access.
y Attention – The state that indicates a problem exists somewhere in the mirror and is
preventing a transition to the active state. For example, a mirror is placed in this state if the
number of secondary images falls below an administrator-defined minimum value. A mirror
in attention state is flagged as faulted in Manager, but still allows all host data access.
If a Secondary Image is fractured, the primary storage system uses a heartbeat every 10 seconds
to determine when the secondary becomes reachable again. This may be compared to a ‘ping’ in
the networking environment.

Mirror Data States

y Mirror Data States
– Synchronized - Primary LUN and Secondary LUN contain identical
data
– Consistent - Write Intent Log or Fracture Log may be needed to
return Secondary to the in-sync state
– Synchronizing - mirror sync operation in progress
– Out of sync - full sync needed
– Rolling back (MirrorView/A only) – the secondary image is being
rolled back (via SnapView) to a previous known good state
y Image condition
– Along with an image state, an image will have an image condition
that provides more information.
¾ Normal - The normal processing state
¾ Admin Fractured - Administrator has fractured the mirror, or a media
failure has occurred. An administrator must initiate a synchronization.
The five image, or data states are: synchronized, consistent, synchronizing, out-of-sync and rolling back. These
states represent the relationships between the primary image and a secondary image.
y Synchronized – The state in which a secondary image is currently an exact byte-for-byte duplicate of the
primary image. It implies that there are no outstanding write requests from a host that have not committed to
stable storage on both the primary and secondary images. Transition from this state can occur to the consistent
state.
y Consistent – The state in which a secondary image is a byte-for-byte duplicate of the primary image either now
or at some point in the past. Transition from this state can occur to either the synchronizing state or the in-sync
state.
y Synchronizing – The state in which a secondary image is being updated from the primary image. This state can
be a full byte-for-byte copy of the data or a partial copy based on either a fracture log or write-intent log.
Transition from this state can occur to the out-of-sync or consistent states.
y Out-of-sync – The state in which the data on a secondary image has no known relationship with the data on a
primary image. This is the case when you add a secondary image to a pre-existing mirror. Transition from this
state can occur to the synchronizing state.
y Rolling back (MirrorView/A only) – the protective SnapView Session on the secondary image is rolling back
to return the secondary image to a known good, consistent, state.
Along with an image state, an image will have an image condition that provides more information.
y Normal – The normal processing state
y Admin Fractured – The administrator has fractured the mirror, or a media failure (such as a failed sector or a
bad block) has occurred. An administrator must initiate a synchronization.
y System Fractured – This occurs when the system fractures the mirrors. For example, if the storage system
containing the secondary image fails, the secondary image is system fractured. Similarly, if the link between
the primary and secondary storage system fails, the secondary image is also system fractured. In either event,
once the issue has been resolved and the secondary storage system is back in communication with the primary
storage system, the secondary image is automatically resynchronized if “auto recovery” policy is enabled.

MirrorView/S and MirrorView/A Configuration

y MirrorView/S and MirrorView/A Setup
– MirrorView/S (and/or MirrorView/A) software must be loaded on both
Primary and Secondary storage systems
– Secondary LUN must be exactly the same size as Primary LUN
– Secondary LUN does not need to be the same RAID type as Primary
– Secondary LUN is not directly accessible to host(s)
¾ Mirror must be removed or Secondary promoted to Primary for host to
have access
– Bi-directional mirroring fully supported
y Management via Navisphere Manager and Secure CLI

– Provides ease of management
– Returns detailed status information
The MirrorView/S (and/or MirrorView/A) software must be loaded on both storage systems,
regardless of whether or not the customer wants to implement bi-directional mirroring.
The secondary LUN must be the same size as the primary LUN, though not necessarily the same
RAID type.
Hosts cannot attach to an active secondary LUN while it is configured as a secondary mirror
image. If you promote the secondary mirror to be the primary mirror image, as seen in a disaster
recovery scenario, or if you remove the secondary LUN, thereby turning it into a FLARE LUN,
then it may be accessed by a host.
A point-in-time copy of the secondary image, either a Snapshot or a Clone, may be made at any
time and be presented to a secondary host.

Resources used by MirrorView/A

y SnapView (on secondary CLARiiON)
– Makes a golden copy of remote image before update starts
y Incremental SAN Copy (on primary CLARiiON)

– Transfers data to secondary image. Uses SnapView as part of ISC
y MirrorView/A license (enabler)

– Licenses MirrorView/A for user
– Licenses SnapView, SAN Copy for system use
y Adequate Reserved LUN Pool space

– Local and remote system
MirrorView/A makes extensive use of other CLARiiON Replication Software for its operation.
SAN Copy, in the form of Incremental SAN Copy, performs the data transfer for MirrorView/A.
It, in turn, makes use of SnapView (on the primary storage system) to track updates to the
Source LUN (primary image), so that they can be copied to the secondary storage system as
scheduled.
SnapView is used on the secondary storage system to make a safety snapshot prior to starting an
update cycle. In this way, if the update data transfer should fail for some reason, and the primary
site fails before the update can be completed, the secondary image can be rolled back to a
(previous) known good state before it is promoted.
When a license for MirrorView/A is installed, the CLARiiON Replication Software which it
uses will automatically be licensed for system (i.e. MirrorView/A) use. If the user wishes to
make use of the functionality of the additional software, it must be separately licensed.
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.

MirrorView Mirror Creation

y Connect storage systems
– Physically, by zoning or creating connection sets
– Logically, by ‘Manage MirrorView Connections’ dialog
y Create Remote Mirror

– Designate a LUN to be a Primary LUN
¾ This is a persistent change to the LUN state
– Specify a mirror name and a mirror type
– Properties for Primary LUN can be specified
– Add secondary image(s)
– Mirror is created in the inactive state, quickly changes to active
MirrorView CLARiiONs must be connected physically, by zoning for FC or creation of

connection sets for iSCSI, and logically, via the GUI or the CLI. Once that task is complete,
other operations will be allowed.
The first of these tasks will be the creation of a remote mirror.

Remote Replication Enhancements - MirrorView

Enhancement Benefits
Provides fine-grained access control of replication
tasks
Replication Roles Roles: Local Replication, Replication, and Replication
Recovery
Roles can have local or global scope
y Increased MirrorView/A limits to max array limit of 256
Replication y New 8 Gb/s and 10 Gb/s I/O Module
Limits
y Increased all Consistency Group counts to 32 for CX4
120/240 and 64 for CX4 480/960
MirrorView/S y Finer tracking granularity reduces amount of data to
Fracture Log be resynchronized
Granularity
y Improves recovery time following a fracture
improvements
In FLARE release 29, a new set of replication roles have been developed to provide the
customer with greater control of CLARiiON array replication. These roles are:
y Local Replication - which provides SnapView operations only (no recovery) a role that
would restrict someone to start/stop SnapView operations
y Replication - which provides SnapView, MirrorView, and SAN Copy operations (no
recovery)
y Replication Recovery - which provides SnapView, MirrorView, and SAN Copy operations
plus recovery
These replication roles can have local or global scope. In order to assign a global scope to a
user, all systems in the Domain must be running FLARE release 29. LDAP role mappings are
also supported. Replication roles can see (but not manage) objects outside of their control. This
new feature facilitates coordination of user access to data and operations. It also introduces a
finer granularity of security.

Security – New Replication Roles: Flare 29 & Higher

y Provides fine-grained access control of
replication tasks:
– Local Replication – SnapView operations only
(no recovery)
– Replication – SnapView, MirrorView, and SAN
Copy operations (no recovery)
– Replication Recovery – SnapView, MirrorView,
and SAN Copy operations plus recovery
y Replication roles can have local or global
scope
– In order to assign a global scope to a user all
systems in the Domain must be running Flare 29
or above.
– LDAP role mapping also supported
y Replication Roles can see (but not manage) Replication Roles
objects outside their control
– Ensures that the view is not restricted
y Facilitates coordination of user access to data
and operations
Three new roles were introduced in FLARE 29 to provide fine-grained access control of
replication tasks:
y Local Replication – SnapView operations only (no recovery)
y Replication – SnapView, MirrorView, and SAN Copy operations (no recovery)
y Replication Recovery – SnapView, MirrorView, and SAN Copy operations plus recovery
Global Replication roles are only supported in a complete FLARE 29 environment, meaning all
arrays in the domain must be at FLARE 29. Global Replication roles (or LDAP mappings
thereof) cannot be created in domains that contain Pre-FLARE 29 systems. You must first
remove all Pre-FLARE systems from the domain. On the same note, Pre-FLARE 29 systems
cannot be added to domains that define global replication accounts. You would have to first
remove all global replication roles and LDAP replication mappings.
Note: All previous security roles are still in effect in Flare 29.

Replication Roles – MirrorView Operations

Local Replication Replication Replication/Recovery
MirrorView
• Synchronize a mirror /
No Yes Yes
consistency group
• Fracture a mirror / consistency
No No Yes
group
• Control the update parameters of
No Yes Yes
an async mirror
• Modify the update frequency of
No Yes Yes
an async mirror
• Throttle a mirror / consistency
No Yes Yes
group
• Promote a sync or async
secondary mirror/consistency No No Yes
group
The chart shown here describes the Replication Roles for MirrorView Operations.

Replication Limits with FLARE 29

MirrorView Increased Replication Limits
CX4-120 CX4-240 CX4-480 CX4-960
R28 R29 R28 R29 R28 R29 R28 R29
MirrorView/A
MirrorView/A Objects 100 256 100 256 100 256 100 256
MV/A Consistency Groups 50 64 50 64 50 64 50 64
MV/A Mirrors per Consistency Group 8 32 8 32 16 64 16 64
MirrorView/S
MV/S Mirrors per Consistency Group 16 32 16 32 32 64 32 64
Replication Limits NOT Increased

CX4‐120 CX4‐240 CX4‐480 CX4‐960
R28 R29 R28 R29 R28 R29 R28 R29
MirrorView/S
MirrorView/S Objects 128 128 256 256 512 512 512 512
Primaries with WIL Enabled 128 128 256 256 512 512 512 512
MV/S Consistency Groups 64 64 64 64 64 64 64 64
Shown here at the top of the slide is a list of replication limits that have increased for
CLARiiON FLARE 29. The MirrorView/A limits increased to max array limit of 256 Async
mirrors. SnapView snapshot limits doubled in release 29. All Consistency Group member counts
increased to 32/64, respectively. Consistency groups, which helps with both crash consistency at
the array level, and also application consistency when using Replication Manager (Replication
Manager leverages array consistency groups).
The bottom of the slide shows the replication limits that did not increase.

8 Gb/s FC and 10 Gb/s iSCSI I/O Module – MirrorView
y Supports new 8 Gb/s FC and 10 Gb/s iSCSI

y In new arrays, MirrorView port will be highest-numbered logical port
– MirrorView port displayed in Navisphere
– SAN Copy can use all non-MirrorView ports
y For existing arrays, new I/O modules can replace older I/O modules
– Example: change from 1Gbit port currently used by MirrorView, to new 10 Gb/s
y Replication between faster ports and slower ports supported
– For 10 Gb/s iSCSI > 1 Gb iSCSI, requires switch to bridge between speeds
4 Gb/s FC SAN 4 Gb/s FC SAN 8 Gb/s
IP SAN IP SAN
1 Gb/s 1 Gb/s 10 Gb/s
10 Gb/s Ethernet and 8 Gb/s Fibre Channel respectively delivers significantly greater bandwidth
than that of 1 Gb/s Ethernet and 2 times the bandwidth of today’s 4 Gb/s Fibre Channel
deployments. MirrorView ports can leverage the greater bandwidth.
The nature of the I/O (sequential vs. random) and (large vs. small block) will affect how much
IOPS processing increases can be achieved. Replication Products such as MirrorView can
leverage the increased bandwidth for greater IOPS processing speed. For example since
MirrorView/A is more sequential it will have a greater benefit, because mirror updates and the
time for full a sync and re-sync will take much less time.
Note: MirrorView ports are set in FLARE when the array is initialized and cannot be changed
with out destroying the configuration.

Virtual Provisioning & MirrorView: Planning and

Design FLARE Release 29
y Thin LUNs and pre-R29 LUNs are NOT allowed to co-
exist in any mirror relationship
y Primary and secondary images can be created on Thin
LUNs
y All combinations of Thin and Traditional LUNs are
allowed
y MV/S has checks added to consider the pool space
available to the secondary
– Initial sync option should be set
¾ MV/S checks are not a guarantee that the synchronization will complete
¾ MV/A does NOT have any checks to consider the Thin Pool space
In CLARiiON FLARE Release 29, support for Virtual Provisioning with MirrorView enables
remote replication protection of virtually provisioned LUNs, reducing customer’s TCO. Thin
LUN to thin LUN replication makes efficient use of remote replication resources. However, you
can replicate a traditional LUN and a thin LUN and the replica can become fully provisioned
after a full sync. If you just promote a secondary thin LUN (without a sync) that was in a
MirrorView relationship with a traditional LUN the LUN stays “thin”. You can replicate a thin
LUN to a traditional LUN and the non-provisioned spaces in the thin LUN will be zero filled. In
effect, negating any space saving advantages of thin LUNs.
As a best practice, the MirrorView combination of Thin LUNs (primary and secondary) work
best and have predictable results when synchronizing, re-synchronizing, or promoting. When
combining Thin and Traditional LUNs in a MirrorView set you may get undesirable results. In
the 1st scenario, with FLARE release 29 committed on both sides, if you have a Thin LUN
primary and a Traditional LUN secondary and promote the secondary. The Thin LUNs
unallocated areas are then “zero filled”, and any space gain from being thin is lost. 2nd scenario,
if FLARE 29 is not committed on the secondary side then no MirrorView relationship can exist
between Thin LUNs and pre-release 29 LUNs.
To avoid a “pre-release condition” FLARE 29 must be installed and committed on all arrays
participating in MirrorView relationships.

Virtual Provisioning & MirrorView: Checks

y When adding a secondary Thin LUN or synchronizing existing
mirrors, MAKE SURE that the Thin Pool has enough capacity for the
synchronization to complete
– If no space exists to write new data, a “Media Failure” administrative
Fracture results
y MV/S has checks added to consider the pool space available to the
secondary
– Before adding a secondary image to a mirror
¾ Initial sync option should be set
– Before starting a synchronization on an existing mirror
y MV/S checks are not a guarantee that the synchronization will
complete.
– Space can still be exhausted due to new mirrored writes while syncing
y MV/A does NOT have any checks to consider the Thin Pool space.
– A failed update due to out of space conditions will be treated like a failed
write on the secondary causing an admin fracture to the mirror
Virtual Provisioning and MirrorView considerations are shown here. Please take a moment to
review them.

VP MirrorView Replication – Implementation

MirrorView/S Valid LUN Type Combinations
Primary Secondary 1 Secondary 2

Scenario 1 Thin R29 Thin or R29 Traditional R29 Thin or R29 Traditional
Scenario 2 R29 Traditional R29 Thin or R29 Traditional R29 Thin or R29 Traditional
Scenario 3 R29 Traditional Traditional (R29 or Pre-R29) Traditional (R29 or Pre-R29)
Scenario 4 Pre-R29 Traditional Traditional (R29 or Pre-R29) Traditional (R29 or Pre-R29)
MirrorView/A Valid LUN Type Combinations
Primary Secondary
Scenario1 Thin R29 Thin or R29 Traditional
Scenario2 R29 Traditional R29 Thin or R29 Traditional
Scenario3 R29 Traditional Traditional (R29 or Pre-R29)
Scenario4 Pre-R29 Traditional Traditional (R29 or Pre-R29)
Listed are the valid combinations for MirrorView replication with virtual provisioning in release
29. These combinations are enforced by FLARE. When adding a secondary thin LUN (or
synchronizing existing mirrors), confirm that Thin Pool has enough capacity for the
synchronization to complete. If there is not enough space to write new data, a “Media Failure”
administrative fracture results.

Flare 29 and MirrorView/S Improved Granularity

y Finer tracking granularity reduces amount of data to be
resynchronized
– Enabled by reducing the amount of data each bit in the Fracture Log
(bitmap) represents
– Fracture Log tracking granularity is reduced by a factor of eight
y Improves recovery time following a fracture

– Reducing amount of data tracked for resync enables completing
resync more quickly
– Faster resync reduces amount of time required to restore DR
protection
y No user operations required for change

– Fracture Log size increased automatically
– Write Intent Log not changed
– One 128 MB LUN per SP

Lesson 2: MirrorView Consistency Groups

y Explain the features of MirrorView Consistency Groups
y Discuss the requirements for using MirrorView
Consistency Groups

Consistency Groups
y Group of secondary images treated as a unit
y CG group limits depend upon CLARiiON code & model
– Up to 64 groups per CX4
– Up to 64 mirrors per group
y Primary image LUNs must all be on the same CLARiiON

y Secondary image LUNs must all be on the same
CLARiiON
y Operations happen on all mirrors at the same time
y Ensure a restartable set of LUNs
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, i.e. all
made at the same point in time. As a result, the remote images are always restartable copies of the local
images, though they may contain data which is not as new as that on the primary images.
It is a requirement that all the local images of a Consistency Group be on the same CLARiiON, and that
all the remote images for a Consistency Group be on the same remote CLARiiON. All information related
to the Consistency Group will be sent to the remote CLARiiON from the local CLARiiON.
Only one remote image is allowed for any mirror in a Consistency Group. The operations which can be
performed on a Consistency Group match those which may be performed on a single mirror, and will
affect all mirrors in the Consistency Group. If, for some reason, an operation cannot be performed on one
or more mirrors in the Consistency Group, then that operation will fail, and the images will be unchanged.
For the CX3 series systems, Consistency Groups are available for MirrorView/A and MirrorView/S, and
the limits for each, 16 groups are independent of each other.
For the CX4 series systems, the max number of Consistency Groups per storage system is 64. Managing a
Consistency Group is simple – create and name the group, specify synchronous or asynchronous
mirroring, and add member mirrors. A Consistency Group of the same name is automatically created on
the secondary CLARiiON, and the Secondary Images are added to it as members.
Note: MirrorView/A source limits are shared with SAN Copy incremental-session and SnapView
snapshot source limits. Please see the MirrorView Release Notes for the latest limits.

Consistency Group Status (1)

y Synchronized
– All the secondary images are in the Synchronized state
y Consistent
– All the secondary images are either in the Synchronized or
Consistent state (at least one is in the Consistent state)
y Quasi-Consistent (MV/A only)

– A new member that is not consistent with existing members is added
to the Consistency Group, which automatically starts an update.
After the update completes, the Consistency Group is again
Consistent
The Synchronized and Consistent states are similar to states of the same name, applied to
individual mirrors. Synchronized means all the secondary images are in the Synchronized state.
Consistent means all the secondary images are either in the Synchronized or Consistent state,
and at least one is in the Consistent state.
The Quasi-Consistent state is unique to Consistency Groups; the Group is partially consistent,
meaning that at least one member is consistent, and at least one member is not consistent. All
member mirrors will be consistent after the next update. In a Quasi-Consistent status, a new
member that is not consistent with existing members is added to the consistency group, which
automatically starts an update. After the update completes, the consistency group is again
consistent.


y Synchronizing
– At least one mirror in the group is in the Synchronizing state, and no
member is in the Out-of-Sync state
y Out-of-Sync
– At least one member of the group is Out-of-Sync
y Scrambled
– There is a mixture of Primary and Secondary Images in the
Consistency Group (usually after a failed promotion attempt)
y Incomplete
– Some, but not all, of the secondary images are missing, or mirrors
are missing. This is usually due to a failure during group promotion.
The group may also be scrambled
The Synchronizing status means that at least one mirror in the group is in the Synchronizing
state, and no member is in the Out-of-Sync state.
The Out-of-Sync status shows that the group may be fractured, waiting for synchronization
(either automatic or via the administrator), or in the synchronization queue. Administrative
action may be required to return the consistency group to having a recoverable secondary group.
The Scrambled and Incomplete statuses for Consistency Groups are both indications that errors
have occurred. Recovery may involve the removal of group members, the recreation of
secondary images, and a full synchronization.
The Scrambled status means there is a mixture of primary and secondary images in the
consistency group. During a promote, it is common for the group to be in the scrambled state.
While the Incomplete status means that some, but not all of the secondary images are missing,
or mirrors are missing. This is usually due to a failure during group promotion. The group may
also be scrambled.


y Rolling Back (MV/A only)
– The group is in this state if one or more members had an unfinished
update when the group was promoted. The group remains in this
state until all members of the group complete their respective
rollback operations
y Local Only
– The Consistency Group contains only primary images. No mirrors in
the group have a secondary image
y Empty
– The Consistency Group has no members
The Rolling Back state applies to a secondary group promoted after a failed update. The
sequence is illustrated in the next slide sequence. In the Rolling Back status, a successful
promotion occurred where there was an unfinished update to the group. This state persists until
the Rollback operation completes.
With the Local Only status the consistency group contains only primary images. No mirrors in
the group have a secondary image.
Finally, the Empty status simply means that the consistency group has no members.

Lesson 3: Managing MirrorView with Navisphere Manager

y Configure and manage MirrorView/S with Navisphere
Manager
y Configure and manage MirrorView/A with Navisphere
Manager
y Configure and manage MirrorView Consistency Groups
The procedures for managing MirrorView/S and MirrorView/A are identical in many cases and
very similar in most other cases. This lesson covers the management of both products.

Manage Mirror Connections
Managing MirrorView connections is started by right-clicking the storage system, then choosing
MirrorView > Manage Mirror Connections...
The dialog allows up to 4 remote CLARiiONs to be connected to the one currently being
managed.
Once that logical connection is in place (and it cannot be created if the physical connection,
usually via zoning, is not already in place), the storage system may participate in a mirrored
relationship. The status Enabled indicates that connections have been made for both SPA and
SPB. Other status values show that partial connections have been made; SPA may be connected
to its remote peer, but SPB not, for example. The environment should be checked to determine
why all connections are not in place.

Allocate the Write Intent Log (MirrorView/S only)
To allocate the Write Intent Log, right-click the storage system and select MirrorView.
Click Allocate Write Intent Log. Note that only LUNs which are >= 128 MB (0.125 GB) are
displayed.
The Allocate Write Intent Log dialog box allows the selection of 2 LUNs of at least 128 MB
each. One will be allocated to SPA, and the other to SPB. Both become Private LUNs, as seen
above.
Important Note: In the latest release of FLARE when creating a MirrorView/S mirror, the
Write Intent Log in selected by default.

Create Remote Mirror
After MirrorView Connections have been made, the user may create a remote mirror. This procedure is the same
for MirrorView/A as for MirrorView/S, and turns a FLARE LUN into a primary image for a mirror. The creation
of a Remote Mirror starts by right-clicking the storage system, or a LUN, then choosing MirrorView > Create
Remote Mirror…
This dialog allows selection of the mirror type (synchronous or asynchronous), primary LUN, and some mirror
configuration items. The mirror name is assigned here, a choice made as to whether or not the WIL will be used,
(note this selected by default with latest release) and other configuration parameters are set up. Note that the
minimum number of required images does not in any way affect whether or not I/O is allowed to the primary
image.
The dialog which appears allows the user to select which LUN should be used for the primary image, name the new
remote mirror, and choose the required number of secondary images.
Note that if all the prerequisites are met, Asynchronous mirrors are the default mirror type. Prerequisites include:
y CLARiiON must be a CX-series storage system
y MirrorView/A must be licensed
y There must be space in the Reserved LUN Pool
If the Asynchronous mirror type is selected, the ‘Use Write Intent Log’ and ‘Quiesce Threshold’ checkboxes are
not present.
Once the remote mirror is created, it appears under the Remote Mirrors container. The mirror is in the Attention
state because there is no secondary image. Note that the new mirror is called out as a Sync mirror.
Once the user selections have been made, the Remote Mirror is created and displayed in the GUI. Note that the
mirror is marked as being in the Attention state; there is no secondary image at this point. There are, as yet, no
reserved SnapView Snapshots, SnapView Sessions, or reserved SAN Copy Sessions, also because no secondary
image is present.

Add Secondary Image (MirrorView/A)
Adding a secondary image requires a right-click on the mirror, and selection of the Add
Secondary Image… option. Note that other menu choices allow destruction of the mirror, and
the retrieval of mirror properties.
The right-click options shown here are identical to those for a synchronous mirror.
Choose a secondary storage system to host the secondary image, and which LUN will be used.
A secondary storage system will only appear in the list if it meets certain requirements:
y It is a CX, CX3 or CX4-series storage systems
y There is available space in the Reserved LUN Pool
The pane in the middle of the dialog has containers which may be expanded to show the LUNs
underneath them. SPA and SPB containers hold the LUNs owned by those SPs; other containers
will display their subset of the available public LUNs and metaLUNs. The dialog displays the
owning SP of the primary image at the top of the dialog to allow the user to easily choose a
secondary owned by the same SP.
Two of the choices for the secondary image are similar to those for a synchronous mirror - the
recovery policy, and the synchronization rate. The choice not present with synchronous mirrors
is the Update Type. Here the user may select manual updates, a time interval measured from the
start of the last update, or an interval measured from the end of the last update. If an update
cycle runs over its allotted time, then the next cycle will begin immediately after the current
cycle finishes. The defaults settings are shown in the example.

The secondary image has been added, and the mirror automatically starts to synchronize. Note
that the system has automatically created a Reserved SnapView Snapshot, a Reserved SnapView
Session, and a Reserved SAN Copy Session for the mirror, and the names of those objects
reflect the fact that they are used for MirrorView/A (FAR) and which mirror they are associated
with.
The mirror is shown as being in the transitioning state, and the data state shown as
synchronizing.
The Reserved LUN which is assigned to the Primary Image at this point will not be freed up
until the Remote Mirror is destroyed.
The initial synchronization has finished, and the secondary status has changed to Synchronized.
If the primary image had received updates since the start of synchronization, the secondary state
would be Consistent. Note also that the SnapView reserved objects are not destroyed, and that
the Reserved SAN Copy Session is marked as Completed.

Add Secondary Image (MirrorView/S)
Right-clicking on the mirror allows selection of the Add Secondary Image… option, which
launches the dialog shown on the right of the slide.
Choices made here include the LUN used for the secondary image, how quickly the secondary
synchronizes, and whether recovery from a failure will be automatic or manual.
The dialog shows only LUNs of the correct size in the LUNs pane.
Once the secondary is added, the system automatically starts the synchronization (if ‘Automatic’
was selected by the user). Note that just prior to the start of synchronization, the mirror is
marked as fractured and out of sync, and a red ‘F’ is superimposed on the mirror icon.
When synchronization starts, the mirror is displayed as being in a transitioning state, and the
data state is shown as ‘Synchronizing’.

Mirror Properties and Secondary Image Operations
The example show the properties of both a Synchronous (the left ) and Asynchronous secondary
image (right). The General tab gives basic information about the mirror, including the name and
mirror type.( Not Shown ) The Primary Image tab shows information about the primary image,
its LUN number, and disk type (Not shown).
The Secondary Image tab (there may be 2 for synchronous mirrors) shows the configuration of
the secondary image(s), as well as the synchronization progress, Recovery Policy,
Synchronization Rate, and Update Type for Asynchronous. The screenshot at the lower middle
of the slide shows the operations which may be performed on a Secondary Image. Some of these
choices may not be allowed if the state of the Secondary Image is incorrect.

Create Consistency Group
To create a Consistency Group, right-click the storage system and choose MirrorView > Create Group…
The resulting dialog allows selection of mirror type, a name for the group (required), an optional
description, and which mirrors will be group members.
The advanced parameters, which are configurable here, match those for an individual mirror – Recovery
Policy, Synchronization Rate, and Update Type – and the options are identical to those seen for an
individual mirror. The Consistency Group is displayed in its own container in the GUI, with member
mirrors shown beneath it.
Note that the mirror type (Async/Sync) is displayed, as well as the data state (Synchronized). Operations
which can be performed on the group are:
y fracture
y synchronize
y destroy
y retrieval of properties from the primary storage system
y promote and retrieval of properties from the secondary storage system
The Remote Mirrors container shows individual mirrors with status information. Other displayed
information includes mirror type, and Group (if any) that the mirror is a member of.
The Properties displayed for the Consistency Group include those configured at creation time: name,
synchronization rate, etc. In addition, there is a Force Destroy option, which destroys the group, and, if
the Force Mirror Removal box is checked, do so even if mirrors are still members of the group.

Lesson 4: Managing MirrorView with Navisphere Secure CLI

y Manage MirrorView/S with Navisphere Secure CLI
y Manage MirrorView/A with Navisphere Secure CLI
The commands for managing MirrorView/S and MirrorView/A are identical in many cases, and
very similar in most other cases. This lesson covers the management of both products.

Secure CLI Commands for MirrorView

y Secure CLI
– naviseccli –address <SP> mirror -enablepath <remote SP>
[-connectiontype fibre|iscsi]
– naviseccli –address <SP> mirror -disablepath <remote SP>
[-connectiontype fibre|iscsi]
– naviseccli –address <SP> mirror [-sync|-async] command
– mirror -enablepath SP-hostname [-connectiontype fibre|iscsi]
– Examples:
– naviseccli –address cx1a mirror -enablepath cx2a
– naviseccli –address cx1b mirror –async -list
The structure of the Secure CLI commands is shown here. All examples assume that the
appropriate security files have been created.
Note that the Secure CLI commands are an exact match of the operations that can be performed
from the GUI; in many cases, the command name matches the menu choice.
Before secondary images can be added to mirrors, the physical (cables and zoning or connection
sets) and logical connections must be established between the participating CLARiiONs. The
-enablepath command establishes the logical connection; the -disablepath command removes the
connection.
The –enablepath and –disablepath commands allow the user to specify a connection type; if
none is specified, the CLARiiON tries FC first, then tries iSCSI.

MirrorView Secure CLI Commands (1)

y -info
– Display MirrorView-specific information for the CLARiiON
y -list
– Display information about existing mirrors
y -create
– Create a Remote Mirror (create the Primary Image)
y -destroy
– Destroy a Remote Mirror (remove Primary Image)
y -change
– Change Remote Mirror properties, e.g. description, required images
This first group of commands performs the creation, destruction, modification, and retrieval of
status for Remote Mirrors.
Note that the creation of a mirror involves only choosing a name and specifying a Primary
Image LUN. Most mirror parameters are specified when adding a Secondary Image. Those
initially configured parameters may be altered with the –change command.


y -addimage
– Add a Secondary Image to the Remote Mirror
y -removeimage
– Remove a Secondary Image from the Mirror
y -changeimage
– Change Secondary Image properties e.g. Recovery Policy
y -syncimage
– Synchronize a Secondary Image
y -fractureimage
– Fracture a Secondary Image
These commands all deal with operations which may be performed on a Secondary Image, the
creation, removal, modification, as well as the synchronization and fracturing of the image. The
–addimage command allows specifying the synchronization rate and other mirror parameters.


y -promoteimage
– Promote a Secondary Image to a Primary Image
y -allocatelog (MV/S only)

– Allocate LUNs to the Write Intent Log
y -deallocatelog (MV/S only)

– Deallocate LUNs from the Write Intent Log
y -listlog (MV/S only)

– List Write Intent Log details
y -listsyncprogress
– List the progress of a synchronization
These commands allow promotion of a Secondary Image and display the progress of a
synchronization operation. There are also 3 commands that are MV/S specific. They deal with
the allocation, deallocation and status retrieval from the Write Intent Log.


y -setfeature
– Adds the feature to or removes the feature from the LUN I/O stack
y -nowriteintentlog
– Need to use this option with mirror creation to create a WIL-less
mirror
The –setfeature command allows MirrorView to be added to the I/O stack of a LUN (usually
used when dealing with a LUN on a remote storage system). If a secondary image is removed by
specifying its image UID, the mirror feature needs to be removed in this manner.
This final CLI command is the –nowriteintentlog. The write intent log is automatically used on
all mirrors on CX4 series systems. CX4 series systems allow all mirrors to have the write intent
log allocated up to the maximum allowable number of mirrors on the system. The performance
improvements previously made in release 26 allow write intent log use with negligible
performance impacts under normal operating conditions. Therefore, the write intent log is
configured on all mirrors by default. The only way to disable this functionality is to use this
option with mirror creation to create a WIL-less mirror.

MirrorView Consistency Group CLI Commands (1)

y -creategroup
– Create a MirrorView Consistency Group
y -destroygroup
– Destroy a MirrorView Consistency Group
y -addtogroup
– Add a mirror to a MirrorView Consistency Group
y -removefromgroup
– Remove a mirror from a MirrorView Consistency Group
y -changegroup
– Change MirrorView Consistency Group property e.g. synchronization
rate
The Consistency Group CLI commands follow the GUI menu choices, creation, destruction and
modification of a Consistency Group, as well as the addition and removal of mirrors from the
group.

MirrorView Consistency Group CLI Commands (2)

y -syncgroup
– Synchronize a Consistency Group
y -fracturegroup
– Fracture a Consistency Group
y -promotegroup
– Promote a Consistency Group
y -listgroups
– List information about Consistency Groups
This final set of commands allows the synchronization, fracture and promotion of a MirrorView
Consistency Group. The listgroups command retrieves Consistency Group information.

Lesson 5: Using MirrorView with SnapView

y Explain how MirrorView can be used with SnapView
Snapshots and Clones can be used in conjunction with MirrorView to make a copy of mirrored
data available to remote hosts.

MirrorView and SnapView

y MirrorView and SnapView are used in conjunction to:
– Allow access to a copy of data stored on a mirror image LUN
¾ COFW will impact performance of mirror
¾ Clone synchronization may impact performance of mirror
y For backup purposes, we can

– Clone primary or secondary images
– Make a Snapshot of primary or secondary images
y DR testing can use Clones of secondary images

– No need to disrupt mirror operation
– Maintains data protection while testing
MirrorView and SnapView work well together. This combination has been used in several
products, among them the CEIM (CLARiiON Exchange Integration Module), a previous
integration product in the CLARiiON space, since replaced by Replication Manager.
Note that the ability to clone a Secondary Image now allows DR testing using a full copy of the
data. This obviates the need for a promotion of the Secondary Image, and may simplify testing.

Possible Replications per CLARiiON Volume Type

Potential Usage
LUN Type Make a snapshot Make a clone Use as Use as source Use as source
of it? (BCV) of it? source for for full SAN for incremental
MirrorView? Copy session? SAN Copy
session?
Yes Yes Yes (c) Yes * Yes
LUN or metaLUN
not yet in use with
any replication
application (a)
No (d) No (e) No (i) Yes No (j)
SnapShot
Yes No (f) No (g) Yes * Yes

Clone (BCV)
Yes Yes (b) No (h) Yes * Yes

MirrorView source
LUN
Yes Yes (b) No (h) No (k) Yes

MirrorView
destination LUN
Shown here are replications that are possible.

* - CAUTION – Source LUN should not change during the copy
a) Includes any LUN used as a target for either a full or incremental SAN Copy session
b) Only if the source LUN is either in a CX3-series storage system running FLARE
02.24.xxx.5.yyy or higher or in a CX-series storage system running FLARE 02.24.xxx.5.yyy
or higher
c) Can use with MirrorView/A or MirrorView/S but not both at once
d) Cannot create a snapshot of a snapshot
e) Cannot clone a snapshot
f) Cannot clone a clone
g) Cannot mirror a clone
h) Cannot mirror a mirror
i) Cannot mirror a snapshot
j) Incremental sessions use snapshots internally
k) Create snapshot or clone and use as the source for SAN Copy session

MirrorView with SnapView
Primary Secondary
CLARiiON CLARiiON
Primary Primary
primary host Mirror Mirror
Image MirrorView Image
connection
Snapshot/ Snapshot/
test host Clone Clone backup host
This shows a typical distance replication solution. SnapView, in the form of Snapshots or
Clones, or a combination, may be used on the primary or secondary image to allow testing or
backup. Bear in mind that the use of SnapView point in time copies on a MirrorView image may
impact performance, especially for MirrorView/S.

LAB
EXERCISES:
y MirrorView/S
y MirrorView/A
Lab Exercise

Module Summary
Key points covered in this module:
y MirrorView/S and MirrorView/A connectivity options
y The operation of the MirrorView/S Fracture Log
y The operation of the MirrorView/S Write Intent Log
y How MirrorView/S and MirrorView/A make remote copies
of LUNs
y The required steps in MirrorView/S and MirrorView/A
administration
y How MirrorView and SnapView can be used together
y Consistency Group functionality
These are the key points covered in this module. Please take a moment to review them.

Course Summary
Key points covered in this course:
y MirrorView/S and MirrorView/A concepts
y Concepts related to SAN Copy
y Configuration and management of MirrorView
y Configuration and management of SAN Copy
y Using EMC Navisphere Manager, Navisphere Secure CLI
and admhost in a practical environment
These are the key points covered in this training. Please take a moment to review them.
This concludes the training.

Assessment
Refer to the link/URL below to access the assessment.
LINK TO TEST URL

or
https://secure.testcraft.com/emc/assess.aspx?aid=MR-
1ZP-MVSCSP&apass=PASSWORD
Refer to the link/URL on the slide to access the assessment.

Closing Slide

MirrorView and SAN Copy Configuration and Management SRG R29

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MirrorView and SAN Copy Configuration and Management SRG R29

Transféré par

Droits d'auteur :

Formats disponibles

MirrorView and SAN Copy

Configuration and Management

EMC Education Services

MirrorView and SAN Copy Configuration and

© 2009 EMC Corporation. All rights reserved.

Welcome to MirrorView and SAN Copy Configuration and Management.

3.24.0.1 January 2007 Complete

4.28.0.1 September 2008 Complete

4.28.5 February 2009 Complete

4.29 October 2009 Complete

© 2009 EMC Corporation. All rights reserved. Course Introduction - 2

Copyright © 2009 EMC Corporation. All rights reserved.

© 2009 EMC Corporation. All rights reserved. Course Introduction - 3

© 2009 EMC Corporation. All rights reserved. Course Introduction - 4

© 2009 EMC Corporation. All rights reserved. Course Introduction - 5

© 2009 EMC Corporation. All rights reserved. Course Introduction - 6

y If the phone rings, answer it as

© 2009 EMC Corporation. All rights reserved. Course Introduction - 7

© 2009 EMC Corporation. All rights reserved. Course Introduction - 8

© 2009 EMC Corporation. All rights reserved. Course Introduction - 9

Module 1: SAN Copy and Incremental SAN Copy

Module 1: SAN Copy and Incremental SAN Copy - 1

Lesson 1: SAN Copy and Incremental SAN Copy

Module 1: SAN Copy and Incremental SAN Copy - 2

Overview of SAN Copy and Incremental SAN Copy

y Source LUN may be a point in time copy

y SAN-based (FC or iSCSI) data transfer

y Full or incremental copies

Module 1: SAN Copy and Incremental SAN Copy - 3

SAN Copy Requirements and Recommendations

Module 1: SAN Copy and Incremental SAN Copy - 4

Module 1: SAN Copy and Incremental SAN Copy - 5

SAN Copy Features

Module 1: SAN Copy and Incremental SAN Copy - 6

Module 1: SAN Copy and Incremental SAN Copy - 7

Incremental SAN Copy Features

y Mark and Unmark operation

y Modify Incremental Copy Session Properties

y Resume to only failed destinations

Module 1: SAN Copy and Incremental SAN Copy - 8

y Auto-Recovery (all SAN Copy Sessions)

Module 1: SAN Copy and Incremental SAN Copy - 9

SAN Copy Parameters

SAN Copy performance can be affected by some of the configurable parameters.

Module 1: SAN Copy and Incremental SAN Copy - 10

Host Buffer Issues

y Windows has no such commands, so we supply a host-

Module 1: SAN Copy and Incremental SAN Copy - 11

SAN Copy Session Creation Process Flow

Running an Incremental SAN Copy Session

y User quiesces (freezes) Source LUN

Module 1: SAN Copy and Incremental SAN Copy - 13

SAN Copy Operation

y Source LUN may be R/W for ISC Sessions

Module 1: SAN Copy and Incremental SAN Copy - 14

Module 1: SAN Copy and Incremental SAN Copy - 15

SAN Copy Failover

y Sessions can be manually transferred to the peer SP

Module 1: SAN Copy and Incremental SAN Copy - 16

Incremental SAN Copy and SnapView

y SnapView Integration presented through SAN Copy UI

Module 1: SAN Copy and Incremental SAN Copy - 17

ISC SnapView Snapshot