App Layering in Azure

[Roger Stuart1709157773]

We have started shifting our App Layering environment from on-Prem to Azure.  We already have about 40 AL Servers running in Production in Azure.  We have more than a thousand App Layered 2016 Servers currently deployed on-prem in VMware that we need to shift to Azure so we need to figure this out and get it right the first time.  We followed Rob Zylowski post to get started with AL in Azure.

 

We have it working and overall it works well once it’s up and running but the biggest problem we have is with adding machines and updating machines. On-prem we can add a machine in about 5 minutes.  When it’s time to update a Machine Catalog it takes about 3 minutes to copy the new image and less than 5 minutes to reboot the machine and have it ready for use.  In Azure it regularly takes about an hour or more to update a machine because it literally deletes the entire machine and recreates it.  A new machine takes about 45 minutes to create.  I’m new to Azure and figuring it out as I go but something tells me this can’t be normal.  Other than Rob's tutorial there's still very little out there about AL in Azure so I haven't found an answer.  Is this normal? Can someone suggest what I might be missing?

[Rob Zylowski]

To us it would look like vSphere.  I have no idea how long it will take to update.

 

[Rob Zylowski]

Unfortunately Yes I think that is normal.  Much of it has nothing to do with App Layering though you of course have to deploy the new image which always takes time.  You can gain some performance benefits by using a larger box for your Appliance and then it will inherit more network performance and better disk performance.  But its not a huge difference.

[Roger Stuart1709157773]

Thanks Rob.  For once I wanted to hear that I made a mistake.  That's very distressing to learn how much more time it's going to take to patch all these machines each month. 

[Rob Zylowski]

Yes also definitely beware of the number of desktops deployed per subscription.  Azure API limits will greatly affect the performance you see when redeploying an image.  We recommend no more than 1200 desktops per subscription if using Citrix Cloud and Azure and 1000 if using an Om-Premises version and Azure both dependent on the API limits per subscription and service principal used.

[Roger Stuart1709157773]

Rob, just for clarification, The deployment from the ELM to Azure is slow probably 45 minutes to an hour.  We can't use Offload Compositing because we expand out C drives.  But updating a machine from Citrix cloud takes about an hour from the time I kick it off to completion with MCS.  Is that normal?

[Rob Zylowski]

We don't have offload compositing for Azure anyway so yea that time seems within normal range and yes MCS updates can certainly take an hour.  The question will be if you do a mass update will its still be an hour or much longer due to API limits.  Hopefully you will be doing the updates over night or you could use a A and B catalog approach where you update a B catalog with all the machines in Maintenance mode, then swap from the A machines to the B machines and vice versa for the next update.  That at least lets you pre-deploy updates but with a bit higher cost as you will for some time have both desktops running.

[Roger Stuart1709157773]

Hi Rob,  I'm looking into my alternatives since moving our workloads to native Azure doesn't seem to be a viable solution.  I see that Azure is now offering  VMware in Azure.  Has Citrix looked into this at all?  Could I expect this to work with comparable performance to On-Prem? https://azure.microsoft.com/en-us/services/azure-vmware/

[Rob Zylowski]

From an App Layering perspective yes you should see similar performance to on-premises VMware because you can use the composting engine feature.  I would think PVS would also work on VMWare on Azure but I am not sure if that is the case.  I will try to find out.  MCS always takes longer to deploy an image than PVS does to boot it.  Depending on your requirements it might help when using MCS to use two separate catalogs (A and B) where one is active and one is not.  You can then deploy a new image to the standby catalog and after testing that its all good you can swap by putting the opposite catalog in maintenance mode and vice versa.  That helps deploy a new image with little downtime but it doesn't help get one out faster when you have an emergency update.

[Roger Stuart1709157773]

I can't use Offload compositing because we have to expand our C drive to 50 GB and that gets ignored by Offload compositing, something I wish Citrix would fix but we've learned to live with it.  We don't use PVS. 

 

On-prem I can assign an image to a Machine catalog that is VMware hosted in about 3 minutes and I can reboot those machines in about 3 minutes. In Azure those same two task take from 1 - 2 hours to complete.  So what I'm wondering is if I linked Citrix Could Studio to these Azure based VMware clusters could I expect those two task to be more in line with time it takes to complete on-prem.  I'm sure there may be some additional time but is there anything that you know of (anything different like APIs)  that would significantly increase using it in Azure VMware?

 

From an ELM perspective, would Citrix need to create a custom Connector to publish to the Azure Vmware clusters?

[Rob Zylowski]

You can increase the size by just changing this 

[Rob Zylowski]

BTW to make your OS layer bigger just change it here when adding a version :

 

 

[Roger Stuart1709157773]

Hi Rob.  I just saw your comment.  Unless something has changed I don't believe that settings changes the default 20 GB C drive that is available when Elastic Layering is enabled.  All of our images have elastic layering turned on and therefore we had to use this article to work around the size limitation. 

 

https://support.citrix.com/article/CTX225030

[Rob Zylowski]

Sorry you are right I was not thinking about the writable partition size.  So did you just edit the cam config?

[Roger Stuart1709157773]

Yes I edited the cam config  but Offload Composting doesn't account for that.