05 Friday RemoteCopy 01

Module 6: Remote Copy
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Objectives
At the end of this presentation, students should be able to:
• Explain the difference between Synchronous and Periodic Asynchronous Remote Copy
(RC)
• List valid RC combinations and configurations
• Set up RC for Disaster Recovery
• Monitor RC
2
Remote Copy: What is it?
Array-based Remote Replication for 3PAR storage
Simple CLI interface
UI via Inform Management Console (IMC) 4.1
Synchronous, Asynchronous Periodic and Synchronous Long Distance (SLD)
Modes
• Traditional Synchronous mode
• Periodic Mode: Snapshot-based, intervals as low as 5 minutes
• Combine the benefit of Synchronous and Periodic mode for extra level of data
availability
FC and IP connectivity modes

3
Most common reasons customers
choose RC
High performance
• For RCFC typically can achieve 450-500MB/s
• For RCIP 150-180MB/s
• Usually 3x better performance than EMC Mirrorview/RecoverPoint
Simple management
• Simply to setup use, takes 30-45 mins to setup from scratch
• Usually takes days to weeks for similar EMC solutions
• DR operation is simple to use and simulate
Better features
• Synchronous Long Distance (SLD) which is a high end feature is included in the standard RC licensing
4
Remote Copy: Topology Features
One-to-One
• Either in synchronous or asynchronous periodic mode
Many-to-One (4:1)
• Single InServ can be the target for multiple (up to 4) source InServs
One-to-Many (1:2)
• One InServ can be primary to multiple (up to 2) target InServs
• Different remote copy groups (i.e., you can’t send a given volume to two targets simultaneously except in SLD
mode see below)
Synchronous Long Distance (require InForm OS 2.3.1 or higher)

• A given RC group can be sent to two different InServs simultaneously
• Allows for Sync mode to one target, Periodic to the other. Require one link being FC and the other IP
5
Remote Copy: RC Setup Tool
For CLI:
• DCS, keyword search “remote copy setup”
• Available for RCFC, RCIP
• Input values: IP addresses, names, etc.
• Outputs: commands for configuration and operation.
For UI:
• Inform Management Console (IMC 4.1)
• Click on Remote Copy icon
6
Remote Copy: Distances and Latencies
2.3.1 2.2.4
Sync/IP 130 miles/1.3ms 130 miles/1.3ms
Sync/FC 130 miles/1.3ms 130 miles/1.3ms
Periodic/IP 150ms round trip 150ms round trip
Periodic/FC 130 miles/1.3ms 130 miles/1.3ms
Periodic/FC (FCIP) 60ms 60ms
7
Remote Copy: Protect and share data affordably
3PAR Remote Copy
3PAR Remote Copy
– Smart
• Initial setup in minutes Thin Provisioned
Base Volume
• Simple, intuitive commands
• No consulting services
• VMware SRM integration Primary Secondary
– Thin vs.
• Native IP-based, or FC Other Common Approach Remote
• Thin provisioning aware
Copy
Base
• No extra copies or infrastructure needed
Volume
• Thin conversion
BCV Converter/ Converter/
– Ready
Extender Extender
• Asynchronous Periodic , Synchronous or SLD
• Mirror between any InServ size or model Primary Secondary
• Many to one, one to many
Actual Used Capacity Unused Purchased Capacity
8
Native IP-based Remote Copy
Simplified!
Native IP eliminates need for 3PAR InServ
expensive converters Remote Copy
• Distance flexibility
Primary Secondary
• Cost-effective
vs.
Other Common Approaches
Designed to be transport agnostic

• Native Gigabit Ethernet TCP/IP today Converter Converter
Primary Secondary
• Other protocols quickly assimilated
9
Cost Effective: Active/Active links
Optimize Link Utilization, Increase Availability
Data transfers spread across all configured links

