Pierre Altmayer Posted May 7, 2019 Posted May 7, 2019 Hello, when using a scale out file server (MS Cluster Scale-out FS), the elastic App Layers take a long time to be mounted. the same layers but when using a traditional File Server works perfectly. I've opened a Citrix Support Case but it was closed saying that the issue is only with scale out file server. But int the Citrix Documentation, the only way to provide a high availability is to use a scale out file server. does anyone got this issue ? thanks
Rob Zylowski Posted May 7, 2019 Posted May 7, 2019 Well Citrix wont be able to help with this one its the Windows client doing the mounting to a Microsoft server product. What mode are you using for the file server is it "Scale out file server for application data"? If not i would change to that mode as its meant for mounting large files. Also you might want to test having more RAM on the server to see if caching matters. If you mount a layer manually does it also take a long time? Rob
Pierre Altmayer Posted May 7, 2019 Author Posted May 7, 2019 Hello, yes it is configured as Scale out file server for application data when mounting manually, it takes 1 sec. also every smb transfert are very good the cluster node has really enough RAM and cpu the Citrix Uniservice mounts the VHDX, and the log shows that it takes long time for each VHDX Regards
Rob Zylowski Posted May 7, 2019 Posted May 7, 2019 Well we now mount disks after logon by default which can mean they take longer to mount. If you edit a layer and put it in "compatibility mode" does it mount quicker?
Pierre Altmayer Posted May 7, 2019 Author Posted May 7, 2019 Quote If I set the layer in compatibility mode or if i configure the layer service to mount layers before logon (registry key) then it takes a long time before showing the desktop. with standard file server, the mount is quick in or not in compatibility mode.
Pierre Altmayer Posted May 7, 2019 Author Posted May 7, 2019 in the log i got : 17:21:41 User logged in successfully ... 17:22:46 waiting fo 7 layers to be ready exactly 1 minute after : 17:23:46 Request service .... 17:24:22 NativeMethodInterceptor : OpenVirtualDisk took 161 seconds so it takes 3 minutes to mount layers
Pierre Altmayer Posted May 7, 2019 Author Posted May 7, 2019 the scale out file share is \\SOFS\APL and it is located if I share the same folder directly on a cluster node, then it works as it should be
Rob Zylowski Posted May 7, 2019 Posted May 7, 2019 Lets see if others resound. I did not have that issue with SOFS but I only used it in my lab which is a simple environment.
Pierre Altmayer Posted May 7, 2019 Author Posted May 7, 2019 Yes, thanks. I will re-open the Citrix support case. Regards
Darin McClain Posted August 11, 2019 Posted August 11, 2019 On 5/7/2019 at 11:43 AM, Pierre Altmayer said: Yes, thanks. I will re-open the Citrix support case. Regards Did you get a resolution with this? I thought I fixed mine, but it's back. Seems to be when I push over 100 VMs mounting layers, it comes back sporadically. My servers aren't working hard at all. only 1.5GB used of 4GB RAM, less than 10% CPU, never see it peak above 500Mb/s on the NIC when I login to several machines at once mounting about 8 layers each. If I transfer a vhd from this share, it will hit 1400Mb/s. So not hitting a bottleneck there. Darin UPDATE: Disabling continuous availability fixed my layer mounting issues, even though having that on was the primary reason we made these servers...
Question
Pierre Altmayer
Hello,
when using a scale out file server (MS Cluster Scale-out FS), the elastic App Layers take a long time to be mounted.
the same layers but when using a traditional File Server works perfectly.
I've opened a Citrix Support Case but it was closed saying that the issue is only with scale out file server.
But int the Citrix Documentation, the only way to provide a high availability is to use a scale out file server.
does anyone got this issue ?
thanks
9 answers to this question
Recommended Posts
Archived
This topic is now archived and is closed to further replies.