What’s up, everyone!
This week I had a look at scaling plans for Azure Virtual Desktop. Until recently we only had the ability to use Autoscale for pooled host pools but nowadays we can use Autoscale for personal host pools as well since the feature went into preview. That gave me the idea to take a look at scaling plans. What are they again, how do we configure them and of course how to create a scaling plan for a personal host pool.
Enjoy!
Prerequisites
Microsoft released the following prerequisites for scaling plans:
- The scaling plan has to be in the same region as the host pool you want to assign the scaling plan to.
- Make sure to configure the MaxSessionLimit parameter for pooled host pools. This parameter specifies how many sessions are accepted per session host.
- Grant AVD access to manage the power state of the session host VMs.
- Assign the Desktop Virtualization Power On Off Contributor role to the Azure Virtual Desktop service principal. Find out how.
- Scaling plans with autoscale isn’t supported in every Azure region. Make sure to check the list of supported regions here.
What are scaling plans?
As an admin of virtual desktops you want to make sure that there’s enough capacity to allow all users to login and have a good experience. But there are several factors as to why your company needs more or less capacity. During peak days you’ll see that most or perhaps even all of your users will sign into AVD while during off days you might see a drop in sign-ins. This is also true for the holiday season for example where you would see a drop in sign-ins as well. Another thing to keep in mind is costs. If you have a lot of capacity but it’s unused or unnecessary, then shutting those session hosts down would save you money.
That is where scaling plans come in. Admins can define a schedule when to scale up to add capacity to the environment or when to scale down to save costs.
Scaling plans can now be used for pooled host pools as well as personal host pools and configuring them is basically the same.
There’s a Microsoft doc that’s definitely worth to mention. It’s titled ‘How a scaling plan works‘ and contains a lot of great information. Some examples are;
- You can assign a scaling plan to one or more host pools of the same type but you cannot assign multiple scaling plans to a single host pool. You’ll only see unassigned host pools when assigning a scaling plan. Does that mean you have the same autoscale settings in the weekend as you would during the week? Well, no. You can configure multiple schedules in one plan.
- Information about the times of day. These are also explained in my post below.
- Do not use scaling plans alongside other solutions.
Creating a scaling plan
All of the magic happens in Azure so first we need to login to the Microsoft Azure portal and open Azure Virtual Desktop. You can find Scaling plans in the Manage menu.
We can create our first scaling plan by clicking on the + Create button.
Most of the required information speaks for itself. In the Host pool type dropdown box you can select if you are creating the scaling plan for a pooled host pool or a personal host pool.
Did you notice the exclusion tag box? It’s the last box in the previous screenshot. Admins can create and name a tag and assign it to one or more hosts in the pool. By adding the name of the tag in this scaling plan you can make sure that affected hosts are not shutdown by this scaling plan. However they are being used in the calculation to decide the minimal number of hosts in the pool.
Let’s continue. The next step is to create a schedule for this scaling plan. Click the + Add schedule button to get started.
A schedule contains the information when the schedule will run and what actions will be performed.
We can add a name and select on what days of the week the schedule will run on the General tab;
During Ramp -up we can configure what happens to the assigned host pool when users start to sign in to the environment.
Start time
The start time is basically when scaling plan will start to ramp-up the environment if necessary to create more capacity. Let’s say that users start to sign in at 08:00. Admins can choose to select a time before or near to 08:00. I’ll keep 08:00 in this demo.
Load balancing algorithm
Your users are now logging in! But where do their sessions land? We have two flavors here. Using breadth-first we configure the environment to fill up each host equally. Alternatively you can fill up one host at a time by selecting depth-first as the algorithm.
Minimum percentage of hosts (%)
How many session hosts should be available to accept user sessions? A quick example; you have 100 session hosts and you configured 5% of the environment as the minimum percentage of hosts, you would have 5 session hosts ready to accept sessions. The percentage would probably depend on the size of your environment and how many users simultaneously login at the same time.
Capacity threshold (%)
How aggressively do you want to power on additional session hosts? The lower the percentage, the sooner Autoscale will power on additional hosts. An easy example is when your capacity thresholds is set to 60% and your total host pool capacity is 100 sessions, Autoscale would power on additional hosts once you have 60 active sessions. The percentage you want to use depends on your environment and how fast users will sign-in.
Peak hours start when ramp-up ends. Ideally you would want to specify when most of the users signed into AVD and you can change the load balancing algorithm if you want to.
As time flies by the users will reach the end of their shift and start to sign out of AVD. Time to save money by reducing the capacity of the environment since we don’t need it anymore, right?
We can end the Peak hours and move on to the Ramp-down and let Autoscale know when to start to downsize the environment.
Specify the time to start ramping down and choose the desired load balancing algorithm. Define how many hosts you want to shrink down to during the ramp-down and off-peak phases. (This works the same as explained before). We do have some new options here;
Force logoff users
Select either Yes or No but keep in mind that forcefully logging off users session can result in loss of data.
Delay time before logging out users and shutting down VM’s (Min)
Select the number of minutes before users will be signed out. Autoscale will shutdown the VM once there are no more sessions on the host.
Notification Message
Accept the default message or get creative and define your own message that will be shown to users before they are logged off.
Moving on to the last step Off-peak hours. Most of the users have logged off by now. Time to shrink the environment as save more on costs.
This works the same as shown before, just select the start time to enter the off-peak hours and select the load balancing algorithm.
Finish up by clicking on the Add button.
We now successfully added a schedule to the scaling plan. Almost there!
We still need to assign the scaling plan somewhere. It just so happens that we can do just that in the next step; host pool assignments.
Select the host pool and enable Autoscale.
Next up you can add tags if you like to.
In the final step we will get a validation to make sure that everything is OK. We only have to take a second to admire our awesome work and click the Create button to save our scaling plan.
The deployment will start and finish up pretty quickly. Click the blue Go to resource button.
Or go back to Azure Virtual Desktop, Manage, Scaling Plans.
Let’s checkout the schedule for a personal host pool. I’ve created a new scaling plan and selected personal as the host pool type. Creating the schedule is the same and it has the same steps;
- General
- Ramp-up
- Peak hours
- Ramp-down
- Off-peak hours
We can see some differences during Ramp-up. This pane will tell us on what days the schedule will run, the timezone and when the phase stats.
Select Yes or No to start the VM on connect. The longer the VM remains powered off, the more you save. The only downside is that the user will have to wait until the VM is booted and accessible. So signing in will take a bit longer.
In the VMs to start section, you get three choices.
Assigned VMs only
Select this option to have Autoscale start VMs that are assigned to users.
Assigned an unassigned VMs
Select this option to have Autoscale start VMs that are assigned or unassigned to users.
Don’t turn VMs on at start time
Select this option if you want to leave the VMs powered off. If you select this option, Microsoft recommends to use Start on connect.
To finish up we can configure the desired Disconnect settings and Log off settings. For both settings admins can choose to perform ‘None‘ or ‘Shutdown‘ as the action.
The Peak hours phase looks a bit different. It does not have the option to Start VMs during the start of this phase which makes sense.
Next up is Ramp-down. It looks a lot like Peak hours. doesn’t it? One thing that might look off is that there’s a Start VM on Connect option. If set to Yes, users will have the same experience as before meaning if they login and their personal desktop is powered off, they will have to wait a minute for their desktop to become available.
And lastly we get to configure the settings for off-peak hours. Nothing new here, so make sure to configure the settings to your liking and save the schedule.
The only thing left is to finish creating the scaling plan and once deployed you’ll now have access to two.
Remember the exclusion tag?
So how does the exclusion tag work? Tags are configured on the virtual machine. From the Azure portal, Virtual Machines, click on the VM, Tags.
Tags are name/value pairs. Just add a name and optionally a description. I used the following:
- Name: SP_EXCLUSIONTAG
- Value: This tag makes sure that Autoscale function leaves this VM alone.
Next up is to add the newly added tag to the scaling plan that is assigned to pooled host pools. From the Azure portal, go to Azure Virtual Desktop, Scaling Plans, Settings, Properties, Exclusion tag.
Finish up by clicking the save button in the ribbon.
Why would you use the exclusion tag?
Basically for any scenario where you want to exclude session hosts from Autoscale. This could be for maintenance or during deployment of new session hosts.
Amazing post, thanks a lots.
I followed the steps but in my personal pool the VMs never shutdown and get de Dallocated state.
Could you help me?.
Thanks in advance.