--- myst: html_meta: "description lang=en": "Learn how to configure AutoScale for Server Pools in Kasm Workspaces. This guide details settings for dynamically provisioning and managing resources such as RDP, KasmVNC, VNC, and SSH, ensuring efficient session allocation and optimal scaling." "keywords": "Kasm, AutoScale, Server Pool, autoscaling, RDP, VNC, SSH, KasmVNC, cloud infrastructure" "property=og:locale": "en_US" --- ```{title} AutoScale Configuration (Server Pool) ``` # AutoScale Configuration (Server Pool) ```{contents} Table of Contents :depth: 3 :local: ``` This section covers the AutoScale configuration step of the Wizard for Pools of type "Server". ```{figure} /images/compute/create_autoscale_server.webp :align: center **Create Autoscale for Server** ``` (autoscale_server_config)= ## AutoScale Settings for Server Pool * Configure the following settings in your Kasm deployment. ```{eval-rst} .. table:: General AutoScaling Settings :widths: 200 +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Name | Description | +=============================================+===================================================================================================================================================================+ | **Enabled** | Whether to enable this config or not. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Name** | Name for the AutoScale config. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **AutoScale Type** | The type of AutoScale config this is, either a Docker Agent or a Server. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Pool** | Which pool this AutoScale config is attached to. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Aggressive Scaling** | When enabled, the system may take more expedient measures to provision raw compute resources for on-demand session requests. | | | See :ref:`aggressive_scaling` for more details. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Deployment Zone** | Which zone this AutoScale config applies to. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Downscale Backoff (Seconds)** | This setting prevents prevents the system from downscaling (deleting Servers) for this amount of time (in seconds) when needed. This is useful for preventing the | | | system from thrashing up and down if the available resource hover around an interval that would typically trigger autoscaling. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Require Checkin** | When enabled, the system will wait to receive a callback from the newly created server to set its status to Running. The callback may come from the Kasm Windows | | | Service or by calling the `set_server_status` API. See :ref:`require_checkin` for more details. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Kasm Desktop Service Installed** | When enabled, the sytem will assume the Kasm Desktop Service is installed, enabling workflows that require the agent. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Type** | Whether to use KasmVNC or RDP, VNC, or SSH. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Port** | Which port to connect on. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Credential Type** | Which type of credentials are used for this server. Options are Static Credentials, Dynamic User Accounts, SSO User Accounts, and Authenticate with Smartcard. | | | See :ref:`sso_windows_ldap`, :ref:`ssh_authentication_options` | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **SSO Domain** | The domain to use for SSO User Accounts **Connection Credential Type**. A blank entry will pass the username to Windows exactly as it is in Kasm. A value of | | | localhost will instruct Kasm to drop any domain part from the Kasm username i.e. john_smith@example.com becomes john_smith when passed to Windows. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Username** | Which username to connect to the server with. Only visible with Static Credentials **Connection Credential Type**. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Password** | Which password to connect to the server with. Only visible with Static Credentials **Connection Credential Type**. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Use User SSH Key** | Whether to use the SSH keys assigned to a Kasm user. (Only applicable to SSH connection type) | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Private Key** | The private key to authenticate against the SSH server with. (Only applicable to SSH connection type) | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Private Key Passphrase** | The passphrase encrypting the specified private key. (Only applicable to SSH connection type) | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Info (JSON)** | Any extra connection info. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Create Active Directory Computer Record** | Whether to create an active directory record or not. See :ref:`ad_computer_record` | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Reusable** | Whether the connection reusable. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Minimum Available Sessions** | The minimum available sessions that should be free. Auto scale more resources if under this threshold. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Max Simultaneous Sessions Per Server** | Max sessions per server allowed. See :ref:`max_simultaneous_sessions_per_server` | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Max Simultaneous Users** | For RDP/SSH servers, the number of concurrently connected users per server. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` ```{eval-rst} * Click "Next" and you will now be prompted to enter your :ref:`provider-specific details `. ``` (max_simultaneous_sessions_per_server)= ### Max Simultaneous Sessions Per Server For RDP and SSH servers, the `Max Simultaneous Session Per Server` and `Max Simultaneous Users` work together. SSH and RDP support multiple sessions per user per server. For RDP this is typically found in RemoteApp use cases. For SSH and RemoteApp servers you may want 1 server to handle just 2 concurrent users but up to 10 concurrent sessions each. These settings are used for two purposes, auto-scaling and deciding where to assign new sessions to. For auto scaling, Kasm periodically checks to see that it has resource availability to create `Minimum Available Sessions` on the existing servers in the pool. It checks how many sessions and how many new users each server can handle, it uses the lower of those two values to determine how many new sessions each existing server can likely handle. If the total from all servers is less than the `Minimum Available Sessions`, new servers are created until it reaches the desired capacity. Kasm will not allow a single user to provision multiple RDP desktops per server. Only RemoteApps are allowed to be assigned to the same server for a single user. Kasm will allow one desktop and multiple RemoteApps on the same server for a user. (require_checkin)= ### Require Checkin The **Require Checkin** flag can be used to ensure the system waits until a newly created server is fully ready before allowing a users session to connect. Administrators may use the autoscale startup script to ensure the desired configurations and services are properly initialized (e.g RDP is enabled and running). If using Windows sessions, administrators may use the [Kasm Desktop Service](/guide/windows/windows_service.md). All systems may use the `set_server_status` API. ```{eval-rst} .. http:post:: /api/set_server_status?token={checkin_jwt} **Example request**: .. tabs:: .. code-tab:: json { "status": "running", "status_message": "Initialization Complete", "status_progress": "100" } .. code-tab:: bash curl -k -X POST -H "Content-Type: application/json" -d '{{"status": "running", "status_message": "Initialization Complete", "status_progress": "100"}}' https://{upstream_auth_address}/api/set_server_status?token={checkin_jwt} ``` Additional examples are available in the [workspaces-autoscale-startup-scripts](https://github.com/kasmtech/workspaces-autoscale-startup-scripts/) repo. (ad_computer_record)= ### Create Active Directory Computer Record As covered in the above table, the AutoScaling configuration for a Server Pool allows the administrator to automatically join new VMs to an active directory domain. If the checkbox for **Create Active Directory Computer Record** is checked two additional fields will be shown, **LDAP Config** and **Active Directory Computer OU DN**. ```{figure} /images/compute/join_to_domain.webp :align: center **Join to Domain** ``` Kasm Workspaces creates the AD Computer record, but it **does not join the computer to the domain**, this needs to be done on the system itself. When Kasm creates the AD record, a temporary randomly generated password is created which can be used on the target VM to join it to Active Directory. Kasm can inject this password in a PowerShell script on the VM. That PowerShell script needs to be executed when the VM starts up, in order to complete the process of adding the VM to Active Directory. Below is an example PowerShell script, the special tags `{ad_join_credential}` and `{domain}` will be replaced by Kasm with the randomly generated password and domain name respectively. This script is placed in the [VM Provider](/guide/compute/vm_providers.md) configuration in the Startup Script field. ```powershell $joinCred = New-Object pscredential -ArgumentList ([pscustomobject]@{{ UserName = $null; Password = (ConvertTo-SecureString -String '{ad_join_credential}' -AsPlainText -Force)[0] }}) Add-Computer -Domain "{domain}" -Options UnsecuredJoin,PasswordPass -Credential $joinCred -Force -Restart ``` ```{note} Some cloud providers will automatically execute this startup script when the VM boots, making it easy to get auto AD joining working end-to-end. Other cloud providers, such as Azure, do not automatically execute this script. See the details of each [VM Config Provider](/guide/compute/vm_providers.md). ``` **LDAP Config** The LDAP Config drop down allows the administrator to select which [LDAP configuration](/guide/ldap.md) to use to add the computer record to Active Directory. The LDAP Configuration does not have to be enabled, this allows the administrator to use one LDAP configuration for Authentication and another for AD Computer record creation. If using LDAP for end-user authentication to Kasm Workspaces, the administrator can also configure single-sign on to the Windows systems. **Active Directory Computer OU DN** This is the DN of the Active Directory Computer OU that the administrator would like the computer records placed in. ```{note} The LDAP config must be using an SSL secured LDAPS connection or the LDAP server will not permit Kasm to create the AD Computer record. ``` (sso_windows_ldap)= ### Single Sign-On to Windows Systems via LDAP When users login to Kasm via [LDAP Authentication](/guide/ldap.md), they are able to create sessions to Windows systems that are joined to the same Active Directory domain and are configured for SSO credential pass-through. In the above table covering the Auto Scale configuration fields for Server Pools is the **Connection Credential Type** field. Select the value *SSO User Accounts* in the Auto Scale configuration for the Server Pool. This requires that all users accessing servers in this Server Pool are authenticated to Kasm using LDAP authentication. See our Windows Deployment Guide video for a walk through of this topic and more. (ssh_authentication_options)= ### Authentication Options When Connecting to an SSH Server Kasm Workspaces has the ability to connect to arbitrary SSH servers. It can use SSH key or password authentication. There are a few combinations of options on the Autoscale Config edit screen that can be selected. The Autoscale Config can be configured to use: - Username/password authentication - Username and select the `Use User SSH Key` to send the username and private key stored with the Kasm user. - Username and a pasted in private key, optionally you can include a passphrase if the key has one. Select the value *SSO User Accounts* in the **Connection Credential Type** field and check the **Use User SSH Key** checkbox and Kasm Workspaces will send the user's Kasm Workspaces username along with the user's Kasm Workspaces SSH key allowing easy multiple user support on SSH servers. There are some restrictions on the ssh keys supported that are enforced by the connection proxy library used for the ssh server connections: The SSH key must be an ssh-rsa key in PKCS1 format (i.e. the header of the key starts with `-----BEGIN RSA PRIVATE KEY-----`) with a key size of 2048. In addition, some newer Linux distributions such as Ubuntu 22.04 LTS will not accept ssh-rsa keys by default. To work around this edit the `/etc/ssh/sshd_config` file on the target server using the startup script of the vm provider and add these two lines to the config. ```{parsed-literal} HostKeyAlgorithms +ssh-rsa PubkeyAcceptedKeyTypes +ssh-rsa ``` (aggressive_scaling)= ### Aggressive Scaling Starting in Workspaces 1.14.0, administrators can choose to leverage fully on-demand compute resources for container and server/server pool based sessions. When users requests a session, and no compute is available, the system will queue the request, provision the resources according to the autoscale configs, then fulfill the request. This will prevent the user from receiving a No Resources error. Instead, the user will be presented with a status indicator while the request is fulfilled, which may take several minutes. This can be used alongside the existing standby and staging mechanism to give the administrator more options to balance compute costs with session delivery times. Enabling **Aggressive Scaling** in the Autoscale Config, instructs the system to make more opportunistic choices when requesting resources, with the goal of reducing the users wait time. This mode may result in compute resources being utilized in less cost-efficient ways, since users may end up on separate machines instead of pooled together depending on the circumstance. This mode may also result in the system scaling slightly beyond the max instances defined on the associated VM Provider due to the potential concurrent nature of resource provisioning. ```{figure} /images/compute/queued_session.png :align: center **A Requested Session in Queue** ``` (server-provider-specific-settings)= ```{include} /how_to/infrastructure_components/autoscale_providers/providers_index.md ``` ## Windows Templating To AutoScale Windows resources in Kasm Workspaces, you must first create Windows templates that will serve as the base images for provisioning new instances. These templates should include necessary configurations such as licensing considerations, required drivers, guest agents, sysprep, domain join settings, and any additional software required for your deployment. Properly prepared templates ensure seamless AutoScaling and optimal resource utilization. For more details about Windows templates, refer to the [Windows AutoScale Template Creation Guide](./windows_autoscale_templates.md)