Re: SVM_DR Snapshots not deleted on source
Cannot set DNS on Node
Hello,
I am new to NetApp and this forum. And this is my first question so forgive me if I ask something silly.
We have 2 nodes currently and I need to create a cluster and join these 2 nodes.
Model: FAS2520
Version: NetApp Release 8.3.2P2
Node 1
e0M > IP assigned > Pinging
e0C > IP assigned > Pinging
Node 1
e0M > IP assigned > Pinging
e0C > IP assigned > NOT Pinging, but link is up (destination host not reachable)
On Node 1, I can see DNS show output configured.
But on Node 2, I dont' see DNS entry. The issue is I don't get any option also to set DNS;
::> vserver services name-service dns create -vserver Default -domains <domain name> -name-server <name server IP>
Error: invalid argument "-domains"
But this same option I get when run on Node1.
Since there is no data as of now I can do anything on nodes.
On Node 2, I also did > reboot > wipealldata > Reinitialized disks > But same issue
Please help, thanks.
It appears "volume move" will cause massive data loss on large volume
We have been using "volume move" to shuffle volumes around our cluster, being told that it is a great tool, and will cut-over cleanly.
Well, I've found out that it isn't so clean. When "volume move start" is executed, it appears to create a snapshot for the copy. It then proceeds copying data from that snapshot, and including snapshots which existed prior to the "volume move start" snapshot. Once it is ready to trigger the cutover, it updates, I believe, from the origination snapshot, cuts-over the volume, but does not update files created or modified after the origination snapshot.
This has been wreaking havoc with our moves, with users telling us their data has reverted to a prior time; I now believe the users are correct.
-Unfortunately, I could not find any documentation or TR's which address the issue. So I must assume it is an issue with the volume move command.
-One caveat, is we did not have snapmirror licensed on the entire cluster. Perhaps that would cause "volume move" not to be able to update, however, there should have been a note in the documentation.
If anyone at NetApp can address this, that would be great. I'd like to know if "volume move" can be used in future, or if I need to go back to good old Volume SnapMirror.
Re: It appears "volume move" will cause massive data loss on large volume
If you're seeing this behavior I would open a ticket, that's not at all how vol move is suposed to work. I have moved 100s of volumes, including a lot of NFS and LUN based VMware DataStores with zero issue.
Give these a read over:
https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-98BCA1F4-9366-4D89-85BA-AD732375EA81.html
https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-26FE8933-0EB0-450C-BCB4-10DAE3552878.html
Are you seeing any errors? what happens after the move, are you having to restore?
Re: It appears "volume move" will cause massive data loss on large volume
Sorry, your links come up with unauthorized access.
No errors at all; the automatic triggers starts and completes.
However, viewing snapshots, the volum move snapshot is created at the time the "volume move start" is executed. It does not change. With Snapmirror, I find that all snapshots past the creation are locked, which tells me "vol move" is not using volume snapmirror.
Re: It appears "volume move" will cause massive data loss on large volume
That's weird, so am I now... sorry about that.
Give this a shot, it's the parent topic link. https://library.netapp.com/ecmdocs/ECMP1368845/html/GUID-A03C1B1E-3DE2-455D-B5AD-89C1389EF0C8.html
Re: It appears "volume move" will cause massive data loss on large volume
Well, DataMotion, sounds like VMware. But beyond that, it still does not talk about snapshots and snapmirror requirements.
There should be a HUGE banner in front of this command, that apparently based on the link you sent, it will not work with NFS/CIFS shares.
- Actually, it works, with CIFS/NFS active
- It does not fail.
- It does not copy anything after the initial "volume move" snapshot is created
Re: It appears "volume move" will cause massive data loss on large volume
Snapmirror has nothing to do with vol move. They might use some of the similar mechanism under the hood, but they are separate.
Found more modern versions of the docs specifically on ONTAP (clustered):
but I asure you that moving volumes around on Clustered ONTAP is non-disruptive.
Re: "network ping -node cluster1-01 -destination remote IC IP"is not working
Based on the syntax, I don't have to use "-vserver xx -lif yy" as the option, I can use "-node node-1" as the option as following:
network ping -node node-1 -destination "remote IP"
my problem is, on this cluster, the command above doesn't work. On the other cluster, it is working fine.
Why?
How could I know which lif will this command be using to send ping packets out?
Re: Cannot set DNS on Node
You will need to cable the cluster ports between the two controllers and then I would just start over and re-run opt 4 .
Please see this to verify the basic network and SAS cabling:
https://library.netapp.com/ecm/ecm_get_file/ECMP1189305
Once both nodes have been re-initialize run through the cluster setup wizard:
https://library.netapp.com/ecmdocs/ECMP1610202/html/cluster/setup.html
You'll create the cluster on node 1, and node 2 will join that cluster.
In C-dot (cluster mode) DNS isn't set per node, it's set per vserver (SVM).
Re: discrepancy btw volume size and transferred size by SnapMirror
Re: File Auditing using ELK stack
Re: Data Ontap SMI-S Agent is not running. HTTP Error (401 Unauthorized) is showing.
Re: New TR Released:TR-4650: NetApp ONTAP and Splunk Enterprise
Thanks for the Information!
Re: New TR Released:TR-4569: Security Hardening Guide for NetApp ONTAP 9
Thanks for the information!
Re: Cannot set DNS on Node
Connection is switchless.
I am reinitializing both the nodes now, will update how it goes.