High Availability
PowerShell Universal high availability configuration.
Last updated
Was this helpful?
PowerShell Universal high availability configuration.
Last updated
Was this helpful?
PowerShell Universal can be configured for high availability ("HA") by using a combination of SQL server persistence and a load balancer to ensure that both the front end tools, such as dashboards are accessible and back-end tools, such as jobs, continue to run.
As jobs run, user's login and app tokens are created, the SQL server will be used to store this information and will be shared across nodes.
PowerShell Universal supports the use of load balancers such as F5 and nginx. There are some requirements that must be met when using load balancers.
Persistent (sticky) sessions are required by the admin console and apps
Web socket support is required by the admin console and apps
To aid with load balancing; you can use the /api/v1/status endpoint for your nodes. The endpoint will return status codes based on the current state of the node. 200 means the node is online and ready to receive requests. Servers running in maintenance mode will return 503. Servers that failed to start due to a configuration error, will return 500. Servers with apps that failed to start will also return 500.
You can set your nodes into Maintenance Mode by clicking Platform \ Computers and checking the maintenance mode option. Once maintenance mode is enabled, the /api/v1/status endpoint will begin returning 503. This should be configured to disable traffic being routed to the node while maintenance is performed.
There currently are some limitations to highly available PowerShell Universal clusters.
Caching performed using $Cache is limited to a single process on a single node. For example, each app running outside the integrated environment will have its own cache.
Set-PSUCache will not share data across nodes if -Persist is not specified. To ensure all nodes have the same data include this switch.
Multi-Node app broadcast messages are currently not supported. Using cmdlets like Show-UDToast -Broadcast will cause a toast modal to be shown to all connected users of the current node but will not be broadcast to the apps across all nodes.
We recommend taking advantage of (or PostgreSQL) to ensure that all nodes within your cluster share the same data in regard to job queues, app tokens and identities within your system. Each node should be configured with the same SQL server connection string.
We recommend using to store and version control the PowerShell configuration scripts used to manage the PowerShell Universal nodes. One-way git sync may be preferred as the nodes will then be read-only and pull configurations after they have been merged to your production branch. Each node pulls the configuration files on a configurable interval (defaults to 1 minute). Storing git configuration settings in the database is desired as it requires less configuration per node.