Prevents bottle-necks
Automatically “rebalances” load in case of link failure
Primary Secondary
10
Flexible, Modular Architecture
Configure and mirror between any size InServ
Primary Secondary
11
Thin Provisioning Aware
Base Volume Remote Copy
RAID Protection RAID Protection
2 TB 2 TB 2 TB 2 TB
Don’t 1 TB 1TB 1 TB 1 TB
purchase or
mirror unused Thin Provisioned 3PAR Remote Copy
Base Volume
allocated RAID Protection RAID Protection
capacity
1 TB 1 TB 1 TB 1 TB
12
Remote Copy: Asynchronous
Space efficient
• Copy-on-write Snapshot versus full PIT copy
• Thin Provisioning-aware
Bandwidth-friendly
• Delta copy resynch
• Set timing and frequency of resynch as needed
Targeted Use
• Extended Distances
13
Remote Copy: Asynchronous
Primary Site Secondary Site
Base Snap- Base Snap-
Time
Volume shot Volume shot
1 Initial Copy A AR
Resynchronization.
Starts with
snapshots
B AR
2
Resynchronization. B-A
Delta Copy delta BR
Upon Completion.
3
Delete old snapshot A AR
14
Ready for next
resynchronization
B BR
Remote Copy: Synchronous
Real-time Mirror Primary Secondary

1 2
• Highest I/O currency
• Lock-step data consistency 4 3
Space Efficient Step 1 : Host server writes I/Os to primary

cache
• Thin provisioning aware Step 2 : InServ writes I/Os to secondary
cache
Targeted Use Step 3 : Remote system acknowledges the
• Campus-wide business continuity receipt of the I/O
Step 4 : I/O complete signal communicated back
to primary host
15
3PAR Remote Copy: Data integrity
Assured Data Integrity

– Single Volume
• All writes to the secondary volume are completed in the same
order as they were written on the primary volume
– Multi-Volume Consistency Group

• Volumes can be grouped together to maintain write ordering
across the set of volumes
• Useful for databases or other applications that make dependant
writes to more than one volume
16
3PAR Remote Copy
Efficient data replication
Simple 3PAR Remote Copy
• Initial setup time is fast compared to other vendors Thin Provisioned
Base Volume
• Simple, intuitive commands
Primary Secondary
Efficient vs.
• Thin provisioning aware Other Common Approach
• Asynchronous Periodic or Synchronous Base Remote
• Distance flexibility Volume Copy
BCV Converter/ Converter/
Scalable Extender Extender
• Flexible, modular architecture
Primary Secondary
• Configure and mirror any size InServ
Actual Used Capacity Unused Purchased Capacity
17
Thin Remote Copy
Delivers dramatic data transfer savings for
initial synchronization Efficient
• 99.9% savings for new volumes
• Up to 80% savings for existing fully
provisioned, “fat” volumes*
Other benefits
• Speeds initial synchronization Source Target
• Preserves precious remote copy link • Zeroes detected inline on source system, then
efficiently transmitted to remote system
bandwidth for existing replication groups • Capacity savings when combined with Thin
Conversion
18 * Dependent on written utilization of existing volume, 80% data transfer savings assumes industry-standard 20% written utilization
Remote Copy: Distance-based Replication
Support for Native GigE and FC Replication
Synchronous mode commits writes to both Inservs
before acknowledging to host
Periodic Async mode tracks changes between
synchronization and only updates new data.
Both Synchronous and Periodic are Thin Provisioning
aware.
19
– V-Series
RC can be configured using either GigE or
Fibre Channel
GigE subnet must be a different subnet from
the InServs subnet
A dedicated GigE port is available in F-series,
T-series and V-series systems, so no PCI slot
is required
Fibre Channel (RCFC) will make all 4 ports
on the HBA card unavailable for host
connectivity
20
T-Series and F-Series
0 1 2 3 4 5 PCI Slots 0 1 2 3 4 5
OK OK
< …. > < …. > | O| O | < …. > < …. > | O| O |
OK / OK /
! !
GigE Management Port

