Kasm Maintenance Mode
Kasm Administrators occasionally need to place the kasm deployment into a shutdown or standby mode to perform server maintenance. The instructions below detail the proper shutdown order and restart order for kasm services to avoid system errors.
Instructions
Stopping Single Servers Deployments:
Use the Kasm UI to terminate all workspace sessions.
If using agent auto-scaling:
Record the autoscaling configuration “standby” compute (ie: “Standby Cores”, “Standby GPU”, and “Standby Memory”) values for future restoration.
Set the autoscaling configuration “standby” compute (ie: “Standby Cores”, “Standby GPU”, and “Standby Memory”) to zero.
Do not uncheck the “Enable” checkbox for the autoscaling configuration. This will prevent kasm from removing any existing auto-scaled agents.
Use the Docker Agents screen in the Kasm UI to delete any auto-scaled agents. Do not delete any agents with “hardware” in the “provider” column.
SSH to all remaining Agents and stop the kasm services (
sudo /opt/kasm/bin)
.SSH to the single server and stop the kasm services (
sudo /opt/kasm/bin)
.
Stopping Multi-Server Deployments:
Use the Kasm UI to terminate all workspace sessions.
If using agent auto-scaling:
Record the autoscaling configuration “standby” compute (ie: “Standby Cores”, “Standby GPU”, and “Standby Memory”) values for future restoration.
Set the autoscaling configuration “standby” compute (ie: “Standby Cores”, “Standby GPU”, and “Standby Memory”) to zero.
Do not uncheck the “Enable” checkbox for the autoscaling configuration. This will prevent kasm from removing any existing auto-scaled agents.
Use the Docker Agents screen in the Kasm UI to delete any auto-scaled agents. Do not delete any agents with “hardware” in the “provider” column.
SSH to all remaining Agents and stop the kasm services (
sudo /opt/kasm/bin)
.SSH to any existing Dedicated Proxies and stop the kasm services (
sudo /opt/kasm/bin)
.SSH to any existing Guac Connection Proxies and stop the kasm services (
sudo /opt/kasm/bin)
.SSH to all Webapp servers and stop the kasm services (
sudo /opt/kasm/bin)
.SSH to the Database server and stop the kasm services (
sudo /opt/kasm/bin)
.If you are using an RDS or Elasticache you will use your provider’s method for stopping the data service.
Restarting the Servers:
Restart the servers in the reverse order of stopping the servers.
Use command “
sudo /opt/kasm/bin/start
" to start the kasm services on each server.It is recommended to wait for each server to completely restart its kasm services prior to proceeding to the next server. Check on the health status of the kasm services for each server by running the “sudo docker ps -a” command to view the kasm_db, kasm_redis, kasm_manager, kasm_api, kasm_proxy, kasm_share, kasm_gauc, or kasm_agent services. The Kasm role for a server determine which kasm_* service containers you should expect to see. In general, if the a kasm_* service container is not present you can assume that it is not needed on that specific server.
Restore auto-scale configurations by replacing the original values in the “standby” compute fields.
Related Docs:
Links to related docs in the kasm_docs project
Related articles
Links to related kb articles in the Confluence project