A challenge for SMSQL lovers...
I have 3 SQL servers of 30 in total all running Snapdrive 7.1.1, SnapManager 7.2 with these 3 having issues connecting to a newly implemented 8.3.2 cluster/SVM used for Snapvaulting. I have had a Netapp technical case open, a Partner Helpdesk case after being told it was configuration by tech support and then back to tech support, escalated and now awaiting another escalation.
The issue is in adding credentials for these 3 servers to this SVM either via HTTP or HTTPS, Snapdrive hangs for 10 minutes before reporting various communication errors including "unable to get CDOT version". If default credentials are added in with the correct details for this clusters vsadmin account and then iSCSI connection attempted, it reports the same errors after a similar 10 minute timeout. Connection to non Snapvault/production SVMs within the same datacenter works.
For the 3 servers with issues, we have in summary:
We have checked Snapdrive configuration including checking connection to mgmt. LIF of SVM is being used as it was
Checked iSCSI interfaces are setup and added a secondary as one did not exist
Checked vsadmin account is setup correctly and it was
Checked DNS and tried via IP with the same result, tried many host file entry edits to test over past week and no changes. Resolution/reverse resolution is the same as for servers without the issue
Checked network route and is taking the same path as data is from servers without the issue
Observed that connection via HTTP or S is established in netstat –a output
Saw no evidence in logs on storage using event log show *iscsi*
Created new account as a test with vsadmin role, no change
Tried Snapdrive 7.1.3 and 7.1.1 both compatible with CDOT 8.3.2, circumnavigated Snapdrive via adding the ISCSI connection address directly into MS ISCSI Initator as a discovery portal which allowed connection directly through that software
Rebooted filer and made no difference
Created new SVM, tested from servers without issue and could connected, tested from 3 servers with issue and could not
Saw that in wireshark traces the "Client Hell" SSL headed packet is not replied to from the cluster with the usual "Server Hello, Certificate" message suggesting comms are stalling somewhere - this is where it is at with Netapp.
Any ideas on anything else to try? Let me know if you want any further data, I am in this for the long haul..
Cheers!