Console port C0 GigE IP Replication Port
Remote Copy Eth port E1 Port 2: Disk
Mgmt Eth port E0 Port 1: Disk or Host
Host FC/iSCSI/RC FC ports Slot 1: 2 FC Ports for Host or Disk
Disk FC ports Slot 1: 2 FC Ports for Host, Disk, iSCSI or
FC Based Replication
21
Remote Copy Pairs
The relationship between a storage server pair which contains the Remote Copy
configuration
Within the pair:
• The local, active, or primary storage server is the server that holds the volumes to be
copied to the backup server
• The backup, remote, or secondary server is the “remote” storage server (contains the
VVs that have been copied from the active server)
22
Remote Copy Configurations (1 of 5)
Bidirectional
• Each InServ provides backup to the other InServ for selected volume groups
23
Unidirectional
• Each InServ is either a backup or primary InServ
• Selected primary volume groups to the other which will be selected secondary volume
groups
24
N to1
• InServs use the same
backup or secondary
InServ; a combination of
unidirectional and
bidirectional (only one
bidirectional) can be used
•N has a max of 4
• Secondary InServ must
have 4 or more controller
nodes
25
1 to N
• A single primary InServ can use
multiple InServs as backup; a
combination of unidirectional and
bidirectional (only one
bidirectional) can be used
•N has a max of 2
26
SLDRC (Synchronous Long Distance
Remote Copy) only InForm OS 2.3.1.x
and >
• A single volume group is copied to
volume groups on two other backup
InServs
• None of these links can be
bidirectional
• Either backup site can take over in a
disaster
• One synchronous via Fiber Channel
and the other asynchronous periodic
via Fiber Channel or Ethernet
27
Remote Copy: Steps for Unidirectional Setup
1. InServs can be any combination
2. Establish RC links
− GigE
− Fibre Channel
3. Start Remote Copy on both systems

4. Establish RC relationship on both systems
− Each RC relationship is defined separately
5. Create RC group (synchronous or Periodic Asynchronous)

6. Add volumes (volumes must have snap space) to RC group
7. Start RC group (and synchronization)
28
Remote Copy Links
Sending Link Created manually during the Remote Copy setup
The commands that configure the “Sending Link” are:
• admitrcopylink
• Creatercopytarget
Receiving Link Automatically created on all nodes that have sending links
configured
29
Synchronous Remote Copy
Host-initiated write is performed on both the active and the backup storage servers
before acknowledging the host write
On active storage server, the write is written to the write cache of two nodes; this is
the standard redundancy of the 3PAR InServ
Concurrently, the write is sent via communication link to backup storage server
The write request is written to the write cache on two nodes before it sends
acknowledgment to the active system
Host write is acknowledged once the local cache update completes, as well as
receiving the remote acknowledgment
30
Asynchronous Periodic Mode
Host writes are performed on the active server
Host write is acknowledged as soon as the data is sent to the cache of two nodes
(normal host write acknowledgment)
The “active” and “backup” servers are resynchronized periodically
The resynchronization can be scheduled or done manually
31
Advanced replication configuration―SLD
1 3
4
32
Set up RC Links―part 1
33
Set up RC links―part 2
34
View RC links
35
Create RC group
36
Replication completed
37
Failure occurred
38
Recover from Synchronous site (sa-ins56)
39
Restore RC group
40
Failure occurred
41
Recover from Asynchronous site (sa-ins55)
42
Restore RC group
43
Remote Copy enhancements
for 3.1.2
Future Remote Copy Enhancements
InForm OS 3.1.2 release
• Support for both Synchronous and Asynchronous RC between a pair of HP

3PAR Storage Systems
• Sharing of host HBA ports with Remote Copy for HP 3PAR 7000 platform
• Automation of Remote Copy Volume creation on the DR site

