I don't think you will be getting that the way you think.

SnapMirror in Clustered ONTAP is vastly different.
For starters, you are supposed to have at least one Intercluster LIF per node.
This is because when SnapMirror kicks off, it will use the InterCluster LIF on the node that the volume actually resides.

If you do a "vol move" from node 1 to node, the next time, SnapMirror will use the InterCluster LIF on node 2.

Same idea goes for the destination IP. It will go to where ever the volume/aggregate resides.

To get the source address, you will need to do some calculations:
source volume name -> aggregate name -> aggregate owner -> intercluster LIF on node owner.
That would be your source address. Again, if the volume changes nodes, then the source address will change!


--tmac

Tim McCarthy, Principal Consultant

Proud Member of the #NetAppATeam

I Blog at TMACsRack


On Wed, Jan 3, 2018 at 11:11 AM, Ehrenwald, Ian <Ian.Ehrenwald@hbgusa.com> wrote:
I've been working on this off and on between my regular duties, then delayed by holiday breaks, etc.

Something I haven't been able to figure out is how to programmatically get a Snapmirror relationship's source cluster management address hostname (or even just an IP address).  I can easily get the source vserver name, source volume name, and even a pre-constructed combination of the two from what Get-NcSnapmirror returns when run against the destination controller.

In essence, I want to be able to pass to this script three arguments: Current Snapmirror destination cluster mgmt address, current snapmirror destination vserver, and current Snapmirror destination volume.  Then do some stuff to extract the rest of the required information out to reverse the relationship and resync, such as current snapmirror source cluster address, current snapmirror source vserver, and current snapmirror source volume.  I'm 66% of the way there, it's the current snapmirror source cluster address that I can't see to pull out of anywhere.

I was playing around with Get-NcVserverPeer when run against a Snapmirror destination, but I can't seem to get what I want there.

Any hints from people who have done this before?  Thanks so much.


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948 / ian.ehrenwald@hbgusa.com


________________________________________
From: Ehrenwald, Ian
Sent: Thursday, December 14, 2017 11:40:41 AM
To: toasters@teaparty.net
Subject: VMware SRM + NetApp SRA + NetApp WFA?

This isn't 100% NetApp related, more like 60%, but I think it's still a relevant topic of discussion that others may eventually benefit from too.

I've been tasked with setting up DR for a set of VMware VMs at our primary data center by replicating them via SnapMirror to our secondary data center.  Normally I'd just use VMware SRM with the NetApp SRA, set up Array Based Replication within SRM, and be done with it.  Let SRM and the SRA take care of test, failover, reprotect, etc.

However, the sticking point is that a lot of the protected VMs use in-guest NFS mounts for things like database volumes or application binaries and SRM doesn't know what to do with those SnapMirror pair volumes because they're not VMware datastores.

My initial thought was to use some PowerShell with the NetApp PowerShell Toolkit in the SRM Recovery Plan for each individual VM pre-boot to connect to the SnapMirror destination filer, break the SnapMirror(s) that the VM uses, mount the volume(s), set export policies, etc.  Then figure out how to correctly do resync and reprotect without blowing things up.

I got as far as the first part in PowerShell (connect to the destination filer, break the mirror) and thought to myself that this was stupid.. I'm re-inventing the wheel.  Surely someone else out there must have done this before and there is a pre-existing solution?  I spoke with a NetApp tech support engineer that I happened to have a case open with already regarding the NetApp SRA and he was able to come up with a suggestion from another engineer: Call WFA from SRM in each VMs recovery plan to break the SnapMirror for the volumes required for the VM to work, then also use WFA in the cleanup and reprotect plan to do that work.

Has anyone else done something like this?  I have a feeling that I'm not breaking new ground with this task.  Implementing it wrong has pretty severe implications, though, so I'm not eager to mess it up.


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948 / ian.ehrenwald@hbgusa.com

This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters