3PAR StoreServ Storage
cancel
Showing results for 
Search instead for 
Did you mean: 

Trouble using Remote Copy and non-RC volumes at the same time

SOLVED
Go to solution
3PAR_Timo
Occasional Collector

Trouble using Remote Copy and non-RC volumes at the same time

Hi there.

Situation:

  • 2x 3par 7200 running synchronous remote copy for multiple volumes. Both systems attached to multiple Hyper-V clusters via FC fabric. Everything fine so far.
  • Exporting a VVOL from 3par-A (the one holding the active part of the RC-group) to the cluster works fine. VVOL is reachable from different (all) Hyper-V cluster nodes.
  • Exporting a VVOL from 3par-B to a single cluster node works fine. VVOL is accessible. Once added to the Hyper-V cluster, only this node can access it via FC (MPIO), while the other nodes report trouble and failback to so called redirected IO (i.e. accessing the volume redirected over ethernet via the one and only node that has direct FC access to it).

Goal: Have several VVOLs in RC and some non-RC VVOLs on both storages, in this case: get it working with 3par-B and the cluster hosts.

Any hints?

Thanks in advance. Timo

3 REPLIES
Sheldon Smith
Honored Contributor

Re: Trouble using Remote Copy and non-RC volumes at the same time

First, the non-RC VVs are irrelevant. It sounds like your problem is with the VVs in Remote Copy Groups (RCG).

While all base VVs are inherently read/writeable (RW), the secondary volume of a RCG is set by Remote Copy to be read-only (RO). Windows normally gets "annoyed" with an un-writable volume.
Depending on the versions of firmware running on the 7200s, and the versions of Microsoft Windows, it is possible to add the volumes in an RCG in such a manner that the volume pair appears to the host as a single disk and the direction of the RCG can be manually changed using a "setrcopygroup switchover" command. The precursor to automatic switchover with Peer Persistence.

This requires:

  • the Microsoft Windows hosts have a persona of 15 "WindowsServer" on both 3PAR-A and 3PAR-B
  • the Secondary volume of a volume pair has the same LUN WWN as its Primary volume

Once both Primary and Secondary volume are exported to a host, they appear as a single disk. Primary paths will show active, the Secondary will show as standby.

See the Hewlett Packard Enterprise Information Library for all related documentation.

  • HPE 3PAR Windows Server 2016/2012/2008 Implementation Guide
  • HPE 3PAR Remote Copy Software User Guide

Note: While I work for Hewlett Packard Enterprise, all of my comments (whether noted or not), are my own and are not any official representation of the company.
----------
If my post was useful, click on my KUDOS! thumb below!
3PAR_Timo
Occasional Collector

Re: Trouble using Remote Copy and non-RC volumes at the same time

Sheldon, thanks for your reply.

Actually, all remote copy VVOLs work just fine. They are functioning the way you described for quite some time now. Windows shows 4 active and 4 standby paths for those volumes.

Now I wanted 2 volumes which should not be part of any remote copy group. It's not required in order to fulfill the business case, instead increased performance is necessary (which will be provided having them non-RC on both 3pars).

As I mentioned, the first attempt was successful: New VVOL on 3par-A, exported to host set, one of the cluster nodes utilized to initialize and format the volume, adding to cluster, cluster is happy with that volume.

The second (failed) attempt was: New VVOL on 3par-B, exported to host set, one of the cluster nodes utilized to initialize and format the volume, addint to cluster - everything fine so war, but: Bringing that cluster disk online is only possible on the node which has been contact to it first. All other nodes can not reach the VVOL via FC, so they failback to the so called redirected IO mode of Windows clustering - which I have to avoid.

Therefore, any further advices will be great.

3PAR_Timo
Occasional Collector
Solution

Re: Trouble using Remote Copy and non-RC volumes at the same time

Alright, situation is resolved: VDS rescan was required. In order to provide further info, I wrote a blog article upon that topic at http://timo.dgtl.de/2017/05/shared-volume-io-resumed-no-direct-io-mode.html