• Verify RC volume status (via CRC checks)
• Transparent failover
45 Rev. 12.41
Future Remote Copy Enhancements
InForm OS version - TBD
• True Async Remote Copy
46 Rev. 12.41
Remaining Enhancement Areas
1-to-1 and 1-to-2 configurations
1-to-1 Remote Copy configuration
• Support for eight RCFC and RCIP links
between a pair of HP 3PAR Storage
Systems
• Higher number of Synchronous and
Asynchronous volumes
1-to-2 Remote Copy configuration
• Both links are Synchronous Remote
Copy
• Bi-Directional replication for both the
links
48 Rev. 12.41
Synchronous Long Distance
• Bi-Directional replication on Synchronous
and Asynchronous Periodic link
• Multiple SyncLD configuration with either A
or B as source
• Additional configuration (1:1, 1:2 or 1:4)
with primary, SYNC or DR site as the target
or source
• SYNC site is the repository of delta changes
only
49 Rev. 12.41
4-to-1 Remote Copy Configuration Gaps
• Increase the number of source systems
that can replicate to the Target System
• Increase the number of links available on
the Target System
• Increase the Bi-Directional replication to
all links
50 Rev. 12.41
Other Remote Copy Enhancements
• In a 3 data center replication ability to replicate from A – to – B – to – C
• Autonomic Group support with Remote Copy
• Ability to replicate snapshot tree
• Support a Queuing mechanism for application to hand over snapshots to
replicate through Remote Copy
51 Rev. 12.41
Remote Copy—Issues and risks
• The performance goals of Peer Persistence are to ensure that the attached host set does
not timeout during the switchover operation.
• For small groups with few volumes this is normally not an issue, however with a large
number of volumes spread over a number of groups the switchover operation can take
a longer period of time than our goal of 30 seconds maximum.
• The reason for this is that the switchover operation requires snapshots to be taken on
both primary and secondary so that recovery points are in place should the operation
fail. As a result of these snapshots the system TOC is updated which results in non-
optimal switchover times.
• The switchover operation is a superset of the existing Remote Copy disaster recovery
commands including stoprcopy, failover, recover and reverse operations.
• The recover sub-operation requires that the volumes are promoted back to a known
state.
52 Rev. 12.41
Remote Copy Issues and Risks (Cont)
• This should be a purely academic operation as the volumes should be consistent during the
switchover so there should be no data to promote, however in the event that the switchover has
failed OR the user has been using different combinations of Remote Copy commands then the
recover sub-operation does require the promote to prevent miscompares between primary and
secondary volumes.
• As a result of these promotes the final reverse operation which tidies up the state of the remote
copy group is an asynchronous task which might timeout if the volume promotes take longer than
we expect, or if communications between the arrays is lost during this time.
• In this instance the primary and secondary groups will be marked as pri-rev and sec-rev and
subsequent switchover commands will fail until the reverse operation is completed.
• To manually complete this operation the user should use the setrcopygroup reverse –natural
<groupname> command which will complete the tidyup of these groups.
Configuration rules, installation, upgrade and downgrade considerations
• Use the normal procedure for installation, upgrade and downgrade of this software.
53 Rev. 12.41
Troubleshooting Remote Copy
• Remote Copy configuration is managed by the SysMan application.
• The showrcopy command will indicate the state of the Remote Copy groups and
volumes.
• The showvlun command will indicate the state of the exported LUNs.
• In the event of a customer escalation an InSplore should be collected for each array in
the configuration.
54 Rev. 12.41
Remote Copy data verification
Remote Copy data verification
• The need for Remote Copy Data Verification
− Remote copy does not currently provide any means for customers to compare live primary and
secondary volumes
• Volumes that belong to remote copy groups that are in the started state
− Inconsistencies between the two volumes are not easily detectable
− In fact there is no easy way to carry out a comparison without using third-party software or
running a file system check (such as fscheck).
• Remote Copy Data Verification
− Provides customers with a data verification tool which compares primary and secondary
volumes and reports inconsistencies.
− The key feature of the project is that the comparison can be carried out without stopping the
remote copy group.
− Additionally, an option is provided to automatically correct any miscompares which are
discovered.
56 Rev. 12.41
How does it work? (Function)
• checkrcopyvv detects miscompares in passive volumes
− No I/Os occur during the compare operation
− Uses snapshots, rather than the base volumes, during the compare.
• Avoids the requirement to quiesce the volumes
• Repair option employs the existing resync code
− Writes the miscompared blocks back to the secondary volume
− The repair option makes some modifications
57 Rev. 12.41
Configuration and installation
• Remote Copy Data Verification can be used on all Remote Copy configurations
• It can only be used to check one volume at a time, so for example, on an SLD system
the command will need to be issued once for the sync target and once for the periodic
target.
• The command must be issued from the primary 3PAR 7000 system
• The data on the primary 3PAR 7000 system is assumed to be correct. When
miscompares are discovered, the primary volume is used as a source to repair any
errors on the target volume.
• The feature requires 3.1.2 or later
• There is no impact to upgrade/downgrade functionality.
• There are no special installation or configuration requirements.
58 Rev. 12.41
Performance benefits
• Previously undetected inconsistencies can be detected and repaired with a single
command.
Any gotchas?
• The command runs at a relatively low priority so as not to impact on normal system
operation.
• This means that very large volumes can take a considerable amount of time to
compare/repair.
• It also means that the command can run slowly on very busy systems.
• This is deliberate.
59 Rev. 12.41
Troubleshooting
• What files to gather (file name and path)
− Output is logged to the sysmgr log:
− /var/log/tpd/sysmgr
• Commands to run and what output to collect

