2018-05-15 12:51 AM
With SMB3 support available on Windows OS releases Server 2012, WIN8 & later persistent handle support has become available. Since ONTAP9 continuously available (CA) shares have also become an option. There is however a caveat in TR 4100 (https://www.netapp.com/us/media/tr-4100.pdf) which states
"ONTAP 9 does not support persistent handles for use cases other than Microsoft Hyper-V over SMB and SQL Server over SMB".
We are curious about this statement. We have created standard CIFS File Shares with CA enabled and successfully performed multiple takeover and givebacks without disruption to CIFS activity. Testing the same shares with the CA option disabled was, as expected, disruptive. Does anyone understand why standard windows shares with CA enabled are not officially supported and\ or have any experience of using them in a production environment?
best regards, D
(Btw - I created a similar post on here yesterday which has disappeared!)
Solved! SEE THE SOLUTION
2018-05-14 02:06 AM - edited 2018-05-14 02:07 AM
Since the advent of Windows Server 2012 and Windows 8 embedded SMB3 support means that CIFS clients can use persistent handles. NETAPPs later OS releases support Continously Available (CA) Shares which can be enabled using a switch at either creation or at a later stage. However, as stated in TR4100,
"ONTAP 9 does not support persistent handles for use cases other than Microsoft Hyper-V over SMB and SQL Server over SMB"
This statement is quite clear in terms of what is supported and what is not supported but it does not provide any explanation as to why a standard CIFS File shares with CA enabled is not a supported scenario. We have tested configurations in our LABs where standard File Share have CA enabled and these shares remained available throughout multiple takeover and giveback scenarios. I also tested Shares that were without CA enablement and, as expected, we were required to terminate CIFS before takeover\ giveback was possible.
Can anyone enlighten me as to why Ontap 9 does not support persistent handles in case other than Hypher-V and SQL when our lab enviroment shows that is can work? We have searched NETAPPs support documentation extensively and since we went to ONTAP 9 we have asked a number of NETAPP support personnel for an explanation. However we have never managed to get a satisfactory explanation.
many thanks, D
2018-05-15 03:47 AM
it's more of a protocol thing rather NetApp requirement. According to these two below, the CA never designed for end-user usage in mind.
Note the performance issues on low speed networks. offline files and other compatibility issues.
i can attest that i had issues with saving SQL backups dumps from old SQL servers (likely 2008 but can't remember) on a Microsoft SOFS. Microsoft refused to support it (even as it was a paid advisory ticket) and stated that SOFS and the CA feature are only intended for Hyper-V and SQL back-end usage.
2018-05-15 08:23 AM
Some really interesting reading in both those technet pages. I was not aware of this - "Starting in Win10, when you connect to a CA-enabled share, there is no longer an option to use offline files. No matter the settings, files will not cache and the user will not run into timeout problems." As all of our clients are Win10 this is both a good thing and a bad thing as I suspect our user community do use them. The references to performance concerns are worrying as is the reference to non MS Office application use as we are currently moving to Google Apps. You have also mentioned that Microsoft stated that "SOFS and the CA feature are only intended for Hyper-V and SQL back-end usage which tallies with what NETAPP are saying. It is frustrating how unclear the various vendors documentation is in relation to this issue.
thanks - your response has been very useful.
2018-05-16 04:45 AM
ONTAP maintains a per-client set of synchronised locks for enabling continuously available shares, which use up NVRAM on each controller in a HA pair serving data.
With a limited number of HyperV servers using a limited number of files, we've been able to model and test it to our satisfaction.
With several thousand general purpose clients, opening a totally unknown set of files, it's more difficult to model, and situations may arise where the feature slows down the controllers too much (by eating NVRAM and forcing more frequent checkpoints).
For "general purpose" use, the clients will generally re-try the connection and deal with the slight interruption better than an enterprise app running inside a Hyper-V or SQL environment would.
We know we have customers that have turned on CA for general purpose storage, and don't have problems, sometimes in very large environments, but as we tend to be conservative (as most storage admins are), it is not a "supported" use case. We have fixed BURTs that only occur with CA shares being used outside this use-case, so if it can be proved that there is a technical issue (vs performance) only present when it is enabled, you may raise a support case.
I hope this helps with your analysis of if this feature is right for your environment. Please let me know if you have any further questions.