SRM 5 and SRA 2 error "cannot be matched to a remote peer device"

[PETERMCCLOUD]

Hi there,

I am new to NFS and am in the process of setting up a DR environment between two data centres with vmware SRM 5.

The production data centre has an NFS connected vSphere ESXi 4.1 cluster with an FAS3210 NAS. On tap version is 8.0.2

The DR data centre has an older IBM N-Series N3300 fibre channel connected ESXi 4.1 cluster.  On tap version of the SAN is 7.3.4.

We are using Snapmirror to replicate at the QTree level.

We have installed SRM 5 and the SRA 2 adapter and have set up the arrays and things appear to be OK until we attempt to set up the array pairs. 

When we do we get an error message "Device '[volumename]' cannot be matched to a remote peer device"

We have checked the exports settings on the NFS side and that appears to be correct.

Is it possible to create an SRM array pair using NFS at the production site and FC LUN's at the recovery site?

[columbus_admin]

I am by no means an SRA expert, but I have looked at the perl scripts that make it up.  The SRA and SRM need to look for the same thing on both sides, so FC to FC, NFS to NFS.  Without this, compliance is going to be a gamble.  We have a nested export on an NFS volume with no datastores, but SRA/SRM knows that is an issue if we did have NFS datastores and it causes a bit of grief by failing to update SRM groups(there is a workaround, it stinks, but it works).

This ensures that the process can be followed, imagine how complicated an automated system would have to be to search every protocol in the middle of a disaster event to make that happen.  Your time would HAVE to go way up, just to check for all the permutations.  It couldn't verify exports from an FC to NFS datastore is just the first issue I could think of.

One major thing I would look at is that there is a "time" issue if you are using 64bit aggrs and qtree replication to 32bit aggrs when you split the mirrors. Here is a LINK to the discussion.  I know it exists going from 32bit to 64bit, not sure about the opposite direction.

- Scott

[sharmas]

I see some problems here with the setup. Its not possible to replicate between FC and NFS. You can have FC LUNs replicate to iSCSI or vice versa in case the idea is to ethernet on one of the sites. Also you can't replicate from a higher Ontap major release to a lower. Eg: you can replicate between 8.0.3 to 8.0.2 but not 8.0.2 to 7.3.4.

SRM basically automates failover in case of a DR and completely depends on the Storage level replication to work. So you need to setup the SnapMirror first before attempting to setup SRA. All the relationships need to be in place beforehand.

[columbus_admin]

Sharmas,

     He is replicating at the qtree level so FC to NFS does not matter, replication is below the protocol layer.  How he is going from 8.0.x to 7.3.x is interesting I have to admit, most likely because it is an IBM N series.

    He also states all the replications are in place and it fails inside SRM.  The SRM checks to ensure consistency within the protection group is what is failing based on what he wrote.  I still believe that the issue is because SRM looks for identical configurations between replication stores, thus NFS on one side and FC on the other would not work.  The SRA scripts all appear to be "if A == B, then ok"(obviously this is very oversimplified) types of checks.

- Scott

[sharmas]

Ontap doesn't stop one from replicating at QTREE or Volume Level. It doesn't care if the data inside it is File data or block data. What I meant was that the access should be either block or NAS at both sites. One can't access NAS data using a Block protocol as the host will not find any LUN to connect to.

That particular error that PETERMCCLOUD is getting is because SRM/SRA isn't able to find the export options on the DR site as the DR site is FC and not NFS. It is because he is trying to use different protocols at the two sites. As far as replicating from higher release to lower release is concerned, it is something that NetApp doesn't support.

[sharmas]

Just wanted to correct myself here. One can replicate at Qtree level using Qtree SnapMirror without any ONTAP version restriction. Its the Volume SnapMirror (VSM) that has the version restriction I described above.

Regards

Satinder

[keitha]

SRM also only support VSM no QSM...Several things need adjusting.

[sharmas]

I just checked SRM supports QSM too. Section 5.4 here http://media.netapp.com/documents/tr-3671.pdf

[nsitps1976]

Does SRM work between FAS and N Series? Can anyone answer this?

[sharmas]

Yes SRM works with N-Series and FAS as long as you are able to replicate between the sites and follow the best practices documents here http://media.netapp.com/documents/tr-3671.pdf

They use the same SRA.

[nsitps1976]

thanks for this - ibm has a diffrent SRA than netapp, are you saying the same one should be used for both the ibm and netapp system?

[sharmas]

Yes, use either of the two for both FAS and IBM N-Series. Its using the same code. The difference between IBM SRA build and NetApp FAS build is only in installation package. Changes include SRA name, UUID, path etc. Since UUID differs for IBM and NetApp build, SRM will not able to match both builds in case you use a different SRA for FAS and a different one for N-Series.

[nsitps1976]

Very helpful, thanks. I will use netapp SRA on all systems. Thanks again.

[vibh007]

Run replication then check

[MNazri]

Just to add the below requirements for SRM 5 and SRA;

1. The hostname referenced in snapmirror.conf must match the actual hostname. If it does not (as in our case where the hostname is uppercase and in snapmirror.conf its lowercase), then SRA will have a problem discovering the array device.

2. Ensure that snapmirror relationships are not in a transferring state. If there are, transfers need to complete to confirm that SRA is able to pair the devices

3. Remove unneeded export statements for RO snapmirror destinations. Having these export statements may cause issues when attempting a Recovery operation in that the destination hosts may not be able to mount the volume due to the existing export statements. It's best to remove these and to allow SRA to create them during the Recovery operation.