• No special commands – just the sysmgr log
• The repair operation task log can be viewed by using the showtask –d <tid>
command.
Common error messages and limitations
• checkrcopyvv cannot be run using the –v option while the remote copy group is
stopped.
• checkrcopyvv cannot be run using the –r option while the remote copy group is
stopped.
60 Rev. 12.41
Troubleshooting (Cont)
• a second instance of checkrcopyvv cannot be started while an existing instance exists.
• checkrcopyvv can only be run from the primary 3PAR 7000 system.
• checkrcopyvv cannot continue if there is a configuration change since the online compare
command was issued.
• The showtask –d command returns a log detailing the progress of the repair sync. The log will
indicate a problem if the repair operation did not complete successfully.
• A secondary snapshot might be left behind if all Remote Copy links go down during a compare
operation. This will expire and delete automatically.
What does each error message mean?
• Error messages have been written to be self explanatory.
• Log messages related to this feature are prefixed with the letters RCDV. (Remote Copy Data
Verification)
• Bugs for this feature can be found by searching bugzilla for the feature id RCOPY2
61 Rev. 12.41
Remote Copy 1-to-2
bi-directional support
Bi-directional support in 1:N

configuration
Remote Copy 1-to-2 bi-directional support
• Remote Copy will now support bi-directional groups when provisioned in 1-to-2
configurations.
• Primary Remote Copy groups can be created on both sides of both legs of a 1-to-2
configuration.
63 Rev. 12.41
Bi-directional support in 1:N configuration
• In an 1:N (1:2) configuration, bi-directional
replication supported between Source and
ce
both of the two Targets S our
en
e t we
b 1
− Supported configs: t io nal arget
ec n d T
dir a
• Async Periodic on both targets Bi-
• Sync on one and Async Periodic on other Target 1

target Bi
-d
• Why should the Customer care? i re
cti
on
an al b
− Provides high level of deployment flexibility d T et
arg wee
et n S
− Allows customers with 3 datacenters (DCs) to 2 ou
Source rce
deploy primary applications on all 3DCs, and
protect their data/applications using storage
system located in another DC. Note: Different volume
groups are being replicated (1:N)
64 Rev. 12.41
Target 2
Benefits
• Benefits
− This feature allows more complex bi-directional configurations to be designed.
− Offers customer more options and flexibility
• How does it work?

