With autoscaling we refer to the system's ability to automatically adjust session host servers' resources (RAM & CPU) according to number of users creaed in the environment. Autoscale can also automatically create new session host servers when you reach your maximum number of users per server.
In Starter plan, the autoscaling is pre-defined according to the formula below and the resources (RAM, CPU) are adjustable manually through itopia Instances module if you disable the autoscale. Make sure you disable the autoscale before changing RAM and CPU (details below) otherwise, the system will scale the resources back to your default amounts.
In Pro plan, autoscaling can be configured according to your preferences. It will automatically add or remove resources and /or instances from the client group based on increases or decreases in number of created users.
The following information explains how the default formula works to assign your resources:
PDC server (Primary domain controller): 1 CPU, 5.5 GB RAM, 50 GB storage
0-7 users: 2 CPU, 7.5 GB RAM
8 -15 users 4 CPU, 15 GB RAM
16 – 25 users: 4 CPU, 26 GB RAM
26 users and more: new USS instance (session host) will be created with 4 CPU and 13 GB RAM on both instances
BDC/SDC (Backup/Secondary domain controller): 1 CPU, 5.5 GB RAM
RDG1 server (RDS Gateway): 1 CPU, 3.8 GB RAM
RDG2 server (Redundant Gateway): 1 CPU, 3.8 GB RAM
BRK server (Dedicated Broker): 1 CPU, 3.8 GB RAM
FSB (Dedicated file server/Broker): 1 CPU, 3.8 GB RAM
Configure autoscaling (Pro plan)
If you have Pro plan with itopia, you can configure autoscaling from Workspaces section - Autoscaling. The configuration becomes available once the deployemnt is launched to cloud.
Go to Cloud Desktops section and select Autoscaling
If it's the first time you open Autoscaling tab, you will see the default setup. You can change the autoscaling settings to meet your needs related to resource management.
If you have multi-region deployment, first select the region you will be changing the settings for. Otherwise continue to the next step.
if you decide to customize the autoscaling settings, start deleting the default configuration on the right.
Then continue by specifying your requirements on the left in Users per server field: Specify the maximum number of users that will be allowed to connect to one server.
When the amount of active (on-cloud) users exceeds your number, new user session server will be created.
Server specifics: Here you can determine the resources for the instance depending on the number of users.
First choose the min and max number of users (always start with 0), then select a Machine type. To add the setting, click on the green + sign.
The setting will be displayed in the list on the right. Continue the same way till the max number of users per server is reached like in the below example:
You can disable the autoscaling anytime with the button on the top left.
IMPORTANT: When autoscale is disabled you have to manage the resources (RAM, CPU) manually from Instances module.
What happens when autoscaling is triggered?
As previously mentioned, the system scales your resources based on user count. The autoscale is triggered as you add or remove users.
Whenever the instance resources need to be updated, you get an alert that the instances will need to reboot to update. The system asks you to select when you want the resources reconfigured (servers rebooted). You can force the change with "Force update" option or schedule it to a specific day and time.
In case the resource change includes new session host creation, the system will spin up a new instance and create a task for every application that must be installed on the newly created VM. At this moment end user logins are disabled to the new instance.
Note: The new session host will be created in the same datacenter region but different zone (e.g. if you deployed in US- East1-b, the new session host can be created in US-East1-c). The reason is to balance the session hosts.
You need to install all the applications on the instance and mark all the installation tasks as complete in itopia for the end user logins to be allowed in the instance. In other words, once you complete all the installation tasks, system allows logins to the server and scales the other instances resources according to your selected schedule (reboot needed). If you selected "Force update" option, the changes will be done right away.
If there's any obstacle like low IP quota that causes a delay in updating the resources (server creation and re-configuring of the RAM and CPU in existing servers) your schedule to make the updates may change. If because of any delay the schedule you selected is no longer valid, the resources will update at 12 AM local time that is set for that particular deployment.
Autoscaling failed creating a new instance
There can be cases when the autoscaling process is not triggered as it should after adding more users. The conditions for creating new instance were met but you notice that a new instance wasn't created and/ or you get an error message in the portal.
The most common cause is a low Google IP quota. You will get a task in Tasks module to increase the quota so the autoscale can be launched. Once you request the quota increase in Google, you must wait for an email confirmation that the quota was increased.
Once you received a confirmation, you can complete the task to increase quotas and the autoscale will be launched again at the time you scheduled iniatially..