Thanks Mary, the project is on hold until we can determine if there is a configuration issue or a technology issue. In the mean time we found the following... but each indicate some performance hit but a 500-600MBps delta is not a minor variance
:)
Article 1: https://blogs.technet.microsoft.com/josebda/2014/08/18/using-file-copy-to-measure-storage-performance-why-its-not-a-good-idea-and-what-you-should-do-instead/
5.4. Create a non-CA file share
If your file server is clustered, you can use SMB Continuously Available file shares that allow you to lose any node of the cluster at
any time without impact to the applications. The file clients and file servers will automatically recover though a process we call SMB Transparent Failover.
However, this requires that every write be written through to the storage (instead of potentially being cached). Most server workloads
(like Hyper-V and SQL Server) already have this unbuffered IO behavior, but not file copies.
So, CA has the potential of slowing down file copy operations, which are normally done with buffered IOs.
If you want to trade reliability for performance during file copies, you can create a file share with the Continuous Availability property
turned off (it’s on by default on all clustered file shares).
In that case, if there is a failover during a file copy, you might get an error and the copy might be aborted. But if you don’t have any
failovers, the copy will go faster.
For server workloads like Hyper-V and SQL Server, turning off CA will not make things any faster, but you will lose the ability to transparently
failover.
Note that you can create two shares pointing to the same folder, one without CA for file copy operations only and one with CA for regular
server workloads. Having those two shares might have the side effect of confusing your management software and your file server administrators.
Article 2: http://windowsitpro.com/windows-server-2012/new-ways-enable-high-availability-file-shares
Keeping file shares available. SMB Transparent
Failover consists of several configuration changes and new technologies. One benefit that file servers traditionally offer clients is buffering of data writes to disk. This element provides faster acknowledgments to client write requests because the file server
caches the write operation in its volatile memory (meaning that if the server loses power, it loses the data), tells the clients that the data is written so that the client can carry on its work, then performs the write in the most optimal way. Certain applications
always open handles with this caching disabled, through the use of the FILE_FLAG_WRITE_THROUGH attribute when creating the handle, ensuring that data is always written to the actual disk before receiving acknowledgment and avoiding any volatile cache.
SMB Transparent Failover sets the FILE_FLAG_WRITE_THROUGH as the default for all created handles, eliminating the use of volatile memory cache. Now, there might be some slight performance implications because the cache is no
longer used, but the assurance of data integrity is a good trade for the
possibility of a slight performance degradation. (slight understatement
J)