− No special command required
− Standard Remote Copy configuration commands should be used to configure primary remote
copy groups on any arrays of a 1-to-2 Remote Copy configuration.
− This functionality was possible in software release 3.1.1 but had not been qualified as a
supported customer configuration.
65 Rev. 12.41
Best Practices
• Configuration and best practices
− Maximum limits still unchanged.
− 800 volumes - Max replicated volumes for Synchronous Remote Copy target
− 2400 volumes - Max replicated on a system with only Periodic Asynchronous Remote Copy
targets.
• Configuration rules, installation, upgrade & downgrade considerations
− Use the normal procedure for installation and upgrade of this software to 3.1.2
− The downgrade procedure requires that the bi-directional configuration on 1-to-2 deployments
to be removed before the downgrade procedure will be allowed.
• Issues and risks
− Only one single Synchronous Remote Copy target, however these targets configuration will
support bi-directional Remote Copy.
− Multiple Periodic Asynchronous Remote Copy targets can be configured.
66 Rev. 12.41
Remote Copy Mixed sync/periodic
mode support
Remote Copy mixed sync with periodic mode
•support
Prior to 3.1.2, Remote Copy only supports a single replication mode
• Only synchronous or only periodic-running in a 1:1 Remote Copy configuration.
• Customers required a mixed sync/periodic support
− Offers more flexibility for different applications that might require different RPO.
• 3.1.2 will now allow mixed Sync/Periodic in a 1:1 Remote Copy topology
How does it work
• Mixed Sync/Periodic mode requirements:
− Two targets between the same system pair.
− One for synchronous mode and one for periodic mode.
− Each target has its own links. Two links are required for each of the target.
• 4 links are required between the same node pair( 4 RCIP links or 2 RCIP and 2 RCFC links)
• Synchronous remote copy group created using Synchronous mode target
• Periodic groups created using Periodic remote copy target.
68 Rev. 12.41
Best practices
• Each mode would apply to different Remote Copy Groups within the 3PAR 7000 system
• Note: A given Remote Copy Group would replicate using one of the modes, not both
• Support needed on 3PAR 7000 T, V, F and A-Class systems
• Maximum replicated volumes on a mixed Synchronous and Asynchronous Periodic 1:1 Remote Copy
configuration would be 800.
• 3PAR 7000 systems in the 1:1 Remote Copy relationship must comply with maximum latency.
• Bi-directional replication is supported.
• Volumes from array A can be replicated to target volumes on array B while volumes from array B can be
replicated simultaneously to target volumes on array A.
• Two-node systems are supported.
Two-node system
• Since we only support 1 RCIP link per node, user must use RCFC and RCIP together. We don’t support pure
RCIP for mixed mode for 2 node systems.
• There could be a negative impact on Host Service Times for the synchronous volumes during re-syncs of other
periodic volumes.
69 Rev. 12.41
Remote Copy VASA support and
inter-Remote Copy group transfer
What is it
• VASA interfaces directly with CLI to create a VM on the fly.
• These CLI commands create a new volume.
• Issue: For Remote Copy, difficult to add a volume Remote Copy group because there
is no way to create a similar volume on the secondary automatically.
• In 3PAR OS 3.1.2, Remote Copy interfaces enhanced to support automatic volume
creation on the secondary when a new VASA connected volume is added to the
remote copy group.
• These new interfaces are not restricted to VASA only.
71 Rev. 12.41
creatercopygroup
• Two new options –usr_cpg and –snp_cpg
− -usr_cpg <cpg name> <target_name>:<cpg_name>...
• Specify the local user CPG and target user CPG that will be used for volumes that are auto-
created. Local cpg will only be used after failover and recover.
− -snp_cpg < cpg name> <target_name>:<cpg_name>...
• Specify the local snap CPG and target snap CPG that will be used for volumes that are auto-
created. Local cpg will only be used after failover and recover.
72 Rev. 12.41
admitrcopyvv
• New option -createvv for admitrcopyvv
− Indicates that the secondary volume will be created automatically with the user specified
usr_cpg and snap_cpg on secondary side.
− The remote side volume will have the same size, same volume type, and same wwn as the
primary side volume.
− New option –nosync is added to specify to skip the initial sync of this volume.
• This is for the admission of the volumes that have been pre-synced with target volumes.
− User can also specify an optional read-only snapshot <snapname> along with the virtual
volume name <VV_name>.
− This snapshot is a starting snapshot.
− When the group is started a full sync is not performed. Instead , the volume will sync deltas
between <snapname> and the base volume.
73 Rev. 12.41
dismissrcopyvv
• Will have a new option
• –removevv to remove the volume on secondary side automatically.
− Primary side volume will not be deleted
setrcopygroup cpg
• New subcommand setrcopygroup cpg to allow user to set usr_cpg and snp_cpg locally
and on remote side for an existing Remote Copy group.
• Useful to change the cpg associated with an existing Remote Copy group, or specify
cpg for the Remote Copy groups without cpg specified.
removecopygroup
• We added a new option –removevv for removercopygroup
• It will automatically delete all the volumes in the Remote Copy group on remote side.
• Primary side volumes will not be deleted.
74 Rev. 12.41
showrcopy
showrcopy –d will show the local cpg and remote cpg information.
---
Group Information
Name ID Target Status Role Mode LocalUserCpg LocalSnapcpg RmUserCpg RmSnapcpg Options
wg1 37 t1 New Primary Periodic cpg4 cpg4 cpg2 cpg2 over_per_alert

75 Rev. 12.41
showcpg
• showcpg –d shows the Remote Copy usage for the cpg.
• Will show the number of Remote Copy groups using this cpg as usr_cpg and number
of Remote Copy groups using this cpg as snap_cpg.
• If any of this RC_usage count is not zero, user cannot remove this cpg.
showcpg -d ---------------(MB)----------------
-Volumes- -Usage- --- Usr --- --- Snp ---- -- Adm --- - -- LD ---- --RC_Usage--
Id Name Warn% VVs TPVVs Usr Snp Total Used Total Used Total Used Usr Snp Adm Usr Snp
0 cpg1 - 42 0 21 21 32768 30720 65536 21504 16384 5376 92 8 4 0 0
1 cpg4 - 2 0 1 1 11264 10240 65536 7168 16384 512 8 8 4 3 3
2 cpg2 - 0 0 0 0 0 0 0 0 0 0 0
0 0

