I have a customer that has been experiencing latency on an application that they have been running that launches from a CIFS file share at the home office over a 40msec WAN connection. From packet captures, we can see that the WAE is in fact optimizing the file read/writes for the files the application is calling but it still is sending the Query_Path_Info, etc calls to the origin server as would be expected for file coherency.
The question here revolves around DFS. The customer would like to place a DFS server in the remote office and run the application from the DFS server share. Will this help at all by mitigating the need to send the query packets across the WAN?
If the DFS target (i.e. the origin server where the data resides) is still on the other side of the WAN, your users aren't likely to see a significant performance improvement by having their DFS referrals answered locally.
What is your overall request hit rate ('sh stat cifs requests')?
Thanks for the quick reply. What if we were to replicate a copy of the data to the DFS file server at the remote site and use DFS/FRS to maintain file coherency? We were planning on trying this for the files that the application was calling off of the share. The plan was to use DFS to fool the client application into using the local file share at the remote site and then that share would use DFS/FRS to maintain consistency. Would this help? Sorry, I am not much of MS guy.
Also, if we did use DFS/FRS to replicate a copy of the data to the remote file server wouldn't we need to configure core/edge on the waes at each end of the connection?
I don't have access to get the "sh stat cifs request" at this time. I will see if i can get them tomorrow.
Yes, we have been running "serverless" at the remote site using this application for about a week or so now.
First tests from the remote site were very slow without any acceleration. Then we installed WAAS with CIFS acceleration and they were noticeably better but still not as fast as the customer was expecting.
One of the main issues with the applications transactions from what i can tell is that the files that are being called are numerous and quite small <160KB each. When I did a packet capture I noticed that more than half of the packets were Query_Path_Info or something similar and all were exhibiting RTT that seemed indicative of a WAN round trip time. I pinged TAC and they acknowledged that the queries in SMB protocol did in fact have to go back to the origin server.
So here we are trying to see if we can get the local acknowledgement via DFS and local file server to improve the application response time further.
One other question about WAFS that puzzles me. If we were to take File A and preposition that file on Edge WAE A would there be a noticeable difference in the local acknowledgements of that file as compared to never prepositioning the file on the wae first?
Will DRE provide the local caching in the CIFS cache for CIFS files if they are not prepositioned first? Will act of accessing the file on the origin server actually preposition the files in the CIFS cache?
I am still struggling with the advantage of prepositioning beyond being able to avoid the cold pass on the files during the first transaction.
Could you explain what the benefits we could get from a local ack perspective with a preposition vs. non-prepositioned files?
The benefit of preposition is as you described ... cache hits on the first access. With on-demand caching, subsequent access after the first is served locally from the cache.
When you access a file that is the CIFS cache are the attributes of that file from a CIFS perspective and from a local AO acknowledgement standpoint any different? Will you get better performance with prepositioned CIFS data files than from data files residing the DRE on-demand cache?
Is there any difference?
There are two disk-based caches used by WAAS:
- DRE segment cache
- CIFS object cache
The DRE cache stores previously seen chunks of TCP segments. The CIFS object cache stores objects (directories and file) in their native format (as they would be stored on the orgin file server).
The DRE cache is populated on-demand, by virtue of traffic passing through WAAS to/from the WAN. The CIFS object cache is populated 1) on-demand as users access directories and files on the origin file server, or 2) by prepositioning, whereby an administrator specifies directories/files that should be copied to the cache prior to a user requesting them.
The performance once an object is in the cache is the same, regardless of how it got there.
You can try the following tweaks on the WAFS Edge device to improve metadata performance:
sh stat wafs expert "-server Rx -mbean RxCIFS -attr QueryPrefetchInfolevels 257;258;1006;1007;1022;1034"
sh stat wafs expert "-server Rx -mbean RxCIFS -attr DirListAge 120000"
sh stat wafs expert "-server Rx -mbean RxCIFS -attr FileAttrAge 2000"
This same customer has some additional questions about WAAS 4.0.17 and Microsoft DFS. They have an application that runs off a remote file share on a NetApp filer. We were able to get improved performance over their T1/80ms WAN using the CIFS AO however its still not as good as they would like.
They have implemented a workaround solution using a Desktop PC running Server 2008 OS and MS DFS. This is providing them the performance that they are after. The application is mapping to the local DFS share and able to get acknowledgements locally.
Can we do the same thing with WAFS using its DFS features and remove the local PC as well? They currently have a 512-2G WAE in place. Will this require them to upgrade to the WOW using a 674 to get the same performance or can it be done with DFS on the WAE using the CIFS cache. The files they are caching on the PC for the application are no more than 40GB in size.
Yes, the local PC is serving as the DFS target. Can we perform the same service that the DFS share is performing on the WAE? I read in the configuration guide that we can use DFS with WAFS however it doesnt seem to indicate if this is a full DFS implementation or just some sort of DFS spoofing to preserve whatever aliasing the site had before you remove a DFS server. Not sure how that works.
The question is whether we can replace the local dfs target pc that is currently acting as a dfs file share for the application using a similar dfs setup with the wae. Does the wae interoperate with ms dfs the same way an ms server does or do we need to go with the 674 and WOW to get this functionality. This all seems to be related to local acknowledgement of file access to the share. The application performs much better when the share is local than it does with exported cifs shares on the wafs device.
The CIFS acceleration in WAAS is intended to prevent the need for a local file server (which is a DFS target in your case). It seems like you tested this and didn't see the performance you expected.
Can you describe the WAN characteristics and use case(s) in more detail (types of servers/clients, actions taken, etc.).
The clients are windows xp/vista. Servers are NetApp filer in core site and remote site is windows 2008 server running on a desktop pc. The files for the application are replicated to the local file server at the site and clients at the site access the share via DFS. This provided us the Lan-like performance we were looking for. With WAFS/WAAS enabled we are not getting the same performance due to the frequent file locking and queries having to traverse the wan. There are a ton of little files in this application and each one is subject to a delay during the query process across the wan.
WAN is T1/80-200 msec.
Can we run the WAE as the DFS root for the application files instead and have the same results? Does the WAE support full integration with DFS (FRS for instance) as a normal server does? We would like to remove the local file server and just cover the WAE as the DFS target instead. Is this supported? Can we still use WCCPv2 for other transparent CIFS traffic to other servers?
WAAS is not intended as a DFS target, but rather to accelerate access to a DFS target across the WAN. As you stated, there are some protocol messages that will have to traverse the WAN to maintain coherency with the CIFS semantics. Most notably are the file open and close requests.
There is potentially some tuning we can perform to improve metadata caching performance. Is it possible for you to provide me a packet capture from the client when WAAS is in place and you are seeing sub-optimal performance?