M 201 Res 01

SAN Copy and Incremental SAN Copy - 1
Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

The objectives for this module are shown here. Please take a moment to read them.
The objectives for this lesson are shown here. Please take a moment to read them.
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.
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 Unisphere to provide the drive letter/file system mapping of participating Symmetrix
volumes, the Unisphere 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 Unisphere much the same as any attached host. The SAN Copy port is
identified by the storage system name rather than the Storage Processor network name, the owning
Storage Processor, and also the ports World Wide Name.
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 adjusts 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 tries to use FC connections between the storage systems involved in a session, then tries
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 only copies changes to the destination(s). Changes are tracked by means of
bitmaps, and, if required, a COFW process is 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 performs 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 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 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, has 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 calculates 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
increases 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 are updated with the
completion status, the time of completion and, in the case of a failure, the number of blocks transferred
before the failure.
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.
The SAN Copy session can be set to copy data between two 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 are 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 Unispheres multi-domain
management feature, can communicate with each other, and share information about LUNs; all LUNs
that may be used for SAN Copy purposes are 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, is 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.
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 are incremental. If an additional destination is added at any time, a full
copy is performed to that destination only; subsequent copies are incremental.
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 initiates 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.
When the user creates a SAN Copy session, the SAN Copy software stores that information
persistently in the PSM LUN. It is the softwares 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 sessions status is 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.
When a source LUN is not available through the sessions owning Storage Processor, the session will
fail. This happens 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.
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.
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.
Sessions are treated in a similar way. Sessions and their Snapshots are 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 is not 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 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.
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 Unisphere does not allow the ISC session to start. An error
message is displayed upon this failure.
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 is unbound from the Source LUN stack if no
ordinary SnapView Sessions are running on that Source LUN.
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.
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.
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 tries to resume the session by retrying five times at three-minute intervals.
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:
Local Replication - which provides SnapView operations only (no recovery) a role that would
restrict someone to start/stop SnapView operations
Replication - which provides SnapView, MirrorView, and SAN Copy operations (no recovery)
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 Unisphere 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 include SAN Copy actions.
Thin Replication is applicable with SAN Copy.
Space reclamation is a new feature in FLARE Release 30 that allows the system to free up allocated
storage that is not used. This feature works in conjunction with LUN migration and SAN Copy when
migrating existing volumes to thin LUNs. Unused storage is often locked up by applications that are
either no longer important to organizations or do not need the storage that was originally allocated to
them. With the space reclamation feature, you can nondisruptively migrate existing volumes of your
applications to FLARE release 30 thin LUNs and reclaim the unused space. Since thin LUNs only
consume storage to which data is written, all the allocated but unused storage is returned to the pool
that can be used by other LUNs in the pool. The process is completely transparent and so you can
move your applications without requiring any downtime.
Space reclamation is automatically invoked when performing a SAN Copy pull operation on source
volumes from older CLARiiON systems, Symmetrix storage systems, and supported third-party
systems to a thin destination LUN running FLARE release 30.
Space reclamation is also invoked when you perform a LUN migration to move an existing traditional
LUN or thick LUN to a thin LUN within the same array, (running FLARE release 30). The software
detects zeros at 8k chunk granularity. For example, it will only migrate 8k chunks with data in them. If
the 8k chunk is filled with zeros, it will not be migrated to a thin LUN.
In SAN Copy sessions, pools LUNs can be source and/or destination LUNs. The support for thin
LUNs was added in FLARE release 29. Thick LUNs will also be supported for SAN Copy operations
starting with FLARE release 30. When all the systems involved in SAN Copy operation are running
FLARE release 29 and later, and the source and destination LUNs are thin, only the consumed capacity
is copied; the unused or zeroed space is not copied. This is true for a full-copy session, initial
synchronization, and a bulk copy of an incremental session. Incremental updates are similar because
only data that has changes is copied.
SAN Copy supports migrations between thin, thick, and traditional LUNs. With the space reclamation
feature in FLARE release 30, you can do a SAN Copy pull operation from a non-thin source on an
older release CLARiiON or any supported third-party array to a FLARE release 30 thin destination and
reclaim the zeroed space from the non-thin source.
Also good to know!
LUN migration moves data from a source LUN to a destination LUN (of the same or larger size)
within a single storage system. This migration is accomplished without disruption to the applications
running on the host. Pool LUNs can be the target or source of LUN migration operations. LUN
migration can enhance performance or increase disk utilization for your changing business needs and
applications by allowing the user to change LUN type and characteristics, such as RAID type or size,
while their production volume remains online. Pool LUNs can be moved between pools or to a
traditional LUN in another RAID group.
When migrating a thin LUN to another thin LUN, only the consumed space is copied. When migrating
a thick LUN or traditional LUN to a thin LUN with FLARE release 30, the space reclamation feature
is invoked and only the consumed capacity is copied.
If you are migrating a traditional LUN on a prerelease 30 system to a thin LUN, the thin LUN ends up
being fully allocated. Migration from thick LUNs to traditional LUNs or another thick LUN and from
traditional LUN to thick LUNs is also permitted.
29
Three new roles were introduced in FLARE 29 to provide 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
Global Replication roles are only supported in a complete FLARE 29 or higher environment, meaning
all arrays in the domain must be at FLARE 29 or higher. 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 and higher.
29
The chart shown here describes the Replication Roles for San Copy Operations.
Doubled SnapView snapshot limits, and by extension, SAN Copy:
Expands usage of SnapView and SAN Copy
Limits not increased on CX4-960
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
and thus increased IOPS processing speed.
The nature of the I/O (sequential vs. random) and (large vs. small block) affects 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.
CLARiiON FLARE Releases 29 and higher support SAN Copy using both Pool LUNs and Traditional
RAID Group LUNs. (FLARE 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 scenarios result in a fully provisioned Thin LUN which could be an
undesirable circumstance:
1
st
scenario - when creating a copy session with Traditional Pool or FLARE source LUN and a
Thin LUN destination.
2
nd
scenario - when creating a PULL copy session.
3
rd
scenario - when creating a copy session with Thin destination on pre-R29 array
The Unisphere SAN Copy wizard can be launched from the Replicas > SAN Copy wizard menu.
With FLARE Release 30, Thin LUNs continue to be supported for SAN Copy, the difference is Thin
LUNs are now created in Pools. By default, newly created Pool LUNs are created as traditional, fully
provisioned LUNS, that is, all storage capacity is fully allocated to the LUN when created, Thin LUNS
are created by selecting the Thin box under the LUN Properties. All combinations of LUNs are
supported for SAN Copy as noted in the previous slide. The example shows the wizard selection for
both source and destination LUNs. From the top window, a Thin LUN is selected as the source, the
bottom window displays the available LUNs which could be Thin or Traditional LUNs ( either Pool or
RAID Group LUNs) provided the LUNS are at least the same size or larger than the source LUN.
For the Navisphere Secure CLI, there were no changes to the sancopy command syntax.
The objectives for this lesson are shown here. Please take a moment to review them.
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:
Select the storage array in which the Storage Group you want to connect to (the peer) resides, ( Example:
FNM00100100003) .
From the Storage menu select Storage Groups a list of available storage groups will appear. Right-click the
selected group and then click SAN Copy > Connections.
The SAN Copy Connections dialog box opens. In SAN Copy System, select the storage system/SP entry
that includes the SAN Copy port you want to connect to the Storage Group. Ports to connect lists all
available SAN Copy ports, both FC and iSCSI for the selected SAN Copy storage system and SP.
SAN Copy displays only those SAN Copy ports that are in the same zone or connection group as the SP
ports of the Storage Groups storage system.
Select all the SAN Copy ports that you want to connect to the selected Storage Group, and click OK.
View the Connectivity Status > SAN Copy Initiators to view detailed information. The example
shows all initiators logged in and registered.
iSCSI connections appear here as well. A Fibre-preferred connection searches for a fibre connection
path to the remote LUN first and an iSCSI connection path second.
The Configure SAN Copy Settings option ( shown with default values ) allows configuration of the
number of concurrent sessions per SP, number of buffers per session, buffer size, and checkpoint
interval.
The memory configured here is used by SAN Copy when running full as well as incremental sessions.
Note the buffer size, by default is 1024 blocks ( 512kB ) and 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 is 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 are written to cache. Write requests larger than 1023 are written
directly to disk.
Like most operations in Unisphere, there is more than one way to accomplish the same task. To create
a CLARiiON to CLARiiON SAN Copy session from the Dashboard menu, ( not shown ) right-click
the storage system on which you want to create the session and click SAN Copy > Create Session.
The storage system must have the SAN Copy software installed.
The example shown in the slide uses a second method of selecting Replicas > SAN Copy Wizard.
The first wizard screen to appear is a summary of the steps the wizard takes the user through in the
creation of the session. Read the wizard summary and click Next.
The Select Session Type window allows you to select the type of session; full copy or incremental
copy.
The Select Storage Sources window allows you to 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.
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.
In Storage Destination, select a storage system in which the destination logical units reside from
the dropdown menu.
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.
From Available Storage, select the logical units that are used as destination storage, and click the
right arrow to move them into Selected Storage.
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 Unisphere Host Agent from the Symmetrix host system added to a portal, Unisphere 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.
Clicking the Session Name highlights the Edit tab in the lower right window and allows the user to
edit the session name and throttle value. 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. 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.
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 change the session property.
If the session summary is accurate, click Finish to create the sessions.
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:
1. From the Replicas tab navigate to the Sessions tab.
2. Right-click the Session Name and then click Start or optionally, select Start from the bottom of
the window.
3. Once the session is started, click the status option to view the operation.
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 once the session is started.
Confirmation and Success boxes are displayed and the session is 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 allows the session to complete. Again,
Unisphere displays Confirmation and Success boxes.
Many commands are common to SAN Copy in Full Copy Mode and Incremental SAN Copy.
Commands that are unique to one or the other are called out.
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 shows 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.
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
restarts 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.
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.
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.
The objectives for this lesson are shown here. Please take a moment to review them.
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:
admhost lun_activate which can be used to assigns drive letters (NT/2K/2K3 only) and re-
discover deactivated LUNs.
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.
admhost lun_flush which can be used to which can be used to flush data from host buffers to
maintain LUN currency.
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 Unisphere Host Agent is not present. The
agent would otherwise inform Unisphere of the mapping.
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.
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.
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.
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.
To avoid conflicts with access to the destination LUN or volume, the admhost lun_deactivate
command should be issued against the destination LUN. This flushes 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 takes place. While the session is active, the
source LUN is 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 online.
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 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 Exercise
These are the key points covered in this module. Please take a moment to review them.

M 201 Res 01

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

M 201 Res 01

Hochgeladen von

Copyright:

Verfügbare Formate

SAN Copy and Incremental SAN Copy - 1

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.

Das könnte Ihnen auch gefallen