76 Rev. 12.41
growvv
• The grow operations of Remote Copy volumes are coordinated between the primary
and secondary targets.
• A coordinated grow can be started from primary or secondary target.
• Volumes on remote targets are grown to the intended size of the local volume.
• If a target cannot be contacted or Remote Copy is not started, only the local volume
will be grown.
Best practices
• Both primary and secondary need to be 3.1.2. or later
77 Rev. 12.41
Remote Copy SMI-S support
SMI-S support
• HP StorageEssentials requested that CIM provide support of discovery of Remote Copy entities.
• It requires Remote Copy provide WWN for remote side volume and remote node WWN.
• In 3.1.1, Remote Copy compute the remote volume WWN, in 3.1.2, HP enhanced the code to get
the information from the remote side.
• In 3.1.1, we added support to provide remote node WWN and local and remote volume WWN in
getrcopy.
• For remote side volume WWN in 3.1.1,
− During system init phase, we will set remote volume WWN to NOWWN and WWN status to
RM_VV_WWN_INAVLID.
− While users try to add new volume to Remote Copy group, we will compute the remote volume WWN
using remote system id and remote volume id and set the WWN status to RM_VV_WWN_COMPUTED
− For existing volume in the group, we will compute the remote WWN when we try to start the group. The
remote volume WWN will be calculated and the WWN status will be set to RM_VV_WWN_COMPUTED.
79 Rev. 12.41
Enhancements in 3.1.2
• For 3.1.2, we added support to communicate with remote side to get the WWN instead of computing the WWN locally.
• While we try to add new volume to the group, we will communicate with remote side to get the WWN, and the WWN status is set
to RM_WWN_VALID.
• For existing volume in the group, we will get the remote side WWN when we try to start the remote copy group, and the WWN
status will be set to RM_VV_WWN_VALID.
Best practice
• The information is stored in TOC.
• We will get the WWN when we try to add new volumes to group or when user try to start the group. So if the groups are created
before, the WWN will remain as NOWWN until user try to start the group.
• If one side is at a version not support the new message, we will compute the remote WWN locally.
Troubleshooting
• We can call
• cli Tpd::rtpd getrcopy to list the local WWN and remote WWN and WWN status on both primary and secondary systems.
• The information displayed should match on both primary and secondary systems.
80 Rev. 12.41
Inter “Volume Group” Transfer
Without Full Resync
Inter “Volume Group” transfer without full sync
• Move Remote Copy Volumes from one
Remote Copy Volume Group to another Source
Source Vol
Vol Grp1
Grp1
Target
Target Vol
Grp1
Grp1
Vol
without the need for a fresh full sync

