Peer Persistence brings Metro Clustering to 3PAR Storage

This is part 3 of a multipart series focused on 3PAR storage from an EVA Administrator’s perspective. Check out parts one and two – Understanding the 3PAR difference in array architecture and Learning the 3PAR lingo for the EVA administrator. 

HP 3PAR Peer Persistence is the most exciting feature for me in the new 3PAR StoreServ 7000 series.  I’ve referred to it has a ‘holy grail’ feature to my sales team and to our internal team at work.  While its not the first to market with metro storage clustering, it brings the feature set to the 3PAR lineage and features a non-disruptive failover between the arrays.  VMware officially started supporting metro storage clusters in 2011 with a limited number of storage vendors and solutions and as of posting, 3PAR does not have official support stated from VMware, but it should soon.

Peer Persistence rides on top of the Remote Copy replication feature set and uses synchronous replication.  The two key pieces to the Peer Persistence solution are assigning the secondary copy the same volume World Wide Name (WWN) as the primary and the use of Asymmetric Logical Unit Assignment (ALUA) on the VMware side to recognize the active paths when a failover is invoked.  To a VMware host, you see active and standby paths to the VLUN thanks to the shared volume WWN.

EVA Administrators are experienced with ALUA for finding and using the optimized active paths to a LUN.  On the EVA, only one controller has true write access to the LUN and the paths to that controller are marked as “Active (I/O)” and the paths to the secondary controller are marked as “Active”.  The secondary paths would not be used for IO.

Within 3PAR, Peer Persistence uses the same ALUA technology to discover the active paths to the active array and to set the paths to the target/secondary 3PAR array into StandBy mode. It is also critical in the discovery of a switchover condition where the primary paths become blocked, ALUA issues a discovery command the the Secondary array’s paths are found as active.  With the 3PAR, all paths to the active array are labeled as “Active (I/O).”

Is Peer Persistence right for your environment?  Let’s start with the list of requirements:

• Close proximity of your two datacenters with large pipes and low latency.
• The ability to perform synchronous Remote Copy between your 3PAR arrays in 1-to-1 configuration.
  •  Requirements of Synchronous Replication
• The volumes exported from primary and secondary must share the same volume WWN.
• ESX hosts must be 5.0 or higher and must be exported with host persona 11 (VMware)

Clearly, this isn’t for everyone.  The fact that you must be within synchronous distances for replication is a deal breaker for many customers, but not all.

Setup Peer Persistence

Peer Persistence sets up just like any other Remote Copy scenario.  I won’t cover that in this post, but I suggest you check out the HP 3PAR Remote Copy Software User’s Guide for all the details on setting up Remote Copy in various scenarios and for more details on Peer Persistence.

After you have created your Remote Copy group with virtual volumes inside and before you export the volumes to the hosts, changes for Peer Persistence are necessary.  On the Primary 3PAR array, you will need to enumerate a list of the virtual volumes including their WWN.  You can display this in the 3PAR CLI using the showvv command.

[sourcecode]showvv -d <vv_name>[/sourcecode]

The output should be a single line including the WWN of the virtual volume.  I suggest that you highlight and copy the WWN for use in the next step.

Next you will assign the secondary virtual volume the same WWN.  Open a 3PAR CLI connection to the secondary 3PAR array and in this CLI environment, you will issue a setvv command.

[sourcecode]setvv -wwn <WWN> <vv_name>[/sourcecode]

On the secondary array, issue another showvv command and confirm that the WWN on the secondary now matches the WWN on the primary.

Once you have completed the WWN assignment on the secondary volume, you may start replication and export the Virtual Volumes to the hosts.  When exporting, ensure host person 11 (VMware) is used for all hosts.

Invoking a switchover

A switchover is easy.  From the 3PAR CLI, a single command will allow you to switch over an entire Remote Copy group of Virtual Volumes or all Virtual Volumes with Remote Copy targeted to a specific 3PAR array.  However, there are several piece of information you will want to check before issuing the switchover command.

To find the names of the Remote Copy groups and/or to see which Remote Copy groups are targeted towards a particular 3PAR array, you issue the showrcopy command in the CLI.   In the output, you will find the name of the Remote Copy group and the array it is targeted to replicate to.   A sample of showrcopy output is below:

With the information, you can initiate a switchover from primary to secondary with no interruption in service.  From a showrcopy output, you can determine which target 3PAR array is part of the synchronous replication (outlined above in green).  The target name can be used to failover all Virtual Volumes hosted by this 3PAR array to the target/secondary array for those VV’s.

Otherwise, if you want to issue the The switchover is initiated from the primary array for an Remote Copy group, so you will want to look at the Role column (outlined above in blue) of the Group Information in the output.  In this example, only sync_group_1 may be issued the switchover command on this 3PAR array.  To failover sync_group_2, you must connect to CLI on the System2 3PAR array.  To failover a Remote Copy group of Virtual Volumes, you have to issue a command using the Remote Copy Group name (outlined above in red). You should also ensure that Remote Copy is running and in Synced status by checking the SyncStatus column (outlined in orange above).  In our example above, you will need to wait for syncing to complete for localvv.0 and localvv.1 before issuing a switchover command.

Failover all volumes replicating to a Target 3PAR 

Taking the target 3PAR array name, outlined in the example in green, issue the following command:

[sourcecode]setrcopygroup switchover -t <target_name>[/sourcecode]

Using the output from our example, we would issue the following:

setrcopygroup switchover -t System2

Failover a particular Remote Copy Group

To switch a particular Remote Copy Group, take the remote copy group name – for instance sync_group_1  from the example above and issue this command in the 3PAR CLI:

[sourcecode]setrcopygroup switchover <group_name>[/sourcecode]

For our example with sync_group_1, you would run:

setrcopygroup switchover sync_group_1

Within a matter of seconds, the 3PAR arrays will fail from the primary to secondary and your active and standby paths will switch in VMware.

Behind the Scenes

Behind the scenes, the primary 3PAR array is in control of the synchronous Remote Copy. The primary array stops accepting IO on its interfaces, commits all writes, then swaps control to the secondary array which then opens its paths and begins accepting IO. At the same time, the VMware hosts are notified that the path is blocked and it initiates a ALUA discovery to find its active paths.

In part 4, we will focus on best practices for vSphere 5.1 with the 3PAR StoreServ 7200/7400 arrays.