SMVI SnapMirror Update over private SnapMirror network

[malcolmpenn]

We are currently using a dedicated private IP network for SnapMirror between two sites and have defined this ifgrp interface in the /etc/hosts and this interface ip address as the snapmirror.access on the primary filers and create a snapmirror relationship on the destination filers.

Everything work as expected, we have completed the first baseline transfer and our volume was mirrored to the remote location.

Our private SM network between sites are on 10.1.10.x and this network is not available to any external hosts.

We then defined all the filers (local and remote) within SMVI but from our V-Center / VSC server we are only able to see the remote filers over our management network 192.168.101.x

We then create a backup of the datastore/VM through SMVI and used the option "Update SnapMirror" but of course the snapmirror update did not occur, until we added the management interface IP address to snapmirror.access on the primary filers and then everything worked okay.

I don't really want to open up our private SnapMirror network to our V-Center / VSC server but currently can't see any other way to using SMVI to update the snapmirror relationship using our snapmirror dedicated IP network because SMVI can only see our remote filers over the 192.168.101.x network.

Has anyone else found a work around for this ?

Many thanks

Malcolm

[mwalters]

Hi Malcolm,

So: clearly with CLI-based replication, you "simply" need to ensure the name resolved by SnapMirror (in SnapMirror.conf) ensures the private address is used.

It looks like you can do something similar with OnCommand 5.0:

See https://now.netapp.com/NOW/knowledge/docs/DFM_win/rel402/html/faq/index.shtml#_16.8

You can set DataFabric Manager server options hostPreferredAddr1 and hostPreferredAddr2 for each host involved in SnapMirror based backups.

Use dfm host set command from the CLI.

For example:

dfm host set myhost.example.com hostPreferredAddr1=1.2.3.4  hostPreferredAddr2=1.2.3.5 

Protection Manager will use only those IP addresses for Volume SnapMirror (VSM) or QTree SnapMirror (QSM) based data transfers.

Those settings need to be set before Protection Manager has created the QSM or VSM relationships. Protection Manager then creates appropriate Disaster Recovery Manager connection policy for those relationships.

If the SnapMirror relationship has already been created, you can create or modify the Disaster Recovery Manager connection policy for that relationship directly using Disaster Recovery Manager.

Hope this helps!

[malcolmpenn]

Hi Mike,

Thanks very much for your reply.

We have previously setup Protection Manager to use the dedicated SM interfaces (using the dfm host set ) as we needed to test application integration with SMSQL & Exchange and everything worked as expected and the SnapMirror was updated to the remote location over the private SnapMirror interfaces / network.

But when protecting VMware we couldn't fine a method of integrating SMVI with Protection Manager so therefore we tried testing SMVI with the "Update SnapMirror" feature of the policy and then we were going to import the snapmirror relationship into Protection Manager to monitor the lag period but hit the problem above. Ideally we wanted to avoid created SMVI policy backups/snapshots on the source and then needing a seperate Protection Manager schedule to update the SnapMirror.

In order to provide the integration between VMware and On-Command / Protection Manager we have now reviewed the On-Command host plugin for VMware, could I be correct in thinking this feature / plugin will give us the integration we require to provide the solution above without needing to play around with host resolution on the CLI and we can simply ignore directly using SMVI and create everything within On-Command Core / VMware plugin and the SnapMirror interfaces used will be controlled by defining the "hostPreferredAddr1" as you suggested above.

Cheers

Malcolm

[fenton · Accepted solution]

Hey Malcolm

Yes this is one of the new features in OnCommand 5.0 - be sure to use the Host Package 1.1

http://now.netapp.com/NOW/knowledge/docs/oncommand/relhost11/pdfs/workflows.pdf

The guide as to the capability is here - essentially the integration works in a very similar way to SME/SMSQL Protection Manager integration so the same option on the snapmirror hostPrefferred address should work fine

Cheers

Rich

[malcolmpenn]

Hi Rich,

Having few problems with bring this all together, have re-tested applying the settings within DFM to set the Preferred IP address to be the IP of the snapmirror interface of the filers but it still seems to trying to use the options snapmirror.access configuration. The volumes which I am testing are between hhnetapp01 & dpnetapp01

C:\Users\snapdrive>dfm host get hhnetapp01

Preferred IP address 1:                      10.11.3.65

Preferred IP address 2:

Primary IP Address:                          192.168.5.80

C:\Users\snapdrive>dfm host get dpnetapp01

Preferred IP address 1:                      10.11.3.67

Preferred IP address 2:

Primary IP Address:                          192.168.103.160

Then I am having what seems to be an connection (http/https) issue between On-Command Core server and the On-Command Host (V-Center) server, the only error shown in the job is:

"Error 403 fault: SOAP-ENV:Server[no subcode]

"HTTP Error"

Detail: HTTP/1.1 403 Forbidden

Then when I run "dfm hs diag <IP of Host (V-Centre)>" it returns that HTTPS has failed and Plugin Reachable is Unknown 😞

Any ideas ?

Cheers

Malcolm