1 2 Initial Sync for newly 1` 2`
− Remote Copy Volumes can be moved among added Source Volume
SS 3 3`
different volume groups, and to use their 1. Stop Vol Groups
existing snapshots for delta resync. This Source
Source Vol
Vol Grp2
Grp2 - Snapshot taken Target
Target Vol
Vol
Grp2
Grp2
avoids the need for full sync for the existing 2. Move vol 3 and 3`
Remote Copy volumes when moved. 4 5 4’ 5`
3. Start Vol Groups
• Why should the Customer care?
− Efficient utilization of bandwidth by
completely avoiding full initial sync for Only delta
Remote Copy volumes being moved resync needed!
− No impact of Remote Copy performance due
to avoidance of initial full sync
3PAR StoreServ 3PAR StoreServ
82 Rev. 12.41
Bi-Directional Support in
Synchronous Long Distance
Configuration
Bi-directional support in Synchronous Long Distance
configuration
Bi-directional between Source
• In an SLD configuration, bi-directional and Sync Target
replication supported between Source

and Sync Targets
− Supported configurations:
Source Sync Site
• Only one Source and Sync Target pair
Un
i-d
allowed bi-direction
ire and
ct i D
• Source/DR pair is Uni-direction as before
on R
al Ta
be rg
• Why should the Customer care?
tw e t
ee
n
So
− Provides high level of deployment flexibility
rcu
e
− Allows customers with 3 data centers to
deploy primary applications on their source
and Sync sites, and protect their DR Site
data/applications using storage system
84 Rev. 12.41 Note: Different volume groups are being replicated (1:N)
located
© Copyright in another
2012 Hewlett-Packard dataL.P.center.
Development Company, The information contained herein is subject to change without notice.
Target 2
Troubleshooting
• Remote Copy configuration is managed from the System Manager application.
• The showrcopy command is the only source of information from the CLI/UI that
indicates the state of Remote Copy targets and groups.
• In the event of a customer escalation an InSplore should be collected for each array in
the 1-to-2 configuration.
85 Rev. 12.41
Peer Persistence
Peer Persistence (“Transparent” Failover)
ESX cluster
ESX running in ALUA

mode
Active Path (Vol A)
A
LUN
LUN B
LUN B
LUN A
Active Path (Vol B)
Up to 5ms RTT latency
Fabric Fabric Passive Paths
Array A Array B
Vol B (Secondary) Sync RC Vol B (Primary)
Vol A (Primary) Vol A (Secondary)

Site 1 Site 2
87
Peer Persistence
• Peer persistence is a feature that has been added to Remote Copy in 3.1.2.
• Synchronous Remote Copy volumes can be created on primary and secondary arrays using the
same WWN addresses, and exported to the same host set from both arrays.
• Host IO access is managed using Synchronous Remote Copy to allow volume access to be
migrated between primary and secondary arrays without disrupting IO from the host set.
• The setrcopygroup switchover <group> command allows a Synchronous Remote Copy group to
be migrated from a primary array to the secondary array without impacting the host set or any
outstanding IO associated with these volumes.
Business benefits
• The Peer Persistence feature allows versatile deployment of storage services within data centres.
• Synchronous Remote Copy volumes can be migrated between storage arrays without stopping IO
from the VMware ESX 5.0 hosts.
88 Rev. 12.41
How does it work?
• Access to these volumes is controlled using different target port groups as defined in SPC-4.
• Asymmetric logical unit access (ALUA) is used to define different target port groups for both primary and
secondary array allowing the primary target port group to be configured as ACTIVE and the secondary target
port group configured as STANDBY.
• ACTIVE target port groups supports SCSI READ/WRITE access.
• STANDBY target port groups do not support SCSI READ/WRITE access.
• When the setrcopygroup switchover <group> command is issued host access to the primary volumes will be
blocked and any in flight IO will be allowed to drain, the group is then stopped and failed over to the
secondary volume.
• Target port groups on the primary volume will be changed to STANDBY and secondary target port groups will
become ACTIVE.
• Any IO which was blocked on the primary volumes will now be unblocked and returned to the issuing host
with a sense error indicating the change of target port group. The host will perform fresh inquiries on all target
ports and reissue the IO to the secondary volumes.
• The Remote Copy group will be reversed to reflect the updated roles for both arrays and the group restarted so
that a disaster recovery solution is always available.
89 Rev. 12.41
Learning check
Lab activity
Lab debrief
Thank you

05 Friday RemoteCopy 01

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

05 Friday RemoteCopy 01

Caricato da

Copyright:

Formati disponibili

Module 6: Remote Copy

FC and IP connectivity modes

Synchronous Long Distance (require InForm OS 2.3.1 or higher)

expensive converters Remote Copy

Designed to be transport agnostic

Data transfers spread across all configured links

Configure and mirror between any size InServ

Real-time Mirror Primary Secondary

Space Efficient Step 1 : Host server writes I/Os to primary

Assured Data Integrity

– Multi-Volume Consistency Group

GigE Management Port

3. Start Remote Copy on both systems

5. Create RC group (synchronous or Periodic Asynchronous)

• Support for both Synchronous and Asynchronous RC between a pair of HP

• Automation of Remote Copy Volume creation on the DR site

• True Async Remote Copy

• Commands to run and what output to collect

Bi-directional support in 1:N

• Sync on one and Async Periodic on other Target 1

• How does it work?

without the need for a fresh full sync

replication supported between Source

ESX running in ALUA

Vol B (Secondary) Sync RC Vol B (Primary)

Vol A (Primary) Vol A (Secondary)

Potrebbero piacerti anche