2014-04-08 03:24 PM - edited 2015-12-18 12:24 AM
Are multiple secondary interfaces supported from the same source filer to multiple destinations?
When I run this with 4.1 with a config that has snapmirror destinations in filer2 and filer3 I get a failure. It seems that SC sends zapi call to filer2 to update snapmirror destinations, but in the api call specifies the destination filer as filer3.
ERROR: STORAGE-02085: Updating SnapMirror relationship filer1-wan:my_vol -> filer3:my_vol_m] failed with error [netapp.manage.NaAPIFailedException: Illegal destination filer specification: filer3. Destination filer, if specified, must match the local host: filer2. (errno=13101)].
2014-04-15 04:56 AM
Hari tested this in his environment and it worked ok for him.
Here is what he sent me:
I tried secondary interface in my lab env, it worked for me with multiple secondary interface with same source
Hope this helps.
2016-04-12 01:35 AM - edited 2016-04-12 01:42 AM
Hey there, sorry for hijacking this thread, but in our tests this is not working, either with SC 4.1 nor with SC 4.3
When I define one SECONDARY_INTERFACE it works fine.
However, as soon as I define multiple ones, it only uses the last defined one and doesn't see the other destinations anymore.
No matter which syntax I tried, it only works when I only define a single one.
Next thing is: If I have defined a global config, the SECONDARY_INTERFACES parameter in the single backup configs is ignored, it pulls it from the global config, no matter what. If no SECONDARY_INTERFACES are configured in the global config, it stays empty, even if defined in the single config, too
EDIT: also the following does not work when having configured a secondary interface.
PRIMARY:/vol/src/- to PRIMARY:/vol/dst/dst
When the SECONDARY_INTERFACES parameter is set, SC seems to expect the destination to be the name defined there for all relationships.
So when source and destination volume are on the same filer it fails because this one is ignored as the destination name (which is the source name) doesn't match the one configured in the parameter. Which again is bad when combined with global configs, so we would need to configure credentials again in each job which defeats the purpose of global configs.