HP 3PAR Remote Copy Software User Guide HP 3PAR OS 3.1.3 Abstract This guide is for system and storage administrators who monitor and direct system configurations and resource allocation for HP 3PAR StoreServ Storage systems.
© Copyright 2014 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Contents I Setting the Foundation for Remote Copy.......................................................12 1 Planning Your Remote-Copy Setup Strategy..............................................13 Setup Instructions and Resources..........................................................................................13 Requirements.....................................................................................................................13 General Requirements.....................................
1-to-N Remote-Copy Considerations.................................................................................44 M-to-N Remote-Copy Examples............................................................................................45 1-to-1 Remote-Copy Example...........................................................................................45 Example Remote-Copy Pair for N-to-1 Setup......................................................................46 Example 1-to-N Remote-Copy Setup.......
11 Viewing Remote-Copy System Information...............................................95 How Remote Copy Tracks Synchronization Details..................................................................95 Tracking Synchronous Volume Groups..............................................................................95 Tracking Asynchronous Periodic Volume Groups................................................................96 Viewing Synchronization Task Information........................................
Setting Volume Group Policies...........................................................................................118 Automatically Restarting Volume Groups........................................................................119 Generating Alerts for Slow Resynchronization of Asynchronous Periodic Volume Groups.......119 Volume Group Modes......................................................................................................120 Overview of Volume Group Modes..........................
Setting Associated Local and Remote CPGs for Remote-Copy Groups......................................153 Automatically Creating Target Volumes on the Secondary System...........................................154 Automatically Deleting Target Volumes on the Secondary System............................................154 Coordinated Manual Grow over Remote Copy....................................................................155 Configuring ESX Host Personas.................................................
Second Primary System (System3).............................................................................183 System Information during Failover for N-to-1 Configurations.............................................184 Synchronous Mode for N-to-1 Configurations..............................................................184 Asynchronous Periodic Mode for N-to-1 Configurations................................................184 Example Output after Primary System Failure for N-to-1 Configurations..........
27 Using Remote Copy Commands..........................................................261 About the Remote-Copy Commands...................................................................................261 Issuing Remote-Copy Commands.......................................................................................262 28 HP 3PAR Quorum Witness Deployment................................................263 Starting the vSphere Client.....................................................................
Figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 Unidirectional 1-to-1 Remote Copy......................................................................................16 Bidirectional 1-to-1 Remote Copy........................................................................................17 N-to-1 Remote Copy.............................................................................................
53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 Handling Failover..........................................................................................................144 Communication Failure—Array to Array............................................................................145 Communication Failure—Site 1 to Quorum Witness............................................................145 Communication Failure—Site 1 to Quorum Witness and Site 1 to Site 2...............................
Part I Setting the Foundation for Remote Copy 1. Plan your setup strategy. “Planning Your Remote-Copy Setup Strategy” (page 13) 2. Select a remote-copy configuration. “Selecting a Remote-Copy Configuration” (page 16) 3. Select a network connection type. “Selecting Network Connections” (page 23) 4. Review the requirements and restrictions to make sure the system is prepared for remote-copy configuration.
1 Planning Your Remote-Copy Setup Strategy Setup Instructions and Resources Depending on your comfort level and familiarity with HP 3PAR Remote Copy Software, use the following resources to help you set up your remote-copy system: New User If you are setting up HP 3PAR Remote Copy for the first time: • Follow the setup steps, as they relate to your remote-copy system, in “Setting the Foundation for Remote Copy” (page 12), and “Setting Up the Remote Copy Servers” (page 39), of this user’s guide.
General Considerations • • Distance between the systems. ◦ Systems in the same room can be connected through Gigabit Ethernet (GigE) switches, or through FC networks. Longer distances require other topologies. ◦ To use remote copy for disaster recovery, the backup storage system should be kept at a remote site far enough away that the two sites are unlikely to be affected by the same disaster. ◦ In synchronous replication mode, the latency of remote-copy writes increases with distance. Bandwidth.
Remote Copy and Virtual Domains HP 3PAR Remote Copy checks for the presence of HP 3PAR Virtual Domains Software (domains) on the backup system to verify that you have mirrored the virtual volume to the same backup system domain name as the primary-system domain name. If a virtual domain is required, define it when you create a remote-copy group by using the creatercopygroup command: # creatercopygroup -domain domain1 group_name target:periodic For remote copy to operate, you must name the domain correctly.
2 Selecting a Remote-Copy Configuration Review the remote-copy configurations and select the configuration that is best suited for your system. • “Unidirectional 1-to-1 Configuration” (page 16) • “Bidirectional 1-to-1 Configuration” (page 16) • “N-to-1 Configuration” (page 17) • “1-to-N Configuration” (page 18) • “Synchronous Long Distance Configuration” (page 20) Remote-copy configurations are based on the relationship between a pair of storage systems, known as the remote-copy pair.
Figure 2 Bidirectional 1-to-1 Remote Copy N-to-1 Configuration An N-to-1 remote-copy configuration is composed of multiple remote-copy pairs. A maximum of four primary storage systems use the same backup storage system. NOTE: Because the backup system participates in one remote-copy pair for each primary system, a backup system with one or two primary systems needs only two controller nodes. A backup system with three or more primary storage systems must have four or more controller nodes.
Figure 3 (page 18) illustrates an N-to-1 configuration where: • Bidirectional remote copy is maintained between remote-copy pair System3 and System4. Unidirectional remote copy is maintained between System1 and System4 and between System2 and System4. Figure 3 N-to-1 Remote Copy 1-to-N Configuration A 1-to-N remote-copy configuration is composed of multiple remote-copy pairs. A single primary storage system can use a maximum of four backup storage systems.
Figure 4 1-to-N Remote Copy M-to-N Configuration In an M-to-N remote-copy configuration, bidirectional data replication takes place in a 4x4 fan-in, fan-out configuration. Data replication occurs without the need for dedicated remote-copy pairs. The transport layer can be RCFC, RCIP, or FCIP, or a mixture of these, with up to five links per node. Only one RCIP link per node is possible; the other links may be RCFC or FCIP.
Figure 5 M-to-N Remote-Copy Configuration—Example Synchronous Long Distance Configuration A synchronous long distance (SLD) remote-copy configuration is composed of two targets: one synchronous group and one asynchronous periodic group. In SLD remote copy, one primary system uses two backup systems and participates in two remote-copy pairs, one for each backup system. In an SLD configuration, remote copy volume groups from the primary system are replicated to the two separate target arrays simultaneously.
SLD configurations differ from 1-to-N configurations as follows: • In SLD configurations, remote-copy volumes on the primary system are in a remote-copy relationship with two secondary volume groups. Virtual volumes in the primary system are included in two primary groups, one copied to a backup system in synchronous mode, and one copied to the other backup system in asynchronous periodic mode. The two primary groups can be started and stopped independently of each other.
Because SLD configurations include a standby link, as illustrated in Figure 6 (page 21), this configuration allows for multiple backup and recovery scenarios during a failover.
3 Selecting Network Connections 1. Review possible network connections. • “IP Networks” (page 23) • “Fibre Channel Networks” (page 24) • “Fibre Channel over IP Networks” (page 24) 2. Review general network information for remote copy. “Requirements” (page 13) Storage systems in a remote-copy pair are connected through a dedicated link or through a network, as illustrated in Figure 7 (page 23).
Fibre Channel Networks RCFC can be set up only on storage systems that communicate over FC storage area networks (FC SAN). • Be sure you understand the FC SAN that is used to connect the storage systems. • Remote-copy systems must be configured to be in the same FC SAN and zone. Each storage system should have a pair of host bus adapters (HBAs) installed for load sharing and fault tolerance. • Prior to HP 3PAR OS 3.1.
4 Gathering Setup Information 1. Contact your network administrator to obtain: • IP addresses or 64-bit World Wide Name (WWN) address information for the interfaces of the storage systems • Gateway IP addresses, netmask, and IP addresses for each link • Any additional details about the network connections that might be useful 2. Verify that the firewall settings allow the remote-copy systems access to TCP port 5785. 3. Use the provided worksheets to organize the data.
5 Setting the Transport Layer Review transport layer requirements. “Transport Layer Considerations” (page 26) Set the transport layer.
Storage and HP 3PAR 10000 StoreServ Storage systems, individual ports can be configured for RCFC. Remote-copy links in asynchronous periodic mode do not have to be dedicated to remote copy, and can be shared with other traffic, but this is not recommended. The remote-copy links in synchronous mode require guaranteed bandwidth over dedicated remote-copy links. RCFC over IP network connections are allowed only for remote copy in asynchronous periodic mode.
Figure 10 Network and RCIP Setup—Example Initial-Pair Worksheet RCIP Additional Remote-Copy Pairs Worksheet Figure 11 (page 29) is a worksheet for setting up additional remote-copy pairs over RCIP.
Figure 11 Network and RCIP Setup Information—Example Additional Pairs Worksheet Setting Up Remote Copy over IP 29
Configuring Ports for RCIP For RCIP configurations, each link between a remote-copy pair is a logical link between a controller node on one storage system and a controller node on the other storage system in the pair. These links use a GigE port from each of the nodes in the storage systems that belong to the remote-copy pair. RCIP configurations can use up to eight links between systems. Up to eight nodes can each have one GigE port contributing links to an RCIP remote-copy pair.
4. 5. Repeat Step 1 through Step 3 for each Ethernet port on each HP 3PAR StoreServ Storage used in the remote-copy configuration. Issue the following command on each system: # showport -rcip 6. Compare the IP addresses and netmask with your RCIP worksheet(s). For example: N:S:P State ---HwAddr--IPAddr Netmask Rate Duplex AutoNeg 0:3:1 ready 000423CBF68C 10.100.24.107 255.255.255.0 1Gbps Full Yes 1:3:1 ready 000423CBF693 10.101.24.107 255.255.255.
Verifying That the Servers Are Connected Perform the following steps to verify that the servers are connected: 1. Issue the following command: # controlport rcip ping where: • —Interface from which to ping, expressed as node:slot:port • —IP address on the target system to ping For example: # controlport rcip ping 10.101.24.108 0:3:1 PING 10.101.24.108 (10.101.24.108) from 10.100.24.107 : 56(84) bytes of data. 64 bytes from 10.101.24.108: icmp_seq=1 ttl=253 time=0.
Checking RCIP Link Throughput and Latency By default, the cli checkrclink command uses port 5001. There is, however, an optional parameter that allows you to specify a different port number: # checkrclink startclient
1. Issue the controlport rcip mtu command: # controlport rcip mtu 9000 where represents the location of the GigE port, expressed as node:slot:port, and the MTU value specified is the same value returned by the cli checkrclink command for Max MTU. 2. 3. Repeat the command for all remote-copy GigE ports on each storage system.
Figure 12 Network and RCFC Setup To configure an RCFC transport layer, use the worksheet in Figure 13 (page 35) Figure 13 Network and RCFC Setup Information—Example Worksheet Configuring Ports for RCFC For RCFC configurations, each link between a remote-copy pair is a physical link between a controller node on one storage system and a controller node on the other storage system in the pair.
To configure the ports, use the controlport rcfc command. CAUTION: shared. Each pair of RCFC links must exist in an exclusive zone. Fabric zones cannot be Setting Up Dedicated Node Pairs for RCFC Verify that each FC interface on each node on the primary remote-copy system connects to a dedicated FC interface on each node on the backup remote-copy system. RCFC requires a dedicated node pair for each backup system, as shown in Figure 14 (page 36).
2. Issue the following command: # controlport config rcfc -ct point -f where: 3. 4. 5. • -ct point—point-to-point mode. • —FC adaptor port, expressed as node:slot:port. Record the port positions in the “RCFC Remote-Copy Pair Worksheet” (page 34) worksheet. Repeat Step 2 through Step 3 for each port on each system in the remote-copy configuration. To verify that the FC communication links have been established, issue the showrctransport -rcfc command.
Checking RCFC Link Throughput and Latency CAUTION: Do not check the links if CPU usage is already close to 100%. The link check temporarily increases CPU usage. To view statistics for CPU usage from all nodes, issue the statcpu command. Follow these steps to check links: 1. Ensure that the systems are not displaying signs of saturation. 2.
Part II Setting Up the Remote-Copy Servers To set up: See the following: M-to-N remote copy “Setting Up N-to-1 Remote Copy” (page 40) • 1-to-1 remote copy • N-to-1 remote copy • 1-to-N remote copy SLD remote copy “Setting Up Synchronous Long Distance Remote Copy” (page 56) For additional information, see the following: • “Setting Up a Unidirectional Configuration” (page 76) • “Setting Up a Bidirectional Configuration” (page 86) • “Using Tape for Initial Synchronization and Backup” (page 151) •
6 Setting Up M-to-N Remote Copy 1-to-1 Remote Copy Follow these guidelines for setting up 1–to-1 remote copy. To set up 1-to-1 remote copy in a unidirectional configuration: 1. Verify that your setup plan meets the remote-copy requirements. See: • “Requirements” (page 13) 2. Review the basic 1-to-1 setup and with the example Figure 18 (page 46) (basic 1-to-1 setup) remote-copy pair used to illustrate unidirectional setup.
Table 2 Setting up N-to-1 Remote Copy Step For information, see... 1. Verify that your setup plan meets the N-to-1 requirements. “Requirements” (page 13) 2. Review the basic N-to-1 setup and with the example remote-copy pair used to illustrate setup. Figure 16 (page 44) (basic N-to-1 setup) 3. Verify connectivity between the remote-copy pair you plan to configure. “Verifying Connectivity between Remote-Copy Pairs for M-to-N Setup” (page 48) 4.
Table 3 1-to-N Remote Copy Step For information, see... 1. Verify that your setup plan meets the 1-to-N requirements. “Requirements” (page 13) 2. Review the basic 1-to-N setup and the example remote-copy pair used to illustrate setup. Figure 20 (page 48) (basic 1-to-N setup) 3. Set up a unidirectional configuration for the first remote-copy pair and start initial data replication for the primary volume groups. “Setting Up a Unidirectional Configuration” (page 76) 4.
synchronous/asynchronous periodic 1-to-1 remote-copy configuration is 2400 volumes in all (not 2400 volumes for synchronous mode and 6000 volumes for asynchronous periodic mode). • For HP 3PAR F-Class and T-Class storage systems, the maximum number of replicated volumes on a mixed synchronous/asynchronous periodic 1-to-1 remote-copy configuration is 800 volumes in all (not 800 volumes for synchronous mode and 2400 volumes for asynchronous periodic mode).
Figure 16 N-to-1 Remote-Copy Configuration In an N-to-1 remote-copy configuration: • All of the remote-copy pairs can be bidirectional. • You can use RCIP, RCFC, or FCIP connections with N-to-1 remote-copy configurations. • For a 2:1 configuration using RCIP, the target requires a minimum of two nodes. For a 3:1 or 4:1 configuration using RCIP, the target requires four nodes. • If you are using FCIP or RCFC, the target requires two nodes for every source node replicating to it.
Figure 17 1-to-N Remote-Copy Configuration In a 1-to-N remote-copy configuration: • Primary systems with only two controller nodes must be one of the following storage systems: ◦ HP 3PAR StoreServ 10000 Storage ◦ HP 3PAR StoreServ 7000 Storage ◦ HP 3PAR T-Class ◦ HP 3PAR F-Class • You can use both RCIP and RCFC connections with 1-to-N remote-copy configurations. • For RCFC configurations, primary storage systems must have at least two controller nodes.
Figure 18 Unidirectional 1-to-1 Remote-Copy Pair—Example Example primary system Example backup system System name System1 System2 System ID 112 125 Nodes eight (only two are shown) four (only two are shown) Nodes dedicated to remote copy 0 and 1 2 and 3 Links Node 0: IP address XXX.XX.1.10 Node 2: IP address XXX.XX.2.10 Node 1: IP address XXX.XX.1.11 Node 3: IP address XXX.XX.2.11 Target system System2 System1 Target Interface IP Node 0: XXX.XX.1.10 Node 2: XXX.XX.2.10 Node 1: XXX.
Figure 19 N-to-1 Remote-Copy Configuration—Example Example primary system Example backup system System name System1 System2 System ID 112 125 Nodes eight (only two are shown) four (only two are shown) Nodes dedicated to remote copy 0 and 1 2 and 3 Target system System2 System1 Links IP address XXX.XX.1.10 IP address XXX.XX.2.10 IP address XXX.XX.1.11 IP address XXX.XX.2.
Figure 20 Example 1-to-N Remote-Copy Configuration One of the remote-copy pairs can be bidirectional, and the other can be unidirectional. Both remote-copy pairs can also be bidirectional, and both pairs can operate in synchronous mode, as shown in Figure 20 (page 48). Verifying Connectivity between Remote-Copy Pairs for M-to-N Setup Use the following commands to verify connectivity for the remote-copy pair you are configuring.
• —Location on the current system (System1) that contains the IP connections to the target system, expressed as node:slot:port • —Link IP address for the corresponding port on the target system (for example, XXX.XX.1.10 or XXX.XX.1.11).
where: • —Name of the target system (System1) • FC—Defines link as an FC link • —WWN of the node on the target system • —FC adapter port on the primary system (System2), expressed as node:slot:port, and the WWN of the peer port on the current system (System1) Checking the Links between Systems for M-to-N Remote Copy Follow these steps to check links between systems. 1.
3. Repeat Step 1 and Step 2 on the primary system (System1). Problem Solution You encounter problems 1. Use the dismissrcopylink command to remove the links: with the links. • RCIP: dismissrcopylink : • RCFC: dismissrcopylink 2. Repeat the setup from “Setting Up the Primary System for Unidirectional Remote Copy” (page 78). Verifying That Virtual Volumes Are Created for M-to-N Remote Copy 1.
1. Issue the following command to set up a volume group on the primary storage system (System1): # creatercopygroup : where: • —Name of the volume group (Group1) • —Name of the target system (System2) • mode—Specifies asynchronous periodic mode For more information, see “Volume Group Modes” (page 120). The creatercopygroup command creates the following: • A primary volume group (Group1) on the primary system (System1).
3.
Selecting an Initial Replication Method for M-to-N Remote Copy Select the method to use to start replicating the data in the primary volume groups: • Direct replication Copy data directly from the virtual volumes in the primary volume group to the virtual volumes in the secondary volume group. • “Selecting an Initial Replication Method for M-to-N Remote Copy” (page 54) Through tape. Using tape for the initial backup can be faster if you are copying very large volumes. 1.
Name Target Status sync_group_1 System2 Started LocalVV ID RemoteVV localvv.0 391 remotevv.0 localvv.1 392 remotevv.1 4. Role Mode Primary Sync ID SyncStatus 351 Synced 352 Synced Options LastSyncTime NA NA Problem Solution The initial synchronization fails. Repeat from Step 1. Repeat the steps in “Starting Initial Replication for M-to-N Remote Copy” (page 54) for all primary volume groups on the primary system.
7 Setting Up SLD Remote Copy 1. Verify that your setup plan meets the SLD requirements. “Requirements” (page 13) “SLD Remote-Copy Considerations” (page 56) 2. Review the SLD setup. “SLD Remote-Copy Example” (page 62) 3. Verify connectivity between the remote-copy pairs you plan to configure. “Verifying Connectivity between Remote-Copy Pairs for SLD Setup” (page 57) 4. Set up the primary and backup systems (the remote-copy “Setting Up the Primary System for SLD Remote Copy” pairs) and check the links.
• With HP 3PAR OS 3.1.3 and later, you can create four target systems per source system. • If you are using two-node systems for your SLD configuration: ◦ You can use HP 3PAR T-Class, F-Class, StoreServ 10000, or StoreServ 7000 Storage systems. ◦ One pair of connections on a node pair must be set up in synchronous mode and one pair of connections on the other node pair must be set up in asynchronous periodic mode.
• ◦ —WWN of the target node (node 2FF70002AC0000C3 on SystemB). ◦ :—FC adapter port on the primary system (SystemA), expressed as node:slot:port, and the WWN of the peer port on the target system (SystemB) (0:1:1:20210002AC0000C3 and 1:3:2:21210002AC0000C3). For RCIP: # creatercopytarget IP : : where: 58 ◦ —Name of the remote-copy target system (SystemB). ◦ IP—Specifies an IP link.
3. To define the targets for the asynchronous periodic backup system (SystemC) on the primary system (SystemA), issue the following command on the primary system (SystemA): • For RCFC: # creatercopytarget FC : : where: • ◦ —Name of the remote-copy target system (SystemC). ◦ FC—Specifies a FC link. ◦ —WWN of the target node (node 2FF70002AC0000C3 on SystemC).
2. Define a target (for example, the primary system SystemA) on the backup system. On the backup system (SystemB), issue the following command: • For RCFC: # creatercopytarget FC : : where: • ◦ —Name of the remote-copy target system (SystemA). ◦ FC—Specifies a FC link. ◦ —WWN of the target node (node 2FF70002AC000060 on SystemA).
where: 4. • —Name of the remote-copy target system (SystemC). • IP—Specifies an IP link. • :—Node on the backup system (SystemB) that contains the IP connections to the target system, expressed as node:slot:port, and the IP address for the target system (SystemC) (2:4:1:10.100.33.63 and 3:4:1:10.101.33.63). To start HP 3PAR Remote Copy on the other backup system (SystemC), issue the following command: # startrcopy 5.
6. Define a second target system (for example, the synchronous backup system SystemB) for the current backup system.
Figure 21 SLD Remote-Copy Configuration—Example Example primary system Example backup system 1 Example backup system 2 System name SystemA SystemB SystemC Nodes four four four System ID 96 195 63 Three secondary virtual volumes: Three secondary virtual volumes: • testvv.B.0 • testvv.C.0 • testvv.B.1 • testvv.C.1 • testvv.B.2 • testvv.C.2 One secondary volume group (testgroup.r96) One secondary volume group (testgroup.
The primary system and backup system 1 (SystemA and SystemB) are located near each other. • SystemA and SystemB are connected through RCFC or RCIP. • Replication between SystemA and SystemB is in synchronous mode.
2. Verify the following: • The Target Information area shows a Status of ready. • The Link Information area shows a Status of Up for all the links. The following example shows the showrcopy command output for SystemA: Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemB 6 FC ready 2FF70002AC0000C3 mirror_config SystemC 7 IP ready mirror_config Link Information Target SystemB SystemB SystemC SystemC receive receive receive receive 3.
4. Repeat Step 1 and Step 2 on the other backup system (SystemC). The following example shows the showrcopy command output for SystemC: Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 3 IP ready mirror_config SystemB 4 IP ready mirror_config Link Information Target SystemA SystemA SystemB SystemB receive receive Node 2:4:1 3:4:1 2:4:1 3:4:1 2:4:1 3:4:1 Address 10.100.33.96 10.101.33.96 10.100.33.195 10.101.33.
1. Create a volume group on the primary system (SystemA): # creatercopygroup :sync :periodic where: • —Name of the volume group (testgroup). • —Name of the target systems (SystemB and SystemC). • sync | periodic—sync for synchronous mode and periodic for asynchronous periodic mode. SLD configurations require one target system to be in sync mode and the other target system to be in asynchronous periodic mode.
2. On the primary system (SystemA), add the pre-existing virtual volumes to the newly created volume group. Issue either of the following commands: # admitrcopyvv where: • —Name of the virtual volume (testvv.A.
Starting Initial Replication for SLD Remote Copy: Copying Data Directly from Primary Volume Groups Follow these steps to start initial replication: 1. To start replication from the primary volume group to the secondary volume groups on SystemB and SystemC, issue the following command from the primary system (SystemA): # startrcopygroup where represents the name of the primary volume group (testgroup). The startrcopygroup command, when run on a group for the first time: 2.
3. On all three systems, verify that the SyncStatus column in the Group Information area displays Synced. The following example shows the showrcopy groups command output for SystemA: Group Information Name Target Status testgroup SystemB Started LocalVV ID RemoteVV testvv.A.0 100 testvv.B.0 testvv.A.1 101 testvv.B.1 testvv.A.2 102 testvv.B.2 Name Target Role Mode Primary Sync ID SyncStatus 200 Synced 201 Synced 202 Synced Status testgroup SystemC Started PDT , over_per_alert LocalVV ID RemoteVV testvv.
Failover and Failback Behavior of Individual Remote-Copy Groups in SLD Configuration Individual remote-copy groups can be failed over without forcing a full array failover. Failover of individual remote-copy groups is illustrated in the following sections.
Figure 23 Failure of an Individual Volume Group in SLD Remote-Copy Configuration SystemA fails over to SystemB.
between SystemB and SystemA, and in asynchronous periodic mode from SystemB to SystemC, as shown in Figure 25 (page 73). Figure 25 SystemA Becomes the Secondary-Reverse System To restore normal operation, the setrcopygroup restore command is issued. SystemA becomes the primary system; SystemB becomes the secondary system, and SystemC becomes the secondary backup system. The backup link between SystemB and SystemC is once again inactive, because the system is running normally (see Figure 22 (page 71)).
Figure 26 SystemA-to-SystemC Failover After all updates have been sent to SystemC, SystemB then reverts to being the secondary system. After SystemC receives the update from SystemB, it becomes the primary-reverse system and continues to synchronize with SystemB in asynchronous periodic mode, as shown in Figure 27 (page 74).
When the setrcopygroup recover command is issued, SystemA comes back online and is now the secondary-reverse system, receiving updates from SystemC in asynchronous periodic mode (while SystemB is also receiving updates from SystemC), as shown in Figure 28 (page 75). Figure 28 SystemA Becomes Secondary-Reverse System When the setrcopygroup restore command is issued, SystemA again becomes the primary system; it is resynchronized from SystemC to be up to date, and then synchronizes with SystemB as usual.
8 Unidirectional Configuration Follow these guidelines to set up a unidirectional configuration: 1. Verify that your setup plan meets remote-copy requirements. See: 2. • “Requirements” (page 13) • “N-to-1 Remote-Copy Considerations” (page 43) • “1-to-N Remote-Copy Considerations” (page 44) • “SLD Remote-Copy Considerations” (page 56) Review the basic unidirectional setup. See “Example Unidirectional Remote-Copy Setup” (page 76) 3.
Figure 29 Unidirectional Remote-Copy Configuration—Example Example primary system Example backup system System name System1 System2 System ID 112 125 Nodes eight (only two shown) four (only two shown) Nodes dedicated to remote copy 0 and 1 2 and 3 Target system System2 System1 Links IP address XXX.XX.1.10 IP address XXX.XX.2.10 IP address XXX.XX.1.11 IP address XXX.XX.2.
• For RCFC remote-copy pairs: # showrctransport -rcfc For more information, see “Verifying That the Servers Are Connected” (page 32). Setting Up the Primary System for Unidirectional Remote Copy Follow these steps to set up the primary system: 1.
2. To define a target on the primary storage system (System1), issue the following command: • For RCIP: # creatercopytarget IP : : where: • ◦ —Name of the target system (System2). ◦ IP—Defines link as an IP link ◦ —Location on the current system (System1) that contains the IP connections to the target system, expressed as node:slot:port.
2.
The following example shows the showrcopy command output for System2: Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy System1 112 IP ready mirror_config Link Information Target System1 System1 receive receive 3. Node 0 1 0 1 Address 10.100.24.108 10.101.24.108 10.100.24.108 10.101.24.108 Status Options Up Up Up Up Repeat Step 1 and Step 2 on the primary system (System1).
Creating Volume Groups for Unidirectional Remote Copy Remote-copy volume groups are pairs of virtual volume sets that are logically related and that are used when data needs to be consistent between specified sets of virtual volumes. For more information, see “Working with Volume Groups” (page 110). NOTE: You can create groups and add volumes to groups without disrupting host access to volumes. 1.
where: • s|m|h|d—Synchronization time period (time between start of resynchronizations), followed by time unit: s (seconds), m (minutes), h (hours), or d (days) • —Name of the target system (System2) • —Name of the primary volume group (Group1) or: # setrcopygroup period -pat s|m|h|d where represents the pattern of volume group names (for example, Group*). 3.
Selecting an Initial Replication Method for Unidirectional Remote Copy Select the method for replicating the data in the primary volume groups: • Direct replication. Copy data directly from the virtual volumes in the primary volume group to the virtual volumes in the secondary volume group. • “Starting Initial Replication for Unidirectional Remote Copy: Copying Data Directly from Primary Volume Groups” (page 84) Through tape.
4. Repeat the steps in “Starting Initial Replication for Unidirectional Remote Copy: Copying Data Directly from Primary Volume Groups” (page 84) for all primary volume groups on the primary system.
9 Bidirectional Configuration 1. Verify that your setup plan meets the remote-copy requirements. See: • “Requirements” (page 13) • “N-to-1 Remote-Copy Considerations” (page 43) • “1-to-N Remote-Copy Considerations” (page 44) • “SLD Remote-Copy Considerations” (page 56) 2. Review the basic bidirectional setup. “Example Bidirectional Setup” (page 86) 3. Set up the unidirectional configuration for the remote-copy pair. “Setting Up a Unidirectional Configuration” (page 76) 4.
Figure 30 Bidirectional Remote-Copy Configuration—Example Example primary system Example backup system System name System2 System1 System ID 125 112 Target system System1 System2 Virtual volumes and volume groups • Unidirectional setup • Unidirectional setup (System1 —> System2): (System1 —> System2): One secondary volume group (Group1.
Setting Up the Systems for Bidirectional Remote Copy In bidirectional remote copy, the backup system (System2) also contains primary volume groups and therefore is also considered a primary system for the purposes of the primary volume groups it contains. Verify that unidirectional 1-to-1 remote copy is already set up. • If unidirectional 1-to-1 remote copy is set up, the required links between the remote-copy systems already exist.
3. (Optional). If you are creating a volume group that uses periodic mode, you can set up automatic synchronization. CAUTION: Do not set a resynchronization period at this point if you plan to perform the initial synchronization and backup using tape. For more information, see “Using Tape for Initial Synchronization and Backup” (page 151).
4.
• Through tape. Using tape for the initial backup can be faster if you are copying very large volumes. 1. Copy data in the virtual volumes in the primary “Using Tape for Initial Synchronization and volume group to tape first. Backup” (page 151) 2. To fully synchronize the primary and backup systems, copy the data to the virtual volumes in the secondary volume group.
Part III Managing Remote Copy For information about: See the following: Viewing configuration and synchronization details, statistics, and recovery progress after failover “Viewing Remote Copy System Information” (page 95) Setting the policies for automatic restarts and synchronization alerts “Setting Volume Group Policies” (page 118) Changing modes, synchronizing, changing target groups to source, stopping and restarting, and removing remote copy “Performing Manual Operations” (page 93) Using volum
10 Stopping, Starting, or Removing Remote Copy Manual Operation Command For more information Stop and restart remote copy groups stoprcopygroup “Stopping and Restarting Remote Copy” (page 94) startrcopygroup Stop and restart remote copy “Stopping and Restarting Remote Copy” (page 94) stoprcopy startrcopy Erase the remote-copy configuration “Removing Remote Copy Completely” (page 94) stoprcopy Problem Solution If the mirror system does not respond to a command after 5 minutes (the timeout limit
Stopping and Restarting Remote Copy To stop remote copy temporarily, issue the following command: # stoprcopy -stopgroups To restart remote copy, issue the following command: # startrcopy NOTE: The startrcopy command starts HP 3PAR Remote Copy, but does not restart the volume groups. To restart all remote-copy volume groups, see “Stopping and Starting Remote-Copy Groups” (page 93). Removing Remote Copy Completely WARNING! reversible.
11 Viewing Remote-Copy System Information Description Command: For more information: Configuration details showrcopy Link throughput and latency statistics “About the Remote-Copy Commands” (page 261) statrcopy Virtual volume statistics (such as I/O number, size, and completion time) statrcvv Histogram of remote-copy volume statistics histrcvv Problem Solution If the mirror system does not respond to a command after 5 minutes (the timeout limit), the following error message appears: Ensure tha
To verify that a resynchronization took place, check the tasks by using the showtask command. For information about using the showtask command, see “Viewing Synchronization Task Information” (page 96). Tracking Asynchronous Periodic Volume Groups For asynchronous periodic mode volume groups, the startrcopygroup command starts synchronization only the first time the command is issued for a volume group.
• Step—For active remote-copy synchronization tasks, indicates the completed and total volume size in MB, in the following format: / • Start Time—Time the task was started. • Finish Time—For Done, Cancelled, and Failed tasks, the time the task stopped because of completion, cancellation, or failure.
Task Management Commands for Remote-Copy Synchronizations Table 4 Task Management Commands Command Description Domain: Privilege Level removetask Removes information about one or more tasks and their details. all: Super, Edit, Service showtask Displays information about tasks on the system. all: Super, Edit, Browse specified: Edit, Browse none: Service waittask Forces the CLI to wait for a task to complete before proceeding.
12 Remote-Copy Pairs and Targets For more information about: See the following: The foundational remote-copy system relationship “Remote-Copy Pairs” (page 99) Why remote copy uses targets “Overview of Targets” (page 99) How to determine the target definition for a system or volume group “Target Definitions” (page 99) The target system, and data flow between systems under various circumstances “Remote-Copy Target System” (page 100) Remote-Copy Pairs Remote-copy configurations and operations are bas
This relationship between target definitions and remote-copy system pairs is true for all valid remote-copy configurations: • unidirectional • bidirectional • M-to-N • SLD For the system that contains the primary volume groups (the primary system), the target system is the same as the backup system. For the system that contains the secondary volume groups (the backup system), the target system is the same as the primary system.
System Roles and Direction of Data Flow Under normal operating conditions, the natural direction of data flow is from the primary volume group to the secondary volume group. HP 3PAR remote copy replicates data from primary volume groups, which you name, and which are kept on the primary system, to secondary volume groups, which HP 3PAR Remote Copy names, and which are kept on the backup system.
13 Remote-Copy Links Remote-copy links are divided into two main types: sending links and receiving links. You create links during remote-copy setup by using either the creatercopytarget command or the admitrcopylink command. For more information, see “Setting Up a Unidirectional Configuration” (page 76). When you create a link, it becomes both a sending and receiving link for the port specified in the command.
Figure 32 Supported Sending-Link Connections Links per Remote-Copy Pair When you set up remote-copy links between a remote-copy pair, you must create one set of sending links on the primary system and one set of sending links on the backup system (Figure 33 (page 104)).
Figure 33 Sending Links for a Remote-Copy Pair—Example For additional information, see the following: • “Setting Up the Primary System for Unidirectional Remote Copy” (page 78) • “Setting Up the Backup System for M-to-N Remote Copy” (page 49) Links per Multiple Remote-Copy Pairs If your remote-copy configuration involves more than one remote-copy pair (N-to-1, 1-to-N, M-to-N, or SLD), you must create sending links on each system for all the remote-copy pairs in the configuration.
14 Working with Virtual Volumes Description Command For more information Review virtual volume requirements. “Creating Remote-Copy Virtual Volumes” (page 105) Convert a virtual volume for remote copy use and assign it to a CPG setvv -snp_cpg “Converting Standard Virtual Volumes” (page 106) Increase virtual volume size. growvv “Growing Virtual Volumes” (page 107) Rename a virtual volume. setvv -name “Renaming Virtual Volumes” (page 108) • “Common Provisioning Groups” (page 108) 3. Create a CPG.
modified. To create target volumes automatically, use the admitrcopyvv -createvv command. See: Automatically Creating Target Volumes on the Secondary System HP 3PAR Command Line Interface Administrator’s Manual • Virtual volumes used with HP 3PAR Remote Copy must be one of the following types: ◦ Thinly-provisioned virtual volumes (TPVVs) with snapshot space drawn from a CPG. TPVVs require the use of HP 3PAR Thin Provisioning Software. ◦ Fully provisioned virtual volumes (FPVV).
2. Convert the standard virtual volume to an FPVV and assign it to a CPG by issuing the following command: # setvv -snp_cpg where: • —Name of the CPG to assign to the virtual volume and from which snapshot space is to be allocated. • —Name of the virtual volume to convert into an FPVV for use with remote copy. Growing Virtual Volumes Follow these steps to grow a virtual volume: 1.
Renaming Virtual Volumes To rename a virtual volume, issue the following command: # setvv -name where: • —New name you are assigning to the virtual volume • —Virtual volume to rename Virtual Volumes and CPGs To create virtual volumes for remote copy: For more information, see: 1. Create a CPG. • “Common Provisioning Groups” (page 108) • HP 3PAR Command Line Interface Administrator's Manual 2.
When volumes draw additional space from the CPG, the volumes become larger and require additional storage space. To expand a volume’s storage space, the system automatically creates additional logical disks and adds them to the CPG. This expansion continues as necessary until the CPG reaches its specified allocation limit. FPVVs The system cannot allocate space on demand to FPVVs. The system can only allocate space on demand to snapshots of these volumes.
15 Working with Volume Groups For more information about: See the following: What volume groups are and why remote copy uses them “Why Use Volume Groups” (page 110) How remote copy operates on virtual volumes in a volume “How Volume Groups Work” (page 111) group Volumes you can add to volume groups “Rules for Forming Volume Groups” (page 112) “Rules for Adding Snapshots to Volume Groups” (page 112) How HP 3PAR Remote Copy names the secondary volume “Natural Direction of Replication” (page 113) group Whe
How Volume Groups Work HP 3PAR Remote Copy functions as if the virtual volumes in a volume group are related and therefore ensures that the data in the virtual volumes within a volume group maintain write consistency. When you start or stop remote-copy operations, HP 3PAR Remote Copy starts and stops operations for the whole volume group.
Rules for Forming Volume Groups The group of virtual volumes in a remote-copy volume group: • Must be located on the same storage system. • Can be logically related. • Can be volumes for which there is a cross-volume ordering of writes. • Must not exceed the maximum (300).
Natural Direction of Replication The natural direction of remote-copy replication is from the primary volume group to the secondary volume group (from the primary system to the backup system). Linking Virtual Volumes in Volume Groups As long as a secondary virtual volume is the same size as the primary volume, you can map any primary virtual volume to any secondary volume in the secondary volume group.
Figure 35 Volume Mapping between Bidirectional Primary and Backup Systems Changing the Remote-Copy Mode for a Volume Group For most remote-copy configurations, you can have only one mode per target system, synchronous or asynchronous periodic, for all primary volume groups on the primary system. 1. Stop the primary volume group on the primary system. (Resynchronization snapshots remain on the system.
where represents the pattern of volume group names (for example, Group*). 3. To start the primary volume group, issue either of the following commands: # startrcopygroup or: # startrcopygroup -pat where represents the pattern of volume group names to start (for example, Group*). 4.
Synchronous Mode • In synchronous mode, you must specify the -orvd option to manually force a full synchronization between volume groups in synchronous mode even if the volumes are already synchronized. This option is also relevant for synchronous mode volume groups that have become inconsistent. Issue either of the following commands: # syncrcopy -ovrd or: # syncrcopy -ovrd -pat where represents the pattern of volume group names (for example, Group*).
Changing Secondary Volume Groups to Primary If a primary system or primary volume fails, you can change secondary volume groups to primary volume groups to aid in disaster recovery.
Setting Volume Group Policies Policy Description For more information: Automatically restart after certain types of failure by using “Automatically Restarting Volume Groups” (page 119) the auto_recover policy setting. Never automatically restart (default) by using the no_auto_recover policy setting. Configure automatic failover on a remote-copy group by using the auto_failover policy setting.
Automatically Restarting Volume Groups By default, remote-copy volume groups do not restart automatically.
• To return the volume groups to the default policy and generate alerts for asynchronous periodic resynchronizations that do not complete within the synchronization period, set the volume groups to the over_per_alert policy by issuing either of the following commands: # setrcopygroup pol over_per_alert or: # setrcopygroup pol over_per_alert -pat Volume Group Modes For information about: See the following: Comparison of the two types of modes “Overview of Volume Group Modes” (pag
6. After the active cache update on the primary system is complete and the primary system receives the backup system’s acknowledgment, the primary array sends an acknowledgment of the write to the host. I/O to the host is complete. Figure 36 Remote Copy in Synchronous Mode Advantages of Synchronous Mode • Even if the primary system, the backup system, or the communication links go down, both storage systems contain all the data for I/O that has already been acknowledged to the server.
1. 2. 3. The host sends a write request to the primary system. As soon as the data is written into cache on the primary system, HP 3PAR Remote Copy acknowledges the host write.
For additional information, see the following: • “Working with Volume Groups” (page 110) • “Volume Group Modes” (page 120) Types of Synchronization Remote copy performs one of two types of synchronization on volume groups: Type of Synchronization Functionality full synchronization HP 3PAR Remote Copy copies the entire primary volume. resynchronization HP 3PAR Remote Copy copies only the data that has changed since the previous synchronization.
3. When it is time to perform a resynchronization between the primary and secondary remote-copy groups, HP 3PAR Remote Copy creates snapshots as described in Figure 38 (page 124). For more information about this process, see “Volume Group Modes” (page 120). Figure 38 Snapshot Creation before Resynchronization (Asynchronous Periodic Mode) 4.
4. Saves the active snapshot, which enables HP 3PAR Remote Copy to perform a fast resynchronization later (Figure 40 (page 126)). Figure 39 Full Synchronization Using Primary Volume Snapshots (Asynchronous Periodic Mode) Resynchronization Remote copy performs a resynchronization if both of these conditions are met: • The primary volume was previously synchronized. • A valid (up-to-date) resynchronization snapshot exists.
Figure 40 Fast Resynchronization Using Resynchronization Snapshots 6. Deletes the old resynchronization snapshot. Setting Up Resynchronization for Asynchronous Periodic Mode Setting the Synchronization Period For remote copy to automatically resynchronize asynchronous periodic mode volume groups, you must configure the synchronization period for the volume group. There is no default synchronization period. To set the synchronization period, use the setrcopygroup command.
Considerations for Setting the Synchronization Period CAUTION: When you set the synchronization period, you must allow sufficient time for the volume group to complete synchronization. If you specify too small a time span between synchronizations, the volume group might continuously synchronize. The minimum synchronization period supported by remote copy is five minutes; the maximum is one year.
16 Optimizing Performance To optimize RCIP throughput, increase MTU size. “Optimizing RCIP Throughput by Increasing MTU Size” (page 128) To optimize RCIP throughput during initial synchronization, “Avoiding RCIP Throughput Issues during Initial use tape. Synchronization” (page 128) To optimize synchronization with a remote system, balance “Optimizing RCIP Synchronization Speed over Distances” bandwidth and latency.
To optimize throughput, consider increasing the MTU size to 9000 bytes. 1. Check link throughput. The output of the cli “Checking RCIP Link Throughput and Latency” (page 33) checkrclink command displays the maximum MTU for the specified RCIP links. • If the Max MTU value is 1500 bytes, you cannot increase MTU. • If the Max MTU is 9000 bytes, you might be able to increase MTU. 2. If the Max MTU value is 9000, verify that your setup allows an MTU increase. “Increasing MTU” (page 33) 3.
where: 3. • —Maximum throughput limit and size unit. By default, throughput is measured in KBps. Optionally, you can specify the size unit (GBps, MBps, or KBps). • —Target name (for example, backup system name) To start the volume groups, issue either of the following commands: # startrcopygroup or: # startrcopygroup -pat Removing Throughput Limits To remove throughput limits, follow these steps: 1.
1. Set the local switch port to full duplex, if possible. To change the switch port settings, refer to your switch manufacturer’s documentation. 2. To set the storage system port duplex and speed setting, issue the following command: # controlport rcip speed full where: • —Network speed. ◦ If you are able to change the local switch port, specify the maximum supported speed of your network. HP recommends a value of 1000 Mbps.
17 HP 3PAR Peer Persistence with Transparent Failover HP 3PAR Peer Persistence is available for VMware configurations from version 3.1.2 MU2 of the HP 3PAR OS software. Peer persistence provides the ability to redirect host I/O, either manually or automatically, from the primary to the secondary storage system in a manner that is transparent to the host while causing minimal disruption to service.
Table 7 HP 3PAR Peer Persistence Switchover and Failover Requirements Failover Requirement Description HP 3PAR Peer Persistence switchover Remote-copy groups are configured • The storage arrays have at least two in synchronous mode between two HP remote-copy-over-FC links available; 3PAR StoreServ arrays. or • The storage arrays have at least two remote-copy-over-IP links available. The source volume and target volume For more information, see must share a common WWN.
Figure 41 Quorum Witness Update and Status Messaging HP 3PAR Peer Persistence HP 3PAR Peer Persistence enables the transparent migration of applications from one HP 3PAR StoreServ to another, maintaining business continuity for virtualized data centers. In the event of a failure in the source storage system, host traffic is redirected to the secondary storage system transparently and without major impact to the hosts.
HP 3PAR Peer Persistence failover can occur when either the array or the site becomes unavailable, as shown in Figure 42 (page 134) and Figure 43 (page 135)). To ensure that applications can continue running without any interruption, a quorum witness is required to enable the automatic failover. Figure 43 HP 3PAR Quorum Witness The HP 3PAR Quorum Witness does not preclude the performance of manual peer-persistence switchovers.
Figure 44 Manual Peer Persistence Switchover Performing a switchover moves an entire VMware data store from one array to another. Executing a switchover in response to a VM migrating from one site to the other makes sense only if every VM has its own data store—that is, its own logical unit number (LUN). This is generally not the case.
Figure 45 HP 3PAR Peer Persistence—Working Principle To summarize the switchover: • Synchronous remote-copy volumes are created on source and target arrays using the same WWN addresses. • The source and target volumes are exported to the same host set from both arrays using different target port groups supported by persona 11 (VMware). • Using ALUA, paths to the source volumes are presented as active, and paths to target volumes are presented as standby.
Figure 46 Transition States As the secondary path becomes activated, the following actions occur (see Figure 47 (page 138)): 1. The target remote-copy group changes state to become “primary-reversed.” 2. At this point the primary-reversed volume becomes read/write. 3. The primary-reversed target port group state is changed to active. 4. The primary-reversed array returns a failover-complete message to the primary array.
1. The source-array target-port group state is changed to standby, and any blocked I/O is returned to the host with a sense error: NOT READY, LOGICAL UNIT NOT ACCESSIBLE, TARGET PORT IN STANDBY STATE 2. 3. The host performs SCSI inquiry requests to detect which target port groups have changed and which paths are now active. Host I/O begins to be serviced on the active path to the primary-reversed array.
Figure 49 Role Reversal Begins To complete role reversal, the following actions occur (see Figure 50 (page 140)): 1. When the primary-reversed and secondary-reversed volumes are back in sync, the snapshots that were taken on both sides get removed. 2. The remote-copy groups then undergo a reverse (natural) operation. 3. This reverse request updates the remote-copy request to change the primary-reversed group to a primary group. The secondary-reversed group becomes a target.
The transparent switchover is complete (see Figure 51 (page 141)): • The system is now fully reversed and ready for another switchover request. • The switchover has occurred in such a way as to: ◦ Manage host traffic without letting it time out. ◦ Ensure that volume migration happens transparently to the applications on the host. The target time to ensure that the host traffic does not time out is 60 seconds. This does not include the subsequent recovery and reversal operations.
in a peer-persistence configuration, additionally configured for automatic failover, to post updates regarding their operational presence and health. Storage systems also poll the quorum witness for the current operational status of their partner storage systems within each distinct peer-persistence pairing, conceptually referred to as a quorum.
Figure 52 VMware vMSC Certification—Uniform Host Access Uniform host access provides: • Protection against storage failure • Active load balancing Handling Automatic Transparent Failover To handle automatic failover, each HP 3PAR StoreServ stores its individual quorum state.
Figure 53 Handling Failover For more information about handling peer-persistence failover, see “Quorum Troubleshooting” (page 267). Link and Communication Failure Scenarios Communication Failure—Array to Array In an array-to-array communication failure (see Figure 54 (page 145)): • The HP 3PAR StoreServ arrays continue to send and receive communication to and from the quorum witness. • A failover does not take place. ◦ Replication of I/O across remote-copy links stops.
Figure 54 Communication Failure—Array to Array Communication Failure—Site 1 to Quorum Witness In the event of a communication failure between site 1 and the quorum witness (see Figure 55 (page 145)): • HP 3PAR StoreServ array A has lost connectivity with the quorum witness. • Remote-copy links are operational and the HP 3PAR StoreServ arrays are aware of each other's operational state. • A failover does not take place: ◦ Host I/O continues to the source volumes.
Communication Failure—Site 1 to Quorum Witness and Site 1 to Site 2 In a dual-network communication failure between site 1 and the quorum witness, and between site 1 and site 2 (see Figure 56 (page 146)): • HP 3PAR StoreServ array B reacts to the isolation of HP 3PAR StoreServ array A just as it would react to a failure of HP 3PAR StoreServ array A: HP 3PAR StoreServ array B performs a failover to become the source site.
Figure 57 Communication Failure—Site 2 to Quorum Witness Communication Failure—Site 2 to Quorum Witness and Site 1 to Site 2 In a dual-network communication failure between site 2 and the quorum witness, and between site 1 and site 2 (see Figure 58 (page 147)): • HP 3PAR StoreServ array A reacts to the isolation of HP 3PAR StoreServ array B just as it would react to a failure of HP 3PAR StoreServ array B. However, because HP 3PAR StoreServ array A is already source, no action is required.
No Communication on the Part of Quorum Witness with Site 1 and Site 2 In a dual-network communication failure resulting in no communication between the quorum witness and site 1, and between the quorum witness and site 2 (see Figure 59 (page 148)): • HP 3PAR StoreServ array A and B have both lost connectivity with the quorum witness. • Remote-copy links are operational, and the HP 3PAR StoreServ arrays are aware of each other’s operational state.
Figure 60 No Communication among Quorum Witness, Site 1, and Site 2 When all communication fails, service to the host must be manually re-enabled by transitioning the volumes groups out of the failsafe state on the primary storage SystemA, thus exporting the associated volumes to the attached hosts. From the command line, this is done by issuing the setrcopygroup override subcommand on a group or list of remote-copy replication groups.
The response to hosts with personas that do not support ALUA (persona 6, for example) will be as follows: Sense Key 0x02 ASC 0x04 ASCQ 0x0 Not Ready LUN Not Ready LUN Not Ready, Not Reportable The response to hosts with personas that support ALUA (persona 11, for example) will be as follows: Sense Key 0x02 ASC 0x04 ASCQ 0x0b Not Ready LUN Not Ready Target Port in Standby State The path_management policy can be enabled or disabled by issuing the following HP 3PAR OS command: # setrcopygroup pol [path_man
18 Using Tape for Initial Synchronization and Backup For the first data synchronization between systems, it can be faster to back up primary volume groups to tape and then copy data from the tape to secondary volume groups. IMPORTANT: Using tape for synchronization and backup is not supported for SLD configurations. CAUTION: To use the tape backup method for the initial synchronization of your remote-copy data, you must use block-based backup software.
where represents the name of the volume group to start (Group1). or: # startrcopygroup -pat where represents the pattern of volume group names to start (Group*). The volume will be synced using the snapshot specified with the admitrcopyvv command as the starting point of the volume changes. 9. Repeat from step 1 for each primary volume group you are synchronizing by using tape.
19 Managing VASA-connected Remote-Copy Groups and Volumes vSphere Storage application program interfaces (APIs) for Storage Awareness (VASA) is a set of APIs that enables VMware vCenter Server to detect the properties of storage arrays.
• -snp_cpg :...
where -removevv automatically removes the corresponding secondary volume of the specified volume in the specified volume group.
20 Error Handling For information about: See the following: Volume synchronization states “Synchronization States” (page 156) The timeout periods per type of failure and volume group mode “Timeouts for Remote-Copy Failure” (page 156) The effect of one link failing “Failure of a Single Link” (page 157) What happens when all links in a remote-copy pair fail “Target failure” (page 157) How remote copy handles system failures “Failure of a Storage System” (page 159) Different types of write errors
HP 3PAR Remote Copy uses low timeout values for synchronous volume groups to ensure that remote copy stops replication before the host I/O times out. Timeouts and Transient Network Problems If remote copy is using a network that has transient problems, HP 3PAR Remote Copy might display repeated link failure alerts or even stop all synchronous volume groups.
Restarting Synchronous Volume Groups after Link Recovery After you recover at least one link between the systems and remote copy marks the link(s) as Up: • If the auto_recover policy is set, the volume groups automatically restart. The auto_recover policy affects restart only after link failure. For more information, see “Automatically Restarting Volume Groups” (page 119). • If the no_auto_recover policy is set (the default), you must manually restart remote copy on the systems in the remote-copy pair.
Failure of a Storage System If one of the systems in a remote-copy pair fails, the other system: • detects the failure as a concurrent failure of both communication links • Generates an alert. • Handles the failure like a failure of all links (see“Target failure” (page 157)). Failure of a Primary System When a primary system fails and you need access to the data on the secondary virtual volumes, you must switch the role of the volume groups containing those volumes.
Read Errors Read Errors during Initial Synchronization During initial synchronization: • Synchronous volume groups—HP 3PAR Remote Copy reads the base volume. • Asynchronous periodic volume groups—HP 3PAR Remote Copy creates a read-only snapshot of the base volume. If the read request fails for any reason, HP 3PAR Remote Copy: • Cancels the synchronization process. • Marks the secondary volume as NotSynced • Issues an alert indicating that the synchronization failed.
To resynchronize the virtual volumes: • Wait for the next scheduled synchronization. If it completes successfully, HP 3PAR Remote Copy marks the virtual volume state as Synced. • Issue the syncrcopy command.
Part IV Recovering from Disaster To recover and restore this configuration after the See the following: primary system goes offline: Non-disruptive disaster recovery for 1-to-1 remote “Using Peer Persistence for Non-disruptive Failover in 1-to-1 Remote Copy in copy in geocluster environments Geocluster Environments” (page 163) 1-to-1 remote copy “Disaster Recovery for 1-to-1 Configurations” (page 171) N-to-1 remote copy “Disaster Recovery for N-to-1 Configurations” (page 181) 1-to-N remote copy “Disast
21 Using Peer Persistence for Non-disruptive Failover in 1-to-1 Remote Copy in Geocluster Environments HP 3PAR Peer Persistence software allows you to federate your HP 3PAR StoreServ Storage systems across geographically separated data centers. This inter-site federation of storage allows you to use your data centers more effectively by allowing you to move applications from one site to another according to your business need and without any application downtime.
NOTE: With the path_management policy enabled, host persona 11 configures the target port groups of secondary volumes as STANDBY. With HP 3PAR OS 3.1.2 and earlier, this can cause ESX host problems if the attached host can see only STANDBY target ports. As of HP 3PAR OS 3.1.3, the path_management policy can be disabled, thereby allowing non-uniform access to the secondary volumes that are in the ACTIVE read-only state. Before you begin non-disruptive failover: 1.
Figure 61 Bidirectional 1-to-1 Remote-Copy Configuration—Example Example primary system Example secondary system System name System1 System2 System ID 96 11 System1 = primary: • Two VVs: localvv.0 and localvv.1 • Two corresponding VVs: remotevv.0 and remotevv.1 • One primary volume group: sync_group_1 • One secondary volume group: sync_group_1.r96 • Two corresponding VVs: remotevv.0 and remotevv.1 • Two VVs: localvv.0 and localvv.1 • One secondary volume group: sync_group_2.
System Information during Normal Operation Primary System (System1) When all systems are up, the showrcopy command output on the primary system (System1) looks like the following output for 1-to-1 configuration of synchronous mode remote copy: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy System2 9 IP ready mirror_config Link Information Target System2 System2 receive receive Node 0 1 0 1 Address 10.100.33.11 10.101.33.11 10.100.
Name Target Status Role Mode Options sync_group_1.r96 System1 Started Secondary Sync LocalVV ID RemoteVV ID SyncStatus LastSyncTime remotevv.0 375 localvv.0 413 Syncing NA remotevv.1 376 localvv.1 414 Syncing NA Name Target Status sync_group_2 System1 Started LocalVV ID RemoteVV localvv.0 385 remotevv.0 localvv.1 386 remotevv.
Switchover 1. 2. Before performing a switchover operation, confirm that the remote-copy group is started and synced. Reverse the role of all volume groups on the system.
3. Verify the reversal of volume group roles by performing the following actions: a. Issue the showrcopy command on the target system (System2). b. In the Group Information area, check that the Role column for the reversed volume group displays Primary. For example, the showrcopy output for System2 shows that the role of sync_group_1.
• Confirm that the host persona is configured as persona 11 (VMware). • Confirm that the associated hosts are operating with VMware ESX release 5.0.
22 Disaster Recovery for 1-to-1 Configurations Before you begin disaster recovery: 1. Review the remote-copy pair used to illustrate 1-to-1 disaster recovery. “Bidirectional 1-to-1 Remote-Copy Configuration—Example ” (page 172) 2. Review system information for 1-to-1 configurations. “System Information during Normal Operation” (page 173) 3. Understand the system information to look for during a “System Information during Failover for 1-to-1 failover. Configurations” (page 174) Recover the systems: 1. 2.
Figure 62 Bidirectional 1-to-1 Remote-Copy Configuration—Example Example primary system Example backup system System name System1 System2 System ID 96 11 System1 = primary: • Two VVs: localvv.0 and localvv.1 • Two corresponding VVs: remotevv.0 and remotevv.1 • One primary volume group: sync_group_1 • One secondary volume group: sync_group_1.r96 • Two corresponding VVs: remotevv.0 and remotevv.1 • Two VVs: localvv.0 and localvv.1 • One secondary volume group: sync_group_2.
System Information during Normal Operation Primary System (System1) When all systems are up, the showrcopy command output on the primary system (System1) looks like the following output for 1-to-1 configuration of synchronous mode remote copy: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy System2 9 IP ready mirror_config Link Information Target System2 System2 receive receive Node 0 1 0 1 Address 10.100.33.11 10.101.33.11 10.100.
Name Target Status Role Mode Options sync_group_1.r96 System1 Started Secondary Sync LocalVV ID RemoteVV ID SyncStatus LastSyncTime remotevv.0 375 localvv.0 413 Syncing NA remotevv.1 376 localvv.1 414 Syncing NA Name Target Status sync_group_2 System1 Started LocalVV ID RemoteVV localvv.0 385 remotevv.0 localvv.1 386 remotevv.
Name Target Status sync_group_2 System1 Stopped LocalVV ID RemoteVV localvv.0 385 remotevv.0 localvv.1 386 remotevv.1 Role Mode Primary Sync ID SyncStatus 423 Stopped 424 Stopped Options LastSyncTime Thu Dec 14 17:51:48 PST 2006 Thu Dec 14 17:51:44 PST 2006 Recovering from Disaster for 1-to-1 Configurations Follow these failover and recovery guidelines to recover from system failure. Failover in 1-to-1 Remote-Copy Configurations 1.
2. Verify the reversal of volume group roles: a. Issue the showrcopy command on the failover system (System2). b. In the Group Information area, check that the Role column for the reversed volume group displays Primary-Rev (primary as a result of reversal). For example, the following showrcopy output for System2 shows that the Role of sync_group_1.
a. b. Issue the showrcopy command on the failover system (System2).
Link Information Target System2 System2 receive receive Node 0 1 0 1 Address 10.100.33.11 10.101.33.11 10.100.33.11 10.101.33.11 Status Options Up Up Up Up Group Information Name Target Status sync_group_1 System2 Started LocalVV ID RemoteVV localvv.0 413 remotevv.0 localvv.1 414 remotevv.1 Role Mode Options Secondary-Rev Sync ID SyncStatus LastSyncTime 375 Syncing Thu Dec 14 17:58:25 PST 2006 376 Syncing Thu Dec 14 17:58:25 PST 2006 Name Target Status Role Mode Options sync_group_2.
6. Verify that failback is complete and the natural direction of data flow is restored: a. Issue the showrcopy command on the failover system (System2). b. Verify that the Role of the secondary volume group is Secondary. The following showrcopy output for System2 shows that group sync_group_1.
d. Verify that the Role of the primary volume group is Primary. The following showrcopy output for System1 shows that role for group sync_group_1 is correctly restored to Primary: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy System2 9 IP ready mirror_config Link Information Target System2 System2 receive receive Node 0 1 0 1 Address 10.100.33.11 10.101.33.11 10.100.33.11 10.101.33.
23 Disaster Recovery for M-to-N Configurations Disaster Recovery for N-to-1 Configurations Before you begin disaster recovery: 1. Review the example remote-copy pair used to illustrate “Unidirectional N-to-1 Remote-Copy Configuration” N-to-1 disaster recovery. (page 181) 2. Review system information for N-to-1 configurations. “System Information during Normal Operation for N-to-1 Configurations” (page 182) 3.
Example first primary system Example second primary system Virtual volumes and volume • Two VVs: localvv.0 groups: and localvv.1 System2 = primary • One primary volume group: Data flow: periodic_group_1 System2 —> System1 • Two corresponding VVs: remotevv.0 and remotevv.1 • One secondary volume group: periodic_group_1.r96 Virtual volumes and volume groups: • Two VVs: localvv.0 and localvv.
First Primary System (System2) When all systems are up, the showrcopy command output on one of the primary systems (System2) looks like the following output for N-to-1 configuration: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy System1 11 IP ready mirror_config Link Information Target System1 System1 receive receive Node 0 1 0 1 Address 10.100.33.63 10.101.33.63 10.100.33.63 10.101.33.
System Information during Failover for N-to-1 Configurations Synchronous Mode for N-to-1 Configurations When a failure occurs on systems with synchronous mode volume groups such that all links between the systems are broken, the following actions occur: • After 10 seconds, the system marks the sending links as Down. • After another 10 seconds, the system marks the targets as failed.
Failover for N-to-1 Configurations 1. Reverse the role of all volume groups on the system that is still in normal operation (the failover system). On the failover system (System1), issue the following command: # setrcopygroup failover -t where represents the name of the target system that failed (System2). The setrcopygroup failover -t command: • Changes all secondary volume groups on the failover system (periodic_group_1.
2. Verify the reversal of volume group roles. a. Issue the showrcopy command on the failover system (System1). b. In the Group Information area, check that the Role column for the reversed volume group displays Primary-Rev (primary as a result of reversal). For example, the showrcopy output for System1 shows that the role of periodic_group_1.
2. When both systems in the remote-copy pair are ready to resume normal operation, reverse the natural direction of data flow and resynchronize the systems by performing the following steps: a. Stop I/O to the reversed volume groups on the failover system. b. On the failover system (System1), issue the following command: # setrcopygroup recover -t where represents the name of the target system with which to synchronize (System2).
remotevv.2 remotevv.3 c. d. 23 24 localvv.0 localvv.1 385 386 Synced Synced Thu Dec 14 18:23:45 PST 2006 Thu Dec 14 18:23:44 PST 2006 Issue the showrcopy command on the recovered system (System2).
4. On the recovered system (System2), issue the following command to verify that the volume groups are started: # showrcopy groups where represents the volume group that should be started (periodic_group_1). Problem Solution The volume groups are not started. 1. On the recovered system, issue: startrcopygroup or: startrcopygroup -pat where -pat represents the pattern of volume group names (for example, periodic*). 2.
6. Verify that failback is complete and the natural direction of data flow is restored: a. Issue the showrcopy command on the failover system (System1). b. Verify that the Role of the secondary volume group is Secondary. The following showrcopy command output for System1 shows that the Role of group periodic_group_1.
d. Verify that the Role of the primary volume groups is Primary. The following example of the showrcopy command output for System2 shows that the Role of periodic_group_1 is correctly restored to Primary: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy System1 11 IP ready mirror_config Link Information Target System1 System1 receive receive Node 0 1 0 1 Address 10.100.33.63 10.101.33.63 10.100.33.63 10.101.33.
Figure 64 Unidirectional 1-to-N Remote-Copy Configuration Example primary system Example first backup system Example second backup system System name System1 System2 System3 System ID 96 61 11 Virtual volumes and volume • Two VVs, localvv.0 • Two corresponding VVs: • Two corresponding VVs: groups: and localvv.1, belong remotevv.0 and remotevv.0 and to primary volume group Data flow: remotevv.1 remotevv.
Target System2 System2 System3 System3 receive receive Node 0 1 0 1 0 1 Address 10.100.33.61 10.101.33.61 10.100.33.11 10.101.33.11 10.100.33.61 10.101.33.61 Status Options Up Up Up Up Up Up Group Information Name periodic_group_1 LocalVV ID localvv.0 21 localvv.1 22 Target Status Role Mode Options System2 Started Primary Periodic over_per_alert RemoteVV ID SyncStatus LastSyncTime remotevv.0 413 Syncing NA remotevv.1 414 Syncing NA Name periodic_group_2 LocalVV ID localvv.2 23 localvv.
Status: Started, Normal Target Information Name ID Type Status Options Policy System1 4 IP ready mirror_config Link Information Target System1 System1 receive receive Node 0 1 0 1 Address 10.100.33.96 10.101.33.96 10.100.33.96 10.101.33.96 Status Options Up Up Up Up Group Information Name Target Status Role Mode Options periodic_group_2.r96 System1 Started Secondary Periodic Last-Sync Thu Dec 14 18:19:12 PST 2006 , over_per_alert LocalVV ID RemoteVV ID SyncStatus LastSyncTime remotevv.0 385 localvv.
System1 1 receive 0 receive 1 10.101.33.96 Down 10.100.33.96 Down 10.101.33.96 Down Group Information Name Target Status periodic_group_1.r96 System1 Stopped LocalVV ID RemoteVV ID remotevv.0 21 localvv.0 413 remotevv.1 22 localvv.
2. Verify the reversal of volume group roles. a. Issue the showrcopy command on the failover system (System2). b. In the Group Information area, check that the Role column for the reversed volume group displays Primary-Rev (primary as a result of reversal). The following example of the showrcopy command output for System2 shows that the Role of periodic_group_1.
b.
System2 System3 System3 receive receive 1 0 1 0 1 10.101.33.61 10.100.33.11 10.101.33.11 10.100.33.61 10.101.33.61 Up Up Up Up Up Group Information Name Target Status Role Mode Options periodic_group_1 System2 Started Secondary-Rev Periodic Last-Sync Thu Dec 14 18:19:17 PST 2006 , over_per_alert LocalVV ID RemoteVV ID SyncStatus LastSyncTime localvv.0 413 remotevv.0 21 Syncing Thu Dec 14 18:40:14 PST 2006 localvv.1 414 remotevv.
5. Restore the natural direction of data flow to the remote-copy pair. On the failover system (System2), issue the following command: # setrcopygroup restore -t where represents the name of the target (recovered) system (System1).
6. Verify that failback is complete and the natural direction of data flow is restored: a. Issue the showrcopy command on the failover system (System2). b. Verify that the Role of the secondary volume group is Secondary. The following example of the showrcopy output for System2 shows that the Role of group periodic_group_1.
Name Target Status Role Mode Options periodic_group_1 System2 Started Primary Periodic Last-Sync Thu Dec 14 18:39:03 PST 2006 , over_per_alert LocalVV ID RemoteVV ID SyncStatus LastSyncTime localvv.0 21 remotevv.0 413 Stale Thu Dec 14 18:40:14 PST 2006 localvv.1 22 remotevv.1 414 Stale Thu Dec 14 18:39:03 PST 2006 Name Target Status Role Mode Options periodic_group_2 System3 Started Primary Periodic over_per_alert LocalVV ID RemoteVV ID SyncStatus LastSyncTime remotevv.2 23 localvv.
24 Disaster Recovery for SLD Configurations Before you begin disaster recovery: 1. Review the example remote-copy pair used to illustrate “SLD Remote-Copy Configuration” (page 203) SLD disaster recovery. 2. Review system information for SLD configurations. “System Information during Normal Operation for SLD Configurations” (page 203) 3. Understand what system information to look for during “System Information during Failover for SLD Configurations” a failover.
Figure 65 SLD Remote-Copy Configuration Example primary system Example synchronous backup system Example asynchronous periodic backup system System name SystemA SystemB SystemC System ID 96 195 63 Virtual volumes and volume • Four VVs, testvv.0 – groups: testvv.3, belong to primary volume group Data flow: multi.1 SystemA —> SystemB SystemA —> SystemC mode sync —> SystemB • Four corresponding VVs: • Four corresponding VVs: testvv.0 – testvv.3 testvv.0 – testvv.
SystemB SystemC SystemC receive receive receive receive 1:2:1 0:3:1 1:3:1 0:2:1 1:2:1 0:3:1 1:3:1 21210002AC0000C3 10.100.33.63 10.101.33.63 20210002AC0000C3 21210002AC0000C3 receive receive Up Up Up Up Up Up Up Group Information Name multi.1 LocalVV testvv.0 testvv.1 testvv.2 testvv.3 Target Status SystemB Started ID RemoteVV 100 testvv.0 101 testvv.1 102 testvv.2 103 testvv.
Name multi.1.r96 LocalVV testvv.0 testvv.1 testvv.2 testvv.3 Target Status SystemC Backup ID RemoteVV 200 testvv.0 201 testvv.1 202 testvv.2 203 testvv.
Asynchronous Periodic Mode System Information during Failover When a failure occurs on systems with asynchronous periodic mode volume groups such that all links between the systems are broken: • After 25 seconds, the system marks the sending links as Down. • After another 200 seconds, the system marks the targets as failed.
SystemA 42 IP SystemB 44 IP failed ready mirror_config mirror_config Link Information Target SystemA SystemA SystemB SystemB receive receive Node 0 1 0 1 0 1 Address 10.100.33.96 10.101.33.96 10.100.33.195 10.101.33.195 receive receive Status Options Down Down Up Up Up Up Group Information Name multi.1.r96 LocalVV testvv.0 testvv.1 testvv.2 testvv.3 Target Status SystemA Stopped ID RemoteVV 300 testvv.0 301 testvv.1 302 testvv.2 303 testvv.
Figure 66 Failing Over to the Synchronous Backup System Follow these failover and recovery guidelines to recover from system failure. Failover in SLD Remote-Copy Configuration 1. Reverse the role of all volume groups on the synchronous backup system (the failover system). On the failover system (SystemB), issue the following command: # setrcopygroup failover -f -t where represents the name of the target system that failed (for example, SystemA).
~/bin# waittask -v 5745 Id Type Name Status Phase Step -------StartTime------------FinishTime------5745 remote_copy_failover multi.1.r96 done --- --- 2009-06-29 12:16:31 PDT 2009-06-29 12:16:39 PDT Detailed status: 2009-06-29 12:16:31 2009-06-29 12:16:31 2009-06-29 12:16:32 2009-06-29 12:16:34 2009-06-29 12:16:39 SystemC. 2009-06-29 12:16:39 PDT PDT PDT PDT PDT Created Begin Switched Starting Started PDT Completed task. Failover operation on group multi.1.r96 started. Group multi.1.
3. Verify the reversal of volume group roles: a. Issue the showrcopy command on the failover system (SystemB). b. In the Group Information area, check that the Role column for the reversed volume group displays Primary-Rev (primary as a result of reversal). The following example of the showrcopy command output for SystemB shows that the role of multi.1.
4. Verify that the asynchronous periodic backup system (SystemC) is now the backup system. a. Issue the showrcopy command on the asynchronous periodic backup system (SystemC). b. In the Group Information area, verify the following: • The Status of the volume groups on the asynchronous periodic backup system (SystemC) for which the target is the synchronous backup system (SystemB) is Started.
where represents the name of the target system with which to synchronize (SystemA). The setrcopygroup recover command: • Switches the volume groups on the recovered system (SystemA) to secondary mode. • Copies data from the reversed volume groups on the failover system (SystemB) to the corresponding volume groups on the recovered system (SystemA).
a. b. Issue the showrcopy command on the failover system (SystemB).
The following example shows the showrcopy command output for SystemA: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemB 58 FC ready 2FF70002AC0000C3 mirror_config SystemC 59 IP ready mirror_config Link Information Target SystemB SystemB SystemC SystemC receive receive receive receive Node 0:2:1 1:2:1 0:3:1 1:3:1 0:2:1 1:2:1 0:3:1 1:3:1 Address 20210002AC0000C3 21210002AC0000C3 10.100.33.63 10.101.33.
Target SystemA SystemA SystemB SystemB receive receive Node 0 1 0 1 0 1 Address 10.100.33.96 10.101.33.96 10.100.33.195 10.101.33.195 receive receive Status Options Up Up Up Up Up Up Group Information Name multi.1.r96 LocalVV testvv.0 testvv.1 testvv.2 testvv.3 Target Status SystemA Backup ID RemoteVV 300 testvv.0 301 testvv.1 302 testvv.2 303 testvv.
CAUTION: The volume groups must be started before you continue to the next step and issue the setrcopygroup restore command. 5. To restore the natural direction of data flow to the remote-copy system, issue the following command on the failover system (SystemB): # setrcopygroup restore -f -t where represents the name of the target (recovered) system (SystemA). The setrcopygroup restore command: • Starts tasks for each group that was recovered.
6. Verify that the SLD setup is restored and operating normally. a. Issue the showrcopy command on the recovered system (SystemA) and verify that it has resumed the role of primary system.
# showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 46 FC ready 2FF70002AC000060 mirror_config SystemC 47 IP ready mirror_config Link Information Target SystemA SystemA SystemC SystemC receive receive receive receive Node 0:2:1 1:2:1 0:4:1 1:4:1 0:2:1 1:2:1 0:4:1 1:4:1 Address 20210002AC000060 21210002AC000060 10.100.33.63 10.101.33.
c. Issue the showrcopy command on the asynchronous periodic backup system (SystemC) and verify that it is in the role of backup system. The following example shows the showrcopy command output for SystemC: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 42 IP ready mirror_config SystemB 44 IP ready mirror_config Link Information Target SystemA SystemA SystemB SystemB receive receive Node 0 1 0 1 0 1 Address 10.100.33.96 10.
Figure 67 Failing Over to the Asynchronous Periodic System with Data Transfer Follow these failover and recovery guidelines to fail over to the asynchronous periodic backup system with data transfer. Failover in Asynchronous Periodic SLD Remote-Copy Configurations 1. Reverse the role of all volume groups on the asynchronous periodic backup system (the failover system).
2. Verify that failover tasks complete successfully (failover of individual groups can still fail). For example, failing over to the asynchronous periodic backup system (SystemC) results in a task list that looks like the following: # setrcopygroup failover -f -t SystemA failover started with tasks: 6740 ~/bin# waittask -v 6740 Id Type Name Status Phase Step -------StartTime------- -FinishTime6740 remote_copy_failover multi.1.
3. Verify that the newer data is being pushed to the failover system. a. While remote copy progresses through the failover tasks, issue the showrcopy command on the synchronous backup system (SystemB).
# showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 42 IP failed mirror_config SystemB 44 IP ready mirror_config Link Information Target SystemA SystemA SystemB SystemB receive receive Node 0 1 0 1 0 1 Address 10.100.33.96 10.101.33.96 10.100.33.195 10.101.33.195 receive receive Status Options Down Down Up Up Up Up Group Information Name multi.1.r96 LocalVV testvv.0 testvv.1 testvv.2 testvv.
4. Verify the reversal of volume group roles. a. Issue the showrcopy command on the failover system (SystemC). b. In the Group Information area, check that: • the Role column for the reversed volume group displays Primary-Rev (primary as a result of reversal) • the SyncStatus column of the virtual volumes displays Synced The following example of the showrcopy command output for SystemC shows that the Role of multi.1.
# showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 46 FC failed 2FF70002AC000060 mirror_config SystemC 47 IP ready mirror_config Link Information Target SystemA SystemA SystemC SystemC receive receive receive receive Node 0:2:1 1:2:1 0:4:1 1:4:1 0:2:1 1:2:1 0:4:1 1:4:1 Address 20210002AC000060 21210002AC000060 10.100.33.63 10.101.33.
In the following example, HP 3PAR Remote Copy copies data from the virtual volumes in volume group multi.1.r96 on SystemC to multi.1 on SystemA. • Starts remote copy on the recovered system (SystemA). The following example shows the list of tasks launched by the setrcopygroup recover command for SystemC: # setrcopygroup recover -f -t SystemA recover started with tasks: 6747 ~/bin# waittask -v 6747 Id Type Name Status Phase Step -------StartTime------- -FinishTime6747 remote_copy_recover multi.1.
b. Verify the following the target system (SystemA): • The Status of the target system is ready. • The Status of primary system’s sending links (SystemA) is Up. • The SyncStatus of all volumes in the Primary-Rev volume groups is Synced.
Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemB 58 FC ready 2FF70002AC0000C3 mirror_config SystemC 59 IP ready mirror_config Link Information Target SystemB SystemB SystemC SystemC receive receive receive receive Node 0:2:1 1:2:1 0:3:1 1:3:1 0:2:1 1:2:1 0:3:1 1:3:1 Address 20210002AC0000C3 21210002AC0000C3 10.100.33.63 10.101.33.
f. Verify the following: • The Status of the target system (SystemA) is ready. • The Status of the primary system’s sending links (SystemA) is Up.
4. To verify that the volume groups are started, issue the following command on the recovered system (SystemA): # showrcopy groups where represents the volume group that should be started (for example, multi.1). Problem Solution The volume groups are not started. 1. On the recovered system, issue either of the following commands: startrcopygroup or: startrcopygroup -pat where -pat represents the pattern of volume group names (multi*). 2.
SystemA. 2009-06-29 14:56:56 PDT Syncing SystemB. 2009-06-29 14:56:56 PDT Waiting SystemA to complete. 2009-06-29 14:56:56 PDT Waiting SystemB to complete. 2009-06-29 14:57:14 PDT Stopped 2009-06-29 14:57:15 PDT Switched secondary to primary. 2009-06-29 14:57:16 PDT Switched 2009-06-29 14:57:16 PDT Waiting snapshot promotions. 2009-06-29 14:57:17 PDT Starting 2009-06-29 14:57:25 PDT Started SystemA. 2009-06-29 14:57:25 PDT Completed Synchronization started for group multi.1.
6. Verify that the SLD setup is restored and operating normally. a. Issue the showrcopy command on the recovered system (SystemA) and verify that it has resumed the role of primary system.
# showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 46 FC ready 2FF70002AC000060 mirror_config SystemC 47 IP ready mirror_config Link Information Target SystemA SystemA SystemC SystemC receive receive receive receive Node 0:2:1 1:2:1 0:4:1 1:4:1 0:2:1 1:2:1 0:4:1 1:4:1 Address 20210002AC000060 21210002AC000060 10.100.33.63 10.101.33.
c. Issue the showrcopy command on the asynchronous periodic backup system (SystemC) and verify that it has resumed the role of backup system. The following example shows the showrcopy command output for SystemC: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 42 IP ready mirror_config SystemB 44 IP ready mirror_config Link Information Target SystemA SystemA SystemB SystemB receive receive Node 0 1 0 1 0 1 Address 10.100.33.
Failing Over to the Asynchronous Periodic Backup System (No Data Transfer) If the primary system fails or is taken offline, you can failover the storage system to the asynchronous periodic backup system without a final data transfer from the synchronous backup system (see Figure 68 (page 235)) if: • The asynchronous periodic backup system is functioning properly. • The asynchronous periodic backup system contains the most current data. • The synchronous backup system also failed or was brought down.
Failover 1. Reverse the role of all volume groups on the asynchronous periodic backup system (the failover system). On the failover system (SystemC), issue the following command: # setrcopygroup failover -f -discard -t where represents the name of the target system that failed (SystemA). The setrcopygroup failover -f -discard -t command: 2. • Bypasses the data transfer step between the backup systems (SystemB and SystemC).
3. Verify the reversal of volume group roles: a. Issue the showrcopy command on the failover system (SystemC). b. In the Group Information area, check that: • the Role column for the reversed volume group displays Primary-Rev (primary as a result of reversal) • the SyncStatus column of the virtual volumes displays Synced The following example of the showrcopy command output on SystemC shows that the Role of multi.1.
# showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 46 FC failed 2FF70002AC000060 mirror_config SystemC 47 IP ready mirror_config Link Information Target SystemA SystemA SystemC SystemC receive receive receive receive Node 0:2:1 1:2:1 0:4:1 1:4:1 0:2:1 1:2:1 0:4:1 1:4:1 Address 20210002AC000060 21210002AC000060 10.100.33.63 10.101.33.
The setrcopygroup recover command: • Switches volume groups on the recovered system (SystemA) to secondary mode • Copies data from the reversed volume groups on the failover system (SystemC) to the corresponding volume groups on the recovered system (SystemA) The data used to synchronize the systems includes the snapshots taken when the recovered system (SystemA) went down as well as recent I/O to the failover system (SystemC).
multi.1 5915 rcpy.222.103.58 snp vcopy testvv.3 103 RO normal -- -- -- 1024 snap multi.1 3. Verify that the primary system is up and the remote-copy pairs are synchronized: a. Issue the showrcopy command on the failover system (SystemC). b. Verify the following for the target system (SystemA): • The Status of the target system is ready. • The Status of primary system’s sending links (SystemA) is Up. • The SyncStatus of all volumes in the Primary-Rev volume groups is Synced.
• The Role of the synchronizing volume groups is Secondary-Rev. • The SyncStatus of all volumes in the Secondary-Rev volume groups is Synced.
f. Verify the following: • The Status of the target system (SystemA) is ready. • The Status of the primary system’s sending links (SystemA) is Up.
4. To verify that the volume groups are started, issue the following command on the recovered system (SystemA): # showrcopy groups where represents the volume group that should be started (multi.1). Problem Solution The volume groups are not started. 1. On the recovered system, issue either of the following commands: startrcopygroup or: startrcopygroup -pat where -pat represents the pattern of volume group names (multi*). 2.
2009-06-29 14:56:56 PDT Syncing SystemB. 2009-06-29 14:56:56 PDT Waiting SystemA to complete. 2009-06-29 14:56:56 PDT Waiting SystemB to complete. 2009-06-29 14:57:14 PDT Stopped 2009-06-29 14:57:15 PDT Switched secondary to primary. 2009-06-29 14:57:16 PDT Switched 2009-06-29 14:57:16 PDT Waiting snapshot promotions. 2009-06-29 14:57:17 PDT Starting 2009-06-29 14:57:25 PDT Started SystemA.
6. Verify that the SLD setup is restored and operating normally. a. Issue the showrcopy command on the recovered system (SystemA) and verify that it has resumed the role of primary system.
# showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 46 FC ready 2FF70002AC000060 mirror_config SystemC 47 IP ready mirror_config Link Information Target SystemA SystemA SystemC SystemC receive receive receive receive Node 0:2:1 1:2:1 0:4:1 1:4:1 0:2:1 1:2:1 0:4:1 1:4:1 Address 20210002AC000060 21210002AC000060 10.100.33.63 10.101.33.
c. Issue the showrcopy command on the asynchronous periodic backup system (SystemC) and verify that it has resumed the role of backup system. The following example shows the showrcopy command output for SystemC: # showrcopy Remote Copy System Information Status: Started, Normal Target Information Name ID Type Status Options Policy SystemA 42 IP ready mirror_config SystemB 44 IP ready mirror_config Link Information Target SystemA SystemA SystemB SystemB receive receive Node 0 1 0 1 0 1 Address 10.100.33.
Figure 69 One Backup System Failure with SLD Remote Copy In this example, when SystemB is restored, HP 3PAR Remote Copy transfers data from SystemA to SystemB and restores synchronous mode remote copy between SystemA and SystemB. Handling Primary System Failure If the primary system in an SLD remote-copy configuration fails, the asynchronous-periodic mode secondary array is the anticipated failover site.
Figure 70 (page 249) illustrates an SLD configuration in which the primary system, SystemA, goes down. In this example, SystemB becomes the temporary primary system, and SystemC becomes the backup system to SystemB. After this, SystemC becomes the primary system and SystemB becomes the backup system. NOTE: You can set up either backup system to assume the role of the primary system in the event of failover.
In this example, when SystemA is restored, HP 3PAR Remote Copy performs the following actions: • Transfers data from SystemB to SystemA. • Restores SystemA as the primary system. • Restores SystemB and SystemC as backup systems. • Restores synchronous mode between SystemA and SystemB. • Restores asynchronous periodic mode between SystemA and SystemC.
Part V Reference For information about: See the following: Quick setup steps for RCIP, RCFC, and remote-copy configurations “Quick Setup Guide” (page 252) Quick disaster recovery steps for remote copy “Quick Disaster Recovery Guide” (page 259) CLI commands relevant to remote copy “About the Remote-Copy Commands” (page 261) “Using Remote Copy Commands” (page 261) Quorum Witness deployment “HP 3PAR Quorum Witness Deployment” (page 263) Remote Copy snapshots “Remote-Copy Snapshots” (page 270)
25 Quick Setup Guide To set up: See the following: Transport layer for RCIP “Quick Setup: RCIP Transport Layer” (page 253) Transport layer for RCFC “Quick Setup: RCFC Transport Layer” (page 254) Remote-copy configurations and scripts “Quick Setup: Remote-Copy Configurations” (page 254) Unidirectional remote copy “Quick Setup: Unidirectional Remote Copy” (page 255) Bidirectional remote copy “Quick Setup: Bidirectional Remote Copy” (page 256) SLD remote copy “Quick Setup: Synchronous Long Distanc
Quick Setup: RCIP Transport Layer Table 8 Quick Setup Steps for RCIP Step Reference Primary System Backup System 1. On all RCIP ports, set up “Setting Up the Remote-Copy controlport rcip the interface. Interface for RCIP” (page 30) addr [-f] controlport rcip addr [-f] 2. On all RCIP ports, set the “Setting the Gateway” gateways. (page 31) controlport rcip gw [-f] controlport rcip gw [-f] 3.
Quick Setup: RCFC Transport Layer Table 9 Quick Setup Steps for RCFC Step Reference Primary System Backup System 1. Take the port offline. “Setting Up Remote-Copy Interface for RCFC” (page 36) controlport offline controlport offline 2. On all RCFC ports, set up “Setting Up Remote-Copy the interface. Interface for RCFC” (page 36) controlport config rcfc -ct point -f controlport config rcfc -ct point -f 3. On all RCFC ports, get RCFC port positions.
Quick Setup: Unidirectional Remote Copy Table 10 Quick Setup Steps for Unidirectional Pairs: 1-to-1, N-to-1, and 1-to-N Configurations Step Reference Primary System 1. Start remote copy. “Setting Up the Primary System for Unidirectional Remote Copy” (page 78) startrcopy — RCIP: creatercopytarget IP : — 2. Define a target.
Table 10 Quick Setup Steps for Unidirectional Pairs: 1-to-1, N-to-1, and 1-to-N Configurations (continued) Step Reference Primary System • If synchronizing directly from system to system: “Starting Initial Replication startrcopygroup for Unidirectional Remote Copy: Copying Data Directly from Primary Volume Groups” (page 84) 11. Verify synchronization.
Quick Setup: Synchronous Long Distance Remote Copy Table 12 Quick Setup Steps for Synchronous Long Distance Configurations Step Reference Primary System Sync System Periodic System 1. Start remote copy. “Setting Up the Primary System for SLD Remote Copy” (page 57) startrcopy — — 2. Define target for sync backup system. “Setting Up the Primary System for SLD Remote Copy” (page 57) Assuming RCFC: creatercopytarget FC : — — 3.
Table 12 Quick Setup Steps for Synchronous Long Distance Configurations (continued) Step 13. Add virtual volumes to their volume groups. Reference Primary System (page 66) : periodic “Creating Volume Groups for SLD Remote Copy” (page 66) admitrcopyvv : : Sync System Periodic System — — — — 14. Start replication.
26 Quick Disaster Recovery Guide To recover from primary system downtime for: See: 1-to-1 “Quick Recovery: 1-to-1 and M-to-N Remote-Copy Configurations” (page 259) N-to-1 1-to-N SLD “Quick Recovery: Synchronous Long Distance Configurations” (page 260) For additional information, see the following: • “Disaster Recovery for 1-to-1 Configurations” (page 171) • “Disaster Recovery for N-to-1 Configurations” (page 181) • “Disaster Recovery for 1-to-N Configurations” (page 191) • “Disaster Recovery fo
Quick Recovery: Synchronous Long Distance Configurations Table 14 Quick Recovery Steps for Synchronous Long Distance Configurations Step Failover System 1. Change secondary volume groups to primary. setrcopygroup failover -f -t Failed/Recovered System Backup System (of failed system) OR (no data transfer): setrcopygroup failover -f -t -discard (possible data loss) 2. Verify group reversal. Verify that failover tasks complete successfully. 3. Back up data. showrcopy 4.
27 Using Remote Copy Commands For information about the following commands, see the HP 3PAR Command Line Interface Reference. To access this document, go to the HP 3PAR StoreServ Storage site and click the Support link for your product: www.hp.
Description Command View historical performance data reports for remote-copy volumes srstatrcvv Enable remote copy on a storage system startrcopy Enable remote copy for a remote-copy volume group startrcopygroup View I/O statistics for remote-copy ports statport View statistics for remote-copy volume groups statrcopy View statistics for remote-copy volumes statrcvv Stop remote-copy functionality for all started remote-copy volume groups stoprcopy Stop remote-copy functionality for a specific
28 HP 3PAR Quorum Witness Deployment This appendix describes how to deploy HP 3PAR Quorum Witness for peer-persistence failover. See “HP 3PAR Peer Persistence with Transparent Failover” (page 132). Starting the vSphere Client 1. Install the vSphere client from the following link to your Windows system: http://h18004.www1.hp.com/products/servers/software/vmware/esxi-image.html? jumpid=reg_r1002_usen_c-001_title_r0001 2. 3. 4. 5.
4. 5. 6. 7. 8. 9. Type your new password, and then retype the password to confirm. Select Configure the Device, then select the device to configure, either eth0 or eth1. Change the device’s static IP address to an IP address of your choice. See “Configuring a Static IP Address” (page 264). Click OK, and then click Save & Quit to save the IP address and close the screen. Select DNS configuration. Change the default Hostname setting from localhost.localdomain to server.domain.com.
nameserver 192.168.1.3 6. Restart the network service by issuing the following command: service network restart 7. Verify IP connectivity to arrays. Quorum-Witness CLI Commands Creating a Quorum Witness To create a quorum witness on a target, follow these steps: 1. Make sure that the target is sync—that is, that it contains only sync groups and is not in an SLD configuration. This condition is enforced in the software. 2.
1. 2. Check the status of the quorum witness by issuing the showrcopy -qw command, and ensure that the quorum-witness state has advanced to the not-started state on both systems. To start the quorum on the local machine, issue the start command: # setrcopytarget witness start 3. Issue the showrcopy command to confirm that the quorum witness has started: # showrcopy -qw targets Target Information Name ID Type Status Policy QW-IP Q-Status Q-Status-Qual RC045IP 4 IP ready mirror_config 15.214.
To remove a quorum witness, you must first stop it; see “Stopping a Quorum Witness” (page 266). Then issue the remove command: # setrcopytarget witness remove You can also tunnel the remove command to the other HP 3PAR OS using the –remote option: # setrcopytarget witness remove –remote Auto Failover Policies A volume group must have the auto_failover policy set if it is to be valid for automated and transparent failover.
Table 15 Quorum Status Qualifiers (continued) Quorum Status Qualifier Description is either in the Initializing state, or is not sufficiently far enough into its Re-starting system stability checks to consider auto-advance to the Starting state. Target not ready A target failure, one of the side effects of a storage system failure, is one of the criteria evaluated when making a decision to perform a peer-persistence failover.
Table 15 Quorum Status Qualifiers (continued) Quorum Status Qualifier Description A locally detected quorum-announcer status inconsistency will typically be as a result of a transient timing issue which will resolve quickly. The status checks between the two systems are crucial to ensuring that one half of the quorum cannot be primed for peer-persistence failover before the other half of the quorum on the partner storage system has been fully configured and initialized.
29 Remote-Copy Snapshots For information about: See the following: What snapshots are and why remote copy uses them “Why Use Snapshots” (page 270) Ensuring virtual volumes have enough space to create the “Volume Space Considerations” (page 270) necessary snapshots In synchronous mode, when remote copy takes snapshots and what it does with them “Snapshots and Initial Synchronization Failure” (page 271) “Snapshots and Resynchronization” (page 271) “Snapshots and Resynchronization Failure in Synchronous M
For additional information, see the following: • “Common Provisioning Groups” (page 108) • “Converting Standard Virtual Volumes” (page 106) Snapshots in Synchronous Mode In synchronous mode, remote copy creates snapshots only when: • An error occurs. • Disaster recovery is in process. • A volume group is manually stopped. Use the createsv -rcopy command to create identical read-only snapshot volumes on both the primary and secondary node.
Snapshots Taken before or during Disaster Recovery If the Backup System Fails If the backup system fails, or all communication links to the backup system fail, the primary system: • stops the replication of all volume groups • takes snapshots of all volumes that were completely synchronized If the Primary System Fails When remote copy restarts after a primary system failure (either manually using the startrcopygroup command or via the auto_recover policy), HP 3PAR Remote Copy first looks for a valid res
• When the resynchronization completes, remote copy deletes the old snapshots on the primary and the backup systems. • After resynchronization, the base volume on the backup storage system matches the new snapshot on the primary storage system. The new snapshot on the primary system can now be used in the next resynchronization operation.
30 Support and Other Resources Contacting HP For worldwide technical support information, see the HP support website: http://www.hp.
For information about: See: Migrating data from one HP 3PAR storage system to another HP 3PAR-to-3PAR Storage Peer Motion Guide Configuring the Secure Service Custodian server in order to monitor and control HP 3PAR storage systems HP 3PAR Secure Service Custodian Configuration Utility Reference Using the CLI to configure and manage HP 3PAR Remote Copy HP 3PAR Remote Copy Software User’s Guide Updating HP 3PAR operating systems HP 3PAR Upgrade Pre-Planning Guide Identifying storage system components
For information about: See: Planning for HP 3PAR storage system setup Hardware specifications, installation considerations, power requirements, networking options, and cabling information for HP 3PAR storage systems HP 3PAR 7200, 7400, and 7450 storage systems HP 3PAR StoreServ 7000 Storage Site Planning Manual HP 3PAR StoreServ 7450 Storage Site Planning Manual HP 3PAR 10000 storage systems HP 3PAR StoreServ 10000 Storage Physical Planning Manual HP 3PAR StoreServ 10000 Storage Third-Party Rack Physic
Typographic conventions Table 16 Document conventions Convention Element Bold text • Keys that you press • Text you typed into a GUI element, such as a text box • GUI elements that you click or select, such as menu items, buttons, and so on Monospace text • File and directory names • System output • Code • Commands, their arguments, and argument values • Code variables • Command variables Bold monospace text • Commands you enter into a command line interface • Syste
31 Documentation feedback HP is committed to providing documentation that meets your needs. To help us improve the documentation, send any errors, suggestions, or comments to Documentation Feedback (docsfeedback@hp.com). Include the document title and part number, version number, or the URL when submitting your feedback.
Glossary A asynchronous periodic mode Data replication in which the primary and secondary volumes are resynchronized at set times—for example, when scheduled or when resynchronization is manually initiated. H HP 3PAR Remote Copy Software A host-independent, array-based data mirroring solution that enables data distribution and disaster recovery for applications. With this optional utility, you can copy virtual volumes from one system to a second system.
synchronous mode 280 Glossary Data replication that writes data to the primary and secondary sites simultaneously over a network, such that data remains current between sites.
Index Symbols 1-to-1 quick recovery, 259 remote copy, 16 1-to-1 remote copy illustration, 45 setup bidirectional, 40 unidirectional, 40 1-to-N quick recovery, 259 1-to-N remote copy configuration, 18 considerations, 44 A accessing HP 3PAR Quorum Witness, 263 adding FPVVs, 152 admitrcopylink CLI command, 30, 254, 261 admitrcopytarget CLI command, 261 admitrcopyvv CLI command, 53, 54, 68, 83, 90, 105, 113, 123, 151, 152, 154, 255, 256, 258, 261 alerts, 157 ALUA, 136, 149, 163 not supported by generic persona
dismissrcopylink, 30, 51, 66, 81, 261 dismissrcopytarget, 261 dismissrcopyvv, 53, 68, 83, 90, 261 -removevv, 154 growvv, 105, 107, 155, 261 histrcvv, 95, 261 issuing, 262 quorum, 265 remote copy, 261 removecpg, 153 removercopygroup, 53, 68, 83, 90, 261 -removevv, 155 removercopytarget, 261 removetask, 98 setcpg -name, 153 setrcopy switchover, 141 setrcopygroup, 110, 119, 126, 149 -snp_cpg, 153 -usr_cpg, 153 failover, 110, 117 failover -f -discard -t, 236 failover -f -t, 208, 220, 260 failover -t, 175, 185,
consistency groups configuring the synchronization period, 126 loss of sync between, 157 synchronization of new consistency groups, 123 controller node ports, install and configure, 30, 184 controller nodes, 27 in 1-to-N configuration, 45 in N-to-1 configuration, 44 in SLD configuration, 57 interface, 30 controlport CLI command, 30, 31, 32, 34, 36, 37, 131, 253, 254, 261 controlport command controlport rcfc, 35 conventions text symbols, 277 CPG, 108 allocation limit, 109 assigning VV to, 107 creating, 109 l
FPVV creating, 151 limits, 106 new or empty, 152 free snapshot data space, 108 fully-provisioned virtual volume see FPVV G gateway IP address, 25 RCIP, 31 Gigabit Ethernet cards, 26 switches, 14 GigE interface, 23 growvv CLI command, 105, 107, 155, 261 H HBA HP 3PAR StoreServ 10000 Storage, 24 HP 3PAR StoreServ 7000 Storage, 24 load sharing and fault tolerance, 24, 26 shared by host and RCFC, 24 sharing restrictions, 24 histrcvv CLI command, 95, 261 host bus adaptor HBA, 24 host persona, 164 configuring,
MTU, 32 increasing, 33 N N-to-1 quick recovery, 259 N-to-1 remote copy configuration, 17 restrictions, 43 natural direction of data flow, 101 network bandwidth, 14 connections, 14, 23 IP, 23 new consistency groups, 123 no_auto_failover, 267 node pairs in RCFC configuration, 36 in SLD remote copy, 57 non-disruptive failover synchronous mode, 164 NotSynced, 160 O Open Virtualization Format see OVF OVF, 133 template, 263 P path management policies, 149 peer persistence, 134, 163 policy auto failover, 133 au
bidirectional 1-to-1, 16 configurations, 16 N-to-1, 17 over Fibre Channel, 24 setup, 254 pairs, 16, 99 removing, 94 setup, 13 setup strategy, 13 SLD, 20 SLD restrictions, 56 stopping, 94 target definitions, 99 targets, 99 unidirectional 1-to-1, 16 volume groups, 110 remote copy over Fibre Channel see RCFC Remote Copy over IP see RCIP remote-copy group removing, 155 remote-copy pair worksheet, 25, 27, 28, 31 RCFC, 34 remote-copy target system, 100 remote-copy volume increasing size of, 155 removecpg CLI comm
176, 177, 179, 182, 183, 184, 186, 187, 188, 189, 190, 191, 192, 193, 194, 196, 197, 198, 200, 203, 204, 205, 206, 210, 211, 213, 214, 215, 217, 219, 222, 224, 226, 227, 228, 230, 232, 234, 237, 240, 241, 243, 245, 247, 255, 256, 257, 258, 259, 260, 261, 265, 266, 267 showrctransport CLI command, 37, 66, 261 showtask CLI command, 95, 96, 97, 98 showvv CLI command, 151, 164 simplifying administration by using volume groups, 110 SLA, 153 SLD configuration, 20 considerations, 56 quick recovery, 260 quick setup
T tape for synchronization and backup, 151 not supported with SLD, 151 target bidirectional remote-copy pair, 100 definitions, 99 target definition, 43 target failure with asynchronous periodic volume groups, 158 with synchronous volume groups, 157 target volumes automatically created, 105 creating, 154 deleting, 154 TCP/IP connections, 254 link connection time, 254 links, 26 text symbols, 277 thinly-provisioned virtual volume see TPVV throughput, 128 timeout errors, 156, 157 TPVV allocation limit, 109 crea
virtual machine migration, 136 Red Hat Linux, 133 virtual volumes, 105 creating, 105 limits, 106 limits in volume groups, 111 primary volume, 113 remote-copy use, 109 rules for creating for remote copy, 106 secondary volume, 113 vMSC configuration, 142 VMware, 132 persona, 133 volume groups configuring the synchronization period, 126 creating, for bidirectional remote copy, 88 creating, for M-to-N remote copy, 51 creating, for SLD remote copy, 66 creating, for unidirectional remote copy, 82 naming, 112 reas
