The first part of this (short) blog series covered the basics of VMware vSphere Metro Storage Cluster (vMSC) with HP 3PAR Peer Persistence. This, the second, part will cover the basic tasks to configure Peer Persistence. Please note that this blog post relies on the features and supported configurations of 3PAR OS 3.1.3! This is essential to know, because 3.1.3 got some important enhancements in respect of 3PAR Remote Copy.
On of the very first tasks is to create zones with between the Remote Copy Fibre Channel (RCFC) ports. I used two ports from a quad-port FC Adapter for Remote Copy. This matrix shows the zone members in each Fibre Channel fabric. 3PAR OS 3.1.3 supports up to four RCFC ports per node. Earlier versions of 3PAR OS only support one RCFC port per node.
RCFC port setup
After the zoning it’s time to setup the RCFC ports. In this case the RCFC ports will detect the partnering port by itself. I assume that the ports are unconfigured. Otherwise it’s necessary to take the ports offline. The command controlport is used to configure a port with a specific port role.
controlport config rcfc -ct point -f 0:2:1
controlport config rcfc -ct point -f 0:2:2
controlport config rcfc -ct point -f 1:2:1
controlport config rcfc -ct point -f 1:2:2
You can do the same with the 3PAR Management Console. After the RCFC port configuration the success of this procedure can checked with doing this on both StoreServs, you can check your success with showrctransport
or with the 3PAR Management Console.
Remote Copy setup
Now it’s time to create the Remote Copy configuration. The screenshots below are schowing the configuration of a bidirectional 1-to-1 Remote Copy setup. Start the wizard and select the configuration.
In the next step, the RCFC ports have to be configured and paired together. Simply connect the ports by selecting a port and pull a connection to the other port. Both ports have to be in the same zone.
A Remote Copy Group groups Virtual Volumes (VV) together to ensure I/O consistency. To create a bidirectional Remote Copy configuration we need two Remote Copy Groups. One from A > B and a second from B > A. I recommend to enable the “Auto Recover” option. This option is only visible, if the “Show advanced options” tickbox is enabled.
This screenshot shows the bidirectional Remote Copy configuration. Each StoreServ acts as primary arry for a Remove Copy Group and as secondary array for a primary Remote Copy Group on the other StoreServ.
If you already created volumes, you can add the volumes in this step. I will show this step later.
The last page shows a summary of the configured options. Simply click “Finish” and proceed with the next step.
After creating the volumes it’s necessary to add them to the Remote Copy groups. Right click the Remote Copy Group and select “Edit Remote Copy Group…”.
Select the volumes to add and check the box “Create new volume”. I recommend to use CPGs with the same characteristics as on the source system. I also recommend to use the same CPG as User and Copy CPG. Click “Add” and repeat this step for each volume that should belong to the Remote Copy Group. At the end click “Next”…
… and “Finish”.
Repeat the steps for the second Remote Copy Group and the volumes on the secondary StoreServ.
This screenshot shows the result of the configuration process.
A very handy feature of 3PAR OS 3.1.3 is that it creates a Virtual Volume Set for each Remote Copy Group. When a VV is added to the Remote Copy Group, it belongs automatically to the Virtual Volume Set and will be exported to the hosts. This screenshots shows the Virtual Volume Sets on both StoreServs.
Please ensure that both Virtual Volume Sets on both StoreServs are exported to all hosts (I recommend using Host Sets). If everything has been correctly presented 8 paths should be visible for each VMFS datastore: 4 active paths to the primary, and 4 standby paths to the secondary StoreServ.
Automate the failover
There are two requirements to automate the failover:
- Quorum Witness
- Enabled “Auto Failover” for Remote Copy Groups
The Quorum Witness is a VMware Appliance that needs to be deployed at a third site. The setup is really easy. Simply deploy the OVA and power it on. A short menu guides you through some setup tasks, like setting a password, assigning an IP address etc. When the Quorum Witness is available on the network, create a Peer Persistence configuration. Enter the IP address and select the targets, for which the Quorum Witness should act as a witness.
If everything went fine, the “Quorum Status” should be “Started”.
Now the automatic failover for the Remote Copy Groups can be enabled.
Select the groups and click the right arrow to enable automatic failover for the selected Remote Copy Groups.
That’s it! To test the failover you can use the 3PAR Management Console or this CLI command:
setrcopygroup switchover -t 7200-EDV1
With this command all secondary Remote Copy Groups on StoreServ 7200-EDV2 will become primary Remote Copy groups. If everything is configured accordingly, you will notice no or only a short IO interruption during the failover. An automatic failover will only occur, if a StoreServ loses all RCFC links AND the connection to the Quorum Witness. Otherwise there will be no automatic failover! The parameter “switchover” is only used for transparent and controlled failovers. It’s issued on the primary storage array. The parameter “failover” is automatically issued from the secondary storage system in case of a failover situation.
The basics tasks are:
- create zones for the RCFC ports
- configure the RCFC ports on each node
- create a bidirectional 1-to-1 Remote Copy setup with Remote Copy Groups on each StoreServ
- add volumes to the Remote Copy Groups
- present Virtual Volume Sets (that were automatically created based on the Remote Copy Groups) to the hosts
- deploy Quorum WItness
- create a Peer Persistence configuration and configure Quorum Witness for the StoreServs that belong to the Peer Persistence Configuration
- Enable “Automatic Failover” for the presented Remote Copy Groups
This is only a very rough overview about the configuration of a 3PAR Peer Persistence setup. I strongly recommend to put some brain into the design and the planning of the Peer Persistence setup.
Feel free to follow him on Twitter and/ or leave a comment.
Latest posts by Patrick Terlisten (see all)
- vSphere Distributed Switch health check fails on HPE Comware switches - April 30, 2018
- Demystifying “Interfaces on which heartbeats are not seen” - March 10, 2018
- Azure PowerShell vs. Azure RM PowerShell - March 6, 2018