Hi Tim Thanks for the speedy reply.
Forgive me, but I don't see source volume name, source aggregate name, source aggregate owner, or source intercluster LIF in the object properties that Get-NcSnapmirror returns. I'm sure I'm misunderstanding where you're going with it. I don't see how I would get that information at all, just given the input parameters of current destination cluster mgmt, current destination vserver, and current destination volume.
The reason I'd like to get the source cluster management hostname out of this is so I can Connect-NcController to it, then run Get-NcSnapmirrorDestination against it to verify that both sides of the Snapmirror relationship agree upon the state of things before proceeding. Then, I'd run Remove-NcSnapmirror against the current destination, then Invoke-NcSnapmirrorRelease against the current source, then New-NcSnapmirror against the current source to turn it into the destination side, then Invoke-NcSnapmirrorResync against the current source to actually do the reverse resync.
I know all of this works, because when I manually feed my script the information I am trying to programmatically get, it succeeds in both directions, and I can flip flop all day. However, I want to reduce the number of human inputs as much as possible for this critical operation, and the more that can be determined by a machine instead of a stupid human, the better :)
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: tmac tmacmd@gmail.com Sent: Wednesday, January 3, 2018 11:30:00 AM To: Ehrenwald, Ian Cc: toasters@teaparty.net Subject: Re: VMware SRM + NetApp SRA + NetApp WFA?
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 #NetAppATeamhttps://twitter.com/NetAppATeam
I Blog at TMACsRackhttps://tmacsrack.wordpress.com/
On Wed, Jan 3, 2018 at 11:11 AM, Ehrenwald, Ian <Ian.Ehrenwald@hbgusa.commailto: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.1948tel:1.617.263.1948 / ian.ehrenwald@hbgusa.commailto:ian.ehrenwald@hbgusa.com
________________________________________ From: Ehrenwald, Ian Sent: Thursday, December 14, 2017 11:40:41 AM To: toasters@teaparty.netmailto: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.1948tel:1.617.263.1948 / ian.ehrenwald@hbgusa.commailto: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.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toastershttp://www.teaparty.net/mailman/listinfo/toasters
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.